Talk while it works: why our agent takes interruptions

An early tester was working through a long task when she typed a correction into the chat — without stopping anything. Afterwards she told us the moment felt unexpectedly good: the other agent tool she uses makes her stop the run first before it will accept a new message. "Having to halt it just to talk to it felt dumb," she said, "compared to this."

She's right, and the difference is not a small UX nicety. It comes from a design decision we made early and keep re-applying: an agent is a colleague, not a machine. You interrupt a colleague mid-sentence and they fold it in. You don't power-cycle them.

Why "stop first" is the wrong default

Making the user halt a run before speaking has three costs, all borne by the user:

• The correction comes too late. The moment you notice the agent going off-track is exactly when you should speak. Forcing a stop means watching it burn time and tokens down the wrong path while you fumble for the halt button.
• Stopping destroys state. A halted run doesn't resume — you start over, or worse, you get a "cancelled" stub and re-explain the context. Your mid-flight course correction costs you the whole in-flight work.
• It inverts who's serving whom. "The machine can't hear you right now, come back later" is the machine's convenience, not yours.

How ours actually works

When you send a message while a run is in flight, three things happen in order:

1. Your words are saved first. The message lands in the conversation history immediately — before anything is dispatched. Your intent is durable from that instant; no queue, buffer, or timing can lose it.
2. It's delivered at the next step boundary. The agent doesn't drop what it's holding mid-tool-call — it reads your message at the next natural pause, the way a person finishes a thought and then takes your point.
3. It steers, not restarts. Everything the run already did stays. Your message is a course correction applied to a moving task, not a reboot.

The principle underneath: durability of user intent outranks convenience of the system. Once the words are saved, everything downstream is timing — and timing can be made graceful. Unsaved intent can't be recovered at all.

What it looks like in practice

The clearest example is already public. In the clock story, the founder's request pivoted twice while the agent was working — "actually, make it an HTML version," then "package it like an installable web app." Each interjection landed mid-run and bent the trajectory. Nobody pressed stop; the app that shipped was shaped by corrections delivered in flight.

The subtler everyday version is duller and more valuable: you're ten messages into a research task, you spot it building the wrong comparison, you type "compare against X instead" — and watch it turn without losing the eight good sources it already gathered.

The principle travels

This week we hit the same question from the other side: what happens when we interrupt you — a server restart for a deploy? The honest answer turned out to be the same rule. During deploys the server now accepts mid-run injections (your saved words survive and the next run picks them up in context) while pausing only new-run starts. Rejecting input the user already typed would have been our convenience overriding your intent — the exact inversion we criticized above, just wearing an ops costume.

We're not claiming this is novel — queued interruptions are how good systems have worked forever. It's just rare in agent UX, where "stop the machine to talk to it" somehow became the norm. We're happy to be the boring, correct default.