Academy

From CWD to AAA: why we build an architecture, not a chatbot

A customer writes in once, mid-story — one message carrying five jobs at once. A single bot flattens it; a pile of bots hands them around. Neither is what a colleague does.

The Felesh team 8 min

A customer writes in once, in the middle of a story already in motion. “You changed my plan last month, now the invoice looks wrong, and I already emailed about this last week.” It is one message, but many jobs at once: recall what happened last month, read the policy that governed the change, check the invoice against it, judge what the person actually wants, and decide what to do right now.

A single chatbot flattens all of that into one shallow reply. A pile of disconnected bots does the opposite — it hands the customer around, each bot meeting them as a stranger. Neither is what a real colleague does. A colleague holds the whole thread at once.

One message, five jobsA customer writes: you changed my plan last month, now the invoice looks wrong, and I already emailed last week. Inside it are five jobs: recall what happened last month, read the policy behind the change, check the invoice against it, judge what the person wants, decide what to do now. A single bot covers one of the five, the invoice check. A colleague covers all five, one tick after another.one customer message“You changed my plan last month, now the invoicelooks wrong, and I already emailed last week.”five jobs inside itsingle botcolleaguerecall what happened last monthread the policy behind the changecheck the invoice against itjudge what the person wantsdecide what to do right nowjobs covered1 of 55 of 5
One message carries five jobs; a single bot covers one of them, a colleague holds all five.

The pattern we started from

The shape of that coordinated, multi-job problem already has a name. It is called Coordinator, Worker, Delegator, or CWD. This is an established, documented pattern — set out by Biswas and Talukdar in Building Agentic AI Systems, chapter 6 — rather than our coinage. In short: a Coordinator plans the work and puts the pieces back together, Specialists each do one thing well, and a Delegator sits in the middle to match the work to whoever can carry it.

Coordinator, Delegator, SpecialistsThe customer message reaches the Coordinator, which plans the work and puts it back together. The Delegator below it matches work to whoever can do it. Three Specialists each take one piece: history takes last month’s plan change, policy takes the plan-change terms, invoice takes the invoice line check. Their results flow into one reply.CWD: who does whatCoordinatorplans the work, puts it backDelegatormatches work to whoever canhistorylast month’s planpolicyplan-change termsinvoicethe invoice lineone reply, the pieces put back together
CWD gives the work a correct org chart: a Coordinator plans it, a Delegator hands each piece to the Specialist who can carry it, and the pieces come back together.

We will not re-teach the mechanics here; the builders’ anatomy of it lives in its own place, in the Coordinator, the Worker, and the Delegator. What matters for us is that CWD is where we started, not where we arrived.

Why coordination alone is not enough for a conversation

CWD answers a question about who does what. It gives you a correct org chart for a task. But a conversation is not a discrete task, and a customer is not a work order. To feel like one attentive mind rather than a switchboard, an assistant needs more than correct routing. It has to hold context across turns, remember the relationship rather than just the last message, move between concerns without losing the thread, and know the limits of its own certainty. Mechanical coordination does not provide that. It gives you a tidy hierarchy that still meets the customer as a stranger every morning.

Fresh work orders versus one threadThree things the customer has told us: last month the plan changed, last week they emailed about it, now the invoice is wrong. Under routing alone, each turn is a new work order and asks who this is, three times. Under a conversation, one thread runs through last month, last week and now, with the same customer and the same context every turn.what this customer has told uslast monthplan changedlast weekemailed about itnowinvoice is wrongrouting alone: a fresh work order every turnnew work ordernew work ordernew work orderwho is this?who is this?who is this?a conversation: one threadlast monthlast weeknowsame customer, same thread, every turn
A router treats each turn as a fresh work order, so it meets this customer as a stranger every time; a conversation keeps one thread.

AAA, the architecture we build instead

This is the evolution we call AAA, Attentive Agentic Architecture: our extension of the CWD pattern into a cognitive, humanised architecture for conversational assistants. Where CWD is about coordination, AAA is about attention. The attentive part comes down to three things.

Layered memory. Working memory for the live turn, interaction history for the relationship, and a long-term knowledge base for what is true. We detailed that division in layered intelligence; the point here is only that memory comes in layers, and an attentive assistant uses all of them.

Three memory layers feed one replyWorking memory holds the live turn: the invoice looks wrong. Interaction history holds the relationship: the plan changed and the customer emailed last week. The long-term knowledge base holds what is true: mid-cycle plan changes are pro-rated. The reply uses all three: the pro-rated line is explained and last week’s email is answered.one reply draws on three layersworking memorythe live turn“the invoice looks wrong”interaction historythe relationshipplan changed; emailed last weeklong-term knowledge basewhat is truemid-cycle plan changes are pro-ratedreply: pro-rated line, last week’s email answered
One reply draws on all three memory layers: the live turn, the history of the relationship, and what is true.

Self-awareness of its limits. The assistant knows when it is unsure, and it knows when an action is too consequential to take on its own. That is not a nicety. It is the difference between a colleague you can trust and one you have to constantly watch.

Unsure or weighty means it stops shortThree proposed actions. Explain the line: high certainty, low consequence, so it answers. Pick which plan: low certainty, low consequence, so it asks first. Refund the difference: high certainty, high consequence, so a person approves. When it is unsure it says so; when the action is consequential a person decides.proposed actioncertaintyconsequenceresultexplain the linehighlowanswerspick which planlowlowasks firstrefund the differencehighhigha person approvesunsure: it says so. consequential: a person decides.
The assistant measures its own certainty and the weight of the action, and when either is wrong for acting alone, it says so or hands the call to a person.

Attention that shifts. In a single conversation, it can move between the invoice, the policy, and the person’s actual worry without dropping any of them, the way a good colleague does.

Intelligence at the edges, determinism in the middle

We describe the shape of this as intelligence at the edges, determinism in the middle. The judgement, the understanding, the drafting, and the deciding live at the edges, where the models are. The middle — how work gets routed, what is allowed, what gets recorded — is plain, fixed, readable code, not a probabilistic guess.

Intelligence at the edges, determinism in the middleA customer message enters the top edge, where a model understands the message and judges what the person wants. The middle is plain code with three rules: route the invoice question to billing, allow a drafted reply that needs approval, and record at 16:05 that it was routed, with its reason. A proposal leaves through the bottom edge, where a model drafts the reply and decides what to propose.edge · modelsjudgement lives hereunderstands the message, judges what they wantcustomer message inmiddle · plain codereadable, auditablerouteinvoice questionto billingallowdraft a replyneeds approvalrecord16:05 routedwith its reasonproposal outedge · modelsjudgement lives heredrafts the reply, decides what to propose
Models sit at the two edges where judgement is needed; the middle that routes, permits and records is plain code you can read.

The reason is trust, not speed. A middle you can read is a middle you can audit. So the system proposes, a person approves, and the reason travels with the action. Nothing consequential happens that a person could not see coming, and nothing is done for a reason that has been left behind.

Where this loses

We prefer to say plainly where this is the wrong tool. An attentive, multi-layer architecture is overkill for a plain question. If a single well-scoped assistant answers it, or even an ordinary chatbot, that is the right tool and AAA is not. Coordinated agents also cost far more to run: community and design work in the field puts it at roughly 15× the tokens of a single call, a widely reported finding rather than a Felesh result. AAA earns its place only when the work is genuinely a relationship with operations behind it, not a lookup dressed up as one.

What is built, and what we are still building

We want to be candid about where we stand. Today, the system has working memory, interaction history, and a long-term knowledge base. Two capabilities we care about are directions we are building, not shipped features: proactive memory, which would surface what you need before you ask, and the assistant learning from its own conversations over time. We would rather name them as a roadmap than imply they already ship.

Built today, still buildingBuilt today and ticked: working memory for the live turn, interaction history for the relationship, and a long-term knowledge base for what is true. Still building, in dashed boxes and not shipped: proactive memory, which surfaces what you need before you ask, and learning from its own conversations over time.built todaystill buildingworking memorythe live turninteraction historythe relationshipknowledge baselong-term, what is trueproactive memorysurfaces what you needbefore you asklearningfrom its ownconversations over timeshippeda direction, not a feature
Three memory layers are built today; proactive memory and learning from its own conversations are directions we are building, not shipped.

The summit

From here, the view is simple. We do not build chatbots, and we do not build a pile of bots that hand your customer around. We build an architecture that pays attention, because a relationship is the thing worth building for. If you want to see how that architecture compounds as it grows, the ecosystem that gets smarter with every addition is the next step up the same path.