How I work with AI agents: operating rules, a pre-stage for checks, a knowledge graph and build-and-critique loops.
Result
The result is a fixed framework for working with Claude: operating rules for an agent company, a pre-stage with checks at the critical points, a shared knowledge graph, loops of building and independent critique, and a memory of lessons learned. Whether the pre-stage saves cost is being measured, not assumed. This page will only state a result once there is one.
Starting point
If you work with AI agents every day, the same questions keep coming up: Which model does a task really need? Is a command risky? Is “done” actually proven? Does the research support the claim? On top of that, knowledge about projects and decisions should be available on every device, and mistakes should not repeat.
What was built
This way of working is a project of my own. It puts work with Claude into a fixed framework of five parts.
Operating rules for agents. In Paperclip, agents work in roles as in a small company. One shared rules file is attached to every agent. It covers the sparing use of large models, short reports and three levels for escalating to me: immediately for security issues, as a decision request for approvals, batched into the daily report for everything else. The rules file reserves new agents, new services and platform updates for me; I approve exceptions individually.
A pre-stage with checks. Before the actual work sits a fast decision model, Jev by TypeSafe. It does not generate text but short verdicts: yes or no, a choice, a level. It is connected through a custom MCP server on Cloudflare Workers, which offers checks at four points:
- Triage of every non-trivial request, with a recommendation for model and effort,
- a check before risky actions such as deleting, overwriting, publishing or deploying,
- a completion check before work counts as done,
- a research check before researched facts are presented as established.
The pre-stage only advises. If a call fails, that is stated and work continues normally; a verdict is never invented. Whether it saves cost overall is being measured by comparing work with and without the pre-stage.
A shared knowledge graph. Lasting facts live in one place and can be retrieved in any environment. Feedback on the pre-stage’s verdicts is logged and used to adjust its thresholds.
Alternating build and critique. A piece of work is split into small parts. A builder builds each part, then three critics with fresh context check it: one against the brief, one against the design rules, one in comparison with a concrete reference. All three must agree. There is no fixed number of rounds. In AI film every round costs money, so a budget ceiling applies there, and I judge the audio because the critics cannot hear.
Lessons learned as memory. Claude Code records feedback from projects as a short note: what happened, why, and how it will be done in future. Examples:
- A music bed that, as briefed, sits very quietly under the voice comes across as missing. In future this is flagged up front and an audible second mix is delivered as well.
- A new video gets a new script and a new voice instead of reusing lines from an earlier spot.
- Statements about a client come only from the client’s own information.
- In a museum project, clear glass could not be captured by photogrammetry. The alternative method is noted for future glass objects.