AIF and A2A

1The short answer

A2A is the delivery layer for agent-to-agent work: discovery through Agent Cards, three transport bindings, a nine-state task lifecycle, streaming, webhooks, and enterprise authentication. It answers which agent can do this, how do I reach it, and what is the task doing now.

AIF is a payload format. It answers what exactly is being asked, under which enforceable limits, and how will we know the result is acceptable. It specifies no transport, no discovery, and no lifecycle, because A2A already does those well.

If you are already sending A2A tasks and your problem is that the receiving agent sometimes does things it should not, or returns work nobody can objectively evaluate, that gap is what a frame fills.

flowchart TB
    subgraph A2A["A2A · the envelope and the pipe"]
        direction TB
        DISC["Agent Card<br/>/.well-known/agent-card.json"]
        TRANS["JSON-RPC · gRPC · HTTP+JSON"]
        LIFE["Task lifecycle<br/>9 states, streaming, webhooks"]
        AUTH["OAuth2 · mTLS · OIDC"]
    end
    subgraph MSG["A2A Message"]
        direction TB
        TP["TextPart<br/>prose for the model"]
        DP["DataPart<br/>the intent frame"]
    end
    subgraph AIF["AIF · what is inside the envelope"]
        direction TB
        C["constraints<br/>enforced before invocation"]
        AC["acceptance_criteria<br/>typed checks"]
        IT["intent_type<br/>dispatch"]
    end
    A2A --> MSG
    DP --> AIF
    class DISC,TRANS,LIFE route
    class AUTH enforce
    class TP model
    class DP context
    class C enforce
    class AC check
    class IT route

2Different questions

Nothing in the top half belongs in a frame. Nothing in the bottom half is in scope for A2A, and that is a deliberate choice rather than an oversight — see the next section.

3Opaque execution, and why the gap exists

A2A lists opaque execution among its guiding principles: agents collaborate based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations. The specification is explicit that agents interoperate without access to each other's internal state, memory, or tools.

That principle is correct for a protocol spanning organisational boundaries, and it is precisely why A2A does not specify token ceilings, tool grants, or completion criteria. Those are internal matters, and A2A treats the remote agent as a black box on purpose.

This is why the two compose rather than collide. A2A deliberately declines to describe the inside of the box; a frame describes the contract on the outside of it.

4Where they genuinely overlap

Three places. Pretending otherwise would be dishonest, and in two of them A2A is the better answer.

4.1 Agent Card and Skills

This overlap has been resolved rather than described. An earlier AIF draft specified a capability manifest at a well-known path. It has been withdrawn, and discovery is now explicitly out of scope for AIF in the same way transport is.

The Agent Card is the better answer by a wide margin: security schemes, transport interfaces, signing, extended cards behind authentication, and caching semantics. Reproducing a fraction of that would have earned nothing but an integration burden.

So the mapping is one-directional. An A2A Skill declares what an agent can do, and AIF has no counterpart at all — deliberately. A frame has no A2A counterpart either, and that is the gap this project addresses.

A Skill is authored once and cached; it is identical for every caller and every invocation. It cannot express that this particular call gets 80 tokens and one cent, because per-request terms have no business in a cached discovery document. That is what a frame carries.

Declare each capability as a Skill, using the same name the frame addresses:

{
  "id": "research.summarize",
  "name": "Executive incident summary",
  "description": "Condenses incident artifacts into an executive summary.",
  "tags": ["research"],
  "inputModes": ["application/vnd.aif+json", "text/plain"],
  "outputModes": ["application/vnd.aif+json", "text/plain"]
}

The dual inputModes is the incremental adoption path. A caller that knows nothing about frames sends a plain text part and is served normally; one that sends a frame gets enforced limits and a validated result.

4.2 Task rejection and refusal frames

A2A has a REJECTED task state, described as the agent deciding not to perform the task, either at creation or later. That is real overlap with refusal at admission.

The difference is granularity. REJECTED tells the caller that the agent said no. A refusal frame carries which terms were unacceptable, as stable codes, plus whether the sender should amend the request or accept that the work was not achievable. If the distinction between "your request was inadmissible" and "the work could not meet the standard" does not matter to your callers, A2A's state is enough.

Use both: set the task state to REJECTED and return the refusal frame as the reason.

4.3 Task state and frame outcome

A2A owns the lifecycle. A frame's outcome maps onto it rather than duplicating it:

5What only A2A does

This list is long, and none of it is on the AIF roadmap. Duplicating any of it would be a mistake.

• Three protocol bindings — JSON-RPC 2.0, gRPC, HTTP+JSON/REST — with functional-equivalence requirements between them.
• Enterprise authentication: OAuth 2.0 flows, OpenID Connect, mutual TLS, API keys, plus in-task authorization when an agent needs credentials mid-task.
• A nine-state task lifecycle with defined terminal and interrupted states.
• Streaming with ordering guarantees, multiple concurrent subscribers per task, and resubscription after disconnection.
• Push notification webhooks with authentication, retry, and delivery guarantees for long-running work.
• Task listing with cursor-based pagination and filtering.
• Agent Card signing and canonicalisation, extended cards behind auth, caching rules.
• Multi-tenancy routing, protocol version negotiation via the A2A-Version header, registered media type and well-known URI.
• SDKs, a formal extension governance process, and Linux Foundation stewardship.

A2A is a production protocol. AIF is a schema and an argument.

6What only AIF adds

Correspondingly short, because it is one idea applied consistently.

7Using them together

A2A messages carry Part objects, one of which holds arbitrary structured JSON. A frame goes in a data part alongside the human-readable text part.

{
  "message": {
    "messageId": "msg-8f21",
    "role": "ROLE_USER",
    "extensions": ["https://agentintentframe.org/ext/v0.1"],
    "parts": [
      { "text": "Summarise incident 4471 for the executive committee." },
      {
        "data": { /* the intent frame */ },
        "mediaType": "application/vnd.aif+json"
      }
    ]
  }
}

A2A defines a formal extension mechanism: extensions are declared in the Agent Card, identified by URI, and negotiated per request through the A2A-Extensions service parameter. The specification notes that extensions can be used to strongly type metadata values — which is exactly what a frame is.

Declared on the receiving agent:

"capabilities": {
  "extensions": [
    {
      "uri": "https://agentintentframe.org/ext/v0.1",
      "description": "Accepts Agent Intent Frames and returns typed result or refusal frames.",
      "required": false
    }
  ]
}

Marking it required: false is the right default: a caller that knows nothing about frames sends a plain text part and is served normally. A caller that sends one gets enforced limits and a validated result. Adoption is incremental and nothing breaks.

On the return path, put the result or refusal frame in a data part of the task's artifact, and set the task state per the mapping in §4.3.

8Do you need both?

The honest default: adopt A2A first, and add frames at the specific boundaries where you need enforcement or checkable completion. Adopting AIF everywhere before you have felt either problem is overhead without a return.

9And MCP, and AG-UI

The four occupy different edges, and the distinctions are crisp:

AIF is the only one of the four that is not a wire protocol, which is why it sits inside one rather than beside it. A production system might use all four: A2A routes the task, a frame states its terms, MCP gives the receiving agent its tools, and AG-UI shows a person what is happening.

Specification → · Library adapters → · A2A specification →