A2A Protocol in Production: Architecture, Security, and Reliable Multi-Agent Systems

Enterprise AI rarely remains inside one agent framework. A support agent may need a finance agent owned by another team. A procurement agent may delegate supplier research to an external service. A customer-facing assistant may need a specialist agent running in a different cloud, language, or security domain.

Custom HTTP endpoints can connect these systems, but every integration invents its own discovery, task state, streaming, files, authentication metadata, and error handling. That creates the same point-to-point integration problem enterprises have already solved for conventional services.

The Agent2Agent Protocol, usually called A2A, provides a standard contract for independent agents to discover capabilities, exchange messages, manage long-running tasks, and return structured artifacts without exposing their internal prompts, tools, or reasoning.

A2A v1.0 makes the protocol stable enough to evaluate for production architecture. The protocol does not eliminate distributed-systems work or security design. It gives those concerns a common vocabulary.

At BoundLayer, we treat A2A as an interoperability boundary, not an excuse to create unnecessary agent networks. This guide explains when to use it, how its core objects fit together, and what a secure and reliable production implementation requires.

---

What Problem A2A Solves

An agent can interact with three different kinds of counterpart:

1. Users provide goals, context, approvals, and feedback.
2. Tools expose deterministic capabilities such as database queries, APIs, search, and file operations.
3. Other agents accept goals, manage their own internal workflow, and return results asynchronously.

Tool calling is appropriate when the caller knows the operation and its arguments. Agent-to-agent delegation is different. The remote system may ask for more input, choose its own tools, work for several minutes, stream progress, and produce multiple artifacts.

A2A standardizes this third interaction model. It allows independently implemented agents to:

• advertise capabilities and supported interfaces;
• receive messages and create tasks;
• maintain context across multiple exchanges;
• stream task status and results;
• request additional input or authorization;
• return text, files, and structured artifacts;
• support polling, streaming, or push notifications;
• negotiate protocol versions and extensions.

The caller sees the remote agent as a service with a task lifecycle. It does not need access to the remote agent's private memory, chain of thought, prompts, or internal tool graph.

---

A2A and MCP Solve Different Problems

A2A and Model Context Protocol are complementary.

MCP connects an AI application or agent to tools and data. An MCP server might expose customer lookup, document search, issue creation, or a database query.

A2A connects one independent agent to another. The remote agent owns its reasoning, tools, state, and task execution.

User
  |
Coordinator Agent
  |-- MCP --> CRM tools
  |-- MCP --> document search
  |
  +-- A2A --> Finance Agent
                 |-- MCP --> ledger tools
                 +-- MCP --> policy database

Do not wrap every function in a remote agent. If a capability is deterministic and the caller can provide complete arguments, a normal API or MCP tool is simpler, faster, and easier to test.

Use A2A when the counterpart has meaningful autonomy, a distinct ownership boundary, or a long-running conversational task. Our guide to MCP security for production enterprise AI covers the tool and data side of this architecture.

---

The Core A2A Objects

A2A becomes easier to reason about when its objects are mapped to familiar distributed-system concepts.

Agent Card

An Agent Card is machine-readable metadata describing an agent. It can advertise:

• name and description;
• endpoint and supported protocol interfaces;
• skills and capabilities;
• accepted input and output modes;
• streaming and push-notification support;
• authentication requirements;
• protocol version and extensions.

An Agent Card is a service description, not proof that the service is trusted. Production clients should retrieve cards only from approved locations, validate transport security, apply an allowlist or registry, and verify signed cards where the deployment requires it.

Message

A Message carries user or agent communication. It can contain text, files, or structured data parts. Messages can start a task or continue an existing context.

Messages are not a reliable event log. Critical results should be represented as task artifacts and persisted in the owning business system.

Task

A Task is the durable unit of work. It has an identifier, status, history, context, and artifacts. The task lifecycle supports asynchronous work rather than assuming one request will complete immediately.

Common states include submitted, working, input required, authorization required, completed, failed, canceled, and rejected. The exact state contract should be handled as protocol data, not inferred from natural-language status messages.

Artifact

An Artifact is an output produced by a task: a report, structured result, generated document, data file, or another deliverable. Separating artifacts from conversational messages gives clients a stable result to validate and store.

Context

A context identifier groups related tasks and messages. It supports multi-turn collaboration without requiring agents to expose their internal memory representation.

Authorization must still be checked for every task and context operation. Possession of an identifier is not permission to read it.

---

Reference Production Architecture

A production A2A environment usually needs more than agents calling arbitrary URLs.

User or business event
        |
Coordinator / workflow service
        |
A2A client gateway
        |
Registry, trust policy, identity, budgets
        |
        +-------------------------------+
        |                               |
Internal A2A agent               External A2A agent
        |                               |
Tools, data, workflows           Vendor-owned runtime
        |                               |
        +---------- artifacts ----------+
        |
Outcome verification and business system
        |
Traces, audit, evaluation, cost accounting

The coordinator owns the business process. It chooses an approved agent, creates the task, persists identifiers, handles authorization requests, receives status, validates artifacts, and decides whether the business goal is complete.

The A2A gateway centralizes cross-cutting controls:

• allowed agents and endpoints;
• Agent Card validation and caching;
• authentication and credential exchange;
• tenant and user context;
• authorization policy;
• rate, time, and cost limits;
• protocol version compatibility;
• audit and trace propagation;
• payload inspection and data-loss prevention.

This does not require a large new platform on day one. A small service or existing API gateway can enforce these controls for the first integration.

---

Use Static Trust Before Dynamic Discovery

Agent discovery is attractive because a coordinator can read capability descriptions and choose a specialist at runtime. In production, open-ended discovery also creates supply-chain and authorization risk.

Start with a registry of approved Agent Card URLs and expected identities. For each agent, record:

• business owner;
• environment and endpoint;
• accepted protocol version;
• approved skills and data classifications;
• authentication scheme;
• tenant model;
• service-level objectives;
• retention and privacy terms;
• incident and revocation contacts.

Cache Agent Cards with an explicit lifetime and invalidate them when trust or configuration changes. A changed endpoint, authentication scheme, skill, or signing key should trigger review rather than silent acceptance.

Descriptions and skill metadata are untrusted input to the coordinator's model. They help routing, but deterministic policy must constrain which agents can be selected for a particular user, tenant, and data class.

Dynamic marketplace-style discovery can be added later if the business need justifies stronger card signing, reputation, certification, and runtime isolation.

---

Authenticate Agents as Workloads

A2A relies on established web security rather than inventing a new identity system. Production endpoints should use TLS and authenticated clients.

Depending on the boundary, suitable mechanisms include:

• OAuth 2.0 client credentials;
• workload identity federation;
• mTLS with short-lived certificates;
• signed service tokens with narrow audiences;
• cloud-native service identities;
• delegated user tokens for on-behalf-of access.

Avoid long-lived shared API keys embedded in prompts, Agent Cards, or configuration repositories. Credentials should be acquired out of band, stored in a secure secret system, rotated, and bound to the intended agent endpoint.

The calling agent's service identity and the human user's delegated identity are different. Preserve both when policy depends on who requested the work.

Our guide to workload identity with SPIFFE, SPIRE, and mTLS describes short-lived machine identity and federation patterns that also apply to A2A services.

---

Authorize Every Operation and Task

Authentication answers who is calling. Authorization decides what that caller may do.

Every A2A request should be scoped by:

• caller identity;
• originating user or tenant;
• target agent and skill;
• task and context ownership;
• data classification;
• requested action and artifact type;
• environment;
• current approval state.

The server must enforce authorization even when the client omits filters. Task listing, retrieval, cancellation, subscriptions, and artifact access must never return another tenant's data merely because an identifier was guessed or a broad query was used.

For user-delegated work, use narrow scopes and purpose-bound tokens. Do not forward a powerful user credential through an arbitrary chain of agents.

A task can transition to an authorization-required state when new access is needed. The coordinator should show the user exactly which agent needs which permission for what purpose. Supply credentials through a secure channel, not as natural-language message content.

Approval must be bound to the task, target, scope, and material parameters. If any of them changes, require a new decision.

---

Design for Asynchronous Tasks

Remote agents are distributed services. They can take seconds or hours, request input, disconnect, restart, or complete after the original client request has ended.

Persist at least:

• local workflow identifier;
• remote task and context identifiers;
• selected agent and Agent Card version;
• caller and tenant;
• current task state;
• last event or update position;
• deadline and cancellation status;
• artifact references;
• verification result.

Choose one status-delivery pattern deliberately.

Polling

Polling is simple and robust for low-volume or slow workflows. Use backoff and stop after terminal states.

Streaming

Streaming gives low-latency updates while a connection is active. Reconnection must reconcile against the authoritative task state because transient events may be missed.

Push Notifications

Webhooks suit long-running tasks but create an inbound security boundary. Authenticate deliveries, validate task ownership, make handlers idempotent, and protect against SSRF when accepting callback URLs.

No matter which transport is used, the remote task state is authoritative. The local coordinator should recover by querying it after a disconnect.

Use a durable workflow engine when the business process spans approvals, timers, multiple agents, and side effects. See durable execution for workflow orchestration for checkpoint, retry, and compensation patterns.

---

Make Delegation Idempotent

Network failure creates ambiguity. A client can send a task request, lose the response, and not know whether the remote agent started work.

Without idempotency, a retry can create duplicate research, messages, orders, or charges.

Use:

• a stable client-generated request key when supported;
• a business correlation identifier in task metadata;
• deduplication at the gateway and receiving agent;
• lookup before retrying an uncertain creation;
• idempotent artifact ingestion;
• explicit reconciliation states;
• bounded retry policies by operation type.

Cancellation is also a request, not proof that work stopped. Confirm the terminal task state and reconcile any side effects already produced.

Artifacts should have stable identifiers, checksums where relevant, and clear replacement semantics. A repeated delivery must not be interpreted as a new business result.

---

Validate Messages and Artifacts at the Boundary

An A2A peer is a remote system, not trusted code in the same process.

Validate:

• content type and protocol version;
• JSON or protobuf schema;
• file size, count, and media type;
• structured-data schema and business constraints;
• links and external references;
• malware where files cross trust boundaries;
• tenant and task identifiers;
• artifact completeness and provenance.

Treat natural-language content as untrusted. A remote artifact can contain prompt injection intended to influence the coordinator or its downstream tools. It may provide evidence, but it cannot grant authority or change policy.

Do not pass remote text directly into a privileged model context alongside credentials and write tools. Label its provenance, minimize it, and keep sensitive actions behind deterministic authorization.

The coordinator should verify the business result independently. A completed A2A task means the remote agent finished its protocol work; it does not automatically mean the enterprise workflow achieved its goal.

---

Keep Agent Boundaries Coarse

Multi-agent diagrams can become complex faster than the underlying product value.

Create a separate A2A agent when there is a real boundary:

• another team owns the capability;
• a different vendor or cloud hosts it;
• the agent has independent state and policy;
• the work is long-running and conversational;
• the capability needs a reusable external contract;
• data residency or security isolation requires separation.

Keep agents in one process or workflow when they share the same owner, deployment, permissions, and lifecycle. In-process function calls are faster and easier to operate.

A2A adds network latency, partial failure, versioning, authentication, observability, and cost. Interoperability is valuable only when it crosses a boundary worth maintaining.

---

Propagate Observability Across Agents

A multi-agent workflow needs one trace that connects the original request to every delegated task and final artifact.

Propagate safe correlation metadata such as:

• trace and span context;
• local workflow identifier;
• remote task and context identifiers;
• agent and release version;
• tenant and data classification;
• deadline and budget;
• parent delegation identifier.

Each agent should record:

• task-state transitions;
• messages and artifact metadata;
• authentication and authorization decisions;
• latency, retries, and errors;
• model and tool usage;
• cost and resource consumption;
• approval and human-intervention events;
• final verification outcome.

Do not put secrets or unnecessary personal data into tracing headers or logs. Apply retention and access controls consistently across organizations.

Measure end-to-end outcomes, not only remote-agent availability. A peer can return completed quickly while producing an unusable artifact.

The operating practices in AgentOps for production AI agents become more important as ownership spans teams and vendors.

---

Evaluate the Whole Delegation Chain

Test individual agents and the coordinator-agent contract.

The evaluation set should include:

• correct and incorrect capability routing;
• unsupported skills and protocol versions;
• authentication and authorization failure;
• input-required and authorization-required states;
• slow, failed, canceled, and duplicate tasks;
• malformed messages and artifacts;
• prompt injection in remote content;
• disconnect and resume behavior;
• partial artifacts and conflicting updates;
• cross-tenant access attempts;
• unavailable agents and fallback policy.

Measure:

• verified business-task success;
• routing precision;
• artifact validity and acceptance;
• authorization compliance;
• duplicate side effects;
• recovery after transport failure;
• human escalation rate;
• end-to-end latency and cost.

Version the coordinator, Agent Cards, remote agents, policies, and evaluator dataset on every run. A remote model or skill change can alter system behavior even when the coordinator code has not changed.

Our guide to AI agent evaluation in production covers golden datasets, trajectory grading, adversarial tests, and release gates.

---

Control Cost and Fan-Out

Delegation can amplify cost. One coordinator may call several agents, each of which calls models, tools, and other agents.

Set limits for:

• maximum delegation depth;
• maximum child tasks;
• task and workflow deadlines;
• tokens and model spend;
• tool and external API spend;
• retries and fallback agents;
• artifact size;
• concurrent tasks per tenant.

Pass a budget with the task where the implementation supports it, but enforce the authoritative limit at the coordinator or gateway. A remote agent's natural-language promise to stay within budget is not a control.

Detect cycles using task ancestry and agent identity. Agent A delegating to B, which delegates back to A, should fail quickly rather than consume budget until timeout.

Track cost per verified workflow outcome across the entire graph. The practices in FinOps for generative AI and agents apply to every delegated model, tool, and runtime.

---

Version the Protocol and Capabilities

A2A v1.0 identifies compatibility by major and minor protocol version. Clients should send the expected version and servers should reject unsupported combinations clearly.

Agent capability changes need their own release discipline. Adding a skill may be backward compatible; changing the meaning or schema of an existing skill may not be.

Use:

• immutable release identifiers;
• explicit input and artifact schemas;
• compatibility tests against supported clients;
• staged Agent Card updates;
• canary traffic;
• deprecation windows;
• rollback to the previous agent release.

Do not infer compatibility from a human-readable skill name. A coordinator should validate the declared protocol, interface, schema, and policy before sending work.

Extensions should be optional unless both sides explicitly require them. Keep core workflows on the standard protocol surface where possible.

---

Common A2A Implementation Mistakes

Turning Every Function into an Agent

Use normal functions, APIs, or MCP tools for deterministic capabilities. Reserve A2A for independent agent boundaries.

Trusting Any Published Agent Card

Discovery metadata is not a trust decision. Use an approved registry, verified identity, and policy.

Forwarding User Credentials Through Agent Chains

Use narrow, audience-bound delegation or request authorization out of band. Do not expose broad credentials to every peer.

Treating Task Completion as Business Success

Validate artifacts and check the external outcome independently.

Retrying Task Creation Blindly

Reconcile uncertain requests and use idempotency to prevent duplicate work and side effects.

Depending on Streaming as the Only Record

Connections drop. Persist state and recover from the authoritative task endpoint.

Allowing Unlimited Delegation

Bound depth, fan-out, time, cost, and concurrency.

Sharing Internal Reasoning Unnecessarily

Exchange goals, evidence, status, and artifacts. Keep private prompts and chain-of-thought internal.

---

A Practical 30-Day Adoption Plan

Week 1: Choose One Real Boundary

Select a workflow where two independently owned agents already need to cooperate. Define the task contract, artifacts, owner, user permissions, and success criteria.

Week 2: Implement Trust and Lifecycle

Publish an Agent Card, configure authentication, enforce tenant-scoped authorization, and persist A2A task state. Start with a static approved endpoint.

Week 3: Add Reliability and Evidence

Implement idempotency, deadlines, retries, cancellation, artifact validation, trace propagation, and independent outcome verification. Exercise disconnect and resume behavior.

Week 4: Evaluate and Canary

Test failure, security, and compatibility cases. Release to a small traffic segment, measure verified success and cost, and expand only when operational evidence supports it.

This creates one useful interoperable boundary without prematurely building a general agent marketplace.

---

How BoundLayer Helps

BoundLayer designs and implements production multi-agent systems across cloud, vendor, and team boundaries.

We can help with:

• A2A architecture and protocol integration;
• Agent Cards, skill contracts, and artifact schemas;
• secure registries and trust policy;
• workload identity and delegated authorization;
• durable task orchestration and human approval;
• A2A and MCP integration boundaries;
• idempotency, recovery, and outcome verification;
• OpenTelemetry tracing, audit, and cost attribution;
• evaluation, compatibility testing, and staged rollout;
• AWS, Azure, Google Cloud, and custom agent platforms.

A2A is most valuable when it replaces bespoke integration across a real ownership boundary. The protocol supplies a common language; production quality still comes from explicit trust, durable state, constrained authority, and verified outcomes.

---

Further Reading

• Official A2A Protocol v1.0 specification
• A2A project and official SDKs
• Microsoft Agent Framework: when to use A2A
• Oracle Autonomous AI Database A2A integration