Agent work should have a lifecycle. ARF enforces one: the agent proposes a plan, you review and approve it, the agent executes under governance, completed work is sealed with a cryptographic proof. If anything fails governance checks, the Agent Remediation Framework handles recovery not the agent doing whatever it wants.
Agent analyzes the task and produces a work plan: what it intends to do, which files it'll touch, which tools it'll use.
You see the plan. ARF shows a structured view of what the agent intends. You can approve, modify, or redirect before a single tool call runs.
Approval is a signed event in the proof chain. Your identity, timestamp, and the exact plan you approved are all recorded.
The agent executes under full governance: every tool call evaluated against policy, circuit breakers armed, TUI showing live progress.
Completed work is sealed: the proof chain is closed, a compliance bundle is generated, and git notes are annotated. The work is immutably attributed.
Before executing any substantial work, ARF's planning gate pauses the session and presents the agent's proposed work plan. This is not the agent's internal reasoning it's a structured representation of intended actions: files to read, files to write, commands to run, APIs to call.
The planning gate is configurable per profile. In Strict mode, every session starts with mandatory planning. In Standard mode, planning is triggered by the agent itself (a governance best practice) or by the complexity of the first request. In Minimal mode, planning is available but not required.
You can redirect at the planning stage annotate the plan, tell the agent to take a different approach, or reject the plan and provide a corrected direction. The redirect is recorded as a governance event; the agent replans.
PLAN REVIEW IRON-WOLF-1 · session 01HX…AB12 Task: Refactor the payment processor to use async/await instead of callback hell. Proposed actions: 1. read_file src/payments/processor.js 2. read_file src/payments/types.ts 3. read_file tests/payments.test.js 4. write_file src/payments/processor.js ! approval req 5. write_file tests/payments.test.js ! approval req 6. bash npm test ! approval req Est. tokens: ~8,000 Est. cost: ~$0.12 Files modified: 2 Risk: low ────────────────────────────────────────────── [y] Approve plan [n] Reject [e] Edit [?] Detail
When a session completes, ARF seals it. Sealing closes the hash chain, computes the Merkle root (for multi-branch sessions), generates the compliance bundle, writes git notes to any commits made during the session, and marks the session as immutable in the local store.
Sealed sessions cannot be modified. The seal itself is a signed record in the chain: it includes the final hash, the seal timestamp, the approver identity (if manual), and a summary of the work performed.
Sessions can be sealed automatically on completion, or manually by pressing ctrl+s in the TUI or running arf provenance export --session [id]. Unhandled failures -- crashes, forced kills -- produce an emergency export with a failure record.
ARF supports structured multi-agent review workflows. One agent produces work; other agents review, validate, and archive it. Each role has different tool permissions, different policy constraints, and contributes to the same proof chain.
Full read/write access to the worktree. Can execute tests. Primary tool budget consumer. Subject to planning gate and approval requirements.
Read-only access. Runs tests against the producer's output. Issues structured review reports. Can approve or block the producer's work proceeding to archive.
Read-only access. Summarizes the session, writes documentation, appends final notes to git. Issues the seal command. Owns the compliance bundle output.
High-level review role. Reads diffs, reviews architecture decisions, can veto entire work sessions before they're merged. Operates from the ARF TUI or a separate review session.