# Agent Harness Audit

## Operation

Inspect the named boundary and report supported findings. Do not edit product code. Include concrete evidence, impact, the owning source, one remediation direction and a meaningful validation route. Severity follows actual impact, not a category example.

## Goal and scope

Audit the run state machine of an agent harness across loops, parallel branches, persistence, tools, recovery, and replay.

## Domain invariants

- Every run, step, attempt, child, tool call, checkpoint, and terminal outcome has a stable identity and an explicit monotonic state transition.
- Loop continuation is bounded by declared success, failure, cancellation, iteration/time/token/cost budgets, and no-progress detection.
- Parallel branches have an explicit fan-out owner, bounded admission, deterministic join policy, failure policy, cancellation propagation, and orphan cleanup.
- Checkpoint and resume boundaries distinguish committed side effects from replayable computation; stale workers cannot commit after lease or version loss.
- Tool execution validates arguments at the boundary, records approval before protected side effects, and uses idempotency/deduplication where retries can repeat effects.
- Context and memory record provenance, scope, freshness, retention, redaction, and size limits; untrusted retrieved content cannot silently become instruction authority.
- Backlog, rate limits, downstream saturation, and cancellation produce bounded backpressure rather than unbounded task creation or retry storms.
- A run can be reconstructed from durable events and correlated traces without treating logs as the source of truth.

## Audit method

1. Trace one representative run from admission through loop decisions, child creation/join, tool effects, checkpointing, resume, and terminal publication.
2. Build the actual transition table, including duplicate delivery, crash windows, cancellation races, stale lease/version, partial join, and operator retry.
3. Inspect where concurrency is bounded and who owns child/task cancellation, result ordering, error aggregation, and cleanup.
4. Compare persisted state with emitted events/traces and identify states that cannot be replayed or explained deterministically.
5. Check approval and trust boundaries for tools, retrieved context, memory writes, and external side effects.

## Priority model

- **P0:** duplicate or unauthorized tool effects, lost run state, cross-run data exposure, runaway fan-out, or unrecoverable orchestration.
- **P1:** a material ownership, checkpoint, replay, cancellation, concurrency, or persistence defect.
- **P2:** a lower-risk but concrete observability, fairness, recovery, or maintainability issue.