Academy

Why we don't build chatbots: the two multi-agent paradigms we rejected

Most AI systems are built in one of two shapes — and both break at scale. This is the story of what we chose instead.

The Felesh team 4 min

When we say “we don’t build chatbots,” we do not mean conversation is worthless. We mean conversation is not an architecture. A chat window is just a front door; what happens behind that door decides whether your system stands or collapses in the real world.

In the course of building agentic systems, we kept encountering two paradigms that looked appealing at first, but failed in practice. It is worth explaining why — because that “why” is exactly what separates an impressive demo from a system you can rely on.

Two paradigms we rejected

The first is tempting: put several agents in a chat room and let them talk until they reach an answer. It looks beautiful in demos, but at scale, no single agent is accountable. Errors accumulate down the chain and become nearly impossible to trace. Free-form conversation does not remove the cost of coordination; it just makes it invisible.

A wrong number travels down the chat and no one owns itFour agents talk about an order for Acme. Intake says the customer wants 12 seats. Billing agrees: 21 seats. Risk says 21 seats looks fine. Provision adds 21 seats. The number contradicts intake, but each agent trusted the line above it, so no one decided the 21.chat room · order for Acmeintakecustomer wants 12 seatsbillingagreed: 21 seatsrisk21 seats looks fineprovisionadded 21 seats12 seats21 seats21 seats21 seatswho decided 21? no one: each trusted the line above
In a chat room the wrong number slips in at the second message: 12 seats become 21, every agent builds on it, and no one decided it.

The second overcorrects: one highly capable agent with a pile of tools. The more tools you give it, the harder its decisions become and the larger its error surface grows. When every capability is compressed into one mind, you cannot evaluate, improve, or constrain any part in isolation.

One agent, nine tools, one wrong pickThe request to add 12 seats for Acme reaches one agent that holds nine tools: seats, upgrade, cancel, rename, resend, invite, close, merge, export. The choice lands first on seats, passes over rename, and ends on cancel, which closed the account instead of adding seats. Nothing else checks the pick.requestadd seatsAcme · 12one agentnine toolsseatsupgradecancelrenameresendinviteclosemergeexportcancel closed the account instead of adding seats
Give one agent nine tools and a request to add seats can run the wrong one, with nothing outside its own head to check the pick.

Both fail at the same point: responsibility either dissolves into conversation until it disappears, or compresses into a single mind until it cannot be separated.

The third path: structure, not conversation

What we arrived at is neither free-form conversation nor a do-everything mind. It is a structure of focused roles with clear boundaries, coordinating through defined, traceable events rather than by chatting. We lay out the anatomy of that structure — and what each role owns — in The CWD anatomy: Coordinator, Worker, Delegator. What matters here is the result: responsibility resides in a place you can see, measure, and trust.

Roles with boundaries, events in a logThe Acme order passes through three roles, each in its own dashed boundary: intake reads the order, billing prices 12 seats, provision adds them once. Each hand-over is an event written to a log: 10:42:01 intake to billing, requested 12 seats; 10:42:02 billing to provision, priced 12 seats; 10:42:03 provision, added 12 seats. Every result has one owner.three roles, each with a boundaryintakereads the orderbillingprices 12 seatsprovisionadds them onceevent log10:42:01intake to billingrequested 12 seats10:42:02billing to provisionpriced 12 seats10:42:03provisionadded 12 seatsevery result points to one role that owns it
Three roles, each inside its own boundary, hand over events, so the same order stays 12 seats and every hop leaves a line in the log.

Why this matters for you

If AI is going to do real work in your organisation — not just an interesting demo — what matters is not the chat window. It is whether, when the system is under pressure, its behaviour can be traced, its parts can be improved in isolation, and its boundaries can be guaranteed.

Traced, improved alone, boundedThree properties, each with a worked line from the Acme order. Traced: who added 12 seats? provision, at 10:42:03. Improved in isolation: change how billing prices, and intake and provision stay untouched. Bounded: provision can only add seats; it has no cancel to run.propertyworked line, Acme ordertracedwho added 12 seats?provision, at 10:42:03improved alonechange how billing pricesintake and provision untouchedboundedprovision can only add seatsit has no cancel to run
Because responsibility sits in a role, each property is one line you can check: who did it, what changes alone, what it cannot do.

We don’t build chatbots because a chatbot is a surface, and we care about the structure standing behind it. The right paradigm is not the one that shines brightest in a demo; it is the one still standing on a bad day.