Juan Piaggio · 2026-10-15 · 7 min read · ai · architecture · strategy · agents
Three things happened in agentic development over the past year that get discussed as separate trends. Teams stopped betting on one large model to absorb end-to-end ambiguity and started decomposing work into role-bound specialists. Bespoke API integrations started giving way to an open context protocol. And autonomy stopped being a demo setting and became a product surface with permissions, checkpoints and telemetry attached.
They are the same movement, and the reason it matters commercially is that each one takes something that used to be differentiating and makes it ordinary.
A monolithic agent asked to handle a real business domain does not fail loudly. It drifts: the prompt grows to absorb every edge case, the failure modes stop being attributable, and nobody can say which part of the reasoning produced the wrong ticket. Splitting the work into a deterministic planner, a tool-execution engine and an adversarial evaluator does not make any single step smarter. It makes each step inspectable, independently testable, and replaceable without touching the rest.
That is why graph-based state machines — LangGraph, AutoGen and the rest — won over free-running loops. A graph is a commitment about what can follow what. It gives you somewhere to put a checkpoint, somewhere to resume from, and a finite set of transitions to reason about when something goes wrong. We have written before that decomposition is not free and stops paying past a point; the structure is what you are buying, and you should buy exactly as much as you will actually inspect.
The Model Context Protocol does something narrow and consequential: it replaces per-vendor, per-datastore glue with a client-server abstraction, so the reasoning layer stops being coupled to where the data lives. A tool is a tool whether it fronts Postgres, a SaaS backend, or a local runtime.
For engineering teams that is straightforwardly good — less brittle code, fewer rewrites when a backend changes. For product strategy it is sharper than that. If connecting a model to a system is standard work, then connecting a model to a system is not a product. A great many companies built their first AI offering on exactly that seam, and the seam is closing.
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 800 236" role="img">
<title>The layers above the state graph are becoming swappable; the state graph is not</title>
<rect x="1" y="8" width="560" height="56" rx="10" fill="var(--sand-1)" stroke="var(--border)" />
<text x="281" y="30" text-anchor="middle" font-size="11" fill="var(--text-muted)">REASONING</text>
<text x="281" y="49" text-anchor="middle" font-size="14" fill="var(--ink-1)">Planners, executors, evaluators</text>
<path d="M281 64 V81" stroke="var(--text-muted)" stroke-width="1.5" fill="none" />
<path d="M276 81 l5 7 5 -7 z" fill="var(--text-muted)" />
<rect x="1" y="88" width="560" height="56" rx="10" fill="var(--sand-1)" stroke="var(--border)" />
<text x="281" y="110" text-anchor="middle" font-size="11" fill="var(--text-muted)">CONTEXT</text>
<text x="281" y="129" text-anchor="middle" font-size="14" fill="var(--ink-1)">MCP clients and servers</text>
<path d="M281 144 V161" stroke="var(--text-muted)" stroke-width="1.5" fill="none" />
<path d="M276 161 l5 7 5 -7 z" fill="var(--text-muted)" />
<rect x="1" y="168" width="560" height="56" rx="10" fill="var(--primary-50)" stroke="var(--primary-600)" />
<text x="281" y="190" text-anchor="middle" font-size="11" fill="var(--primary-600)">STATE</text>
<text x="281" y="209" text-anchor="middle" font-size="14" fill="var(--ink-1)">Workflow, records, audit trail</text>
<path d="M561 36 H588" stroke="var(--text-muted)" stroke-width="1.5" fill="none" />
<path d="M588 31 l10 5 -10 5 z" fill="var(--text-muted)" />
<path d="M561 116 H588" stroke="var(--text-muted)" stroke-width="1.5" fill="none" />
<path d="M588 111 l10 5 -10 5 z" fill="var(--text-muted)" />
<path d="M561 196 H588" stroke="var(--text-muted)" stroke-width="1.5" fill="none" />
<path d="M588 191 l10 5 -10 5 z" fill="var(--text-muted)" />
<rect x="600" y="8" width="194" height="56" rx="10" fill="var(--sand-1)" stroke="var(--border)" />
<text x="697" y="30" text-anchor="middle" font-size="11" fill="var(--text-muted)">COMMODITIZING</text>
<text x="697" y="49" text-anchor="middle" font-size="14" fill="var(--ink-1)">Swap the model</text>
<rect x="600" y="88" width="194" height="56" rx="10" fill="var(--sand-1)" stroke="var(--border)" />
<text x="697" y="110" text-anchor="middle" font-size="11" fill="var(--text-muted)">STANDARDIZING</text>
<text x="697" y="129" text-anchor="middle" font-size="14" fill="var(--ink-1)">Swap the integration</text>
<rect x="600" y="168" width="194" height="56" rx="10" fill="var(--primary-50)" stroke="var(--primary-600)" />
<text x="697" y="190" text-anchor="middle" font-size="11" fill="var(--primary-600)">DEFENSIBLE</text>
<text x="697" y="209" text-anchor="middle" font-size="14" fill="var(--ink-1)">Swap nothing</text>
</svg>
When the model is swappable and the integration is standard, the durable asset is the system of record underneath: the entities, the transitions between them, the history of who decided what, and the accumulated knowledge of which coordination failures actually hurt in your domain.
That knowledge is specific and it is earned. It shows up as the decision that a transition into a done state carries more risk than a label change. That an agent-initiated action and a human-initiated one are not the same event even when the payload is identical. That an action which already executed needs a different decision verb than one still waiting — approving something that has already shipped tells a reviewer the board is waiting on them when it is not. None of that comes out of a model. It comes out of owning the workflow long enough to be wrong about it a few times.
The corollary is uncomfortable for thin interface wrappers and freeing for everyone else: depth beats breadth now. A narrow domain where you model the state properly is worth more than a general assistant over someone else's data.
Autonomy only becomes shippable when its failure modes are bounded, and bounded is a deterministic property — it is not something you prompt for.
| Control | What it bounds | Without it |
|---|---|---|
| Scoped tool permissions | What an agent can reach, per token | A tenant boundary that holds only by convention |
| Intermediate checkpoints | How far a run gets before it is inspectable | Failures that are only visible as outcomes |
| Escalation triggers | Who is interrupted, and when | Queues that are either ignored or rubber-stamped |
| Token and outcome telemetry | What autonomy costs per completed task | Spend you can measure but not attribute |
In Meshworq this is concrete. Every MCP tool call runs the same pipeline — validate, trust, scope, approval, rate limit, execute, trace — and no tool accepts a workspace argument at all, because the only tenant anchor we trust is the one on the verified token. Every proposal that needs a person carries a risk score, so a short queue beats a complete one. Every action lands in a decision ledger with a correlation ID.
That last one is where the convergence shows up as an architectural choice. When we built the unified acceptance timeline, the obvious move was a new decisions table. We deliberately did not: the ledger is a read model over the columns where the four queue sources already record their verdicts. No dual writes, no drift between two accounts of the same event, and it covers decisions made before the feature existed. Treating context and state as one shared fabric rather than per-feature storage is the thing that makes a timeline like that a query instead of a migration.
And plumbing deserves the same scepticism as reasoning. Our MCP endpoint was once silently disabled by the router that manages its own tokens — mounted above it, authenticating every path beneath it, returning 401 before the endpoint was ever reached. Every unit test passed, because router-level tests mount one router. Shared infrastructure fails in ways that component tests are structurally unable to see.
The useful way to read the convergence is as a sorting of what you should stop investing in and what you should double down on. Model access is becoming a procurement decision. Integration is becoming a protocol. What remains defensible is the depth of your domain state graph and the quality of the controls around acting on it — scoped permissions, checkpoints you can resume from, escalation that interrupts the right person, and telemetry that prices autonomy per completed task rather than per token. Build those and generative experiments turn into something a business can actually depend on. Skip them and you have a very capable system with no account of what it did.