The Mesh: agentic AI after the loop
Software
The loop isn't the architecture of agency — it's local cognition inside one worker. The future is agents living in an event-driven mesh, reacting continuously to a world that never waits.
Everyone draws the agent the same way: a loop. Think, act, observe, repeat. It is a good diagram, and I have drawn it myself many times. But after wiring real systems, I have come to believe the loop is quietly the smallest part of the story — and that mistaking it for the whole is why so many "agentic" projects feel powerful in a demo and inert in production.
Here is the claim I want to defend: the loop is not the whole architecture of agency. It is one piece of it — the local cognition pattern inside a single worker. And the thing that actually changes how systems get built is what happens around that worker — the continuous field of events it lives in.
The wheel that never stops
Let me be fair to the loop first, because the easy version of this argument is a strawman. A ReAct-style loop is not a rigid script. Within a single step the model chooses: which tool, which query, whether to stop. That is real, runtime, dynamic control flow. The loop is not "a predefined workflow." That is not its limitation.
Its limitation is temporal. The loop assumes a turn-based game: the agent thinks, and the world politely waits for it to finish before the next thing happens. Inside one task, fine. But step back and the assumption breaks. While your agent reasons, prices move, a file lands, a customer cancels, a sensor trips, another agent emits a result. The loop is local control flow. The world is global coordination. And the world does not take turns.
Reality is weather, not a path
The unit a loop is built around is the turn. The unit reality is built around is the event — a discrete, durable fact that something happened, at a time, with consequences. Events do not arrive in order, on request, one at a time. They arrive like weather: from many directions, at different speeds, indifferent to whether anyone is ready.
Once you see that, the question changes. It is no longer "how do I make my agent loop smarter?" It is "what should wake intelligence up, and what is it allowed to do when it does?" That is not a prompt-engineering question. It is an architecture question, and the architecture already exists. We have spent twenty years building systems that treat the world as a stream of events. We just never pointed agents at it.
The agent as membrane
In an event-driven system, the durable thing is not the program's current state — it is an append-only log of events. State is a view derived by replaying that log. This is event sourcing, and it is the deepest part of the shift, because it reframes what an agent is.
The shallow upgrade is "the agent is both a producer and a consumer of events." True, but not the profound part. The profound part is that the most valuable agents become stateful projectors — they maintain a materialized view over the event stream, a durable and consistent interpretation of a slice of the world, updated continuously as new events land. Be precise here, because the rest of the argument depends on it: the agent is not the view itself (a view is a deterministic read model). The agent is the side-effecting decision surface that reads the log, updates its projection, and emits new events. It stops being a worker that executes and becomes a membrane that holds a meaning.
Producers, consumers, and the politics of choreography
The plumbing for this is a durable, append-only event log with producers, consumers, topics, replay, and fan-out. There are several mature products that embody it — the streaming platforms everyone names, message logs, even a database's change feed — but I am deliberately not going to anchor on one, because the tool is not the thesis, the concept is. The thesis is durable event streams plus autonomous reaction surfaces. Which log you reach for is a decision you make per plan; the topology underneath is the same regardless. That is the whole point: these are substrate-agnostic concepts, and the concepts — not any product — are what should drive your architecture decisions. The idea travels; the implementation is interchangeable.
The genuinely radical move is not technical, it is political: a shift from orchestration to choreography. Orchestration has a central conductor — a workflow engine, or the loop itself — that tells each step when to run. Choreography has no conductor: each agent reacts to events it cares about and emits its own, and coordinated behavior emerges from the dance. Choreography scales and decouples beautifully. It is also far harder to debug. Mature systems will need both: choreographed reaction chains for breadth, explicit orchestration for the high-risk, long-running work. The emerging stack — the event log plus agent-to-agent and tool protocols (A2A, MCP) — is exactly this, with events replacing point-to-point APIs as the integration layer.
The first organism
I will show you the smallest real version I run, but I want to scope it honestly, because the lazy critique writes itself: "this is just event-driven ETL with an LLM bolted on." Fair warning — so here is what it actually is and isn't.
I built my own news system. Scheduled agents pull, on my cadence, from specific producer sources I chose because they align with how I want to see the world — not whatever a generic search or a model's training recall coughs up. Each pull becomes events. A central system holds them. Consumers — me, and downstream agents — subscribe, and one agent's output becomes another's input. It is event-shaped, it has producers and consumers, it composes agent-to-agent.
What it is, honestly, is a seed — the minimal living mesh, the first organism, not the proof of the whole thesis. A real production mesh has to answer harder questions: replay, idempotency, failure handling, observability, downstream contracts, and cost control. My news feed gestures at all of them; it has not had to survive all of them at scale. I am telling you this because the difference between a demo of event-driven agents and a system you can trust is precisely those unglamorous guarantees — which brings us to the part that matters most.
The dark geometry of the mesh
Every architecture has failure modes that look exactly like success. Event-driven agentic systems have especially treacherous ones, because they fail distributed and they fail quietly.
1. Reaction storms — the new infinite loop. The classic agent failure is one agent looping. The mesh failure is worse: one event wakes many agents, which emit more events, which wake more agents. Past a certain density of agents and event types there is a phase transition from stable propagation to exponential cascade. The system looks busy and alive while it is just amplifying noise — and you will not see it in testing, because testing rarely hits the density.
2. Causality rot. Logs tell you what happened. They do not automatically tell you why. With non-deterministic agents and events that can travel many paths, "why did this outcome occur?" becomes statistically answerable but not forensically answerable. Most teams will paper over this with dashboards — observability theater — when what they need is true causal tracing: event lineage, context and model-version snapshots, decisions, costs, and the alternatives that were suppressed.
3. Idempotency collapses. Mind the vocabulary, because the distinction is the point: exactly-once is a broker guarantee, and the log still delivers each event once. What breaks is idempotency — the application-level promise that handling the same event twice yields the same side-effects. With stochastic agents that promise is gone: a duplicate event may not produce the same output, because the model, the retrieval, the tools, or the world moved. You must abandon "same message, same handler" and move to "same intent, bounded side-effects" — semantic deduplication at the business level, not the infrastructure level.
4. Ownership black holes. Agent A emits an event that leads Agent B to enrich it, Agent C to publish it, and Agent D to take an action that destroys value. Who is accountable? "The prompt made the model do it" was already a bad answer; this is far worse. The event-topology designer becomes the new point of moral failure, and the system needs chain-level governance: audit, rollback, human-approval boundaries, and kill switches.
5. The always-on tax. A mesh that runs 24/7 discovers every cost leak in your design and bills you for it. Continuous operation is a capability, not a virtue. Without budgets, quiet hours, backpressure, priority classes, and sampling, "parallelism" quietly becomes uncontrolled spend and attention pollution. The tell: teams sprinkling cron-triggered "sleep" events back in — an admission that the paradigm has not fully won.
6. Immutable hallucinations. This is the one I fear most. In an ordinary event system a bad event is a bug you fix. Here, if an agent hallucinates, it appends a stochastic lie to an immutable log — and downstream agents read that lie as ground truth, because the log is the truth. The falsehood becomes permanent, unassailable causality; worse than causality rot, the bedrock itself is poisoned. And because different agents — different teams, different model versions — quietly drift in how they interpret what an event means, the mesh can slide into incoherence without a single error being thrown. It fails not with a bang, but with a slow loss of shared sense.
Designing the event topology
Notice what just happened: every one of those failure modes is a design problem, not a model problem. That is the real shift in the human's job. You stop writing procedures — the step-by-step of what the agent should do — and you start designing the conditions under which the system should notice, decide, and respond.
What counts as a signal worth waking intelligence for. Which reactions are legal, and which require a human in the loop. Where the damping lives so a storm cannot start. What the budget is, and what happens at the edge of it. Who owns a chain of autonomous reactions, and where the kill switch is. This is a craft, and it is closer to designing a nervous system — or a city's traffic rules — than to writing a script.
After the hype
When the word "agentic" stops being a marketing slide, I think this is what it will mean: not a cleverer loop, but the migration of intelligence out of prompt-bound sessions and into event-driven systems — waking on meaningful change, acting in parallel, leaving a durable trace, and composing into chains of reaction that a person designed the rules for. The enterprises that win with this will not be the ones with the smartest single agent. They will be the ones who learned to design the field.
The loop does not disappear. It survives, smaller, as the local cognition inside each node of something much larger and continuously alive. That larger thing — the mesh — is where agency was always going to live. We just had to stop thinking in turns.
A note on how this was made — and how I work
I did not write this with one model. The essay, the film, and the field guide were built the way I build everything now — by convening a council. I put the thesis in front of a panel of frontier LLMs with strong reasoning, let them disagree, and they caught me overclaiming in three places — including the temptation to call the loop "just a predefined workflow," which it isn't. I kept what survived the argument.
And I do not stop at agreement. I question their answers even when they look right, and push them to defend it from a different angle — because a confident consensus is exactly where a blind spot hides. Not one model. The best of many — and the human who decides.
— Juan Cardena
Part of a bigger picture
This isn't theory for its own sake. It's the architecture underneath something I'm building: Sphere LLM — a proof-of-concept set of tools and agents that live on exactly this event-driven pattern. A sphere of interconnected agents reacting to a continuous world of events, with a human designing the topology and holding the kill switch. It's early, and there is much more to come — but the loop is already becoming the mesh.
Watch the companion film, The Mesh, and read the field guide of the same name. Part three of the trilogy: The Loop · The Council · The Mesh.