It is Tuesday evening and you are reading a transcript. Finance advised a discount to close a renewal, the third time this month, and your policy for two years has been to hold the list price and move on terms. The advice was competent and wrong for your company. You want it changed before tomorrow’s meetings, without opening a ticket with the vendor.
The Register, the one page listing every setting of ArkOne’s reference design for an executive agent, records a specialist’s instructions as exactly that: a setting. That design is called the Cabinet, and in it you edit the instructions tonight and the next meeting reads the new version. Nothing is rebuilt, nothing is redeployed, and nobody outside your company is asked.
Why tonight is possible
The sixth paper opened a Seat, one of the ten specialists at the Table, and found three parts: a name, a model, and a set of instructions about a screen long. The part that matters here is when those instructions are read. In the reference design a Seat reads its instructions each time the Chair, the one voice that runs the meeting, consults it. They are fetched at that moment from where the company keeps them, and the Seat answers under the version it found. Change the text and the next consultation finds the new text. There is no step in between.
Contrast that with the room itself. The loop and its cap, the Table, the Door that decides what may leave, the Record that writes everything down: those are code, and changing code is an engineer’s work with a release behind it. The machinery is built, tested and rarely touched. The judgement inside each Seat is text, owned by the company, and touched whenever policy moves. A vendor who keeps the instructions inside the code has turned a policy change into a software release.
The reference design adds three habits around the edit, because a setting that takes effect at once can go wrong at once. Every change is written to the Record with who made it and when, so tomorrow’s transcript can be read beside the instructions in force. The previous version is kept, so a change can be put back in the time it took to make. And before a change is trusted, the design runs it through the Rehearsal, the standing examination in which scored scenarios are put to the room and a judge model scores the answers, catching a line that reads well and degrades the advice before a client meets it.
Who looks after it? The person who owns the policy. When the finance director changes how discounts are handled, the finance director changes Finance.
Tonight’s change, tomorrow’s meeting
Suppose the Tuesday evening above, in the invented company that carries the renewal through this series. One line is added to Finance’s instructions: never recommend a discount to close a renewal; propose payment terms or a volume tier instead. Two rooms, one week.
| When | The reference design | A room with the instructions inside the code |
|---|---|---|
| Tuesday, evening | The finance director edits the line. The Record notes who, when, and the text before and after. The Rehearsal runs its renewal scenarios against the new line overnight and scores them | A change request is written to the vendor and joins a queue |
| Tuesday, night | The Clock, the scheduler that acts unasked, runs its usual jobs. Nothing is rebuilt | Nothing changes |
| Wednesday, morning | A renewal request arrives. The Chair consults Finance. Finance reads the new line and proposes a volume tier | The same request arrives. Finance proposes a discount, as it did last month |
| Wednesday, later | The finance director reads the transcript beside the instructions in force and sees the line that produced the advice | The vendor confirms the change is scheduled for the next release, in a fortnight |
| The fortnight after | Every renewal follows the new policy | Every renewal follows the old one |
Exhibit 2. Illustrative. One line changed on Tuesday evening, and the week that followed in two rooms.
In the first room nothing was engineered on Tuesday night. The policy changed because a sentence changed, and the sentence was read the next time it was needed. The cost was the finance director’s evening and the Rehearsal’s overnight run.
In the second room the instructions are compiled into the deployed software, so changing one means building and releasing that software again, on whatever schedule releases run. The consequence is measured in the last row: a fortnight of advice your company had already decided against, repeated for every Seat and every policy that moves.
The limit deserves the same clarity. A line that takes effect tomorrow morning takes effect whether or not it was wise. The reference design holds that risk with the Rehearsal, which scores the change before it is trusted, and the kept previous version, which makes a wrong line a one-minute repair. A room offering the edit with no history and no examination has given you speed without a brake.
What this arms you to ask
Ask the vendor whether you can change a specialist’s instructions without a redeploy.
A good answer is a screen you are shown rather than described: the instructions of one specialist, a history of who changed them and when, the control that restores the previous version, and the tests that run when a line changes. The vendor who has this will also name the risk, that a change lands at the next meeting, and show you what stands between a careless edit and a client.
The answer that ends the conversation is that changes go through the vendor and arrive in the next release, which is a redeploy described politely. A second version is more honest and worse: the instructions have been carefully tuned, and changing them risks quality. That names a real danger and, in the same sentence, tells you the instructions are the vendor’s product rather than your policy. Ask the follow-up that separates them: if I change one line tonight, when does the first meeting read it, who can see that it changed, and how do I undo it?
Next paper: Why the Cabinet thinks harder about fewer questions.
Asked plainly
Can I change an AI agent's instructions without the vendor?
In a design where each specialist's instructions are stored as a setting and read at the moment of use, yes: you edit the text, and the next question the specialist answers is answered under the new text. Where the instructions are built into the deployed software, a change becomes a release, and the vendor's timetable becomes yours.
Who owns the instructions inside an AI agent, the vendor or us?
It depends where they are stored, and that is worth establishing before signing. The machinery, meaning the loop, the guards and the audit trail, is code and stays with whoever built it. The judgement, meaning what each specialist is told to do and never do, is text, and it should belong to whoever owns the policy it encodes. A finance director who changes the discount policy should be able to change the finance specialist the same evening, without a ticket.
Is it risky to change an AI agent's prompt?
A change that takes effect at the next meeting takes effect whether or not it was wise. The reference design holds that risk in two ways: every version is kept so a wrong line can be put back at once, and a standing set of scored scenarios is run against the change before it is trusted. A system that offers the edit without the history or the test has given you speed without a brake.
Ask the vendor
The questions this part arms, each with the good answer and the answer that arrives instead.