Agent Architecture Is a Constraint Problem, Not a Technology Choice
MCP is dead. A2A is the future. Everything should be a workflow. Most of these debates are category errors. The tools are not competing. They manage different constraints, and the real decision is which trade-offs your organization can afford.
Walk into any engineering org building with AI agents right now and you will hear the same argument, in slightly different words. MCP is dead. A2A is the future. Everything should be a workflow. No, everything should be an agent. The argument never resolves, because it is the wrong argument. It compares mechanisms that sit on different layers of the problem, which is a little like arguing whether databases beat networks. One side is not winning. Both sides are answering a question nobody asked clearly.
The short version: Agent architecture decisions are constraint decisions. The hard part is not picking a technology. It is naming which constraint is currently binding, and managing the conflicts that show up when two constraints bind at once. The same architecture is correct in one environment and irresponsible in another, and the only thing that changed was the constraint. Technology is downstream of the constraint, not the other way around.
I want to make that claim precise, because it is the whole article. AI agent architecture is not a menu of named patterns you select from. It is the act of deciding which constraints deserve optimization and which mistakes your system is allowed to make. Get that ordering wrong and you ship something that demos beautifully and then refuses to reach production-grade, and nobody on the team can say exactly why it stalled.
The tool debate is a category error, not a close call
The reason the MCP-versus-A2A argument never ends is that the two protocols are not competing. They answer different questions about different parts of the system. Treating them as rivals is the category error that keeps the debate alive.
Most engineering writing on this topic catalogs the patterns. Here is single-agent, here is orchestrator-worker, here is hierarchical multi-agent, here is the protocol comparison, and here, bolted on at the end, is a production-readiness checklist. The catalog is useful the way a parts list is useful. It tells you what exists. It does not tell you what to choose, because the choice does not live in the catalog. It lives in your constraints.
A pattern catalog answers "what are the options." A constraint analysis answers "which option is correct for me, right now, given what I cannot change." Those are different questions, and the second one is the only one that produces an architecture you can defend in a board update. The failure mode I see in delivery orgs is teams optimizing the part of the system that was never binding, then wondering why the elegant design did not move the number that mattered.
Three axes most teams never separate
Start by pulling the problem apart. Almost every agent system, however it is drawn on a whiteboard, makes three separable decisions. They are usually tangled together in the same diagram, which is why the tool debate feels unwinnable. Separate them and the debate dissolves into three smaller, answerable questions.
Axis 1, knowledge and context. What does the system load, remember, and forget? This is the retrieval strategy, the memory model, the context-window budget, the question of what the agent knows at the moment it acts.
Axis 2, tool access and execution. How does the system reach the outside world and run actions? This is where tool definitions live, where calls are made, where side effects happen. MCP is largely an Axis 2 question. It standardizes how a model discovers and invokes tools.
Axis 3, coordination and state. How does work move between steps, or between agents, and how is progress persisted? This is orchestration, handoff, the shape of the control flow, who decides what happens next. A2A is largely an Axis 3 question. It standardizes how agents hand work to one another.
Now the category error is obvious. MCP and A2A are not competitors, they are answers on different axes. Asking which is better is asking whether your tool-access layer should beat your coordination layer. The question does not parse. A serious system makes a decision on all three axes, and the decisions interact, but they are not the same decision and they do not trade off against each other directly.
Five constraints decide what each axis should look like
Knowing the three axes does not tell you how to design them. Five constraints do. These are the forces you usually cannot change in the timeframe of the decision, which is exactly why they bind. Each one pushes each axis toward a different design, and the pressure is rarely the same across axes.
Novelty. How new is the problem to the model? A task the model has seen a thousand times tolerates a thin context and a loose control flow. A genuinely novel task needs richer context loading and tighter verification, because the model is more likely to be confidently wrong.
Rate of change. How fast does the environment shift underneath the system? A stable domain lets you bake assumptions into the architecture. A fast-moving one punishes anything hardcoded and rewards designs that re-discover the world at run time.
Failure cost. What does a wrong action cost? A wrong summary is cheap. A wrong wire transfer is not. As failure cost rises, the tool-access axis moves toward least-privilege and human-in-the-loop gates, and the coordination axis moves toward deterministic, auditable control flow rather than open-ended agent autonomy.
Scale. Volume and concurrency. A handful of calls a day tolerates expensive, schema-heavy patterns. Millions of calls a day make token economics and latency the binding force, and push every axis toward compression and caching.
Governance. Least-privilege, auditability, regulatory exposure. This is not a checklist you append at the end. It is a constraint that changes the verdict. A system that is correct for an internal prototype is irresponsible the moment it touches regulated data, and the architecture has to reflect that before the data arrives, not after the audit.
The mistake the SERP makes, and the mistake most teams make, is treating governance as a final-mile concern. Governance is not a compliance checklist, it is a binding design constraint that reshapes the tool-access and coordination axes from the first diagram.
The decision matrix
Here is the whole framework on one page. Rows are the three axes. Columns are the five constraints. Each cell names the design pressure that constraint applies to that axis. This is the artifact to keep next to the whiteboard. It does not tell you which tool to buy. It tells you where the pressure is, so you can see which constraint is binding before anyone says the word "MCP."
| Axis \ Constraint | Novelty | Rate of change | Failure cost | Scale | Governance |
|---|---|---|---|---|---|
| Knowledge and context | Load richer context; verify retrieved facts before acting | Re-fetch at run time; avoid baked-in knowledge that goes stale | Prefer grounded, cited context over model memory; log what was loaded | Compress aggressively; cache embeddings; cap context budget | Restrict which sources are loadable; record provenance of every fact |
| Tool access and execution | Add verification and dry-run steps before live calls | Discover tools dynamically rather than hardcoding schemas | Least-privilege scopes; human-in-the-loop gate on irreversible actions | Move from full-schema loading to code-execution invocation; batch calls | Scoped credentials per tool; full audit trail of every invocation |
| Coordination and state | Tighter control flow with checkpoints; less open-ended autonomy | Keep coordination logic declarative so it can be rewritten fast | Deterministic, replayable orchestration over emergent agent chatter | Stateless or externally-persisted state; avoid long-lived agent memory | Explicit ownership boundaries; every handoff is logged and attributable |
Read it by column when you know your binding constraint. If failure cost is what keeps you up at night, read the failure-cost column top to bottom and you have your architecture brief. Read it by row when you are debugging a specific axis that is misbehaving. Either way, the matrix replaces "which pattern" with "which pressure," and the second question has answers.
To see the matrix work, take a concrete case: a high-volume customer-support agent handling tens of thousands of conversations a day. Run the columns. The binding constraint is scale, and the conflict it creates is token cost against observability. On the knowledge axis, scale says compress hard and cache the facts the agent reuses on every ticket instead of reloading them. On the tool-access axis, it says move from full-schema tool loading to code-execution invocation and batch the calls. On the coordination axis, it says put the work on a deterministic workflow spine with evaluations on the output, not an open-ended agent improvising each resolution. The trade-off you are accepting is explicit: less free-form autonomy per conversation in exchange for execution you can run cheaply, log completely, and evaluate at volume. That is the architecture brief, and not once did you have to decide whether MCP or A2A was better.
The interesting failures happen when two constraints conflict
A single binding constraint is the easy case. You read its column, you accept the design pressure, you ship. Real systems are harder, because two constraints bind at the same time and pull the same axis in opposite directions. The architecture decision is not which constraint to optimize. It is which conflict you are willing to accept.
These conflicts recur as archetypes. None of them is about a specific company. They are the shape of the problem.
- Speed versus safety. Novelty wants tight verification on the tool-access axis. Scale wants you to skip it. A high-volume system facing genuinely novel inputs has to choose where to spend its verification budget, because it cannot verify everything at that volume.
- Token cost versus observability. Scale pushes the context axis toward aggressive compression. Governance pushes it toward logging full provenance. Compress too hard and the audit trail thins out. Log everything and the token bill is the project's largest line item.
- Governance versus convenience. Least-privilege on the tool axis means scoped credentials per tool and a gate on irreversible actions. Convenience means one broad credential and open autonomy. Every team feels this one, and the convenient choice is invisible until the incident.
- Least-privilege versus coordination. Tight scopes on Axis 2 collide with rich handoff on Axis 3. Agents that can hand work to one another freely are easier to build and harder to contain. The more the coordination axis opens up, the harder least-privilege becomes to enforce.
- Flexibility versus reliability. Rate of change wants declarative, rewritable coordination. Failure cost wants deterministic, replayable control flow. A fast-moving, high-stakes domain wants both and can fully have neither.
Naming the conflict is the work. A team that says "we are accepting the token-cost-versus-observability conflict in favor of observability, because we are in a regulated domain" has made an architecture decision. A team that argues about MCP versus A2A has not. The conflict, not the protocol, is what the board update should be about.
The implementation model quietly changes the constraint economics
Here is where the abstract framework meets a hard number, and where one of the constraints moves under your feet.
Consider the tool-access axis under a scale constraint. The naive implementation of a tool-using agent loads every tool's full schema into the context window so the model can see what it can call. With a handful of tools this is free. With dozens of tools and rich schemas, the tool definitions alone can dominate the context budget before the agent has done any work.
In November 2025, Anthropic published a code-execution approach to the Model Context Protocol that reframes this. Instead of loading every tool schema up front, the model writes code that calls the tools, discovering and invoking them as functions rather than reading their full definitions into context. In a representative multi-tool workflow, the reported effect was a reduction of roughly 98 percent in token load, from around 150,000 tokens of tool definitions down to roughly 2,000. The exact figure is workflow-dependent and the "roughly" is doing real work in that sentence, so treat it as directional, not as a benchmark you can quote to a vendor.
The number is not the point. The mechanism is. Naive full-schema MCP and code-execution MCP are not the same architecture, they are two architectures with different economics. The same logical capability has a different cost curve depending on how it is implemented, which means the scale constraint and the token-cost-versus-observability conflict do not have fixed answers. They move when the implementation model changes. A scale constraint that looked binding under full-schema loading can stop being binding under code-execution invocation, and the architecture you would have defended last quarter is no longer the one you would defend now.
The cost reduction does not come for free. Moving tool work into an execution environment shifts the risk from context bloat to sandboxing, credential scope, and runtime isolation. The token bill falls, but you now own a code-execution surface that has to be sandboxed and a set of tool credentials that has to be scoped tightly, which is its own governance cost on the very axis you were trying to make cheaper.
This is the deeper reason the technology debate is downstream of the constraint analysis. Technologies change the economics of constraints. They do not replace the constraint analysis, they are an input to it.
Agent topology mirrors organizational topology
The constraint that decides more architectures than any other is the one least discussed in the engineering writing, because it is not an engineering constraint. It is an organizational one.
Agent topology mirrors organizational topology. A system owned end to end by one team can be a single agent with a simple control flow, because one team holds all the context and all the accountability. The moment ownership fragments, the architecture has to fragment with it, and it has to do so explicitly. When security owns the credential scopes, the platform team owns the tool layer, the product team owns the agent behavior, and compliance owns the audit trail, the system cannot stay a tangled single agent. It has to expose seams at exactly the boundaries where ownership changes hands, because that is where a human will eventually need to reason about who is responsible for what.
This is why the same logical system gets more explicit architecture as the organization behind it matures. The explicitness is not gold-plating. It is the architecture absorbing the organization's accountability structure. Conway's law was always about this, and agent systems make it sharper because the seams are where governance lives.
The practical consequence is a constraint I would put above most of the technical ones. Architecture maturity cannot exceed organizational maturity for long. A team that builds an elaborate multi-agent topology its operating model cannot own is building a system nobody is accountable for, and that is the premature-Stage-6 failure: the architecture is technically impressive and organizationally orphaned, so it stalls in the gap between demo and production. The fix is not a better protocol. The fix is matching the topology to who actually owns each piece, which usually means a simpler architecture than the team wanted, sequenced to grow as ownership clarifies.
Most engineering blogs treat agent architecture as a tooling problem. It is an operating-model problem wearing a tooling costume. The org chart is in the diagram whether you drew it there or not.
Two predictions you can hold me to
A framework that cannot be wrong is not worth much. Here are two falsifiable claims, each with the condition that would disconfirm it.
Prediction one. Agent-to-agent peer coordination, where autonomous agents hand work to one another as the primary control flow, will not become the dominant enterprise pattern by mid-2027. Most production enterprise systems will still run deterministic orchestration with agents as scoped workers, because failure cost and governance constraints favor replayable control flow over emergent coordination. This is disconfirmed if, by mid-2027, the major enterprise platforms ship peer agent-to-agent coordination as the default and it displaces orchestrator-worker in production systems handling regulated or high-failure-cost workloads.
Prediction two. Naive full-schema tool loading will stop being the high-volume default. Code-execution invocation and similar compression approaches will become standard for systems above a meaningful call volume, because the scale constraint makes the token economics impossible to ignore. This is disconfirmed if high-volume production agents in 2027 still load full tool schemas per call as the standard pattern, with code-execution invocation remaining a niche optimization.
Both predictions follow from the constraint analysis, not from a hunch about which vendor wins. If they are wrong, the framework is missing a constraint, and that is the useful kind of wrong.
What this leaves you with
The winning systems are hybrids, not because hybrid is a safe answer, but because no single architecture survives contact with all five constraints at once. The orgs that succeed know, before they build, which constraint is binding, which trade-off they are accepting, which new bottleneck they create by accepting it, and which architecture they have quietly inherited from their vendors' defaults.
So the next time the MCP-versus-A2A argument starts, do not pick a side. Ask which constraint is binding, on which axis, and what conflict you accept by answering it. The protocol is a detail you can change later.
But the constraint that settles the most arguments is the one that never shows up in a protocol comparison. The architecture you can actually run is the one your organization is built to own. Accountability has to line up with the seams in the system, and no topology outlives the operating model that maintains it. Get that alignment right and the technology questions shrink to details. Get it wrong and the most elegant stack still stalls between demo and production. That is the real decision underneath the tooling debate: not which technology, but which constraints your organization can absorb, and which mistakes it can afford when it is wrong.
