Introduction

A deployable agentic orchestration stack succeeds or fails on separation of concerns. MCP should carry model-to-tool and model-to-context integration. A2A should carry peer-agent delegation and long-running task collaboration. ACP contributes REST-native agent interoperability patterns that many platform teams can operationalize with existing API governance controls , . LangGraph should own durable workflow state. LangChain should help with model and tool abstractions when higher-level ergonomics are useful. FastAPI and Pydantic should provide typed service boundaries. pytest should make the workflow testable. OpenTelemetry should make it observable. Docker should make it portable. SLSA and Sigstore should strengthen release integrity evidence and provenance workflows -.

ACP status requires planning discipline. As of May 2026, ACP maintainers publicly described active convergence into A2A under Linux Foundation collaboration, so architecture choices should preserve migration-friendly boundaries , .

That package combination is not the only viable one, but it is a coherent one. It yields a simple but sophisticated outcome: a coordinator agent that delegates work to specialist agents over A2A, while each specialist uses MCP to reach local tools and contextual resources. The stack is small enough for a single team to understand and strong enough to support progressive hardening.

Scope and Claim Classification

This playbook mixes three kinds of statements:

  1. Protocol-confirmed facts describe capabilities stated in official SDK or protocol documentation.
  2. Implementation-oriented synthesis connects those documented capabilities into an end-to-end architecture.
  3. Operational recommendations describe a pragmatic deployment posture, not a guaranteed outcome.

References support the protocol-confirmed portions of the article. Architectural choices, package combinations, and rollout priorities are implementation-oriented guidance for one practical open-source design.

This post is informational and technical in nature and is not legal advice.

The Design Objective

The target outcome is not “maximum framework usage.” The target outcome is a system that can do five things without ad hoc glue:

  1. Accept a user request and convert it into a durable workflow.
  2. Delegate portions of that workflow to specialist agents with explicit task state.
  3. Expose tools and resources to those agents through structured, typed capability boundaries.
  4. Produce traces, logs, metrics, and test evidence that make failures explainable.

  5. Ship as a portable artifact with verifiable provenance.

  6. Keep human approval checkpoints and operator-visible controls explicit across protocol boundaries.

When those six properties are present together, the system becomes governable rather than merely impressive.

A Reference Architecture That Stays Small

The following reference design is intentionally modest. It avoids speculative complexity while preserving the architectural seams that matter:

User / Front-End
  -> Orchestrator API (FastAPI)
    -> LangGraph workflow runtime
      -> A2A client
        -> Specialist Agent A (research)
          -> MCP server for retrieval / files / browser / prompts
          -> ACP-compatible HTTP facade (optional legacy/partner integration)
        -> Specialist Agent B (planning)
          -> MCP server for policy / calendar / task tools
          -> ACP-compatible HTTP facade (optional)
        -> Specialist Agent C (execution)
          -> MCP server for ticketing / notifications / deployment tools
          -> ACP-compatible HTTP facade (optional)
    -> OpenTelemetry collector/export pipeline
    -> Container image + signed release metadata

This structure keeps agent coordination and tool coordination separate while allowing REST-native interop edges where required by legacy or partner ecosystems. It also limits the coordinator’s responsibilities: it plans, routes, monitors, and aggregates. It does not pretend to be every specialist at once.

Why These Packages Fit Together

MCP SDKs for tool and context surfaces

The official MCP Python SDK supports MCP clients and servers, exposes resources, prompts, tools, supports stdio, Server-Sent Events, and Streamable HTTP, and provides convenient FastMCP and lower-level server patterns . The official TypeScript SDK similarly provides split client and server packages plus thin runtime adapters for Node, Express, and Hono . That makes MCP suitable for the capability layer regardless of whether a team prefers Python or TypeScript.

A2A SDKs for peer-agent collaboration

The A2A project publishes official SDKs for Python, Go, JavaScript, Java, and .NET, and the protocol itself gives teams a first-class task model, Agent Card discovery, streaming, polling, and webhook push delivery . That is exactly what a coordinator needs when delegating real work to other agents.

ACP patterns for REST-native interop and migration-aware design

ACP documentation and OpenAPI material provide practical patterns for HTTP-native agent manifests, run handling, and event-oriented execution semantics , . These patterns are useful where organizations need API-gateway controls, standard REST lifecycle tooling, or partner integration through familiar HTTP contracts.

Given ACP convergence toward A2A, use ACP-compatible seams as integration adapters and keep core orchestration decisions protocol-portable .

LangGraph for durable orchestration

LangGraph is the strongest when workflows are stateful, long-running, and partially deterministic. Its documented strengths are durable execution, human-in-the-loop intervention, memory, and production-ready deployment for stateful agents . Those properties map naturally to the orchestrator layer.

LangChain for high-level agent ergonomics

LangChain’s documented value is quick agent creation, model/provider integrations, and higher-level abstractions. The LangChain docs also explicitly position LangGraph as the lower-level orchestration substrate for advanced needs . That division of labor is useful: use LangChain where you want convenience, and LangGraph where you want explicit control.

FastAPI and Pydantic for typed service boundaries

FastAPI provides high-performance APIs, automatic OpenAPI generation, and strong request and response typing around standard Python type hints . Pydantic complements it with fast validation, JSON Schema emission, strict or lax parsing modes, and typed data models that work well across APIs and tool schemas . For agent systems, that means less ambiguity at every ingress and egress point.

pytest for repeatable workflow verification

pytest remains a strong testing surface because it scales from simple tests to complex functional suites, supports readable assertions, fixture-based setup, and a deep plugin ecosystem . In orchestration systems, the readability of failed assertions matters because failures are often graph- and state-related rather than single-function bugs.

OpenTelemetry for system-wide visibility

OpenTelemetry is vendor-neutral and standardized around traces, metrics, and logs, with a collector model that lets teams instrument many languages and export to the observability backend of their choice . For multi-agent systems, this is how you stop distributed ambiguity from becoming operational blindness.

Docker, SLSA, and Sigstore for portable and assurance-oriented delivery controls

Docker makes the container the unit of development, testing, and deployment . SLSA provides a structured framework for software supply-chain integrity and provenance . Sigstore provides open-source signing and verification tooling, including support for transparent ledger-backed provenance workflows . Those controls are especially relevant given the supply-chain lessons already discussed in the axios compromise review. SLSA levels, attestations, and Sigstore signatures can improve integrity evidence and tamper-detection capability, but they do not by themselves guarantee software security, legal compliance, or absence of compromise.

A Concrete Build Pattern

The most practical implementation pattern is three-layered.

Layer 1: Orchestrator service

Use FastAPI as the externally reachable API surface and LangGraph as the execution engine. The orchestrator should:

  1. Receive user requests.
  2. Create workflow state.
  3. Decide which specialist agent should receive which subtask.
  4. Aggregate final artifacts and present them back to the caller.

The orchestrator should not directly own every tool. It should own routing, policy enforcement, and aggregation.

Layer 2: Specialist agents exposed through A2A

Each specialist agent should expose an Agent Card, declare its supported interface, and communicate in terms of tasks, messages, and artifacts. A research agent, for example, might support streaming and push notifications because document synthesis is often long-running. A policy agent might remain more synchronous.

That gives the coordinator clear collaboration contracts instead of improvised RPC wrappers.

Layer 2B: Optional ACP-compatible interop edge

Where partner ecosystems or existing platform standards are REST-first, publish ACP-compatible facades that map to specialist-agent capabilities. Keep this edge adapter-thin and avoid duplicating business logic.

Layer 3: Tooling behind MCP

Each specialist agent should use MCP internally for capabilities that behave like tools or resources: search connectors, retrieval layers, file systems, browser automation, prompts, calculators, or calendar integrations. This keeps the capability layer inspectable and more easily permissioned.

A Deployable Outcome: One Minimal Production Slice

A useful first production slice is a three-agent document workflow:

  1. A research agent gathers sources and extracts structured notes through MCP-connected retrieval tools.
  2. A synthesis agent transforms those notes into a draft and requests clarifications if needed.
  3. A delivery agent packages the output, stores it, and notifies downstream systems.

The orchestrator coordinates those agents over A2A. Each specialist uses MCP for its concrete tools. LangGraph persists the global state. FastAPI exposes the entrypoint. OpenTelemetry traces the full span tree. Docker packages the services.

That slice is simple enough to ship, but sophisticated enough to demonstrate the real value of the architecture: clear protocol boundaries, durable execution, typed contracts, and observable flow.

Suggested Repository Shape

agent-platform/
  apps/
    orchestrator/
      main.py
      graph.py
      routes/
    research-agent/
      a2a_server.py
      mcp_server.py
    synthesis-agent/
      a2a_server.py
      mcp_server.py
    delivery-agent/
      a2a_server.py
      mcp_server.py
  packages/
    schemas/
    telemetry/
    shared_clients/
  tests/
    unit/
    integration/
    contract/
    e2e/
  docker/
    Dockerfile.orchestrator
    Dockerfile.agent
    compose.yaml

This shape does two useful things. It makes service boundaries explicit, and it gives test scope names that match actual engineering concerns.

Testing Strategy That Matches the Architecture

Do not test an orchestration system as if it were a library with one entrypoint. Test it in layers.

  1. Unit tests should cover routing decisions, schema validation, and graph node behavior.
  2. Contract tests should verify MCP tool schemas and A2A message or task expectations.
  3. Integration tests should run the orchestrator against local specialist agents and validate end-to-end state progression.
  4. E2E tests should run containerized services and verify user-visible outcomes, timeouts, retries, and failure recovery.

pytest is a strong fit here because fixtures can stand up mocked MCP servers, local A2A agents, and transient orchestration state without burying the setup logic inside opaque helpers .

Observability Requirements

Observability in agentic systems must answer more than “did the request fail?” It should answer:

  1. Which workflow node made the routing decision?
  2. Which A2A task ID corresponds to the user-visible request?
  3. Which MCP tool calls were invoked, in what order, and with what latency?
  4. Where did retries, human input, or auth-required pauses occur?
  5. Which artifact version was produced and by which span tree?
  6. Which human approval checkpoint altered workflow progression and why?

OpenTelemetry is useful here because it can represent the orchestrator span, the delegated A2A task spans, and the downstream tool-invocation spans in one trace lineage . That makes post-incident review materially easier.

Enterprise Deployment Profile: Tenant-Aware, Cross-Border, and Human-Centered

Tenant-aware orchestration controls

  1. Scope credentials, tool catalogs, and policy bundles by tenant.
  2. Isolate traces and run identifiers so tenant data never co-mingles in operational views.
  3. Apply per-tenant rate limits and task-priority controls to prevent noisy-neighbor effects.

Cross-border and jurisdiction-aware operation

  1. Keep data residency and retention settings configurable by region.
  2. Separate control-plane metadata from content payloads where legal constraints differ.
  3. Preserve policy-driven protocol routing so jurisdiction constraints do not force architecture rewrites.

Human-in-the-loop and practical HCI

  1. Show clear workflow state, delegated task status, and ownership transitions.
  2. Make approval prompts specific about side effects and data movement.
  3. Provide predictable pause, resume, and escalation controls for operators.

These controls reduce operational ambiguity and support safer autonomous execution in regulated, multi-team environments.

Deployment Controls That Should Not Be Skipped

Container packaging

Package the orchestrator and each specialist agent independently. Docker’s main value here is not fashion. It is environmental consistency across development, CI, test, and production .

Provenance and signing

Adopt SLSA-aligned provenance generation and sign build artifacts with Sigstore-supported tooling. The objective is practical, evidence-backed integrity controls rather than paper-only implementation. The point is to prevent your orchestration platform from becoming another opaque deployment surface , .

Transport and trust boundaries

Use MCP transports appropriate to deployment mode. The official Python SDK recommends Streamable HTTP as the production transport choice for scalable deployment patterns . For A2A, publish a clear Agent Card, use HTTPS in production, and ensure task and webhook authorization is scoped correctly , .

Twelve Implementation Lessons

  1. Keep A2A at the peer-agent layer and MCP at the capability layer.
  2. Use LangGraph for stateful orchestration rather than hiding workflow state inside prompt loops.
  3. Use LangChain where abstraction helps, not where it conceals critical routing logic.
  4. Treat FastAPI and Pydantic schemas as policy boundaries, not just convenience wrappers.
  5. Test protocol contracts directly instead of assuming framework defaults will remain stable.
  6. Trace every delegation edge and every tool invocation from the start.
  7. Prefer simple specialist agents over one overloaded “super agent.”
  8. Containerize each service independently so rollout and rollback stay explicit.
  9. Add provenance and signing before the platform becomes operationally important.
  10. Optimize for explainability and replaceability, not only for demo speed.
  11. Use ACP-compatible REST seams when they reduce integration friction, but keep standards convergence in roadmap planning.
  12. Design every critical workflow with explicit human approval and override paths.

Glossary

Durable execution

The ability of a workflow runtime to persist state across failures and resume from a known checkpoint, a core LangGraph design goal .

Streamable HTTP

An MCP transport mode recommended for production deployment in the official Python SDK because it supports scalable HTTP-based integration patterns .

Agent Card

The A2A discovery manifest that tells clients which interfaces, skills, and security schemes an agent supports .

Agent Manifest

An ACP-oriented description surface for discovery and interoperability, including agent identity, capabilities, and metadata .

Structured validation

Type-driven input or output validation, commonly implemented with Pydantic models or typed schemas to reduce ambiguity across service boundaries .

Frequently Asked Questions

What is the simplest deployable architecture for MCP, A2A, and ACP-aware interoperability?

One orchestrator service plus two or three specialist agents is enough. The orchestrator uses A2A to delegate tasks. Each specialist agent uses MCP to reach concrete tools and resources. ACP-compatible facades can be added at partner-facing boundaries where REST-native interoperability is required.

Should I choose LangGraph or LangChain for orchestration?

Choose LangGraph when you need explicit durable workflow control. Use LangChain on top when its higher-level abstractions improve development speed without hiding critical execution logic , .

Which Python packages are enough to start building this stack?

For a practical Python-first baseline, mcp, a2a-sdk, langgraph, langchain, fastapi, pydantic, pytest, httpx, opentelemetry-sdk, uvicorn, and Docker-based packaging are sufficient for a strong first slice , .

Should I start new projects with ACP or A2A for agent-to-agent collaboration?

For many long-lived greenfield collaborations, A2A is often a lower-regret default today because of active protocol momentum and documented ACP convergence direction. ACP patterns remain useful for REST-first interoperability edges and migration-minded design , .

How should I test agent-to-agent workflows without creating flaky suites?

Separate contract tests from end-to-end tests. Use mocked or local A2A agents for protocol checks, then run a smaller number of containerized end-to-end workflows for full-path validation.

Do I need supply-chain controls for an internal agent platform?

In most organizations, supply-chain controls are advisable even for internal agent platforms based on risk profile, regulatory exposure, and internal assurance requirements. Internal platforms still ship containers, dependencies, and artifacts that can be tampered with or misattributed , .

What is the first observability signal I should add?

Add end-to-end tracing that ties one user request to one orchestration run, all delegated A2A tasks, and all MCP tool calls. Without that lineage, later debugging becomes unnecessarily speculative.

How do tenant-aware and cross-border controls affect protocol design?

They require explicit policy partitioning, region-aware data handling, and identity federation choices that remain portable across clouds and partner ecosystems. Protocol layering helps preserve those controls without excessive custom glue.

Do these practices apply identically across UK, EU, US, Canada, Hong Kong, China, and Australia?

No. Privacy, transfer, residency, and sector-specific obligations vary by jurisdiction and industry. Use these practices as technical design guidance and validate legal and regulatory requirements for each operating context.

Conclusion

The most valuable agentic stacks are not the ones with the most moving parts. They are the ones where each moving part has a justified role. MCP should expose capabilities. A2A should coordinate peer agents. ACP patterns should be used where REST-native interoperability improves integration and migration outcomes. LangGraph should manage durable workflow state. LangChain should accelerate high-level agent construction where useful. FastAPI, Pydantic, pytest, OpenTelemetry, Docker, SLSA, and Sigstore can make the system more typed, testable, observable, portable, and better evidenced for release assurance.