An agent SDK that ships its own reference.
Most SDKs leave your coding agent guessing. a2a ships the answer: a2a init writes an AGENTS.md — the cross-tool standard — plus a CLAUDE.md and an invokable build skill, so Claude Code, Codex, and Cursor all open your project already fluent in the platform. One reference, every tool, real code from the first prompt.
$ a2a init my-agent+ my-agent/AGENTS.md # source of truth+ my-agent/CLAUDE.md # imports @AGENTS.md+ my-agent/.claude/skills/build-a2a-agent/SKILL.md+ my-agent/agent.py # starter @a2a.tool agent# one reference — every coding agent reads it
One command, every coding agent fluent
Run a2a init
The scaffold writes AGENTS.md as the source of truth, a CLAUDE.md that imports it, and a .claude/skills/build-a2a-agent playbook — alongside your starter agent.
Open in any tool
Codex and Cursor read AGENTS.md at the repo root; Claude Code reads CLAUDE.md and can invoke the build skill. All fluent in the SDK, no setup.
Build and deploy
Your coding agent writes @a2a.tool skills against the real API and verifies with a2a validate and a2a card, then a2a deploy ships it with proof.
Why an agent-native SDK converts a first-time build
The reference in the repo is the difference between a coding agent that ships your agent and one that hallucinates its way to a broken deploy.
No hallucinated APIs
The shipped reference is the source of truth, so coding agents write against the real decorator, RunContext, and grant APIs instead of inventing them.
One reference, no drift
CLAUDE.md and the build skill defer to AGENTS.md, so every tool and every teammate builds against the exact same instructions.
Policy baked in
The golden rules ship with the project — use ctx.llm, never read provider keys, durable files through the workspace backend — so generated code is safe by default.
Verified, then deployed
The reference teaches the full CLI loop, so the coding agent runs a2a validate and a2a card before a2a deploy — a broken agent never reaches the build.
“The best SDK docs are the ones your coding agent never has to go looking for.”
Before you deploy.
What is an AGENTS.md-native SDK?
It's an SDK that ships its own instructions for coding agents. When you run `a2a init`, the scaffold writes an AGENTS.md — the cross-tool standard file for agent instructions — plus a CLAUDE.md that imports it and an invokable build skill. So the SDK reference lives in your project, and any coding agent that opens it already knows how to build on the platform.
Why does shipping the reference in the repo matter?
Because coding agents are only as good as the context they have. Point one at an unfamiliar SDK and it invents plausible-but-wrong APIs. When the reference ships in the project — real decorator options, the ctx.llm rule, the workspace-backed file paths, the deploy flow — the coding agent writes against the actual SDK from the first prompt, then verifies before deploy.
Does one reference really cover Claude Code, Codex, and Cursor?
Yes. AGENTS.md is the single source of truth that Codex and Cursor read at the repo root, and Claude Code gets a thin CLAUDE.md that imports it plus a .claude build skill. They all defer to the same file, so your whole team builds against one consistent reference no matter which tool they prefer.
What does the reference actually teach the coding agent?
The agent anatomy (the A2AAgent class and @a2a.tool skills), the four things you wire (the LLM via ctx.llm, durable files, sandboxed execution, DeepAgents), the golden rules (never read provider keys, write durable files through the workspace backend), auth, and the CLI workflow — a2a dev, a2a validate, a2a card, a2a deploy — so the agent can build and verify end to end.
Ship the SDK your coding agent already understands.
a2a init scaffolds a project whose reference every coding agent reads — AGENTS.md, CLAUDE.md, and a build skill — and a2a deploy ships the result with a managed Postgres database, an MCP server, an API, a frontend, and an Ed25519-signed receipt for every run. The whole agent app, built with the tools you already have.