Scripts decide, models write
About three in four commits on the main branch of Trusq, the product my company builds, carry a coding agent as co-author. Development with agents is non-deterministic by nature. The same prompt produces a different plan on the next run, a fresh reviewer finds different things than the last one, and the models behind it, Claude Opus, Sonnet and Haiku, change with every release. I do not want to remove these differences between runs, because they account for a lot of the quality. But I want the process around it to stay predictable.
So I built a kit for Claude Code that gives the non-deterministic work a deterministic frame. The models write: specifications, plans, code, tests and reviews. Scripts decide: which step comes next, when a review is finished, when a change is blocked and when a person has to look. For the same input those scripts give the same answer every time, and they have tests. The rule fits in four words: models write, scripts decide.
The kit is called claude-agentic-kit. It grew inside the Trusq repository from March 2026, became a project of its own in April and is now at version 1.16. I designed it and directed its development, and agents built most of it inside the frame it provides, through its own pipeline: its backlog holds 50 items, 40 of them done.
The frame
Every piece of work moves through the same five steps in the same order: refine, plan, implement, review, document. What happens inside a step varies from run to run, but the shape around it does not. Refining turns a rough backlog item into a specification and asks me only the decisions it cannot look up in the code. Planning cuts the work into pull requests of about 20 files, never more than 50. Implementing happens test-first in a separate git worktree, so an agent never touches my working copy. Review is adversarial, by agents whose only job is to find what is wrong, and documentation is updated before anything counts as done.
Each step is a skill the agent follows. Between the steps sit small programs that the agent has to call and cannot argue with. There are 21 of these gate scripts, next to 20 skills and 22 agent roles. The skills and roles are where the models work. The gate scripts are the frame.
A review loop with four possible answers
The clearest example is the gate that ends a review. A reviewer reads a specification, a plan or a diff and reports how many critical findings and warnings it found. Opus reviews the odd rounds and Sonnet the even ones, because different models find different things. A fixer agent on Haiku addresses the findings, the next reviewer looks again, and the question is when to stop.
The reviewer's findings are the non-deterministic part, and that is useful: a fresh look finds what the last one missed. The same property makes the model a poor judge of when the loop is done. It either declares the work converged because the findings got shorter, or keeps going because there is always one more thing to say. So the decision lives in a shell script. It takes the counts of the current round, looks up the earlier rounds in a small state file, and prints exactly one of four words: converged, continue, oscillation_guard or exhausted. Oscillation means a fix made things worse, and exhausted means the round budget for that size of change is used up. In both cases the loop stops and a person looks.
The comment at the top of the script states the reason: "Pulling state-machine logic out of the main model's context makes the gate testable and insulates it from main-model downgrades." The loop may run a different number of rounds each time, but how it ends is fixed in code, and that does not depend on whether the model calling it is having a good day.
How a review loop ends.
Mistakes that turn into checks
The second gate turns what the agents get wrong into something the frame can check. After pull requests are merged, a skill mines their review comments and review rounds for recurring errors and writes them into a catalogue. Before a step runs, a script picks the ten entries that matter most for that step, ranked by how often they occurred and how severe they are, and puts them into the agent's instructions. Finding the mistakes is work for a model. Choosing which of them the next agent sees is a script, with a ranking anyone can reproduce.
Where an entry has a literal signature, a line of code that is known to be wrong, the script also searches the change for it and stops the run if it appears. It only searches the added lines of a diff, so a pull request that removes the bad pattern does not get blocked for containing it. Entries that need judgment stay advice. Only the ones a machine can check reliably are allowed to block, and that keeps the frame itself deterministic.
Routing as policy, not habit
Which Claude model does which job is part of the frame too. Every recurring role has its own agent file that pins Opus, Sonnet or Haiku, so the choice does not depend on what the main agent happens to pick in a given run. The rubric says to pick the cheapest model that survives three questions: what shape the task has, what ships if the agent underperforms, and whether a deterministic gate or a fresh reviewer checks the result afterwards.
Open-ended reasoning where a miss would go unnoticed gets Opus: drafting a specification, planning a security review and the deep correctness review of a pull request. Checklist reviews, research and planning get Sonnet. Fixes from an explicit list of findings, checking an implementation against its plan and read-only exploration of the codebase get Haiku. The third question is where the frame pays off. Because a gate or a reviewer checks the result, a cheaper model can safely do the drafting. The kit never pins anything above Opus; whether the main session runs on a larger model is the operator's choice.
Where the line runs
None of this makes a script judge whether code is good. Models still do that, and they do it well when they review each other with a clear brief. The line runs between content and control flow. The content is non-deterministic, and it may stay that way. The control flow is deterministic: whether to continue, stop, block or ask a person. The models' output becomes an input to that decision instead of the decision itself.
What carries over
This is not specific to AI. Distributed systems have always worked this way. Nobody can make the network reliable, so we put timeouts, retries and circuit breakers around it, and those are plain code with tests. Agents are another non-deterministic component, an unusually capable one, and the same engineering applies: let the component vary, keep the frame around it deterministic, and treat everything it produces as input.
Next Wednesday: how the kit compares with Spec Kit, Superpowers, Matt Pocock's skills and the rest, and which decisions each of them leaves to a model.