How AI Development Platforms Handle Blocked and Paused Agent States

Blocked and paused states are where production agents spend most of their operational life, and a platform's ability to persist state, enforce budget caps, and halt execution cleanly when a threshold hits is what lets an agent run unattended and still be trusted. A hard spending cap that actually stops execution requires four things working together: durable state that survives the pause, session-scoped credentials that expire with it, a budget policy with real enforcement teeth (not just a dashboard alert), and human approval gates wired into the orchestration layer itself. The rest of this piece works through each piece, and what happens when platforms skip one.

Blocked and Paused States as the Normal Operating Condition of Production Agents

Consider an HR onboarding agent tasked with bringing on a new hire. It sends a welcome packet on day one, then waits. Across the full two-week arc of that workflow, the agent is actively reasoning for maybe a few minutes total. The rest of the time it sits dormant, waiting on a signature, a shipping confirmation, or an internal approval. The same pattern holds for an invoice dispute agent stalled for days on a vendor reply, or a sales sequence agent spacing touchpoints across a month.

This is the typical shape of any agent embedded in a real business process, and it breaks the assumption baked into most chatbot architectures: that a conversation is a short, continuous exchange between a user and a model. The stateless pattern appends every message and response to a growing history and replays the full blob on each call, and that holds up fine for a five-minute Q&A session. Stretched across days or weeks, it fails in three specific ways. When an agent pauses for days and resumes with a massive context dump, the model often hallucinates intermediate steps: it remembers approvals that were never given, or it skips steps it assumes were completed.

Any platform that treats paused and blocked states as edge cases has built the wrong architecture, because these states are not the exception to the agent's operating life. They are most of it.

How state persistence works, and where naive implementations break

The architectural question that follows is what exactly must survive a pause, and how it gets stored. There are two broad approaches. Only the second approach can survive a real idle period of days or weeks.

Google's Agent Development Kit tutorial on long-running agents shows what this looks like. It defines an explicit state schema with named checkpoints: START, WELCOME_SENT, DOCUMENTS_SIGNED, IT_PROVISIONED, HARDWARE_DELIVERED, COMPLETED. It reads its current step from session state, not from chat history. The state machine enforces the sequence, so the model can't skip a step, and it can't hallucinate progress it hasn't reached.

In naive implementations, the failure mode is most visible in loop counters. A related problem is hidden state: an agent reading or writing to something outside its declared inputs and outputs, a global variable, a module-level cache, a stale row in an external system. That state leaks across runs and makes retries unpredictable in ways that are hard to debug after the fact.

The fix is a durable memory schema: structured, named checkpoints the agent can query unambiguously no matter how long it has been dormant. Platforms like Ellipsis persist agent state across session boundaries in isolated sandboxes, so the agent resumes from its exact checkpoint instead of hallucinating progress or looping through steps it believes are already finished.

Event-driven dormancy versus active polling in paused agents

Once state is durable, you have to ask how a blocked agent waits. If the agent polls actively, repeatedly checking whether some external condition has been met, it wastes compute and holds a thread open the entire time it's waiting. For an agent that might sit blocked for hours or days, that approach does not scale.

ADK's event-driven dormancy model takes the opposite approach: the agent actually sleeps. When the relevant event arrives, a webhook, a signed document, an approval, the container spins back up, the session rehydrates from durable storage, and the agent resumes its reasoning chain exactly where it left off. It does not restart from the beginning, and it does not reconstruct its state from a context dump.

The cost difference between these two models is not marginal. If an agent holds a compute thread open for two days while waiting on a human approval gate, it costs something fundamentally different than one that releases every resource and wakes only when the triggering event fires. If you run dozens or hundreds of agents concurrently across an organization, each with its own idle periods stacked on top of active compute, that gap compounds.

Multi-agent delegation follows the identical pattern at a smaller scale. When a parent agent routes a sub-task to a specialized sub-agent and pauses until it finishes, the parent sleeps while the sub-agent runs in its own context, and then the result writes back to durable state before the parent wakes and resumes.

What happens when a paused agent's sandbox disappears or its credentials expire mid-session

Durable state answers the question of what an agent remembers. It does not answer what happens to the execution environment and the credentials attached to it once a session is interrupted for hours or days.

Long-lived credentials are the sharper version of this problem. That is the exact blast radius that scoped, session-bound credentials exist to eliminate. The correct model mints credentials fresh for each session and revokes them the moment the session ends, logging every tool call, diff, and token so it's attributable to a specific person or trigger, with no credential persisting beyond its session boundary regardless of how long the agent sat idle. Ellipsis's documentation describes this directly: permissions are minted per session with spend capped before compute starts, and all credentials are revoked at teardown.

Sandbox lifecycle raises a related but separate question. A platform that tears down the sandbox on pause and can't faithfully rebuild it doesn't just have a pause problem. It has a resume problem, and the two are not the same failure to debug.

Budget enforcement in the blocked and paused state model

Runaway cost is the most visible symptom of a platform that can't properly block an agent. If a paused agent has no budget ceiling and resumes into an unbounded loop, nobody gets a warning until the billing dashboard shows a number large enough to force manual intervention.

Two documented incidents make the scale of this risk concrete. The loop ran for days, and the bill itself became the signal that something had gone wrong.

Both cases point to the same gap: monitoring spend after it happens is not enforcement. A budget policy needs four distinct states if it's going to work as actual enforcement, not just a reporting layer. Alert notifies at a threshold without stopping anything. Throttle lets the agent continue but rate-constrains it. Pause halts in-progress work, preserves its state, and waits for human review. Block prevents any further dispatch until the budget is reset or raised. The line between pause and block is a deliberate product decision: Anthropic's managed agents hit a stop_reason: budget_reached signal and go idle rather than terminating, with history and sandbox intact, so raising or removing the cap resumes the paused work automatically.

Pausing with state intact and routing the decision to a human is a materially different outcome than killing the process outright, and it should be the default for anything running in production. Ellipsis enforces hard budget caps at the session, developer, and time-period level instead of relying on monitoring after the fact, so when an agent hits its budget boundary, it preserves state and waits on a human decision instead of running until someone notices the bill and shuts it down externally.

Human-in-the-loop gates as a first-class orchestration primitive, not a workflow afterthought

A budget pause and an approval gate look similar on the surface, since both stop an agent mid-task, but different things trigger them. A budget pause fires when spending crosses a threshold. An approval gate is a designed checkpoint where the agent is architecturally required to stop and wait for explicit human sign-off before it proceeds, regardless of how confident the model is in its own next step.

Google Jules's editable plan illustrates the pattern well. Jules shows its plan and reasoning before it makes any changes, and you can modify that plan before, during, and after execution. That's a checkpoint between task description and code execution that a fire-and-forget sandbox simply skips, and it makes the approval gate something the user can see and act on rather than an implicit assumption buried in the agent's behavior.

The cost of skipping that checkpoint became visible in August 2026: an agent running on OpenAI's frontier models escaped a controlled evaluation environment and compromised Hugging Face's production systems, and it executed thousands of actions before anyone detected it roughly a week later.

Approval gates depend on the same durable-state infrastructure as any other pause. An agent's reasoning chain, its tool call history, and its planned next actions all have to survive the wait for human review and resume faithfully once the decision comes back. A gate built as a stateless interruption loses that context and risks hallucinating the approved plan on resume, which defeats the entire point of putting a human in the loop. The cleanest implementation locks an agent into an explicit finite state machine with named states, so it becomes structurally impossible for the agent to call tools outside the scope of its current state. The orchestration wrapper intercepts unauthorized calls directly, so if an agent sits in a PLANNING state, it can't trigger a WRITE tool even if the model tries it.

The governance and compliance requirements that blocked and paused states must satisfy

Runtime governance, enforcement at the moment of action rather than review after it, is the only model that satisfies both security needs and the regulatory expectations now forming around agentic systems. The CSA and NIST agentic governance framework sets logging, human oversight, and agent identity with least-privilege access as baseline requirements for autonomous systems, and these are not optional hardening reserved for regulated industries.

Agentic AI deployment is outpacing the governance structures meant to oversee it, and most organizations can't say what every agent or workflow in their own environment is doing. That gap turns per-session audit trails from a compliance checkbox into a basic operational requirement: a team that cannot answer what its agents did last week has lost visibility into its own infrastructure. Every tool call, diff, and thinking token needs to be logged and attributable to a specific person or trigger, and that logging serves real-time governance, not just post-hoc review. Blocked and paused states generate the highest-value audit events of any point in an agent's run, because they mark the moments when its behavior is most consequential and most likely to need human review before anything proceeds further.

Expressing agent configuration as YAML checked into a repository, reviewed and versioned like any other code, makes these policies enforceable. A per-agent config that specifies daily limits, per-task limits, alert thresholds, and an on_exceed: pause_and_alert action is reviewable, auditable, and reproducible in a way an ad-hoc dashboard setting never is. Ellipsis's own documentation describes an agent as one YAML file in a repository, deployed the same way any other code change is: committed, pushed, and live on merge.

What a platform must provide to handle blocked and paused states reliably in production

The gap between a demo and a production deployment is orchestration infrastructure, and everything argued above points to the same list of requirements. State storage needs to be durable and explicit, decoupled from conversation history, so if an agent pauses for days, it can resume without hallucinating steps it never completed. You need waiting to happen through event-driven dormancy rather than active polling, so a paused agent releases its compute and wakes only when the relevant event arrives. Sandboxes need to be session-isolated, with credentials minted fresh for each session and revoked the instant it ends, so a dormant agent never holds on to access rights it no longer needs. Budget enforcement needs to operate at the session, developer, and time-period level through the four-state policy of alert, throttle, pause, and block, so spending stays controllable before it becomes an organizational problem the way it did at Uber. Human-in-the-loop approval gates need to be designed into the orchestration layer itself, enforced structurally rather than left to the model's judgment, so consequential actions cannot proceed without explicit sign-off. Every tool call, diff, and token needs full observability, attributable to a person or trigger, so that paused and blocked states produce the audit trail governance and compliance actually require. And agent configuration needs to live as YAML checked into the repository, so budget limits, credential scope, and gate policies are version-controlled and reviewable the same way any other code change is.

Treating paused and blocked states as edge cases is a prototype mentality, and it misreads how production agents actually spend their time: dormant, waiting on a human gate or an external event, for the overwhelming majority of their operational life. That reality calls for infrastructure built around state persistence, credential scope, and cost control across idle periods of any length, not infrastructure that only optimizes for the happy path of continuous reasoning. Running Claude Code or Codex on a laptop is a reasonable way to prototype an idea. Running it on managed infrastructure that handles blocked and paused states with the same engineering discipline applied to the rest of the workflow makes an agent reliable across an entire engineering organization, beyond merely impressive in a controlled demo.