Your name is on the building, and on the letterhead, and on the side of the vans. There is no board that meets quarterly to absorb a bad decision, no general counsel two doors down, no head of communications who owns the apology. There is you, a group of companies you have spent a long time assembling, and a set of clients and suppliers most of whom you could ring at home.
Somebody in the group has now proposed putting an agent in front of some of that correspondence. The proposal is good. It names the right recurring work, it has a cost against it, and the person who wrote it is somebody you trust with more than this.
What you are turning over is narrower than whether it works. It is the part nobody in the room raised, because they were being careful about the technology rather than about the exposure: when this thing writes to a client, the signature at the bottom of that message is yours.
Why your version of this risk is not the one the vendor has priced
A listed company’s bad outbound message is an event. It has a date, a scope, a number of recipients, and a recovery path that somebody has run before. The communications team drafts a note, the account managers make calls, the survey comes back three points down and eight points back up by the following quarter. It is genuinely unpleasant and it is bounded, and the reason it is bounded is that the counterparty’s relationship is with a brand rather than with a person.
Yours is not shaped that way. A client of eleven years takes your call because of an afternoon in two thousand and fifteen when you did something for them that no contract required. That is not a brand asset and it does not survive being surveyed. It survives on the assumption that when something arrives with your name on it, you wrote it or somebody you chose wrote it. One message that quotes a figure you never agreed does not cost you a reputation score. It costs you the thing the relationship was resting on, which is that your word arrives unmediated.
So the question you have been circling is the wrong one. How good is it has no answer you can act on, because every honest answer is a quality rather than a limit, and a quality cannot be breached. The question that has an answer is what cannot leave without a person, and that one is answerable as a list.
The list is the only artefact in this decision you can actually hold. In the Cabinet, ArkOne’s reference design for an executive agent, the rules that decide what may leave are called the Door, and they run in code after the agent has decided to send and before anything reaches anybody. No more than five messages to one person in an hour. Nothing near-identical to something sent to the same person in the past six hours. Nothing at all while a person is on leave or outside their working hours. When a rule refuses, the reason is handed back, so the work reschedules rather than trying again in a loop. Every one of those values is written down on the Register, the standing page of the design’s settings.
Here is the advantage you hold over the chief executive of a listed group, and it is a real one. Those are settings, and you can simply decide them. No committee, no policy cycle, no consultation. You can name the classes of message that must stop for a human before lunch tomorrow and nobody will ask you to justify the choice.
Here is the disadvantage, in the same breath. Nobody else will catch it if you decide it loosely. There is no risk committee reading the configuration, no internal audit function that will find it in the third quarter. The list is as good as the hour you gave it.
The three settings, and the one that is honest
There are three places this dial can sit. The two ends are the ones people argue for, and the middle is the one that gets bought.
| Where the dial sits | What leaves on its own | What it costs you | Who it suits |
|---|---|---|---|
| Everything | Every message the agent decides to send, to anyone on the roster | Your signature on prose nobody read; the ledger becomes the first place you learn what was said | Nobody whose own name is on the correspondence |
| Nothing | No message at all; every draft waits for a person | You read every draft, so the work is now reading rather than writing, and at a few hundred messages a week that is a job | A first quarter, deliberately, while you learn what it writes |
| The honest middle | Internal messages, scheduling, acknowledgements, anything to your own staff | Judgement, once, about which classes of message carry your word rather than your logistics | An owner who intends to run this past the pilot |
Exhibit 2. Illustrative. What may leave without a person at three settings, and what one message costs with a ledger and without one.
The first row is not a straw man, and that is why it is in the table. It is what you get from a system whose outbound checks were written as instructions to the model rather than as rules in code, because an instruction is a request and a model under pressure from a plausible task will sometimes grant its own exception. Nothing was switched off. Nothing was ever switched on.
The second row is where a cautious owner reaches first, and it is a reasonable place to begin a quarter. Its cost is the one nobody models: a draft that waits is a draft somebody reads, and in a private group that somebody is you or one of the two people who can speak for you. A bottleneck that is also the owner is how these arrangements quietly stop being used, which the account of how a pilot dies sets out at length.
The third row is a decision rather than a posture, and it is about categories. Anything to a client, a supplier or a regulator waits. Anything quoting a price, a discount, a date or a commitment waits. Anything internal, or confirming something already agreed, may leave. That split takes an afternoon to draw and holds for years, because it follows the shape of your business rather than the shape of the software.
Now the part the proposal will not have mentioned, and the part to raise first. When the Door itself errors, the reference design lets the message through and writes the fault down. The reasoning behind that is sound: a guard that refuses everything the moment it breaks turns an outage into a quiet afternoon, and a quiet afternoon is the harder failure to see. You will notice a wrong message. You will not notice three days of nothing.
For you, that default is the wrong way round on one class of message, and the design provides for it. A company may set the Door to refuse rather than allow when the Door itself errors, for a named class of tools such as payments and regulatory filings. The class you care about is not on that example list and it should be: anything leaving under your own name to somebody outside the group. That election belongs in the contract rather than in a support ticket, and it is the most useful sentence you can add to the schedule, which is where the four terms that decide how this goes ends up.
Two smaller rules do work an owner would otherwise do by hand. A message from anyone not on the roster is dropped without a reply, so the room never gets into correspondence with a stranger who wrote in. And approval rights are named per person rather than by seniority, with exactly one scope that approves anything at all; in the reference design that scope belongs to the chief executive, and in your group that is you.
What one message costs, with a ledger and without
Suppose a privately held hospitality group, invented for this exercise: four hotels and a restaurant business, the owner’s surname above the door of all five. An agent handles supplier correspondence and event enquiries. In the sixth week a reply goes to a corporate client who has booked the same December function for nine years, confirming a rate that was discussed internally and never agreed. The client books on it, and you find out eleven days later.
| What you need to establish | With the Record | With what a typical build leaves you |
|---|---|---|
| What was actually sent, and when | The message as sent, the time, the recipient, and every outbound rule that ran with its verdict | The sent folder, if it sends from an account you control |
| Whether a person approved it | The pause, who answered, the words they answered with, and that the run then stopped | Somebody’s recollection of a Tuesday |
| Where the rate came from | The shelf the passage was drawn from and the specialist that put the figure into the reply | An assumption, argued between two of your directors |
| Whether anyone has tidied it since | Every correction as a later entry, with the original standing beside it | No way to tell, which is the same as no |
Exhibit 3.
The left-hand column is what append-only means in practice, and it is worth asking to see rather than being told about. An entry is never edited. A correction is a new entry and the old one stands. That is what makes the thing evidence rather than notes, and it is also why it is uncomfortable: a mistake you made is still legible in it next year, and so is the moment one of your directors approved something quickly.
What it cannot hold is the difference between a decision and a keystroke. Your directors approve things in batches, because that is how a small senior team gets through a Monday: eleven items in the queue, eleven approvals, and the ledger records eleven considered judgements because that is the only thing it is able to record. The seventh of those eleven is the one you will be arguing about, and the entry beside it looks exactly like the other ten. That limit matters more to you than to a listed group, because a dispute with a client of nine years is not settled by proving a sequence. It is settled in a conversation, and what the ledger buys you in that conversation is the ability to say exactly what happened without guessing, which is a smaller thing than being right.
The right-hand column is what you have if nobody asks for the left. Three of those rows resolve into somebody’s memory of a Tuesday and the fourth into nothing at all. An owner in that position has two options on day eleven: honour a rate nobody agreed, or tell a client of nine years that the message carrying your name was not from you. Both are expensive and only one is survivable more than once.
The list, and what to do with it
What you are going to hand the vendor is one page, in your own words, and it has two halves.
The first half is the list of what cannot leave without a person, written as classes rather than as examples. Anything to a named client or supplier. Anything containing a price, a discount, a date or a term. Anything to a local authority or a regulator. Anything to more than one recipient at a time. Keep it short enough to fit on one side, because a list of thirty classes is a list nobody has decided, and it will be quietly reinterpreted by whoever configures the system.
The second half is three questions about that list, and they separate a build from an assembly.
Where does each of these rules run, and what happens when the rule itself errors? A good answer names the failure behaviour for each class on your page, and can say which rules live in code and which are only written into the instructions given to the model. A real answer, and you will hear this one, is that the safeguards are layered and the prompts are hardened. Take it at face value rather than as evasion, because it is usually true. Then put your own signature in the room and make them show you: here is a message on my list, addressed to a client of mine, going out over my name. Send it, now, while I watch. What you are looking for is what physically happens next. If somebody on their side has to decline to press a button, you have bought a promise about their staff. If the message stops without anybody in the room doing anything, you have bought a limit.
Can I set it to refuse rather than allow when the check breaks, for the classes on my list, and where is that written? The good answer names the setting, says it is per class of action rather than global, and says where the election is recorded. The thin answer is that it is configurable, which is generally honest and is not an answer. Your follow-up is the same one every time: what is it set to today, in the instance you would be running for me, and does changing it need your engineers or mine.
Show me the last message this system refused to send, and the reason it gave. A good answer opens a ledger live and finds one, with the rule that refused it and the reason handed back. A vendor whose system has never refused anything has either never run it or has nothing in the path that could refuse. That question is put more thoroughly to a seller in the question about what sits before a message leaves, and it is the one to ask while the laptop is still open.
One thing not to ask for. Do not ask whether it might send something wrong. It might, and a vendor who says otherwise is selling you something that does not exist, and you have learned nothing about the arrangement you would actually be running.
Write the list before the next meeting
Open your own sent folder at last Monday and work forwards through the week, sorting each message you actually sent into one of two piles: this could have gone on its own, and this needed me. Not classes in the abstract. The real messages, one at a time, which is half an hour and needs nothing from anybody.
The second pile is your list, and it is better than any list you would have written from first principles, because you are not guessing at what carries your word. You are reading it. When somebody later proposes moving one class out of that pile for a good reason, you will be arguing from the messages rather than from a policy, and that is an argument you can win in your own boardroom.
What happens after the thing is running is a separate problem, and it is not one person’s job however much you would like it to be. The first ninety days takes it apart into the three jobs it actually is, and the first of those is the one you have just done by reading a week of your own sent folder.
component: null
Asked plainly
How do I stop an AI agent from contacting clients without approval?
By naming the classes of recipient and message that must stop for a person, and asking where that rule runs. A rule written into the instructions given to the model is a request; a rule that runs in code after the model has decided and before anything leaves is a limit. The list is short in practice: anything to a client, anything that quotes a price, anything to a regulator. Everything else can leave on its own, and the useful conversation is about which side of that line each thing sits on.
What happens if the thing that checks outbound messages breaks?
That is a design choice somebody has made, and you should ask which way it was made. A guard that allows the message and writes the fault down keeps working when the guard is broken; a guard that refuses turns every outage into a silent day, which is harder to notice than a wrong message. The reference design allows and logs by default, and lets a company set the opposite for a named class of tools such as payments and regulatory filings. An owner whose own name is on the correspondence usually wants that election written into the contract.
Why is the risk different for a privately held company?
Because the counterparty's relationship is usually with a person rather than with a brand. A listed company that sends a wrong message runs a reputational event it can measure and recover from over a quarter. A private owner sends it under a name that is personally theirs, to a client or supplier who trades with them on the strength of twenty years of dealing, and there is nobody above them to absorb it. The compensating advantage is that the owner can decide the limits alone, in an afternoon, with no committee.