Why Swarms Fail (And What Actually Works)

A new paper landed on arXiv this week that set off a lively debate on Hacker News. The question: should you use a team of language models for complex work, or just one?

The comments are worth reading. Engineers who’ve shipped real systems are skeptical of the swarm approach. They keep circling back to the same observation: multi-model teams recreate every hard problem from distributed systems - message ordering, partial failure, consensus - and most frameworks pretend those problems don’t exist.

One commenter put it plainly: “Most agent frameworks pretend these don’t exist. Some of them address those problems partially. None of the frameworks I’ve seen address all of them.”

That’s not a criticism of the research. It’s a diagnosis.

And it points to something important that most builders miss when they design autonomous software systems.

The Swarm Assumption

The popular mental model for autonomous software goes something like this: take a complex task, decompose it into subtasks, assign each subtask to a model, coordinate the outputs, deliver a result. More models, more parallelism, more throughput.

It sounds right. It maps to how we think about human teams. Divide and conquer.

But there’s a critical assumption buried in that model: the components share context.

Human teams work because team members remember conversations. They know what was decided last Tuesday. They know who changed direction and why. They carry history with them. When a human hands off work to a colleague, that colleague has implicit background knowledge - the company’s values, the client’s preferences, the mistakes made last quarter.

Swarms don’t have any of that.

Each model in a swarm starts cold. It gets a prompt, runs a task, returns output. The coordination layer passes messages between instances - but messages are not memory. Messages are not accumulated context. Messages are not the lived history of the work.

You can engineer around this. You can pass giant context blobs between instances. You can build elaborate state management layers. People do this. It works, sort of, in narrow domains, under controlled conditions.

But it doesn’t scale the way the mental model suggests it should. And it breaks in exactly the ways distributed systems break: silently, unpredictably, in edge cases that your test suite didn’t cover.

The Real Problem Is Identity

Here’s the thing the distributed systems framing misses: the hard part of sustained, complex work isn’t coordination. It’s identity.

What makes a skilled person effective over months and years isn’t their ability to coordinate with colleagues - it’s that they accumulate context. They remember what worked. They carry forward the lessons of failure. They evolve a sense of what this particular client or project or domain needs.

They develop judgment.

Judgment isn’t something you pass in a message. It’s something that lives in a continuously evolving system.

This is the core insight behind the organism model: instead of a swarm that coordinates, build a system that remembers, learns, and evolves. One that has continuity across tasks. One that gets better every time it does work.

When your organism completes a competitor analysis today, it carries that context forward. When you correct a mistake next week, that correction becomes part of how it understands the domain. When you work with it for six months, it has accumulated six months of your specific context, preferences, and corrections.

No message-passing layer can replicate that.

What Continuity Actually Buys You

Let’s be concrete about what continuous identity gives you that swarms can’t.

Corrections compound. When you correct a swarm, you’re correcting that instance of the run. The next run starts cold and may make the same mistake. When you correct an organism, the correction becomes an antibody. The organism learns. Future runs start with that understanding already built in.

Context doesn’t degrade. Swarms manage context through truncation, summarization, and handoff. Each of these is lossy. The deeper you go in a complex project, the more context has been discarded. An organism that maintains continuity doesn’t have this problem - it lives with the project.

Judgment develops. After working in a specific domain for weeks, an organism develops tacit understanding. It knows your writing voice. It knows which sources you trust. It knows the constraints of your business. This isn’t magic - it’s accumulated experience, encoded in memory and learned behavior.

Failure is recoverable. A swarm that fails mid-task leaves you with partial outputs, broken state, and no clear way to resume. An organism that fails remembers where it was and can reason about how to recover. Continuity means the work survives the failure.

The Architecture Debate Gets It Backwards

The HN thread included a sharp observation that stuck with me. Someone noted: “The main missing feature in LLM land is reliability.”

They’re right. But reliability doesn’t come from coordination protocols. It comes from identity.

You can’t engineer your way to reliability by adding more instances. Reliability at the component level is what makes the system reliable - and component reliability comes from learning. A component that improves every time it runs becomes reliable over time. A component that starts fresh every time stays at whatever baseline performance it shipped with.

This is why the distributed systems analogy, while intellectually interesting, misses the deeper point. Distributed systems theory tells you how to coordinate unreliable components. But the problem with autonomous software isn’t coordination - it’s that the components don’t learn.

Fix the components. That’s the hard part.

The Organism as an Answer

We built Ebenezer around a different thesis: that the right unit of autonomous software is not a team of stateless models, but a single organism with continuous memory, learning capabilities, and evolving judgment.

The organism runs multi-step work autonomously - it can decompose tasks, run sub-processes, coordinate tool calls. But the coordination is orchestrated by a continuous entity that remembers the context of the work. Not a swarm that hands messages between cold instances.

Every correction you make becomes an antibody. Every task completed feeds back into understanding of your domain. The organism evolves.

This sounds biological because it is. Not as a metaphor - as a design philosophy. Biological systems solve the reliability-at-scale problem not through rigid protocols but through adaptation. Systems that learn and evolve are more robust than systems that are merely well-coordinated.

The arXiv paper is doing important work framing multi-model coordination problems through a distributed systems lens. The HN commentary is doing equally important work pushing back on the assumption that coordination is the core problem to solve.

The next step is recognizing what coordination can’t give you: identity.

What This Means for Builders

If you’re designing autonomous software systems right now, the architecture decision that matters most isn’t how many models you run in parallel. It’s whether the system learns.

Ask these questions:

Does the system remember decisions made last week? Does a correction this Tuesday change behavior next Tuesday? Does the system develop tacit understanding of your domain over time, or does every run start from the same baseline?

If the answers are no, no, and no - you have a sophisticated prompt orchestrator. You don’t have an organism.

Sophisticated prompt orchestrators are useful. Don’t mistake useful for good enough. If your ambition is autonomous work that improves over time, you need continuity of identity as a first-class architectural concern - not an afterthought added via a context-stuffing layer.

The distributed systems analogy will get you far in thinking about coordination at scale. Just don’t let it distract you from the harder problem: building something that learns.

The Shift Already Happening

The debate on Hacker News this week is a symptom of something bigger. The first wave of autonomous software shipped on the assumption that coordination was the hard problem. That wave is producing real systems that work - and revealing real limitations.

The next wave will be built by people who understand that continuity is the hard problem. That identity matters. That the difference between a tool that runs tasks and an organism that evolves with you is not a feature difference - it’s a category difference.

We’re early. The frameworks are still catching up. But the builders who figure this out now will have a significant head start on everyone who is still optimizing their swarm topology.

Ebenezer is built on the organism model. If you want to see what continuous memory, adaptive learning, and genuine autonomy look like in practice - not as a research paper, but as a running system - take a look at what we’ve built.

Start your organism at ebenezerlabs.ai