Real-time agents need two clocks. Conversation latency and task latency are different SLOs.

Tencent's Gander keeps full-duplex conversation separate from asynchronous long-horizon work. Production agents should measure interaction latency and task execution independently instead of hiding both behind one response-time number.
Tencent released Gander on 9 September as an open-source agent that keeps a live multimodal conversation running while a separate asynchronous worker handles longer tasks. Its technical report describes a Cerebellum-Brain architecture: the Cerebellum owns real-time interaction, while the Brain handles complex reasoning and higher-level agentic work.
The obvious reading is that this is another voice-model release. The more useful reading is architectural. A production agent now has at least two latency domains with different failure modes: the time required to acknowledge and steer a user, and the time required to complete the delegated work.
One response-time metric hides the failure
Gander's repository makes the split operational. A task can start from a trusted user turn, accept new constraints while it runs, fork a read-only side inquiry, ask for permission and be cancelled without ending the live conversation. Execution generations fence stale results after an objective changes.
That state model matters more than whether the front end feels fast. A conversational layer can answer in hundreds of milliseconds while a background task is stuck on a tool, waiting for approval or continuing against an obsolete objective. Averaging those events into one end-to-end latency number produces a healthy dashboard for an unhealthy agent.
Responsiveness and completion are different reliability properties. Measure them on different clocks.
The same separation applies to errors. A missed interruption is an interaction failure. A stale result delivered after the user changed the objective is an orchestration failure. A tool timeout is an execution failure. They need different telemetry, retry rules and service objectives.
The orchestration layer becomes a control plane
Gander's design routes task state, trusted turns, worker events, permissions and deliveries through an orchestration runtime between the conversational model and the worker. The included Brain provider is Codex, but the provider interface is replaceable. That makes the boundary useful even when the models change.
For production teams, the control plane should own task identity, generation or revision number, permission state, cancellation, tool events and final-delivery eligibility. The conversational model can request a task change; it should not be the only authority deciding whether an old result is still valid.
This also changes observability. Trace the live interaction and background execution separately, then join them with a stable task identifier. Record time to first acknowledgement, interruption handling and clarification latency on the interaction side. Record queue time, tool latency, approval waits, retries, objective revisions and time to verified completion on the execution side.
Design the SLO around the handoff
The practical test is not whether an agent can talk while it works. It is whether operators can prove which objective the worker is executing, whether the user can redirect it without losing state, and whether stale work is prevented from becoming the final answer.
Gander is research, and its reported evaluations should not be treated as production guarantees. But the architecture exposes a useful deployment rule: do not make a single model response the unit of reliability for an asynchronous agent. Define separate interaction and execution SLOs, instrument the handoff between them, and make task state an explicit production object.
Sources
- Omni Interaction Agent Technical Report — Gander research team
- Omni-Interaction-Agent repository — Gander research team
- Tencent's Gander aims to keep talking while it works in the background — The Decoder
Written by the Devence Lab research team.

