TL;DR
MCP and A2A solve different integration problems and belong at different layers of the enterprise agent architecture.
Use MCP when an agent needs controlled access to tools, resources, APIs, data, and bounded operations.
Use A2A when one independently operated agent needs to discover another agent, delegate a goal, participate in a multi-turn interaction, track a stateful task, receive progress updates, and consume formal artifacts.
The clean architecture is:
A2A connects governed agents. MCP connects each agent to governed capabilities. The enterprise controller remains authoritative across both planes.
A2A should not create an uncontrolled mesh in which agents discover one another and redistribute authority freely. The root controller must still decide which agents are trusted, which skills can be invoked, what data may cross the boundary, how much delegation is allowed, which approvals remain valid, how tasks map to the parent workflow, and how results are verified.
The remote agent must have its own controller and governed MCP plane. An A2A task marked completed should not automatically make the enterprise workflow successful. The parent controller must validate the returned artifacts, reconcile any side effects, and verify the intended business outcome.
Introduction
This series began with a simple architectural position:
The agent proposes. The controller authorizes. MCP carries the governed interaction. The runtime executes and verifies.
Part 1 placed MCP beneath an enterprise agent control plane instead of treating it as the complete agent controller. Part 2 defined the trusted controller responsible for identity, durable state, policy, approvals, budgets, retries, cancellation, and termination. Part 3 governed the MCP gateway and server layer. Part 4 followed an authorized action through execution, verification, compensation, and recovery.
Part 5 extends the architecture beyond one agent.
The moment an agent delegates work to another independently deployed agent, the problem changes. The receiving system may run in a different product, cloud, organization, security domain, framework, or operational team. It may have its own model, controller, tools, data, policies, memory, and release process.
Representing that entire system as a simple function can hide important behavior.
An independent agent may need to:
- ask clarifying questions
- negotiate task scope
- maintain state over time
- request additional authentication
- stream progress
- produce several artifacts
- pause for user input
- reject the task
- delegate internally
- continue working after the original connection closes
Those interactions are closer to collaboration than tool invocation.
That is where the Agent2Agent Protocol fits.
The correct enterprise architecture does not replace MCP with A2A or A2A with MCP. It uses each protocol at the boundary it was designed to standardize, then places both beneath a trusted control model.
The Series Architecture in One View
The completed series separates five concerns that are often combined into one vague agent layer.
The A2A connection exists between agent systems.
The MCP connections exist between an agent host and its approved servers.
The control plane governs both.
Scope and Assumptions
This article assumes:
- A2A version 1.0 is the selected agent-to-agent interoperability baseline
- MCP version 2025-11-25 is the stable MCP baseline used by the participating agent systems
- agents are independently deployed or operated
- each agent has a trusted controller around its model
- each agent uses governed MCP access for its local tools and resources
- the root enterprise workflow remains authoritative outside the protocol objects
- authentication, authorization, data policy, and evidence retention are enterprise requirements
- remote agents may execute long-running, multi-turn tasks
- some delegations may cross organizational or tenant boundaries
The article does not assume that every multi-agent interaction requires A2A.
Several simpler patterns remain valid:
- a deterministic workflow calling an API
- an agent invoking a bounded MCP tool
- one process calling an internal function
- a parent controller executing a known child workflow
- a model selecting among several predefined workers inside one trusted runtime
A2A becomes useful when the remote participant behaves as an independent agent rather than as a fixed tool.
Terminology Guardrails
Several terms need clear boundaries before the architecture can be discussed accurately.
MCP host
The AI application that coordinates one or more MCP clients. It can contain a model, an agent loop, a controller, user experience components, and other application services.
MCP client
The protocol component that maintains a connection to one MCP server.
MCP server
A program that exposes tools, resources, prompts, or other supported MCP capabilities.
A2A client
The application, service, or agent that initiates an A2A interaction on behalf of a user or upstream workflow.
A2A server
The remote agent system that receives A2A requests and manages its own task execution.
Agent Card
A discovery document that describes an A2A agent’s identity, supported interfaces, capabilities, skills, and security requirements.
A2A task
A server-generated, stateful unit of work with a defined lifecycle.
Message
A communication turn used for instructions, clarification, questions, status information, or follow-up input.
Artifact
A concrete output produced by a task, such as a report, structured result, document, image, evidence bundle, or other deliverable.
Enterprise workflow
The authoritative business process owned by the trusted controller. It may contain several A2A tasks, MCP calls, approvals, timers, manual steps, and recovery activities.
An A2A task is not automatically the enterprise workflow.
An MCP task is not automatically an A2A task.
A conversation is not automatically durable workflow state.
MCP and A2A Solve Different Problems
| Decision area | MCP | A2A |
|---|---|---|
| Primary interaction | Agent or host to tool, resource, or context provider | Client agent to independently operated remote agent |
| Typical work unit | Tool call, resource read, prompt, or task-augmented request | Message, stateful task, multi-turn interaction, and artifacts |
| Discovery object | Tools, resources, prompts, server capabilities | Agent Card, skills, interfaces, security requirements |
| Expected behavior | Bounded capability with a defined contract | Autonomous or agentic participant managing its own execution |
| Internal implementation visibility | Server exposes selected capabilities | Remote agent can remain opaque |
| Interaction length | Often discrete, though long-running requests are possible | Designed for short, long-running, streaming, and asynchronous collaboration |
| Clarification | Usually host-managed around tool use | Native task and message interaction can request input |
| Formal output | Tool result or resource content | Task artifacts |
| Authority model | Host and server controls | Client controller and remote agent controls |
| Best fit | Data access, API operation, computation, retrieval, bounded execution | Delegation, negotiation, specialist work, cross-platform agent collaboration |
This distinction should guide protocol selection.
Do not choose based on which SDK is easier to install.
Choose based on what the remote participant actually is.
Use MCP for Bounded Capabilities
MCP is the better fit when the calling system knows the operation it needs and can describe it through a controlled schema.
Examples include:
- retrieve a service record
- query a database through a constrained interface
- search an approved document repository
- calculate a value
- create a ticket
- simulate a configuration change
- request a bounded deployment operation
- retrieve health or status data
- read an approved file
- invoke a domain-specific enterprise API
The capability may still be sophisticated. The important property is that the caller invokes a defined operation rather than delegating an open-ended goal to another autonomous system.
Use A2A for Agent Delegation
A2A is the better fit when the remote system needs to own how the work is performed.
Examples include:
- ask a network operations agent to investigate an outage
- delegate contract analysis to a legal specialist agent
- ask a procurement agent to obtain and compare supplier options
- send an incident to a security response agent that may require clarification
- ask a travel agent to coordinate several external providers
- delegate code review to an independently operated engineering agent
- ask a partner agent to process a multi-stage business request
- coordinate work across agents built on different frameworks
The client defines the goal, constraints, expected artifacts, and authority boundary.
The remote agent decides how to perform its internal reasoning and which approved tools it needs.
A Simple Decision Framework
A common architecture mistake is promoting every function into an agent and every internal agent into a remotely discoverable A2A service.
Protocol layers add operational cost. Use them when the independence and interaction model justify that cost.
Agents Are Not Automatically Safe Because They Use A2A
A2A standardizes communication. It does not automatically make the remote agent trustworthy.
A remote agent may still:
- misunderstand the request
- expose an overstated skill
- operate with excessive authority
- mishandle sensitive data
- return malicious or unsafe artifacts
- delegate work to an unapproved third party
- consume excessive time or cost
- fail to stop after cancellation
- change behavior after an upgrade
- produce a task status that does not match the business outcome
The protocol creates a common interaction model.
Enterprise trust still requires admission, authorization, policy, monitoring, evidence, versioning, testing, and ownership.
Build a Private Agent Catalog
Agent discovery should feed an enterprise admission process, not a direct autonomous connection path.
The private A2A catalog should record:
- enterprise agent identifier
- provider and technical owner
- business owner
- Agent Card location
- approved Agent Card hash
- signature validation status
- approved interfaces and protocol versions
- endpoint and tenant routing
- supported security schemes
- approved skills
- skill risk classifications
- allowed callers
- allowed data classifications
- permitted regions
- task duration limits
- artifact types and size limits
- downstream delegation policy
- observability requirements
- service-level expectations
- review date
- approval expiration
- quarantine status
- emergency contact
- kill-switch owner
A public Agent Card can describe what an agent claims to offer.
The enterprise catalog should describe what the organization has verified and approved.
Agent Card Signing Improves Integrity, Not Complete Trust
A2A version 1.0 allows Agent Cards to be signed using JSON Web Signature after canonicalization.
A valid signature can help prove:
- the card was not modified after signing
- the card originated from the holder of the signing key
- the capabilities and endpoints match the signed content
It does not prove:
- the implementation is secure
- the advertised skill behaves correctly
- the remote agent uses least-privilege tools
- the signing environment is uncompromised
- the agent meets your compliance requirements
- the agent will remain compatible after an upgrade
- the provider should be trusted with a specific data class
Treat the signature as one evidence item in the admission decision.
The same principle applies to TLS certificates, OAuth tokens, registry records, and product certifications. Each signal answers a narrow trust question.
An A2A Agent Card can advertise skills. A skill describes an area of capability that clients can use when deciding whether the agent is suitable for a task.
An MCP tool generally describes a more bounded callable operation with an input schema.
A skill such as network-incident-investigation may internally use:
- topology discovery tools
- monitoring queries
- ticket data
- configuration resources
- diagnostic commands
- change-management APIs
- several model calls
- an approval workflow
- another specialist agent
The A2A client should not assume it knows or controls those internal details.
It should instead govern:
- whether the skill may be requested
- what goal may be delegated
- what data may be supplied
- what authority the remote agent receives
- what artifacts must be returned
- whether side effects are allowed
- how completion is verified
The remote agent’s own controller should govern its MCP tools.
The Parent Controller Must Authorize Delegation
The model should not be able to choose any discovered agent and send it unrestricted context.
A delegation decision should evaluate:
- authenticated requester
- client agent identity
- parent workflow type
- selected remote agent
- requested skill
- target tenant
- target environment
- data classification
- purpose limitation
- expected artifact
- allowed side effects
- maximum task duration
- cost and token budget
- delegation depth
- concurrency and fan-out
- approval status
- policy version
- remote agent version
- Agent Card hash
The controller should produce a bounded delegation envelope.
The model can propose the agent, skill, goal, and candidate context.
Trusted code must supply the authority and limits.
The Delegation Envelope
The following YAML is an application-level control contract, not a native A2A protocol object.
agent_delegation:
version: 2
parent:
enterprise_run_id: run-8d22
delegation_id: delegation-4b91
workflow_type: production_incident_response
policy_version: federation-policy-v7
requester:
principal: user-48291
organization: enterprise-a
source_application: operations-copilot
client_agent:
agent_id: incident-orchestrator
release: 3.4.1
workload_identity: incident-orchestrator-prod
remote_agent:
catalog_id: network-operations-agent
approved_card_hash: card-sha256-7cc4
protocol_version: "1.0"
permitted_skill: network-incident-investigation
task:
goal: "Determine the network cause of the service outage"
target_environment: production
side_effect_mode: read_only
maximum_duration_seconds: 600
maximum_follow_up_turns: 3
maximum_artifact_bytes: 5242880
delegation_depth_remaining: 0
context:
allowed_data_classes:
- internal
- operational
prohibited_data_classes:
- credentials
- customer_content
allowed_system_references:
- incident_record
- affected_service
- approved_topology_snapshot
expected_artifacts:
- type: diagnostic_report
media_type: application/json
required: true
- type: evidence_summary
media_type: text/plain
required: true
completion:
accept_task_completed_without_artifacts: false
require_artifact_schema_validation: true
require_parent_verification: true
cancellation:
propagate_to_remote_task: true
require_side_effect_reconciliation: true
observability:
propagate_trace_context: true
retain_status_history: true
retain_artifact_hashes: true
capture_sensitive_content: false
The remote agent should receive only the context required to complete the delegated task.
The side_effect_mode is authoritative because the controller supplied it. A model-generated message claiming that writes are approved must not change it.
Identity Must Be Preserved Across Both Planes
A multi-agent workflow can involve several distinct identities:
- human or service requester
- parent enterprise workflow
- client agent
- A2A client workload
- remote agent service
- remote controller
- remote MCP client
- remote MCP server
- downstream enterprise system
These identities must not collapse into one broad bearer token.
A2A establishes identity through standard web security mechanisms outside the message payload.
That means the remote agent should not treat identity fields inside a message or metadata object as authoritative.
The A2A request may contain a tenant routing value advertised by the selected interface. That value helps route the request. It should not override authenticated tenant or organization claims.
The same rule continues into MCP. An inbound A2A token should not be forwarded unchanged to an MCP server or downstream enterprise API unless the security architecture explicitly supports the correct audience and delegation flow.
Prefer:
- workload identity
- token exchange
- on-behalf-of delegation
- narrowly scoped service roles
- short-lived credentials
- explicit audience validation
Authorization Must Exist at Every Boundary
The parent controller authorizes the delegation.
The A2A server authorizes access to the selected skill and task.
The remote controller authorizes its internal workflow.
The MCP server authorizes access to its tool.
The downstream enterprise system authorizes the resource operation.
| Boundary | Required decision |
|---|---|
| Parent controller | May this workflow delegate this goal to this remote agent? |
| A2A gateway or server | May this authenticated client use this skill and access this task? |
| Remote controller | May the remote agent perform the proposed internal plan? |
| MCP gateway | Which approved tools may the remote agent see and invoke? |
| MCP server | Is this domain operation valid for this identity and resource? |
| Enterprise system | Does native resource authorization permit the final action? |
Removing a layer may be reasonable in a tightly controlled internal environment, but the design should make that decision explicit.
Keep the State Hierarchy Separate
The parent enterprise workflow, A2A task, remote workflow, MCP task, and downstream operation are related but distinct state machines.
| Identifier | Owner | Meaning |
|---|---|---|
| Enterprise run ID | Parent controller | Complete business workflow |
| Delegation ID | Parent controller | One authorized delegation within the workflow |
| A2A context ID | Remote agent | Conversational grouping across tasks and messages |
| A2A task ID | Remote agent | Stateful unit of delegated work |
| Remote run ID | Remote controller | Remote agent’s internal workflow |
| MCP task or call ID | MCP participant | One protocol-level operation inside the remote workflow |
| Downstream operation ID | Enterprise system | Native job, transaction, or change operation |
| Artifact ID | Remote agent | Concrete output produced by the A2A task |
Do not replace the enterprise run ID with the A2A task ID.
The remote server generates the A2A task ID and owns its lifecycle. The client should treat it as an opaque reference.
The parent controller should maintain the mapping between all identifiers for tracing, cancellation, reconciliation, and evidence.
Map A2A Task States into the Enterprise Workflow
A2A tasks can move through states including:
- submitted
- working
- completed
- failed
- canceled
- input required
- rejected
- authentication required
The parent controller should map those states into its own workflow rather than copying them blindly.
| A2A task state | Parent workflow interpretation |
|---|---|
| Submitted | Delegation accepted, but work has not been proven complete |
| Working | Remote work active; parent budget and deadline continue |
| Input required | Pause and route the exact clarification through policy |
| Authentication required | Obtain approved secondary credentials outside the message payload |
| Completed | Retrieve and validate required artifacts, then verify outcome |
| Failed | Classify failure, preserve evidence, and evaluate retry or alternate agent |
| Rejected | Record reason and decide whether the request or agent selection should change |
| Canceled | Reconcile whether remote side effects occurred before closing the parent action |
An A2A completed state means the remote agent considers its task complete.
The parent controller still determines whether the enterprise delegation succeeded.
Messages Carry Interaction, Artifacts Carry Deliverables
A2A distinguishes conversational messages from task artifacts.
Use messages for:
- initial instruction
- clarification
- additional context
- status explanation
- user input
- follow-up question
- task refinement
Use artifacts for:
- diagnostic report
- generated configuration
- contract analysis
- structured recommendation
- change plan
- evidence package
- image
- document
- machine-readable result
The distinction matters because streaming messages may be transient. A disconnected client may not receive every status message, and message history persistence can vary by implementation.
Critical results should therefore be stored as artifacts or in another durable evidence channel.
Do not place the only copy of an approval requirement, verification result, or final diagnostic finding in an ephemeral progress message.
Treat A2A Artifacts as Untrusted Inputs
A remote agent artifact can contain:
- text
- structured data
- inline bytes
- external file references
- images
- documents
- generated code
- configuration
- links to additional content
The parent controller should not automatically trust or execute it.
Apply controls such as:
- media-type allowlist
- file-size limit
- schema validation
- malware scanning
- secret detection
- data-classification checks
- tenant validation
- filename normalization
- content hash
- provenance record
- storage isolation
- expiration policy
- manual review for executable content
- safe rendering
- prohibition on automatic external fetches
A structured artifact can still contain prompt injection or misleading values.
A signed Agent Card does not sign every artifact unless the implementation adds a separate artifact-signing mechanism.
Polling, Streaming, and Push Notifications Have Different Risks
A2A supports several ways to receive task updates.
Polling
Polling is simple, works through restrictive networks, and gives the client control over when it requests updates.
Tradeoffs include higher latency and repeated requests.
Streaming
Streaming provides real-time task status and artifact updates over an active connection.
The client still needs reconnect and reconciliation behavior. A broken stream does not prove the task stopped.
Push notifications
Push notifications support long-running work when the client will not remain connected.
They also introduce a webhook attack surface.
A push design should require:
- pre-approved callback endpoint
- no model-supplied webhook destination
- callback authentication
- TLS validation
- task and tenant binding
- replay protection
- event deduplication
- payload-size limits
- source validation
- callback rate limiting
- correlation with the expected task
- polling fallback for reconciliation
A notification should trigger a trusted task read.
It should not independently authorize a workflow transition based only on the webhook payload.
The Remote Agent Should Have Its Own Control Plane
An A2A server should not expose a model directly to external requests.
The remote agent system should contain:
- request intake
- authentication and skill authorization
- task state
- policy evaluation
- approval handling
- budget controls
- model adapter
- governed MCP catalog
- execution runtime
- artifact service
- verification
- evidence and telemetry
- cancellation and kill switches
The remote agent may be opaque to the A2A client, but it should not be uncontrolled internally.
Opaque execution protects implementation details.
It does not excuse missing governance.
MCP Lives Inside the Remote Agent Boundary
A remote agent can use MCP to access its own approved capabilities.
For example, a network operations agent might use:
- monitoring MCP server
- topology MCP server
- ticketing MCP server
- configuration analysis MCP server
- change-management MCP server
- network-controller MCP server
The A2A client delegates a network investigation goal.
The remote controller decides which MCP tools are needed.
The parent controller does not need access to the remote agent’s complete tool list. It needs a clear contract for skill behavior, side-effect authority, required artifacts, and completion semantics.
This separation preserves agent autonomy while keeping enterprise authority bounded.
A Practical End-to-End Scenario
Consider an incident-response orchestrator that needs specialist network analysis.
Parent request
The business request is to identify why an application is unavailable.
The parent controller authenticates the operator, creates the enterprise run, classifies the incident, establishes a read-only investigation budget, and determines that the network operations agent is approved for diagnostic delegation.
A2A delegation
The client agent sends a bounded investigation goal through A2A.
The request includes the incident identifier, affected service, approved topology snapshot reference, deadline, and expected artifacts. It does not include broad production credentials.
Remote task
The network agent authenticates the A2A client and authorizes the diagnostic skill. It creates an A2A task and maps that task to its own internal run.
Internal MCP execution
The remote controller exposes only approved read tools.
The network agent uses MCP to query monitoring, topology, routing state, recent changes, and policy status.
Artifact production
The remote agent returns:
- structured diagnosis
- evidence summary
- affected path
- confidence
- remediation recommendation
- unresolved uncertainties
Parent validation
The parent controller validates the artifact schemas, scans content, checks evidence references, and evaluates whether the diagnosis explains the observed outage.
Separate remediation decision
The diagnosis does not automatically authorize a change.
The parent controller creates a new decision for remediation. Depending on ownership, it may:
- invoke a local MCP tool
- delegate a separate A2A remediation task
- request human approval
- assign the work to an operator
This separation prevents a diagnostic delegation from silently gaining production write authority.
End-to-End Delegation Flow
The important control is the second verification step.
The remote agent verifies its task according to its domain.
The parent controller verifies that the returned result satisfies the enterprise workflow.
Control Delegation Depth and Fan-Out
Multi-agent systems can expand rapidly when one agent delegates to two agents, which each delegate to two more.
Without explicit limits, this creates:
- hidden cost
- duplicated work
- conflicting actions
- data sprawl
- unclear accountability
- recursive loops
- difficult cancellation
- unbounded latency
- inaccessible evidence
- unpredictable authority propagation
The root controller should define:
- maximum delegation depth
- maximum active child tasks
- maximum total remote agents
- permitted agent-to-agent relationships
- permitted cross-organization routes
- cumulative token and cost budget
- cumulative elapsed time
- authority budget
- data-sharing limits
- approval requirements for secondary delegation
A remote agent should not assume it may delegate simply because it supports A2A.
Delegation authority must be explicit.
Prevent Authority Laundering
Authority laundering occurs when an agent lacking permission asks another agent to perform the prohibited action.
For example:
- the parent agent cannot access production payroll data
- it delegates a broad analysis task to a finance agent
- the finance agent has payroll access
- sensitive payroll data returns in an artifact
- the original requester receives data they were not authorized to access
The protocols operated correctly.
The authorization model failed.
Prevent this by carrying purpose and caller context into every delegation decision. The remote agent must evaluate whether the authenticated client and represented requester may use the requested skill and receive the resulting data.
Do not assume that the remote agent’s authority can be inherited by the caller.
Cross-Agent Conflict Resolution Still Belongs Above the Protocols
A2A allows agents to coordinate, but it does not automatically arbitrate conflicts between independent agents.
Two agents may:
- update the same ticket
- change the same service
- reserve the same resource
- produce incompatible recommendations
- spend the same remaining budget
- initiate opposing recovery actions
- communicate contradictory information externally
The enterprise controller should own shared coordination mechanisms such as:
- resource leases
- optimistic concurrency
- change windows
- authority budgets
- global action deduplication
- priority rules
- incident commander authority
- workflow conflict policies
- human escalation
Domain systems should also enforce their own conflict controls.
Do not rely on agents negotiating informally through messages when the result affects authoritative state.
Cancellation Must Propagate Without Assuming Rollback
Canceling the parent workflow should:
- stop new delegations
- stop new MCP work in the local agent
- send cancellation to active A2A tasks
- prevent new remote side effects
- cancel or contain remote MCP operations where possible
- query final remote task state
- retrieve final artifacts and evidence
- reconcile downstream systems
- compensate when required
- close the parent workflow only when the final state is understood
An A2A task marked canceled does not prove every internal tool or downstream operation was reversed.
Cancellation controls future work.
Recovery determines what to do with work that already occurred.
Version Both Protocol Boundaries
The agent architecture now contains several independently changing contracts:
- A2A protocol version
- Agent Card schema and signature
- remote agent release
- advertised skills
- A2A extensions
- MCP protocol version
- MCP server release
- tool descriptions
- tool input and output schemas
- controller policy
- artifact schemas
- enterprise workflow version
A production catalog should pin the approved combinations.
An Agent Card change may affect:
- endpoint
- protocol binding
- tenant routing
- security scheme
- skill list
- supported capabilities
- extensions
- protocol version
A skill description change can influence model selection in the same way that an MCP tool description can influence tool selection.
Material changes should trigger revalidation.
A2A Version 1.0 Migration Considerations
A2A version 1.0 formalizes multiple protocol bindings, strengthens Agent Card handling, adds enterprise-oriented security features, and changes several operation and data representations from earlier versions.
A migration plan should verify:
- supported interface order
- protocol-version negotiation
- client and server SDK compatibility
- operation naming
- streaming event representation
- Part serialization
- task visibility rules
- authentication flows
- signed Agent Card validation
- extension support
- multi-tenant routing
- backward compatibility with earlier agents
Do not assume that a client supporting an earlier A2A release can consume version 1.0 behavior without testing.
The enterprise catalog should record which versions were actually validated together.
A Federated Agent Policy Example
The following YAML shows a broader enterprise policy that joins A2A delegation with governed MCP use.
It is an application-level example, not a native A2A or MCP policy format.
federated_agent_policy:
version: 7
defaults:
unknown_agents: deny
unknown_skills: deny
unknown_mcp_servers: deny
cross_organization_delegation: deny
recursive_delegation: deny
a2a:
protocol_versions:
allowed:
- "1.0"
agent_card:
require_private_catalog_entry: true
verify_signature_when_present: true
quarantine_on_material_change: true
approve_extended_card_separately: true
delegation:
maximum_depth: 1
maximum_parallel_tasks: 3
maximum_follow_up_turns: 4
maximum_task_duration_seconds: 900
model_may_select_uncataloged_agent: false
remote_agent_may_redelegate: false
identity:
authenticate_every_request: true
authorize_per_skill: true
trust_identity_from_message_payload: false
require_audience_bound_token: true
tenant:
use_catalog_routing_value: true
trust_tenant_as_authorization_claim: false
artifacts:
require_expected_artifact_contract: true
allowed_media_types:
- application/json
- text/plain
- application/pdf
maximum_bytes: 10485760
scan_files: true
validate_structured_data: true
auto_fetch_external_urls: false
retain_content_hash: true
notifications:
allow_model_supplied_webhook: false
require_registered_callback: true
authenticate_notifications: true
poll_after_notification: true
mcp:
require_governed_gateway: true
require_private_server_catalog: true
expose_tools_per_remote_task: true
token_passthrough: deny
verify_postconditions_for_writes: true
require_idempotency_for_retries: true
authority:
diagnostic_delegation:
side_effect_mode: read_only
remediation_delegation:
require_parent_approval: true
require_remote_approval: true
maximum_change_actions: 1
workflow:
parent_run_remains_authoritative: true
a2a_completed_requires_parent_verification: true
cancellation_requires_reconciliation: true
conflicting_agent_actions: block_and_escalate
observability:
propagate_trace_context: true
record_agent_card_hash: true
record_remote_agent_release: true
map_all_task_and_operation_ids: true
capture_sensitive_content: false
emergency:
agent_kill_switch: true
skill_kill_switch: true
a2a_route_kill_switch: true
mcp_tool_kill_switch: true
credential_revocation: true
The policy gives the remote agent room to reason while preventing it from inheriting unrestricted authority.
Common MCP and A2A Architecture Failures
| Failure mode | What happens | Corrective control |
|---|---|---|
| Every agent is wrapped as an MCP tool | Multi-turn and long-running behavior becomes awkward or hidden | Use A2A when the remote participant owns task state and collaboration |
| Every tool becomes an A2A agent | Simple integrations gain unnecessary state and operational complexity | Keep bounded operations in MCP or normal APIs |
| Public Agent Card treated as approval | Unreviewed agents enter production workflows | Use a private admission catalog |
| Signed Agent Card treated as full trust | Integrity evidence is confused with implementation assurance | Combine signature validation with security and operational review |
| Skill advertisement treated as authorization | The agent claims capability, so the client assumes permission | Authorize each client, skill, task, and data boundary |
| Identity included in message metadata | Caller can assert its own tenant or privilege | Establish identity through authenticated transport |
| Parent token forwarded across every layer | Token audience and accountability collapse | Use separate A2A, MCP, and downstream credentials |
| A2A task replaces enterprise state | Root workflow becomes dependent on a remote agent’s lifecycle | Map the task into authoritative parent state |
| Completed task equals business success | Artifacts or downstream outcomes remain unverified | Validate artifacts and verify the parent outcome |
| Messages used as durable evidence | Disconnects or retention differences lose critical information | Store deliverables as artifacts and enterprise evidence |
| Artifact automatically executed | Generated code or configuration creates an injection path | Scan, validate, review, and promote artifacts |
| Remote agent can delegate freely | Authority and cost spread through an uncontrolled mesh | Limit depth, relationships, fan-out, and budgets |
| Cancellation assumed to reverse work | Remote side effects remain after the parent closes | Reconcile and compensate before terminal closure |
| Agents compete for one resource | Conflicting actions pass independently | Use controller-level locks, budgets, and conflict policy |
| No version pinning | Agent or protocol changes alter production behavior silently | Pin cards, skills, interfaces, protocols, and artifact contracts |
| Separate traces for each protocol | Operators cannot reconstruct the end-to-end workflow | Propagate one enterprise trace and map all identifiers |
A Practical Implementation Sequence
Start with one read-only delegation
Choose a specialist agent that produces a diagnostic or advisory artifact without changing production systems.
Define the exact skill, data boundary, task duration, artifact schema, and owner.
Build the private A2A catalog
Record the approved Agent Card, version, interfaces, identity scheme, skills, data classifications, and operational owner.
Implement the parent delegation envelope
Separate model-proposed goal and context from trusted identity, authority, policy, budget, and completion requirements.
Map A2A tasks into parent workflow state
Persist the enterprise run ID, delegation ID, A2A context ID, task ID, remote agent release, and artifact IDs.
Validate messages and artifacts
Treat all remote content as untrusted.
Apply schema, size, data-classification, malware, and prompt-injection controls.
Require a governed remote MCP plane
Confirm that the specialist agent accesses enterprise tools through its own trusted controller and approved MCP catalog.
Add streaming or push only after polling works
Polling provides a useful reconciliation baseline.
Add streaming for responsiveness and push notifications for disconnected tasks after identity, replay, and callback controls are ready.
Add cancellation and timeout tests
Cancel the parent at different stages and prove that remote task state, internal MCP calls, downstream operations, and artifacts can be reconciled.
Add one approved write delegation
Separate diagnostic and remediation skills. Require stronger identity, explicit approval, idempotency, post-condition verification, and recovery.
Test cross-agent conflict
Run parallel tasks that target the same resource and confirm that the controller or domain system prevents incompatible action.
Expand the federation gradually
Add agents, skills, organizations, and delegation depth only after operational evidence shows that ownership and failure containment remain clear.
Validation Tests for the Combined Architecture
A production test plan should include:
- unknown Agent Card
- invalid or changed Agent Card signature
- unapproved protocol version
- changed skill description
- wrong tenant routing value
- valid token with unauthorized skill
- identity claim inserted in message metadata
- expired A2A token
- remote agent requesting secondary authentication
- task moving to input required
- task moving to authentication required
- lost streaming connection
- duplicated push notification
- malicious webhook registration attempt
- missing required artifact
- oversized artifact
- artifact with wrong media type
- artifact containing secrets
- artifact containing prompt injection
- task completed with failed parent verification
- remote MCP tool timeout
- remote unknown side-effect outcome
- parent cancellation during remote execution
- remote agent attempting unauthorized redelegation
- two agents attempting conflicting changes
- trace reconstruction across A2A, MCP, and downstream systems
- emergency disablement of one agent or skill
An interoperability demonstration is not a production readiness test.
Operating Metrics
Measure the combined architecture through business and control outcomes.
Useful metrics include:
- delegations by agent and skill
- accepted, rejected, failed, and canceled A2A tasks
- input-required and authentication-required rates
- task completion latency
- artifact-validation failure rate
- missing-artifact rate
- remote agent retry rate
- parent verification failure rate
- cross-agent conflict rate
- delegation-depth violations
- redelegation attempts
- data-policy denials
- secondary-authentication frequency
- push-notification authentication failures
- duplicate notifications suppressed
- cancellation-to-containment latency
- cost per verified delegated outcome
- manual escalation rate
- Agent Card change events
- version incompatibility events
- agent and skill kill-switch activations
A high task-completion rate can hide a low verified-outcome rate.
The root metric should reflect successful, policy-compliant business outcomes.
Operational Ownership
| Capability | Accountable owner |
|---|---|
| Enterprise agent federation policy | AI platform and security architecture |
| Parent workflow | Agent service owner |
| A2A private catalog | AI platform or integration governance team |
| Agent Card and skill review | Remote agent owner and application security |
| Client and remote identities | Identity and access management |
| A2A routing and gateway | Platform and network teams |
| Remote agent controller | Remote agent service owner |
| Remote MCP gateway and tools | Remote platform and domain owners |
| Artifact security | Data security and application security |
| Task and workflow state | Parent and remote controller owners |
| Cross-agent conflict policy | Business service and platform owners |
| Trace and observability | SRE and security operations |
| Cancellation and recovery | End-to-end agent service owner |
| External provider assurance | Vendor risk and procurement |
| Final business outcome | Named enterprise service owner |
A remote agent may be operated by another team or company.
The parent enterprise still needs an owner accountable for deciding whether delegation is appropriate.
Combined MCP and A2A Architecture Checklist
Protocol selection
- The remote participant genuinely behaves as an agent.
- Bounded operations remain tools or APIs.
- A2A is used for stateful delegation, not as a replacement for every integration.
- MCP is used inside agent systems for governed capability access.
Agent admission
- Every remote agent has an approved private catalog entry.
- Agent Card integrity and provider identity are verified.
- Skills are reviewed individually.
- Approved interfaces, versions, security schemes, and routing values are pinned.
- Material Agent Card changes trigger revalidation.
Identity and authorization
- Requester, client agent, remote agent, MCP server, and downstream identities remain distinct.
- Identity is established through authenticated transport.
- Message metadata is not trusted as authority.
- Skill access is authorized per client.
- A2A tokens are not passed blindly into MCP or downstream APIs.
- Tenant routing does not replace tenant authorization.
State and tasks
- The enterprise run remains authoritative.
- Delegation, context, task, MCP, and downstream operation IDs are mapped.
- Input-required and authentication-required states have controlled workflows.
- Completed A2A tasks require artifact and outcome validation.
- Cancellation requires reconciliation.
Context and artifacts
- Only task-required context crosses the boundary.
- Sensitive data classes are explicitly permitted or denied.
- Messages are not the only durable evidence channel.
- Required artifacts have schemas and size limits.
- Files and structured data are scanned and validated.
- External artifact locations are not fetched automatically.
Delegation control
- Maximum depth and fan-out are enforced.
- Remote redelegation requires explicit authority.
- Cost, time, token, and action budgets cover the complete federation.
- Authority laundering is tested.
- Shared-resource conflicts are arbitrated above the protocols.
Remote MCP plane
- The remote agent has a trusted controller.
- MCP servers and tools are admitted through a private catalog.
- Tool exposure is limited per delegated task.
- Credentials are audience-bound and short-lived.
- Writes use idempotency and post-condition verification.
- Remote completion evidence maps back to the A2A artifact.
Operations
- Polling reconciliation works even when streaming or push fails.
- Push callback endpoints are pre-approved and authenticated.
- One enterprise trace spans both protocol planes.
- Agent, skill, route, tool, and credential kill switches are tested.
- Version upgrades include interoperability and rollback testing.
- One owner remains accountable for the complete outcome.
Conclusion
MCP and A2A are complementary protocols, but they do not remove the need for an enterprise control plane.
MCP standardizes how an agent host connects to tools, resources, and bounded capabilities. A2A standardizes how independently operated agents discover one another, exchange messages, manage stateful tasks, request clarification, stream progress, and produce artifacts.
The strongest enterprise pattern is therefore:
A2A between governed agent systems. MCP beneath each agent for governed capability access. A trusted controller above both for identity, policy, workflow state, budgets, conflict resolution, verification, and termination.
Do not build an open agent mesh in which discovery becomes trust and delegation becomes inherited authority.
Use private catalogs, explicit skill authorization, separate identities, bounded delegation envelopes, mapped task hierarchies, artifact validation, controlled delegation depth, cross-agent conflict rules, and end-to-end evidence.
The series began by arguing that MCP should be the governed nervous system through which agents access enterprise capabilities, not the brain making every control decision.
The completed architecture adds one more distinction:
A2A lets controlled agents collaborate. It does not make the collaboration self-governing.
