The agent can run for months. What happens when its workflow history keeps growing?

The workflow history is an execution record, not a document database and not the model's context window. If we append entire retrieved pages, streaming tokens and every intermediate thought to it, replay cost grows with work that the workflow engine never needed for deterministic decisions. The model may also lose its context separately even while the workflow has a perfect event log. These are two different limits.

I would first measure event count, serialized bytes, replay time, pending commands and signal rate per run. Keep small durable facts in the workflow: current state, versioned decision references, pending operation IDs, timers, owners and the next step. Large source snapshots, tool payloads and model traces live in access-controlled external stores with immutable content or revision IDs. The workflow records pointers and digests sufficient to find the exact evidence later, subject to retention. That reduces history size, but it creates a new requirement: a pointer must not resolve to different bytes after replay. If the source can expire, decide whether the workflow must retain a permitted snapshot or can no longer safely resume that task.

For a Temporal-like engine, Continue-As-New starts a new execution with a fresh history while passing forward explicit state. Temporal's execution limits and Continue-As-New documentation make that a concrete mechanism. It is not a magic compression of unknown state. A stable business run ID should span the old and new executions, while each execution keeps its own ID. The rollover payload names unresolved operations, current policy and workflow version, source references, deadlines and waiting human actions. Do not copy every old message into it.

The pending provider operation is the hard part. It was submitted under one stable effect ID before rollover. The new execution reads the same operation ledger and reconciles it, instead of issuing another trade review action with a fresh identity. If the provider result is unknown, carry that uncertainty forward. A rollover cannot turn “sent, unknown” into “not sent.” If there is a child workflow or pending activity, follow the engine's actual parent close and activity semantics. Temporal's child workflow documentation notes that continuing the parent as new does not retain an ongoing child in the new execution. Own its identity and coordination explicitly rather than assuming it moved.

Human approval has a similar edge. The old approval link must resolve to one durable proposal and action fingerprint, regardless of execution rollover. The new worker checks that it has not expired, that the approver still has authority, and that the proposed effect is unchanged. Do not let a new workflow ID make an old approval appear like a new request or silently apply it to changed state. How do you deploy new agent workflow code while 200,000 runs are waiting? covers workflow code upgrades while runs wait. This question is about the accumulating history and the exact state transfer after a long life.

There is no need to roll over on a fixed number without considering size and rate. Trigger before the engine warning threshold with headroom for pending updates and retries. Test a rollover with a delayed provider receipt, a human click on the old link, duplicate source signal, source deletion, and worker crash between recording the new execution and closing the old one. The stable ledger and idempotent transition must make that crash recoverable. Measure replay time, history growth and duplicate effects after rollover, not just whether the new execution started.