A2A Agents Need Delegation Memory

The Agent2Agent protocol is moving multi-agent systems from custom glue into shared infrastructure. The Linux Foundation says A2A has passed 150 supporting organisations, reached a stable 1.0 specification, and landed inside Google, Microsoft and AWS platforms. The official protocol frames A2A as the common language for agents built on different frameworks to discover each other, delegate work and coordinate tasks.

That is useful infrastructure. It also exposes the next operating problem: when one agent delegates work to another, the company needs to remember what was handed off, which agent accepted it, what came back, who approved the result, and which correction changes the next run.

A2A agents need delegation memory. Delegation memory is the governed record of cross-agent task state, artefact versions, source authority, approvals, review outcomes and write-back that keeps multi-agent work from becoming another chain of confident black boxes.

A2A makes agent handoffs cheaper

A2A matters because enterprise agent work is drifting across vendors, departments and runtime environments. A sales agent, procurement agent, support agent and finance agent will live across different platforms. The protocol gives agents a way to discover each other through Agent Cards, understand capabilities, exchange messages, create tasks and return artefacts without exposing internal memory or proprietary tools.

The official A2A documentation separates that job from MCP. MCP connects an individual agent to tools and data sources. A2A lets specialised agents collaborate with each other. That distinction is clean enough technically, but it widens the operating surface for the company.

A protocol can describe the receiving agent’s endpoint, skills, authentication scheme and supported capabilities. It cannot decide whether the receiving agent has enough business context, whether the delegated task needs legal review, whether the artefact it returns should overwrite the previous version, or whether a failed handoff should become reusable knowledge.

That work belongs in the company memory layer.

Agent Cards need trust memory around them

A2A uses Agent Cards to describe what an agent offers. The agent discovery guidance says the card can include identity, provider information, service endpoint, capabilities, authentication requirements and skill descriptions. Discovery can happen through a well-known URI, a curated registry or private configuration.

Those options create different trust questions.

A public card is good for discoverability, but sensitive skills and internal endpoints need authentication. A curated enterprise registry gives the organisation more control, but the registry still needs ownership, approval standards and selective disclosure. A private configuration works for known relationships, but changes to capability or access can quietly drift if nobody records why the relationship exists.

Delegation memory should sit beside the registry. It records which agents are approved for which workflow, who owns the Agent Card, when a capability changed, which user group can discover it, and what evidence proves the agent is still fit for the task. Without that record, discovery becomes a catalogue problem rather than an operating control.

The risk is concrete. ServiceNow’s Action Fabric announcement describes external agents such as Claude, Copilot or homegrown agents triggering governed work inside ServiceNow through its MCP server. ServiceNow emphasises identity verification, permission scoping, audit trails, session management and role based tool packages. That is the shape serious enterprise action will take: agent discovery, tool access and workflow execution under visible control.

Tasks need state memory beyond task IDs

The A2A task model is built for work that takes more than one response. Tasks can ask for input, require authentication, complete, fail, reject or cancel. A shared context ID can group related messages and tasks. Follow-up work can reference earlier task IDs, and parallel tasks can run inside the same context.

Those primitives are exactly why operating memory matters.

A company needs more than task 123 completed. It needs to know whether the result answered the business question, whether a human accepted the artefact, whether the output replaced an older version, which source settled a conflict, and whether a downstream workflow used the result.

The A2A documentation is explicit that artefact mutation history belongs on the client side, not inside the serving agent. That is a strong design choice. It keeps the protocol focused, but it pushes version control, acceptance and business judgement back to the organisation using the agents.

Delegation memory handles that client-side responsibility. It links the original request, delegated task, returned artefact, human review, accepted version and final action. When a user asks the agent to refine the output later, the system can see which version was accepted rather than trusting whichever artefact appeared last.

Multi-agent work creates review residue

The first wave of connector work taught teams that access is cheaper than judgement. A similar pattern appears with agent-to-agent workflows: delegation becomes cheaper than accountability.

A product agent can ask a research agent for customer evidence. The research agent can ask a data agent for usage patterns. The data agent can return a chart, a caveat and a field-quality warning. The product agent can then draft a launch decision that looks coherent to the manager reading the final answer.

The manager still needs the receipt.

Which agent supplied the evidence? Which dataset did it use? Did the data agent warn that the segment was incomplete? Did the research agent cite customer calls or only support tickets? Did the product agent preserve those caveats in the final recommendation? Did anyone approve the message before it reached sales, support or customers?

That review residue is not governance theatre. It is how the next workflow improves. A rejected artefact should change the task brief. A missing source should update the source map. A bad handoff should narrow the agent’s delegation rights. A human correction should become company memory rather than staying trapped in one chat transcript.

ServiceNow points at the action layer

ServiceNow’s Action Fabric is a useful market signal because it connects the agent interoperability story to governed enterprise execution. The announcement describes agents triggering ServiceNow workflows headlessly, including approvals, catalogues, playbooks, OAuth, audit trails and consumption metering. Its AI Control Tower page frames the control problem around AI agents, models, identities, MCP servers, risk, compliance, runtime performance and value measurement.

That does not mean every company needs ServiceNow as the answer. It shows where the pressure is moving. Once agents can delegate across systems and trigger work without a traditional user interface, the operating layer has to remember more than prompts and outputs.

It has to remember the route from request to action.

For smaller and mid-market teams, the practical version is narrower: one workflow, a small set of approved agents, a source hierarchy, a task-state receipt, a review queue and a write-back rule. That is enough to expose whether multi-agent delegation is creating leverage or only distributing confusion.

Build the first delegation loop around one workflow

Teams do not need a full multi-agent estate before designing delegation memory. They need one workflow with enough pressure to reveal the handoff risk.

Start with a workflow such as sales proposal preparation, support escalation, incident response, procurement change review or product launch planning. Then map the delegation loop across nine controls: receiving agent, approved remote agents, safe Agent Card fields, tools behind each agent, task states that require review, accepted artefact version, source hierarchy for conflicting evidence, record location for approvals and the downstream system that receives the final action.

That loop turns A2A from interoperability into operating infrastructure. The agents can coordinate, but the company retains the memory of why a handoff deserved trust.

Where Model Operator fits

Model Operator builds the memory and workflow layer teams need before AI can be trusted across functions. For A2A and multi-agent systems, that means mapping source authority, agent discovery, permission boundaries, task states, artefact ownership, review paths and write-back routes around the work teams already run.

The package route depends on the first constraint. Fragmented context points towards an Agentic Company Brain. AI inside Slack or Teams points towards Company Brain + Slack / Teams Bots. Cross-agent workflow design and adoption risk point towards AI Initiative Consulting.

If your team is experimenting with A2A, MCP, custom agents or internal AI workflows, start with one delegated task. Make the handoff, state, source and review trail visible before adding more agents. This connects directly to MCP connectors needing permission memory, AI asset inventory needing operating memory and Copilot Studio agents needing evaluation memory.

Model Operator builds governed company memory and internal AI interfaces for teams that need AI to work inside real operating constraints.

Start a build conversation: modeloperator.io or alexander@modeloperator.io.