Why Businesses Keep Building Agents That Can't Work Together, and a Proposed Standard Runtime to Fix It

Schroeder begins by noting that he sees businesses building their own agents to help run their operations. He says this runs against the prevailing wisdom in AI, which holds that the right way to enable a business with AI is to build an MCP server that exposes the business's pieces and parts, write markdown files such as skill files or agents.md files, and hand them to a sufficiently smart model such as Claude or Grok, and that this is enough.

He acknowledges that one interpretation is that these businesses are simply making a mistake and need better advice. He says that view may be partly true, but that the market is showing something worth examining, and he proposes three reasons why companies still build agents: integration, trust, and efficacy.

Schroeder's first reason is integration. He argues that the processes deeply embedded in a business must be handled properly because they are not small factors for the company. He uses an HVAC repair company as an example, listing processes such as managing warranty claims and checking whether a claim falls within the warranty period, crew scheduling so the right people go to the right places, pulling permits from the state, campaign management, account expansion and job materials.

He says the same applies beyond HVAC repair. Universities have processes such as financial aid, grant administration and housing assignments, and cloud providers must handle abuse and billing disputes. In his words, a business is really just its processes, and any AI integration has to handle those processes properly.

He adds that businesses want to be able to trust the process, get reliable execution over time, and have repeatable results, so the same claim produces the same outcome. They also do not want completely generic tools, because each business has a voice and tone it wants to preserve.

The second reason is trust. Schroeder says that what he and his team like to say is that if an agent can do anything, it might do anything, and that is a liability, one he describes as untenable for businesses. He suggests the tools available to an agent must be restricted to a very fine-tuned set.

He gives an example in which a warranty claim agent, unable to sign into the warranty portal, creates a new account, or replies to emails, or looks up election results. He notes that smart models usually do not make such mistakes, but it can happen because the agent has the tools to do it.

Businesses therefore want a clear workflow in which a warranty claim triggers an agent that has specific tools, such as looking up equipment, attaching photos and submitting a claim.

Schroeder argues that such a warranty claim agent is a full agent. It can take multiple turns, perform real work and do evaluation, and it has its own context. However, its scope is limited to what it can actually perform.

He says the goal is not to trust that a model will not go off and do something else, but to limit what it is able to do.

Schroeder calls efficacy, not efficiency, the third need, and says it may be the most important of the three. The question is whether the job gets done well. He argues it is not enough to ask whether the model is smart enough or can complete the assigned task efficiently; the key question is whether the agent, in the totality, improves the performance of the business or process over what was done before.

He returns to the HVAC warranty claim, saying that although the claim itself is a small task for an agent, it would make a good agent in its own right. It would not be a simple workflow, because it has multiple turns and is a legitimate agent.

He also says business processes can be evaluated, and that a model can become very good at the things being measured. He describes this benchmarking as a negative only when it targets the wrong goals, but for an agent fine-tuned to one specific task, it is a positive: a single model with one prompt and specific tools can reach a very high efficacy rate and eval pass rate if that is all it is asked to do.

Schroeder asks why, if small domain-specific agents are so valuable, they are not everywhere. He says in one sense they are, because many people are building agents now. The problem is that the result is a mess: agents are written in many different languages, with different tools and different agentic loops.

He explains that agents look simple, consisting of a model, a system prompt, tools and a message history, but are actually hard to build. Builders must handle the orchestration of loops and how many steps can run before a problem arises, parallel tool execution that requires an async system, and durability so the agent can pick up after errors. In order to build an agent, he says, you are really building a harness.

He adds that even an MCP-only approach runs into trouble, because many businesses find they also need inference. Once tools need inference, multiple inference steps follow, and the builder has recreated an agent system inside MCP. Even a custom harness raises problems: two custom harnesses cannot easily be shared, one may not run in another's hosting environment, and it is unclear how two of them could be composed efficiently.

Schroeder says he does not want to build hundreds of custom agents, calling that insane, and that there has to be something better. He points to skills as evidence that the solution is not one person writing everything: an entire ecosystem of people writes skills, and these are just markdown files. He argues it is silly to expect one business to create hundreds or thousands of interoperable agents of its own, and that an ecosystem of sharable agents is needed instead.

He says standards are the answer and that standards already exist for much of the agent ecosystem: MCP for tool distribution, skills and agents.md as forms of prompts, A2A for intercommunication, ACP, and x402 for payments. But as of today, he says, there is no standard for the harness itself and no agent runtime.

Schroeder says a spec provides speed, because builders do not have to reinvent the entire system each time they create an agent. The loop and the way to write tools can be specified, so agent makers need not build that part of the ecosystem.

It also provides consistency, meaning every agent is built the same way. Schroeder notes that this does not mean every agent is only a markdown file; agents still need deep customization, but those customizations should work in any compatible runtime. Portability means an agent can be packed up and handed to someone else, and he jokes that it could be put on a zip drive or a USB stick. Composability means assembling smaller parts into something larger, which he says is key to bringing domain-specific agents to market.

He says no such specification existed until now, and announces the standard agent specification, an open-source spec available at standardagentspec.org.

Schroeder says the team decided that all agents written to the specification would use the same language, and chose TypeScript. He says the choice was not because they are big TypeScript fans. Instead, he argues that languages have little value today, and the only thing that matters is the artifact they produce. In his view there are really two languages that matter: Rust or Rust-like systems that write extremely fast performant code, and TypeScript.

TypeScript runs everywhere, he says, including the edge, your computer and your phone. Because it is interpreted, agents can write other agents and execute them immediately without a build or compilation step, which is essential to the design. He adds that the team wanted to avoid the existing MCP model, which requires a server to serve tools, and instead wanted everything bundled together.

Schroeder explains that models, prompts and agents are all defined in TypeScript and are tightly typed, using define model, define prompt and define agent. A model defined in code specifies the exact model the agent runs on. Fallback models can also be included, and if the primary model fails, the recommendation is to move up one level of intelligence.

Schroeder cites the Model Zen Garden project, which creates 3D zen gardens for people to walk through. The team found that one model, priced at 10 cents, was spectacular at producing 3D gardens at a fraction of the cost of all the others. He acknowledges it was not a very good model overall, but it excelled at that one characteristic, and for domain-specific agents that kind of narrow strength is a benefit rather than a hindrance.

He contrasts this with the common practice of swapping models willy-nilly and hoping for the best, which goes against the principle of efficacy. He concludes it is almost always better to pin a very specific model, running at a specific quant and from a specific provider, to an agent.

Schroeder says prompts are the system prompts, but they own one side of the conversation. Agent conversations are always two-sided, between the assistant and the user, and the prompt owns one of those sides. Prompts can include other prompts, which are rendered at runtime. A public environment variable can be written into a prompt at runtime, and a tone prompt can be included in many sub-agents so that they all speak to users the same way.

Tools are of three kinds: a function that runs TypeScript code, a prompt, or an entire sub-agent. A prompt tool is useful when a small amount of inference is needed somewhere else, such as using a model to generate an image without a full sub-agent, or when one model is better than the primary model at sounding human. The third kind is a whole sub-agent, which can be called as a tool.

He notes that the specification allows these pieces to be mixed in various ways. The most familiar is a prompt speaking to a human. A deterministic handler can also speak to a human without any AI, and a prompt can speak with a human where one side is a sub-agent.

Schroeder gives a handler example in which a handler speaks deterministically to a human or to an AI. In the example, two agents speak to each other, with a side A and a side B, and each side is given its own prompt. Here the asset worker and the asset reviewer form the two sides of the conversation.

He then describes sub-agents as entire agents with their own side A and side B. His example includes a calendar agent with two instances of the same agent, one for a work calendar and one for a personal calendar, both backed by the same agent and the same prompt.

Schroeder describes parent hooks as a fascinating concept in the specification. A child sub-agent installed under a parent automatically exposes and modifies the parent's hooks. This allows composition without any additional configuration and without telling the parent prompt that the child has a subprompt that does something.

His example is that installing a Gmail agent is enough to let the parent know how to use it. He explains that hooks are deterministic events, such as filter messages, before tool call and after update message, which run at specific moments in the agent's life cycle, and that these are defined in the specification.

He also describes effects as scheduled code. A developer writes a chunk of code to occur later, such as an alarm clock or sending an email. A tool call can schedule an effect for a point in the future, so that a request to be reminded of a piano recital could set a reminder to trigger at the right time. Each thread is a full environment that he likens to a small sandbox.

Schroeder says agents must be able to be packed, for example into an npm package. Once published, anyone can install and load the agent and it works. He credits the runtime with making this work, since the spec sets explicit rules for how an agent must run, while leaving implementation open.

He gives examples: the spec defines how a step is handled, how safety is enforced and how files are stored, but does not say how files are read. His team hosts the runtime on Cloudflare durable objects, where reading a file is implemented as reading from a database; there is no actual file system, though the thread sees one. He says this is part of the critical runtime contract.

Schroeder announces Standard Agent Builder, which he describes as the first public runtime for the standard agent specification. He says his team has used it in production for some time. Anyone can clone it onto their machine and start using it, and they can ask their coding agent to create a new agent, which will know how to do that. The coding agent does not need to reinvent every part of the harness, but knows how to define the necessary pieces deterministically.

Agents can run locally for free, and a hosted cloud is available for production. Schroeder says the specification is open, so people can point their coding agent at the spec and ask it to build a runtime for it, and the team will link those runtimes on the spec site.

Schroeder then describes a demonstration. Earlier that day he had Claude Code create a battery warranty claim agent, similar to the HVAC example, by giving it a full PDF of the process. He fast-forwarded the footage. The agent read everything the PDF defined, then wrote specific tools and defined specific models for the task, all in code. Because the architecture was already solved for it, the agent could do this far faster than people are traditionally used to. Schroeder says that in real time, producing the agent took 5 minutes and 21 seconds.

Schroeder shows the Standard Agent Builder admin view for the battery warranty agent. It lists all the threads and provides detail on everything that happened. Developers can see all the tools that were called, the exact models, the exact cost and the number of tokens sent. In this run the cache rate reached 94 percent.

The view also shows the tools offered to the model, six in this case, from which the model chose one to call, and the full request body sent to the LLM, which he says is valuable when building tools. The run ultimately called the ship replacement tool. He notes the tools were explicit ones created for that process and could only do the work assigned to them.

He also shows how users can reach the agent. A chatbot on a website was built on it, since HTTP and websocket APIs are part of the specification. Because it is a standard, the same agent could also be exposed as an MCP server so that someone using a chatbot service could have their agent communicate with it.

Schroeder says the team is excited to see people build runtimes. A runtime can be written in any language, such as Rust or Go, as long as it can execute the TypeScript in the spec. He says the runtime is totally up for grabs as long as it complies with the specification, and encourages people to build agents and try to break the spec.

He acknowledges that the team is not presenting a finished solution and is looking for help pushing the spec forward. He compares the moment to the early days of the web, when browsers each pushed their own features, and says that a ragtag group of spec enthusiasts helped turn the web into a spec owned by the whole ecosystem. He hopes the same can happen with agents.