Every Company Is Building Agents That Can't Work Together - Justin Schroeder, Standard Agents Transcript, AI Summary & Key Points

00:00 Hey, my name is Justin Schrader. I want to talk to you about standard agents and specifically standardizing agents. But before I do, I want to mention an interesting observation. Um, right now I'm noticing that everybody's building agents. Um, if you walk down your street today, you're probably going to run into people who are building agents to help power their business.

00:19 And this is actually weird because it goes against the prevailing wisdom of the day. Right now, most people who are deep in AI are going to tell you that the right way to put your business and and enable your business with AI is to build an MCP server that exposes the pieces and parts of your business and then write some markdown files, skill files or uh agents MD files, right?

00:41 You you write some markdown files basically documentation and then you give it to a sufficiently smart uh model. So something like you know a claude or Grockbot agent, something like that and then you call it a day. this is sufficient and this is going to do the job. And what's interesting is people just aren't doing this. Well, I mean, people are building MCP, but they're still building agents.

01:03 So, we could view this potentially as they're just making a mistake. Maybe these people are just doing the wrong thing and we need to advise them better. And that might be true. But I actually think that there's some wisdom in what the market is showing us. There's something more there that I want to talk about. And I think it comes down to three factors.

01:18 I think there's three primary reasons why people are still building agents and I want to walk through them before we get into standards. First is integration. Businesses need their processes that are deeply embedded inside of their business to be handled properly. These are not small factors for the business. For example, take something like an HVAC repair company.

01:40 You have all kinds of business processes that make up that organization. Things like, you know, managing warranty claims. How do you know when a warranty claim comes in that it's within the appropriate period or that it's one of the things that was guaranteed? How about crew scheduling? Crews are running all over a big city trying to perform various operations.

01:56 How do you know that the right people are going to the right places? This is critical for their business to function well and they already have lots of software to help handle this. How about pulling permits from the state? How about campaign management or account expansion or job materials? There are so many important processes that a given business needs for it to operate effectively.

02:18 And it's not just HVAC repair. HVAC repair has a bunch, but universities, how about financial aid? How do we make sure that financial aid is appropriately given out or grant administration or housing assignments? How about something like a cloud provider? Making sure that um we aren't having abuse or billing disputes. There are all kinds of important processes that are currently being handled that if you want to integrate AI need to be handled properly and it's not just three, it's really any organization.

02:45 There's all kinds of other higher order things like payroll or contract review. All of these are important processes. It turns out that a business is really just its processes. That is its foundation, its core. In fact, everything that makes a given business valuable is really the result of the processes that got there. So things like relationships and network effects and proprietary data, all of those come as a result of the process working really well, whatever that is and however many that is, right?

03:14 So the idea that we're going to use something like Grockbot to start running all of those processes, honestly, it is it's just not palatable. People do not want this. Even if it works well, which it probably will with some of these really big models. It's too risky. It's too risky to take their business critical process, the thing that makes them who they are as a business, and hand that over.

03:40 So, what businesses really want, and we've found this even in our own experience, is they really want control. And then they need to trust the process. They need to have reliable execution over time. And it needs to be repeatable. It needs to work the same way for the same claim. Okay? And finally, it can't be generic. You just can't use completely generic tools to perform this, right?

04:05 There's a voice. There's a tone that a given business has that they want to preserve. So that's integration. The second part I think that businesses really need is they need to be able to trust what the agent does. And what we like to say around here is that if an agent can do anything, it might do anything. And that is a liability. In fact, that's a really big liability and something that is untenable.

04:31 So, you really need to restrict what Grockbot can do down to something really, really fine-tuned, right? You know, I mean, here this I'm obviously in Jest, but you know, hey, did you get the warranty claim? Yeah, couldn't sign into the warranty portal, so I made a new account, right? I mean, it's not out of the question that Grockpot would do something like that or I replied to some emails while I was at it.

04:50 I read up on the election results, so on and so forth. And the reason of course is just because it has those tools. It has the ability to do that. Now, usually these smart models don't make those result, those errors, those those kinds of mistakes, but it absolutely can happen, right? So, Grockbot has the ability to go check an X account while it's in the middle of performing some other operation.

05:11 And businesses don't want that. They don't want that. Now, instead, what they want is a very clear workflow where some claim is, you know, warranty claim is triggering a given agent to pick up some work. And that agent has very specific tools like looking up equipment, attaching photos, submitting a claim. Now, these are full agents. They have multi-turns.

05:31 They can perform real work. They can do evaluation. They have their own context, but they are limited in their scope to what they can actually perform. We're not just trusting that a model's not going to go do that. So trust number two absolutely critical. Number three is efficacy not efficiency efficacy. This is the most important of the three perhaps.

05:56 We need to make sure that the job is done and it's done well. You know it's it's not enough to say like is my model smart enough but can it do the task it's been given? Can it do it efficiently? And in the in the totality, does it improve the performance of the business or of that process over what we were previously doing? That is absolutely important.

06:14 So, think about, you know, our HVAC uh warranty claim. Our warranty claim itself, that's a small task for an agent, but what we're saying is that would actually make a great agent. That entire thing, just the warranty claim would be an agent. It's not a workflow. It has multiple turns. It is a legitimate agent. And what's really cool about this is you can take all of your business processes and then you can eval them.

06:39 Right? When you try to evalu form of benchmaxing over time where it tries to get really good at the things that are being observed. That's not a bad thing. It's just bad if what you are wanting out of it is not one of those things. But with an agent that is fine-tuned for a very specific task, that benchmaxing is actually a positive. It's a good thing for an individual model with an individual prompt with an with individual tools to have a very high efficacy rate and a very high eval pass rate if that's all that

07:15 they're being asked to do. So the current state of affairs is that we use super super smart models like you know opus 55 which is a spectacular model and and then we just give it more tools and more skills and I don't want to say that this doesn't work because we have created an ecosystem where this works tremendously well however it can it is also very very large as opposed to creating something with you know deepseek v4.1 flash that is only performing one operation something something like the warranty claims agent.

07:50 So fundamentally a Gmail agent beats a Gmail skill. It's not that both of them don't work. Of course, Claude can very easily use a skill to go check Gmail or probably do it without a skill. But Deepseek v4.1 Flash can actually do a tremendous job of this. So it's definitely going to be cheaper. Obviously Flash is incredibly cheap. Um but you can actually eval that tiny little agent.

08:13 And if you guys remember the Jeepa paper from uh several months ago, it said that fine-tuning an agent is actually more effective fine-tuning the prompt of an agent than fine-tuning a model. And that is absolutely true. We can get DeepSeek V, you know, 4.1 Flash to do a tremendous job, an incredible job of just being a Gmail agent. That's very simple.

08:33 It only falls apart when you ask it to be way more than that. And then finally, you can compose it into a larger system. You could even expose the Gmail agent as an MCP server to Opus 55. Or you could create an hierarchy of these smaller agents all working together under some larger agent that has a defined task as well. So if these smaller domain specific agents are so great, why aren't they everywhere?

08:59 Why isn't everybody using them everywhere? Well, they sort of are, right? Because everybody kind of is building agents right now. The problem is that they're just a mess. Everybody's writing them in all kinds of different languages, writing all kinds of different tools, all kinds of different uh agentic loops. It's it's a bit of a mess. And the truth is that agents are actually hard.

09:19 The base is really simple, right? You just have a model, then you've got a system prompt of some kind. You put some tools in there, then you have a message histories. Uh but in reality, of course, it's actually very hard. There are so many things to worry about. Um there's, you know, the actual orchestration of the loops, how many steps it can take before there's a problem.

09:37 You have parallel tool execution where you need some sort of async system to handle those. You need durability so we can pick up after errors. There is a lot that goes into building an agent. And really in order to build an agent, what you're really doing is you're building a harness. And even if you did go down the MCP path and all you were doing was MCP, well often you're going to find and a lot of businesses that we talked to are finding that they also need inference.

10:04 The tools themselves need inference to become more val more more valuable. But if you're going to start providing inference there, then pretty soon you need multiple steps of inference and all of a sudden you've recreated another agent system just within MCP. But even if you did build a custom harness, there are still important problems that have to be solved.

10:22 For example, I can't build a custom harness and you build a custom harness and then we just easily share with each other. It might not run in my hosting environment. There's all kinds of questions about how you would actually share that with someone else. Or how about composition? How do you actually put two of these things together and have them work efficiently together?

10:40 If I built mine in a different way than yours, then they're in they're fundamentally incompatible. And we're not building them at scale. Like I don't want to build hundreds of these custom agents. That's insane. I don't want to do that and then ultimately just end up with Grockbot at the end of the day. There has to be something better than that. And we see this because even skills aren't being written entirely by one person, right?

11:03 There's an entire ecosystem of people's people writing skills. Again, these are just markdown files. So the idea that one person is or one business is going to create hundreds or thousands of their own agents that are interoperable is a little bit silly. We need an ecosystem of sharable agents instead. So the solution is obviously standards, right? That's the whole point of my talk.

11:25 We're talking about standard agents and what's interesting is that we have standardized agents to a large degree. We've standardized the things around them. Right? So for tools we have MCP basically tool distribution standards. Uh skills are basically a form of prompts that we have decided we can standardize. They have agents MD another form of prompts.

11:45 We have A2A for for intercommunication. We have ACP and we've got you know X42 if you want to do payments. There's all kinds of standards that are starting to evolve around the agent ecosystem, but as of today, there is nothing for the harness itself. There is no agent runtime. And this is important because what a spec actually gets you is incredibly important.

12:07 First of all, speed. You don't have to reinvent the world every time you create an agent, right? You can have the exact ampic loop specified. We can know exactly how to write tools. Our agents are not responsible for building that part of the ecosystem. Consistency. Every agent should be built exactly the same way. Now that doesn't mean that every agent is just a markdown file.

12:32 It needs to have deep, deep ability to customize, but those customizations should automatically work in any compatible runtime. There's also portability. I need to be able to write an agent, pack it up, and literally put it on a zip drive if I want to or a USB stick and give it to you. And of course, composability. This is, you know, perhaps a little bit of a vague and overused term, but all it means is that you're assembling smaller parts into something larger than itself.

13:00 And composability is really a huge key to unlocking how domain specific agents can be brought to the market. So, we need this. But unfortunately, no such spec exists until today. And I am really excited to tell you about the standard agent specification. We are announcing it literally today as you are watching this. It is an open-source spec. It's available today at standardagentspec.org.

13:34 And I'd like to show it to you a little bit. To start with, we make some claims. First, this is our definition of agents. Agents are deterministic software that harness the non-deterministic results produced by models in pursuit of a desired objective. If that sounds a lot like a harness, it even has the word harness in it. It's intentional. A good agent is a good harness.

13:54 You could almost think of an agent like an instance of a harness. And then there are five other core principles that the spec is built on. First of all, agents need to be vendor agnostic. Agents should be domain specific. Agents should be coupled to a given model. Agents should be composable. And agents should be portable. I want to talk about two of these that seem like they're contradictions.

14:19 The vendor agnostic thing and the couple to a model. Vendor agnostic means I don't want my agent running exclusively on anthropics hardware or exclusively within the OpenAI ecosystem. I need to be able to host it wherever I want to host it and I need to be able to run whatever models I need to run. That being said, an individual agent is almost always best when it's paired with a specific model.

14:44 Now, this starts to be less true on the large model front, but even there it's true. Different harnesses do produce different results. So, let me give you a little bit of a tour here of the specification. First, we have the runtime. An agent runs in a runtime very similar to how a language runs in a runtime. The language in this case is the definition of the agent and the runtime is what is so highly specified.

15:10 But if we take a look inside, we'll see that agents are really just packages with lots of pieces and parts which are painfully and excruciatingly detailed in the specification. So we're going to keep this little map here of model, system prompt, tools, sub aents, agent rules, hooks, effects, and then the thread. all of that map and we're going to walk through some of these piece by piece.

15:30 So first of all, everything in the specification is intended to be written as code. Now this is important for two reasons. One, we need to be able to pack this up and distribute it. I need to be able to take an agent and everything that that means, every piece of information that has to do with that agent, and I need to be able to pack it up, literally put it on a USB stick and hand it to you or publish it to a package registry.

15:56 And the only way we're going to do that is if everything is code. So, first everything has to be code. Also, we want to be able to write agents with agents. I don't want to sit down and handwrite an agent. That's crazy. So, of course, it needs to be code. So it is an agent first ecosystem. So let's take a look at how these are actually written. We made a really interesting decision early on.

16:19 We decided that we needed to have all of the agents written according to the specification in the same language and we chose TypeScript. Now we didn't choose TypeScript because we're big TypeScript fans. It's fine. Uh we chose TypeScript because in today's era, languages really almost have no value. The only value a language has is the artifact that it produces at the end.

16:42 What's unique about it? And in our opinion, there's really only two languages that matter. I know some of you are going to disagree with this, but the two languages are Rust or Rustlike systems that that write extremely fast performant code and TypeScript. Now, why TypeScript? Typescript because it runs everywhere, absolutely everywhere. It runs on the edge.

17:01 It runs on your computer. It runs on your mom's computer. It runs on your phone. It runs everywhere. And in this particular case, we want agents to run everywhere. But there is a second reason. Typescript is an interpreted language. Well, technically JavaScript is. JavaScript is an interpreted language. And we want that because we want our agents to be able to write agents and execute them immediately without a build or a compilation step.

17:25 And the only way we're going to do that is by using an interpreted language. And as far as interpreted languages go, TypeScript is about as robust, fast, available, and portable as any of them out there. We didn't want to do the MCP thing that already exists. MCP requires you to have some sort of server in order to serve the tools. We don't want to do that.

17:45 We want to be able to bundle it all together. So this is what it looks like. If you want to define a model, you do that in Typescript. All of this is very tightly typed. If you want to define a prompt, you define the prompt using define prompt. You want to define an agent, you do it with define agent. Now, one really important fact is that models uh models that are defined in code define the exact model that they are running on.

18:13 So, my agent is going to run on a specific model of OpenAI. And of course, you can have fallback models. So if my primary model fails then we recommend you go up a level of intelligence and switch to another one. This gives us a tremendous advantage that we can use the jaggedness of an LLM. So a good example is uh you know we have this fun project called model zen garden and model zen garden creates lots of different uh 3D zen gardens for people to walk through and what we found is one model in particular um 10 cents

18:45 y3 was spectacular at producing 3D gardens at a fraction of the cost of all the others. It wasn't a very good model but this is the jaggedness. it was good at that one characteristic and one trait. And for domain specific agents, that actually is a benefit, not a hindrance. So, it's great to be able to use a smaller model for a small task that it's very, very good at.

19:06 And right now, we've sort of all been trained that you write your agent and then you just swap out models willy-nilly and you kind of hope for the best. That goes against one of our fundamental principles, which is efficacy. We need high efficacy. And so it is almost always better to pin a very specific model running at a specific quant by a specific pro provider to your agent.

19:30 Next are prompts. Prompts are what they sound like. These are the system prompts. But interestingly, they own one side of the conversation. So conversations for agents are basically always two-sided. You have the assistant and you have the user. And in this case, the prompt is owning one side of that conversation. And another interesting thing you can do is you can include prompts inside of other prompts.

19:51 They are effectively rendered at runtime. So if you have environment variables that are public or things like that that you want to get written into the prompt at runtime, that is completely possible. Or perhaps you have something like a tone prompt where you have got lots of different sub aents and all those sub aents need to speak to users in a particular way.

20:12 That's not a problem. you can just make that happen uh by including a singular prompt in all of them that says hey you're going to speak this way. Now tools are basically one of three kinds. You either have a function where you actually run some code in Typescript or it's a prompt. So this is really useful when you need to perform a little bit of inference somewhere else like I need to just use nano banana to produce an image but I don't need a full sub aent to do that.

20:40 um or this one model is actually better than my primary model at sounding like a human. So, one of my tools is actually a prompt. It's just a subprompt, not a sub aent. And then the third type of tool is an entire agent, a whole sub agent. So, I can call an agent as a tool and it will just work. This is all part of the specification. Now, remember I said that all conversations in AI have two sides, side A and side B.

21:05 And there's a bunch of different ways according to the spec that you can mix and match these. The one we're the most familiar with is a prompt speaking to a human. In other words, you have an AI talking to a human. This is like chat GBT. But you can also have two AIs speaking to each other. Where side A and side B are actually both AI and side A is, you know, writing thinking it's speaking to a human and side B is writing thinking it's speaking to a human and they're both performing the operation together.

21:34 Now, this works wonderfully as built-in eval built-in QA. I ask, you know, side A to to generate some kind of asset. It produces an image, let's say, and and there's a watermark on it. It thinks it looks great. So, it passes it to side B. Side B looks at that and says, "Hey, there's a watermark on there. What are you doing?" Side A says, "Oh my goodness, I'm so sorry about that.

21:53 You're absolutely right." And then it regenerates it. So, those work really great for built-in uh evalu. And then we have a handler. A handler is basically just code. So the simplest form you could imagine a piece of code runs on one side that just says continue and you type something to it and it says continue. You type something says continue. So in that case you could actually create an agent with no AI involved at all where you have deterministic code speaking to a human.

22:21 That's fine within our spec. And then uh ultimately you could have an a prompt and a human talking to each other where one of them is actually a sub agent. This gets a little bit confusing but rest assured your coding agent will figure out when you need to use these. So handlers here's an example of a handler. In this particular case the handler is speaking uh deterministically back to a human or even to an AI.

22:43 In this case we have uh two agents speaking to each other. So you have a side A and a side B. And here you can see that we're defining which prompt each side has. So we have the asset worker and then the asset reviewer side of the conversation. Now sub aents sub aents are exactly what they sound like. They are entire agents with their own side A and side B.

23:07 And here you can see that we have the calendar agent and in this case we have two instances of the same agent. A one is a work calendar and one is personal calendar but ultimately they have the same agent backing both of them the same prompt the calendar agent. Now parent hooks are a fascinating concept in the specification. They allow a child sub agent to get installed under a parent and when they get installed they automatically expose and modify the hooks of the parent.

23:39 This allows a composition without having to do any additional configuration or telling the parent prompt, hey, by the way, you have this subprompt that does something. No, not necessary. Just installing the Gmail agent, for example, automatically can let the parent know how to use it. Hooks are what they sound like. They are deterministic events, stuff like filter messages, before tool call, after update message that run at very specific moments in time throughout the life cycle of the agent running.

24:10 And these are all defined in the specification. Effects are basically scheduled code. You write a chunk of code that needs to occur at some other point. This could be something simple like an alarm clock. You could have a define effect for an alarm clock or you could define an effect to uh send an email. And when you define this effect, you can then schedule it to occur at some other time.

24:34 Obviously, you are often going to schedule the effect inside of a tool call. So you could have a tool call that schedules an effect to happen at some point in the future. This is effectively like if I'm talking to Grockbot and I say, "Hey, please, you know, don't don't let me forget my my kids piano recital tomorrow." Okay, great. No problem. It's going to then set some sort of a reminder to to trigger.

24:53 This is how a tool would be able to do something like that within the specification. You have an effect that you define and then later you schedule it to occur at some point in the future. Now every thread according to the specification is a full little environment. You could think about each one like a little sandbox. It has its own messages and and everything to do with its messages stored there.

25:17 All of its own tools are stored there. Its sub aents are stored there. It has its own KV store. It has its own file system. It even has an ability to write its own code. and then run that code if you choose to give it the ability to do that, of course. So, let's take a little bit of a look at threads. First, there's code execution. Here you can see I can write some code.

25:38 It can be just a text code. My agent can write some code, store it to the file system that I just told you exists. And then it could read that code and run it. And then you specify exactly what it has access to. You can even say you don't have access to the internet when you run it. That is all part of the specification. Instead, you say, "These are the things that you can import.

26:00 These are the things that are allowed." And by doing this, you can allow agents to have tremendous latitude to operate within their own ecosystem. You could also write uh an agent to use code mode. The spec is very unopinionated about things like that. But personally, I use code mode all the time with the standard agent specification. By doing this, threads can also use decision models.

26:22 In this case, we're using Typesafe AI's Jev to determine if the customer is being, you know, is happy or is upset. What's their sentiment right now? Do we need to escalate this to a human? That is part of the runtime in the thread execution. Threads can also expose endpoints. This is part of the specification. It doesn't have to, but a given agent should have the ability to expose its own endpoints.

26:48 This would allow you to create something like Grockbot that's completely open- source where you can host it on your own service and it would expose its own ooth endpoints for example or host its own API. So you could create something uh like cloud artifacts and then agents must be able to be packed. The idea is you can pack these down into something like an npm package or literally an npm package, publish it, and anyone can install it, anyone can load it, and it just works.

27:24 The runtime is the magic behind it just working. Of course, once you have an agent in a runtime, there are explicit rules in the specification for how it needs to run. Now everything is really unopinionated and it never says what kinds of implementations you need to have. What it says is how you handle the different runtime states like how do you handle a step of the agent, right?

27:46 How do you enforce safety across uh your run code? How do you how do you store files? So for example, there is a a basically a thread state readad file. Well, it doesn't say how the file should be read. In our case, we actually host this on Cloudflare in durable objects and we implement read file as reading to a database. There actually is no file system, but the thread sees there being a file system there.

28:13 That is all part of the runtime contract that is really, really critical. So, in the end, you can build almost any agent system you can think of. You could build really small ones or you could build entire coding agents. So, we actually did this a while ago. We built a full coding agent made up of lots of individual tiny little sub aents that were all working together and it worked great.

28:36 And what was awesome about it is because they were all standard agents, we could go and install another standard agent that was out in the ecosystem and just add them to our coding agent like you would add skills except these are full agents with their own ability to perform execution. But there's one more thing I want to talk about. We're also releasing standard agent builder.

28:55 This is the first public runtime for the standard agent specification. We have already been using this in production for some time and it's working great. You can clone this literally today onto your machines and start using it. Then you just ask your coding agent to create some new agent for you and it will know exactly how to do that. It knows it does not need to reinvent every part of the harness, but it knows exactly how to define deterministically the pieces and parts that need to be there.

29:27 And then you can run it at anywhere. You can run it for free locally and if you push it, we have a cloud you can push it to if you want to put it in production. But again, it's an open specification. You can just point your coding agent at the spec and say, "Build me a runtime for this specification." We will even host and put links on the spec site to your runtime because we really do want this to be an open ecosystem.

29:48 Okay, with all that, I want to do a little bit of demo time. Earlier today, I had Claude Code create a battery warranty claim. So, this is very similar to the HVAC example that we were doing. I gave it a full PDF of the process that it needed to go through. Now, I'm fast forwarding this so that way you guys don't have to sit here and watch while Opus does its work.

30:10 But right now it is reading um everything that that PDF defines as part of its process. Then it's going to write specific tools and define specific models in order to fulfill that specific task. And then it's going to write those in code. And while it's doing this, it knows that it the architecture is already solved for it. So it can do this way way way faster than you're traditionally used to.

30:34 Um so you can see here this is in real time now. So, we fast forwarded. It's now telling me it's done. Okay. So, in real time, it took 5 minutes and 21 seconds in order to produce this agent. And I want to show you what it actually made in 5 minutes and 21 seconds. So, this is the file system. Here you can see it created these files. So, battery warranty agent with prompts and then specific tools.

30:58 Check battery, escalate to lead. And here you can see what the agent itself looks like. Now, this is a side A is a prompt and side B is a human. Here's the actual prompt that it wrote. Here is the model. So, it created a model called warranty, which is Deepseek V4.1 flash. And in this case, it's also showing uh the here we're looking at the tools that it created in order to do its job.

31:23 Stuff like offer tradein, check battery, uh report safety issue. All of those tools are explicit tools just for that process. They are not tools that were created in any which way to go check on the latest, you know, politics or anything like that. These can only do the work that they've been assigned. Now, here it is inside of agent builder. We have our actual battery warranty.

31:45 Then we can see all of the threads and this is like the admin view into your agent. Now, you can actually interact with it directly here, although most of your users are not going to be using the agent here, but you get incredible detail on everything that happened. So, we can see all of the tools that were called. We can see exactly the models, exactly the cost, how many tokens were sent, what our cash rate hit was, 94% in this case.

32:08 We can see the tools that we sent. Um, so in this case, we sent these six tools for it to choose from, and you know, in in our particular case, it shows one of those tools to call. Um, you can also see the full request body, every little detail about what was actually sent to the LLM. This is super valuable for when you're building out your tool. And then ultimately, we can see that it called the ship replacement tool.

32:32 And then finally, the way your users are actually going to interact with this is manifold. In this case, we put a little chatbot on a website. Now, this is the actual agent behind the scenes because an HTTP API and a websocket API are both part of the specification. They both need to be exposed. So, here we can see that we could very easily build an online support bot that is able to do this.

32:53 But again, we could expose the same agent because it's a standard as an MCP server. So if somebody is using our website with chatgbt or something like that, they could automatically have uh their agent talk to our agent. So that is a little brief preview of how the standard agent builder works that's out and available right now. So I know that was a lot.

33:16 It was a lot of information, but I hope you were able to get something from that. We are really excited to see people start building runtimes. Um, if you would like to build a runtime, build it in whatever language you want, as long as it can execute the TypeScript that's in the spec. Um, you could build the runtime in Rust, you could build it in Go, you could build in whatever language you want.

33:34 The runtime is totally up for grabs as long as it complies with the spec. Then start building some agents. I'm super excited to see an ecosystem of domain specific agents emerge. Um, whatever you want to build, we would love to see it. And then try breaking the spec a little bit. Um, we are by no means coming with a finished solution. We're looking for people to help push the spec forward.

33:57 This very much reminds me of the early days of the web, right? When each browser was trying to push its own features. Hey, you should use Mozilla because we have this crazy new thing called JavaScript or something like that that nobody else has. That's a little bit like the world we're in right now. And it took a ragtag group of spec enthusiasts [clears throat] to get a spec that was uh owned by the entire world by the entire ecosystem and really push the web forward.

34:23 We want the same thing to happen right now with agents. So I hope that some people out there would be excited to help us on that journey and then start your coding agent. Boot it up, add a skill to it and start writing new stuff today. Okay. Thank you very much. You can follow me on X. You can go to standardagentspec.org or to hear more. All of this is available to you and I cannot wait to see what you all build.