« Phase 03 · Warmup · Track Overview

Hitchhiker's Guide — A2A, ACP & Agent Interop

The 30-second mental model

MCP: what tools do I have. A2A: who else can do this, and how do I hand it to them.

Delegated work is long-running, artifact-producing, cancellable, interactive, and across a trust boundary — five reasons a request/response tool call cannot hold it. So A2A makes the task a first-class, addressable, long-lived object.

Then it stops. Depth, cycles, tenancy, classification, auth and the identity chain are yours. And your kernel should speak none of these protocols — A2A, ACP and each hyperscaler fabric are edge adapters over one internal task model.

Tool call vs delegated task

Tool callDelegated task
Durationsecondsminutes to hours
Resulta return valueartifacts with identity
Interactionone-shotcallee can ask (input-required)
Controlruns to completioncancellable
Boundaryyour trust domainanother team, tenant, or vendor

The lifecycle

submitted ──► working ──► completed ✔
    │            │  ▲
    │            │  └── input-required / auth-required
    ├──► rejected ✔    (the callee needs info / a credential)
    └──► canceled ✔ / failed ✔

submitted → completed is illegal: a completion with no working state is a completion with no evidence. rejectedfailed: "I won't" and "I broke" are different rows in every report.

The five undefined things (memorize this list)

GapControl
Delegation depthmax chain depth, enforced at admission (4 is a sane start)
Cyclestarget already in the chain → refuse; identify by registered identity, not endpoint
Tenancymay this caller reach that agent at all
Classificationmay this data go there — downhill only
Authenticationrefuse a card offering only an API key
(and) the identity chainderived from verified caller context, never the message body

One-liners

  • contextId groups tasks; taskId identifies one. The context is the join key across trace, cost, audit and evidence.
  • role: "user" is the calling agent — inherited chat vocabulary; read it as "the party being served."
  • data parts are the point. A typed screening result beats a paragraph a caller must parse.
  • Artifacts ≠ history. The auditor wants the report, not the chat.
  • One generator, three modes. send = drain the stream; stream = yield; push = webhook.
  • A callback URL is an SSRF. Allow-list the host, require a token, control egress.
  • Cards are prompt surface. Pin the reviewed text; don't trust what the endpoint serves today.
  • Delegate across an ownership boundary, not a task boundary.

Vocabulary

Agent Card · the discovery document. Skill · the unit of discovery, with tags. Task · the unit of delegated work. Artifact · a durable output. Part · text / file / data. contextId · groups related tasks. Push notification config · caller-supplied webhook. Delegation chain · the ordered list of agents a request passed through. Edge adapter · the per-protocol translator around a protocol-agnostic core.

War stories

The two-organization infinite loop. Investigation delegated to Credit Risk; Credit Risk, honestly, delegated a screening back to the agent already in the chain. Neither team was misbehaving; neither could see the whole cycle. It ran for six hours and the bill was the first symptom.

The erased hop. The callee constructed its own chain entry from the request body. A misconfigured intermediary omitted itself, and the audit record showed a two-hop flow that had actually been three. Found during a model-risk review, not by monitoring.

The metadata endpoint. A push-notification callback URL pointing at 169.254.169.254. The server dutifully fetched it. One allow-list line.

The classification leak inside one tenant. Tenancy was checked; classification was not. A restricted investigation delegated to a summarization agent cleared for internal, inside the same tenant, and nothing errored.

The protocol migration that was a data migration. A2A objects stored directly in the task store. The next spec revision renamed a state, and the fix was a backfill across three million rows plus a compatibility shim that outlived the engineer who wrote it.

Five agents, one team. A "multi-agent architecture" for a linear four-step workflow, all owned by one squad. Latency tripled, cost quadrupled, and debugging required correlating five traces. It was a function call wearing a protocol.

Beginner mistakes

  1. Wrapping an agent as an MCP tool and hitting a timeout.
  2. Trusting the chain in the message body.
  3. No depth limit; no cycle detection.
  4. Tenancy checked, classification forgotten.
  5. Any callback URL accepted.
  6. A callback with no verifiable token.
  7. Publishing your tenant model in the agent card.
  8. Storing protocol objects in the kernel.
  9. An undeclared lossy state mapping.
  10. Collapsing input-required and auth-required — one goes to the user, one to identity.
  11. Multi-agent for a single-owner workflow.
  12. Substituting a service account for a missing user identity at a fabric boundary.

What "good" sounds like

"A2A gives me a long-running task object, artifacts, cancellation and an interactive callee. What it doesn't give me is admission control, which in a bank is the whole risk: depth, cycles, tenancy, classification downhill-only, an acceptable auth scheme, and a delegation chain derived from the caller's verified context rather than asserted in the message. The kernel stores an internal task model with A2A and ACP as edge adapters, so a spec revision is an adapter change, and lossy mappings — ACP has no rejected — are declared and pinned by a test rather than discovered by an auditor. And at any fabric boundary I assert the identity I require and refuse rather than degrade; substituting a service account for a missing user is how you end up telling an examiner that 'the platform' moved the money."