🔗 Companion project: Maestro — ardeshir.io/maestro/
Beyond MCP: Reimagining Agentic Architecture
Let’s push past the current state of the art, and propose what Barnyard could actually look like if we stop iterating on MCP-plus-graphs and start designing from first principles.
Where the Current Stack Actually Stands
The industry summary is accurate as a snapshot of where the field converged through 2025–2026. The honest reading of it:
The field solved the context explosion problem by externalizing state (memory layers, vector stores, graph runtimes), and solved the tool fragmentation problem by standardizing on MCP. What it has not solved — and what the real question points at — is the coordination, continuity, and economics of long-running agentic work.
LangGraph checkpoints are still glorified save-files. MCP is still a synchronous request/response protocol dressed up as a standard. “Multi-agent” systems are mostly orchestrators dispatching to sub-prompts, not genuinely concurrent reasoning processes.
So the interesting question isn’t “how do we build a better LangGraph on EKS.” It’s: what assumptions are we still carrying from the chatbot era that we should drop?
Five Assumptions Worth Breaking
1. That the LLM call is the unit of work.
Today every framework treats model.invoke() as the atomic step. But reasoning isn’t atomic — it’s a continuous process that gets interrupted by token generation. What if the unit of work were a reasoning continuation — a resumable, migratable computation that happens to call models, rather than a graph node that wraps a model call?
2. That tools are called, not subscribed to.
MCP is RPC. Every tool interaction is a round-trip. For a researcher running continuous work, this is backwards — the agent should subscribe to streams of data (new papers, sensor readings, market ticks, file changes) and react, not poll. The right primitive is closer to reactive streams (Rx, Flink, Materialize) than to REST.
3. That memory is a database the agent queries.
Vector DBs, episodic stores, graph DBs — all of these put the agent in a pull model. But human researchers don’t “query their memory”; relevant context surfaces to them based on what they’re doing. The right primitive is a context field — an ambient, continuously-recomputed projection of relevance — not a retrieval call.
4. That agents are processes that terminate.
Almost every framework assumes a request comes in, work happens, a response goes out. Real research is a months-long, branching, dormant-and-reawakening activity. We need agents that look more like living organisms or long-running OS daemons with sleep/wake cycles, not request handlers.
5. That orchestration is centralized.
LangGraph, Semantic Kernel, AutoGen — all have a central runtime that owns the graph. This doesn’t scale to swarms or federated work across organizations. The right primitive is peer-to-peer agent gossip with eventual consistency, not a master orchestrator.
Barnyard: A Proposed Architecture
If we take those five seriously, here’s what a system designed for continuous researcher productivity could look like. Let’s call the components by deliberately non-MCP names to force the abstraction.
The Substrate: Continuation-Passing Agents
Instead of graph nodes, the atomic primitive is a Continuation — a serializable reasoning state that includes:
- The current hypothesis/goal frame
- A pointer to its context field (see below)
- A budget (tokens, wall-clock, dollars, tool quotas)
- A parent/child lineage
- A wake condition (event predicate, timer, or external signal)
Continuations can be paused, migrated across machines, forked, and merged. They live in a continuation store (think: Durable Objects, Temporal workflows, or Erlang processes — pick your inspiration). The LLM is just one of several “evaluators” a continuation can dispatch to.
This is the key shift: the agent is the continuation, not the model call.
🔗 Companion project: Maestro — ardeshir.io/maestro/