Find the controls your agent is missing before production finds them.
Run /harness-audit from your agent repository. The audit traces critical paths through code, configuration, tests, and available runtime evidence. It returns a scoped launch decision, explicit unknowns, and a fix queue.
$ /harness-audit ./agents/refund --traces ./logs/runs
scanning repo...
found LangGraph workflow, tool registry, policy bundle
mapping the candidate release and reachable effects
checking the authorization and recovery paths
result: BLOCKED for live refunds
runtime observation: not verified
next fix: validate tool args before dispatchUnauthorized dispatch, duplicate-write risk, and unverified runtime behavior block live refunds in this example.
Each finding identifies its supporting artifact and the remaining evidence gap.
Fix the most load-bearing runtime gap first, then rerun the audit.
Trace controls to the effects they protect.
The eight properties below are an orientation map. The current method assesses the evaluated release, applicable capabilities, lifecycle scenarios, and bypass paths. It does not average control coverage into a readiness score.
Context-aware
Compiled context matches intent; irrelevant memory, tools, and evidence are trimmed instead of hidden in prose.
Policy-governed
Policy runs outside model code at compile, plan, and tool-execution boundaries.
Tool-controlled
Only declared capabilities are callable; schemas, native action risk, compatibility mode ceilings, and sandbox profiles are enforced.
Validated
Completion is gated by evaluators, rubrics, and critic verdicts that are versioned like code.
Observable
Runs emit trace IDs, tool envelopes, evidence refs, and scorecard events that can be joined later.
Reversible
Risky writes have idempotency, replay bundles, rollback paths, and compensation records where applicable.
Measurable
Metrics attach to intents, tenants, pack versions, and business outcomes instead of vague agent quality.
Continuously improving
Failures become typed proposals that pass replay, review, and release gates before promotion.
A production audit has to inspect the runtime, not the story around it.
Architecture diagrams and checklists are useful, but they cannot prove that a tool call is validated before execution or that a failed write can be replayed. The audit treats the repository as implementation evidence and tests deployed behavior where authorized evidence is available.
Trace the enforcement path
A control must protect the reachable effect; a bypass invalidates the claim even when the control exists.
Effectiveness, evidence, and confidence
Keep these judgments separate. A defined control can still be untested or bypassed.
Built for iteration
The fix queue is dependency ordered so teams can make one high-leverage change and rerun quickly.
Install once. Run it from any agent repo.
Use the Claude Code command when you want a launch gate, a quarterly harness review, or a focused check after changing tools, policy, memory, or replay.
Install once
Register the ContextOS skills marketplace in Claude Code and install the audit command.
Run from the repo
Point the audit at your agent root, or at a subpath plus traces for the workflow under review.
Fix the P0s
Work the dependency-ordered fix queue, commit evidence, and rerun until blockers clear.
# in Claude Code
/plugin marketplace add contextosai/skills
/plugin install harness-audit@contextosai-skills# from the root of your agent repository
/harness-audit
# or scope the review to one workflow plus traces
/harness-audit ./agents/refund --traces ./logs/runsManual install also works: clone github.com/contextosai/skills and copy skills/harness-audit into your .claude/skills/ directory.
An assurance report with a focused closure plan.
The report is meant to be used by the team that owns the agent: platform engineers, applied AI engineers, PMs, reviewers, and anyone accountable for launch readiness.
# Illustrative Harness Assurance Report - refund-agent
Target: ./agents/refund
Release: candidate-refund-01 (example identifier)
Mode: code+tests
Launch decision: BLOCKED for live refunds
Scope: payment writes; production behavior not observed
Critical path
model output -> direct dispatch -> payment write
failed obligation: permission checked before the effect
Evidence
agents/refund/graph.py:142 - direct dispatch path
tools/refund.py:31 - retry without operation identity
Effectiveness: Ineffective on inspected path
Runtime postcondition evidence: Not verified
Confidence: bounded by the inspected code and tests
Fix queue
1. Enforce caller, object, policy, and approval at dispatch
Closure: authorized success and forbidden-write denial
2. Reconcile a lost response using the payment operation ID
Closure: fault fixture confirms no duplicate refund
3. Observe the candidate in an isolated payment environment
Closure: correlated authorization and postcondition evidence
Re-audit after dispatch, credentials, policy, or release changes.
Example paths and findings are fictional; no audit was executed here.Scoped launch decision
BLOCKED, CONDITIONAL, or READY for the evaluated release and its declared deployment scope.
P0 blockers
Failures that can create unsafe writes, unreplayable decisions, hidden policy bypasses, or unbounded costs.
Evidence ledger
Every pass and fail cites the file, line, trace, or missing artifact used to make the call.
Rerun loop
The report is shaped for iteration: fix one load-bearing gap, rerun, and compare the result.
Turn harness risk into a concrete fix queue.
Start with the audit, fix the highest-risk runtime gap, then rerun until your launch claim is backed by artifacts.