Set the rules once, let agents build within them

In June 2025 Gartner warned that a large share of agentic AI projects would be cancelled by 2027, with runaway costs and weak governance near the top of the reasons (Gartner press release, 25 June 2025). You can read that as a forecast. I read it as a description of what happens when agents are let loose with no rules they can’t cross.

The reason matters, because the tools themselves aren’t the problem.

The developer was the rules

When one developer uses a coding assistant, an enormous amount of governance happens without anyone writing it down. The developer knows not to touch the payments module without talking to someone first. They know the team’s conventions, which tests matter and which are flaky, and that you don’t send customer data to a model you haven’t been cleared to use. They also feel the cost. If the assistant goes round in circles for twenty minutes, they notice, get bored and stop it.

In other words the human is the policy, the reviewer and the budget, all at once. That’s why assistants have been so easy to adopt. The rules never had to leave anybody’s head.

Now take the same work and hand it to several agents running in parallel, overnight, on a backlog nobody is watching line by line. That’s the whole point of using agents: they go faster than a person can follow. But the moment you remove the person from each step, you also remove every rule they were quietly enforcing. Nothing stops the agent editing the payments module. Nothing notices the twentieth retry. Nothing knows that the change needs a second pair of eyes.

So the rules have to be written down, somewhere the agents can’t route around.

What the rules actually are

When you sit down to write them, the list is less mysterious than it sounds. Most organisations already have these rules. They’re just scattered across wiki pages, code review habits and people’s memories.

1. What agents may change, and what they mustn’t touch at all.
2. Which checks a change has to pass before it goes anywhere.
3. Which changes need a named person to approve them, and who that person is allowed to be.
4. Which models may be used, and where code and data are allowed to go.
5. How much a piece of work may cost before it stops.

The interesting part is the word “once”. Rules typed into a prompt are suggestions, and they drift. Every engineer phrases them a bit differently, and the model may or may not honour them on a given day. Rules written once, for a team or a codebase, apply to every agent on every task the same way. They can be reviewed like code, and versioned like code, and when one changes, that change has its own record. Six months later you can say exactly which rules a given piece of work was built under.

The budget is a rule, not a report

I want to dwell on the last item, because it’s the one people tend to treat as a billing detail.

A budget that sends you an alert is a dashboard. A budget that stops the work is a rule. The difference matters most when things are going wrong, which is precisely when nobody is looking at the dashboard. An overnight run doesn’t wait for someone to read a notification at 7am.

A good budget does more than stop things, too. If the ceiling is tight, the work should adapt: use a smaller model for the boilerplate, save the expensive one for the part that needs it, and decline to start a task it can’t afford to finish rather than abandoning it half done. When it does stop, it should say what it stopped and why. That’s the behaviour I’d look for, and I go into the cost side more in cost governance before the invoice.

The same goes for every other rule on the list. An instruction in a prompt is a request to the model. A rule has to be enforced by something outside the model, so that it holds whether the model agrees with it or not.

Where we’ve landed

This is the interface we’re building Kizuna around. You set your rules once: what’s in bounds, what has to be checked, who approves what, which models are allowed, what the work may cost. Agents build within them. Every change carries a record of which rules applied and who signed off, which is the subject of one record per change. And it works the same on your own infrastructure as anywhere else, because rules that depend on someone else’s service aren’t really yours. More on that in sovereign AI, air-gapped by default.

We’re still in development, so I’ll be honest that this is a direction we’re committed to rather than something with years of production behind it. But I’m fairly confident it’s the right shape. Giving agents autonomy is only reasonable if they come with limits they can’t talk their way past.

How to test it, with us or anyone

If you’re evaluating any agent platform for serious work, a few questions will sort the real thing from the demo quickly.

Ask to see an agent decline to do something because a rule said no. Not an alert after the fact. A refusal, with a reason.

Ask where the rules live. If the answer is “in the prompt” or “in each engineer’s settings”, they aren’t rules.

Lower the budget and see what changes. If the only thing that changes is when the alarm goes off, the budget is decorative.

Change a rule and ask to see the record of that change, and which pieces of work ran under the old version.

Then try it for real on something small. Pick one codebase with a backlog you understand. Write the rules down, including a budget set a bit below what you’d expect to need. Let agents work on it for a few weeks and watch two things: how often they stay inside the lines without being told, and how much of your people’s time goes into the approvals that genuinely need a human. If agents keep wandering out of bounds, you’ve learned something cheaply. If they don’t, you’ve found a way of working that scales past the number of people you have watching.

If you’re working on this, we’d like to hear from you at /contact.