Resources · Reference architectures
Reference architectures for AI assistants and automations
The four designs we build most often, each drawn to the same diagram legend, so a support chatbot, a WhatsApp bot, a phone agent and an automation pipeline can be compared box for box. They are reference designs, not drawings of client systems: each page lists the options we choose between per project, what fails and what drives the running cost.
| Criterion | RAG support chatbot | WhatsApp business bot | Inbound voice agent | Event-driven automation |
|---|---|---|---|---|
| Starts from | A question in a web widget or help centre | A WhatsApp message, or an update someone opted into | A phone call to your number | Webhooks and schedules |
| Main job | Answers from approved content, with citations | Order and booking answers, and updates | Answer, book or transfer | Move and enrich records across tools |
| Time budget per reply | Conversational: a few seconds is fine | Conversational, on the customer’s phone | Real time: silence feels broken | Off the request path: seconds to minutes |
| State it keeps | Versioned index, conversation log | Event store, consent, window state | Call state, call record | Event log, idempotency keys |
| Where a person steps in | A decline, or the customer asks | A takeover in the team inbox | A warm transfer with a summary | The dead-letter list and replay |
| First failure to design for | Citing a stale or wrong passage | Duplicate events and late free-form sends | Slow turns and talking over the caller | Lost or doubled writes |
| Platform layers it leans on | Know, with Control | Reach, with Control | Reach, in real time | Reason and Control |
Reference architectures
The four architectures
RAG support chatbot
Help-centre content to a cited answer, an honest decline or a helpdesk ticket with the transcript.Starts from: a support questionReference designWhatsApp business bot
Signed webhooks, one ordered lane per customer, a send gate for the service window, consent and CRM write-back.Starts from: a WhatsApp messageReference designInbound voice agent
The real-time turn loop with barge-in, narrow booking tools and a warm transfer with a summary.Starts from: a phone callReference designEvent-driven automation
Store-then-acknowledge ingress, a durable queue, idempotent workers, a model step, dead letters and replay.Starts from: a webhook or a scheduleReference design
How to read these diagrams
- Source
- Where a request or data enters: a chat widget, a WhatsApp message, a phone call, a webhook, a schedule or an approved document set.
- Processing
- Ordinary code we write and test: ingress endpoints, routing, retrieval, queues, workers and tool calls. It behaves the same way every time.
- Model
- A language, speech or embedding model call. Its output is treated as a draft and checked before it can reach a customer or a system.
- Control
- A gate that can stop, hold or reroute work: input checks, citation checks, send rules, transfer rules and dead letters.
- Human
- A customer or someone on your team. An arrow into a person is the answer, the escalation or the approval path.
- System of record
- Where state lives and survives a restart: your CRM, helpdesk or calendar through its API, a search index, a log.
- Arrows run in the order data moves: left to right, or top to bottom on a phone.
- A label on an arrow names what travels along it, such as a question, an event id or a ticket.
- Named products are options from our build stack; “your … via its API” means the system you already run.
- Each diagram is a reference design, not a drawing of any client’s system. Component choices are made per project.
Method
How to use these architectures
Every architecture page follows the same order: what it solves, each component with the options we choose between, the data flow step by step, the design decisions and their alternatives, the reference diagram, failure modes, cost drivers, limits and variants. Read the one that matches where your requests start. Many projects combine two, such as a support chatbot that also answers on WhatsApp, or a phone agent whose bookings feed an event pipeline.
How we use them in a project
- At scoping we pick the closest architecture and mark which boxes your systems already cover.
- Each box gets a chosen option and a written reason, so the build plan can be checked against the reference.
- The failure modes become test cases, and the cost drivers become the running-cost estimate, quoted with dated vendor prices.
What they are not
They are not client systems, benchmarks or timeline promises. Products named in the boxes are options from our build stack; “your CRM via its API” means whatever you already run.
FAQ
Frequently asked questions
What is a reference architecture, and how is it different from a build plan?
A reference architecture is the general design: the boxes, how data moves between them and what can go wrong. A build plan is that design for one project, with an option chosen in every box, your systems named, test cases and a timeline. We start every plan from the closest reference.
Which architecture fits a project that spans web chat and WhatsApp?
Start from the RAG support chatbot for answers from your content, and add the WhatsApp design’s ingress, send gate and consent store as a second channel. Both can share one router, one set of content and one handoff.
Why do all four architecture diagrams use the same legend?
So they can be compared and combined. A control box means the same thing on every page: a gate that can stop or reroute work. Whichever design you read, it is easy to see where a person steps in, what is a model call and what is plain code.
Can we hand these designs to another vendor or our own developers?
Yes. They describe mechanisms, not anything proprietary, and the options in each box are tools you can buy or run yourself. If you build in-house, the failure modes make a useful review checklist.
Why are particular products named inside the boxes?
They are options from the stack we build with, named so the designs are concrete. At scoping we choose per box from what you already run, your data rules and the cost drivers listed on each page.
Do these reference architectures change over time?
Yes, when a vendor changes behaviour or we change a default. Each page shows the date of its last real change, and its vendor facts list the date we checked them.
Next step
Have a workflow in mind? Let’s scope it together.
Book a free 30-minute strategy call. Bring one process you want to automate and we will talk through scope, integrations and a sensible first step.
Free 30-minute call · no commitment