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 areaMCPA2APrimary interactionAgent or host to tool, resource, or context providerClient agent to independently operated remote agentTypical work unitTool call, resource read, prompt, or task-augmented requestMessage, stateful task, multi-turn interaction, and artifactsDiscovery objectTools, resources, prompts, server capabilitiesAgent Card, skills, interfaces, security requirementsExpected behaviorBounded capability with a defined contractAutonomous or agentic participant managing its own executionInternal implementation visibilityServer exposes selected capabilitiesRemote agent can remain opaqueInteraction lengthOften discrete, though long-running requests are possibleDesigned for short, long-running, streaming, and asynchronous collaborationClarificationUsually host-managed around tool useNative task and message interaction can request inputFormal outputTool result or resource contentTask artifactsAuthority modelHost and server controlsClient controller and remote agent controlsBest fitData access, API operation, computation, retrieval, bounded executionDelegation, 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.
Skills Are Not the Same as MCP Tools
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.
BoundaryRequired decisionParent controllerMay this workflow delegate this goal to this remote agent?A2A gateway or serverMay this authenticated client use this skill and access this task?Remote controllerMay the remote agent perform the proposed internal plan?MCP gatewayWhich approved tools may the remote agent see and invoke?MCP serverIs this domain operation valid for this identity and resource?Enterprise systemDoes 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.
IdentifierOwnerMeaningEnterprise run IDParent controllerComplete business workflowDelegation IDParent controllerOne authorized delegation within the workflowA2A context IDRemote agentConversational grouping across tasks and messagesA2A task IDRemote agentStateful unit of delegated workRemote run IDRemote controllerRemote agent’s internal workflowMCP task or call IDMCP participantOne protocol-level operation inside the remote workflowDownstream operation IDEnterprise systemNative job, transaction, or change operationArtifact IDRemote agentConcrete 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 stateParent workflow interpretationSubmittedDelegation accepted, but work has not been proven completeWorkingRemote work active; parent budget and deadline continueInput requiredPause and route the exact clarification through policyAuthentication requiredObtain approved secondary credentials outside the message payloadCompletedRetrieve and validate required artifacts, then verify outcomeFailedClassify failure, preserve evidence, and evaluate retry or alternate agentRejectedRecord reason and decide whether the request or agent selection should changeCanceledReconcile 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 modeWhat happensCorrective controlEvery agent is wrapped as an MCP toolMulti-turn and long-running behavior becomes awkward or hiddenUse A2A when the remote participant owns task state and collaborationEvery tool becomes an A2A agentSimple integrations gain unnecessary state and operational complexityKeep bounded operations in MCP or normal APIsPublic Agent Card treated as approvalUnreviewed agents enter production workflowsUse a private admission catalogSigned Agent Card treated as full trustIntegrity evidence is confused with implementation assuranceCombine signature validation with security and operational reviewSkill advertisement treated as authorizationThe agent claims capability, so the client assumes permissionAuthorize each client, skill, task, and data boundaryIdentity included in message metadataCaller can assert its own tenant or privilegeEstablish identity through authenticated transportParent token forwarded across every layerToken audience and accountability collapseUse separate A2A, MCP, and downstream credentialsA2A task replaces enterprise stateRoot workflow becomes dependent on a remote agent’s lifecycleMap the task into authoritative parent stateCompleted task equals business successArtifacts or downstream outcomes remain unverifiedValidate artifacts and verify the parent outcomeMessages used as durable evidenceDisconnects or retention differences lose critical informationStore deliverables as artifacts and enterprise evidenceArtifact automatically executedGenerated code or configuration creates an injection pathScan, validate, review, and promote artifactsRemote agent can delegate freelyAuthority and cost spread through an uncontrolled meshLimit depth, relationships, fan-out, and budgetsCancellation assumed to reverse workRemote side effects remain after the parent closesReconcile and compensate before terminal closureAgents compete for one resourceConflicting actions pass independentlyUse controller-level locks, budgets, and conflict policyNo version pinningAgent or protocol changes alter production behavior silentlyPin cards, skills, interfaces, protocols, and artifact contractsSeparate traces for each protocolOperators cannot reconstruct the end-to-end workflowPropagate 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
CapabilityAccountable ownerEnterprise agent federation policyAI platform and security architectureParent workflowAgent service ownerA2A private catalogAI platform or integration governance teamAgent Card and skill reviewRemote agent owner and application securityClient and remote identitiesIdentity and access managementA2A routing and gatewayPlatform and network teamsRemote agent controllerRemote agent service ownerRemote MCP gateway and toolsRemote platform and domain ownersArtifact securityData security and application securityTask and workflow stateParent and remote controller ownersCross-agent conflict policyBusiness service and platform ownersTrace and observabilitySRE and security operationsCancellation and recoveryEnd-to-end agent service ownerExternal provider assuranceVendor risk and procurementFinal business outcomeNamed 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.
External References
A2A Protocol: Agent2Agent Protocol SpecificationCanonical URL: https://a2a-protocol.org/latest/specification/
A2A Protocol: A2A and MCPCanonical URL: https://a2a-protocol.org/latest/topics/a2a-and-mcp/
A2A Protocol: What is A2A?Canonical URL: https://a2a-protocol.org/latest/topics/what-is-a2a/
A2A Protocol: Core Concepts and Components in A2ACanonical URL: https://a2a-protocol.org/latest/topics/key-concepts/
A2A Protocol: Enterprise FeaturesCanonical URL: https://a2a-protocol.org/latest/topics/enterprise-ready/
A2A Protocol: Multi-Tenancy and Multi-Agent RoutingCanonical URL: https://a2a-protocol.org/latest/topics/multi-tenancy/
A2A Protocol: What’s New in A2A Protocol v1.0Canonical URL: https://a2a-protocol.org/latest/whats-new-v1/
A2A Protocol: A2A Protocol Ships v1.0: Production-Ready Standard for Agent-to-Agent CommunicationCanonical URL: https://a2a-protocol.org/latest/announcing-1.0/
Model Context Protocol: Architecture overviewCanonical URL: https://modelcontextprotocol.io/docs/learn/architecture
Model Context Protocol: AuthorizationCanonical URL: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
Model Context Protocol: TasksCanonical URL: https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks
How to Design Tools That AI Agents Can Use Reliably
TL;DR An agent tool is not merely an API endpoint with a JSON wrapper. It is a contract between a nondeterministic decision-maker…
The post How MCP and A2A Fit into One Enterprise Agent Architecture: Enterprise Agent Control Plane Series, Part 5 appeared first on Digital Thought Disruption.