There is a complaint making the rounds that lands hard if you have ever babysat an autonomous agent: when the agent fails mid-task, the chat window turns you into the retry protocol. The agent stops, says something vague, and waits. You re-read your original request, restate it with one more constraint, and send it back. It fails again, slightly differently. You clarify again. Each failure costs a few extra turns of you re-explaining what you already explained.

That is not a model problem. It is an interface problem. Chat is a wonderful way to author intent — to explore, to phrase a goal, to react to a first draft. It is a poor way to recover from failure during long-running autonomous work. Those are different jobs, and we kept reaching for the wrong tool until our own system forced the distinction.

A recovery interface has to do three things a conversation does not: bound retries, isolate failure, and fail loudly. Our whole task system exists because chat does none of them.

Chat does not bound retries

A conversation has no built-in stopping rule. If an agent keeps failing and you keep clarifying, the loop runs until you get tired. The conversation itself does not know it is going in circles — it has no counter, no budget, no notion that this is the fourth attempt at the same dead end.

Our earliest version of this had no counter either, and it bit us. A single task hit an upstream wall it could not get past and entered a retry loop. There was no chat turn to interrupt it, so it just retried. It tried that one task several hundred times in a row before anyone looked. Nothing was making progress; the system simply had no idea it was supposed to stop.

The fix was not a better prompt. It was moving the stopping rule out of the conversation and into the task object. Every task now carries a failure count. When it fails, the count goes up; the task resets to a ready state for a second and third attempt, and on the third failure it is marked permanently failed. No more retries, no exceptions. The bound is a property of the task, not something a human has to remember to enforce by closing the tab.

This is the load-bearing difference. "Don't retry forever" stated in a prompt is a hope. "Retry at most three times" enforced in the code that runs the task is a guarantee that holds especially when the agent is in a bad state and reasoning poorly — which is exactly when you need it.

Chat does not isolate failure

When you recover through conversation, each failure is handled in a vacuum. The chat does not know that the last five tasks failed for the same reason, because each one is its own little thread. So a shared, upstream problem becomes a per-task retry storm: everything downstream keeps trying, keeps failing, keeps burning attempts on a wall that is not going to move for the next hour.

We learned this the expensive way. An upstream dependency went down, and before we had any shared signal, every task that touched it ran its full retry budget against a service that was simply offline. Many tasks, three attempts each, all doomed, over many hours.

The structured answer is a circuit breaker that lives above the individual task. When a class of failure shows up — an upstream that is down, a credential that has gone bad — the system writes a short-lived, timestamp-stamped marker and stops spawning work that depends on it. Crucially, the marker expires on its own clock rather than waiting for someone to clear it; after the backoff window, the system tries one probe and resumes if the probe succeeds. The failure is isolated to one shared switch instead of replayed independently in a hundred separate threads. No human has to notice the pattern across conversations, because the pattern is recorded as data in one place.

Chat makes you the dependency tracker

The most underrated thing chat does not do is hold readiness conditions. If a task cannot run yet — it is waiting on a date, on another task finishing, on a step that has to come first — a conversational interface offloads all of that onto you. You are the one who remembers to come back later and say "okay, now."

A structured task carries its own readiness. A task can hold a date gate ("not before this day") that the system promotes automatically when the clock passes it. A task can declare that it depends on another task and only becomes eligible when its parent completes. A task can spawn its own follow-ups on completion, so the next step appears without anyone re-typing it. The decision of when work resumes belongs to the system, not to a human re-entering the same instruction at the right moment.

This is the part that quietly drains your day with a chat-only setup. It is not the dramatic failures; it is the dozens of "ping me when X is done" obligations that the interface silently assigns to you.

Chat fails quietly

A stalled conversation looks exactly like a conversation that is thinking. The agent goes quiet, and you cannot tell from the interface whether it is working, stuck, or dead. Failure here is something a human has to notice.

A structured task fails loudly because failure is a state, not a silence. Every task moves through explicit states — pending, ready, claimed, in progress, failed — and a running task emits heartbeats. If a task is claimed but its heartbeat goes stale, a monitor detects the orphan and resets it without anyone watching. Failure surfaces as a row you can query and a status that changes, not as a chat that simply stopped updating. You find out because the system told you, not because you happened to scroll back.

You author in chat; you recover in structure

None of this is an argument against chat. Chat is still where intent is born. It is the right place to say what you want, to look at a first attempt, to change your mind. We would not give that up.

The mistake is using the same surface for failure recovery. The moment work goes autonomous and long-running, recovery needs properties a conversation structurally lacks: a retry bound it cannot exceed, a shared switch that isolates a common failure, readiness conditions it carries itself, and a failure state that announces itself. Wrap the work in a task object that has those, and the human stops being the retry protocol. Chat goes back to the one thing it is genuinely great at — telling the agent what "done" looks like in the first place.

Next time: what a task object should actually carry across a handoff — and why "just pass the conversation history" loses the one thing the next agent needs most.