{
  "schemaVersion": "1.0",
  "title": "What AIP is",
  "description": "Agent Interoperability Protocol (AIP) gives agents, applications, tools, and workflows a shared contract for discovering capabilities and managing work that extends beyond a one-shot call. This page is for evaluators deciding whether AIP fi",
  "canonical": "https://getaip.org/docs/getting-started/what-is-aip",
  "route": "/docs/getting-started/what-is-aip",
  "source": "docs/getting-started/what-is-aip.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Start Here",
  "documentType": "Getting started",
  "language": "en",
  "revision": {
    "lastReviewedRevision": "97be86e9efedf07ecf1783b03800f683f107fb04",
    "documentationSourceRevision": "9192fef3695ad294994f2712f6d156241e5e92fb",
    "basis": "frontmatter"
  },
  "downloads": {
    "md": "/docs/download/getting-started/what-is-aip.md",
    "txt": "/docs/download/getting-started/what-is-aip.txt",
    "json": "/docs/download/getting-started/what-is-aip.json",
    "pdf": "/docs/download/getting-started/what-is-aip.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: What AIP is\ndescription: Understand the problem AIP 1.0 solves, its semantic model, and its trust boundaries\nkind: explanation\naudience: evaluator\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\n---\n\n# What AIP is\n\nAgent Interoperability Protocol (AIP) gives agents, applications, tools, and\nworkflows a shared contract for discovering capabilities and managing work that\nextends beyond a one-shot call. This page is for evaluators deciding whether AIP\nfits an integration and for developers who need its core mental model.\n\nThe normative wire protocol is AIP 1.0. Implementation details on this page\napply to version `1.0.0` of the Rust workspace at the source revision recorded\nin page metadata. An implemented feature or a passing deterministic test does not\nby itself qualify a deployment for production.\n\n## The interoperability problem\n\nApplications already expose APIs, tools, webhooks, queues, and agent-specific\nprotocols. Those interfaces can carry a request. They do not necessarily give\nevery participant the same model for capability discovery, identity, approval,\nretry safety, cancellation, delegated authority, lifecycle state, or an\nexternal outcome that is temporarily unknown.\n\nAIP defines a semantic contract around that work. A participant can describe\nwhat it offers, a caller can submit a typed action, and both sides can refer to\nthe same lifecycle and evidence objects. The application or external product\ncontinues to own its domain logic and system of record.\n\n## The AIP mental model\n\nAIP answers five questions with explicit protocol objects:\n\n| Question | Main AIP objects | What they establish |\n|---|---|---|\n| What can this participant do? | `Manifest`, `Capability`, `Resource` | Provider identity, available operations, input and output schemas, supported profiles, resources, and declared limits or security metadata |\n| Who is acting, and for whom? | `Principal`, `Envelope`, `IdentityContext`, delegation chain | Claimed sender and recipient, tenant and external-account context, human or service actors, credential references, and delegated scope |\n| What may the operation do? | `CapabilityContract` | Declared side effects, idempotency, execution and retry support, data handling, credential requirements, approval, transactions, and compensation |\n| What state is the work in? | `Session`, `Action`, `ActionStatus`, `Cancel`, `Event`, `StreamChunk` | Stable identifiers, lifecycle state, cancellation and streaming support, and terminal status |\n| What was recorded? | `ActionResult`, `ReceiptChain`, `AuditEvent`, transaction views | Result data and bounded execution, receipt, audit, and transaction records |\n\nA capability contract is a declaration that callers and runtimes can validate;\nits presence is not proof that every deployment enforces the declaration. The\n[capabilities and contracts](../concepts/capabilities.md) documentation owns the\ndetailed contract model.\n\n## How work moves through AIP\n\nA typical AIP exchange has five stages:\n\n1. **Discover.** A participant returns a manifest containing its identity,\n   capabilities, profiles, resources, and declared boundaries.\n2. **Establish trust.** Before privileged work, a trusted edge authenticates the\n   caller and binds protocol identity and tenant context to deployment-owned\n   evidence.\n3. **Submit.** The caller sends an `Action` inside an AIP `Envelope`, using\n   stable identifiers for capability, message, session, and correlation where\n   applicable.\n4. **Govern and execute.** The receiving implementation validates the request,\n   applies authorization and approval policy, and dispatches the action to a\n   native handler or product connector.\n5. **Observe.** The caller receives an acknowledgement, can follow lifecycle or\n   stream events, and can query the final result and associated records.\n\nThe protocol does not require one physical topology. In the reviewed Rust\nimplementation, the gateway, runtime, storage, profiles, and product connectors\nremain separate components with explicit responsibilities. Read\n[How AIP works](how-aip-works.md) for the detailed lifecycle.\n\n## Trust and data boundaries\n\nThe protocol carries identity, policy, and evidence data, but those values do\nnot create trust by themselves.\n\n- **Identity:** `Principal`, `Envelope.from`, and `IdentityContext` contain\n  claims and references. A deployment can treat them as authority only after a\n  trusted edge authenticates the caller and resolves tenant membership.\n- **Integrity and authorization:** the Rust implementation keeps signature and\n  canonicalization support in `aip-crypto` and policy primitives in `aip-auth`.\n  A valid signature protects message integrity; it does not grant permission to\n  invoke a capability.\n- **Credentials:** capability contracts describe credential requirements, and\n  actions can carry credential references. Raw connector secrets remain at the\n  connector or deployment boundary rather than in manifests, action metadata,\n  protocol errors, or audit records.\n- **Provider state:** an external product remains the source of truth for its\n  side effects. Idempotency, retry, transaction, compensation, and\n  reconciliation contracts describe how uncertainty is handled; they do not\n  turn a non-idempotent provider into an exactly-once system.\n- **Evidence:** lifecycle views, receipts, and audit events are scoped records.\n  Conformance and qualification require separate procedures and exact artifact\n  identities.\n\nRead [Identity and trust](../concepts/identity-and-trust.md) for the full trust\nmodel and [Conformance and qualification](../reference/conformance.md) for the\nevidence boundary.\n\n## Integration choices and trade-offs\n\nAIP keeps one native semantic core while allowing different integration\nsurfaces:\n\n| Surface | What it preserves | Boundary or trade-off |\n|---|---|---|\n| Native AIP | Native envelopes, capabilities, actions, lifecycle, and evidence objects without translation | The participant adopts the AIP model directly |\n| Transport binding | Native AIP messages over HTTP, NATS, SSE, or WebSocket | The binding changes delivery behavior, not native message meaning |\n| Compatibility profile | Existing MCP or A2A client behavior mapped to AIP | Only the correspondence defined by the selected profile is available; foreign DTOs remain outside `aip-core` |\n| Product connector | An existing product API and event model exposed as AIP capabilities | The product remains the domain authority; declared capabilities require separate implementation and test evidence |\n\nCompatibility profiles improve access from existing protocol clients. Product\nconnectors preserve the external product boundary. Native AIP avoids a profile\nmapping when an integration needs the native lifecycle model.\n\nAIP is a fit when independently operated participants need shared semantics for\nidentity, governed mutations, lifecycle, recovery, or evidence. A direct API or\ntool call is usually the smaller contract when one owner controls both sides and\nnone of those cross-system semantics is required.\n\n## What AIP does not provide\n\nAIP does not choose an agent model, planner, business workflow, or provider\noutcome. It does not replace an application's database, authorization source,\npolicy engine, or secret manager. It also does not make a self-asserted identity\ntrustworthy, guarantee exactly-once external effects, or qualify an untested\nbuild or deployment.\n\nProfiles and connectors are integration boundaries, not alternative branches of\nthe native wire protocol. They translate external systems without adding their\nproduct-specific objects to the AIP semantic core.\n\n## Related pages\n\n- [Quickstart](quickstart.md)\n- [How AIP works](how-aip-works.md)\n- [Profiles, transports, and connectors](../concepts/profiles-and-connectors.md)\n- [Identity and trust](../concepts/identity-and-trust.md)\n- [AIP 1.0 specification](../spec/AIP-1.0.md)\n",
    "text": "What AIP is\n\nAgent Interoperability Protocol (AIP) gives agents, applications, tools, and\nworkflows a shared contract for discovering capabilities and managing work that\nextends beyond a one-shot call. This page is for evaluators deciding whether AIP\nfits an integration and for developers who need its core mental model.\n\nThe normative wire protocol is AIP 1.0. Implementation details on this page\napply to version 1.0.0 of the Rust workspace at the source revision recorded\nin page metadata. An implemented feature or a passing deterministic test does not\nby itself qualify a deployment for production.\n\nThe interoperability problem\n\nApplications already expose APIs, tools, webhooks, queues, and agent-specific\nprotocols. Those interfaces can carry a request. They do not necessarily give\nevery participant the same model for capability discovery, identity, approval,\nretry safety, cancellation, delegated authority, lifecycle state, or an\nexternal outcome that is temporarily unknown.\n\nAIP defines a semantic contract around that work. A participant can describe\nwhat it offers, a caller can submit a typed action, and both sides can refer to\nthe same lifecycle and evidence objects. The application or external product\ncontinues to own its domain logic and system of record.\n\nThe AIP mental model\n\nAIP answers five questions with explicit protocol objects:\n\n| Question | Main AIP objects | What they establish |\n\n| What can this participant do? | Manifest, Capability, Resource | Provider identity, available operations, input and output schemas, supported profiles, resources, and declared limits or security metadata |\n| Who is acting, and for whom? | Principal, Envelope, IdentityContext, delegation chain | Claimed sender and recipient, tenant and external-account context, human or service actors, credential references, and delegated scope |\n| What may the operation do? | CapabilityContract | Declared side effects, idempotency, execution and retry support, data handling, credential requirements, approval, transactions, and compensation |\n| What state is the work in? | Session, Action, ActionStatus, Cancel, Event, StreamChunk | Stable identifiers, lifecycle state, cancellation and streaming support, and terminal status |\n| What was recorded? | ActionResult, ReceiptChain, AuditEvent, transaction views | Result data and bounded execution, receipt, audit, and transaction records |\n\nA capability contract is a declaration that callers and runtimes can validate;\nits presence is not proof that every deployment enforces the declaration. The\ncapabilities and contracts (../concepts/capabilities.md) documentation owns the\ndetailed contract model.\n\nHow work moves through AIP\n\nA typical AIP exchange has five stages:\n1. Discover. A participant returns a manifest containing its identity,\n   capabilities, profiles, resources, and declared boundaries.\n2. Establish trust. Before privileged work, a trusted edge authenticates the\n   caller and binds protocol identity and tenant context to deployment-owned\n   evidence.\n3. Submit. The caller sends an Action inside an AIP Envelope, using\n   stable identifiers for capability, message, session, and correlation where\n   applicable.\n4. Govern and execute. The receiving implementation validates the request,\n   applies authorization and approval policy, and dispatches the action to a\n   native handler or product connector.\n5. Observe. The caller receives an acknowledgement, can follow lifecycle or\n   stream events, and can query the final result and associated records.\n\nThe protocol does not require one physical topology. In the reviewed Rust\nimplementation, the gateway, runtime, storage, profiles, and product connectors\nremain separate components with explicit responsibilities. Read\nHow AIP works (how-aip-works.md) for the detailed lifecycle.\n\nTrust and data boundaries\n\nThe protocol carries identity, policy, and evidence data, but those values do\nnot create trust by themselves.\n• Identity: Principal, Envelope.from, and IdentityContext contain\n  claims and references. A deployment can treat them as authority only after a\n  trusted edge authenticates the caller and resolves tenant membership.\n• Integrity and authorization: the Rust implementation keeps signature and\n  canonicalization support in aip-crypto and policy primitives in aip-auth.\n  A valid signature protects message integrity; it does not grant permission to\n  invoke a capability.\n• Credentials: capability contracts describe credential requirements, and\n  actions can carry credential references. Raw connector secrets remain at the\n  connector or deployment boundary rather than in manifests, action metadata,\n  protocol errors, or audit records.\n• Provider state: an external product remains the source of truth for its\n  side effects. Idempotency, retry, transaction, compensation, and\n  reconciliation contracts describe how uncertainty is handled; they do not\n  turn a non-idempotent provider into an exactly-once system.\n• Evidence: lifecycle views, receipts, and audit events are scoped records.\n  Conformance and qualification require separate procedures and exact artifact\n  identities.\n\nRead Identity and trust (../concepts/identity-and-trust.md) for the full trust\nmodel and Conformance and qualification (../reference/conformance.md) for the\nevidence boundary.\n\nIntegration choices and trade-offs\n\nAIP keeps one native semantic core while allowing different integration\nsurfaces:\n\n| Surface | What it preserves | Boundary or trade-off |\n\n| Native AIP | Native envelopes, capabilities, actions, lifecycle, and evidence objects without translation | The participant adopts the AIP model directly |\n| Transport binding | Native AIP messages over HTTP, NATS, SSE, or WebSocket | The binding changes delivery behavior, not native message meaning |\n| Compatibility profile | Existing MCP or A2A client behavior mapped to AIP | Only the correspondence defined by the selected profile is available; foreign DTOs remain outside aip-core |\n| Product connector | An existing product API and event model exposed as AIP capabilities | The product remains the domain authority; declared capabilities require separate implementation and test evidence |\n\nCompatibility profiles improve access from existing protocol clients. Product\nconnectors preserve the external product boundary. Native AIP avoids a profile\nmapping when an integration needs the native lifecycle model.\n\nAIP is a fit when independently operated participants need shared semantics for\nidentity, governed mutations, lifecycle, recovery, or evidence. A direct API or\ntool call is usually the smaller contract when one owner controls both sides and\nnone of those cross-system semantics is required.\n\nWhat AIP does not provide\n\nAIP does not choose an agent model, planner, business workflow, or provider\noutcome. It does not replace an application's database, authorization source,\npolicy engine, or secret manager. It also does not make a self-asserted identity\ntrustworthy, guarantee exactly-once external effects, or qualify an untested\nbuild or deployment.\n\nProfiles and connectors are integration boundaries, not alternative branches of\nthe native wire protocol. They translate external systems without adding their\nproduct-specific objects to the AIP semantic core.\n\nRelated pages\n• Quickstart (quickstart.md)\n• How AIP works (how-aip-works.md)\n• Profiles, transports, and connectors (../concepts/profiles-and-connectors.md)\n• Identity and trust (../concepts/identity-and-trust.md)\n• AIP 1.0 specification (../spec/AIP-1.0.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "f1218695ad394672caa8481e6771344d0050ec8a01b5f82e317256380171d5ce"
  }
}