Long-Running AI Agents Need a Waiting State

An AI agent can stop working for a good reason. The missing invoice has not arrived. Someone needs to choose between two plausible interpretations. A review is required before the next action. Generating another answer will not remove any of those dependencies.

Yet the language around autonomous agents still rewards uninterrupted motion. Longer runs, more tools, more steps completed without a person. That makes a convincing demonstration. It is an incomplete specification for software that must finish real work.

My position is simple: a long-running agent needs an explicit waiting state, a precise reason to leave it and a reliable account of the work already completed. Without those, a pause becomes indistinguishable from a crash, and “continue” can mean “start again”. Our production workflow records at Norman make this distinction concrete. The useful finding is about what the states mean, not how many tasks they contain.

What makes an AI agent long-running?

A long-running agent keeps responsibility for an objective across interruptions. It may perform a short burst of work, wait for an external event and continue later. Keeping a model generating throughout that interval is neither necessary nor evidence of useful progress.

The industry is moving in this direction. On September 14, 2026, Salesforce announced a runtime for goals spanning days and weeks; its first agent, Hunter, was in pilot. On September 15, Workiva introduced Agent Studio, including company context and scheduled workflows.

Those announcements change the product question. A conversational assistant can return control after an answer. A persistent workflow must explain who has the next move when the answer alone cannot advance the task. “The agent is active” is too vague to settle that question.

For builders, this is a shift in the unit of work. The conversation, the model invocation and the business objective have different lifetimes. Treating them as the same object makes an innocent pause look like either a technical failure or a completed job.

Is a waiting agent a failed agent?

Sometimes waiting is correct. Sometimes it hides a defect. A system needs enough state to tell the difference without asking the reader to interpret a transcript.

Consider an agent preparing documents for review. It has matched the available material and now needs a missing attachment. The completed matching work remains useful. The next step depends on evidence that a model cannot manufacture. Calling the entire process “running” suggests ongoing computation; calling it “failed” discards the distinction between missing information and a broken operation.

The following is a design vocabulary, not a claim about a particular vendor's implementation:

These distinctions are useful only if they change behaviour. A waiting state that the scheduler immediately retries is a label without a contract. A failed state that offers only “ask the agent again” transfers recovery work back to the user.

What did Norman's production records show?

We checked stored workflow states in a fixed recent creation window, using read-only aggregate queries. The cohort contained workflows with automated step types. We inspected state markers and whether steps had been marked complete, without reading conversations, documents or customer identities.

The records included workflows labelled active that were explicitly blocked on user input or a manual step. Steps marked complete coexisted with those human dependencies. A lifecycle label therefore could not tell us whether a workflow was computing, awaiting a person or already finished with part of its work.

The check also exposed a combination of a human-input blocker and a running step marker. That observation deserves care. A stored running marker does not prove a worker is currently executing. A snapshot cannot tell us which transition produced the combination, whether it was transient or what the person saw. It does show why competing status fields need an explicit interpretation.

We are not presenting this as a completion-rate benchmark or evidence that every pause was justified. We did not measure time spent waiting or verify eventual outcomes. The narrower conclusion is useful enough: operational records distinguish human dependencies from completed progress, while the word “active” conceals that distinction.

Our current runner code makes that separation intentional. It stops at a manual step, and an explicit request for input keeps the current step open. That is source-level behaviour; the database review does not establish which deployed revision created every historical record. The broader role of this surrounding software is covered in our agent harness article.

What should an agent save before it waits?

A good waiting record should let someone continue the work without reconstructing the whole conversation. It needs the unresolved question, the dependency that blocks progress, the work already completed and the event that allows the task to resume.

“Please review” is a weak request. “The receipt and the transaction disagree on the date; choose which document should support this entry” describes a decision. The exact question depends on the workflow, but it should explain why the agent cannot safely infer the missing answer from available evidence.

The request should also identify who needs to act. Otherwise everyone can see that work is blocked while nobody knows whether it belongs to them. A person should be able to answer, explicitly skip a permissible step or cancel the task. Those outcomes have different meanings and should stay distinguishable afterward.

Saving a conversation is not sufficient. A transcript may contain an outdated plan followed by a correction. The application needs a current account of completed work and unresolved dependencies. Our discussion of tool-result contracts addresses the related problem of keeping missing information separate from an empty result.

This is also where I would resist adding more autonomous reasoning. Once the missing dependency is identified, repeated deliberation can produce increasingly elaborate guesses. The next useful operation may be delivering a clear question and releasing the worker until something relevant changes.

How should an AI agent resume after a pause?

Resuming should start with the saved task and the new evidence. It should not automatically replay every action described in the chat. An invoice may have been edited, an attachment replaced or the task cancelled while the agent was waiting.

A practical resume path checks whether the task is still open, whether the required input arrived and whether earlier conclusions still apply. It then continues from the earliest step affected by the change. Unaffected completed work should remain completed; changed evidence may require a specific result to be recomputed.

This is a proposed operating contract, not a claim that our aggregate review tested every recovery path. In particular, saved progress alone does not prove recovery after a worker crash or prevent duplicate external effects. Those guarantees require their own implementation and tests. Our article on agent retries explains why the boundary of a retry matters.

Human input should resolve a dependency, rather than silently expanding the task. If an answer introduces new work, the system needs to make that scope visible. Otherwise a simple clarification can turn into an open-ended assignment whose completion conditions keep moving.

How do you evaluate an agent that sometimes waits?

Separate the time spent doing work from the time spent waiting for another actor. Then examine whether the waiting request was useful. Did it name a real missing input? Could the agent already have found the answer? Did the response unblock the intended step?

Completion matters, but a single completion figure cannot answer those questions. A workflow can finish quickly by making an unsupported assumption. It can also wait indefinitely after asking a vague question. Both behaviours deserve attention, even though their terminal states look different.

For a demonstration, deliberately withhold a necessary attachment. Inspect the waiting state, provide the attachment, change a relevant fact and watch what resumes. Check whether completed work survives and whether the system revisits the result affected by the change. Repeat with cancellation. This tests the handoff the polished happy path leaves invisible.

I would judge the promise of long-running AI by that transition. Can the product explain why it stopped, preserve useful work and respond correctly when circumstances change? An agent that can answer those questions has a meaningful basis for working over time. A longer uninterrupted run, by itself, does not supply one.