Long-Running AI Agents Need a Task System, Not a Better Chat Window

An AI agent can appear to be working while the product has already lost control of the work.

The message keeps streaming. A progress indicator moves. Then a browser tab refreshes, a tool call times out, a person comes back the next morning, and nobody can answer three basic questions: What did the agent already do? What is safe to retry? What exactly needs a human decision?

That is not primarily a model problem. It is a task-system problem.

As agents move from answering questions to researching, coding, processing files, coordinating with business systems, and preparing customer-facing work, a chat window becomes an increasingly poor control surface. It can show a conversation. It cannot reliably own state, approvals, retries, handoffs, artifacts, and cancellation.

OpenAI's July 2026 guidance on long-running Codex work is useful context: long work improves when teams give an agent a prepared environment, a concrete task, clear acceptance criteria, and feedback on what it produced. The transferable lesson is not that every product needs a coding agent. It is that a long-running agent must operate inside a work contract, not an endless prompt.

The signal is not duration alone

A task that takes two minutes may need durable handling. A task that takes an hour may not. The better question is whether losing the current run would create meaningful cost or uncertainty.

Move work out of a chat-shaped interaction when at least two of these are true:

• It can pause or outlive one browser request. A report may wait for a data source, a queue, or an approver.
• It changes something outside the product. Sending a message, changing a record, creating an invoice, publishing a page, or deploying code has consequences beyond a draft.
• It can spend money or consume a limited resource. Model calls, paid data, API quotas, compute jobs, and credits need a budget boundary.
• It produces an artifact another person must use. A patch, research file, export, campaign draft, or support response needs a clear owner and a reviewable version.
• It may be restarted. If a retry can create duplicates, repeat a charge, overwrite a newer record, or contact a customer twice, the product needs an explicit retry rule.

This is why “give the agent more context” is only part of the answer. Context engineering helps an agent decide well. A task system helps people and software recover when the work is interrupted.

A minimal lifecycle has more value than a clever progress animation

For many small products, the first useful state machine is deliberately boring:

Do not add states to imitate an enterprise workflow product. Add them because each one changes what the user can do next. “Running” is insufficient when the real next action is “upload the missing file,” “approve sending this,” or “take over from the agent.”

The record behind each task should be equally concrete. At minimum, keep the input snapshot, the allowed tools and permissions, a spend or effort ceiling, the source materials, the checkpoints, every external side effect, and the final artifact. A chat transcript is useful evidence, but it is not a dependable task record.

Checkpoints turn a fragile run into a recoverable one

A checkpoint is not a decorative update such as “still thinking.” It is a durable boundary after which the next step can be understood and resumed.

For a market-research task, a good checkpoint may be “sources collected and deduplicated; the draft has not been written.” For a coding task, it may be “tests are green on the current branch; no pull request has been opened.” For an operations task, it may be “the CRM records were matched; no customer has been contacted.”

Each checkpoint needs three properties:

1. A named artifact or state change. Someone can inspect it without reconstructing the entire conversation.
2. A next action. The system knows whether to continue, wait, ask, or stop.
3. A retry boundary. Re-running the next step does not silently repeat a completed action.

Temporal's workflow documentation describes the general durable-execution concern: work can survive failures and be resumed rather than treated as a single fragile request. You do not need that specific platform to adopt the principle. You do need to decide what happens after a worker restart, a provider timeout, a rate limit, or a person closing a laptop.

Approval is a product decision, not a generic “Are you sure?” dialog

Human review belongs before an action becomes hard to reverse, expensive to repeat, or harmful to an external party. It should not appear after the agent has already sent the email, overwritten the record, or spent the budget.

OpenAI's Agents SDK treats human-in-the-loop control as an interruption point around tool use. That maps cleanly to product design. An approval screen should let a reviewer answer a real decision, not merely click a reassuring button.

Show:

• the action in plain language;
• who or what will be affected;
• the source evidence and any uncertainty;
• the monetary, data, or reputational consequence;
• the exact scope, such as recipients, records, files, or deployment target;
• options to approve, edit the parameters, reject, or stop the task.

A useful rule is simple: draft freely, execute cautiously. A support agent can prepare a response without a pause. Sending it under the wrong policy is a different class of act. A coding agent can propose a patch. Merging it, rotating a secret, or deploying it needs a separate decision and a visible rollback path.

Retries need idempotency, budgets, and a stop condition

The most expensive agent failures are often not dramatic. They are loops.

An agent retries a slow enrichment call five times. A provider returns after a timeout, but the product has already sent a duplicate request. A task re-runs from the beginning and emails a customer again. A broad search quietly consumes the monthly budget before anyone sees the first useful result.

For each external step, define an idempotency key or an equivalent record of whether that specific action already happened. Set a per-task budget, a retry count, a timeout, and a failure owner. Then give the task a stop condition: “pause after two failed source fetches,” “ask for approval before crossing $10,” or “cancel when no acceptable artifact exists after three bounded attempts.”

This is also where AI ROI as cost per accepted task becomes useful. A cheap individual model call can be expensive when the run repeatedly fails, waits for people, or produces work that nobody can accept. Measure the full task, including recovery.

Start with one task that deserves to be boring

Do not begin by giving an agent broad access to every business system. Choose one recurring task with a bounded input and a recognizable artifact.

A good first candidate might be a weekly competitor brief, a structured support-draft queue, a repository issue triage, or a document-to-CRM preparation task. It should be useful enough that a person cares when it fails, but reversible enough that failure does not damage a customer relationship.

Run ten real tasks for one week. For each run, record:

• whether the input was complete;
• which checkpoint was last reached;
• how often the product had to ask a person for information;
• whether a retry was safe and whether it occurred;
• whether the final artifact was accepted;
• total model, tool, and review cost;
• the reason for a stop, escalation, or cancellation.

At the end, do not ask whether the demo looked autonomous. Ask whether the task became more reliable, more inspectable, and cheaper to recover. If it did not, improve the task boundary before adding another agent capability.

When a chat window is still the right product

Not every AI feature needs a queue, orchestration layer, or work-history dashboard. Keep the interaction simple when the output is immediate, inexpensive, reversible, and can be discarded without confusion. A rewrite suggestion, a short explanation, or a low-risk classification can remain conversational.

The dividing line is accountability. Once a user expects a result later, expects another person to trust it, or could be harmed by a repeated action, the product owes them a task they can inspect and control.

For the permission layer behind those controls, use the AI Agent Security Checklist. For the work-quality layer, use the AI ROI scorecard. Together they turn an agent from a persuasive chat interface into a product that can finish work without hiding its failures.