A proposed runtime standard for agents that work together

Justin Schroeder observes that companies are building their own agents even as tools such as MCP and reusable instructions make general-purpose agents more capable. He sees three reasons: integration, trust and effectiveness.

Business processes are specific and consequential. Schroeder gives warranty claims, crew scheduling and permits at an HVAC company, and financial aid and housing assignments at a university, as examples.

He argues that businesses want control, reliable repeatable execution and an experience that reflects their own way of working. They may be reluctant to hand a critical process to an unrestricted general-purpose agent.

Trust also depends on restricting what an agent is able to do. In his example a warranty agent needs equipment lookup, photos and claim submission, rather than access to unrelated tasks.

Schroeder distinguishes effectiveness from speed: the question is whether the agent completes its assigned work well enough to improve the business process.

A narrowly scoped warranty agent can be evaluated against the particular outcomes it is supposed to produce. He argues that optimizing for those tests is useful when the tests match the real job.

He suggests a small model tuned through its prompt and tools can perform a specific task cheaply, even though a larger general model may handle many tasks. He calls a dedicated Gmail agent an example.

Those specialized agents can themselves become tools for a larger agent or be combined in a hierarchy. The issue, he says, is that teams build their agents in incompatible ways.

The apparent basics are a model, prompt, tools and message history. Production systems must also handle execution loops, parallel tools, recovery and persistence.

A custom agent harness may be difficult to run in someone else’s environment, combine with another harness or distribute at scale. Schroeder wants an ecosystem of reusable agents.

He says MCP standardizes tool access and other projects address prompts, communication or payments, but argues that the agent runtime itself also needs a common contract.

A shared specification could reduce repeated infrastructure work and help make agents consistent, portable and composable, while still allowing their behavior to be customized.

Schroeder announces the open Standard Agent Specification and defines an agent as software that uses model outputs to pursue an objective. Its principles include portability, composition and domain specialization.

He distinguishes a vendor-neutral runtime from a particular agent being paired with a particular model. A portable framework can support different providers while an individual agent remains tested against one choice.

An agent package contains a model, prompts, tools, subagents, rules, hooks, effects and a thread. The runtime provides the execution contract for those pieces.

The specification uses code so that an agent can be packaged and distributed, and so coding agents can create the definitions. The selected authoring language is TypeScript.

Schroeder says portability and the ability to execute generated code motivated the language choice. Compatible runtimes can be implemented in other languages as long as they execute the specified TypeScript.

The model definition pins a model and can specify a fallback. He recommends choosing a particular model and provider based on the task and evaluating that combination.

He points to a 3D garden project where one comparatively small model performed especially well at a particular task. That uneven distribution of strengths can benefit specialized agents.

Prompts can include other prompts and incorporate runtime information. A shared tone instruction, for example, can be reused by several subagents.

A tool can be a function, a prompt that invokes a model, or another agent. This lets one agent call a more specialized agent as a tool.

The specification models a conversation as two sides. A model can interact with a person, another model or deterministic code.

For example, one model can create an image and another can review it and request a correction. Schroeder describes this as a way to include evaluation in the interaction.

Subagents can be instantiated more than once, such as separate work and personal calendar agents sharing the same underlying definition.

Parent hooks allow an installed subagent to expose its capabilities to the parent. Hooks run deterministic code at defined lifecycle moments, including before a tool call.

Effects are code scheduled for a later time. A reminder or a later email are examples he uses to explain how a tool can schedule future work.

Each thread has its own messages, tools, subagents, key-value store and file system. A runtime can allow an agent to write and run code under specified restrictions.

The thread can expose endpoints, and the specification calls for agents to be packaged so others can install and run them with a compatible runtime.

The runtime contract specifies behavior without requiring one storage implementation. His team, for example, implements the file interface on top of a database in Cloudflare Durable Objects.

Schroeder says his team built a coding agent from smaller standard agents, then added another compatible agent without rebuilding the whole system.

The team is also releasing Standard Agent Builder, a runtime that can run locally or be deployed. Schroeder invites others to implement alternative runtimes against the specification.

In a demonstration, he gives a coding agent a PDF describing a battery warranty process. The coding agent creates prompts, model definitions and tools for that process.

He reports the generated agent took five minutes and 21 seconds to produce in the demonstration. Its tools include checking a battery, escalating an issue and offering a trade-in.

The builder shows the agent’s threads, tool calls, model, token usage and request details. The example chooses a replacement-shipping tool during the interaction.

The same agent can be exposed through a website interface or an MCP server, allowing another agent to interact with it, Schroeder says.

He asks developers to build agents and runtimes, test the specification and help improve it. He describes the proposal as an evolving ecosystem rather than a finished design.