Twenty past six, and the meeting broke up ten minutes ago. Your chief technology officer stayed behind to say the rest of it properly: we can build this, and we should, and here is roughly how. A written outline is in your inbox before you have left the building, with a timeline in it and a name against each piece, which is what happens when somebody has been thinking about a problem for a while.
Everything about that is good news, and you know it. This is the person who kept the migration on the rails when nobody outside the team understood why it was hard. They have built things you rely on daily, they have read the same material you have, and they understand your renewals in a way no supplier will inside a year.
Which leaves you holding a decision you are not equipped to make, about the judgement of the person you would normally ask.
Why this particular decision is hard
What makes this hard has little to do with trust or with technical literacy. The trouble is that both of the obvious moves are wrong.
Approve it because you trust the person, and you have not made a decision, you have delegated one while keeping the accountability. Decline it on instinct and you have overruled your most senior engineer on their own ground with nothing to show for the reasoning, which is a cost you pay for two years in every conversation after it.
What sits between those is a scoping conversation, and a chief executive can hold one of those without knowing what a token is. It turns on a property of the work rather than on anybody’s competence: the part of an agent that is easy to picture is not the part that fills the calendar.
The reasoning part of an agent is a loop. Something reads a request, decides whether it needs a tool, uses it, reads what came back, and goes round again until it can answer. That loop is well documented, quick to build, and the part every demonstration shows. Around it sits the machinery that turns the same behaviour into something a company can run rather than its builders.
In ArkOne’s reference design for an executive agent, the Cabinet, those surrounding parts carry names. The Door, the rules running in code that decide what may leave and what happens when a rule itself errors. The Directory, the roster of people it may address at all. The Record, the ledger of every action and the reason beside it, where nothing is edited and a correction is a new entry. The Signature, the step where work stops until a person answers. The Clock, which decides when something runs and never what it may do. The Mandate, one authority setting per specialist, shipped at propose and wait. The Rehearsal, the scored examination run before any change is trusted. Every value sits on the Register.
Held against a working system, the reasoning machinery is about a fifth of it. That is a fact about the shape of these systems rather than a criticism of anybody’s estimate, which is why the question about proportion belongs here too. The remaining four fifths are invisible in a demonstration, unglamorous, and where the calendar goes. Vendors under-size them as well.
The four fifths, and how to raise them
Suppose an outline like the one in your inbox, invented for this exercise. It covers the loop, the specialists, the connection to your document store, and a screen your operations team types into. It is a good outline. Here are the parts it does not yet mention, and the honest reason each waits.
| The part | What it does | Why it is usually deferred |
|---|---|---|
| The outbound rules | Decide in code what may leave, to whom, at what rate, and what happens when a rule errors | Nothing leaves during a demonstration, so no rule is missing yet |
| The roster | Names the people the system may address, and drops a stranger unanswered | In development the only correspondent is the engineer testing it |
| The ledger | Writes every action and its stated reason, appended, never edited | Easy to build, hard to build so a failed write cannot break the system |
| The approval step | Stops a run until a person answers, and records the answer | Adding a pause to something you are proving works comes last |
| The scheduler | Decides when unasked work runs, and guarantees a job fires once | A job that fires twice is invisible until two copies are running |
| The authority setting | Says whether each specialist may act, must propose, or must escalate | In a prototype the answer is the same for everything |
| The standing examination | Scores fixed scenarios before any change ships, so a slip is caught | You cannot write it until you know what good looks like |
Exhibit 1. Illustrative. Eight questions for your own engineering lead, and what a whole answer contains.
The right-hand column is an account of good engineering practice rather than of oversight. Every reason in it is correct at the point it is made: you do not build outbound rules before anything can go out, and you cannot score scenarios before you know which matter. The parts are deferred in the right order, and the deferral is invisible in the thing everyone judges the work by.
Two rows carry more than the others. The ledger is where a build stops rather than fails: on the morning a client quotes back a discount your company never agreed, what settles it is a record you can read and nobody can tidy. Writing entries to a store is a small job. Writing them so a correction stands beside the original, and so a failed write does not take the working system down with it, is a different job.
The scheduler is the row that catches teams who have shipped a great deal of software. Claiming a due job has to happen in one indivisible step, or two copies of the same overnight run each decide the job is theirs and your client receives one message twice.
Eight questions, and what a whole answer contains
Suppose you take these to your chief technology officer as questions rather than as a challenge, because that is what they are: two people scoping the same job.
| The question | A whole answer contains | A partial answer sounds like |
|---|---|---|
| What may this send, to whom, without a person? | The named rules, where each runs, what happens when one errors | We will put guardrails around sending |
| Who may it talk to, and what happens when a stranger writes to it? | A roster, and the stranger dropped unanswered | Access control comes with the platform we are using |
| Where is every action written down, and who can edit it? | A store, appended, with the reason beside the action | Everything gets logged |
| Which actions stop for a person, and what happens after they answer? | The named actions, and whether the run continues or waits | We will add approvals for the risky ones |
| What runs unasked, and how do we know a job fires once? | The scheduled jobs, and the claim that makes a job exclusive | The scheduler handles that |
| What is each part allowed to do on its own? | One setting per specialist, and the default it ships at | It only does what we tell it to |
| How do we know a change did not make it worse? | Scored scenarios, a pass mark, and a rule for a single slip | We will test it before it goes live |
| Who operates all of this in eighteen months? | A name, and what happens when that person is on leave | The team will own it |
Exhibit 2.
The right-hand column is what the work honestly sounds like before it has been scoped. Nobody can name outbound rules that do not exist yet, and an engineer who invented six on the spot would be guessing. Asking moves those rows from later into now, while the calendar is still being written.
What the answers tell you is where the work stands, not how good the engineer is. Somebody who has run a system like this will already have views on the roster and the ledger, because those generate the calls at night. Where the answer to the last four rows is that the team will settle them once the shape is clearer, that is accurate about the outline, and the reason to ask while the estimate is open.
The last row does not get easier with more engineers, and it is the one your successor inherits.
What a good build decision looks like
Take the eight questions to your chief technology officer, say plainly that you cannot judge the engineering and are trying to judge the coverage, and ask for the outline again with those rows in it. Set no deadline on the reply. What comes back is a better estimate than any supplier could produce, because it is written by someone who knows which of your systems have an interface and which are run by a person with a spreadsheet.
Then read the second version for two things: whether every row has an owner, and whether the total is a project you want. Both are chief executive questions, and neither needs a line of code read.
Building is genuinely right for some companies, and two situations make it clearly right. The first is when the surrounding machinery is close to what you already sell: a company whose product carries approval flows, an audit ledger and a permissions model has most of the four fifths built and operated, and buying means a second copy of something your team runs well. The second is when nothing leaves the building. An internal system that reads your own documents and answers your own staff needs no outbound rules, no roster of strangers, and no ledger anybody outside will read. That is a smaller and more honest project, and buying is an expensive way to get it. The comparison page sets the two options against each other row by row.
Where the answer is build, three things are worth insisting on, and none constrains how the work is done. Write the invisible parts into the plan as named deliverables with dates, so they are commitments rather than intentions competing with the interesting work. Ask for the authority setting to ship at propose and wait, so the first version asks permission by default and the permission to act is granted deliberately, one specialist at a time. And name the operator before the first line is written: the hardest thing to add later is a person.
Say the last part out loud in the room. A build approved this way is a stronger position than a purchase, because the four fifths end up owned and operated by people who sit in your meetings. The eight questions exist so the plan is one the two of you can both defend in eighteen months, to a board that will ask about the invisible parts long after the demonstration is forgotten.
Before you reply to the outline
One thing to do tonight, before you answer the email. Reply with the eight questions and one sentence: I cannot assess the engineering and I am trying to understand the whole of the job, so tell me what is missing from this list as well.
That last clause is the part that matters. Your chief technology officer will add rows nobody outside your company could have written, because they come from operating your systems rather than from reading about agents. A list that comes back longer than it went out means the two of you are scoping the same job.
A week later you have a scoped project with owners against it, arrived at by the person who will build it. If the answer turns out to be buying after all, the evening before the first demonstration is where that road starts. Whether you approve it is then a question of appetite and calendar, which you have answered a hundred times.
component: null
Asked plainly
What should a CEO ask their own engineering team before approving an AI agent build?
Ask for the parts of the system that never appear in a demonstration, each with an owner and an estimate beside it: the rules that decide what may leave the company, the roster of people it may address, the record of every action and its reason, the step where work waits for a person, the scheduler and its guarantee that a job fires once, and the scored examination run before every change. A team that has built this before answers those faster than the questions about the model. The reply is a scoping conversation, not a test anyone passes or fails.
How can a non-technical CEO judge an internal AI proposal?
By judging coverage rather than engineering. You cannot assess whether an approach is sound, and you can read whether an estimate names the unglamorous parts of the system and puts an owner against each. The reasoning loop is the visible share of a working agent; the guards, the roster, the ledger, the approval step and the standing tests are the larger share, and they are the parts most likely to be missing from an estimate written in good faith.
Is it a bad sign if an engineering team estimates an AI build quickly?
No. A fast estimate for the reasoning part is usually accurate, because that part is genuinely fast and well documented. The signal to look for is which parts the estimate covers. An estimate that prices the loop precisely and treats everything around it as integration is estimating the part everybody can see, which is the ordinary way these projects are sized, by vendors as well as by internal teams.