Every Company Is Building Agents That Can't Work Together - Justin Schroeder, Standard Agents

An HVAC technician has photographed a broken part. A warranty claim now needs the equipment record, the photos and a submission to the manufacturer. Justin Schroeder imagines asking a general-purpose assistant to take care of it. When the assistant cannot sign in to the warranty portal, it creates a new account. Perhaps it catches up on a few emails along the way. The example is a joke, but the manufacturer would receive a claim from an account the business never authorized.

Schroeder would give the agent three tools for that job: look up equipment, attach photos and submit a claim. It could still ask for missing information and take several turns to finish. The technician would have latitude over how to describe the fault, and the model could choose which tool to call next. Neither needs authority to create an account. A different agent could handle crew scheduling or state permits, where the same company follows different rules.

The narrow assignment also gives the business something it can measure. Two identical claims ought to reach the same disposition. An unusual one may need a person. Those are cases a warranty team can collect, label and rerun. A higher score on a general model benchmark tells that team little about whether its next claim will be filed correctly. Schroeder argues that a smaller, cheaper model deserves a trial when the team can evaluate it on the actual work.

Consider a team that builds a good Gmail agent. The team can tune a model for email and expose the agent as an MCP tool to a larger assistant. A second team now wants to run the email agent in its own environment. Handing over the prompt and tool descriptions leaves out some consequential code. What happens when the model calls two tools at once? How many steps may it take? Which part of a conversation survives a failed request?

These decisions live in the harness, the software that runs the loop around the model. Two companies can both speak MCP and still give different answers to every question above. A Markdown skill can explain what an agent ought to do, and a protocol such as A2A can carry a message between agents. The recipient still has to implement the behavior that made the original agent dependable. Schroeder wants to be able to hand someone a package containing that behavior, down to putting it on a USB drive.

The open Standard Agent Specification is Schroeder’s proposal for that package and its runtime. An author writes the model selection, prompts, tools and other pieces in TypeScript. The host runs the resulting agent according to a common contract. The author can choose a particular model and test against it. Another company can run the package on its own hardware or implement the host in a different language, provided it can execute the TypeScript and honor the same behavior.

The distinction is easiest to see in a file read. An agent can save a file and read it in a later turn. In the hosted implementation Schroeder shows, a Cloudflare Durable Object reads the contents from a database. The agent sees a file. A local runtime could store the same contents on disk. Requiring the two hosts to expose the same operation gives an agent somewhere else to run without asking its author to adopt the same storage system everywhere.

The specification describes a conversation as two sides. One side can be a person, a model working from a prompt, or ordinary code. In one example an asset worker produces an answer and an asset reviewer sends it back for another pass. In another, a deterministic handler simply tells the other side to continue. A team can put code in charge of a predictable decision and spend an inference call where an answer genuinely needs judgment.

An agent can also contain another complete agent. Schroeder shows two calendar instances, one for work and one for personal appointments, backed by the same calendar agent. Each instance has a separate job in its parent. Hooks let the installed child participate in specified events in the parent. The author who knows calendar behavior can ship that behavior with the package, while the person assembling the parent decides which calendars it should use.

For the demo, Schroeder gave Claude Code a PDF describing a battery warranty process. The coding agent read the policy and generated the model definition, prompts and tools for a specialist. Schroeder reports that this took five minutes and 21 seconds. The resulting files include operations to check a battery, report a safety issue, offer a trade-in and escalate to a lead. An engineer reviewing the output can compare those operations directly with the policy that prompted them.

Standard Agent Builder shows what happened on an actual turn. The runtime sent six tools to the model and the model picked one: ship a replacement. The inspector exposes the request, model, token counts, cost and which tool ran. It reported a 94 percent cache hit rate for that example. That figure describes the displayed request. The reason to inspect it is practical: if a replacement ships when a claim calls for escalation, the operator can see which choices the model received.

A customer used a chat box on a website, while Schroeder inspected the same agent in Builder. The runtime supplies HTTP and WebSocket interfaces, and the agent could also be exposed through MCP for someone using a different assistant. Schroeder closes by inviting people to implement other runtimes and try to break the specification. The real test of portability will come when someone takes a working package out of Builder and runs the same claim somewhere else.