Turn Agent Rules Into Gates
A prompt asks the agent to behave, and a strong model follows it about eight times in ten. A factory runs unattended, so the rules that matter become deterministic gates: allow docs and tests, ask a human about money, deny auth and production.
Chapters
Transcript
A prompt can be ignored
Now a prompt just ask the agent to behave and it can be ignored. For example, if you type Claude code just hey can you ignore this and you strictly follow this rule. If Claude Code is using Opus, then most probably they will be able to pick that line and able to you know do that 10 out of maybe eight out of 10 times it will be able to follow that rule. But if you are saying you know don't touch authentication related code or don't touch payment related code in the in the agents.md or in any of your rules, then it is more likely that it will be it will be followed again. Like bigger models might follow eight out of ten times, but it won't be followed every time. So that is where when you are creating that using your own harness, like on your terminal session, it is okay, you can keep that way, but when you are actually doing it in a factory, you are not babysitting each and every step. Then you need to write your guards that ignore such action deterministically. So converting a non-deterministic process to a deterministic process is what makes your factory more and more stronger.
Allow, ask, deny
Okay, a boundary meets every request before the agent acts. So this boundary is where it's basically like a hook. Even before your agent act on what needs to be done, this boundary need to be set. Like, hey, you can do this, you can't do this, and we need to enforce it. If you say like docs and test, you can automatically do whatever you want. You can write the doc, you can rewrite the doc, you can read the doc, you can run the test and all those things. But when it comes to money, ask a person, put a human in the middle and ask, hey, can you do this? I need to execute this. Can you do this? And then when you have authentication or anything that is you know in the production system, when you are you know checking it on, no, it is always denied. So these are already being built within the harness as much.
A model for each task
So most of the time your coding harness already cover all these things, but we still need to enforce for our factory because then you can use different coding agents, different model more confidently. For example, for your planning agent, you can use Opus 5.5, which has been released yesterday, I believe, yesterday or day before. you can use Opus 5.5, but for you know, writing your document, you can use just Claude Haiku. that way you don't need to spend your tokens on a simple docs writing or text writing, and if you are doing your actual execution, it's always better to you know once you have a clear-cut plan, you can even say a middle ground, like instead of opus or Haiku, you can use Sonnet on it. So that way you can execute different different models very easily. You don't need to always fall back on model, let the model handle all these. If you if you do that, then you need to babysit every time to the model. But if you are defining this, then you will be able to automate that and you will be able to create easily.
A gate is not overridden
Now, a rule can be overridden. So if you write it in AGENTS.md eight out of ten times it will be honored and it will be working. But when you are actually writing a check, writing a gate that okay, this rule shouldn't be overridden. This hook shouldn't be overridden. When when a coding agent try to write to a path which is not allowed, then automatically that rule will say denied. So automatically the coding agent is able to learn from it and able to act on that.
This lesson is cut from the free Lightning session Design a Software Factory for Your Coding Agents. The Live Labs build the same system with you, free, on Thursdays: see the Live Labs.