The conversation is not the work loop

Agent frameworks usually use the same model loop for conversation and work. That is simple while the agent is idle. Once it starts a long task, no separate part of the system remains available to decide how to respond to you.

Where your message actually goes

In the current crop of open-source agents, every message you send becomes a prompt to the loop that does the work. There's real engineering in front of it, with gateways doing session routing, per-channel adapters, and mention gating, but that layer is transport. It decides which agent run your message reaches, not what should happen conversationally.

Send a message mid-task and the framework has three common options. It can queue the message, stop and restart the task, or insert the message into the worker's next tool result as steering. In one implementation, your message becomes an annotation prefixed with User guidance: inside the worker's transcript. Another collects every message received while the agent is busy and replays them together after the run ends.

These are reasonable policies for a system with one loop. They share the same limit: the only model that could decide whether to reply is busy doing the work.

A layer whose only job is the conversation

Unify's runtime has a ConversationManager, a separate model loop that handles the conversation but has no tools for doing the work. When work is needed, it calls act(...), receives a handle immediately, and remains available. Running tasks appear in its context as in_flight_actions. Each one has tools for sending a correction, checking progress, pausing, or stopping.

Left: channels feed a gateway with queue/steer/interrupt busy policies into one agent loop, where mid-task messages are queued or pasted into tool results. Right: mediums feed a ConversationManager with its own LLM loop — speak or wait, response policies, act and steering tools — delegating to two in-flight CodeActActors, with notifications flowing back. — The same inbound message, in the two architectures.

A message that arrives mid-task does not have to wait or stop the work. The conversation layer can answer directly, send a correction to the task, or check its progress. It can also say nothing. On a live call every turn is an explicit choice between SPEAK and WAIT.

Progress notifications travel in the other direction. Workers send them to the conversation layer, which decides whether to pass them on now, later, or never. The same layer serves every medium, so it sees the relevant history whether you return by chat, email, or a live call.

Thinking Machines drew the same picture

In May 2026 Thinking Machines published Interaction Models: A Scalable Approach to Human-AI Collaboration. The model handles 200ms micro-turns over continuous audio, video, and text instead of waiting for fixed turn boundaries. Their paper argues that AI labs have focused on autonomy and, as a result, humans "increasingly get pushed out not because the work doesn't need them, but because the interface has no room for them."

Their answer is a two-part system, with a time-aware interaction model that maintains real-time presence, paired with an asynchronous background model that handles sustained reasoning and tool use. When deep work is needed the interaction model delegates, sending what they call "a rich context package — not a standalone query", and then "remains present throughout — answering follow-ups, taking new input, holding the thread — and integrates background results into the conversation as they arrive."

Their diagram has the same system-level split. An interaction model stays present while a background model works. Our ConversationManager occupies the interaction seat, while actors perform the background work. act(...) sends a filtered snapshot of the live conversation rather than a bare query, and results return through the same layer. On voice we repeat the split at a shorter time scale, with a fast model handling turn-taking while the slower model composes substantive answers.

Voice call architecture: a caller connects through a LiveKit room to the fast brain (STT, VAD, TTS, fast LLM, fillers and barge-in), which exchanges utterance events and notifications with the slow brain — the ConversationManager's persistent reasoning loop — over IPC. — The fast/slow split on live calls: presence and reasoning on different clocks.

The obvious objection

Thinking Machines would push back on one thing, since their post argues interactivity should live in the model rather than in a harness, and cites the bitter lesson. We are a harness. I take that seriously. For the really low-level stuff, like working out whether someone has finished a sentence or is just pausing mid-thought, I think they're right, and I'd happily delete our voice-activity plumbing the day their model is an API.

Their diagram still has two loops and a delegation boundary. The interaction model must connect to the user's channels, the assistant's memory, the team's permissions, and the long-running tasks it can steer. Our conversation layer provides those connections. A native interaction model could replace the fast model and much of our turn-taking code while keeping the surrounding system. If conversation and work share one loop, there is no separate seat to upgrade.