Internal product · in development
Loop Agent
One agent holding a single conversation thread across voice, chat, and WhatsApp, instead of separate tools that lose context when a customer switches channel. Currently an internal build.
- Client
- Internal product
- Sector
- Product development
- Status
- In development — not yet a deployed client project
The situation
The pattern across client work was consistently the same failure: a voice bot that answers calls well, a chatbot that handles WhatsApp fine, and no shared memory between them. A customer calls, gets qualified, messages an hour later, and starts from zero. The business paid for two AI tools and got one broken conversation.
Loop Agent is the attempt to solve that directly — one agent, one context object, however many channels the customer actually uses.
What made it hard
Channels are transports, not products
Treating voice and chat as separate systems that occasionally sync is what produces the problem. They have to read and write the same conversation thread, or the architecture reintroduces the gap it was built to close.
Tenant isolation
Shared infrastructure serving multiple clients means isolation has to be enforced at the data layer rather than trusted to application code.
Handoff edge cases
Mid-conversation handoffs between specialised agents are where a multi-agent system is most likely to lose the thread, which makes them the hardest part to get right.
How it works
Customer reaches out
Any channel — call, chat, or WhatsApp — starts the same thread.
Context stays in the loop
CRM, calendar, and history stay in sync as the conversation moves.
Nothing drops
Follow-up, booking, and handoff all draw from the same context.
One context, every channel
Rather than a voice bot and a chat bot that occasionally sync, every channel is treated as a different transport for the same underlying conversation. Intent, history, CRM state, and calendar availability live in one context record tied to the customer rather than three copies drifting apart.
In practice: if a call ends with "let me think about it," the follow-up that goes out later is grounded in what was actually discussed. If the customer replies on WhatsApp, that reply lands with the full history attached rather than as a fresh message from a stranger.
Multi-tenant by design
Each client is modelled as a squad of specialised agents — reception, sales, follow-up — defined as configuration rather than code. A client wanting different qualification questions gets a different squad definition, not a fork of the codebase.
Data isolation is enforced through row-level security at the database, so a missing tenant filter returns nothing rather than leaking across clients.
What is still ahead
Hardening the handoff logic for edge cases, and getting the first non-internal deployment live so the "one context, every channel" claim is tested against a real, messy customer base rather than internal test scenarios.
Where this stands
Figures below are labelled by what they actually are. Nothing here is presented as a delivered result unless it is one.
Stage
An internal product, not a deployed client project. The architecture draws on patterns proven in live client work.
First external deployment
The claim that context survives a channel switch is not properly tested until it meets a real customer base.
Stack
Working on something similar? I'd be glad to talk through it.
Book a Discovery Call