Classification: TOOL BEHAVIOUR is observable; token savings and behavioural improvements have not been measured in a paired test.
View the full infographic → · View this article
A shared operating-rules file can make recurring safeguards easier to review and update. Its value is consistency and legibility until a matched test proves a reduction in request size or an improvement in accepted outcomes.
Keep policy short, scoped and testable
Rules work best when each line names an observable behaviour: persist a checkpoint, reconcile an ambiguous external write, separate process heartbeat from semantic progress, or stop at a human-only authority gate. Avoid broad slogans that do not tell a worker what to do at the next failure.
Reuse without blind repetition
A shared policy can provide stable defaults while each job supplies its own task contract, source evidence and acceptance test. Do not paste unrelated project history into every request. Retrieve specifics when they matter and pass forward a concise verified summary.
Before claiming context savings, preserve the old and new policy, count tokens using the same tokenizer or provider boundary, and test task quality on comparable cases. A line count is not a token count, and shorter instructions can omit a binding requirement.
See what each choice changes
The AI Agent Operating Rules Builder exposes recovery, checkpoint, idempotency, human-gate and progress choices as exact rule text. The Token Optimisation Rules Builder makes each selected sentence visible. Both run in the browser; neither measures how your agent behaves after installation.
For the evidence boundary between a short reply and a request, see the one-run canary report. For progress and recovery signals, read the incident observation.