What AIP Is
AIP is a protocol for running useful work across agents and applications when a simple tool call is not enough.
It answers five practical questions:
- What can this system do? A manifest publishes typed capabilities, resources, supported transports, and security requirements.
- Who is asking? A trusted identity context preserves the human, service, tenant, external account, and delegated authority involved in the request.
- What is allowed to happen? A capability contract declares side effects, data sensitivity, retry safety, approval rules, and transaction behavior.
- What is happening now? Every action has a durable lifecycle that can be queried, streamed, cancelled, resumed, and recovered.
- What actually happened? Events, receipts, audit records, and transaction state provide operational and compliance evidence.
The Problem AIP Solves
Applications already expose APIs, tools, webhooks, queues, and agent-specific protocols. Those interfaces are useful, but they usually describe only how to send a request. They do not give every participant the same answers for approval, retries, cancellation, tenant boundaries, delegated authority, or a provider outcome that is temporarily unknown.
AIP adds a shared semantic layer. A restaurant booking, refund, CRM update, or agent delegation becomes a typed action with an identity, policy, lifecycle, and evidence trail. The underlying application remains responsible for its domain logic; AIP makes that logic interoperable and governable.
AIP Is One Protocol, Not Several Product Branches
AIP has one native semantic model. Products join it through connectors, and existing protocols join it through compatibility profiles.
- A connector maps a product’s real API and events to AIP capabilities and lifecycle events.
- A compatibility profile maps another protocol to the same AIP semantics.
- A transport binding carries native envelopes over HTTP, NATS, SSE, or WebSocket without changing their meaning.
There is no separate enterprise edition of the wire model. A simple read-only tool can publish a small capability contract, while a payment or identity operation publishes the full approval and transaction contract. Both are AIP.
Relationship to MCP
MCP is a first-class compatibility profile, not a second runtime. Existing MCP clients can discover and call AIP-backed tools through MCP stdio or Streamable HTTP. The AIP gateway translates those calls into native actions and projects native lifecycle data back into MCP responses, notifications, and tasks.
MCP remains useful for broad client compatibility. Native AIP is the stronger contract when a workflow needs durable state, enterprise identity, approval, transactions, delegation, or operational query APIs.
Relationship to Agent-to-Agent Protocols
AIP models delegation natively as a parent-child action graph. An A2A-facing endpoint may be exposed by a compatibility profile, but A2A objects do not enter the AIP semantic core. The same separation applies to product-specific task and conversation models.
Who Uses AIP
| Reader | What AIP provides |
|---|---|
| Application developer | One typed contract for calling tools and workflows |
| Agent developer | Discovery, streaming, cancellation, and remote delegation |
| Product integrator | A connector SDK with consistent identity and error rules |
| Platform team | Durable execution, recovery, policy, and tenant isolation |
| Security team | Trusted identity, least privilege, approvals, and replay control |
| Operations team | Query APIs, metrics, events, receipts, and audit evidence |
What AIP Does Not Do
AIP does not replace an application’s business logic, database, authorization source, or secret manager. It does not make a non-idempotent provider exactly once, and it does not make an untrusted identity claim trustworthy. A production deployment must connect AIP to real identity, policy, storage, and provider boundaries.
Next, run the Quickstart or read How AIP Works.