Subscribe for more posts like this →

Deep-dive 7 — Long-Horizon Agents as Long-Running Workflows

Stackshala

Stackshala

— 3 min read
Share

Consequence from the field guide: constrain the executor's action space hard — few, well-scoped, ideally reversible or dry-runnable tools. Draft-commit the irreversible ones. Set hard budgets. Checkpoint. You are trading the agent's freedom for your ability to recover.

How it's done

A multi-step agent is a long-running distributed workflow, and the orchestration playbook transfers with almost no translation:

  • Plan-then-execute — separate a planner/orchestrator (the deterministic-ish backbone) from executors/workers (the intelligence at the leaves). The winning 2026 shape is a deterministic backbone with LLM intelligence at specific steps, not a monolithic loop where one model does everything.
  • Checkpointing — persist intermediate state so a crash or restart doesn't discard hours of accumulated work.
  • Compensating actions — on a failed step, replan (compensate forward) rather than restart from zero. A failed executor escalates to the planner for a revised sub-plan.
  • Idempotency — retries + side-effecting tools + a non-deterministic actor means duplicate-action risk; use idempotency keys and dedup exactly as in at-least-once messaging.
  • Deadline & budget propagation — give the loop a wall-clock deadline and a token/cost budget, propagated into sub-tasks, so a confused agent can't burn unbounded money and time.

Tools available

  • LangGraph 2.0 — the 2026 release codifying production orchestration: type-safe streaming, durable state, and unified primitives (Router, Supervisor, Subagent) so you don't hand-roll them.
  • Temporal — durable execution / workflow engine, battle-tested for long-running, crash-resilient workflows; the most direct import of classical durable-execution guarantees.
  • Prefect / Airflow — deterministic pipeline orchestration for the non-agentic backbone.
  • Agent SDKs: OpenAI Agents SDK, CrewAI, Pydantic AI, Google ADK — most now emit OpenTelemetry spans (see Deep-dive 9).

The key mental import is durable execution: treat the agent run like a workflow that must survive process death.

Best practices

Deterministic backbone, intelligence at the steps. Constrain the executor's tools to a small set that is ideally reversible or dry-runnable; draft-commit anything irreversible. Set hard budgets and deadlines and propagate them (your deadline4j instinct applied to a loop that otherwise runs forever). Checkpoint so a restart resumes rather than repeats. Make every side-effecting tool idempotent. Design replanning triggers so a failed step is a compensation event, not a terminal one. Decompose into supervisor/subagent structure when it genuinely aids observability — but see the over-use warning below and Deep-dive 8.

Failure points teams ignore — and what each costs

  • Unbounded loops. No deadline, no budget. Consequence: the canonical incident — an agent stuck in a loop silently burning tokens and dollars until someone notices the bill. This is the single most common production surprise.
  • Non-idempotent side effects under retry. Consequence: the agent sends the email twice, files the ticket twice, or charges the card twice — the exactly-once fiction, rediscovered painfully.
  • No checkpointing. Consequence: a crash forty minutes into a task discards all accumulated state and cost; the run restarts from zero.
  • Open-ended action set, no compensators. The planner invents actions at runtime for which no compensating action exists. Consequence: partial failures become unrecoverable — the agent leaves the world in a half-done, inconsistent state.
  • Monolithic single-agent loop. All reasoning, routing, and execution in one model call sequence. Consequence: brittle and nearly unobservable — you can't see or fix where it went wrong.
  • Planner / reasoning drift. Over a long horizon the agent loses the thread of the goal. Consequence: it confidently completes the wrong task.

How to evaluate and mitigate

Evaluate: task-completion rate on multi-step scenarios drawn from your real workflows (the AppWorld / OfficeBench style of long-horizon benchmark, but on your tasks). Cost and latency distribution including the tail — the tail is where runaway loops live, so alert on it. Recovery rate after deliberately injected step-failures. Duplicate-action rate under forced retries.

Mitigate: plan-then-execute; hard budgets and deadlines with runaway alerts; idempotency keys and dedup on side effects; checkpoints; a constrained, reversible tool surface plus draft-commit for the irreversible; explicit replanning triggers; supervisor/subagent decomposition where it buys observability.

Practical vs. still research

Practical / mature — and mostly your existing discipline: plan-then-execute, durable execution (Temporal, LangGraph), budgets and deadlines, checkpointing, and idempotency are imported nearly wholesale from distributed systems. This is the deep-dive where your background pays off most directly.

Practical but over-used: multi-agent supervisor/subagent architectures work but carry real coordination overhead; reach for them for observability and decomposition, not because "multi-agent" sounds advanced.

Still research: robust automatic compensation over an open-ended action set, and reliable planning over genuinely long horizons (hours) — agents still drift, and the longer the horizon, the worse reliability gets. Bound the horizon, checkpoint often, and keep a human able to intervene on the irreversible.

Read more