Harness Engineering Notes: Agent Workflows That Hold Under Pressure

Give an agent a tool and it will eventually call it twice, call it with the wrong arguments, or call it at exactly the wrong moment. This is not a model defect to wait out - it is the operating condition the harness must be designed for.

The harness is everything around the model that makes agent behavior hold: idempotency keys on every mutation, JSON schema validation on every tool result, policy gates before any persistent write, and full audit trails after. BrewCMS models this explicitly - the policy engine evaluates content:create before any draft exists, and every lifecycle transition is an audited event.

Bounded tool calling is the highest-leverage control. Each tool declares its input contract, its blast radius, and its retry semantics. The agent proposes; the harness disposes. Probabilistic reasoning stays inside, deterministic enforcement stays outside.

Start every agent workflow with three questions: what happens on double-execution, what happens on malformed output, and what is the human-visible audit record. If any answer is unclear, the harness is not done.