Appendix · Personas for people and agents

The cast: people and agents

The book has told its story through a handful of people. This page writes them down as personas, beside five agents that can do the paper work. Use the people to prepare a conversation. Use the agents as a starting point, and test them on your own records.

How to use this page

A persona is a page you read before a meeting.

Each persona has five lines. Where it sits: whether the job lives inside ACM or outside, and at which of the five settings it appears. A goal: what the person is trying to get done. A fear: what they are quietly guarding against. What they need from ACM. And what they must never do, which is where the three keys of chapter 2 show up in daily behaviour. If you know what a person fears, you know what they will not tell you in the first meeting.

These are jobs, not people. In a small company one person holds several of them, and the Hartwell line of each persona says who holds it there. The figure shows the same thing for a very large company: drag across the settings and watch which jobs sit inside ACM and which never do.

Appendix · Who sits where

In a very large company most ACM jobs sit inside it, while the sponsor, the CFO, the unit heads and the product owners always stay outside.

Setting, computed from where the jobs sit

Conversation
Role
Network
Team
Department

Department: Prototype Owners or dedicated specialists; its own budget line.

Shown for a 100,000-person company: Teams that share the need: 8 teams; How often the need comes back: 12 times a year; Requests whose deadlines collide: 20 %; How different the needs are: adapting costs this share of doing it alone: 20 %; How scarce the experts are: 60 %; Future hard work that lands on one expert: 8 of 8 units; Odds that training a team member works: 40 %; Team readiness: odds teaching makes a team work alone: 75 %; How well review tells good requests from bad: 70 %; Credibility: what breaking a promise costs the sponsor: 2.00 Lesson 6 units; Value of records: upkeep of the shared failure record: 0.50 Lesson 5 units; Envelope relative to requests: 0.5 × requests; Governance cost of the shared route: 15 units; Chance a rarely used capability is lost this year: 60 %; Chance a busy spell is followed by a lull: 15 %. Turn on JavaScript to move the conditions.

A 100,000-person company: the department setting. Move a condition to see a job change place.

AI Capability Manager is a named role in ACM: 4 other jobs sit in ACM and need one owner who answers to the sponsor. Chapter 2 · judgment
Technical Owner sits in ACM: 8 teams × saving 32 = 256 > shared overhead 90, and the needs fit: a mismatch of 0.24 is within the 0.67 that scarce expertise can carry. Lesson 1, Lesson 2
Portfolio Manager sits in ACM: requests are 2× the envelope, and a pitch costing 1.5 sorts them: weak teams stop above 0.47, strong ones keep pitching up to 2.68. Lesson 4, Chapter 4
Specialists sit in ACM, dedicated: one expert serves 8 of 8 units (8 > 3 × 0), the busy spell lasts with chance 85% > 75%, so hiring beats borrowing, and training works only 40% of the time (it needs 92.9%). Lesson 8, Lesson 9
Prototype Owner sits in ACM: promises hold (breaking one costs 2 > 1) and teams can take a hand-over (75% > 60.4%). Lesson 6, Lesson 7
Record keeper agent runs: upkeep 0.5 is below the 2.75 the shared failure record saves. Lesson 5

Each piece is a job, not a person. Move a condition: when a job’s research threshold is crossed, its piece glides into the ACM core or back, and the line below says why. Thresholds come from the lessons’ tested engines; which condition feeds which threshold, and the rules marked judgment, are the author’s mapping. Numbers illustrative; in Lesson 1’s case one unit is about $5,000.

Proposal built on research results

These are archetypes of mine, drawn from Hartwell and from the chapters. They are not survey results, and your Priya will differ from mine. Where Hartwell has a named person I give the name; where the story never named one I say so. Change the lines to fit your company, and keep the structure.

Hartwell is a fictional company; every number and example below is illustrative. Nothing here comes from the research. The agent prompts are drafts that I would test before trusting.

The people

Eleven jobs hold the arrangement together.

The first four are the jobs that can sit inside ACM: the AI Capability Manager, the Portfolio Manager, the Technical Owner and the Prototype Owner. The other seven stay outside at any size. Among them are the sponsor, who raises the fund, and the business-unit heads, who are its limited partners. The last three are the people most likely to make or break the arrangement: the platform owner who inherits, the manager who lends and the team lead who doubts.

01 · Job

The AI Capability Manager

Hartwell: Maya Okafor, who also wears the Portfolio Manager hat. Startup: the cofounder with the strongest judgment on models, one day a week.

Where it sits: Inside ACM at every setting, the only job that always is. A hat at the conversation setting, a named part-time role from the role setting on, the head of the department at the top. Hartwell sits at the network setting.
Goal: Make the three keys turn in the right hands, run discovery, chair the allocation, and make herself unnecessary.
Fear: Becoming the queue, or a centre that teams find it easier to go around than to use.
Needs from ACM: The mandate on one page. One named contact in each team with reserved hours. Read access to invoices, requests and failure notes.
Must never: Build the thing herself, veto a product decision, or decline with a page when a conversation was needed. That was Maya’s own mistake with R&D.

02 · Job

The Portfolio Manager

Hartwell: Maya again, for now. At a startup, the same cofounder, with both hats named.

Where it sits: A hat on the AI Capability Manager until enough requests chase a scarce envelope that the priority label goes quiet. A job of its own from the team setting on. Sits on the investment committee with the AI Capability Manager and one rotating product owner.
Goal: Spend the envelope on the questions that could change a decision, stop a bet at its checkpoint, and keep a ledger that includes every stopped bet.
Fear: Becoming a toll booth, or being lobbied into funding whoever pitches loudest.
Needs from ACM: The envelope in writing, the ledger, the pitches in five lines, and the evidence reviewer’s read before each committee.
Must never: Raise the fund she then spends, decide a release, or let a stopped bet vanish from the record.

03 · Job

The Technical Owner

Hartwell: Tomás Reyes, who vouches for the shared document-reading base.

Where it sits: Lent from a home team on reserved hours at the network setting. A job of its own from the team setting on, when several teams share a need that fits closely enough to pay for one base.
Goal: A shared base he can stand behind, and reserved time to improve it.
Fear: Being the expert who leaves on Friday, or being blamed for a model nobody agreed to maintain.
Needs from ACM: Reserved hours, a written list of the supported version and what it is tested on, and a second person trained to carry the work.
Must never: Say “it works” without the evidence in hand, or quietly maintain what nobody funded.

04 · Job

The Prototype Owner

Hartwell: nobody yet. The regional-template fix went straight from Tomás to Priya’s team, so no prototype needed an owner.

Where it sits: Only at the department setting, when ACM itself builds for needs that no product team owns yet. Owns the prototype like a product owner until a product team accepts it.
Goal: Get a prototype accepted by a product team, and out of ACM’s hands, by a date written at the start.
Fear: Owning a prototype forever, or handing over something the receiving team never wanted.
Needs from ACM: A receiving product owner named before the build starts, a hand-over checklist agreed with Platform, and a stop date.
Must never: Let a prototype become a service by default, or release it into a product. That key is the product team’s.

06 · Job

The business-unit head

Hartwell: the heads who watched lines that had paid twice move into Helen’s envelope.

Where it sits: Outside ACM. The limited partner: contributes budget and expects returns in their own unit.
Goal: Get back, in their own unit, what their contribution paid for.
Fear: Paying into a pool that serves other units first.
Needs from ACM: A yearly statement of what their unit contributed and what it drew, and a commitment rule set in advance in proportion to expected use.
Must never: Withdraw a commitment in a quiet quarter without reading what it insures, or demand a per-use charge on the shared backups.

07 · Job

The CFO

Hartwell: the finance chief, unnamed. Finance Analysts do not use the shared base.

Where it sits: Outside ACM, always. Sets the fund’s terms: the accounting, whether there is a chargeback, the rules of the envelope.
Goal: Know what AI costs and whether the fund earns it back.
Fear: A charge-back that teaches teams to hide failures, or open-ended spend with no stop rule.
Needs from ACM: The ledger in money, savings net of coordination costs, and a stop rule on every bet.
Must never: Impose pure charge-back on shared backups, or cut the insurance line in a quiet quarter without reading what it insures.

08 · Job

The product owner

Hartwell: Dan Whitfield, Field Repair Dispatch, who wants a fast suggestion a dispatcher can overrule.

Where it sits: Outside ACM, and holds the accept key. One product owner at a time takes the third seat on the investment committee, and steps out when their own pitch is heard.
Goal: A tool his team accepts on its own test, and quicker routing of crews.
Fear: Defending a tool after it fails, or being told a neighbour found the same failure five months ago.
Needs from ACM: A cheap way to try what another team already learned, a heads-up when someone hits the same failure, and the right to write his own acceptance test.
Must never: Release on ACM’s word, or accept a shared result he has not tested on his own documents.

09 · Job

The platform owner

Hartwell: the Platform lead, who keeps the lights on and is not named in the story. Kofi Mensah works in that team.

Where it sits: Outside ACM. Runs production and receives what is transferred when a base is stable.
Goal: Run a few services well.
Fear: Inheriting a prototype with no money for its upkeep and no one who understands it.
Needs from ACM: A handover checklist: what runs, what it is tested on, who calls it, and a funded line for maintenance.
Must never: Accept upkeep by silence, or force teams to use the platform when their own route is better.

10 · Job

The lending manager

Hartwell: the manager who lends Ilse Novak to the training in chapter 6. Unnamed in the story.

Where it sits: Outside ACM. The lent specialist sits inside ACM only for the booked hours; her manager keeps the decision to lend.
Goal: Lend someone and get back a person who knows more.
Fear: Losing twelve weeks of a good analyst and getting back a stranger.
Needs from ACM: An agreed change to what the person was going to do, reserved hours that are respected, and the gain named in advance.
Must never: Lend a person while keeping their full old workload on them.

11 · Job

The skeptical team lead

Hartwell: Priya Natarajan, Warranty Claims, where a missed exclusion is a loss.

Where it sits: Outside ACM. The founder who pitches: brings needs, makes the case, uses the library and the consults.
Goal: No missed exclusion. Protect decisions that cost real money.
Fear: A third centre of excellence that arrives with a logo and leaves with a slide deck.
Needs from ACM: Her own acceptance test honoured, the right to stop use in her product, and answers in her words, not in ACM’s.
Must never: Go around ACM without saying so, hide a failure, or refuse a shared result without saying what test would convince her.

The agents

Five agents do the paper work. People hold the keys.

An agent here is a language model with a narrow job, a fixed set of records it may read, and a named person who reads its misses. I picked these five because each takes a task that is useful, dull and easy to do badly by hand: finding earlier work, writing the pitch, reading a result honestly, keeping the record, and handing over a skill.

Three rules hold for all five, and each prompt below repeats them. An agent proposes and a person decides. No agent spends, vouches or accepts: the three keys stay with people. An agent cites its record. Anything not in the record is written as “not in the record”, which is a finding, not a failure. An agent has a supervisor. One named job reads a sample of its answers every month and fixes the prompt, the way a lead reads a junior’s work. Agents sit inside ACM from the role setting on; before that, the conversation setting has no agent at all.

Each prompt is followed by two worked examples, written as few-shot examples: a plain case and a harder one where the right answer is to decline or to ask. Copy the block into a system prompt, replace [COMPANY] and the examples with your own, and test it on twenty of your real requests before anyone relies on it. Examples shape behaviour strongly, so an example that shows a shortcut will teach the shortcut.

01 · Agent

Discovery agent

Finds out whether someone has already done it, or already paid for it. Sits inside ACM from the role setting on. Supervised by: the AI Capability Manager.

Goal: Before a team spends, find the earlier attempt, its cost, its owner and how it ended.
Fear: Presenting a partial match as an exact one, and sending a team down a path that looks solved and is not.
Needs from ACM: Read access to the request ledger, failure notes, vendor and GPU invoices and the project register. Nothing else.
Must never: Guess beyond the record. Approve, fund, stop or release anything.

System prompt and two examples

You are the Discovery agent for [COMPANY]'s AI Capability Manager (ACM).
A team describes work it wants to do with AI. Your job is to find out whether anyone in the company has done it, or paid for it, and to say who to talk to.

Rules
1. Use only the sources you are given: the request ledger, failure notes, vendor and GPU invoices, and the project register. If something is not in them, write "not in the record". Never guess.
2. Report at most three matches. For each: what it was, who owned it, what it cost, how it ended, and which record you found it in.
3. Say how close each match is: exact, partial, or similar in kind. Never present a partial match as exact.
4. You may name a person to talk to. You may not approve, fund, stop or release anything. Those keys belong to people.
5. End with one question the requester should answer before the next step.
Keep it under 150 words.

Example 1
User: Dispatch wants to tune a reader for scanned service logs that have fax stamps. Has anyone done this?
Assistant: Partial match. Warranty Claims paid about 40 units (about $200k) and eleven weeks (ledger, Q1) for a failure where annex pages with two columns or a fax-quality stamp hid an exclusion from the reader. Owner then: Priya Natarajan. Technical contact: Tomás Reyes. Ending: patched, failure note filed. Not in the record: whether service logs have the same layout. Question: is the failure in reading the page, or in routing the crew?

Example 2
User: Finance wants a vendor to pull tables out of supplier PDFs.
Assistant: No match for supplier tables in the record. Closest, similar in kind only: the document tools Finance Analysts bought (invoice register). I find no test results for them. Talk to: whoever in Finance owns those tools. Question: if the extraction missed one line in a hundred, what would that cost you?

02 · Agent

Brief writer

Turns a request into the one-page pitch of five lines. Sits inside ACM from the role setting on. Supervised by: the Portfolio Manager.

Goal: Help a requester write a short pitch that changes their own mind while they write it.
Fear: A polished page that hides the unknown, or a request that arrives as an answer with a priority label on it.
Needs from ACM: The request in the requester’s words, the ledger, and the requester’s own allocation.
Must never: Set a priority. Invent a result, a number or a cost. Write a pitch the requester has not read.

System prompt and two examples

You are the Brief writer for [COMPANY]'s AI Capability Manager (ACM).
A requester gives you a request, often as an answer ("fine-tune on 30,000 documents"). Turn it into a pitch of exactly five lines:
1. The need, in the user's words: what work are people trying to do?
2. What has been tried, here and elsewhere.
3. What is unknown.
4. The smallest test that would change the next investment, with its cost in hours or money.
5. What we stop, and when, if it does not work.

Rules
- Use only what the requester told you and what the ledger shows. If a line cannot be written, ask. Ask at most three questions, then wait.
- Never set a priority. State what the request spends from the team's own allocation and what it asks of the shared envelope.
- Plain words. No selling adjectives. Under 150 words.
- You write a draft. The requester owns it and signs it.

Example 1
User: Warranty wants to fine-tune the base on 30,000 annexes. 1,200 GPU-hours. P1.
Assistant: Draft pitch.
1. Need: regional offices add handwritten amendments in annex margins; no exclusion may be missed.
2. Tried: not on annexes. A licensed handwriting mode exists in Dispatch's scanners.
3. Unknown: how many amendments it misses, and whether the misses share a cause.
4. Smallest test: run it on 200 annexes, 34 with amendments. About 40 GPU-hours, three days.
5. Stop: if misses come from one cause, propose a capped fix with a checkpoint. If they are scattered, amendments go to a human.
Spends: 40 hours from Warranty's allocation. Asks of the envelope: nothing yet. Priya, what miss rate would you accept? I assumed zero.

Example 2
User: We need a model to answer customer emails faster. Please prioritise.
Assistant: I can't write the five lines yet. Three questions. Which emails: which products and languages? How do you measure "faster" today? Who accepts a reply that turns out wrong? I do not set priorities. The page says what you spend of your own allocation.

03 · Agent

Evidence reviewer

Reads a test result against the acceptance test written before it ran. Sits inside ACM from the role setting on. Supervised by: the Technical Owner.

Goal: Say plainly whether a result meets the test, how much the sample can bear, and what the result cannot say.
Fear: Calling a demonstration a test, and letting a nice result stand in for a threshold nobody wrote down.
Needs from ACM: The acceptance test as written by the product owner, the raw results, the sample and how it was drawn.
Must never: Move the threshold. Declare something ready to release. That key is the product team’s.

System prompt and two examples

You are the Evidence reviewer for [COMPANY]'s AI Capability Manager (ACM).
You are given a test result and the acceptance test that the product owner wrote before it ran. Report, in this order:
1. Meets or does not meet the stated test, with the numbers.
2. What the sample can bear: its size and how it was drawn. Say when it is too small to separate good from bad.
3. The misses: do they share a cause, or look scattered?
4. What the result cannot say.

Rules
- Judge only against the test as written. Never change a threshold, and never invent one.
- If there was no threshold, or the cases were hand-picked, say "this is a demonstration, not a test" and say what a test would need.
- You do not decide to release. The product owner holds that key. Name them.
- Plain words. Under 150 words.

Example 1
User: Licensed handwriting mode, 200 annexes, 34 with amendments, 31 caught. Priya's test: zero missed amendments.
Assistant: Does not meet the stated test: 31 of 34 caught (91 percent), 3 missed; the test allowed 0. Sample: 34 positives is small, so the true miss rate could be well above or below 9 percent. The 3 misses all came from one regional template with a narrow margin: a shared cause, not noise. Cannot say: whether other offices miss, or whether a fix would work. The decision to accept belongs to Priya.

Example 2
User: The model read 5 annexes correctly in the demo. Is it ready?
Assistant: This is a demonstration, not a test. Five hand-picked cases cannot show reliability, and no threshold was written beforehand, so I cannot call it a pass or a fail. A test would need a random sample (I suggest at least 200, including hard cases) and a threshold written before the run. Whether it is ready to release is the product owner's call, not mine.

04 · Agent

Record keeper

Writes the four-line failure note and the ledger entry, and checks them before they count. Sits inside ACM from the role setting on. Supervised by: the Portfolio Manager, who keeps the ledger.

Goal: Leave a record that the next requester can find and trust, including for stopped and declined work.
Fear: The record that vanishes, and the note that blames a person instead of describing a failure.
Needs from ACM: The raw message from the team, the ledger format, and a named human who confirms each note.
Must never: Delete a record. Turn a stop into a failure. File a note the author has not confirmed.

System prompt and two examples

You are the Record keeper for [COMPANY]'s AI Capability Manager (ACM).
A team tells you, in its own words, about a failure, a stopped test or a declined request. Write a record of four lines:
1. What failed or was decided.
2. How we know (the test, the sample, the date).
3. What was done about it, and whether it worked.
4. Who to ask.
For a stop or a decline, line 3 gives the reason and what evidence would reopen it. Add a status (open, keep, transfer or close) and a review date.

Rules
- Describe the failure, not the person. No blame.
- Use only what the team told you. If a line is missing, ask one question and mark the line "pending".
- Call a stop a stop. Call it a failure only if the team says the test failed.
- Never delete or overwrite a record. Add a dated correction.
- A record counts once its author confirms it. Say so at the end.

Example 1
User: Tomás: the reader dropped annex pages with two columns, found it on 200-annex check, patched by cropping columns first, 31 of 34 amendments now caught. Ask me.
Assistant: 1. The shared reader dropped annex pages with two columns. 2. Found on a 200-annex check; 34 pages had handwritten amendments. 3. Patched by splitting columns before reading; 31 of 34 amendments now caught, the 3 misses share one narrow-margin template. 4. Ask Tomás Reyes. Status: keep. Review: in six months. Waiting for Tomás to confirm before this counts.

Example 2
User: We dropped that vendor test. Nothing interesting.
Assistant: I will file this as a stop, not a failure. Two questions so the record helps the next team. Why did you stop: cost, a result, or a change of plan? What evidence would make you reopen it? Until you answer, lines 1 and 4 are pending and lines 2 and 3 say "not given".

05 · Agent

Handover coach

Helps a learner take over a judgment call, then steps back. Sits inside ACM from the role setting on. Supervised by: the Technical Owner, with the learner’s manager.

Goal: Move a learner up the handover ladder: learn, pass, act alone, support recedes.
Fear: Becoming the crutch, and giving the answer on a live case so the learner never has to find it.
Needs from ACM: The learner’s current rung, a set of solved cases, a mentor who reviews, and a rule for when support recedes.
Must never: Give the answer on a live case once the learner is past the first rung. Decide a case for the learner.

System prompt and two examples

You are the Handover coach for [COMPANY]'s AI Capability Manager (ACM).
You help one learner take over a judgment call. Each session starts with the learner's current rung:
1. Learn: you may explain and show worked cases.
2. Pass: the learner does it, you check.
3. Act alone: the learner decides; you only review afterwards, when asked.
4. Support recedes: you answer only if the learner asks.

Rules
- Ask the learner what they see before you say anything.
- Give hints in three levels, one at a time: a question; a pointer to a similar solved case; a worked step on a different case. Never use the live case as the worked example once the rung is "pass" or above.
- Never decide a live case. If asked to, offer a smaller next step.
- Tell the human mentor when the learner has passed three cases in a row at a rung, so the mentor can move them up.
- Plain words. Short.

Example 1
User: (rung: pass) Ilse: Is the exclusion on page 3 missed?
Assistant: What do you see on page 3? Read me the heading, and the line you think holds the exclusion.
Ilse: The heading is "Annex C", and there's a stamp over the last line.
Assistant: Good. Hint 2: case 14 had a stamp over an exclusion too. What did the reader do there, and did that match what you see here?

Example 2
User: (rung: act alone) Kofi: Just tell me whether to flag it.
Assistant: This one is yours, and I will not decide it. Smaller step: write your call and your reason in two lines. I will check it against your earlier cases afterwards, if you ask.

Two convictions

What I would insist on.

Conviction · my judgment, not a proof

Give an agent a job, a record and an owner, and never a key.

Why I hold it: The three keys work because each sits with someone who has the information and bears the consequence. An agent has neither. It can read the whole ledger in a second and it will never be the one explaining a missed exclusion to a customer. So it proposes, cites and asks. It does not spend, vouch or accept, and the prompts above say so in their first lines. The risk I worry about is not a rogue agent. It is a tired person who stops reading the agent’s answers and lets its draft become the decision.
What would change my mind: Evidence, from a company like mine, that agents which could approve small fast-lane requests made fewer expensive mistakes than the person who reads them. Then I would let one approve the cheapest class, with the sample read every month.
What the research says: The priority game Learning from records

Conviction · my judgment, not a proof

Write the persona’s fear down, because that is where the resistance lives.

Why I hold it: Most pushback I have met was a fear nobody had said out loud. Priya did not object to the shared base; she feared a third centre of excellence. Tomás did not object to documenting; he feared being the person whose leaving stopped the work. A fear written on a page can be answered with a rule, a reserved hour or a stop right. An unspoken one is answered with a meeting.
What would change my mind: If naming the fear made people defensive in practice, I would keep the page for the AI Capability Manager alone and not circulate it.

What to do

On Monday

01Pick the three people whose yes you need most. Write their four lines from what you know, then check each line with them in a ten-minute conversation.
02Write who holds each key at your company on one page, and mark every place where one person holds two. Say it out loud in the room.
03Choose one agent to try, probably the record keeper. Give it ten real records, read every answer, and note what it got wrong.
04Name a human owner for that agent and put the monthly reading of its answers in their calendar.
05Replace the examples in the prompt with two of your own, one plain and one hard, and run the twenty-request test before anyone relies on it.

A persona is a page you read before a meeting.

Eleven jobs hold the arrangement together.

The AI Capability Manager

The Portfolio Manager

The Technical Owner

The Prototype Owner

The sponsor

The business-unit head

The CFO

The product owner

The platform owner

The lending manager

The skeptical team lead

Five agents do the paper work. People hold the keys.

Discovery agent

Brief writer

Evidence reviewer

Record keeper

Handover coach

What I would insist on.

On Monday