Agents are deterministic software that harnesses the non-deterministic results produced by models in pursuit of a desired objective.
1. Agents should be vendor-agnostic. 2. Agents should be domain-specific. 3. Agents should be coupled to a model. 4. Agents should be composable. 5. Agents should be portable. ## Why Standard Agents?Because everyone is building agents, but none of us can share them. We believe agents need a standards movement led by practitioners like you — much like the one that grew the early web into the rich ecosystem that we all enjoy today.
This specification covers every aspect of Standard Agents and the requirements for their runtime. Every part of a Standard Agent is defined in code, allowing your agents to be versioned, packaged, shared, and installed.
### Core DefinitionsAdapters that translate requests into a provider’s native format and transform responses back.
The LLM to use, with its capabilities, pricing, and fallback chain.
Capabilities that a model can call: functions, prompts, and agents.
Scheduled side effects, such as delayed notifications and background cleanup, that run outside normal tool execution.
System instructions, a model reference, available tools, and behavior for each model request.
Functions that take one side’s turns by running code in place of a model.
Two sides in a conversation, each backed by a human, a prompt, or a handler, with rules for when turns and sessions stop.
Agents composed as children, each running in its own isolated thread.
Instances of an agent, each with its own identity, storage, and lifecycle.
A proposed scope for durable values, endpoints, event streams, and credential grants owned by a runtime principal.
Interception points in the execution lifecycle for validation, transformation, and side effects.
Type-safe references to models, prompts, agents, and tools through TypeScript declaration merging.
The ordered, persistent conversation history of a thread.
Isolated thread storage for files and images that persists across executions.
On-demand JavaScript or TypeScript in an isolated sandbox with explicitly bridged capabilities.
An optional capability for live byte streams between agent code and its host.
Step counts, cancellation, and run status while a thread is active.
Named, typed questions evaluated against context without advancing the conversation.
HTTP APIs for operations on a specific thread.
The execution environment that assembles context, executes tools, enforces stop conditions, and persists state.
Self-contained npm packages that make agents installable and distributable.
Agents, prompts, models, tools, and hooks are all written in TypeScript. It is the default language of the web, it has types, and it can run anywhere, which makes it a strong fit for tools.
This defined execution environment lets tools run directly in the runtime and access thread state, with no separate server to operate. Tools install with their agent through a package manager and behave the same way in every spec-compliant runtime.
No. A runtime can be written in any language, as long as it can execute TypeScript.
Skills and MCP have real uses and can add value to an agent. On their own, they do not make an agent composable or shareable. The specification defines the complete agent, including its model, prompt, tools, and hooks, so that it can be packaged, installed, and composed with other agents.