One Year of MCP — with David Soria Parra and AAIF leads from OpenAI, Goose, Linux Foundation

One year ago, Anthropic launched the Model Context Protocol (MCP)—a simple, open standard to connect AI applications to the data and tools they need. Today, MCP has exploded from a local-only experiment into the de facto protocol for agentic systems, adopted by OpenAI, Microsoft, Google, Block, and hundreds of enterprises building internal agents at scale. And now, MCP is joining the newly formed Agentic AI Foundation (AAIF) under the Linux Foundation, alongside Block’s Goose coding agent, with founding members spanning the biggest names in AI and cloud infrastructure. We sat down with David Soria Parra (MCP lead, Anthropic), Nick Cooper (OpenAI), Brad Howes (Block / Goose), and Jim Zemlin (Linux Foundation CEO) to dig into the one-year journey of MCP—from Thanksgiving hacking sessions and the first remote authentication spec to long-running tasks, MCP Apps, and the rise of agent-to-agent communication—and the behind-the-scenes story of how three competitive AI labs came together to donate their protocols and agents to a neutral foundation, why enterprises are deploying MCP servers faster than anyone expected (most of it invisible, internal, and at massive scale), what it takes to design a protocol that works for both simple tool calls and complex multi-agent orchestration, how the foundation will balance taste-making (curating meaningful projects) with openness (avoiding vendor lock-in), and the 2025 vision: MCP as the communication layer for asynchronous, long-running agents that work while you sleep, discover and install their own tools, and unlock the next order of magnitude in AI productivity. We discuss: * The one-year MCP journey: from local stdio servers to remote HTTP streaming, OAuth 2.1 authentication (and the enterprise lessons learned), long-running tasks, and MCP Apps (iframes for richer UI) * Why MCP adoption is exploding internally at enterprises: invisible, internal servers connecting agents to Slack, Linear, proprietary data, and compliance-heavy workflows (financial services, healthcare) * The authentication evolution: separating resource servers from identity providers, dynamic client registration, and why the March spec wasn’t enterprise-ready (and how June fixed it) * How Anthropic dogfoods MCP: internal gateway, custom servers for Slack summaries and employee surveys, and why MCP was born from “how do I scale dev tooling faster than the company grows?” * Tasks: the new primitive for long-running, asynchronous agent operations—why tools aren’t enough, how tasks enable deep research and agent-to-agent handoffs, and the design choice to make tasks a “container” (not just async tools) * MCP Apps: why iframes, how to handle styles and branding, seat selection and shopping UIs as the killer use case, and the collaboration with OpenAI to build a common standard * The registry problem: official registry vs. curated sub-registries (Smithery, GitHub), trust levels, model-driven discovery, and why MCP needs “npm for agents” (but with signatures and HIPAA/financial compliance) * The founding story of AAIF: how Anthropic, OpenAI, and Block came together (spoiler: they didn’t know each other were talking to Linux Foundation), why neutrality matters, and how Jim Zemlin has never seen this much day-one inbound interest in 22 years — David Soria Parra (Anthropic / MCP) * MCP: https://modelcontextprotocol.io * https://uk.linkedin.com/in/david-soria-parra-4a78b3a * https://x.com/dsp_ https://x.com/dsp_?lang=en Nick Cooper (OpenAI) * X: https://x.com/nicoaicopr Brad Howes (Block / Goose) * Goose: https://github.com/block/goose Jim Zemlin (Linux Foundation) * LinkedIn: https://www.linkedin.com/in/zemlin/ Agentic AI Foundation * https://agenticai.foundation Full Video Episode Timestamps 00:00:00 https://www.youtube.com/watch?v=z6XWYCM3Q8s Introduction: MCP's First Year and Foundation Launch00:01:17 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=77s MCP's Journey: From Launch to Industry Standard00:02:06 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=126s Protocol Evolution: Remote Servers and Authentication00:08:52 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=532s Enterprise Authentication and Financial Services00:11:42 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=702s Transport Layer Challenges: HTTP Streaming and Scalability00:15:37 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=937s Standards Development: Collaboration with Tech Giants00:34:27 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=2067s Long-Running Tasks: The Future of Async Agents00:30:41 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=1841s Discovery and Registries: Building the MCP Ecosystem00:30:54 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=1854s MCP Apps and UI: Beyond Text Interfaces00:26:55 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=1615s Internal Adoption: How Anthropic Uses MCP00:23:15 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=1395s Skills vs MCP: Complementary Not Competing00:36:16 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=2176s Community Events and Enterprise Learnings01:03:31 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=3811s Foundation Formation: Why Now and Why Together01:07:38 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=4058s Linux Foundation Partnership: Structure and Governance01:11:13 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=4273s Goose as Reference Implementation01:17:28 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=4648s Principles Over Roadmaps: Composability and Quality01:21:02 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=4862s Foundation Value Proposition: Why Contribute01:27:49 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=5269s Practical Investments: Events, Tools, and Community01:34:58 https://www.youtube.com/watch?v=z6XWYCM3Q8s&t=5698s Looking Ahead: Async Agents and Real Impact This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.latent.space/subscribe https://www.latent.space/subscribe?utm_medium=podcast&utm_campaign=CTA_2

• 0:06Speaker 00

  Hey everyone, welcome to the Lit in Space Podcast. This is Alessio from the Rocco Labs and I'm joined by swyx, editor of Lit in Space.

• 0:13Speaker 01

  Hey, and here we are joined finally in the studio for the first time. Welcome back, David from Anthropic/MCP.

• 0:19Speaker 02

  Yeah, hey, well, nice to finally talk to you in Perth then. Last time, like a year ago, it was over VC and this is way fun.

• 0:27Speaker 01

  I watched it back, those eight months. It's been a crazy eight months and I think we just celebrated like the one year anniversary of MCP.

• 0:34Speaker 02

  Yes.

• 0:35Speaker 01

  At least the public announcement.

• 0:36Speaker 02

  Yeah.

• 0:37Speaker 01

  And also last night or yesterday was the AGentic AI.

• 0:40Speaker 00

  On the launch.

• 0:41Speaker 01

  Launch.

• 0:42Speaker 00

  Yeah, that was nice. It was a nice event. It was nice to see the Anthropic office.

• 0:46Speaker 01

  Yeah.

• 0:46Speaker 00

  And I've been.

• 0:46Speaker 01

  You like it?

• 0:47Speaker 00

  Yeah.

• 0:47Speaker 01

  It's very good food. I would say in terms of my food bench, Anthropic does rank over OpenAI.

• 0:54Speaker 00

  Yeah.

• 0:56Speaker 02

  At least that's what we have going for us.

• 1:00Speaker 00

  Awesome, man. Do you want to give just a quick overview of what's happening with MCP? And now you're donating it to the foundation and then we'll do kind of like a one year recap of the protocol itself. And then we'll have the rest of the leads from the foundation join us to do more of the high level.

• 1:14Speaker 02

  Yeah, that sounds good. Yeah, I mean, where we at at the moment, we have done like a year, like a year ago, we launched it. And then we had this like crazy adoption over the last year now, which it feels like an eternity, honestly. But we have this like crazy growth and like adoption, you know, through initially through like Thanksgiving and Christmas. Very early was a lot of like builders building MCP. And then, you know, you had like the first big clients coming in like Cursor and VS Code. And then like you had this like inflection point around April with like Sam Altman and Satya and Sundar and all. I'm posting about like MCP and that they're going to adopt MCP at Microsoft, at Google, at OpenAI.

• 1:59Speaker 02

  And that was really like the big inflection point. So.

• 2:01Speaker 00

  Yeah.

• 2:02Speaker 02

  But in all of the time, you also had to do a lot of work on the protocol itself, right? We like, we moved, we launched originally as like basically local only. Um, we could like build local M C P servers for cloud desktop. Um, but then we like in March this year, we moved into like, how can you do remote M C P servers to connect like really about like to a remote server? And introduced like the first iteration of authentication. And then in June, we revisited that and like improved it quite a little bit so that it works better for um, you know, uh, for enterprises in particularly. And we were very, very lucky that in that time from March, like June, we're like able to like have absolute industry leading experts that literally work on O R itself to help us with some of the

• 2:47Speaker 02

  the pieces, right? Um, and how to get it right. And then we focused a lot of on like security best practices and this type of work. And now we're like, I feel we have a really solid foundation. We're doing, we just launched like in our end of like November than the recent iteration of the protocol. Finally, like the next bigger improvement of the protocol, which is like long running tasks to really allow for like, you know, deep research type of task and like, you know, maybe even agent to agent communication. And so I think we're just stepping into like this territory now with like, okay, we have really solid foundations. We have like one more big primitive we wanna have. We wanna make like a little bit more scalability, things work. And then we're, you know, gonna get into a phase where it's probably becomes a bit more stable.

• 3:33Speaker 02

  And so, yeah, it's been, it's been absolutely crazy, man.

• 3:35Speaker 00

  You did say the agent to agent, so there is a A two A protocol. Um, I'm curious when the Agentic Engineering Foundation got formed or just the Agentic Foundation. Was there any discussion about any of these other protocols being a part of it? Or, you know, Sean wrote a post called Y M C P one.

• 3:53Speaker 02

  Yeah.

• 3:53Speaker 00

  Already, so.

• 3:54Speaker 02

  One of my favorite posts of the year.

• 3:55Speaker 00

  It was already.

• 3:57Speaker 02

  It was, and it was before Seb and all the other guys. Yeah, yeah, you were right.

• 4:02Speaker 00

  Well, I mean, I, I think it was just obvious that was going to happen.

• 4:05Speaker 02

  Yeah.

• 4:05Speaker 00

  So.

• 4:05Speaker 02

  Yeah. So we of course have conversations around like what else is in the market, like there are payment protocols that are interesting and so on. But when we wanted to to start a foundation, we wanted to make sure, first of all, two things. We wanted to start it small and make sure that the group that is founding this, like for us, it's the first time we at Anthropic have an open source foundation. So this is all new to us. So we really want to start it small and making sure we're learning along the ways and being able to like shepherd this in the way we feel is best for the industry, together with OpenAI and Block. But the second part of that is also like, we really felt like we wanted to see things that have a lot of adoption or D factor like, at least on the protocol side,

• 4:49Speaker 02

  like a D factor standard. And I don't think any of the other protocols, it feels like they're not just there yet. But of course, if they get there, then we're like super open, as long as they're like complementary to what's in the foundation. On the application side, we're a little bit more flexible and we're like more open. But on the protocol side, I think we really want to make sure that we're not like offering, like the foundation doesn't encompass like five protocols for the same like communication there. And so, yeah, there was discussion, but I think for now, we just want to start it small.

• 5:21Speaker 01

  Is there a role, like a double hat that you have now with the foundation? Or are you more focused on MCP?

• 5:28Speaker 02

  I am still mostly focused on MCP. It's a bit of a double hat. So there is just like, I think people need to understand like the foundation part is mostly just an umbrella to make sure the projects under it stay always neutral. And I think that's really the most important part you want to get a lot, you know, want to understand. Because the rest of it is like, okay, how do we use the budget of the foundation for events and things that are like quite dry? And then the technical parts to like MCP, they stay actually the same. Like on the way we govern MCP, nothing has really changed. And so that's really still my job is to lead core maintainer of like shepherding the processes, shepherding the protocol forward. And then beyond that, now the additional double role is like,

• 6:10Speaker 02

  I'm also going to be on the technical steering committee of the foundation, which will like make sure. Sure to like figure out what are the projects we want to have in the foundation. So if someone comes with a project to us, the people that have projects in it will decide is this something we would want? Is this something that we feel is like well maintained, has a lot of adoption, is not going to go away? We want to make sure the foundation is have like super interesting and important projects and not like a dumping ground like have, you know, some foundations might have ended up with.

• 6:42Speaker 01

  That's true. So we're going to meet some of the others later, but maybe we'll just focus back on the MCP development.

• 6:48Speaker 02

  Yeah.

• 6:48Speaker 01

  You've covered a lot. There's been four spec releases.

• 6:51Speaker 02

  That's a lot.

• 6:51Speaker 01

  Yeah, so people may have missed some of them. That's what I'm saying, right? Like, and I think it's really interesting how you we've continued to work on like really important parts. Like, I I always think like it's very hard to follow up a major success with a sequel.

• 7:06Speaker 02

  Yeah.

• 7:06Speaker 01

  Because the sequel usually like is it's hard to repeat.

• 7:09Speaker 02

  Yeah.

• 7:09Speaker 01

  That impact. But I think like every single time you've actually managed to like focus on something important.

• 7:14Speaker 02

  Yeah.

• 7:15Speaker 01

  So maybe we can cover, I guess, maybe we'll start with the the March, May one, which is HTTP streaming, which is good. And the off spec.

• 7:23Speaker 02

  Yeah.

• 7:24Speaker 01

  Any other, I don't know if you want to highlight any others, but we'll just catch people up on that stuff.

• 7:28Speaker 02

  Yeah, so that that was, I think that was really a, that was such an important one, like.

• 7:32Speaker 01

  It was the number one requested thing.

• 7:34Speaker 02

  Yeah, it was like, it really opened up this like remote thing and we were, we already knew actually in December, in November, that the next big thing will be like, how can you do this over the, over remote? And authentication is quite important. One of the things I think people very rarely notice when it comes to MCP, MCP is very, very prescriptive in like each layer. Like other protocols are not like that. For example, like we like, you want to do authentication? If the client and the server don't know each other, you need to do all, right? And so we were very early, we wanted to have like one way to do something. And so we really focused on like, what does this mean? Like, how do we get it over? How do we build a protocol that has this like these streaming properties that we require? And then how do we do authentication very early?

• 8:19Speaker 02

  Authentication, in the first iteration, I think we did an okay job, but we got some aspects wrong. And most of them honestly were just mean. Understanding enterprises well enough. But then again, I think the the strengths that we have with M two P, and I think the one thing, if anything, I'm proud of is like building a community of people that can come together and help me figure shit out because, you know, I have my set of experiences of like what I'm good at. Um, and enterprise authentication turns out is not one of them, right? But they're way better suited people for that. And so that's when we like, after that March.

• 8:51Speaker 01

  I saw, I saw you post that, but I didn't really dig into the details. Was it like the the close Samos uh Skype type of authentication issue?

• 8:59Speaker 02

  The main issue we did is um in in all, there are two components. There is an, this is authentication server who gives you the token. And then there's the resource server, it takes the token and gives you the resource in return. And in the first iteration of our authentication spec, we combined them together into the M two P server, which if you were building.

• 9:20Speaker 01

  Unusable, yeah.

• 9:21Speaker 02

  The i- it's kind of usable if you build like an M two P server, like has like a, like a public server as a, you know, your startup, you're building a server for yourself. You want to bind this to um the accounts you already have, that is completely usable. The reality in enterprises is you don't authentic, you authenticate with some central entity like, you know, you know, you have some ID, IDP provider and IDP.

• 9:45Speaker 01

  And you go up to.

• 9:46Speaker 02

  And also. Yeah, for most people, they what, they don't even notice that it's happening. All they know is like, oh, in the morning, I'm gonna go login with Google for and then get access to all my work stuff, right? But that's effectively the IDP, right? Um, and if you combine these into the same server, you just can't do this anymore. And so all we needed to do is like, okay, we are a resource server. Yeah, M two P server is a resource server, how you get the token from the authentication server. We have opinions on how you should do it, but it's kind of separated. And that's what happened then in the June spec where we separated this out. Um, and worked through all of these like, okay, now how do you do dynamic client registration and other aspects? Which also were part of the March spec, um, we can talk about that, that's a whole other story of like. We are actually pushing the boundaries of what OAuth can do with MCP,

• 10:31Speaker 02

  because we're trying something very unique with MCP. But yeah, that was the big part in March, which we like. And that was that authentication spec, the first iteration, then fixing it in June.

• 10:43Speaker 00

  Yeah. Wasn't the state of agents authenticating on my behalf? Because even today with the OAuth, I still have to, you know, log into Linear and whatnot.

• 10:51Speaker 02

  Yeah. OAuth itself is, for the most part, a very human-centric protocol. It's just, it just tells you how you obtain a token if you don't have a token. Once you have a token, actually, it doesn't matter. You just put it into the bearer token. And so we're not very prescriptive of what like agent-to-agent authentication would look like, or on behalf of agents. They are ideas that we're looking into, and I don't have all the specifics. But we are not prescriptive in the same way we're prescriptive as with OAuth. But you can technically, as a moment here, you have a token that might be like, bound to like a workload identity or something like that, then you just can pass that still to the MCP server. We're just not telling you how to obtain it just yet, and so we're not prescriptive. And so people do this, and they can do it, particularly when they're within like,

• 11:35Speaker 02

  an enterprise and have a somewhat closed ecosystem. But if the client and the server don't know each other, we just don't have a good solution for now.

• 11:41Speaker 00

  Yep. And then, yeah, on the remote thing, you went from local servers like SSC and then streamable HTTP. Any learnings you want to call out there? Any regrets or learnings for others?

• 11:53Speaker 02

  And transport. The one discussion has never stopped on the very beginning of the last years of our transport. And we literally just spent the last two days at the Google offices with a bunch of like, senior engineers from Google, Microsoft, AWS, Anthropic, OpenAI. Just like, what do we need to do here to really, really make this solid? When we looked into Mark, we wanted to get a transport going that basically retains a lot of the properties we had from standard I/O. Because you really, and I still believe this until today, that MCP should also enable agents, and agents are inherently somewhat stateful, and there's some form of like, long-term communication going between like the client and the server. And so we always looked for something like that.

• 12:38Speaker 02

  We also knew that we looked into alternatives like, okay, what happens if we do web sockets? For example, and we have found a lot of issues with doing a proper bidirectional stream. And we were like, okay, what is the right middle ground between having something that can be used in the simplest form that people do? Like where they just want to provide a tool, but then is able to be upgraded to like a full bidirectional stream. If you need it, because you really have like complex agents communicating with each other. That's where a streamable HTTP was born with that intent. And I think there are some things that in retrospect that we got right and something that we got wrong. I think we got right that we are really leaning just on standard HTTP in that regard. We got wrong that we made a lot of things optional for the clients to do.

• 13:23Speaker 02

  Um, like you can, the client can connect and open this return stream from the server, but it doesn't have to. And the reality is, is no client does it because it's optional. And so a lot of the bidiractionality goes away. And so features like elicitations and sampling are just not available to servers because they don't have that stream open. Because the client, the client implement was like, ah, that's the minimal viable project from product for me. I don't have to do it. And so that, that became an issue. So I think there are lessons there. The second part of the lessons is that the way we designed the protocol, the, the transport protocol requires some form of holding state on the server side.

• 14:03Speaker 02

  And that is fine if you have one server, but the moment you scale this horizontally across multiple pods and a like in containers or something like that. Well, now if you get like two call and then elicitation and the elicitation result, you somehow require to like, you might hit two different servers and you need to find a way to have these two servers somehow get this result together. And you in effect, effectively need some form of shared, like the Redis, Memcache, whatever you want. Like some form usually pops up or something like that. Want to, to have like a shared state that you can like have. And that's kind of okay. And like we have seen this in PHP application and Python application being done. But it's, it's not fun if you do this at scale.

• 14:46Speaker 02

  And we know from like some companies like the Googles of the world, the Microsofts of the world. They're doing MTP at a scale that I can't tell you the numbers, but it's like in the million of requests. And so now it becomes a problem, right? And so now we're sitting here like, okay, how do you build an iteration of the protocol? That allows for basically these principles of like, make it as simple as possible for simple MTP servers, but allow this full spectrum of like really bidirectional streaming if you need it, but also make it scalable. And I think we're just about to find the right solutions, but it's just complicated, yeah. Because a lot of the technology of the day is really just, there's very little like that. People either do the simple thing and then you do like something like REST,

• 15:29Speaker 02

  or you do like a full wide Istream and then you're just gonna do like web sockets or like GRPC and so on. And we need kind of both.

• 15:37Speaker 01

  What is it like to be in that kind of meeting where you have all these impressive companies? And everyone is senior and everyone has an opinion?

• 15:44Speaker 02

  It's much fun. Yeah, I got to work with some of the best engineers in the industry, like it's insane.

• 15:49Speaker 01

  Okay, well, who decides, you know, usually there's?

• 15:53Speaker 02

  We're trying to get to consensus, like the reality is technically I decide at the end of the day. But I think that's a more like a formalism. At the end of the day, what you're trying to do is just to really narrow down of like what's the, what are the real problems that we all agree on? What are the things where we not necessarily agree on? And what are the, you know, and then within those bounds, like build the best solution. And it takes a while, it takes a lot of iterations. But it's so much, honestly, it's so much fun because you get to see these unique problems from the companies. You see some of the identity of the companies in the problems themselves, right? Like, you know, Google has a different set of problems, like an like a Microsoft. And a lot of it comes from like just the ways of building things.

• 16:38Speaker 02

  And then the problem from Anthropic look different from the problem from OpenAI. But what I love about all of this is that everybody is that like, sometimes you step back and like you sit in a room with all these competitive companies, but you're actually building something together and I love that. I've been in open source for like 25 years.

• 16:55Speaker 00

  Yeah, it's very.

• 16:56Speaker 02

  I love this kind of stuff.

• 16:57Speaker 00

  Yeah, and when a standard works, this is the ideal.

• 16:59Speaker 02

  And these people are all amazing. I just learn from from all my peers so much. I'm very grateful to be in the situation.

• 17:05Speaker 00

  Yeah, this reminds me of the IETF standards process. Is there some discussion about how this works as a private group versus something more traditional?

• 17:16Speaker 02

  It's an interesting one. Like, it does look a little bit like the IETF. The IETF is very, is slightly different. The IETF is like an open forum where everybody can go. And the result of that, it's like the IETF is very consensus based. And by accident, not by like, not necessarily because they want to be, but by accident, quite slow in the processes. Which is very good in many ways.

• 17:36Speaker 00

  It cannot be undone, right?

• 17:38Speaker 02

  Right.

• 17:38Speaker 00

  Once it's, once it's up.

• 17:39Speaker 02

  Yeah, and like, for example, when you look at like the OLS two point one spec, it's been in the works for like three years or four years and they're just not done with it, right? And that's like, that's the length of which IETF standardization works. Like, these things can take a long, long time. And I think that's good for certain pieces, but I think in the I at the moment, it's just so much fast moving. It just, you're somewhat forced to find a smaller group. And so that's why we run MCP as like a really traditional open source. Um, project with like a core maintainer group of like eight people that basically decide everything. And then like input from everybody else. And we get input and people can make suggestions and we have a lot of the changes don't come from the core maintainers, but they're the ones that decided.

• 18:18Speaker 02

  And that's like way more, it's like a middle ground of being somewhat consensus based, but also somewhat like a bit of a dictatorship. Which can be good if you want to move fast, which MCP wants to do at the moment.

• 18:31Speaker 00

  How do you balance the influence of like the model improvements with how to shape the protocol? Because obviously, you know, you have Anthropic in open AI, you guys are doing post-training on these models to make them better tool calling. And you have preferences on the shape of the protocol versus there's people that are not aware of like how you're structuring that. So, yeah, do you like share some of these? Like, does the protocol influence some of the model post-training or like vice versa, maybe?

• 18:56Speaker 02

  I'm not one hundred percent familiar. Like, I'm, I'm a product person. I'm not fully familiar with everything we do on the research side for sure. But it influences the post-training in the sense that. We're making use of things like the MCP atlas that we are like having in our model card of like making sure that like we're taking this large set of tools in the wild and make sure that our models work with that. And I think the primitives of the protocol, they're actually very rarely influenced by model improvements. I think there's a sense that that we do anticipate the exponential that the models are on in terms of like improvement and that we're relying to some degree of mechanics that you can't put into into the model training.

• 19:40Speaker 02

  I'm gonna get more concrete here. So for example, people have had long conversations around context load of MCP servers. And that happens because MCP opens up the door to a lot of tools. And if you naively take all the tools, throw them into the context window, you just get a lot of load. It would be the equivalent if you take all the skills, take all the markdown files and just throw them all into the context, you would also have a lot of load. But we already knew, and I think we always knew that we that you can do something like progressive discovery. That's like a general principle thing of like you can give the model some information, let the model then decide to gain more information, right? And of course, here is where we're like, you know, some of the foresight that we see

• 20:24Speaker 02

  because we are the big model companies, we know that we can train this if we wanted to. And what the training does is just optimizes it. The model can do it in principle already, right? And any model can do it, it does any type of tool calling. But if you train the model for it, it's just better at it, right? And so these things then go hand in hand in a way. But in the end of the day, the general mechanic of progressive discovery or this progressive discovery, that's just inherent to any type of model that can do any type of tool calling in the end of the day, if that makes sense.

• 20:54Speaker 00

  Yep. Yeah, and I think the context fraud point is important. And I think down there's the MCP versus code mode thing. And then it's like, well, if Anthropic says code mode and Anthropic made MCP, maybe.

• 21:07Speaker 01

  Is that the best way? So the block was never actually called a code mode. That's the call fair term.

• 21:11Speaker 02

  That's it. But yeah, but like people call it, we call it a pre chromatic MCP and other call it code. But in the end of the day, what it boils down to is just like, okay. And here's the interesting part, like the, so first of all, MCP is a, is a protocol between the AI application and like servers, right? So the model is actually technically not involved in MCP. Um, and so now you have an application go like, I have a bunch of tools. What can I do with it? And you can do the naive thing and go like, okay, I have tools. Uh, I'll throw them into tools for the model and I, I call them. But you can be more creative with it. You can go and like, okay, models are really good at writing code. What if I take this and treat it like, it's like API calls? And you give it to the model and now the model generates, you know, code.

• 21:53Speaker 02

  And what you effectively doing is this composability that the, the model would have done anyway by like call tool A, you know, get the result, go back to inference to call will be, and then combine it into call three. Now you, all you've done is you let the model optimize it in advance and put them into a bunch of code that is just executed in a sandbox and go like, call one, put it into two, put the results into three, get a result. And all you've done is an optimization in the end of the day. Um, but the, the benefits of MCP of having authentication done for you, having, um, something that is, that is suited for the LLM, something that is automatically, that is discoverable and self documenting. These things has not gone away. That's still MCP for you, right? You're just using it at a different rate.

• 22:36Speaker 02

  So I'm always a little bit confused when people go like, but MCPs, why, why does it tell me that, that that does not, that doesn't mean MCP is used? No, it's still, it's just a different use, right? And I think you will see evolutions as we're getting better of like how we use these models and the infrastructure around it gets a bit more mature. You suddenly can assume that most model, like AI applications will have some form of like sandboxing for execution. You can do a lot more fun stuff like that, but I don't think that the value of like an, a protocol that connects the model to the outside world is, is gone because of it. That makes sense. I see it purely as an optimization, honestly, as a token optimization.

• 23:12Speaker 01

  Is this a good time to bring up skills?

• 23:15Speaker 02

  It's always.

• 23:16Speaker 01

  So awesome. So we, uh, skills is a more recent concept.

• 23:21Speaker 02

  Yeah.

• 23:22Speaker 01

  Uh, we, I only bring it up because it's mentally linked in my mind to progressive disclosure and to adding preset code scripts and all that. Uh, skills can also create skills, which is very fun.

• 23:34Speaker 02

  Yeah.

• 23:35Speaker 01

  Well, I think a lot of people are trying to place MCP versus skills. Obviously, they're not overlapping, but how do you view it?

• 23:42Speaker 02

  Yeah, I agree. I think that's the interesting part is like they're not overlapping. I think they solve different things. I think skills are super great. And, you know, they're, I think that the first that really like, they've been built from the principle with progressive discovery. But I think the mechanism of progressive discovery, that's just universal to any type of thing you can do with a model. But what skills do, they like, they give you the domain knowledge for like a specific set of tasks, like how you are, how you behave, how should the model behave as a data scientist? Or how should the model this behave as an accountant or whatever? But MCP gives you the connectivity of the actual actions that you can take with the outside world. And so I think they're somewhat orthogonal in like, in terms of like the skills really gives you this domain knowledge, just like

• 24:27Speaker 02

  kind of vertical and then like MCP gives you this horizontal of like, okay, you know, give me that one action. And of course, skills can take actions. They can take actions because you can have code and scripts in there. And that's great, but it has two interesting aspects that I think people are, the first one is you need an execution environment. So you need to, you need to

• 24:45Speaker 01

  Use a way to execute.

• 24:46Speaker 02

  Yes, and that's, that's perfectly fine for, you know, if you like run a local, like, you know, cloud code or something. Then we can talk about like CLIs, for example. In those scenarios where you have like an execution environment, these things make a lot of sense and, and then it's great. Or if you have a remote execution environment, then it makes a lot of sense, but you still don't get authentication in that regard. And so what I think MCP brings is the authentication piece. It brings the piece that you don't have to that this, like an external like person, like for example, if you have like a linear MCP server, they can improve the server. You don't have to deal with that in your skill, right? It's not fixed in space. And then the third part is that you don't necessarily need an execution environment because the execution environment is effectively somewhere else on a server.

• 25:28Speaker 02

  And so if you build a web application or a like, like a mobile application, you, these things come, you know, work better in some of these regards. So I think they are orthogonal in that regard for the most part. And they are, and I've seen some quite cool deployments where people use skills to explore of like different functions, different like, you know, the accountant, the engineer, the data scientist, and then use MCP server to connect these skills to the actual like data sources within the company. And I think that's actually a really fun model. And I think that's The closest how I think about this.

• 26:06Speaker 01

  Yeah, dude. So MCP is the connectivity layer. I think is the word that you choose.

• 26:10Speaker 02

  Communication layer.

• 26:11Speaker 01

  Communication layer. Yeah. So is it, um, architecturally, I'm wondering if it's like the MCP's client inside of each skill, or is there a shared client that can discover skills?

• 26:24Speaker 02

  We do that as shared. We do that as a shared one. I think you technically want a bit more shared ones because you do, the more shared you have, the better, the more you can do like discovery things. You can do things like, okay, I have connection pooling, I have, I can do automatic discovery of things. I can even like, you know, in a skill, you might just very loosely describe what you want and I can look into the registry that I have access to and get an MCP server for you. Right? These things can you do, can do when you do, but I think both works in the end of the day. Yeah. But this is things to experiment with.

• 26:55Speaker 01

  Uh, I do want to highlight for people who might have missed it. You said, we do blah, blah, blah. Actually, I think nobody understands enough how much Anthropic dog foods MCP. And I only understood this when I watched John Welsh do his talk.

• 27:10Speaker 02

  Yeah.

• 27:10Speaker 01

  At AIE, where he was like, yeah, we have MCP gateway. Everything goes through this.

• 27:14Speaker 02

  Yeah.

• 27:14Speaker 01

  And like, what can you say more about that?

• 27:16Speaker 02

  Yeah, I mean, like, you know, we use those, right? We use a lot of, like, we use a lot of skills internally. We use a lot of MCP servers internally because like we have, you know, obviously, you know, you want to make it very easy for people to deploy MCP. You want to like have some form of like integration with your IDPs and so on. So we have a gateway that we've built custom purpose for ourselves and you just got to like deploy your MCP servers.

• 27:36Speaker 01

  It is all internal apps?

• 27:38Speaker 02

  It's all internal stuff.

• 27:39Speaker 01

  Yeah.

• 27:39Speaker 02

  Some of them are like external things, like technically external things, but in the lack of them offering a first party one, we have our own, like we have a Slack MCP server, which I love to use, that have Claude like summarized my Slack for me. And so there's quite a lot of usage for that. Like we even have like an MCP server, we're like, we're doing like a semi biannual like survey, for example, around like how we, how we feel like about the company, about the future, about AI, about safety, these type of things. And we have an MCP server for that and I can ask Claude questions around the results, which is really fun.

• 28:11Speaker 01

  Is it your team maintaining it?

• 28:12Speaker 02

  Uh, no. We maintain a gateway, but like, I think one of the fun part is like when we started MCP, it was always like MCP before we even open sourced it, it was born out of the idea of like, I'm in a company that is growing crazy. I'm in the development side of things, development tooling side of things. I will grow slower than the rest. How can I build something that they can all build for themselves? And that's really the origin story of MCP. And so it's fun to see a year later, like that's what's actually going on. It's like people built MCP server for themselves. I probably don't even know 90% of the MCP servers at Anthropic. Because, you know, they might be in research and I might not even see them. Or I just don't know because people build for themselves.

• 28:53Speaker 01

  But do they, do they host it themselves? Is there a remote?

• 28:57Speaker 02

  They effectively have a command to launch it. And it just launches in like a Kubernetes cluster for them. So it's like partially managed.

• 29:05Speaker 01

  Yeah, that's good infra for anyone at a large company to build.

• 29:08Speaker 02

  Yeah.

• 29:09Speaker 01

  Any platform infra.

• 29:10Speaker 02

  And some, there are platforms that offer that to you. For us, from a security perspective, we want to build these ourselves.

• 29:15Speaker 01

  Yeah.

• 29:15Speaker 02

  But like they're like, and the person who built Fast MCP, Jeremiah.

• 29:21Speaker 01

  Yes, he's always.

• 29:21Speaker 02

  Company that offers like Fast MCP Cloud, which is a little bit like that. You just like two commands and you have a running instance of an MCP server. That's talk stream of HTTP. And then a lot of internal, like a lot of enterprises use things like Light L L M as a gateway. And then they can even do like just launch standard I O servers, attach them to the, to the gateway. And the gateway does all the authentication, all the hard parts of MCP for them. And so there's a lot of ways to do this. But that's good infrastructure you really want to have is just like make it trivial. Make it like one command to just launch an MCP server that was a standard I O server. And suddenly it's a stream of HTTP server with authentication integrated. And you as a developer only had to do the standard I O part.

• 30:00Speaker 01

  Yeah, I love calling that stuff out because people will take that and actually put this into their companies. So, um, yeah, otherwise also the alternative is chaos.

• 30:10Speaker 02

  Oh, yeah.

• 30:11Speaker 01

  Now you're reinventing everything. Uh, shout out to Jeremiah. I actually, I did invite him to do a workshop on Fast MCP.

• 30:17Speaker 02

  Yeah.

• 30:17Speaker 01

  At, uh, my New York Summit.

• 30:19Speaker 02

  Yeah, here, here, here recently are very great blog posts about like a lot of the usage of MCP. We're actually seeing is internal in companies. And that's actually what we see at the moment too, which is really cool. Like.

• 30:29Speaker 01

  In what companies?

• 30:30Speaker 02

  Internally in companies, in big enterprises, you see MCP everywhere. And it's, it's actually way growing way faster than you would think because it's mostly internal to companies and without people seeing it.

• 30:41Speaker 01

  About discovery, so you launched a registry.

• 30:43Speaker 02

  Yeah.

• 30:44Speaker 01

  There were registry companies, there were gateway companies. The official registry now has other registries putting their own MCP in your official registry.

• 30:54Speaker 02

  We need more registries, man.

• 30:55Speaker 01

  I mean.

• 30:56Speaker 02

  Just one more, bro, one more.

• 30:58Speaker 00

  Yeah, what's the?

• 30:59Speaker 02

  Registry to rule them all.

• 31:01Speaker 00

  Any, any learning from that, like launching a registry for like a new technology and like whether or not, you know, people like, you know, Smithery is one example, right? If you go on the official registers, like all these Smithery AI MCPs that you need to authenticate through them. So it's kind of like just a pass through registry in a way. How do you see, how is this gonna shake out?

• 31:20Speaker 02

  I think we saw a lot of these like different registries come up and we really felt that there is a need for basically like an MPM Pi Pi kind of approach to this, where like there's one more central entity that, that is the, where everybody can publish an MCP server to. And that's really where the original registry came from. And we really wanted to make sure that at least we're encouraging the ecosystem to have a common standard of what these registries can talk to. Because what we want to do, we want to live in a world where a model can auto select an MCP server from a registry, install it and then all the given task that you have at hand and then you just use it, right? It should kind of feel magic, but for that you need like some form of standardized interface.

• 32:00Speaker 02

  And so we've got to do, and that was really the, the inflection point of like, we started quite early working with the GitHub folks. Even in April, and then I got distracted with other things, like authentication and worked on that. And so what I want to see, and I think where we're slow, slowly, but this is slowly heading, is a world where and we have the official registry where everybody can put their MCP server. But this is the equivalent to an MPM, which has the exact same problems of an MPM, like everybody can put it there, basically you don't know what to trust and what not to trust. You have supply chain attacks. These are just fundamental properties of public registries. I mean, that's why we have this concept of sub registries, which then like the Smitherys and others hopefully can do,

• 32:44Speaker 02

  where they can filter and curate on top of it. And that's the, that's really the world we want to live in. I don't think we're quite there yet, but we're slowly getting there. Like the GitHub registry is, is curated after, or speaks the same format as the, as the official registry. And so what we want is like, You as a company can have an internal registry that is a curated form of the official one. Plus, maybe your own ones. I mean, that's the one you trust and it speaks the same API than the official one. And if you have like a VS code or anything else that wants to talk to a registry, you just connect it to yours and you're good to go. And that's really what we want to do.

• 33:22Speaker 00

  It's interesting because NPM in a way, it's almost like a download gateway, you know? It's like, I'm not really using NPM for discovery that often. I don't go to NPM and search for packages. It's kind of like, I find them in other ways and.

• 33:34Speaker 01

  Is this you doing?

• 33:35Speaker 00

  Yeah. Yeah, I'm interested if you see like discovery as like a core piece of like the registry or like if you still assume that like there's going to be some other way that the agent discovers.

• 33:46Speaker 02

  I do think discovery is important in the model world, but I think that that's where it's different from NPM. Because we're building like something for AI first and we can assume there's an intelligent model that knows what it wants. Um, I think that's something that didn't exist before, right? If you, maybe I don't know if you would build modern package management systems with models at heart. Maybe you would do a similar approach of just like, here's what I want to build. Just figure out, I don't care what packages you install, just do it, right? I mean, that's the equivalent in the end of the day. But again, with the public registry, you should probably not do this because it's a dumping run for everybody. You want to do it against a curated, trusted registry.

• 34:27Speaker 01

  I like your phrasing that the model knows what it wants.

• 34:30Speaker 02

  Yeah.

• 34:30Speaker 01

  Uh, because I think there's a lot of, there's a dream that agents can use the MCP directories to discover new servers, install it for itself.

• 34:38Speaker 02

  Yeah.

• 34:39Speaker 01

  That that seems like very AGI if it works.

• 34:42Speaker 02

  Yes.

• 34:42Speaker 01

  But it may not work and I wonder what needs to happen in order to do that.

• 34:46Speaker 02

  I do think we need like a good registry interface on one hand. And then the second part is just like, we need to build for this and see if it works and what.

• 34:55Speaker 01

  We need like trust levels, maybe?

• 34:56Speaker 02

  You will definitely need trust levels. You need trust levels, you might need some form of like, yeah, you need trust levels. You might need some form of signatures, for example, like one of the ideas, I'm not sure if we're going to do it. It's just a random idea, but one of the ideas I always had is like, you can attach like signatures from like different model providers that have scanned this MCP server and say, we trust this. Here's the signature from Anthropic that these tool descriptions. Are safe and here's the like the signature from OpenAI that these are trusted by us and then you can decide, oh, wow. Well, I think these

• 35:27Speaker 01

  Distributed code signing.

• 35:29Speaker 02

  It may be, and it's not just really distributed, it's just like central in a way, right? But I think this is the kind of stuff you will require. Or, but I think in the simplest form, um, what you can do, where you probably see it first is in scenarios like like internally to a company where you have inherent trust because they will use a private registry. They're effectively using private registries already for MPM, they're using for PyPI and they will also do it for MCP servers. And there you have implicit trust and then you can just search. Yeah. Right? And I think that's really the interesting ground where we wanna, where we wanna experiment and that's like, we have our internal registry effectively because when you launch like, um, via John's infrastructure, like an MCP server that gets registered, right?

• 36:13Speaker 02

  And so we, we need to go and then experiment with that too. Okay.

• 36:17Speaker 01

  I actually wanted to also ask, you, you started running some events over in London.

• 36:21Speaker 02

  Yeah.

• 36:22Speaker 01

  You had the Agents Hackathon and you had Dev Summit that you called on your timeline.

• 36:25Speaker 02

  Yeah.

• 36:25Speaker 01

  I just wanted to get anecdotal stories of stuff you learned as you, as you saw the community spring to life.

• 36:33Speaker 02

  So we had two big summits this year, we had the, the MCP Dev Summit in San Francisco.

• 36:40Speaker 01

  And the one in London too, yeah.

• 36:41Speaker 02

  And the one in London. And I think what you learn is a few things. I think that the one thing is that you, that's very hard to get otherwise is just like these stories around how people use it internally in their companies. And there you see some of the struggles, but you see also some of the success stories. And one of the interesting bits that, that, which I really loved is like particularly in London, you had a lot of financial people there because it's like clearly a financial hub and it was actually the, the whole conference was in the financial district. And learning just like the kind of problems of like, um, things you need to enforce because you have legal contracts, because like financial like regulations.

• 37:23Speaker 02

  These were things that were, that I did not know before and I learned a lot about like, okay, what does like a thing like an MCP like communication there need to look like? If you have these like constraints that in a normal like development world doesn't exist. Like I'll give you an example, like, um, if you are in, in financial services, you're exposing some data. That data might be coming from a third party. And you must guarantee that you attribute that third party. And it's a legal contract, right? You must, like, the client displays this data to you. It must tell you this came from this third party, right? And these are constraints that just like in a normal model world don't really exist, right? But like in the financial industry, this is like legally enforced.

• 38:05Speaker 02

  And so these are the things you're like, okay, how will this work in a world where we're full of MCP? And so now that's when we like started like creating this financial services interest group that Bloomberg is heading up to like figure out like, what are some of the things that you like? A client must do if it wants to speak to a financial services MCP server, for example. And, you know, what are the things that need to be respected? And I think that's the kind of things you only learn on the ground in the conferences, talking to people, right? So I think there was some of these learnings there. I think the other things that you just see is like just how many people are building and just the excitement and like the creativity that some people bring to this. Like, that I just love, right? Like, and I'm from Eric, you didn't expect, right?

• 38:49Speaker 02

  Like, I love the guys at Turkish Airlines who just built like the Turkish Airlines MCP servers. You can search for flights and stuff like that. So that was always fun. I love when like people bring some really creative parts to the MCP ecosystem. So I love these communities when they come together because you're just meeting things that are a little bit outside of your bubble. And you just get some input. And I think there's a lot of learning there. And so we're gonna repeat it again. We're gonna do it in New York in April, I think, or March or something like that. And then we're gonna do it again six months later. I absolutely love that. Any good sampling use cases that you found? Uh, not so much. Okay. Yeah, and that's always the, like, you know, last time we talked about this. Yeah. You should use it more. Sampling a little bit, man.

• 39:28Speaker 02

  Like, I think one thing I learned from sampling, like, everyone wants to use tools with sampling and tools that are not exposed via the MCP server. Like, when you want to do something, you want to have a set of new tools that you only want to use during that sample call. And we just have no ability to do it. And we just fixed it in this iteration. And so we hope to see a little bit more, bit more sampling use cases. You will find every now and then an MCP server that does it. But particularly as MCP servers have moved away from more local to be more remote, in remote cases, it's probably always better for you to bring an SDK, because you have full control, you can deploy it, you can deploy API keys, and maybe even charge someone. In a local case, where something is really powerful, because you're shipping something to a lot of people and you don't know what is there,

• 40:13Speaker 02

  what is the model that they've configured, what is the application they're plugging in, it might be VS Code, it might be Cloud Desktop, right? And in those cases, something is useful, but also like clients just don't support it. So something is one of these things, I'm like, I'm still sad about it. I still think it's a very powerful idea. But you know, you gotta, you gotta win some, you gotta lose some, you know?

• 40:30Speaker 01

  No, no, no, you're also, you know, upgrading it and, you know.

• 40:35Speaker 02

  My hopes are still up there. I'm like.

• 40:37Speaker 01

  Yeah, yeah. Like my, in, in some ways, you know, when you get it right, this will be the real agent-to-agent protocol.

• 40:44Speaker 02

  Yes, yes.

• 40:45Speaker 00

  Are most of the use cases that you see still data consumption? That's been my use case for MCP mostly.

• 40:50Speaker 02

  Yeah, it's context.

• 40:51Speaker 00

  Getting. Getting data. Well, the, the most action MCP takes is like update the linear task status. Have you seen very complex like MCP taking action workflows? Or are still people mostly using it for?

• 41:05Speaker 02

  Most people use it for context. I think that's a vast majority of usage.

• 41:08Speaker 00

  It is in the name, context.

• 41:10Speaker 02

  Yeah, yeah. And, and, and Nick Cooper from, from OpenAI always keeps telling me, rightfully so, that the name MCP was probably a little bit poorly chosen. And because it was like, it feels it restricts it a little bit, which I agree with. I, I, it's mostly data use cases. I've seen like people doing deep research. Be it, I think people expose agents via it. And so they are, they are a little bit more complex. But it's, it's not super common. It's, but people like to have experiment with it. Like they have, like the deep research use case, I think is a good one. That is very, very, that is, that's not too uncommon where people do like custom research.

• 41:47Speaker 00

  Yeah.

• 41:47Speaker 02

  On for it. But beyond that, um, yeah, I, most of it is really data. Beyond data and deep research aspects now, you have also this new aspect where people expose like UI components through MCP UI or what we're gonna call MCP I's in the future. And I think that's super, super promising and I think that's really quite fun. That's actually you see a lot now with chat GPT apps, with MCP UI in general, that you see a lot.

• 42:13Speaker 01

  Yeah, and you have the tasks in the last.

• 42:15Speaker 02

  And we have tasks.

• 42:17Speaker 01

  Yeah, well, I mean, I'm curious because like if most use cases are like context and then you build tasks, it's almost like people are not really using it for tasks. So I'm curious like how you designed it, like what you expect people to use.

• 42:27Speaker 02

  We design tasks because people come to us and go like, okay, we really want long running operation, which is basically agents. We want like a long, deep, deep research task that finishes in an hour. We want tasks that like might not finish within the day, right? And people have like awkwardly tried to do this with our tools. And you can, because tools are effectively just an RPC interface at the end of the day. But it gets very quickly awkward because now the model needs to understand, oh, I need to pull this. And it's it's just not very fun. Like, it's just not a first class primitive. And you run into a lot of limitations. But it's it's come from the fact that people want to have a long running agents. And that's like something we heard from so many areas and and people trying to do this.

• 43:09Speaker 02

  That we like, we really felt we needed to do something on a task like on GitHub issues from big companies. Everybody was like, we need, we need something that long running operation is really top of mind. So I really think now we're gonna see a lot of it now. But it's it's a little bit early to see how good it's gonna go because it just landed in the S N case and it needs to land in the clients and then we're gonna, we're gonna see more of it. But I will, I definitely, I think you will see a lot of the custom deep research parts with others.

• 43:38Speaker 01

  Yeah, I'm very bullish on tasks. I think it was very important to get right. Basically, every orchestration or protocol needs, has a sync version and an async version.

• 43:47Speaker 02

  Yeah, exactly.

• 43:48Speaker 01

  As an async version. Any like design choices that you want to call out that, you know, there were two directions and you picked one in in just the overall design of tasks?

• 43:57Speaker 02

  Uh, yeah, in design, there was a lot of conversations, like some, some were like, okay, is this just asynchronous tools? Do we do a different primitives? In the end of the day, it was important for me, my litmus test for it was always, it needs to be able to like, if I want to expose something like Claude Code or like any other like coding agent as an M C P server hypothetically, this needs to work. And a pure asynchronous tool call would just not do this. You want some form of operation that can return, for example, intermediate results in the long term. You want like, okay. I got to this result by calling this tool, this tool, this tool. I had this other input, I had this other tool, I did this. And now this is the result, right? That's really what you want to expose.

• 44:40Speaker 02

  And task is early and it doesn't do that just yet. But it's built in a way that it will be generic enough to be able to support this. That was the main constraint. The other constraint was making sure it is, it's, it's not a copy of tools. Where you can, you can think about like, okay, we just do tools again. Have slightly different semantics. But instead what it's doing is like, this like, you can create a task by calling a tool with a certain set of like metadata fields. And then it automatically creates a task. So the task itself is just the concept of like a container that can

• 45:20Speaker 01

  As a message.

• 45:20Speaker 02

  Something that's instantly, yeah. Like, just like, we do something as concurrently from starting here and to ending here. And the thing we're doing is a tool call. I mean, that opens the door to like later plug in other things and maybe even other tasks.

• 45:33Speaker 01

  Like observability as well.

• 45:34Speaker 02

  Yeah.

• 45:34Speaker 01

  Which is obviously going to be important.

• 45:36Speaker 02

  So I think that was really the design goal, which makes it a little bit more abstract, a little bit more complicated to implement, but that goes away because the SDKs just do it for you. And the SDK and then every day you're just going to like async call this.

• 45:47Speaker 01

  Yeah.

• 45:47Speaker 02

  And you return something.

• 45:49Speaker 01

  I mean, there you start to overlap with other async, like TRPC in JavaScript land or, you know, whatever Go, put above stuff that Go people have.

• 46:00Speaker 02

  Yeah. And the end of the day, it's like, it's, it's designed like a classic

• 46:04Speaker 01

  RPC.

• 46:05Speaker 02

  Operating system interface, like you create a task, you pull it until it's done. And then you can make an optimization, which we're going to do in the next round, which we didn't get around is like, okay, instead of having to pull every minute or hour or whatever you interval you choose, the server can

• 46:21Speaker 01

  Service call us events.

• 46:23Speaker 02

  Call, call your like, like a web hook or something and go like, I'm done, right? That's the optimization. But the actual core interface is always that the client can pull. And that's actually how like operating, our system operation in an operating system can work is like you pull, it has the file changed, has the file changed. But you can also use like a modern interface on the kernel, like I notify or something like that, that tell, or euring or something like that to tell you, oh, I'm done.

• 46:48Speaker 01

  Great. Yeah.

• 46:49Speaker 02

  The file has changed.

• 46:50Speaker 01

  There's a trick I I learned uh where like servers can hold the HTTP connection until it's done and then they terminate and that's the signal to to.

• 46:58Speaker 02

  Yeah, yeah, which we do not necessarily wanna do because it might take a few days and I don't know what how people.

• 47:02Speaker 01

  It's very irresponsible, but it's cool.

• 47:04Speaker 02

  Yeah, yeah, yeah. Yeah, there are plenty of ways. I think we were just gonna go the Webhook way, honestly.

• 47:09Speaker 01

  Tasks are really interesting and and we basically have to invent this uh when we did this at um did like the Devon API uh in cognition and I think that's also like uh an interesting reinvention of of like, well, everyone is going to need some kind of long-running operation and and this is, well, when you're calling an agent, you also need this.

• 47:29Speaker 02

  Yeah, but the interesting part for us, I think what what MCP is always trying to, MCP always tries to encapsulate what currently people are trying to do. And we not wanna be prescriptive what you're supposed to do in a year from now. We don't know, we don't predict. We we did tasks because people like, we need this now, right? We needed this basically six months ago and we're like, okay, I guess now it's time to do this, right? Instead of trying to do, being predictive of of the future, which is why we're trying to keep the protocol somewhat minimal and have, I think to some degree, achieved this, although other people would think already there's too many primitives in the protocol.

• 48:02Speaker 01

  One minor thing, and so let's say, let's say, super long-running tasks, uh lots of messages go back and forth. Anthropic actually was a kind of leader in context compression or uh and and compaction, maybe, let's just call it. And I think a lot of the other labs also do the same thing. Is there a way to handle that or do we just statelessly sort of cut context and it's fine? Do you need a a full log of everything that happens?

• 48:27Speaker 02

  No.

• 48:27Speaker 01

  Just as the felt, yeah, right?

• 48:28Speaker 02

  No, no, you don't. Like, I think we, I think there, this is the thing, right? We're very early in the industry still, we're learning a lot about like, what does the model need, what does not need, right? Um and even today, like, some agents start to like drop tool call results after a few rounds because they don't need it anymore. And I think that's very, very, very good. And so I think besides compaction, you will see I am just better mechanics of like, understanding what you need and what you don't need. Like, for a long asynchronous task, you might have a way where like, okay. Okay, maybe for a while the model sees it, but once you get the result, you just drop everything else. Or you might, might even call like a small model, like a Haiku model and go like, what of this I should retain?

• 49:09Speaker 02

  You tell me, right? You'd like, you might be like, the AGI approach would be just like, let the model figure out what it needs to retain, right? And so you can, you can see both worlds in them. And I think there's just lots to learn. I think there's not the one answer yet because I think we're still figuring these type of things out and we're just improving. And compaction, compaction is, is a good step for it, but I don't think it's the last step there either. It's actually the, the most obvious one, but I don't think it's like, I think if you pay more attention to it, if you particularly think about like, okay, what could you train a model to do here? I think we get to much better ways of doing that, but they're all like independent from how you obtain the context. And I think MCP I always see is like back to like, it's an application layer protocol.

• 49:51Speaker 02

  That's just how you obtain the context, how you select the context, that the problem for the application. And that's the problem all the agent applications will have in the end of the day. And there will be a lot of different techniques. A year ago, everybody have told you it's rag style stuff, but now apparently dead, right? And now we do use models, we use compaction. So I don't know what's going to happen in a year from now.

• 50:11Speaker 00

  Cool. Around MCPs, another question I had is like, how do you see them as being used by developers to build AI apps versus being a protocol? Or AI consumers to plug things in? I, I think that's one of the main things people get wrong where it's like, well, I can just use a REST API. Why do I need MCP? And to me, it's almost like, it's not really for the developers to use. It's for like people using AI tools to just plug things in.

• 50:35Speaker 02

  I get the comparison with the REST APIs quite a lot and I, I think there's interest, it's funny enough because there's two problems in general. Like the first one is REST does not tell you what to do on authentication. The second part is everybody complains to me about like tool bloat. Have you looked at like the average open API spec lengths? If you put that into a model, like you will have a lot of bloat there too, right? Actually way worse. And funny enough, when people try to like map one to one things, the often the model gets slightly confused. Because you have like search by name, search by ID, search by something, right? And like suddenly you have like five tools that look very similar to each other and the model goes like, which one? Do you want, right? I have no clue anymore. Um. So anyway, that side note to to rest versus MCP.

• 51:14Speaker 02

  But I do think MCP, I wanna live in a world where it's like very like much like a consumer focused thing, but something consumers should know about. For them, what I want is I want a world where you go to your application. You say, do this, and it should just do the thing, and it should just connect with the right services. That MCP is under the hood is a detail for that the developer needed to know about, because that's the communication channel that they're talking. But in the end of the day, you just get the tasks done, right? And I and I actually prefer a world where nobody of like my mom should not know what MCP is, right? If she wants to use cloud, right? At the end of the day. Um. But I do think it's very focused on on that pluggability

• 51:59Speaker 02

  of like an external like service and in that regard, more like on the consumer focused side. And there there's still use cases for developers in general, like first of all, as builders, but also like I still love my playwright MCP server, man.

• 52:12Speaker 00

  Yeah, well, I don't from developer uh tool, the new Chrome one is like the new right, the new meta.

• 52:18Speaker 02

  I also understand like for developers, right? Like that run like cloud code locally, you know, like things like APIs can be better approached, right? To some degree, and that's okay.

• 52:27Speaker 00

  I'm curious about the MCP apps UI with what you're talking about, where it's like every client, like ChatGPT has their own, right? So it's like if I'm used to the MCP app of this product, but then if I go in ChatGPT, there's like a different version that they curated. It's kind of like a different experience. So I'm curious how you feel about that, like, do you feel, especially now that you have OpenAI and the foundation, right? Do you feel like all of this will be MCP backed in the same structure?

• 52:54Speaker 02

  There's two influences, right? Like MCP UI existed as a project, um, which had a lot of really good ideas. Um. OpenAI took some of them and really improved upon them. And now, one thing we just announced three weeks ago on the MCP blog is that we're actually working with all all two of them together to build like a common standard. And so we're really hoping that we're getting back to the world where you build for one. Platform and you can use it across all of them. You build for.

• 53:22Speaker 01

  Right ones run everywhere.

• 53:23Speaker 02

  For chat G P T and you might be able to use it in Claude or in the goose or whatever it might be that the program of your choice that implements this. But I think the the the general problem is what we have is to think that there are certain problems like if you if you think about a modern. A I application, everything is very tech based and that's okay, it's nice. But there's things that as a human, you're just way better suited to do in in visual, right? The most basic example is like you want to like book a flight. Seat selection, right? Like you now get select like you wanna do seat selection in text. It's like here's like the twenty five seats you have available like nobody fucking wants to do that, right? Like I have no clue where these seats are even.

• 54:02Speaker 01

  Ashy based drawing.

• 54:03Speaker 02

  Yeah, of course, you want an application that you can select with, or it might be like a theater that you wanna book for or something like that. It's so obvious that you do want to have some form of like an application and a user interface. That the model can navigate and the model can um interact with, but you as a human can also interact at the same time. And I think that's what we're looking for. And so I think it's just a snack situation of like building richer interfaces. Because the pure text interface is just somewhat limited and there's very natural things and you like you see this in music production, you will see it of course, or. You will have like certain brands that will deeply care about presenting their interface. Shopping is a good example, man, like um like shopping has like twenty years of like.

• 54:45Speaker 02

  A B testing, what's the best way to sell you something, right? And so and and shopping interfaces are super complicated, actually. Um and you just want a way for for displaying that to the users that it's familiar to them and that they they can interact with it. And that's what M C P apps is in the end of the day.

• 55:00Speaker 01

  Yeah, and technical direction wise, is the I frame the the way they were.

• 55:04Speaker 02

  Yeah, it's an I frame. It's it's um you are serving basically raw H T M L over um uh over an M C P resource. It goes into an I frame and then it talks to the outside where um post messages over a specific interface. And so what you can do now, you can, because it's raw H T M L and you're not really like loading some external content. You're gonna get uh you can analyze it in advance if you wanted to with security and because you have. I frame you can like the external application like can just speak like a very clear bonded or like security bonded.

• 55:36Speaker 01

  Yeah, and this this has been in browsers forever. I think the the I'm scared of it only because I hate cores issues.

• 55:43Speaker 02

  Yeah.

• 55:44Speaker 01

  And I frames always have course issues.

• 55:45Speaker 02

  Yeah, but this again, this does not load X anything external like it surely like it should not, right? Like there probably are restrictions that we like then iterate and iterate and then in five years, maybe it has not twenty five course headers and whatnot, whatever, right? But um but I think we were starting small again was like pure raw HTML. You should probably not have external references. We don't run through these issues, but you're right.

• 56:08Speaker 01

  And can I inherit styles?

• 56:10Speaker 02

  Uh.

• 56:11Speaker 01

  No, because I frame.

• 56:13Speaker 02

  Yeah, I think you need to put it in in line.

• 56:15Speaker 01

  Yeah, obviously, like you will want it. And then I feel like this is really minor, but UI people care about this.

• 56:21Speaker 02

  Yeah.

• 56:21Speaker 01

  Which is you have it. It should look like chat G P T.

• 56:24Speaker 02

  Yeah.

• 56:24Speaker 01

  Me inside of chat G P T should like cloud and say cloud.

• 56:27Speaker 02

  I think that's a very good question. I'm a hundred percent agree with you, like brands and all this will deeply, deeply care about it.

• 56:32Speaker 01

  Designers.

• 56:32Speaker 02

  Oh, one hundred percent, one hundred percent, yes. And that's something we need to figure out. And that's where you need to get it out of the door and see how people use it and then iterate on it.

• 56:40Speaker 01

  That's that's why I don't think it should be I frame long term. I don't I don't know what I don't know what the solution is.

• 56:44Speaker 02

  Okay.

• 56:45Speaker 01

  But like we need like new I frame that.

• 56:47Speaker 02

  Yeah.

• 56:47Speaker 01

  Let's some permeability because of this stuff.

• 56:50Speaker 02

  Well, I think I think that's sensible. Yes.

• 56:52Speaker 01

  Um, well.

• 56:52Speaker 02

  But the other solution to the problem is the I G I thought approach of I just give it a tool that says, give me a style sheet. And.

• 56:59Speaker 01

  Well, so okay.

• 57:00Speaker 02

  If you can call you and tell you what you're supposed to look like.

• 57:03Speaker 01

  Okay, should an M C P app be know what it's being used with the parent application is is, you know what I mean? Like.

• 57:11Speaker 02

  It it might be like the the the application often exposes tools, right? That the model is free to call it.

• 57:16Speaker 01

  Right, right, right. Okay, so maybe standard as interface for people to pass down styles.

• 57:20Speaker 02

  Maybe, yeah, maybe. I don't know, but it's a it's a very good question. Let me let me ask the team. I'm just like, I'm most of like directionally there. I'm like not in the in the weeds of doing everything there.

• 57:28Speaker 01

  Yeah, it it it seems like a little bit of a surprise to me. I I never really paid any attention to M C P U I. And then suddenly. You guys all adopted it. I was like, okay, well, I guess this is a part of M C P now.

• 57:39Speaker 02

  Yeah.

• 57:40Speaker 01

  And it went from a purely back end concern to now.

• 57:43Speaker 02

  Yeah.

• 57:43Speaker 01

  Front end.

• 57:44Speaker 02

  It's also like notable is technically an extension to M C P, like it's not M C P, M C P. Um, that's a pure technicality because.

• 57:51Speaker 01

  It's a governance thing, right?

• 57:53Speaker 02

  Yeah, it's mostly like. If you are a client that can render HTML, then you might wanna consider implementing it, but you're still an MCP client if you don't. And the reality is, is like, your average CLI agent can't do it, right? So they will never do it. And so I think that's fine. Are there any other extensions that are similar? We're gonna look into like financial services as an extension where like, okay, you might, you might end up in a world where a year from now, there might be clients that have like certifications that they are an MCP and get like a signature that they are like financial services MCP clients. And they can prove it with a server and only then the server allows connections because it knows they are respecting attributions, these daily contracts that you put into place.

• 58:37Speaker 02

  And you will see this everywhere. You will, if you wanna deal in the long run with a public service and public clients that do like deal with HIPAA data, like healthcare data, you will have to have guarantees. Isn't it part of just auth or off? Eh, not necessarily. Like, I give you an example, like, if I have, the client might need to have have five servers installed. And if there's one healthcare server, that healthcare server might tell you, you are not allowed in this session to use any of the other MCP servers because this data I'm giving you cannot leave you, right? You must guarantee that this data doesn't go anywhere else because it's HIPAA data, because it's financial data, whatever it might be. This is a good example, and that might be some of the enforcements you need to do.

• 59:21Speaker 02

  Because you're just like, you don't want to have your, or your social security number or your healthcare data show up in your back accident, right?

• 59:29Speaker 00

  Awesome. We're gonna transition and have the rest of the AAIF group join, but any final call to action, like either, you know, people that should join your team, people that should contribute to the MCP spec or anything else?

• 59:44Speaker 02

  I think the most important part is still building with MCP on a day-to-day basis for people to just go out, build really good MCP servers. I think we see a lot of mediocre MCP servers and I mean, some very, very good ones. And just building good MCP servers, looking at like how to use them. I think that's super important. The second aspect to that is like, we're fully open. Community and we're running it as a as a traditional open source project that is based purely on like what people are able to put in in terms of a terms of effort and time. And so just like being an active part like either giving us feedback, being in the Discord channel, talking with us, giving us ideas, while also just helping us implementing like the types of SDKs, the Python SDKs, you're always looking for new SDKs, right? Like we have active Go SDK development, but like we don't have a Haskell SDK.

• 1:00:29Speaker 02

  I don't know if you're a Haskell developer, maybe you want to write that, right? Yeah, there you go. And so I think there's a bunch of stuff we can do and and be part of it. And I think, um, I don't understand how much you can just be part of the community, but also just like, uh, go and build. Um, and I think there's so much opportunity now, particularly to build like amazing clients now that we have understood aggressive discovery better, now that we have understood code mode better. There's just this next iteration of clients to build and the next iteration of service to build that I'm just looking forward for people to do.

• 1:00:58Speaker 01

  Yeah. Um, my, my last question or call out is, uh, I wanted people to hear directly from you. I sense the energy. I'm very, uh, excited by everything that you're doing. But a lot of people are anxious about joining MCP, joining the Linux Foundation. They're like, oh, is this Anthropic taking his eye off the ball? Can you address those concerns?

• 1:01:17Speaker 02

  Yeah, I love that you asked me that. Like, I think, yeah, I can totally see why people think that, but like, it's actually quite the opposite. Like, the commitment of Anthropic is the same, right? I'm still, we still have the same people I'm helping with the SDKs. We're still super committed in our products to MCP. I'm still the lead core maintainer. Nothing has actually changed. What really is the main part of the foundation is like two things. The number one is like making sure that the whole industry knows that this will stay forever open, that this cannot be taken away. And there have been, there have been like, Anthropic would never do this, I think, but there have been histories of like companies going like taking an open source project and suddenly making it proprietary again. We have protocols that are proprietary. Look at HDMI. Look at like, what's the problems of HDMI in Linux?

• 1:02:01Speaker 01

  Wait, what's what's on HDMI?

• 1:02:03Speaker 02

  Uh, HDMI 2.1, HDMI Forum does not want to allow.

• 1:02:09Speaker 02

  The aim to develop open source Linux drivers for HDMI 2.1, really, there's some, look it up.

• 1:02:15Speaker 01

  Wow.

• 1:02:16Speaker 02

  Um, so you know, there's people like keep a very close tap on it. And what this does is like, no, this is now owned by a neutral entity. It will always stay open. You can use the, the, the word MCP. Nobody's going to sue you over it. So there's a bunch of, they're just giving the ecosystem and the industry that confidence that this stays neutral. I think that's important. The second part to that is that I think one thing I'm, if anything, I'm the most proud of is that I think we have set the, the tone for open standards in the, in the industry. And being able to now use that momentum to build like community in a space where people can come and bring really well done, well supported, well maintained

• 1:03:02Speaker 02

  of projects and have, and have them part of this foundation. I think that's the, that's the other part to that. But the funny part is like our bar for the, for the foundation is going to be like, it needs to be like really well maintained. It's not like you getting, you're taking the ball off. It's actually exactly that what we don't want. And so we will not do that for us. MCP is still core to the product and still super important, anthropic. And so, um, we're still just as much as committed as we've ever been.

• 1:03:28Speaker 01

  Amazing. Awesome. Thanks for joining there. And we're here in the studio with core team members of AAF. It's, it's, it's the biggest panel we've ever had on, on the podcast. So welcome guys. Maybe we'll go left to right and introduce everyone and also identify the voices for people listening on audio.

• 1:03:43Speaker 03

  Uh, I'll start, I'm Jim Zemlin, uh, the CEO of the Linux Foundation. Uh, been working there 22 years and, uh, I was the person who helped facilitate the launch of the, uh, foundation. Uh, but take no credit for any of the technology work that, that's to my, my left.

• 1:04:01Speaker 04

  I'm Nick Cooper from OpenAI. I've been there just over two years now, I think. Uh, I'm generally OpenAI is like head of a lot of protocol things and very interested in the open ecosystem and our representative for AAF as well as a core contributor to MCP.

• 1:04:16Speaker 01

  Got it. What, what's another protocol that might fall on the net umbrella?

• 1:04:20Speaker 04

  Uh, agents and D, just in general, like not just the protocols, but also the product experiences of where OpenAI products intersect with other SaaS provider things and other systems.

• 1:04:30Speaker 02

  I'm David Zorriapara. I am working at Anthropic, member of technical staff there. I'm the co-creator of MCP. And yeah, Anthropic can mostly lead all the MCP efforts.

• 1:04:43Speaker 05

  Great, and I'm Brad. I'm the principal engineer at Block. So by day, I build AI products and by night, I work on open source like Goose and the original author of Goose.

• 1:04:53Speaker 00

  It's great to see everybody come together. Then when I heard about the news, I didn't really expect it. It wasn't on my bingo card. So maybe let's have a little bit of inside baseball. So you obviously have open end Anthropic. And yesterday at the launch event, you were joking on how you didn't know that the two companies even talk to each other. And then, yeah, how did the conversation start?

• 1:05:13Speaker 02

  The conversation started off two things. The first one is that on the MCP side, we always knew that we wanted to find a neutral home for MCP to make sure that the industry understands that this stays open, that this is something safe to adopt. And then very early in the process, as we were looking around like what to do about this? Should this be a project in a foundation? Should this be inside its own foundation? Which is like these common patterns you see for this kind of work. And we got approached by our friends at Block to discuss, because they were looking into like donating Goose, I think, at the time. And so there was a question around doing something together.

• 1:05:56Speaker 02

  And then we approached OpenAI and they were very, very welcoming and like very open to the idea as well. And then it slowly like formed. And I think, you know, the timeframe of this is like a few months. These things are not happening out of thin air in like a week or so. And so just a lot of conversation, like what do we want to do? What are the kind of like constraints we want to have? And what is the thing we want to build? And of course, we were looking for where to put this kind of stuff. And that's where the Linux Foundation comes in as, I think, the biggest foundation of its kind. And certainly has like decades of experience helping companies through a process like this. And building what is technically called a directed fund within the Linux Foundation to build these kind of things out.

• 1:06:42Speaker 04

  I think David said basically all the story from my side as well, which is um. So we saw this like need to connect systems and then MCP gained such very large developer traction. And we had open eye, we were very excited to like use and then contributed and actively participate in this. And from my point of view, it was always very natural that this would grow into something bigger and move to a neutral place. And like MCP has always been like a foundation for like communication between agents and context. In a similar way, the Agentic Foundation is, well, it's a foundation, but also it's like the starting point where I really look forward to other contributions.

• 1:07:20Speaker 04

  Like starting with Goose, our own Agents MD, where we're really open for like a lot of technical contributions to build out like a full agentic ecosystem.

• 1:07:29Speaker 00

  I'm curious, Jim, uh, you know, I've been to Linux Foundation events before I've spoken to them. It's it's almost like, isn't MCP so early that like, how do you even structure it in a way? I'm curious because so many of the technologies that the foundation supports are kind of like core pillars of infrastructure in the internet. This is probably like the youngest technology that you brought in as a foundation. What are the goals of it?

• 1:07:51Speaker 03

  Yeah, I mean, I, I think what's interesting here is even though it's young, I think if you. I think AI years are kind of like dog years.

• 1:08:02Speaker 04

  Absolutely.

• 1:08:03Speaker 03

  It it do you, do you use this metaphor, but.

• 1:08:06Speaker 04

  Yeah, totally. This is why I run three conferences a year.

• 1:08:08Speaker 03

  Yeah, exactly.

• 1:08:09Speaker 04

  You can't do annual.

• 1:08:10Speaker 03

  I think last night someone was asking, what do you, what do you see a year from now? And I'm like, well, if I dial the clock back a year, would I have, I anticipated where we're at right now, there's no way. And so I think part of the thing with MCP is that we're just living in this kind of dog years velocity. Uh, in the past, I think things took a lot more time to coalesce. And what is clear is that a lot of people are adopting MCP. See it in commercial products that companies are rolling out. You see a lot of usage in the enterprise already. And there still is a ways to go in terms of the technology becoming mature. But I think the, the same thing held in internet protocols, you know, that took a little bit longer to mature and the internet matured over time.

• 1:08:55Speaker 03

  But I think the thing I'm most excited about, it's becoming clear that MCP will be a key protocol. This technology movement. And I think, you know, David and these folks were all pretty wise to realize that, you know, if internet protocols had been owned by a single entity, he'd still be calling it American online, America online. It like, you know, it would be, it wouldn't work. And I think that this has got all of the underpinnings to be a huge movement. And at the Linux Foundation, we ask three questions for every project. Will this be meaningful and impactful for industry and society? The second question is, do you need more than one organization to collaborate to do it?

• 1:09:40Speaker 03

  Otherwise, you don't need us. It's case clearly we got that. And three, can we get the resources and build an ecosystem around it? And 50 companies on day one, you know, a huge set of folks in line to participate. In my L inbox, I'm sure your guys are too, is like full in 24 hours. How do I participate? We want to contribute. How do I get in there? I've never seen that kind of inbound interest, starting any project at the Linux Foundation in 22 years.

• 1:10:13Speaker 04

  How do you pick? You got all these people reaching out, you know, there's good and bad. It's a really good question. I think it's like how to pick, how we expand the foundation itself from a governance standpoint, but also like technical contributions and how can the foundation best support them as well? That's like really top of my mind. It's like the first thing we need to like define some structure and work out what we like, how to bring it all together. But I think even before like those details, there's such value in establishing this one forum that people can come to. Like even having a list of eager technical participants and potential opportunities. That's a huge opportunity in front of us to like distill what's truly meaningful to developers, users and everyone.

• 1:10:57Speaker 04

  And very appreciable Linux Foundation reacting as like sort of a galvanizing rod for this like attention.

• 1:11:03Speaker 01

  Brad, on the sort of block and goose side, it's an interesting, the involvement that you guys have had in the sort of engagement that you guys have had. What was your calculus in joining the AIF?

• 1:11:15Speaker 05

  So for us, I think it's like in developing something like Goose, I think the thing that I see it as being part of this umbrella is it's the most concrete piece. So you can actually like download Goose and use it in a way that you

• 1:11:30Speaker 01

  I can download an AGSMD.

• 1:11:32Speaker 05

  Right, right, right. Like, what do those parts do together without having something that actually like connects it to clients? Yeah, exactly. Like a real client. And there's, I think, a lot of value in that because when you get into the protocol space, you want to add things to it, but you have to actually show like what it's enabling. Like, why are you making the protocol wider? And putting it into like a reference implementation shows you like, oh, it's giving this value to people, like very concretely. And I think there's some, like, for example, there's like a spec for MCP, MCP apps that is brand new. And we've been working on MCP UI.

• 1:12:07Speaker 02

  For Goose?

• 1:12:08Speaker 05

  Yeah. So Goose has been like kind of a day one partner with the MCP UI team.

• 1:12:12Speaker 02

  Oh, I didn't know that.

• 1:12:13Speaker 05

  And so now we've had MCP apps, we'll go, we have opened an issue today about how we're going to go get that into Goose. And so that's something where I'm, people, I think, you hear something abstract like that. Like, what is send, what is the server sending an iframe to the client like do? And I think Goose is a place where you can see it, like, okay, you're going to build a dashboard or you're going to have this enhanced chat experience. And so this is something where I think we collaborate more and more to say like, this is what it looks like and how you look at some of these abstract things and make them real.

• 1:12:41Speaker 02

  Yeah, I think the other tidbit here, maybe like back to the history of both MCP and Goose is like, Goose was the first open source agent interface or agent that reached out to us and worked with us to integrate MCP. And I think Brad is actually like technically the first non-anthropic contributor to MCP ever, unlike Bay2 or something like that, like very, very early. So this goes all the way back to like November last year to like the partnership of having MCP inside Goose.

• 1:13:12Speaker 05

  Yeah, we had, we had a version of Goose that was still, you can go check the GitHub history. It was there a little bit before MCP came out and we were sitting there with like a plugin ecosystem who were like, this is awful. Like what, like, why would you, why would anyone want to write? Yeah, why would anyone come develop a plugin just for Goose? But we saw all these opportunities and so we started talking to Anthropic and we were like, I think that there's a space here for a protocol. And they're like, well, let me tell you about, uh, and it was really cool to see you know what this is. I, no, no, no, we didn't. We reached out before we heard the ZET thing. And so we were like, okay, like, yes, we just want to like, we want to pile onto something that has a chance of succeeding because as like a client, it's like an ecosystem, right?

• 1:13:54Speaker 05

  Like the more people are here using it, you get more value as a client than as a server. Because you know, your servers are going to work with any client. And then as a client, you know, you have this like giant library of servers. And so that's been like a big part of what Goose does is that it's not really like, it is a coding tool. People use it as a coding tool, but you can turn off the code part and you can just connect to any MCP server. And so it can be like operating like, uh, you know, a science experiment. I've seen that or like just like Google Docs or whatever. And I think that it kind of shows you how MCP goes beyond just like the back coding space.

• 1:14:27Speaker 04

  Yeah, I think as well, it's also the fact that it's concrete is so important. Like for all these standards, like there's a long history of standards throughout computing that like people like proactively write a standard. And then when, you know, the, and it's actually tried out, it has problems.

• 1:14:44Speaker 05

  Yeah.

• 1:14:45Speaker 04

  But like for MCP and like all these new agentic standards we're coming with, we really want demonstrated utility. Like what the most common thing on the call committee is like, is a proposal. And we come back to people saying like, have you tried it out? Does it work? But the protocol is about communication. So if you're trying something out, you need collaborators and you need like concrete open source projects like Goose and you need clients, you need a variety of servers. Cause it's only with that sort of open ecosystem that you can meaningfully understand if this is actually going to work.

• 1:15:17Speaker 03

  I totally agree with that. I mean, I think the world of standards and open source development are dismerging, right? You sort of co-develop these things together. Um, I think I was trying to figure out whether David is Vent Surf or, uh, Linus Torvalds for agents. And I think maybe it's a little more, it leans a little more Vent Surf and then maybe Ghost is a little more Apache web server and my whole Linus part kind of falls apart at that point. Uh, but you do need something substantive to try the protocols out in order to make sure you know how to improve them. That's that feedback loop that's so critical.

• 1:15:56Speaker 01

  OpenAI also has a coding agent that is open source. I, I think what's the thinking there apart, apart from like, well, would Codex ever be donated to AIF? Or we just don't know yet.

• 1:16:09Speaker 04

  I think the short answer is we don't know yet, but like, it's sort of like a feedback loop, which is um, in this open ecosystem, like, we don't want to have too much alignment all on like one implementation, one thing. There's like real value to users and developers or whoever's the participant to like active competition in some parts. So there's this balance of like, we need openness to foster like collaboration and experimentation. But like, I would like to see a variety of coding agents and each one might deliver unique value, different value and be free to explore independently. So it is sort of like a careful balance here. There's a bit of like a tastemaking approach to like contribute things that benefit from being open.

• 1:16:54Speaker 04

  Like Agents MD is an example, which is open up any GitHub repository. It has this file. It works the same way. Like if everyone sort of did their own thing there, that's very low value, potentially damaging to the way. But um, so there's commonality value, whereas for actual concrete implementations and projects, it's great to have reference implementations in many ways or experimental grounds like Goose. But I really favor a huge variety of them because that way we'll see what comes to be the best.

• 1:17:24Speaker 00

  Is there a roadmap for what you want to add? For example, the agenda commerce protocol, like ChatGPT already uses, but that's not a part of it. There's no model as a part of the foundation. Um, do you already have a roadmap or like you said, you're just kind of like going month by month, seeing what are people using and what should be in there?

• 1:17:42Speaker 02

  I think we don't have a roadmap in the sense of like projects lined up. But I think what we have is principles by which we will select products to some degree. And I think the effort here is mostly around sitting together after the now that the foundation is created and then evolving these principles as we're seeing people going to ask us about the projects they would want to put in. And then if develop the the foundation further as time goes. But at the moment, I think the most important part is that we have the principles in place. And then you go and having the conversations with people who who want to be part of this foundation.

• 1:18:23Speaker 04

  One principle that like really comes to mind to me is composability. Like I often use the analogy of like Lego blocks sort of thing, which is agentic systems are a sum of many, many parks. And so like something that I hope the foundation can evolve to do is have these like interoperable composable bits that all work together binkly. And so we don't have a roadmap of like future contributions. But like I welcome all contributions that play nice with other contributions and like really create this potentially like a future flexible, open agentic stack to be like not a universal agent, but an agent that suits everyone's purpose or need.

• 1:19:04Speaker 03

  Yeah, it it's tricky. You got it. It's a hard and and these guys have the harder job of early in innovation cycle. You don't want to restrict innovation by saying like, oh, well, this is the one, you know, versus that one. But you also don't want to let every single random thing, you know, into an organization like this. And so I do think you need this tastemaking is a good way to describe it where a group of, you know, elite architects and developers, you know, folks like the three people sitting next to me are more curating. And, you know, some some things can work, some things might not, but there needs to

• 1:19:44Speaker 03

  be a process, which I think will define to do that that curation that happens via tastemakers. And it's more of a Not just more, but essentially a technical effort, not something where a committee of, you know, folks from vendors get together and say, well, my product should be in this roadmap and that guy's product should be in this roadmap. It tends to not be very successful.

• 1:20:10Speaker 02

  Yeah, we should lead to this other principle that we really want projects that are, have a lot of traction, that are well maintained, that have, that are very, very healthy in the foundation. I think that's super important to us.

• 1:20:23Speaker 05

  Right. I think like, you're looking for something to have already found a niche and to be established because you don't really want to be pushing like a speculative architecture. You really want to be embracing something that already works. And so I think a lot of the stuff that we're talking about, like payments or like kind of, I really enjoy the like, interface to model architectures. I think those are really interesting, but it's not yet obvious that that pattern needs to exist. And so that's something where we can go see it and like try to make it work in some projects and then come bring that back if it really has a role.

• 1:20:58Speaker 00

  And on the opposite, what's my incentive to bring my project? I have a project with adoption, it's well maintained, it's healthy. What's the benefit that I get from donating to the foundation?

• 1:21:12Speaker 03

  I mean, I could start that, but I'd love to hear from these guys as well. I think what you, all technology is an implicit futures contract, right? And so, you know, if there's technology that has traction and that traction sort of wants to be built upon, having that technology at a neutral place like the Agentic AI Foundation, where the whole industry is making decisions about how to invest. And when I mean, when I say investment, I don't mean like becoming a member of the foundation, because you don't need to become a member to participate on the technical side. It's decisions about, hey, I'm gonna, you know,

• 1:21:51Speaker 03

  assign 10 of my company's engineers to co-develop this with your organization, the contributing organization. And, you know, that's a way that we can all essentially co-develop together and that will provide. Better support, more development velocity, higher code quality because more people are participating in it. And that's a massive incentive if you want your technology to actually be used and adopted in industry and get more feedback and kind of a positive feedback loop of great project that gets great products in the market. That market feedback then allows companies to make money off of them. They then pay engineers to improve

• 1:22:33Speaker 03

  the project, better products, more profits, better project. And that's the incentive, which is a pretty high one.

• 1:22:42Speaker 04

  Co- without a technical sort of spin, which is none of these things are built in a vacuum. Like, all these projects build on lessons and learnings or practical code from other projects. And that's a big opportunity. Like, any technical contribution will bring its own unique value to the foundation. At the same time, it then gets to learn the lessons that all the other participants in the foundation do. And I found it really valuable over this past year, working with David and others on the MCP committee about, is actually that communication thing that makes our ideas more robust, makes the implementation better, we can be sure it's secure and safe and actually works. This requires communication.

• 1:23:24Speaker 04

  And that's sort of, the foundation is the natural town square for this in a way.

• 1:23:29Speaker 05

  So, one last angle on this. I think if you're working on a standard or a protocol, this is such an obvious decision, right? Like, the value in the protocol is about how many people are adopting it. So, being a part of this gets you that reach. But I will say, as someone who's working on a client and not a protocol, I think there's value there too, right? Like, we want this to be part of the foundation because we develop these ideas together, to your point. And so, it makes it better. Like, we're donating Goose because we think it's going to make it a higher quality tool.

• 1:23:58Speaker 01

  I actually have a follow-up question on just the LF side. LF has many other funds and organizations, including the AI Foundation, as well as dedicated PyTorch and all the other ones. I guess, why a new foundation?

• 1:24:14Speaker 03

  Well, because everyone's special.

• 1:24:18Speaker 03

  No, I think that the way we look at in this space, you know, I'll put aside the projects in semiconductor tech and operating system and stuff, but in AI, we think of it sort of like how the market has evolved, you know, it started with tools like PyTorch and, you know, that transformer tech that is used to create LLMs. The Linux Foundation kind of took a pass on like frontier model world because in the open source space, having connection to the internet and some intelligence and a computer, that's sort of entry in the world of frontier LLMs. It's a computer connection to the internet, some intelligence, $2 billion with GPUs and

• 1:25:02Speaker 03

  a ton of data, harder for consortiums to do that kind of work. So pass. Then you look at how, you know, reasoning models have come out, need to be, you know, in inference world, things need to be scalable. Okay, now you've got interesting technology, VLLM, Ray, things like that, they have to be deployed on something, Kubernetes is sort of that. These are all distinct components. Agents are a distinct enough set of technology that it merits its own community. Separate from D and AI. Yeah, because like a PyTorch dev isn't really doing a ton of stuff in agent land, right? You know, somebody working on Dockling maybe is a little more adjacent, right?

• 1:25:46Speaker 03

  But not quite the same as somebody who's like working on transformer tech or VLLM. And so they are logical categories. I mean, sometimes stuff comes in over time and, you know, we sort things out later. We had early on in the telecommunications sector, you know, a software defined networking effort, a network function virtualization orchestration effort, a whole bunch of stuff, all separate entities. And there I was like, let's just bring all these things together because the technology's now mature. We're taking all this money in, but we don't really need the resources anymore because the market's already mature.

• 1:26:26Speaker 03

  And so it took me a year to get all these companies to decide to bring all these things together and not pay all these separate fees and have all these separate orgs. I have a little folder in my inbox that says, you know, convincing people not to give me money. But in this world, I think it's a different kind of audience. I think it's narrow enough. I think it's specific enough to agents where it merits its own entity.

• 1:26:50Speaker 04

  I think as well, it dovetails somewhat with the earlier thought, like with the taste-making aspect to this. For these organizations to be effective, they really need a focus, like something that brings them together.

• 1:27:00Speaker 03

  Motors.

• 1:27:01Speaker 04

  And ultimately, like you can imagine an alternative where we snowball and there's only the Linux Foundation. There's this Uber do everything remotely connected to a computer. And that wouldn't be that effective. So there's a taste-making here as well, which is going to be focused on the Agentic systems and how they connect together. Hence the Gentic AI Foundation. But like, everything's about growth and evolution. So there's a possibility that later down the line, we recognize some natural affinity. There's something new, something old, and then they can be brought together. But the focus helps at the beginning, certainly.

• 1:27:35Speaker 00

  What's gonna be the actionable outcomes? So obviously you have the funds to direct. I know a lot of the Linux Foundation does events. There's also like eventually like certification, things like that.

• 1:27:45Speaker 03

  Yeah.

• 1:27:46Speaker 00

  What's the split of the foundation investments? Is a lot of it going back to different projects individually? Is it about the community building? And then from people that have not been involved from the outside, it's like, this just seems like a nice blog post and a bunch of logos. But like, in reality, how are things gonna be actioned?

• 1:28:05Speaker 03

  Yeah, I mean, 50 companies coming into fund a bunch of blog posts seems like overkill.

• 1:28:09Speaker 00

  Right, exactly.

• 1:28:11Speaker 03

  So I think there's a couple of things. One, The intellectual property assets now are owned by this entity. That entity is responsible for making sure that, you know, that IP is managed effectively, that licenses are complied with, that intellectual property problems are dealt with. Some funding goes to that. There's a leadership function where, you know, to help bring consensus across the industry and within developer communities, you have to have a special kind of someone to do that. And I think they need to be technically knowledgeable, but humble enough to know that they're, that the community is the one who makes the technical decisions. So kind of just, you know, sort of lead through influence to kind of help people organize

• 1:28:56Speaker 03

  things effectively. So you hire some people to do that. You hire people to do like developer outreach, community engagement, because you want more developers coming into the community. So funding to go to that. And then there's a huge convening function. The Linux Foundation hosts 50,000 plus virtual meetings a year. So we have this like, I think we're probably like one of the largest users of Zoom. I know for sure we're the largest Slack user in the world. And so that convening function is critically important. Make it as seamless and easy as possible to convene. And then, yeah, we hold events because I think, you know, to your point, developer

• 1:29:40Speaker 03

  engagement, face to face, being the town square where you physically get together means something. So I think you guys have been to CoopCon, you know, we have easily 10,000 people that come to that conference twice a year. In Europe this summer, there were 13,000 folks there who, you know, come in and they exchange ideas, the core maintainers get together and make real decisions. And then the last thing we spend resources on, and you can go even just check these out for some of our other projects, is we have a whole platform. That enables, you know, maintainers to look at their community and understand, you know, like, what's our velocity? How many developers are we adding? Like, what's the

• 1:30:22Speaker 03

  social media scuttlebutt around this project? What are leading indicators of adoption? How's our security doing? Like, you know, do we have good practices about application security? And those are all things that we, you know, invest in to help make these communities, you know, better commercially adopted, so that we get that positive feedback loop of like, adoption that gets more investment in the form of developers providing input and that that virtuous cycle kicks off. That's where the funding goes for these kind of things.

• 1:30:54Speaker 00

  I put in that question into our doc because it says it's a directed fund. So my cheeky question was, well, what are you directing them to?

• 1:31:01Speaker 03

  So yeah, I mean, it's kind of, so directed fund gets into like the nerdiness of this. Yeah. So but it's the reason we structure it that way is somebody has to own everything. The Linux Foundation is actually the ownership vehicle. And remember, we separate technical governance from the governance of actually how money gets spent, because we don't want this sort of pay to play aspect of technology that tends to screw everything up. And so the directed fund is really like, you know, real stakeholders who really care about this tech, put money in and use it in a way to help build the market and the community and all the things I just talked about, and just let developers do what they're super good

• 1:31:44Speaker 03

  at, get together, solve tough problems, be, you know, tastemakers. That's something that we separate.

• 1:31:51Speaker 00

  Yeah, I think there's a great essay by Rich Hagee, who created Closure, about open source is not about you. Just because something in open source, I don't know to respond to your issue into progress. And I think some of the worries sometimes that people have about the groups is like, well, you know, If not, you're a part of this thing. I'm supposed to also listen to your thing and implement the thing that you said. So I think that's gonna be a super interesting thing in a technology that is so new. You know, I feel like everybody, because there's so much venture money in like early stage companies and like, obviously, the foundation model labs have raised so much money that they need to be on top of it. There's a lot more pressure, I think, from the community to try and be a part of it and like put their stake and be like, yeah, we've contributed that or whatnot.

• 1:32:33Speaker 00

  So I just think it's like a unique compared to like the C N C F, for example, where the hyperscalers are kind of like around the clouds and we all know what those workloads look like and like, nobody's really trying to influence. There's not like a OpenAI preferred thing versus like an Anthropic preferred thing.

• 1:32:50Speaker 03

  But it wasn't, it wasn't always so. So when we started C N C F, I got a call from, I think it was Urs Holsel and Brian Stevens, who were over at Google. It was 2014, I want to say. And, uh, you know, they're competing. Well, they had, they weren't even competing. They weren't in the cloud business and they wanted to be in that business. Amazon was, you know, hosting virtual machines on EC2 and they were the de facto leader. They said, we will give away Kubernetes, which was kind of the Borg and they renamed Kubernetes to the Linux Foundation. And we, you know, because we've never run a virtual machine, we think containers are a better way to scale cloud applications. We'll give you this tech and it'll be helpful to us if the entire industry adopts containers and Kubernetes

• 1:33:35Speaker 03

  as the way to build and deploy applications. So that was the strategy out of Google. And they contributed some serious IP that we all know today is awesome. But at the time, remember, Mesos was still a thing. Like PaaS was still a thing, right? Like, you know, Heroku, Cloud Foundry, even OpenStack, like virtual machines were still kind of a thing. So it wasn't clear what the abstraction layer for cloud computing was. But once the market started sort of piling on to Kubernetes, you know, like, oh, now Microsoft joined Cloud Data Computing Foundation. They're investing in Kubernetes and creating Kubernetes services. Oh, wait, Amazon's now investing in this? Then the consensus was really coming and built up here.

• 1:34:20Speaker 03

  I think there's a somewhat similar situation here with the caveat of saying like 10 times faster.

• 1:34:26Speaker 00

  Right.

• 1:34:27Speaker 03

  Like just day one, so much momentum around MCP, so much interest in this. And then also 10 years of CNCF to sort of teach the developer community and the vendor community how to do this well, where, you know, investment is not mutually exclusive to great technical outcomes, I think has been super positive. So I think this is going to move super fast.

• 1:34:52Speaker 00

  Awesome. We don't want to keep you guys too long. I'm sure you've been on a media tour this week. What's maybe from each of you, like one thing you look forward in the new year from the foundation?

• 1:35:03Speaker 04

  So I don't really know what it's going to be look like, but I really look forward to like the next step. Like as David mentioned, like it's been months of development and discussion or whatever to bring us to this. And there's this sense of, I guess, relief, achievement as like, you know, you made a foundation. We're collaborating, we created this open space, it's great. But the what next? I'm super excited for the next technical contribution for the first AAIF event or night or conference or whatever form it ends up taking. Cause there's another world where like bodies and foundations are created and then like eventually they get forgotten. And this is not that. This is really a beginning. And so I want to see it be healthy and grow.

• 1:35:47Speaker 04

  And I just don't know what comes next. So I'm most excited to see that in the new year.

• 1:35:51Speaker 02

  Yeah, I think I'm most excited, like if I really take a new to look at like what just happened in the industry was creating this, it's like you have Google, Microsoft, Amazon, Block, Bloomberg, Loudfer, OpenAI, Anthropic, just a platinum member, create a foundation. I think it's just like, this is actually quite, quite cool and quite substantial. And now it's just like. Now we had this like starting point of like, what can we do with this? And to Nick's point, we don't, I think there's a lot of like things we don't know yet and like things we need to figure out, like for Anthropic, this is the first big foundation we are recreating, and we have to learn a lot here. But I think it's just such an interesting like starting point, and I'm just super excited for these

• 1:36:36Speaker 02

  like new, when you, when you start something new, like what you can build with it. And it's, it's in a way of building something that I'm not familiar with, so I'm super excited to learn about this and seeing what we can do with, with this, like, I feel like quite unique vehicle now and like really driving the Agentic AI, like AI, open source community forward and focusing on what we're, some of these companies who are very competitive with each other have coming around, and where we can build things together that is just benefiting and uplifting every user in the market and every developer in the market, every builder in the market significantly. And that's what I'm really excited about to see.

• 1:37:15Speaker 05

  I definitely agree with both. I think there's a lot of like opportunity to figure out what the structure does. But let me give you something more specific that I think is like already in, in coming up, which is I, I want to see how agents become asynchronous. And I'm really tired of like reading through chat sessions and I, and I want this to be a thing where I can go have like 20 agents working for me and actually see that come together. So I think that MCP is starting to like approach that answer. And then we want to like figure out how to make those reference implementations and show people how they can actually get like another order of magnitude out of what AI can do for them.

• 1:37:51Speaker 02

  You don't enjoy pressing yes every five?

• 1:37:53Speaker 05

  The approve every, every three seconds. Bypass, bypass.

• 1:37:57Speaker 02

  Dangerously skip permissions.

• 1:37:59Speaker 05

  Yeah, turn all.

• 1:38:00Speaker 03

  I'm with you on that one. I think what I look forward to is, you know, the success stories of, you know, the, the organization that's implemented Agentic technology in that way and hearing how it really impacted their business. I'm looking forward to stories about MCP startups that made a ton of money.

• 1:38:23Speaker 03

  I'm looking forward to stories like in CNCF this year. CVS Pharmacy joined the Cloud Nater Computing Foundation, right? Like, you know, a pharmacy company that's really a user and adopter of technology, sort of, you know, the late majority. I think we're going to start seeing organizations really, really use this tech impactfully, provide feedback back to the community. And like, it just, the potential of the technology, I don't need to tell this crowd how huge it is, but we'll start to see that truly manifest. That is going to be cool.

• 1:39:02Speaker 00

  Well, thank you all so much for joining and congrats on the launch. Thank you for having us.