# Agentic AI Standards and Engineering ROI

**Podcast:** Dev Interrupted
**Published:** 2026-10-06

## Transcript

Welcome back to Dev Interrupted, brought to you by Linear B.
My guest today is Manik Sertani, co-founder and CTO of the Agentic AI Foundation, the home of MCP, Goose, Agents.md, A2A, Agent Gateway, and so much more.
This one's a treat for me as an ambassador for the foundation, because I got to learn from Manik about slop cannons and bottlenecks.
and how they come down to the same culprits we discuss at Linear B.
That is, AI speeds up the coding and the cost moves downstream into review and rework.
So what should a team do about this seemingly insurmountable review problem?
You're about to find out in my conversation with Manik.
Usually I just know exactly where I want to start, but this one there's actually more things than I can bite into, so it's going to be a little trick to me.
And I want to start by saying, Manik, welcome.
to the show.
It's so great to have you on Dev Interrupted.
Thank you, Andrew.
I'm very excited to be here.
Yes.
And just to kick things off, I just want to say that, you know, as an...
AAIF ambassador, I feel like I have been drowning the airwaves over here at Dev Interrupted about all the things coming out of the foundation.
So we're really excited to dive into those topics today.
Really excited to host you and get some insights for our listeners, which are, you know, engineering leaders that are trying to understand how to grapple with these changes in technology and the things that they've taken for granted and how they're evolving.
And a part of that involves learning about the latest trends in technology, but also getting ahead about how most cutting edge.
teams are applying them to actually deliver value and make all of this AI stuff, you know, worthwhile in the end.
But I just got to say, before I jump into our conversation today, I wanted to ask, what has been the most exciting for you as you've kicked off?
the AAIF ambassador program, and you started rounding up a bunch of nerds like me under one banner.
What has that experience been like?
Because I just feel like I've seen so much love on every social media network since the program started.
Yeah, it's been incredible.
It's been overwhelming.
First off, thank you for being an ambassador.
The response has been crazy.
Here's a funny story.
When we first came up with the idea, the plan was we're going to have 10 ambassadors around the world, and we're going to start.
10 and then gradually expand.
We had an arbitrary number.
We just pulled it out of thin air.
And the moment we announced it, we got so many responses of people wanting to be ambassadors that we had a mechanism of scoring them as well.
And, you know, what have they done before as community organizers, things like that, right?
And we had a whole little algorithm in place.
And we had over 150 people which scored over 95%.
And it's like...
we're going to have a really hard time picking the 10 people out of this.
So we just blew the top off saying we're just going to remove the cap.
There is no arbitrary cap of 10.
And we launched with, I think, 140-something ambassadors from day one.
Yeah, the big cohort.
And it's so exciting because that's such a champagne problem to have.
Like, oh, there's so many extremely qualified and really amazing people out there all across the world that are looking to spread the news about MCP and other projects, some of which we're going to talk about today.
So and I and I definitely know when I saw the announcement that there were going to be 10, it definitely.
put this like competitive spirit in my mind too of like, oh wow, like what a great opportunity.
And so that made a lot of people surge to the challenge.
Because you know, you and Angie have done so much for kind of getting folks aligned around how the technology is moving and getting folks informed how to use it every day that there are so many folks that are willing to jump in and start making this kind of content, some of which we're going to dive into, including A2A.
being one of these latest additions to the AAIF.
And I kind of want to start there because as one of the most recent announcements that definitely has some of the biggest excitement around it, I want to know from your perspective at the AAIF, what does the A2A or the agent-to-agent protocol bring and what does it signify for the trajectory of, you know, open source agent ecosystems?
Like, what do you think its role will be to play alongside the other things you have under your wing?
Yeah, so A2A is genuinely exciting.
I'm really happy that it's here.
A2A as a project grew out of Google, as you're aware, and it already took the first few steps towards vendor neutrality and neutral governance.
So A2A already became a Linux Foundation project before it joined the AAIF.
In fact, it did that before the AAIF even existed.
So for us to bring it in, it already meant that a lot of the hard work had already been done.
It already had good governance.
good open source chops, and then the way it was run already, it was run well.
It was run well.
So it was easy to incorporate and bring it into the foundation.
But the really interesting thing to me, though, what it signifies is genuine vendor neutrality.
Now, as you're well aware, the AAIF was founded by MCP and Goose and Agents MD.
MCP, some people see it as a competing standard to A2A.
I don't think it is, but there is a perception out there that it is a competing thing.
And I think this really shows that, no, firstly, they're not competing, but even in the areas where they do overlap, it's genuinely vendor neutral here.
We don't actually care where these projects came from, whether it was from Google or from Anthropic, and such projects can coexist.
They can learn from each other and grow together.
It also breaks any of the preconceived notions that this is an Anthropic foundation.
It's not.
It is an open source foundation.
We're all friends.
We're all serving a greater purpose.
Yeah.
Now that you say that, it really jogs my memory.
I remember us covering on Dev Interrupted.
the original movement of A2A into the foundation and then other projects getting moved under the AAIF and then now all of them being brought under one umbrella.
It makes sense to see this trajectory of them coming to live under what I love how you call you called out that it's like it was already primed and ready and like in the right shape for us to like make it part of this.
And I think that's a big challenge getting all of these different.
stakeholders in the ecosystem to come to the table and work in these working groups and develop these standards.
I definitely have experienced that here in conversations, both like on the show and out in like the field at events, general confusion even around A2A versus MCP.
I feel like MCP tends to be like the golden stepchild that everyone loves and A2A is like deeply misunderstood and like.
just like no one really gets it and it's just like kind of angsty but it's serving its own real purpose as well I will say myself I've had a lot of luck using A2A.
We're also really big fans of Steve Yege and how he talks about software factories and agent orchestration here.
And we're practitioners of that as well.
We have a lot of like factory work behind the scenes here at Dev Interrupted and Linear B.
And a big part of that for me has been he talks about seats and identities that exist with agents over time and how they own their work and the things they do.
And for me, as I've adopted that kind of way of working to A2A has just become instantly much more.
prominent and useful in defining ways for them to communicate with each other.
My agents used A2A to come up with a protocol called Pinky, where they make promises to each other about things they're going to do.
And they use A2A to do that.
And I just was kind of shocked that they were able to pick up the spec and conform it to what they needed.
And those, I think, are the most exciting tools that they are to give the agents.
So to folks that haven't played around with A2A.
You know, I really recommend bringing it into your agent fleets and seeing, asking them what they think that how this could help them, because that's how this documentation is set up to help them as well.
What have you experienced with like adoption around those tools?
No, that's awesome.
I love the name Pinky for that protocol, by the way.
I was like, great job.
And there's even the little pinky emoji.
I was like, y'all figured this all out.
A plus to them.
What have you seen on your side?
No, I'm seeing, I mean.
It's really interesting from my perspective because I think the two protocols have come from different places.
I'm not talking about the companies that created them, but the problems they attempted to address.
And there is a lot of convergence and some of that is happening and they are definitely borrowing ideas from one another, but that's all right.
That's a healthy and a good thing to do.
But they broadly still address somewhat different markets.
And that's sort of what I'm seeing.
One interesting tidbit I can share is we've seen a lot of A2A adoption.
in China, for example, on mobile devices, where the ecosystem there is quite different from what you and I might be used to in the West.
Whereas over here, a lot of at least corporate workloads tend to be exposing SaaS systems or server-side systems or custom corporate systems to agents.
Whereas what we're seeing in China is an ecosystem of apps on mobile devices and those apps...
have built-in agents themselves and they need to talk to one another and discover.
The mode is completely different.
The mode of interaction is completely different.
Yeah, because here the mode is around the data, there the mode is around the agent.
You have all these agents that are living.
100% and have to coexist with each other.
Whereas us, we think about these layers of data and then what's the ultimate ingesture or like everything's a lake flowing into another data lake these days.
We've talked about that with a few leaders on the show.
And so it's a fascinating also to see them taking a step back.
It's almost like.
With technology, you have this whole thing with Conway's Law where how companies organize themselves and their cultures and their teams are is reflected in the shape of the software and services that they provide.
Now that software is a more ubiquitous thing that's used even like all across the world in a lot more different circumstances because of AI, you also get this like Conway's Law that's like of culture.
So maybe the shapes of the East and the shapes of the West are just fundamentally different in what they use the agents for because now it's an interpersonal mode of communication.
And both of them have their own systems for doing those things.
That's right.
That's exactly it.
And so like moving on with A2A, now that it's under the umbrella, you know, what's going to be its future?
What kind of exciting things do you see on the horizon for A2A now that it's kind of under the umbrella?
So a couple of things, right?
Like if I apply the lens of what has happened to other projects when they've joined the foundation, I expect a similar story here.
And that story simply is far broader adoption, far wider appeal.
Now, that's part of the reason why I started the foundation in the first place.
I don't know if I told you that story, but I was at Block at the time and I was leading open source for Block.
And one of the projects under my purview was Goose.
We just created Goose.
We just launched it.
It was gaining a lot of adoption.
And some of the pushback I started to see in the community was around neutral governance.
We had competitors using Goose.
We had potential competitors, distributors wanting to use Goose, like Red Hat wanted to package it and redistribute it.
But they all sort of stopped at the, I'm actually doing it because while it was Apache licensed, it wasn't in a neutral place, which meant they couldn't trust the roadmap.
They weren't guaranteed that there would be a rug pull or something like that.
So that's where I started to see the push for governance.
And that was the birth of the Agenda KI Foundation.
And David at Anthropics saw the same thing with MCP.
So we kind of joined forces and launched the thing.
But what we've both seen is the Goose story was like Goose's adoption just grew exponentially after the creation of the foundation.
That was kind of to be expected.
That's why we did it.
The surprise to me was what happened with MCP.
MCP was already flying high.
MCP was by far and away one of the most popular projects and protocols out there before the foundation.
It's almost like how much does it kind of go, right?
And guess what it did?
Like over five times, in fact, the number of downloads.
We have over a billion downloads right now of the MCP SDKs.
Oh my gosh.
And it's basically 5x in the eight months since creating the foundation, right?
And that's already for a well-known project.
For a slightly lesser-known project, still, that's a sort of hockey stick.
sort of growth we're seeing.
We saw that with Agent Gateway.
We're seeing that with other projects too.
And I expect to see the same with E2A.
I, again, know E2A is a popular project.
It has a lot of adoption, but I think it's going to increase a lot more.
There's a lot more runway for it to grow.
I'm excited to see that kind of hockey stick and where it's going to take it.
And, you know, you talked about Goose.
I will say, big fan of Goose.
here on the show.
We talk about Goose a lot, but also I myself am a user of Goose.
I'm an early practitioner and I was on an episode of Code TV with Angie Jones for Goose actually back in like October.
And that was a ton of fun.
We had a coding challenge where me and my coding partner was my friend from Google.
We had to create an app that you can cannot control with a keyboard or a mouse.
And we had to make it in four hours and we did it with Goose.
So you can watch us like totally fool around.
This is like try to figure out how to combine our two code bases.
This is sub agents were just then starting to be a thing.
Like I don't even think we're at Opus 4.5 yet.
Like it was a hard time for us on that show.
It's a total blast to watch it.
And so we used Goose and I've used Goose since a lot of my workflows are built on Goose.
And I think it's a really powerful tool.
And I totally agree with you.
I've loved to see how much it's grown.
I love to see how that happens with MCP as well.
And speaking of MCP, the darling.
Golden child.
I guess we must move on to the favorite one that everyone loves to talk about.
And us two here on Dev Interrupted because I feel like we talked about the MCP when it first hit the scene.
We talked about MCP when it first died.
We talked about MCP when it came back to life.
We talked about MCP when it died again.
We talked about MCP when there was a scoreboard about how many times it died.
And then now we've covered the latest spec where it became the 728 spec.
We're not calling it the 1.0 because that's a misclassifier for what it really is.
And it was all about the stateless design and what that's unlocking for teams now as they can get more operational with MCP.
And it's been really exciting to see how that architectural evolution has shifted us towards like a wider adoption.
Just curious.
what your thoughts are coming out of the 728 release and what you're most excited about.
Yeah, so I mean, like, that release is super interesting, right?
But again, just like most things happening in MCP, it's responding to demand from the community.
I actually think the MCP project is an incredibly well-run project where they are very close to the community.
They really listen.
And the 728 release was an example of that.
We understood where people's pain points were.
People are looking for ways to simplify things and improve.
And then we were able to do that.
So I think that's really powerful.
Like I said, excellent community stewardship.
In technical detail, I mean, statelessness, of course, is a big deal.
It's simpler to manage.
It's easier to deploy, things like that.
Easier to just wrap your head around.
So I think that's been a really interesting change.
What do you think is the maybe biggest challenge for teams now that it's stateless, right?
And teams can more thoroughly adopt and have these as like workflows that are exposed to customers or their employees and they don't have to worry about juggling this state, which before was kind of like very much a nightmare for serving MCPs at scale that were embedded within services and doing what folks love.
But now that MCP is stateless, what we envision to see is.
organizations finding ways to pack the value that they give the customers and their users into MCP tools that are then delivered into other surfaces too.
I also think about things like MCP apps and UI, and you have lots of MCP that pushes now interfaces into chat.
Do you think that becomes the next things that these things optimize for?
I'm just curious how you see like all the whole spec evolving even beyond the stateless situation.
Yeah, I don't know.
It really depends on what people do with it.
So I think a lot of, I mean, Just because the protocol is state, this doesn't mean there's no state.
A state still has to live somewhere.
People still have to manage that.
And that ends up getting pushed into the application.
That's not a bad thing.
That's a great place to manage a state, really.
And I think, well, it really depends on now what sort of shape those applications take.
So, yes, it's something to watch and learn and see how it evolves.
For sure.
And for...
Let's say that we're a team, like a larger engineering team, and we're using MCP servers internally to serve things between teams.
That's what I've seen as a really common use case, especially as ecosystems of enablement start to pop up within like a large engineering org.
You get this pocket over here that's really agentic, this pocket over here that's building agents and doing cool stuff.
They start to connect and share things with each other.
Other teams and departments now want to tap into this and use things.
And now those teams start to think, is MCP the tool that we use to open those gateways and allow the teams to interact with each other?
I'm curious if you think MCP has a place there or what you would say to that kind of team that's trying to figure out how to share their AI success across their different departments and stuff.
Yeah, absolutely.
I think those patterns have yet to be, I don't know, standardized, I suppose.
There's still many ways.
It's a wild west out there.
It's a wild west.
There are many ways to skin that cat, right?
Like each department could have their own agents and using A2A to talk to each other and coordinate perhaps, right?
Or perhaps you could encode what you do as an agent skill and share that.
And then anyone else can pick up that agent skill and run with it.
And then of course you expose your data endpoints as MCP endpoints.
So you have access to information from each department.
So it absolutely is the wild west.
There's a little bit of, there's no right answer, I suppose, what I'm trying to say.
and everyone's kind of doing it different, that's okay.
There's no wrong answer.
There's no right answer.
There's no Scantron that you can grade.
Unfortunately, not a lot of people have a lot of answers.
So the answer becomes to experiment.
So now it becomes a matter of having a bold experimental mindset, but then also having diligence and good record keeping and good understanding of what you're building and where it's going.
So a lot of this too.
especially with agents, right?
You start introducing agents and you have stuff working and running underneath you.
You start to get very abstract from all of the cognitive stuff going on in your work.
And that can make it really hard to be strategic, but then also to track the impact and understanding of like, oh, I have all these agents.
I'm using all these tokens.
I have all these workflows.
But what is it giving me?
What is it giving my team?
What is it delivering to like the end user, for example?
Do you have strategies for folks that are increasingly agentic to be able to tie and show the work they do back to like ROI or prove that maybe these workflows that they're building have this kind of durable value to them?
Because as you've rightfully said, like it's the Wild West, there's no right answer.
So how do you start to draw some lines down so folks can start agreeing?
Yeah, absolutely.
No, that's a tricky thing to do for sure.
I think there are a few things that need to happen.
Like one is always have a skeptical mindset, right?
Always come in to say, I actually don't know how much value this is going to provide.
It's very possible it'll be zero.
So you cannot be emotionally tied to your work.
You should be willing to throw it away.
And even some of the patterns we talked about may not be the right patterns.
And okay, that's fine.
Be ready to scrap it.
Be ready to move on or transform it.
Luckily, we're in an era.
where some of that change can happen very quickly and relatively easily.
So, okay, cool, embrace that.
Embrace the change.
Embrace being able to throw away stuff, let go of things.
But then it also goes back to what you were saying around measuring that ROI.
That's really important as well, so you know what to change, what to let go of, what to drop, what's working, what's not.
Yeah, so you need visibility and an understanding of your inputs and also those outputs.
You know, a really interesting tool within the AAF ecosystem that I've found really useful for this is Agent Gateway.
That's a tool that I've picked up and I've used personally.
And now I route most of my cloud code or whatever other sessions through this proxy through the gateway.
And the benefits of that have been really multiple for me.
And not only you get like the tracking on your token spend across all your tools, and it's very well labeled just out of the box.
But now you have the ability to pin all sorts of really cool and informative metadata to all of your API requests and do all sorts of really interesting analysis.
I wrote this article that I published on my website very recently about how, for example, I use Beads, the task tracker, to do agentic task work.
And I created a system where they could pin their Beads to the inference that they put in the gateway, which then unlocked an ability.
to tie tasks like discrete tasks that were thought through and then brainstormed and completed to their inference calls, therefore tying them to like a cost.
And it wasn't totally accurate, but it started to give me a ballpark about, you know, the different costs of the different things that I did every day or the workflows that I ran.
And it became really informative for me.
But it had to start by like getting that level of visibility.
I didn't know what questions I needed to ask until I saw the data.
And I was like, oh, why is 80% of this cost in the brainstorming?
Maybe I'm using the wrong model.
Maybe I'm giving it way too much stuff to read.
And that's actually unlocked a lot of opportunities for me to get better personally.
So I've thought of a lot of like interesting abilities for maybe teams to utilize that kind of thing as well.
But there's so many complications involved with being able to have that kind of good tracking and visibility.
Absolutely.
I was going to bring up Agent Gateway, but also Agent Router, which is a similar and related project and gives you a different set of information.
The interesting thing with both of those, though, the really interesting thing for me is that it gives you model independence.
And in this day and age, I think it's really important to have model independence.
Things are changing so quickly.
I mean, what's the best model for a particular task today may not be the best model tomorrow.
And it's not just bumping a version number.
Quite often, it's a different model from a different vendor, possibly an open-weights model.
And being able to do that, I think, is really, really important.
Your engineers used to write the code.
Now they review everything your software factory creates instead.
On October 29th at 10 a.m.
Pacific, I'm hosting LaunchDarkly's head of AI, Mark Pollux, and Kate Huston, author of O'Reilly's The Engineering Leader.
for a workshop on where the software factory is heading and what it asks of the engineers who design and govern it and how engineering health signals and linear B can distribute that review load.
The links in the show notes.
I'll see you there.
Yeah, it's like important to have like a substrate where you can collect all of those.
It's good to have these layers when you're working with these tools where Any kind of tool ecosystem layer where you're working, where there's a lot of providers and a lot of consumers on either side of it, it really benefits you as that person to also draw your line and have your block in there that everything moves through.
Otherwise, you just kind of end up in this like spaghetti web of like, oh, I use this and it goes this and then that goes that.
But if you have a centralized place, you can then start to have real meaningful conversations.
So then I guess maybe that's one strategy we've kind of unpacked here is like having visibility as a team on your usage and then tying that back to tasks as well.
But I want to talk for a moment about the engineers out there.
and the engineering leaders, especially to those listening to this episode, because they're in like a slightly different position with how they have to manage agents because they're not only all up and around the meta stuff of the work they're doing, but it's also their day-to-day grind.
You know, we're talking about in our recent research from Linear B, we found that even in like some of the most advanced or the most like mature AI adoption organizations where they have like a higher percentage of agentic PRs to human PRs, you still see overwhelmingly that those people PRs sit at like a really high unmerged rate.
Yeah.
Like in some cases, 70% of agentic PRs and like in a moderately agentic organization goes completely unmerged.
So then you have to start thinking about like what kinds of costs go into that and what do you get out of that?
And parts of that are obviously.
Our SDLC has new bottlenecks.
We talk about that a lot here, especially bottlenecks around review.
That's the new, that's where a lot of the work is happening now.
What advice would you give for engineering teams that maybe are struggling under those kinds of workflows or encountering those new bottlenecks?
How can they get ahead instead of choking at them?
Yeah, that's really interesting.
So I'm seeing that not just in engineering, by the way, but in other disciplines as well.
I had an interesting term yesterday.
Someone referred to people who publish PRs like that as slop cannons.
Yes.
What do you do with the slop cannons?
These people are shooting stuff at us constantly.
And I mean, like, how do you deal with this, right?
It's interesting.
I don't think there's a clear answer yet.
I've seen teams approach fight AI with more AI, right?
Great.
You're getting lots of AI-generated PRs.
We need AI-generated code review.
Sure, that makes sense.
Is that enough?
Probably not, right?
Are you still going to get swapped by those?
Probably.
And then also in the age of, I don't know, code being generated for next to free, right?
Or just the cost of tokens.
Do I really value a PR anymore?
I mean, am I just using that PR as a way to get someone else's tokens, someone else's token budget?
That's all it is, right?
So what's the point of the PR, really?
Just give me the token budget.
I'll do it myself.
So there's a little bit of that as well, some thinking there.
And then there's another bit of thinking around the code review itself.
Like code review at scale for open source projects is different.
But if you're talking within a corporate environment, sure, code review happens.
How good is the code review?
How high is the quality?
Is it useful?
I don't know.
You're more relying on the author of that code to actually know what they're writing.
That's more important than some of those cases, right?
The problem that I've seen in larger corporations, is where the code generation part is happening automatically.
Even though it's being signed off by an author, that person's not even reading that code.
So why then should someone else go and review that code, right?
So it's like, okay, tell you what, how about this is a trade-off?
I will skip the code review part.
I'll have an AI do the code review, provided you as the author read your own code that you've generated and approve it.
And how do you hold that person accountable to that?
So that's a more interesting question, really, at this point.
and probably more relevant as well.
So that's as far as what happens with a corporation.
In the open source space, it's a bit different because, again, you have no accountability to one another.
It's a bit harder.
I've seen a couple of projects do, including Goose, by the way, doing this now, which is quite interesting, where they've stopped accepting PRs, full stop.
We don't want your PRs.
It's nothing but a conduit to your tokens.
We want your ideas.
If you have a bug, tell us about it.
If you see a bug, tell us about it.
If you want a feature in Tell Us About It, we're accepting issues, file an issue, a detailed, well-written-out issue, and we'll point an AI to that to generate the code.
Yes, absolutely.
That has been a really interesting shape, and you're actually getting into a burning question that I had for you because it's something we've talked about many times on the show, is about the open-source ecosystem just completely drowning underneath.
The AI world.
Like I was I remember there was an early canary in the coal mine and that was Hacktoberfest.
Right.
And it's like there were everyone saw the evolution of this getting really spammy and then now got to a point where you have open very big, very important open source projects that actively turn away or don't allow those kinds of contributions.
You see really in a total evaporation of new contributor, new maintenance, maintainer onboarding because good first issue.
doesn't exist in an agentic world.
And so you really kind of, and then that ruins the ability to like make maintainers of tomorrow.
At the same time, this is like a mini version of the whole build versus buy conversation that everyone's having on everything on their line budget.
Do we just build this?
Do we buy this?
And there's a whole bunch of reasons for why we've unpacked that up, down, left, right on Dev Interrupted, including in a number of webinars and workshops about it.
And I even tried to build Linear B.
You know, at one point I was like, I just like build our own thing.
And I just did it like live on a live stream because everyone was trying to figure this question out.
And another part of it, too, is that those folks that had those projects, they didn't know how to engage with their community anymore.
They became, in fact, estranged.
from their users because their users were no longer humans that loved the project and it fixed some problem for them.
It was a random agent who plugged them into a package JSON somewhere and then they just ended up deployed and there's no more of that kind of fostered connection.
So what is your advice to the open source world?
Is it right for them or do you think the strategy is going to scale for them to keep the walls and the gates closed?
Do you think they have to change their mindsets?
Because what you've just described around the whole issues approach is the approach that I have seen work in the last year.
There's a number of open source projects that I respect and use a lot.
One of them being the Beads Rust Library from Jeffrey Emanuel that I use, and he doesn't take any PRs either.
The man has like a thousand Claude Max accounts.
He doesn't want your tokens.
He just wants your ideas.
And he just wants to make sure they're perfectly aligned with whatever mental system him and his agents have mapped out in all of the way of how they thought the software should work.
And so people drop in issues and he closes them, opens them.
It's really fascinating.
Actually, one of my issues then got turned into something that they merged.
But, you know, I did feel as a contributor, I guess, in this situation, a little divorced from the contribution experience.
So how do you think this is all going to evolve?
What's your advice for this folks?
Yeah, I think the contribution experience, as you say, changes drastically.
It shouldn't go away.
I think it's important for project maintainers to stay connected to their communities.
But the shape of that community changes now.
The community is no longer a community that's giving you code because that's, again, not where the value is.
The value has moved.
Value is in sharing ideas, in sharing experiences, in sharing thoughts.
And I think a good maintainer will shift gears now.
and spend a lot of time creating those community spaces where the community can contribute where the value is, right?
Like, tell us about what's going on with the project when you're using it.
Tell us what goes wrong.
Tell us what goes right.
Tell us what you wished you had.
All of that stuff.
Share ideas, share experiences, and that's where the value is.
And spend time writing it out, perhaps, right, in a really well-crafted issue that an agent can pick up and run with and go build.
But, you know, don't just throw...
slop in terms of here's a pr that that's the key thing is like you do have to curate the slop out it's like a lot of a nucleus now of starting like a good project or a project that's going to be able to foster collaboration across multiple people is you have to fight really hard at the beginning to get a crystallized super clear version of what you want without any of any echoes of those weird slop things in there because those echoes just they they just boom once you let them like fester in some original document.
And so there's like the scope of the work where you've put your attention changes.
You've rightfully called out how.
You know, code is cheap now.
Code is free now, basically.
So it's not about the value of you giving your code contribution.
It's not what I need.
I need your idea.
Because that's the real bottleneck.
In open source, it's around discovery.
Engineering teams, it's around alignment and delivery.
But those are like the main kinds of bottlenecks for sure.
By the way, Dev Interrupted is an official media partner of AgentCon, MCPCon North America in San Jose, happening October 22nd and 23rd.
I'll be there with more than 3,500 builders and speakers from Anthropic, OpenAI, Okta, and more, digging in the MCP and the agent infrastructure we all build on.
Check out the show notes to learn more.
Diving back out of the open source world for a second and talking about those engineers again that are more in like a traditional like engineering org, a lot of them too, I want to get your perspective on this evolving narrative of the software factory.
of this idea that, you know, all of this is going to become automated in some sense from end to end.
And humans kind of get relegated to these quartered aspects of it where you have the domain experts at the very beginning.
You have the ideas and the alignment where you bring in customer ideas.
And then you have the verification and check and alignment and review on the end.
But a lot of the stuff in the middle gets automated.
Are you bullish on the software factory?
Do you see it taking a different shape?
I'm pretty bullish on it.
I think that is the way it is going to end up.
Are we there yet?
Are we there now?
I don't think so.
I think we are perhaps in very constrained pockets, perhaps, or very narrow pockets.
But I don't think we're broadly there.
I do think that's where we go, for sure.
Do you think engineers evolved to become these factory foremen, these people who are building the factory?
Do you think that's what happened next?
100%, 100%.
And I think that's a mindset shift.
that we need to be prepared for and prepared to take.
I think it's a really important shift.
And shifts like this have happened before.
Like once upon a time, being a programmer meant writing machine code.
And, you know, people who wrote machine code would laugh at, you know, anyone using a high-level language saying, you're dumbing down programming, what are you doing?
But of course, that was a necessary step to achieve scale.
And similarly, I think this would be the next, you know, step of scale that we achieve.
by adopting something like a software factory.
And we then have to move to a higher order of thinking and thinking in terms of systems and broader sort of outlook versus just thinking about the programming.
The programming bit is not that important, actually.
The engineering side is much broader than just programming.
Yeah, absolutely.
And it is a lot about a mindset change and it's about changing the ownership about the work that you do.
We talk a lot about the show, about you owning now the decisions.
behind what happens as opposed to the actions being directly done themselves.
And so it's definitely a shift for folks that are typically used to everyday writing code, but a lot of opportunities to to change the way and evolve the way and discover the new ways that we're going to be working.
Because like you said, there's no right or wrong ways to do this.
which allows a lot of us to then kind of experiment.
And for those that are maybe experimenting and they're pushing the edges of what agents can do and how they can collaborate with each other, you know, there's a lot of interesting lessons that I see coming out of these open source standards and these ecosystems that you're maintaining.
And obviously you have MCP addressing the whole question around.
tool usage and how do we make them action wise and useful?
And you have A2A, which is starting to answer this bigger question of how do you allow agents to communicate and coordinate and collaborate?
These are deeply like systemic elements of can these things be productive?
Do you think there are other systemic elements of them being productive that maybe are still missing or maybe that we're still trying to figure out or that you think would be?
would be next any any opportunities you see oh obviously is everywhere opportunities galore right now uh which direction do you want to go in right like from a tooling perspective absolutely there's a ton of stuff that we still need as humans to interact with machines in a software factory type environment for starters um is github the right answer there anymore i don't think it is we need something that'll track more than just human scale pool requests.
We need something that will give you the genesis of what prompts were used to get in a particular outcome, things like that.
But also the Gitforge, the birth of the rebirth of the Gitforge.
It's way, way, way overdue.
I feel like we cover this a lot on the show because everyone is just chomping at the bit for a new Gitforge because the problem has changed.
And one needs to live in the forge has changed.
The problem has changed.
The type of usage has changed, all of this stuff, right?
And then you've got the situation where you potentially want adversarial agents building a thing.
I think that would be fantastic if you had something built into something like Git or something like GitHub, where you could have multiple agents tackling the same problem, backed by different LLMs even, and sort of fighting it out to find the right answer, the best answer, critiquing one another and things like that.
Again, GitHub is built for that.
It's a human scale and it doesn't work like that.
So there's a whole bunch of stuff around tooling over there.
But even on the review side, as a human reviewer, where you want to sometimes be able to step in and check or just to be able to view an audit trail of what happened when a bunch of adversarial agents tried to build a thing.
What were the things they considered?
What were the things they dropped?
What were the decisions they made?
What were the decision points?
And you want to be able to walk through that.
That's more important, again, than the code.
It's sort of inquiring what the thinking process was.
We don't have the tools for that either.
I mean, we've got a log of stuff, but no one's going to read through all that.
I mean, it's something a lot more intuitive and easier to use.
And then, of course, there's a whole bunch of stuff around security and identity and authorization.
Who is allowed to do stuff?
And we haven't even touched on it.
So far, we're just talking about building software.
There's still the deploying and running of software, which I think, again, is a whole separate area that needs a lot of work and the tooling around that.
Same thing again, the audit trails.
How are you going to ensure the thing did what it was supposed to do?
How do you provide the right levels of access?
How do you revoke the right levels of access at any given point?
Like really short-lived tokens, things like that.
And then, of course, there's overarching all of this is the issue of hallucination, which, yes, is driving down.
It's less and less common.
But still, you want verifiability.
You want to be able to know that an action taken was based on real information, not something made up.
How do you trace that?
How do you make sure you can verify that and roll something back if something bad had happened along the way?
So yes, there's a huge tooling gap, I think, all the way across.
Yeah, so if you're listening to this and you're thinking, gosh, I wish I could invent the next MCP or the next A2A, there are still plenty of opportunities out there is what I'm hearing.
Yes, and also to the...
just the development overhang that we have right now like there could we could cease having all development and improvement with models as they are today.
And there would still be so much work to be done across all industries and all places of the world based on what we've found so far just in the last few years that we have plenty to keep us busy.
And so I think it's really interesting to explore the problems and to figure out what's going to be most important.
And two, to see how these organizations are coming together to collaborate on these specs, but also to come into working groups and kind of mature these standards that are going to be powering the technology of tomorrow.
It's all a really exciting opportunity.
And maybe this is an opportunity, too, for our listeners.
If many of them are on teams where they're using these types of technologies, but also maybe they've rolled something of their own that's like a weird cousin or a weird brother to one of these things.
It definitely is happening.
I'm talking to orgs that are kind of hand rolling and hand creating all sorts of different ways and systems of their team.
teams communicating or their agents communicating.
And so what advice would you say to teams that are experimenting and maybe haven't conformed to the standards, or maybe they have ideas about what the standards could do that doesn't match what they need.
So they ended up evolving into something different.
How do they come to the table?
How do they make these kinds of tools match what they need and join?
That way we can all kind of work together as an ecosystem.
Yeah, so experimenting is great, right?
Like I love it when people do that.
I'm glad people are doing that.
And we sort of seem to have found ourselves in this Cambrian explosion of ideas.
I love it.
It's going to shake down.
Some things are going to go away.
I mean, that's normal, right?
I think that I mentioned this before, teams need to be not too married to a particular idea or particular approach they have.
If you do see a better approach, be ready to drop one and move in with the other.
So a really good example is Agency.
There's a Cisco consortium that they stood up around agentic tools and frameworks.
And one of the things that Agency built was something called ACP, not the agent client protocol ACP, not the agent commerce protocol ACP either.
It's a different ACP, which turned out to be very similar to A2A.
And when A2A came about, in the end, Cisco realized, you know what, even though we've spent a lot of time and a lot of effort developing this protocol, and it's in production use and everything else, we're going to sunset this and we're going to double down on A2A.
In fact, we're going to move our resources over.
We're going to join that project.
So I thought that was a really healthy sort of way of sunsetting one thing and doubling down on the thing that's getting a lot more momentum.
So I love the fact that people are experimenting.
That's great.
Bring in the ideas, right?
Contribute the ideas.
At some point, you might end up joining another project and sunsetting.
That's okay.
Be prepared to do that.
Or the opposite might happen.
You might find other people sunsetting theirs and joining yours.
That's also a win.
So yes.
Right.
It's about experimenting.
It's about experimenting.
And the whole point of experimenting is you can't be too tied to an outcome.
Exactly.
You have to have that bold experimental spirit.
And that means throwing away experiments when they don't work or joining others when there may be on to more of a hunch.
But it's also to I love the ACP narrative, not first ABC or not the second ACP, but the other ACP.
But I love that.
Okay, well, when there's a fourth one that pops up, we'll add them to the list.
And actually, what I loved about that story is it reminds me of a guest we had on the very beginning of the year.
They might have been like the first episode of 2026 or the second.
Tyson Singer is the platform leader over at Spotify.
And we talked about Spotify backstage.
And we talked about the IDP.
And you know how Spotify is basically like synonymous with the IDP and the engineering world and backstage is in portal or like an industry standard.
And we talked about their.
story of how they established that standard, but then also to how strategically for them, the reason that they established and created that standard when no one else was doing it was because it was going to save them a huge cost and mental burden later of not aligning to something or not establishing an industry-wide standard.
And then later having to change theirs to match and march up with everybody else once they all caught up with the memo because Spotify was way ahead on what these engineers.
needed at scale.
So that was a fascinating conversation for them that it was just as much about the technology, but also on a strategy level of just avoiding the pain of having to do a really painful transfer later.
So right now, what I'm hearing from you and your story is like, we're in an experimental phase, we want to be bold and experiment.
We also want to be bold and be able to join larger standards as they start to formalize, because that's where you're starting to get more standardization around how the things are used to get more across.
compatibility across orgs.
And you just get more people bought in in conversations around the technology you're building because you're using the same language as everyone else.
And it doesn't have to mean abandoning things either.
Yeah, and more momentum as well, right?
Like if an existing project has more momentum, it will go further than yours.
So looking at where it's going to go in the future as well, it's better to get behind something that has that kind of momentum behind it.
So I guess the answer is really keep experimenting.
That's a good thing, but also keep an eye out.
I wanted to end by asking you, which A2A project do you think doesn't get enough attention?
That's interesting.
I don't have a good answer for that.
We're still pretty new with A2A right now.
You love all your children.
There's no one where it's like, oh, well, maybe that one just doesn't get quite the spotlight.
That's right.
Now, spending a lot of time with A2A at the moment as we're onboarding them and they're still new to the foundation.
getting to know where the opportunities are and where things can be boosted.
That stuff we're still working out and where they need help and things like that.
Yeah, totally.
But in general, they've got a lot of momentum.
It's great to see the momentum behind them.
Lots of momentum in places I wasn't expecting.
Like I said, the China mobile story.
And I mean, stuff there happens at such a scale.
They try a little beta experiment on, you know, 40 million users.
It's like, what?
You deploy that to 40 million users and that's a little tiny beta experiment running in the corner.
Wow.
The scale is just crazy.
Scale is very crazy and the systems are just totally different too.
So it's a whole different game.
But it's been really interesting to explore just even the shape of how this technology matches the different teams.
We've talked about how it matches different cultures and also different companies, but also conforms to the individual needs of the developer.
And so there's just so many ways that this technology can be customized, but then also augmented with these really powerful and important technologies within our ecosystem that we're all sharing.
figuring out how we're going to be using today, tomorrow, and the days to come.
And so, Monik, it's been amazing to have you on this show to kind of give us a high-level view of the different things in your ecosystem, how you see them evolving.
And you've given us a lot of tips for the engineering leaders listening about maybe how they take this back to their teams, think about their bottlenecks as well.
Where could our listeners go to learn more about some of the latest work coming out of your org and the things you're working on?
Absolutely, yeah.
Well, thank you for having me for one thing.
It's been a really fun conversation.
I'd like to point people to aeif.io.
That's the AEIF website.
It's got information on our working groups, on our blogs, events, news.
We even have a newsletter called the Daily Agentic Newsletter, which is on LinkedIn.
You can find it there.
And of course, I personally blog as well on manixertani.substack.com.
So me on Substack, you'll find me there.
I write a lot about ColdPings open source and AI.
Amazing.
We'll include those links with our show notes and also in our newsletter that we include with all of these episodes.
Because, you know, if you're listening to this and you made it this far, maybe you're watching us on YouTube or listening to us on Spotify or Apple.
Definitely be sure to give us a like or subscribe wherever you're listening.
Drop a comment as well.
But definitely come and find Monica and I online.
Tag us.
Share your opinion.
Bring us into some of the projects you're working on or how.
to show us how you're using MCP or A2A.
We would love to hear from you based on our conversation today.
So definitely be sure to tune in and be sure to follow Monik online as well.
So Monik, thanks again for coming on Dev Interrupted.
It has been a total blast hosting you.
I'm going to have to have you again very soon on the show, or maybe we'll see each other on the road because I know there's lots of events on the horizon for you.
So it's been really great chatting.
Absolutely.
Thank you again for hosting me.
This has been fun.