AIP-2: AIP Template

How to use this template

1. Copy this file to AIPS/aip-XXXX.md in github.com/agentproto/specs.
2. Replace the frontmatter values below.
3. Fill in every required body section — keep the section headings exactly as shown so the registry tooling can parse them.
4. Open a PR. Editors will assign a real number.

See AIP-1 for the full submission process and lifecycle.

Template — frontmatter

---
aip: XXXX                                   # Editors assign — leave as XXXX
title: <short, descriptive title>
author: <Your Name <your@email>>
status: Draft                                # Always start here
type: Meta | Schema | Core                  # Pick exactly one
created: YYYY-MM-DD
requires: [<aip>, <aip>]                    # Optional — list AIPs this depends on
replaces: <aip>                              # Optional — only if this supersedes a prior Final AIP
discussions-to: <github discussion URL>     # Optional but encouraged
ref-impl: <repo URL>                         # Required for Schema/Core
---

Template — body

Copy the sections below verbatim. Required sections must be present even if their content is "Not applicable" (with a one-line justification).

Abstract

Two to three sentences. What this AIP defines. A reader scanning the registry should be able to grasp the scope from the abstract alone.

Motivation

Why does this exist? What problem does it solve that existing specs do not? Reference prior art (MCP, A2A, AGNTCY, AITP, internal designs) and explain the gap.

Specification

The normative section. Define the schema, contract, or protocol with enough precision that an independent implementer could build it without asking the author questions.

Use whatever formalism fits — Zod schemas, TypeScript types, JSON Schema, BNF, prose. Be explicit about MUST / SHOULD / MAY (RFC 2119 keywords).

Rationale

Why these design choices? What alternatives were considered and why were they rejected? This section is where you defend non-obvious decisions to future readers (and yourself in 18 months).

Reference Implementation

Link to working code. For Schema AIPs, this is typically a parser and validator. For Core AIPs, this is a runtime adapter or full reference implementation.

If the reference impl is not yet ready: state that explicitly and link to the in-progress work.

Backwards Compatibility

Required if this AIP has replaces set. Document:

• What breaks
• Migration path for implementers of the prior AIP
• Whether the prior AIP is immediately Superseded or has a deprecation window

If not applicable, write "Not applicable — this AIP introduces a new spec."

Security Considerations

Required for Core; recommended for Schema; optional for Meta.

Document the threat model: what does an adversary controlling each input look like? What invariants does the spec rely on? What happens at the trust boundary?

If you genuinely don't see a security surface, say so and explain why — "This is a static file format with no execution semantics" is a valid answer.

Style notes for AIP authors

• Be concrete. Replace "the system" with "the runtime"; replace "the data" with the actual field name. Vague specs become contested specs.
• Use small examples. A 5-line YAML example beats two paragraphs of prose. Show the happy path, then enumerate edge cases.
• Cite prior AIPs by number. Write AIP-7, not "the governance AIP". The number is permanent; the title may evolve.
• Don't apologize. AIPs are reference documents — write declaratively. "The runtime MUST X." not "We think it would be nice if the runtime could X."
• Resist scope creep. One AIP, one decision. If you find yourself defining two things, split them — cross-reference via requires.