Site icon Digital Thought Disruption

How MCP and A2A Fit into One Enterprise Agent Architecture: Enterprise Agent Control Plane Series, Part 5

Paul Bryant

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:

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:

The article does not assume that every multi-agent interaction requires A2A.

Several simpler patterns remain valid:

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 areaMCPA2A
Primary interactionAgent or host to tool, resource, or context providerClient agent to independently operated remote agent
Typical work unitTool call, resource read, prompt, or task-augmented requestMessage, stateful task, multi-turn interaction, and artifacts
Discovery objectTools, resources, prompts, server capabilitiesAgent Card, skills, interfaces, security requirements
Expected behaviorBounded capability with a defined contractAutonomous or agentic participant managing its own execution
Internal implementation visibilityServer exposes selected capabilitiesRemote agent can remain opaque
Interaction lengthOften discrete, though long-running requests are possibleDesigned for short, long-running, streaming, and asynchronous collaboration
ClarificationUsually host-managed around tool useNative task and message interaction can request input
Formal outputTool result or resource contentTask artifacts
Authority modelHost and server controlsClient controller and remote agent controls
Best 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:

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:

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:

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:

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:

It does not prove:

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:

The A2A client should not assume it knows or controls those internal details.

It should instead govern:

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:

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:

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:

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 decision
Parent 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.

IdentifierOwnerMeaning
Enterprise run IDParent controllerComplete business workflow
Delegation IDParent controllerOne authorized delegation within the workflow
A2A context IDRemote agentConversational grouping across tasks and messages
A2A task IDRemote agentStateful unit of delegated work
Remote run IDRemote controllerRemote agent’s internal workflow
MCP task or call IDMCP participantOne protocol-level operation inside the remote workflow
Downstream operation IDEnterprise systemNative job, transaction, or change operation
Artifact 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:

The parent controller should map those states into its own workflow rather than copying them blindly.

A2A task stateParent workflow interpretation
SubmittedDelegation accepted, but work has not been proven complete
WorkingRemote work active; parent budget and deadline continue
Input requiredPause and route the exact clarification through policy
Authentication requiredObtain approved secondary credentials outside the message payload
CompletedRetrieve and validate required artifacts, then verify outcome
FailedClassify failure, preserve evidence, and evaluate retry or alternate agent
RejectedRecord reason and decide whether the request or agent selection should change
CanceledReconcile 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:

Use artifacts for:

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:

The parent controller should not automatically trust or execute it.

Apply controls such as:

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:

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:

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:

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:

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:

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:

The root controller should define:

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:

  1. the parent agent cannot access production payroll data
  2. it delegates a broad analysis task to a finance agent
  3. the finance agent has payroll access
  4. sensitive payroll data returns in an artifact
  5. 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:

The enterprise controller should own shared coordination mechanisms such as:

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:

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:

A production catalog should pin the approved combinations.

An Agent Card change may affect:

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:

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 control
Every 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 collaboration
Every tool becomes an A2A agentSimple integrations gain unnecessary state and operational complexityKeep bounded operations in MCP or normal APIs
Public Agent Card treated as approvalUnreviewed agents enter production workflowsUse a private admission catalog
Signed Agent Card treated as full trustIntegrity evidence is confused with implementation assuranceCombine signature validation with security and operational review
Skill advertisement treated as authorizationThe agent claims capability, so the client assumes permissionAuthorize each client, skill, task, and data boundary
Identity included in message metadataCaller can assert its own tenant or privilegeEstablish identity through authenticated transport
Parent token forwarded across every layerToken audience and accountability collapseUse separate A2A, MCP, and downstream credentials
A2A task replaces enterprise stateRoot workflow becomes dependent on a remote agent’s lifecycleMap the task into authoritative parent state
Completed task equals business successArtifacts or downstream outcomes remain unverifiedValidate artifacts and verify the parent outcome
Messages used as durable evidenceDisconnects or retention differences lose critical informationStore deliverables as artifacts and enterprise evidence
Artifact automatically executedGenerated code or configuration creates an injection pathScan, validate, review, and promote artifacts
Remote agent can delegate freelyAuthority and cost spread through an uncontrolled meshLimit depth, relationships, fan-out, and budgets
Cancellation assumed to reverse workRemote side effects remain after the parent closesReconcile and compensate before terminal closure
Agents compete for one resourceConflicting actions pass independentlyUse controller-level locks, budgets, and conflict policy
No version pinningAgent or protocol changes alter production behavior silentlyPin cards, skills, interfaces, protocols, and artifact contracts
Separate 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:

An interoperability demonstration is not a production readiness test.

Operating Metrics

Measure the combined architecture through business and control outcomes.

Useful metrics include:

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 owner
Enterprise agent federation policyAI platform and security architecture
Parent workflowAgent service owner
A2A private catalogAI platform or integration governance team
Agent Card and skill reviewRemote agent owner and application security
Client and remote identitiesIdentity and access management
A2A routing and gatewayPlatform and network teams
Remote agent controllerRemote agent service owner
Remote MCP gateway and toolsRemote platform and domain owners
Artifact securityData security and application security
Task and workflow stateParent and remote controller owners
Cross-agent conflict policyBusiness service and platform owners
Trace and observabilitySRE and security operations
Cancellation and recoveryEnd-to-end agent service owner
External provider assuranceVendor risk and procurement
Final 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

Agent admission

Identity and authorization

State and tasks

Context and artifacts

Delegation control

Remote MCP plane

Operations

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

Exit mobile version