At the architecture review for Sneeuberg Insurance's claims-triage agent, two teams arrived with what they believed were competing proposals. The claims engineering team wanted to build the agent on LangGraph. The integration team wanted to build it on MCP. The review chair, reasonably, asked which one the insurer should standardise on. Sneeuberg Insurance is fictional, and its systems and figures are illustrative.
The honest answer was both, or neither, depending on the question. LangGraph and the Model Context Protocol do different jobs. One decides how a piece of work moves from step to step and what it remembers along the way. The other standardises how an application discovers and calls tools and data sources. A design can use either without the other, and many good designs use both.
The more important point came later in the review. Even with both in place, the design still had no answer to the questions an insurer's risk committee asks first: whose authority is the agent acting under, who approved the payment recommendation, and where is the record kept? Neither component answers those, and neither claims to.
Two different jobs
Part 1 put LangGraph in the orchestration family and the MCP SDKs in the integration space beside the development SDKs. The distinction is worth making precise, using each project's own description, checked on 7 November 2026.
LangGraph's overview calls it "a low-level orchestration framework and runtime for long-running, stateful agents". Work is a graph of nodes and edges over shared state. Checkpoints let a run resume after a failure or a pause, and an interrupt lets a person inspect or edit state before the run continues.
The MCP specification (revision 2026-07-28) describes "an open protocol that enables seamless integration between LLM applications and external data sources and tools". Hosts run clients, clients connect to servers, and servers offer three kinds of feature: resources (context and data), prompts (templates) and tools (functions the model can call). Since December 2025 the protocol has been hosted by the Linux Foundation's Agentic AI Foundation.
Put simply, LangGraph answers "what happens next, and what do we know so far?" MCP answers "what can I reach, and how do I call it?" The first is about control flow and state. The second is about connection and discovery. CloudNala's earlier article API, function calling and MCP are different layers separated MCP from the APIs beneath it. This article separates it from the orchestration above it.
One claim, followed through both
Sneeuberg's triage agent handles first notification of loss for household claims. A policyholder reports a burst geyser. The agent must gather the details, check that the policy was in force, retrieve the relevant wording, estimate whether the claim falls inside the excess, and route it: fast-track, assessor visit, or referral to the special investigations unit.
Here is what each component does along that path.
The graph owns the sequence. LangGraph holds a state object for the claim: the policy number, the reported cause, the documents received, the cover decision so far and the route chosen. Each node reads and updates that state. Some nodes are plain code, such as the check that the policy was active on the date of loss. Some call a model, such as the step that classifies the cause from the policyholder's description. Edges decide what runs next. A referral edge fires when fraud indicators are present, and nothing else can reach the referral node.
MCP owns the connections. The policy administration system, the claims system and the document store each sit behind an MCP server. When a node needs the policy wording, it calls a tool on the document server. The integration team writes each server once, and any MCP-capable host at Sneeuberg can use it, not only this agent. LangChain's documentation describes an MCPAdapter for connecting LangChain agents to MCP servers, checked on 7 November 2026, so the graph and the protocol meet at a well-defined seam.
The graph owns the pause. When the route is "fast-track payment", the graph reaches an interrupt. The run stops, its state is checkpointed, and a claims handler sees the recommendation with its evidence. The handler approves, edits or rejects, and the run resumes from the checkpoint. MCP has no concept of this step. It is a property of the workflow.
MCP owns the discovery. If the document team adds a tool for retrieving endorsements, any client connected to that server can list it. The graph does not change until someone decides a node should use it. That decision is deliberate, and it should be: a new tool appearing in a list is not the same as a new step being approved in a process.
What each one leaves out
The value of separating the two is that it shows what each leaves to the platform.
| Concern | LangGraph | MCP | Who supplies it at Sneeuberg |
|---|---|---|---|
| Sequence and branching | Yes | No | The graph |
| State across steps and restarts | Yes, through checkpoints | No | The graph, with a durable checkpoint store |
| Pause for a person | Yes, through interrupts | No | The graph, with the claims workbench |
| Tool and resource discovery | No | Yes | MCP servers |
| Transport-level authorisation to a server | No | Optional, specified for HTTP transports | An identity provider and the MCP servers |
| Business authority to act | No | No | Policy rules and delegation limits |
| Audit record of a decision | Partly, through state history and traces | No | A case record owned by claims |
| Risk ownership | No | No | A named business owner |
Two rows deserve a closer look.
Authorisation is not authority. The MCP authorisation specification is optional and applies to HTTP-based transports. When used, it treats the MCP server as an OAuth 2.1 resource server and requires tokens issued for that specific server. That is valuable: it stops a client from reaching a server it should not. It does not tell the claims server whether this agent, acting for this handler, may recommend a payment of this size on this policy. That rule belongs to Sneeuberg's delegation-of-authority matrix, and it has to be enforced somewhere the agent cannot talk its way around. Agent capability is not agent authority sets out the distinction.
The protocol says so itself. The specification's security section states that "MCP itself cannot enforce these security principles at the protocol level" and asks implementers to build consent and authorisation flows into their applications. That is a candid statement of scope, not a weakness. It means the platform has to supply the enforcement.
Where the controls go
Sneeuberg's final design placed each control where it could actually be enforced.
- Identity. The agent runs under a workload identity, and each run carries the identity of the handler or channel it acts for. MCP servers receive tokens scoped to that server and that purpose, as the specification requires for HTTP transports.
- Authority. The claims server checks every write against the delegation matrix, not against the agent's request. A fast-track recommendation above the handler's limit is refused by the server, whatever the graph says.
- Approval. The interrupt is in the graph, but the decision is recorded in the claims system, against the handler's identity, with the evidence the agent showed.
- Gateway. Calls to MCP servers pass through a gateway that logs them and enforces an allow-list per agent. As The gateway is a control point, not a trust boundary warns, the gateway helps, but each server still checks its own permissions.
- Audit. The case record, not the trace, is the evidence. The trace explains how the agent reached its recommendation. The case record shows who decided, under which rule.
None of this depends on LangGraph or MCP specifically. Swap the graph for another orchestration framework and the controls stay where they are. Swap MCP for direct API calls and the controls still stay where they are. That portability is a good test of whether the controls are really in the platform or only in the framework.
When you need one, the other or both
Not every agent needs both components.
- Orchestration without MCP suits a single agent with a few tools that only it will use. Direct function calls to well-defined internal APIs are simpler, and nothing is lost if there is no second consumer.
- MCP without heavy orchestration suits an assistant inside a host application, such as an IDE or a chat client, where the host already runs the loop and the question is only which tools and data it can reach.
- Both suits Sneeuberg's case: a long-running, multi-step process with a human pause, calling systems that other agents and hosts will also need.
The wrong reason to adopt either is that it appeared on a list. The right reason is that a named requirement, such as a resumable pause or a tool that several hosts must share, is met by it and not by something simpler.
Questions for the architecture review
| Question | If the answer is no |
|---|---|
| Does the process have multiple steps, branches or a pause for a person? | You may not need an orchestration framework |
| Must the run survive a restart mid-process? | Durable checkpoints are optional |
| Will more than one host or agent use the same tools? | Direct function calls may be enough |
| Is every MCP server's identity and token scope defined? | Do not connect it yet |
| Is business authority enforced by the system of record, not the agent? | The design relies on the model behaving |
| Is the approval recorded outside the trace, against a named person? | You have a log, not evidence |
| Can you swap the framework without moving the controls? | The controls are in the wrong place |
Key points
- LangGraph manages workflow, state and transitions. MCP standardises how hosts discover and call tools, resources and prompts.
- They are complementary. A design can use either alone, and many good designs use both.
- MCP's authorisation, where used, controls access to a server. It does not decide business authority.
- Neither supplies enterprise identity, authority rules, an audit record or a risk owner. Those belong to the platform.
- Place controls where they survive a change of framework or protocol.
This is part 2 of Building an Enterprise Agent Platform Without Buying Everything. Previous: Twenty agent repositories, five capability families. Next: Framework, SDK, workflow tool or agent platform?.
How CloudNala can help
CloudNala reviews agent designs that combine an orchestration framework with MCP. We map which component owns sequence, state, pause and discovery, then trace identity, authority, approval and audit to the place each is actually enforced. The output is a control placement that survives a change of framework, and a short list of MCP servers that are ready to connect and those that are not.
Background reading: the LangGraph overview, the MCP specification and its authorisation section, all checked on 7 November 2026. For MCP in depth, see MCP in plain language and The enterprise MCP gateway.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Agent Platform Review or write to us at consult@cloudnala.co.za