Channel-Decoupled Agent Core

Problem

When the agent loop is wired straight to one channel's mechanics, every new surface forces a partial rewrite of logic that has nothing to do with the channel. Voice needs streaming and interruption handling, email is high-latency and asynchronous, Slack threads carry their own identity, and background automation has no live user to clarify with. Copying the agent into each surface duplicates the reasoning and lets the copies drift, so a policy fix made for chat never reaches the phone line.

Solution

Separate the agent into a core and a set of channel adapters. The core holds the reasoning loop, tool calls, policies, and session state, and it speaks only a normalized internal contract: an inbound event (who, session, content, modality, attachments) and an outbound action (reply, tool effect, hand-off, push). Each delivery surface is an adapter that owns that channel's specifics: the web adapter handles request-response and rendering, the voice adapter handles streaming audio, barge-in (the caller interrupting mid-sentence), and turn-taking, the email adapter handles asynchronous threads and long latency, the Slack adapter handles thread identity, and a scheduler adapter drives the core with no live user. Session state lives with the core keyed by a channel-independent conversation id, so the same conversation can move across surfaces and the core can run unattended in the background. Adding a channel means writing one adapter, not touching the core; fixing a policy touches the core once and every channel inherits it.

When to use

• The same agent must run across more than one delivery surface (web, voice, email, chat apps) or across both live and unattended modes.
• Channel-specific mechanics (streaming, threading, latency, attachments) keep changing while the reasoning and policies stay the same.
• Policy and behavior must stay identical across surfaces, so a single source of truth for logic is required.