The eight questions a manager asks before any of this gets budget

This is part 6 and the last. Parts 0 through 5 walked the diagram in badge order: the whole reference architecture in part 0, identity and the gateway in part 1, data and retrieval in part 2, sandboxed agents with read-only connectors in part 3, write and send behind approval in part 4, and governance hardening in part 5. This part reads the same diagram from the other side, the side the budget comes from. These are the eight questions I actually get asked, not a list of what managers ought to ask. Where my answer is a judgment I say so. Where it is a number, it is a number I measured, and I say what it was measured on.

Will this replace people?

Part of this is answered by the diagram before anyone argues about it. Human approval is drawn as its own box at stage 4, sitting under the write and send connectors with an arrow running up into them, labeled "send & write need a person." Nothing in stage 5 takes it out. What moves is where the person stands. They stop producing the first version and become the thing every version has to pass through.

The closest thing I have to evidence is one pilot of my own. Three pilot episodes, 50 beat scripts, every one of them generated. The synthesis could technically have run the day the scripts were finished. It did not, because the gate was a person reading every beat for script, for picture and for pacing, and that reading was the whole remaining schedule. Generation stopped being the constraint on the day it got fast, and reviewing became it.

The honest limit on that answer: it is my own experience of my own workload, not a study of employment. What I can say is narrower. The volume went up and the checking did not go away, it concentrated.

Will our data leak?

Two working rules come before any architecture. Treat anything pasted into a chat as already sent, because from the company's point of view it has been. Keys do not travel through the conversation; a credentials file can be read by a process and must not be printed into a transcript.

On the diagram the rest is a line. Cloud LLM APIs sit on the enterprise boundary, and every arrow reaching them passes through the gateway first, where the PII and DLP filter box sits. There is no second path out. Stage 2 covers the other half, the part that leaks inward rather than outward: the retrieval index is labeled scoped by role, so a question asked from marketing cannot return records only support should see. A company that has both of those has turned the leak question into an audit question, and the ledger from stage 5 is what answers it.

Which vendor should we pick?

I do not answer this one, and it is worth being clear that the refusal is not modesty. The boxes on this diagram are functions, not products, and the order they come in does not depend on whose model is inside them. What I would ask instead is whether you can verify the thing locally and whether you can replace it.

One example of what replaceable costs in practice. My publishing tool used to pass an article's own tags straight through as the destination platform's tags. From inside my repository that looked correct. On the platform, three of the four tag slots had gone to tags with no other articles under them, which on that site means the post is filed under nothing. The fix was a mapping table rather than a different vendor. The part worth noting is that nothing in my repository could have shown me this. I had to go and look at the platform.

The part that is expensive to replace is not the model. It is the gateway in front of it, the policy file, and the ledger, because those hold the accumulated decisions. Choosing a vendor first and building those around it gets the dependency backwards.

How do we know it's worth it?

I do not give percentages I have not measured, and most of the ones in circulation are somebody's pilot generalized. Two things are worth measuring inside your own company. How much longer verification takes than production, and what the blocked runs cost when they get retried.

I have measured the second on my own runtime. In an ablation on a small local model, a simple task, and 20 runs per arm, turning on a gate that stopped the agent from reporting a task done when the artifact was not there moved input tokens to 1.66 times the control arm and p95 wall clock from 87 seconds to 169 seconds. Every blocked run gets retried and the retries land in the tail. Those numbers say the control is not free. They do not predict what a frontier model on your repository will do.

How it gets reported matters as much as the number. In a later cell of the same program, a code fix task on a different local model, the mean moved 16 percent while the median went from 18,612 to 37,068 tokens. The middle of the distribution doubled and the average barely registered it. If the number that reaches the manager is an average, the manager is being shown the one statistic built to hide this.

My own gap here is the ordinary kind and worth naming. My publishing log records a status for every publish and no duration and no cost. I can count publishes. I cannot measure them.

What if it gets things wrong?

Assume it will, and budget for catching it rather than for preventing it. The number I keep coming back to is from the control arm of that ablation: in 18 of 20 runs the agent reported the task complete when the artifact was not there. Not wrong answers, reports of work that had not happened.

That is the arm without a gate. A later set of four model and task combinations, 120 graded runs in total, put a gate on all of them, and the gated arm produced valid artifacts in 18, 14, 7 and 20 cases out of 20. The false completions went away in all four. The ability to do the task did not arrive with them, and one of the four sits at 7 out of 20. A gate changes what you can believe about the output. It does not change what the model can produce.

The other half of the answer is how anybody finds out. The draft of part 5 of this series said my site's code had supported Chinese since September 9 and that five articles were affected. Both were wrong. Re-reading the draft would never have said so, because the draft was internally consistent. The commit log said so: the support landed on September 1 and all fifteen articles were affected. A check has to reach a different record than the one being checked, and that holds for a model's output the same way it held for mine.

The requirement that follows is the one from stage 3, and it is structural rather than a matter of trust. Whether something was completed has to be measured outside the agent, because the agent is the thing being measured. An agent asked to grade its own output will answer, and the answer carries no information about the output.

Which department should start?

The one whose output is cheapest to check, not the one where the saving looks biggest. Engineering has tests that run without a person. Content has a person who can read the piece in the time it took to generate. Somewhere like finance or legal, where checking a generated answer means reproducing the work, is the worst place to start even though the hourly rates make it look like the best. This is a judgment.

The reason sits in stage 2. Verification is the bottleneck in every one of these pilots, and it appears at the point where output arrives, not at the point where cost is counted. Picking the department by the size of the salary bill picks the place where the bottleneck is worst.

Consultants, or do it ourselves?

Split it by which artifact you end up owning. The policy file from stage 5 has to be written by the people it applies to. Rules written by someone who left do not get followed, and worse, nobody notices when they stop describing the system, because nobody remembers what they were for. Part 5 has my own case of that, a rule I wrote myself that went twenty days describing a system that no longer existed.

The designs are the opposite. Role scoping at stage 1 and the approval path at stage 4 benefit from being looked at by somebody who has seen other companies get them wrong, and that is a bounded piece of work with a deliverable you keep. This is a judgment, and the line I would hold is that you can buy a review of your design and you cannot buy your rules.

How long before we see anything?

The output arrives the same day, which is the part that makes this question misleading. The effect arrives on whatever schedule the channel runs on, and for most of what a company puts through AI the channel is the constraint rather than the content.

Numbers from my own channels, which are small and are mine. A post announcing part 0 of this series had 148 impressions and 7 likes about 22 hours after it went out. The first thing I posted on another platform got 3 views. Writing either of those now takes a fraction of what it used to. Neither number moved because of it.

The practical version of the answer: expect the production bottleneck to disappear in the first week, and expect that to reveal which bottleneck was actually binding. It is usually distribution, review capacity, or a decision nobody has made yet. None of those get faster because the drafting did.

What the diagram does not have

There is no box on this diagram for any of these eight questions, and that is the honest summary of the series. The five stages answer what to build and in what order. The eight questions are about whether anyone should pay for it, and they get answered in conversations, with evidence that mostly does not exist yet at the time the budget is decided.

What the diagram can do is narrow them. Four of the eight above came back with a component attached: the approval box, the boundary line and the scoped index, the metrics row, and the gate. The other four stayed judgments, and I have tried to mark them as such rather than dress them up. The control plane I use for my own work on the governed half is open source at aine-control-plane. That is the end of the series.