Building Agentic Orchestration with MCP, A2A, ACP, LangGraph, and LangChain: A Deployable Open-Source Playbook

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 [1], [2]. 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 [3]-[11].

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 [12], [13].

Other stacks exist. This one coheres. One coordinator delegates over A2A; specialists reach tools and context through MCP. The whole thing fits in a single team’s head. That matters more than feature checklists, because a stack nobody fully understands is a stack nobody can defend when something breaks at 2 a.m. under production pressure.

Key Terms

Agentic orchestration

A design pattern in which a coordinator agent decomposes user requests into subtasks and delegates them to specialised agents with explicit state management, observability, and approval controls.

LangGraph

A Python framework for building stateful, multi-step agent workflows as directed graphs with durable checkpointing and human-in-the-loop support.

LangChain

A framework that provides composable abstractions for connecting language models to tools, retrievers, and memory, simplifying common LLM application patterns.

Agent Communication Protocol (ACP)

A REST-oriented agent interoperability protocol with synchronous, asynchronous, and streamed execution patterns, currently converging into A2A under Linux Foundation collaboration.

Directed acyclic graph (DAG)

A graph structure with directed edges and no cycles, used in workflow engines to represent task dependencies and ensure deterministic execution ordering.

The Design Objective

Framework maximalism is not the goal. Governability is. Ask yourself: could you explain every delegation edge to an incident reviewer at short notice? Six properties, all present simultaneously, separate a system you can defend in production from one that merely demos well:

1. User requests become durable workflows, not ephemeral prompt-response pairs.
2. Workflow fragments delegate to specialist agents carrying explicit task state.
3. Tools and resources surface through typed, structured capability boundaries.
4. Failures become explainable via traces, logs, metrics, and test evidence.
5. Artifacts ship portable with verifiable provenance.
6. Human approval checkpoints remain visible and explicit across every protocol boundary.

Drop even one. The system reverts to impressive but ungovernable.

A Reference Architecture That Stays Small

The following reference design is intentionally modest. No speculative abstractions, no “we might need this later” layers. It preserves only the architectural seams that actually 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 legacy or partner ecosystems demand them. Notice what the coordinator does not do: it never pretends to be every specialist at once. It plans, routes, monitors, aggregates. Full stop.

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 [14]. The official TypeScript SDK similarly provides split client and server packages plus thin runtime adapters for Node, Express, and Hono [15]. 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 [16]. 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 [1], [2]. 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 [12].

LangGraph for durable orchestration

Stateful workflows break prompt loops. LangGraph handles exactly this problem: durable execution, human-in-the-loop intervention, memory persistence, and production-ready deployment for stateful agents [3]. If your orchestrator loses state on restart, you do not have an orchestrator; you have an expensive autocomplete endpoint. 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 [4]. 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 [5]. 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 [6]. 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 [7]. 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

Blind spots kill multi-agent systems quietly. OpenTelemetry is vendor-neutral and standardized around traces, metrics, and logs, with a collector model that lets teams instrument across languages and export to whatever observability backend they already trust [8]. Without trace continuity, distributed ambiguity compounds into operational blindness faster than most teams expect.

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

Docker makes the container the unit of development, testing, and deployment [9]. SLSA provides a structured framework for software supply-chain integrity and provenance [10]. Sigstore provides open-source signing and verification tooling, including support for transparent ledger-backed provenance workflows [11]. 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

Three layers. That is the practical minimum.

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

Why this shape? Two reasons. Service boundaries become visible in the directory tree itself, not buried in import graphs. And test scope names (unit, integration, contract, e2e) map directly to actual engineering concerns rather than arbitrary folder conventions.

Testing Strategy That Matches the Architecture

Orchestration systems are not libraries. They have no single entrypoint. Test them in layers, or accept that your test suite will lie to you about reliability.

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 [7].

Observability Requirements

“Did the request fail?” is the wrong first question for agentic observability. The right questions are sharper:

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 [8]. That makes post-incident review materially easier. When ACP-compatible REST edges are present, include run IDs and API gateway correlation IDs in the same trace context so cross-protocol incident analysis remains coherent.

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.
4. Apply tenant-specific API gateway policy on ACP-compatible endpoints so REST integrations follow the same partitioning rules as A2A tasks and MCP tool access.

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 [9].

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 [10], [11].

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 [14]. For A2A, publish a clear Agent Card, use HTTPS in production, and ensure task and webhook authorization is scoped correctly [17], [16]. For ACP-compatible surfaces, enforce strong REST auth, signed run metadata where possible, and gateway-level policy controls on run and event endpoints [2].

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.

Implementation Questions

What is the simplest deployable architecture for MCP, A2A, and ACP interoperability for agentic orchestration framework?

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.

When should teams choose LangGraph versus LangChain for orchestration control for agentic orchestration framework?

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 [3], [4]. This choice is orthogonal to protocol layering: MCP still handles tool boundaries, A2A still handles peer delegation, and ACP-compatible seams can still expose REST-native partner integration.

Which Python packages are sufficient for a pragmatic first implementation for agentic orchestration framework?

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 [14], [16]. If ACP-compatible REST interoperability is required on day one, add OpenAPI tooling and gateway middleware that can enforce auth, rate policy, and run-lifecycle observability at the HTTP edge [2].

For new projects, should teams prioritize A2A or ACP for agent collaboration for agentic orchestration framework?

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 [12], [13].

How can teams test agent-to-agent workflows without introducing flaky suites for agentic orchestration framework?

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. If ACP-compatible endpoints are part of the path, add REST contract tests for manifest and run endpoints so protocol drift is caught before integration rollout.

Do internal agent platforms still require supply-chain security controls for agentic orchestration framework?

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 [10], [11].

What is the first observability signal that improves debugging in agent orchestration for agentic orchestration framework?

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

How do tenant-aware and cross-border controls reshape protocol design choices for agentic orchestration framework?

They require explicit policy partitioning, region-aware data handling, and identity federation choices that remain portable across clouds and partner ecosystems. In practice, teams should align MCP tool policy, A2A task authorization, and ACP-compatible gateway policy so tenant and jurisdiction controls remain consistent across every protocol boundary.

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

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

Complexity is cheap. Justified complexity is rare. The most valuable agentic stacks are not the ones with the most moving parts; they are the ones where every part earns its place. MCP exposes capabilities. A2A coordinates peer agents. ACP patterns fill REST-native interop gaps where they reduce real friction. LangGraph manages durable workflow state. LangChain accelerates high-level agent construction where the convenience genuinely outweighs the abstraction cost. FastAPI, Pydantic, pytest, OpenTelemetry, Docker, SLSA, and Sigstore collectively make the system typed, testable, observable, portable, and better evidenced for release assurance. Ship that. Then iterate.

Technical Appendix