MOSS-Live kept talking while tools worked. Publish the two-timeline handoff

THE SIGNAL IN ONE SENTENCE

Most voice assistants still behave like someone holding a walkie-talkie. You speak. They wait. They think. Then they speak while you politely pretend not to interrupt. MOSS-Live is trying to make that rhythm feel more like a real conversation. The OpenMOSS team describes a full-duplex system that can listen and speak at the same time, respond to interruptions and backchannels, track live video, use tools in the background and return to the conversation when a task is ready. Its public demonstrations include a group meeting, a road trip around Zhoushan and a guide in Shanghai. The interesting part is not just that the assistant can talk over the sound of its own machinery. It is how the machinery is divided. MOSS-Live uses a foreground interaction model for listening, turn taking and speech. A background task model handles longer reasoning, tools and jobs that should not freeze the conversation. A coordination layer shares memory, context and task state between them. That gives the assistant two clocks. On the foreground clock, a person may interrupt, correct a name, change the destination, revoke permission or ask a new question. On the background clock, a search may still be running, a calendar request may be pending or a route may have been calculated from instructions that were true 20 seconds ago. The product challenge is no longer only whether the model can hear and answer. It is whether those two timelines can meet without smuggling stale instructions into the final reply. Imagine asking a voice assistant to find dinner near the station while you continue talking with a friend. The background model starts a search. A few seconds later you add that one person has a severe peanut allergy. The assistant acknowledges the correction and keeps the conversation moving. What happens to the search already in flight? If the allergy update changes only the conversational memory, the tool can finish with an unsafe result. If the background task sees the update but does not reveal that it restarted, the user may not know why the answer is delayed. If both timelines write to shared memory at once, an older tool result can overwrite the newer constraint. If the user says cancel, the foreground voice can sound reassuring while the background action continues. This is why every live agent needs a two-timeline handoff. The handoff should begin when a background job starts. Give the job an identity, start time, initiating user request and a versioned snapshot of the constraints it received. Show whether it can only read, whether it can change something and which tools or services it may touch. Then keep a change log while the conversation continues. A correction, interruption, new preference, consent change or cancellation should be written as an event with a timestamp and a consequence for the job. The background task should either accept the update, restart under the new constraints, pause for clarification or declare that the change arrived too late. When the tool returns, the result should carry its own timestamp and dependency list. Which location did it use? Which date? Which people? Which allergy, budget or access constraint? Which version of the conversation state? A result is not current merely because it arrived last. Before the assistant speaks the result, the coordination layer should compare the result against the newest user state. If the state changed, the assistant can say what happened in plain language: the first search finished using your old location, so I discarded it and ran a new one. That is a tiny sentence with a lot of trust inside it. Cancellation deserves the same rigor. A spoken stop should not be a decorative phrase. The foreground model needs to send a cancellation signal to the background task, receive an acknowledgement and disclose any action that could not be reversed. If a reservation was already submitted or a message already sent, the assistant must not pretend that silence erased it. The OpenMOSS article reports strong results on the team's selected evaluations. On FDB v3, the project reports a 51.00 percent tool-use success rate, tied for the best figure in its comparison. On tau-Voice, it reports 57.93 percent multi-turn task success, second highest in the presented table. In a tool-use breakdown, the team reports 95.68 percent tool-selection F1, 72.17 percent argument accuracy, 66.00 percent semantic success, 83.00 percent post-tool response quality and 2.36 seconds of latency. Those figures are useful signals, not field guarantees. They come from the project and selected benchmark settings. They do not establish how the system handles a noisy kitchen, overlapping speakers, code switching, a poor connection, a child in the room, a revoked permission or a tool that returns after the conversation has changed. A benchmark can score whether a tool was called. It rarely captures whether the human understood which version of their request the tool actually used. The public repository also deserves a sober reading. At verification time it was a very small repository with a single visible commit, documentation and media assets. No public model weights or complete implementation were visible in the reviewed listing. That makes the architecture and demonstrations inspectable as a proposal, but it does not yet give outside teams the material needed for full reproduction. There is still plenty worth learning from the design. Splitting interaction from task execution is sensible. A slow search should not make the assistant deaf. A person should be able to interrupt a long explanation without destroying a useful background job. A live camera feed can help a guide respond to what someone is seeing now. Streaming interpretation can preserve conversational rhythm instead of waiting for complete paragraphs. But shared memory is not magic glue. It is a concurrent system. Software engineers already know the failure modes: races, stale reads, partial writes, duplicate work, conflicting updates and actions that finish after cancellation. Voice makes those failures harder to inspect because the interface disappears as soon as the sentence ends. A pleasant voice can turn uncertainty into false confidence with remarkable efficiency. So publish the state. Not as a wall of developer telemetry. Give the user a compact live card or spoken summary showing what the assistant is doing, which request version it is using, whether the job is read-only or can take action, when it last incorporated a correction and how to stop it. Keep the detailed event log available for review after the conversation. For higher-stakes tasks, the handoff should require confirmation. Before sending money, booking travel, changing a record or contacting another person, read back the final action using the newest constraints. Name anything that changed while the task was running. Ask once, clearly, at the point of consequence. The privacy problem runs on two timelines too. A system that continuously listens, watches video and shares memory across models may capture bystanders, private surroundings and conversations that were never meant for the assistant. Selective attention is not consent. The product should make microphone and camera state obvious, separate wake and record behavior, minimize retention, let users inspect and delete stored memory and avoid training on ambient material without a specific choice. Group conversations need special care. One person may invite the assistant while everyone else is merely present. A backchannel such as yes or right can be conversational grease, not authorization. The system should not turn an overheard remark into a tool instruction unless the speaker, intent and permission are clear. The useful future here is not a machine that never stops talking. It is an assistant that stays present while work continues, then tells you exactly which conversation produced which action. MOSS-Live makes the two-clock architecture unusually visible. That is valuable. Now the handoff needs to be just as visible: start state, live changes, tool state, cancellation, freshness check and final claim. Conversation can feel natural. Consequences still need paperwork.