P11 — Loop Agent as Repeated Runs

Problem

Long-lived processes accumulate stale state, are hard to recover, and make ownership ambiguous.

Context

An agent needs to continue a multi-step objective across time or triggers. The loop definition belongs to a caller-owned Workstream or orchestrator; each execution may use a new disposable Task Workspace.

Pattern

Represent the loop as repeated bounded Runs. The external owner supplies each Task’s goal and constraints; each Run performs one safe slice in a Task Workspace and returns a result/lineage record. The owner writes the next semantic checkpoint to its Workstream state.

Diagram

Workstream loop definition
          ↓
checkpoint → Task 1 / Run 1 → checkpoint → Task 2 / Run 2 → …

Example

An upgrade loop records packages inspected, blockers, and next action in its external Workstream state. A later orchestrator invocation supplies the next Task to ws, which executes it in a fresh Task Workspace and managed-repository worktree.

Trade-offs

Recovery and cleanup are easier, and deleting a Task Workspace does not delete the loop’s intent or history. Checkpoints need a schema and can become stale or overly detailed.

Failure modes

The next Run cannot tell completed from pending work, or a checkpoint is treated as canonical truth without validation.

Extension points

Use Git files, SQLite, a queue, or a workflow engine for checkpoints. These are caller/orchestrator choices, not required ws features.

When not to use

Short, deterministic tasks should remain one Run.