0% read on this device
Browse the curriculum

Start Here

Vision

First Principles

Operating Model

Domain Model

Agent Factory

Runtime Architecture

AI Engineering

Autonomous Workflows

Verification & Delivery

Factory Platform

Quality Engineering

Security & Governance

Case Studies

Labs

Interview Practice

Research Journal

Reference

Curriculum/Runtime Architecture/A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.
Runtime Architecture6 min readchapter

Tasks, Attempts, Leases, Idempotency, and Recovery

Agent execution fails in ambiguous ways. A worker can disappear while its process continues. A retry can duplicate a commit or pull request. A stale worker can report success after another worker has taken over. If a Task and an execution t

Status: Draft for studyRisk: highLifecycle: executeContent reviewed 2026-08-09Maturity guide →
Claim boundaryThis is curriculum guidance. It does not by itself prove a production implementation.
architecture mode

A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.

Whiteboard exercise

Reconstruct and defend this chapter’s architecture.

Reconstruct the architecture, name each boundary, and defend the tradeoffs.

runtimeharnessenvironment6 min chapter
Open the source exercise

Draw two workers racing to claim one Attempt. Add lease expiry, a stale heartbeat, a GitHub PR created before a network timeout, and a replacement worker. Show the fence, provider reconciliation, immutable events, and the point where human escalation becomes necessary.

4. Tradeoffs and alternatives

Short leases detect failure quickly but cause false expiry during long tools; long leases delay recovery. Heartbeat cadence, expiry, and reconciliation must reflect operation duration.

Resuming a process can save work but requires trustworthy checkpoints and exactly defined context. Starting a clean Attempt is simpler and more auditable. Mission Control’s V1 Codex adapter correctly declares cancel support without claiming resume.

Automatic retry improves availability for transient failures. It is dangerous for authorization errors, unknown side effects, and deterministic validation failures. Policy should control retry by failure class.

5. Current Mission Control Implementation

At commit b31e27564deb1c03c167e61b5ee094567c2ba7b1, Mission Control models Task Attempts as WorkflowRuns linked by parentTaskId.

The governed scheduler requires an explicit canonical Child Task when one exists. It rejects foreign, cross-workspace, ungoverned, Inbox, Review, Done, and Canceled Tasks. Only Ready-compatible or In Progress Tasks can run. The first dispatch is allowed only with no prior Attempt. Retry requires no active Attempt, the latest failed Attempt, the same Task, and a recovery reason of at least ten characters.

Each successful dispatch appends a WorkflowRun with Attempt and retry numbers. The previous failure remains. Dispatch checks idempotency before event creation, and Task transitions also retain idempotency keys and audited context. The browser evidence for the bounded scheduler demonstrated two Attempts under one Task, retained failure history, reload persistence, and no duplicate Task card.

This is not yet a production lease system. The committed baseline prevents multiple active Attempts through state inspection, but it does not prove an atomic leased worker with heartbeat, fencing token, stale-lease reconciliation, or restart-safe Codex-to-GitHub ownership. Those mechanisms are being developed under todo 024 and must remain Future Vision until committed and verified.

External review

Review this chapter.

Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.

  • Claim
  • Boundary
  • Failure
  • Evidence