---
title: What AIP is
description: Understand the problem AIP 1.0 solves, its semantic model, and its trust boundaries
kind: explanation
audience: evaluator
appliesTo: "1.x"
writingStandard: "aip-docs/1.0"
lastReviewedRevision: "97be86e9efedf07ecf1783b03800f683f107fb04"
---

# What AIP is

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
fits an integration and for developers who need its core mental model.

The normative wire protocol is AIP 1.0. Implementation details on this page
apply to version `1.0.0` of the Rust workspace at the source revision recorded
in page metadata. An implemented feature or a passing deterministic test does not
by itself qualify a deployment for production.

## The interoperability problem

Applications already expose APIs, tools, webhooks, queues, and agent-specific
protocols. Those interfaces can carry a request. They do not necessarily give
every participant the same model for capability discovery, identity, approval,
retry safety, cancellation, delegated authority, lifecycle state, or an
external outcome that is temporarily unknown.

AIP defines a semantic contract around that work. A participant can describe
what it offers, a caller can submit a typed action, and both sides can refer to
the same lifecycle and evidence objects. The application or external product
continues to own its domain logic and system of record.

## The AIP mental model

AIP answers five questions with explicit protocol objects:

| Question | Main AIP objects | What they establish |
|---|---|---|
| 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 |
| 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 |
| What may the operation do? | `CapabilityContract` | Declared side effects, idempotency, execution and retry support, data handling, credential requirements, approval, transactions, and compensation |
| What state is the work in? | `Session`, `Action`, `ActionStatus`, `Cancel`, `Event`, `StreamChunk` | Stable identifiers, lifecycle state, cancellation and streaming support, and terminal status |
| What was recorded? | `ActionResult`, `ReceiptChain`, `AuditEvent`, transaction views | Result data and bounded execution, receipt, audit, and transaction records |

A capability contract is a declaration that callers and runtimes can validate;
its presence is not proof that every deployment enforces the declaration. The
[capabilities and contracts](../concepts/capabilities.md) documentation owns the
detailed contract model.

## How work moves through AIP

A typical AIP exchange has five stages:

1. **Discover.** A participant returns a manifest containing its identity,
   capabilities, profiles, resources, and declared boundaries.
2. **Establish trust.** Before privileged work, a trusted edge authenticates the
   caller and binds protocol identity and tenant context to deployment-owned
   evidence.
3. **Submit.** The caller sends an `Action` inside an AIP `Envelope`, using
   stable identifiers for capability, message, session, and correlation where
   applicable.
4. **Govern and execute.** The receiving implementation validates the request,
   applies authorization and approval policy, and dispatches the action to a
   native handler or product connector.
5. **Observe.** The caller receives an acknowledgement, can follow lifecycle or
   stream events, and can query the final result and associated records.

The protocol does not require one physical topology. In the reviewed Rust
implementation, the gateway, runtime, storage, profiles, and product connectors
remain separate components with explicit responsibilities. Read
[How AIP works](how-aip-works.md) for the detailed lifecycle.

## Trust and data boundaries

The protocol carries identity, policy, and evidence data, but those values do
not create trust by themselves.

- **Identity:** `Principal`, `Envelope.from`, and `IdentityContext` contain
  claims and references. A deployment can treat them as authority only after a
  trusted edge authenticates the caller and resolves tenant membership.
- **Integrity and authorization:** the Rust implementation keeps signature and
  canonicalization support in `aip-crypto` and policy primitives in `aip-auth`.
  A valid signature protects message integrity; it does not grant permission to
  invoke a capability.
- **Credentials:** capability contracts describe credential requirements, and
  actions can carry credential references. Raw connector secrets remain at the
  connector or deployment boundary rather than in manifests, action metadata,
  protocol errors, or audit records.
- **Provider state:** an external product remains the source of truth for its
  side effects. Idempotency, retry, transaction, compensation, and
  reconciliation contracts describe how uncertainty is handled; they do not
  turn a non-idempotent provider into an exactly-once system.
- **Evidence:** lifecycle views, receipts, and audit events are scoped records.
  Conformance and qualification require separate procedures and exact artifact
  identities.

Read [Identity and trust](../concepts/identity-and-trust.md) for the full trust
model and [Conformance and qualification](../reference/conformance.md) for the
evidence boundary.

## Integration choices and trade-offs

AIP keeps one native semantic core while allowing different integration
surfaces:

| Surface | What it preserves | Boundary or trade-off |
|---|---|---|
| Native AIP | Native envelopes, capabilities, actions, lifecycle, and evidence objects without translation | The participant adopts the AIP model directly |
| Transport binding | Native AIP messages over HTTP, NATS, SSE, or WebSocket | The binding changes delivery behavior, not native message meaning |
| 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` |
| 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 |

Compatibility profiles improve access from existing protocol clients. Product
connectors preserve the external product boundary. Native AIP avoids a profile
mapping when an integration needs the native lifecycle model.

AIP is a fit when independently operated participants need shared semantics for
identity, governed mutations, lifecycle, recovery, or evidence. A direct API or
tool call is usually the smaller contract when one owner controls both sides and
none of those cross-system semantics is required.

## What AIP does not provide

AIP does not choose an agent model, planner, business workflow, or provider
outcome. It does not replace an application's database, authorization source,
policy engine, or secret manager. It also does not make a self-asserted identity
trustworthy, guarantee exactly-once external effects, or qualify an untested
build or deployment.

Profiles and connectors are integration boundaries, not alternative branches of
the native wire protocol. They translate external systems without adding their
product-specific objects to the AIP semantic core.

## Related pages

- [Quickstart](quickstart.md)
- [How AIP works](how-aip-works.md)
- [Profiles, transports, and connectors](../concepts/profiles-and-connectors.md)
- [Identity and trust](../concepts/identity-and-trust.md)
- [AIP 1.0 specification](../spec/AIP-1.0.md)