neob.dev

Engineering

Building multi-channel agent systems

Four channels is not four agents. If it becomes four agents, it happened gradually, and it happened inside the adapters.

NEOB Engineering Published 8 min read
omnichannelarchitectureconversational-ai

The architecture is easy to draw and hard to hold: thin channel adapters over one agent definition, one knowledge base, one tool registry, one set of guardrails. The difficulty is entirely in preventing drift.

Customer
PhoneWeb voiceWeb chatMessaging
Agent layer

One agent definition

KnowledgeMemoryBusiness logicToolsGuardrails
Systems of record
CRMCalendarTicketingERP
The shape. Everything that decides behaviour is below the adapter line.

What an adapter is allowed to own

  • Transport. SIP, WebRTC, WebSocket, webhook.
  • Timing model. Sub-second and synchronous, or asynchronous over hours.
  • Output affordances. Audio only; audio plus text; text plus links and files.
  • Identity evidence. Caller ID, session, account handle - reported, not interpreted.

That is the complete list. Business rules, knowledge, tool access and guardrails are not on it, and the moment one appears in an adapter the system has quietly become four systems.

Rendering, not rewriting

The agent produces one answer. Adapters *render* it: a phone adapter speaks it and drops the link; a chat adapter shows the link as a card. What an adapter must not do is ask for a different answer, because that is the point at which the channels start to disagree about facts rather than about formatting.

One reply, several renderings
interface Reply {
  speech: string             // what a voice channel says
  text: string               // what a text channel shows
  attachments?: Attachment[] // dropped by voice, rendered by text
  actions?: Action[]         // buttons in chat; spoken options by phone
}

// Voice: speech only, and options read out - at most three, because a
// caller cannot hold six in their head.
// Chat: text plus attachments plus actions as buttons.

Consistency testing

The failure mode is silent: the phone agent and the chat agent begin giving different answers to the same question, and nobody notices until a customer points it out. The defence is mechanical - run a fixed question set through every adapter and diff the answers on a schedule.

Differences in phrasing are expected and fine. Differences in *fact* are a build failure. Getting that distinction right in an automated check is the actual engineering.

The asynchronous channel breaks assumptions

Phone, web voice and chat are all synchronous with different clocks. A message thread that resumes after three weeks is a different kind of system: the identity evidence is still valid, the context is stale, and the customer expects continuity anyway. We handle this conservatively - re-establish before relying on anything - and we do not think that is the final answer.