Long-horizon agents and durable execution

The running example

Our running example is Stock Replenisher, the stock-ordering agent from above, which keeps a manufacturer's parts in stock. When a part falls below its safety stock, the agent attempts to replenish it. It gets quotes, chooses a supplier, asks the procurement manager to approve the price, places the order, and follows it until the goods arrive.

This can take days or weeks in elapsed time. Most of it involves waiting for the manager's approval, the supplier's response, and the delivery of goods. Meanwhile, things change: the supplier may raise the price after the order is placed, ask a question, or not answer at all. The agent has to handle each case as it arises.

Here is one replenishment as it ran, from the shortage to the goods arriving. The long stretches are waits; the agent's steps are the short bursts in between. Click a mark to see what happened, or use the arrows at the top right to step through the run.

The agentic loop

Most agents, from coding agents such as Claude Code to personal assistants such as OpenClaw, are built around the same loop, usually called the agentic loop. It has four parts:

• a goal: the outcome we want the agent to achieve. For a coding agent, this might be a program to write; for Stock Replenisher, a part kept in stock.
• tools through which the agent acts in the world. Think of read_file, edit_file, and bash for a coding agent; get_quotes and place_order for Stock Replenisher.
• state: everything the agent knows about its progress toward the goal so far.
• a model that, at each turn, looks at the current state and chooses which tool to use next, and what to pass it.

At each turn, the model chooses a tool, and the code around it runs the tool and updates the state with the result. That code is often called the harness; Claude Code, for example, is a harness around Claude. The loop ends when the agent reaches the goal or gives up. When the agent needs input from a person or an external source, it asks and waits for an answer.

Figure 1: Two turns of the loop: one calls a tool, one waits

Here is Stock Replenisher's loop in code. (All code examples are in Python.)

GOAL = ("Bring stock back above safety stock: order from a suitable "
        "supplier, get every price approved by the manager before money "
        "is committed, and see the order through to delivery.")
MAX_TURNS = 30

TOOLS = [
    GetQuotes(), DraftPurchaseOrder(), RequestApproval(),
    WaitForApproval(), PlaceOrder(), WaitForSupplierReply(),
    ReadSupplierReply(), WaitForGoods(), ClosePurchaseOrder(), Done(),
    ...
]

class Replenish:
    async def run(self, stock: StockLevel) -> ReplenishmentResult:
        state = State(stock.sku, stock.on_hand, stock.safety_stock)
        for turn in range(MAX_TURNS):
            allowed_tools = [t for t in TOOLS if t.allowed(state)]
            tool = await self.decider.decide(GOAL, state, allowed_tools)
            if isinstance(tool, Done):
                break
            if isinstance(tool, Wait):
                try:
                    payload = await asyncio.wait_for(
                        self.inbox[tool.event].get(),
                        timeout=timedelta(days=tool.days).total_seconds())
                    tool.apply(state, payload)
                except TimeoutError:
                    tool.apply(state, None)
            else:
                result = await tool.execute(state, self.context)
                tool.apply(state, result)
        return outcome(state)

decider.decide is the call to the model (in our case, a classification model Jev); it picks the tool to run in the current turn based on the GOAL, the current state of the replenishment run (state), and a prefiltered list of allowed tools allowed_tools. The loop ends when the model selects Done or after MAX_TURNS. The outcome shows how the replenishment concluded: received, cancelled, rejected by the manager, or given up.

Each tool has a name and description, which the model uses to make its selection. The allowed method states whether the tool can be used given the replenishment's current state. This way the business rules that matter are in code, not in the prompt. For instance, the place_order tool isn't available until the manager approves the price on the table. The execute method runs the tool, e.g., makes API calls, writes an email, etc., and apply updates state based on the result of execute.

class PlaceOrder(Call):
    name = "place_order"
    description = "Send the approved purchase order to the supplier."

    def allowed(self, state):
        return (state.po is not None and state.order is None
                and state.approved_up_to is not None
                and state.price <= state.approved_up_to)

    async def execute(self, state, context):
        return await context.supplier.place_order(state.po)

    def apply(self, state, ack):
        state.order = ack

state holds everything the agent knows about one replenishment: the quotes, purchase order, approved price range, and order. Only the apply method updates it based on the result of each turn.

@dataclass
class State:
    sku: str
    on_hand: int
    safety_stock: int
    quotes: list[Quote] | None = None
    po: PurchaseOrder | None = None
    price: float | None = None
    approved_up_to: float | None = None
    order: OrderAck | None = None
    goods: GoodsReceipt | None = None
    ...

Wait is also a tool that waits for a message, such as the manager's decision, or until its time runs out. This loop works as long as the process running it stays up, but a lot can go wrong during long wait times. And the agent needs to recover and continue its task.

What can go wrong

It helps to think of a long-horizon agent as a distributed system. Many of the failure modes we are familiar with in distributed systems happen here too: calls to other systems fail, processes crash while the agent waits, and so on.

The first four failures are the same in any domain. A durable execution runtime handles them with general-purpose primitives so that the harness can focus on domain-specific logic. Without the runtime, you would have to write a lot of glue code to handle the failures yourself: record what has been done, retry, set timers, and pick up where you left off.

But treating the agent as just another distributed system misses something. What makes it a different beast is the model at its heart, which can decide how to recover from failures and keep the task going. When a failure occurs, the harness's job is to provide the model with the right input so it can decide what to do next.

The next sections look at durable execution in detail. After that, we return to the failures the harness must handle explicitly.

Making the loop durable

Here is the agentic loop from earlier, written with Temporal's primitives. The highlighted lines are the ones that change.2

replenish/workflow.py

  from temporalio import workflow
  
  @workflow.defn
  class Replenish:
      @workflow.run
      async def run(self, stock: StockLevel) -> ReplenishmentResult:
          state = State(stock.sku, stock.on_hand, stock.safety_stock)
          for turn in range(MAX_TURNS):
              allowed_tools = [t for t in TOOLS if t.allowed(state)]
              tool = await workflow.execute_activity(
                  Decider.decide, args=[GOAL, state, allowed_tools],
                  activity_id=f"decide-{turn}", ...)
              if isinstance(tool, Done):
                  break
              if isinstance(tool, Wait):
                  try:
                      await workflow.wait_condition(
                          lambda: self.inbox[tool.event],
                          timeout=timedelta(days=tool.days))
                      tool.apply(state, self.inbox[tool.event].pop(0))
                  except TimeoutError:
                      tool.apply(state, None)
              else:
                  result = await workflow.execute_activity(
                      run_tool, args=[tool, state],
                      activity_id=f"{tool.name}-{turn}", ...)
                  tool.apply(state, result)
          return outcome(state)

The key thing to notice is that the whole agentic loop, the run method, is annotated with @workflow.run. That makes it a workflow, Temporal's name for a durable program: after a failure, Temporal runs it again and rebuilds its state from the log.

Every step that interacts with the outside world goes through a second primitive, workflow.execute_activity, so that Temporal records the step's input and output in the log, under the name activity_id gives it. Temporal calls such a step an activity. Two calls in the loop are activities: the model's choice of the next tool (Decider.decide), and the tool itself (get_quotes, place_order, close_purchase_order and the others, through run_tool).

A third primitive, workflow.wait_condition, suspends the workflow until a condition holds (here, until a message arrives in the inbox) or the timeout passes. The wait is recorded too, so the process doesn't have to stay up while it waits.

Everything else is the same: allowed and apply. That's the code around the decision, and it runs again on every replay.3

Here is one replenishment as Temporal recorded it. The agent got quotes, drafted a purchase order, and asked the manager to approve it. While it waited, the process crashed and stayed down for a day, as shown by the pink band below. When the process came back, nothing before the band ran again: no new quotes, no second purchase order, no second request to the manager. When the approval arrived, the agent placed the order.

The entity and the workflow

We've seen the durable agentic loop. The next question is where that loop lives and how it maps to the business domain.

Take stock replenishment: there are two loops at play. One handles replenishment for a single SKU and follows the work through until the goods are received. The other is the SKU-level loop. It checks stock against the replenishment policy and triggers replenishment when needed, one at a time. It is also the SKU's point of contact: messages from the manager, the suppliers, and the warehouse come to it. The SKU will be replenished many times over its life.

Figure 5: One agent per SKU; one workflow at a time

This is the distinction between a process workflow and an entity workflow.

A process workflow is a durable workflow that carries out one piece of work (e.g., a replenishment) and then finishes.

An entity workflow is a durable workflow that represents one business entity (e.g., a SKU) for the lifetime of that entity. It maintains the entity's state and initiates process workflows.

In a subscription business, customers fit the same pattern. The customer's entity workflow maintains the customer context and initiates the appropriate process workflows (onboarding, renewal, support, etc.). Each of those process workflows completes, but the customer entity workflow continues.

The entity workflow's first job is to watch the stock and trigger replenishments.

the entity workflow: one per SKU

  @workflow.defn
  class SkuAgent:
      @workflow.run
      async def run(self, sku: str, outcomes: list[ReplenishmentResult]):
          stock = await workflow.execute_activity(get_stock, sku, ...)
          if stock.on_hand < stock.safety_stock:
              self.active = f"replenish-{sku}-{len(outcomes) + 1}"
              try:
                  result = await workflow.execute_child_workflow(
                      Replenish.run, stock, id=self.active)
              except ChildWorkflowError as e:
                  result = ReplenishmentResult(sku, "failed", str(e.cause))
              outcomes.append(result)
              self.active = None
          else:
              await workflow.sleep(CHECK_EVERY)
          workflow.continue_as_new(args=[sku, outcomes])

Each run of the entity workflow checks the stock once. If the SKU is below safety stock, it starts a replenishment and waits for it to finish; otherwise it sleeps until the next check. Then continue_as_new starts a fresh run with the same ID and an empty history, which receives only what it is given, here the SKU and the outcomes so far.

The entity workflow's second job is to receive messages for the SKU from the outside world. It has a stable, unique ID, agent-SKU-123, for the SKU's life. Each request the agent sends out, such as an approval request or a purchase order, carries the SKU or the purchase order number so that the answer can be sent back to agent-SKU-123. The manager approving or the supplier replying doesn't need to know which replenishment is running; the entity passes the message on to the current one.

the manager's approval, sent to SKU-123

  await client.get_workflow_handle("agent-SKU-123").signal(
      "deliver", args=["approval", {"approved": True}])

the entity's address: messages from outside

  class SkuAgent:
      ...
      @workflow.signal
      async def deliver(self, event: str, payload: dict):
          if self.active:
              await workflow.get_external_workflow_handle(self.active).signal(
                  Replenish.deliver, args=[event, payload])

the replenishment's inbox: messages from the entity

  @workflow.defn
  class Replenish:
      @workflow.run
      async def run(self, stock: StockLevel) -> ReplenishmentResult:
          state = State(stock.sku, stock.on_hand, stock.safety_stock)
          for turn in range(MAX_TURNS):
              ...
          return outcome(state)
  
      @workflow.signal
      def deliver(self, event: str, payload: dict):
          self.inbox[event].append(payload)

Every message for SKU-123 goes through SKU-123's entity workflow to the running replenishment, which applies them one at a time.

In the code, Stock Replenisher is now two classes: SkuAgent, the entity workflow, and Replenish, the process workflow that runs the loop from earlier.

That brings us to the waiting.

Waiting for people and systems

As we've seen so far, long-horizon agents spend much of their time waiting for humans or external systems. The durable execution runtime provides primitives for waiting efficiently. While these agents wait, the runtime ensures they don't hold a process in memory or use compute.

This matters because, with the entity-workflow pattern we saw earlier, every SKU will have its own workflow, and that workflow will run as long as the SKU is stocked. A manufacturer with thousands of parts will have thousands of agents. At any given time, almost all of them will be idle or waiting. If a wait holds a process or memory, then the cost increases in proportion to the number of SKUs and the length of the waits, not in proportion to the work actually done.

workflow.wait_condition suspends the workflow until a message of the right type is in the inbox, or the timeout expires. The wait's timer is also logged, and so is the message that ends it. So a wait survives a crash just as a step does.

Figure 6: The wait's timer and the message both go into the log

Waking up has a cost too. Rebuilding a workflow means replaying the log, and that cost grows with the log's length. If wake-up is slow or expensive, then having thousands of agents waiting is just as infeasible as keeping thousands of processes open for weeks. In our runs, waking a workflow took under three seconds and tens of milliseconds of CPU.4

If replay gets too slow, the next thing to try is a snapshot, so only the log after it has to be replayed. This matters most for the entity, whose log would keep growing as long as the SKU is stocked. On Temporal, continue_as_new has the same effect: it carries the entity's state into a fresh run with an empty history. On Cloudflare, the entity is a Durable Object, which reads its current state from storage and has no log to replay. A replenishment workflow doesn't need a snapshot. Its log stays short because the run ends.

A wait ends in one of two ways: a message arrives, or the timeout expires. If the supplier hasn't got back to us within seven days, then wait_for_supplier_reply will mark the order as overdue:

class WaitForSupplierReply(Wait):
    event, days = "supplier-reply", 7
    ...
    def apply(self, state, payload):
        if payload is None:
            state.supplier_overdue = True
        else:
            state.supplier_reply = SupplierReply(**payload).message

class ChaseSupplier(Call):
    ...
    def allowed(self, state):
        return (state.supplier_overdue and state.chases < MAX_CHASES
                and is_open(state))

That means chase_supplier is allowed, and the model will see it as an option on its next turn.

In this run, the supplier goes quiet after the order is placed. Look for the wait that ends with a timeout seven days later, then the chase that follows it, and the reply a day after the chase.

Retrying failed calls, at least once

Calls to external systems can fail because of network issues or because the receiving system is down. Durable execution runtimes provide primitives to retry failed calls with configurable retry policies, so they don't overload the receiving system.

RETRY = RetryPolicy(maximum_attempts=6,
                    initial_interval=timedelta(seconds=2),
                    backoff_coefficient=2)

@workflow.run
async def run(self, stock: StockLevel) -> ReplenishmentResult:
    ...
    result = await workflow.execute_activity(
        run_tool, args=[tool, state],
        activity_id=f"{tool.name}-{turn}", retry_policy=RETRY)
    ...

What the runtime can't do is make a retry safe. If the supplier takes the order and the response is lost, no result is recorded, so the runtime calls the supplier again. This is known as at-least-once semantics, as opposed to exactly-once. This could result in duplicate orders if not handled properly.

To get the effect of exactly once for a write, the receiver must recognise repeats using an idempotency key, which the harness must keep the same on every attempt and replay.

In the place_order tool, the PO number becomes the idempotency key.

class PlaceOrder(Call):
    ...
    async def execute(self, state, context):
        ...
        key = state.po.po_number
        ack = await context.supplier.place_order(po, idempotency_key=key)
        return PlaceOrderResult(placed=True, price=price, ack=ack)

In the run below, the supplier's system is down on the first attempt. The runtime retries with the same PO number as its idempotency key. Look for the two attempts on place_order and the single order at the supplier.

As a recap, here are the primitives used so far, on both platforms:

With these, the loop survives crashes, waits without holding a process, and retries failed calls. Idempotency is the first thing the harness has to handle explicitly, and there are a few other failure modes like it. We'll see them in the next section.

Outcomes the agent doesn't see

We saw earlier how an agent recovers from failed calls using retries and an idempotency key. This only addresses part of the problem. The call that the agent deemed a failure might still have done its work: the supplier may have taken the order and lost only the response. The agent can't tell the difference, so it turns “we don't know” into “it failed” and proceeds as if no order existed.

This is a common problem long-horizon agents need to tackle. One strategy is to make mitigating actions available for these agents. For example, the cancel_order tool can mitigate accidental duplicate orders.

class CancelOrder(Call):
    name = "cancel_order"
    description = ("Cancel an order with its supplier and tell them why, "
                   "for example a duplicate placed by an earlier run.")
    po_number = None  # the model's choice, from a list the harness builds

    async def execute(self, state, context):
        po = self.po_number
        # a generation model (here Claude) writes the email
        text = await context.writer.write_cancellation(po, state)
        sent = await context.supplier.send_message(
            po, text, idempotency_key=context.key)
        await context.supplier.cancel_order(po, idempotency_key=context.key)
        return Cancellation(po, sent)

    def apply(self, state, result):
        ...

In the run below, supplier A takes the order and then becomes unreachable. Subsequent retries also fail because supplier A's system is down. The place_order step fails after six attempts. Still short on stock, the agent starts another replenishment and orders from supplier C. Later, supplier A confirms the first order via an email.

The agent spots the mistake by checking the PO number. If it's not too late, it then uses cancel_order to cancel the earlier order with supplier A, providing an explanation for the cancellation.

The agent found the duplicate only because supplier A wrote. A persistent log records what the agent saw, not what actually happened. The decision to reorder with supplier C was wrong from the moment it was made; the agent just had incomplete information. The next section is about decisions that were correct when made, but whose inputs went stale as the agent sat around waiting.

The world moves on while you wait

A long-horizon agent decides at one time and acts at another, often days later. In the meantime, things change in the real world, and the facts behind the decision go stale. For instance, the manager approves a price from a quote that may be three days old, but the price might have gone up by the time the agent is ready to order.

A useful long-horizon agent needs to handle such cases autonomously over time. Three patterns help achieve this.

• Give a decision an expiry date. An approval is valid until a certain date; after that, the agent must decide again. Quotes will often state a validity period; an approval can too.
• Re-check before committing. Before taking any action that is hard to undo, such as placing an order, re-read the facts on which the decision is based. If those facts have changed, then don't act; decide again.
• Approve a range, not a value. Build some variance into the decision. For example, the manager approves a price range instead of a specific price. The agent can then act anywhere in that range without having to ask again.

Stock Replenisher asks the manager to approve the price and up to 5% above that. The place_order tool then fetches the quote again and checks against that ceiling. If the price is within the ceiling, it orders at that price; if it's above the ceiling, it doesn't order, and the agent goes back to the manager for re-approval. Note that this check is in the tool; it's a deterministic check that runs regardless of what the model decides.

class PlaceOrder(Call):
    ...
    async def execute(self, state, context):
        quotes = await context.supplier.get_quotes(state.sku)
        price = ...  # this supplier's price today, from quotes
        if price > state.approved_up_to:  # above the range: don't order
            return PlaceOrderResult(placed=False, price=price)
        ...  # within the range: order at today's price

In the run below, the manager approves $4.20, up to $4.41. The agent orders at $4.20. The supplier then confirms at $4.35, within the range, so the agent lets the order stand and waits for the goods. A confirmation at $4.54 would have gone back to the manager.

Code change under a running task

We saw a few challenges that arise from unanticipated real-world changes the agent is expected to adapt to. The harness code itself will change and evolve. Deploying changes to the harness affects the suspended agents that assume a certain version of the harness. This is an accidental complexity of using durable execution itself.

Two kinds of harness changes to consider:

1. Business rule changes: e.g., the agent is allowed to draft an order only after n minimum quotes. That n went up from 0 to 4 while some agents were waiting for a manager's approval.
2. Schema changes: renaming of classes and attributes related to state recorded in the log. For example, renaming a step, a workflow or a field of the state in Stock Replenisher.

The general idea behind the mitigation is to treat the log as a published interface, and any code that replays from the log needs to run multiple code versions in parallel and, at runtime, choose the version that applies to a given log.

This is known as Parallel Change. This strategy makes a backwards-incompatible change possible in three steps. First, add the new rule next to the old one; then migrate as new workflows start under the new rule while running ones finish under the old one; finally, remove the old rule once no workflow still uses it.

In Stock Replenisher, while SKU-123 waits for the manager to approve PO 4471, which the agent drafted after getting three quotes, we deploy the rule that allows a draft only after four quotes. A change like this plays out differently on each runtime. On Temporal, SKU-123 silently continued with the order as per the old rule, which the new rule doesn’t permit. On Cloudflare, where our loop checks each recorded decision against the current rules, it failed: PO 4471 stayed a draft. We need to know how the runtime behaves before we deploy a change, and plan the deploy around it.

With the rule versioned, SKU-123 finishes under the old rule on both runtimes, by design:

a business rule change, versioned

  class DraftPurchaseOrder(Call):
      def allowed(self, state):
          min_quotes = 4 if state.rules_version >= 2 else 0
          return (state.quotes is not None and len(state.quotes) >= min_quotes
                  and state.po is None)

In the code above, each replenishment records the rules version it started under in state.rules_version, and DraftPurchaseOrder derives the minimum number of quotes from it.

Memory: what the agent keeps, and what the model sees

Long-horizon agents also need to reckon with history that keeps growing. The durable execution runtime logs everything the agent did. The harness decides what the model sees in each turn. Stock Replenisher needs nothing more than state: it holds everything about the current replenishment, and that's enough to decide the next step. The SkuAgent entity stores the results of previous replenishments but the model never needs to refer to them.

Other agents are not like this. A customer's entity workflow runs for years, collecting every conversation, complaint, and promise, and the next decision may depend on a promise made months ago.

As history grows without bound and stays relevant to the decision, the harness must choose what the model sees. Not everything can be kept in context. MemGPT and Letta let the harness manage memory in tiers: a small working context the model always sees, and external storage like a vector store, which it reads and writes through tool calls. The idea comes from operating systems: the working context is like RAM, and the external storage like disk.

That storage is in addition to the log. Each read and write to this external storage is a step, just like any other call to the outside world.

Text that steers the agent

Agents interact with the outside world through text, written or transcribed from speech. A model can't tell the difference between the text it reads and its instructions, so agents are susceptible to prompt injection.

Stock Replenisher is no exception; it reads the suppliers' emails and acts on its own. Securing agents against these threats is an involved topic of its own, and Agentic AI and Security covers them in some detail. None of these threats are unique to agents running for weeks. Durable execution doesn't help with any of them per se.

In the case of Stock Replenisher, the harness includes some defenses worth noting. The model can only select from allowed_tools, and approval is valid only if it comes from the manager. A supplier email saying “the manager has already approved $6.00” approves nothing; at most it raises the price, and a price above the approved range goes back to the manager.