Fence the agent before you build it.
Most teams decide what an agent is allowed to do after they have seen it work. Doing it the other way round costs a morning, changes what gets built, and is the whole difference between automation and exposure.
Fence first
There is a normal order to these projects and it is the wrong way round.
Someone builds an agent. It works. Everybody is pleased. Then, somewhere between the pilot and going live, a sensible person asks what it is actually allowed to touch, and the team spends three weeks retrofitting permissions onto something that was designed without them.
We do it first. Before a line of code, we write down three lists, agree them with the person whose name is on the risk, and then build inside them. It takes a morning. It changes what gets built.
The three lists
What it may do on its own. The work you are happy happens at two in the morning with nobody watching. Reading. Sorting. Drafting. Looking things up. Preparing something for a person to check. The test is simple: if it did this wrong a hundred times overnight, would that be an inconvenience or an incident? Inconvenience goes on this list.
What needs a person first. Anything that leaves the business, spends money, changes who can see what, or commits you to something. A named person, asked in advance, not told afterwards. This list is usually shorter than people expect and it is always the list that gets argued about, which is exactly why it is worth writing down while everybody is calm.
What it must never touch. The systems and the data that are simply out of scope, whatever a future instruction says. Payroll. The client folder for the one account you cannot afford to lose. Anything with a regulator attached. This list is not about trust, it is about blast radius.
Written down before the build, the three lists stop being a policy document and start being the thing that decides what happens on a Tuesday morning:
Scroll the queue sideways to see what happened.
| Time | What the agent asked to do | Which list it fell on |
|---|---|---|
| 08:14 | Sort the overnight inbox and file 31 messagesWrong a hundred times over is an inconvenience, not an incident | List one, on its own |
| 08:19 | Prepare a quote from the standard rate cardPrepared, not sent. Preparing is list one | List one, on its own |
| 08:31 | Send that quote to the customerCommits you to a price, so it asks first | List two, waiting on Sales |
| 08:44 | Open the payroll folder to check a nameA reasonable request. Still refused | List three, never |
An example of the format, not a customer’s data. Note the 08:44 line: the agent had a sensible reason and the fence did not care, which is the entire point of writing it first.
Why the order matters so much
An agent built without a fence will quietly assume it has one that is the size of whatever credentials it was given. In practice that is usually somebody's full account, because that was the fastest way to get the demo working, and nobody went back.
Retrofitting is worse than it sounds. You are not adding a setting, you are unpicking assumptions that are spread through the way the thing was written. It is the same reason logging bolted on afterwards records outcomes and not reasoning: the design did not have a place to put it.
Fencing first also has an effect that surprises people. It makes the build smaller. Once the three lists exist, half the ideas from the original workshop turn out to sit in list three, and the first agent becomes one job done properly instead of five jobs done nervously.
The brake belongs to you
A fence answers what the agent may do. It does not answer what happens when something you did not anticipate is happening right now.
That needs a stop, and the stop has to be yours. Not a support ticket. Not a phone number that works between nine and five. A control that a person in your business can use, immediately, without asking anyone, that halts the agent and leaves everything it has already done intact and readable.
Ask any supplier to show you theirs. Ask them to pull it in front of you. If the demonstration involves them logging into something, you do not have a brake, you have an escalation path.
Write down who loosened it
Fences move, and they should. Three months in, the thing that needed approval every time has been approved four hundred times without incident, and asking a person to click again is theatre rather than oversight.
So the fence changes, and the change gets recorded: what moved, who asked, who agreed, and when. Not for bureaucracy. For the conversation in a year's time when somebody asks why the agent was allowed to do that, and the honest answer is that a named person decided it should be, on a specific date, for a stated reason.
That record is the difference between a decision and a drift. Most of the uncomfortable AI stories are drift.
It is a morning
The whole exercise is one meeting with the right people in it: whoever owns the process, whoever owns the systems, and whoever carries the risk if it goes wrong. Three lists, one page, signed off before anything is built.
It is the cheapest morning in the project and it is the one that decides whether you end up with an asset you can point an auditor at, or a clever thing nobody wants to put their name to.
Tell us the job that never gets done on time.
We will tell you, in plain English, whether an agent can take it, what it would take to build, and what it would cost to run.