Agent Protocol
Open numbered standards for the AI-agent ecosystem. Filesystem-first; markdown is the program. Specifications for what agents are, what they remember, what they do, and what they're allowed to do — composable across runtimes.
Agent Protocol
AIPs (Agentproto Improvement Proposals) are the numbered specifications that make up Agent Protocol — open standards for the AI-agent ecosystem. They specify portable file formats and runtime contracts for the layer where context lives, roles are defined, and memory is structured — the layer between transport (MCP) and frameworks (LangChain, Mastra, Claude Code, …).
The project is agentproto (the slug used everywhere — repo, npm scope
@agentproto/*, domain agentproto.sh). Agent Protocol is its
human-readable name. AIP follows the convention BIP, EIP, and PEP set:
the project's first letter, then Improvement Proposal.
Text is the new code
Build a serious agent system and you'll hit the same wall everyone hits. You give an agent context, a role, a set of instructions. It works. You try to take what you've learned — not the prompt, the actual understanding — to a different project, a different runtime, a different team. You start over.
Not because the agent is dumb. Because there's no shared format for telling it what it already knows how to do.
Code freezes intent at compile time. Text re-interprets it on every
run. A LESSON.md that says "when a client hesitates on price,
validate the problem before defending value" works for a SaaS sales
agent, a support agent, and a negotiation agent — same file, zero
adaptation. Rules written as code stay coupled to the runtime that
compiled them. Rules written as markdown for an agent to read are
intrinsically cross-context.
The primitives an agent runs on — its operator profile, its accumulated lessons, its governance policy, its work backlog — are already generalisable by nature. What's missing isn't capability. It's a shared format that lets these files travel between systems. Without that, the generalisation stays trapped in whichever stack happened to author it.
AIPs are that format.
What this is not
Not an MCP replacement. MCP solves tool transport — how an agent calls an external tool. AIPs specify the agent's own structure: who it is, what it remembers, what it's allowed to do. The two compose; they don't overlap.
Not an A2A replacement. A2A solves agent-to-agent communication. AIPs specify how each agent understands itself and its context before it talks to anyone.
Not a runtime replacement. Claude Code, Cursor, Mastra, Guilde — these continue to be the runtimes. AIPs define the formats those runtimes can implement to become interoperable.
The layer AIPs occupy is the one currently empty: above transport, below frameworks. The layer where context lives.
The layered model
Each AIP defines a single piece of the stack — a file format, a runtime contract, a composition primitive. They reference each other (AIP-9 requires 3, 6, 7), build on each other, and graduate through a clear lifecycle: Draft → Review → Final → Superseded.
Below, the registry organised as 8 semantic layers. Each section opens with the question that layer answers, then lists the AIPs that live there with their status and dependencies.
Process — How does the standard itself evolve?
How AIPs are proposed, reviewed, and graduated. Read these first if you want to contribute a spec.
| # | Title | Status | Requires |
|---|---|---|---|
| AIP-1 | Purpose & Process | Final | — |
| AIP-2 | AIP Template | Final | — |
| AIP-40 | EXTENSION.md — agentextension/v1 (custom doctype declarations) | Draft | — |
Primitives — What building blocks does everything else compose with?
Small, reusable pieces. Every other layer references at least one of these — collections, refs, IO blocks, secrets, process boundaries.
Identity — Who acts?
How an agent describes itself: its profile, capabilities, persona. The shell that the rest of the layers attach to.
Memory — What does the agent remember between runs?
Knowledge an agent maintains, lessons it distils from experience, prompt overlays it carries forward. Memory turns one-shot agents into ones that compound.
Work, Org & Governance — What gets done, where, and under what rules?
Companies, agencies, work items, offices, assemblies — and the governance layer that records approvals and audit trails. The coordination substrate.
Capabilities — What can the agent do?
Skills, tools, workflows, intents — the declared surface of what an agent or its tools expose. Intent vs implementation: capabilities declare intent.
Drivers — How are capabilities actually implemented?
The DRIVER supertype and its concrete subtypes (CLI, HTTP, MCP, SDK). One tool, many drivers; the routing layer that connects intent to execution.
Surfaces — What does the agent produce or read?
Visual and code surfaces: design tokens, canvas templates, code workspaces. The artifacts agents author or consume on the human-facing edge.
How standards evolve here
The model is the same one that built the internet and most working crypto stacks:
- BIPs — Bitcoin Improvement Proposals
- EIPs — Ethereum Improvement Proposals
- RFCs — Internet Engineering Task Force standards
- PEPs — Python Enhancement Proposals
The process is in AIP-1. Every new AIP starts from the template in AIP-2. Specs land via PR; merged drafts become the registry's canonical home; promotion to Review and Final follows the lifecycle in AIP-1.
This is not a foundation, a community, or a vendor catalog — it's a process. Like every numbered-proposal system before it.
Submit an AIP
- Read AIP-1 for the full process.
- Copy AIP-2 as your starting template — it ships the seven required sections (Abstract, Motivation, Specification, Rationale, Reference Implementation, Backwards Compatibility, Security Considerations).
- Open a PR against
github.com/agentproto/agentproto
with the new file at
specs/aip-XXXX.mdxandlayer:set in the frontmatter so it lands in the right registry section.
Related standards
AIPs aren't built in isolation. The Related Standards & Initiatives page lists the peer specifications (MCP, A2A, AGNTCY, AITP, Anthropic Skills, OTel GenAI, W3C VCs, OpenAPI, DTCG, Olas, Fetch.ai, …) that AIPs defer to, build on, or run adjacent to.