open specs · typescript runtime · any library
Composable primitives for composable agents.
Tools, skills, agents, knowledge, workflows, policies — every part of an agent defined once, as a file with a declared contract. Use them with Mastra, the Vercel AI SDK, MCP, or your own stack. Open numbered specs; a TypeScript runtime that loads, runs, and projects them.
Apache-2.0 · running coding agents? → the CLI
one contract, many hosts
Define once. Run in any framework.
A tool declares its contract — schemas, side-effects, approval class. Implementations are drivers: in-process, CLI, HTTP, MCP. The same tool projects into whichever host you build with, so a new framework is a projection, not a rewrite.
import { defineTool } from "@agentproto/tool"
import { implementTool } from "@agentproto/driver"
import { z } from "zod"
const greet = defineTool({
id: "greet",
inputSchema: z.object({ name: z.string() }),
outputSchema: z.object({ greeting: z.string() }),
})
const impl = implementTool(greet, async ({ input }) => ({
greeting: `Hello ${input.name}`,
}))// Mastra
toMastraTool(impl)// Vercel AI SDK
toAiSdkTool(impl)// MCP / CLI / HTTP
serveTool(impl)the component map
Everything an agent is, as files with contracts
Every serious agent system converged on the same shape — a folder of markdown files the agent reads, writes, and runs from. The AIP specs give that shape a shared vocabulary: one numbered spec per primitive, aligned with the de-facto standards (SKILL.md as Anthropic shipped it, AGENTS.md, CLAUDE.md), not forks of them.
Identity
Who acts?
OPERATOR · IDENTITY · PERSONA
Memory
What does the agent remember?
KNOWLEDGE · LESSON · PLAYBOOK
Capabilities
What can it do?
SKILL · TOOL · WORKFLOW · INTENT
Drivers
How is it actually implemented?
DRIVER · CLI · HTTP · MCP · SDK
Work & governance
What gets done, under what rules?
COMPANY · GOVERNANCE · WORK · OFFICE
Surfaces
What does it produce or read?
DESIGN · CANVAKIT · CODE
52 numbered specs, 8 layers · browse the registry →
why files, why contracts
Agents that improve their own components
Because every component is a file with a declared contract, an agent can extend itself with ordinary file operations — no research project, no plugin API. Self-modification becomes a write_file call the runtime can validate and you can gate.
Add a tool
Write a TOOL.md contract and a DRIVER.md implementation to disk. The runtime picks them up.
Swap a provider
One tool, many drivers — add a second driver and update policy. No caller changes.
Fix a bug in itself
Edit the driver body, rerun the contract's validators, ship — gated by the same checks as any other change.
the human gateway
Primitives need a place to run. And someone needs to see them.
The agentproto CLI + daemon run your coding agents in the background — Claude Code, Codex, open models, all in one list, terminal or web — and check each one's work before it's committed. Built entirely on the primitives above.
npm i -g @agentproto/cli
agentproto serveerrata, in advance
What's real vs. roadmap
The tool/driver primitives, the CLI, nine agent adapters, and the orchestration/supervision layer (nested orchestration, policy gates, fan-in monitoring, MCP composition) are live and used hands-on. The wider AIP spec family beyond that is an open roadmap — most of those packages are early scaffolding, not finished implementations. We'd rather say that plainly than have you find out the hard way.
Full features breakdown →