Driver family
The DRIVER family — AIP-30 abstract supertype plus its concrete subtypes (CLI, and the planned HTTP/MCP/SDK). Catalog page that groups related AIPs whose ordinal proximity isn't enforced by monotonic numbering. The family is the navigation surface; numbers are identifiers.
Driver family
The DRIVER family is the layer that binds abstract TOOL contracts
to concrete backends. AIP-30 defines the supertype every driver
shares (identity, kind, install, auth, sandbox primitive, region,
policy tags, multi-tool implements[]); each subtype AIP adds
kind-specific fields on top.
This page exists because AIP numbering is monotonic at PR-open time (per AIP-1) — the family's members may not end up adjacent in the registry, and that's fine. The family page is the navigation surface; numbers are identifiers.
Provider family
AIP-30 declares the abstract DRIVER.md supertype. Each subtype below specialises it for one transport kind (cli, http, mcp, sdk, builtin).
How members compose
Each subtype is a specialisation: it inherits the universal frontmatter from AIP-30 DRIVER and adds its own kind-specific block.
| Layer | Universal | Subtype-specific |
|---|---|---|
| Identity | id, name, description, version, kind | — |
| Tool dispatch | implements[] (per-tool ref + mapping + narrowing) | per-kind metadata.<kind> (argv / endpoint / mcp_tool_name / function_ref) |
| Lifecycle | install, version_check | (CLI/SDK use; HTTP/MCP/builtin omit) |
| Auth | auth (state, login, refresh, expiry) | — |
| Sandbox | network.egress | CLI adds sandbox.fs/exec/tty and output.exit_codes/json_flag |
| Routing policy | region, policy_tags, cost_override | — |
Adding a new subtype (e.g. a future kind: gRPC) means writing a new
AIP that references AIP-30 in its requires: chain and declares the
gRPC-specific fields. The supertype doesn't grow.
See also
- AIP-30 — DRIVER.md — abstract supertype
- AIP-29 — CLI.md —
kind: clispecialisation - AIP-63 - BROWSER.md - profile over DRIVER of any
kindfor browsers that agents drive - AIP-14 — TOOL.md — abstract contracts the family implements
- AIP-28 — INTENT.md — user-facing layer above TOOL
AIP-64: PACK.md, pack/v1 (the installable capability bundle: plugin, apps, knowledge, playbook, pricing)
Names the pack, the commercial assemblage that ships a plugin (built inline from `./skills/` or merged from published `@agentproto/skill-pack-*` includes) together with zero or more AIP-53 apps, a knowledge workspace selection, an optional playbook to generate, legacy pricing data, and non-technical blockers, as a first-class doctype. Fixes the PACK.md frontmatter (`pack/v1`), every cross-field rule a conformant parser enforces, the two authoring paths (`definePack` and `parsePackManifest`) over one shared zod schema, the frozen `PackHandle` with its derived `status` (`planned | assembling | ready | gated`), the `aip://64/<name>[@version]` artifact-ref grammar and the git pin grammar reused from AIP-62, the `agentproto-pack-digest/v1` content digest over the PACK.md and each declared app's APP.md source, and the installation contract (apps install through AIP-42 `app_install`, the plugin installs through the skill install verb, knowledge resolves at query time, the playbook generates on demand, and re-applying a pack replaces it, never duplicates it).
Propose an AIP
How to submit a new Agent Improvement Proposal — submission workflow, editorial process, review timelines, number assignment, and what makes an AIP land.