ArkOne builds AI agents: software that does office work on its own. The Cabinet is our name for one way of building them, a reference design, and this page describes it as if it were a meeting room, because that is the easiest way to hold it in your head. A room, not a piece of furniture: one voice at the head of the table, ten advisers around it, shelves along the wall, and a door that decides what may leave.
You have probably been told that an AI agent is either a chatbot with ambitions or a digital employee. Both descriptions are sold to you, and both hide the thing you need to know: what the software is made of, so that you can judge what it will do in your company when nobody is watching. Take any vendor’s demonstration apart and you will find a model, the AI program itself, which the vendor rents from one of the large providers and did not build, wrapped in three ordinary objects the vendor did build. A loop. A toolbox. A filing cabinet. This page explains the three, shows them assembled into a room, and ends with three questions that follow from the mechanism rather than from the marketing.
One note before the mechanism. The Cabinet is a design on paper. Every number on these pages is a decision written into the Register, the one page that states every setting of the design, not a measurement from a system running in your company. Where a page can show a run, it says so.
Three ordinary objects
The loop. A chatbot answers in one step: you ask, it replies from what it already knows. An agent may go around first. On each turn it does one of two things: it asks for something it does not yet have, or it answers and stops. A hard question might take several turns, because the contract has to be fetched, Finance has to be consulted, a rule has to be checked. Each turn is a chance to get the thing the answer needs, which is why an agent can do work rather than describe it. It is also why a loop is the first thing to worry about: a loop with no ceiling has nothing in it that stops. The reference design puts a ceiling on it in code and writes the number on the Register; the first paper walks one meeting up to that ceiling and asks what a vendor should be able to show you about theirs.
The toolbox. The model never touches your email, your files or your bank. It writes a request naming a tool, one action from a fixed list that the surrounding code has agreed to perform, and the code either performs it and hands back the result or refuses. Fetch this document. Ask the Finance adviser. Send this message. The list of tools is the whole account of what the agent can do in your company, and a message that arrives during a meeting cannot add to it. The third paper covers what happens when the model wants something the list does not offer; the fourth sorts the tools into four kinds, three of which stay inside the room and one of which reaches the world and cannot be recalled.
The filing cabinet. The model remembers nothing between meetings. What an agent knows tomorrow is what was written down today, in places you own and can read: the decisions of past meetings, the documents it may consult, and a ledger of every action with its stated reason. The reference design keeps the documents on four separate shelves so that your own material, a client’s material, the record of past failures and anything fetched from the web never blur into one. Where the memory lives and what decides that a document is relevant enough to use are the questions of the twelfth, thirteenth and fourteenth papers.
Put a loop, a toolbox and a filing cabinet around a rented model and you have an agent. Arrange them well and you have a room. The room has eleven parts, each with a name and its own paper, and the second primer takes them one at a time. This page needs only the five that the worked example below passes through.
Five parts, one message
The Chair is the loop and the one voice the company hears; it runs the meeting and speaks for everyone in the room. The Seats are the ten advisers, one per department, each a name, a model and a set of instructions; they speak only to the Chair. The Door is the set of rules that decides what may leave the room, to whom, and when. The Signature is a step that waits for a person. The Record is the ledger of every action with its reason.
Suppose a client emails to ask for a renewal at last year’s price. The company and its numbers are invented for the exercise, and the same example runs through every paper in this programme.
| Round | Where in the room | What happens |
|---|---|---|
| Before the first | The Door, inbound | The sender is on the list of people the room may speak to, so the message is admitted and the Chair reads it |
| First | The shelves | The Chair asks for the client’s contract and last year’s pricing; two documents come back |
| Second | One Seat | Finance returns a floor price, and a warning that a discount here sets a precedent across the account book |
| Third | Two Seats at once | Marketing: the client has been a reference twice this year. Operations: delivery on this account costs more since the route change |
| Fourth | The Chair | Finance and Marketing disagree. The Chair keeps the list price and offers the volume tier, drafts the reply, and writes the reasoning to the Record |
| After the fourth | The Door, then the Signature | The reply passes the Door’s rules. Pricing to a client is a class of action this company set to wait, so the run pauses at the Signature and the draft lands on your desk; a person releases it |
Exhibit 2. Illustrative. One renewal request, four rounds of a possible fifteen, through the room and up to the Signature.
Four rounds of a possible fifteen, ended by the Chair’s own answer rather than the ceiling. The advisers were consulted and their advice was used, and none of it reached the client; the second paper is about why the company hears one voice and never the advisers. The Door checked the draft after the model had decided to send it and before it could leave, which is the one moment in the meeting where a rule in code stands between the model and your customer. And because this company chose to make client pricing wait, nothing left at all until a person said so. Every step of it can be read afterwards, in order, by anyone you give the Record to.
Now change one thing at a time. Suppose the client’s email had come from an address the room did not recognise. In the reference design the message is dropped unanswered before the Chair reads it, because the room converses only with the people on its list. That protects you from a stranger steering your agent; it also means a new customer writing from a personal address is not answered, and a person has to be told. Read that setting before you agree to it. Suppose instead that the reply had been the sixth message in an hour to that person: the Door refuses, tells the Chair why, and the Chair reschedules rather than trying again. Suppose the company had set client pricing to act rather than wait: the reply leaves without a signature, and the Record is the only place you learn of it. In each case the model did nothing wrong. The room did what its settings say, and the settings are yours to read.
That is the whole argument of this programme in one paragraph. The judgement in an agent comes from the model, and it is good and getting better. The limits come from the room, and the room is built by people out of settings you can read. The demonstration shows you the first. The Register shows you the second.
What the room does that a person does not
It is tempting to read the parts as a description of a good employee: consults colleagues, writes things down, asks before spending. The comparison helps for about a minute and then misleads, so it is worth saying where it breaks.
A person can be persuaded, and so can a model. The Door does not read the argument. When an aggrieved email arrives at three in the morning, the model may want to reply in kind, may want to copy everyone, may want to send now; the Door applies the same rules it applied that afternoon, and when it refuses, it says why. The limit is on the Register too: if the Door itself breaks, the reference design lets the message through and writes the fault down, on the reasoning that a guard which fails silently hides every outage. A company can set that the other way for payments and filings, and should decide which.
A person carries context in their head; the room hands the Chair a written brief before every turn, and the order that brief is written in decides what each turn costs. The ninth paper explains the mechanism and links the published prices it depends on; the eleventh works a modelled bill with one careless line in the wrong place.
And a person is held to account in the ordinary way. The room is held to account by the Record, which every tool writes to, which is never edited (a correction is a new entry, and the old one stands), and which can never stop a meeting: if the ledger itself fails to write, the failure is logged and the meeting continues, because a room that falls silent whenever its ledger hiccups is a room nobody keeps running. When something goes wrong, you do not interview the agent. You open the Record and read.
What this asks of you
Three questions follow from the mechanism. You can put each to a vendor tomorrow, and each has a good answer and a common one.
What forces it to stop? The common answer is that the model knows when to stop, or that the limit is configurable. Both may be true and neither answers you. Ask what enforces the limit when the model would rather continue, and ask to see a run that reached it.
What can it touch, and which of those actions cannot be undone? The common answer is a count of integrations. Ask for the short list of actions that reach a person or a system you do not control, and the different control in front of each. If that list is longer than a page, that is the answer.
Where does it write down what it did, and can you read it? The common answer is a dashboard. Ask for the ledger exported to you, with the reason beside each action, readable without the vendor in the room.
If you can answer those three for a system you are considering, you understand it well. If you cannot, the rest of this programme exists to help: the second primer walks the eleven parts and names the failure each one stops; the twenty-six Cabinet Papers take one part each; and the Register holds every setting, so that when a paper says fifteen or six hours or four shelves, you can see where the number came from. Learn the room, and the demonstrations start to look different.
Next: The eleven parts of the Cabinet, and what each one stops.
Asked plainly
What is an AI agent, in plain terms?
Software that does work on its own. It reads what arrives, decides what it needs, fetches or asks for it, and acts, within rules a company sets. The model, the AI program a vendor rents from one of the large providers, supplies the judgement; the code around it supplies the loop it runs in, the tools it may use and the records it keeps.
How is an AI agent different from a chatbot?
A chatbot answers in one step from what it already knows. An agent goes around a loop: it can fetch a document, consult a specialist, check a rule and come back, several times, before it answers. That loop is what lets it do work rather than describe work, and it is also what a company has to bound.
What should a chief executive understand about AI agents before buying one?
Three things. What forces it to stop. What it is allowed to touch, and which of those actions cannot be undone. And where it writes down what it did and why. Every other question a vendor answers sits on top of those three.