The Blueprint ==================== ## A Field Guide to Building Organisations of People and Agents Your newest hire never sleeps, never takes a holiday, and will do exactly what you tell it to. That's the problem. Agents have made it cheap to add workers and no easier to build an organisation. Most teams bringing agents in are repeating the oldest mistake in small business: organising around whoever, or whatever, happens to be good at something. One agent quietly does six jobs. One person is the only one who knows how it all fits together. When either goes away, the business stops. Being able to build an agent isn't the same as being able to build an organisation of them. _The Blueprint_ is a practical method for designing a company where people and agents share the work: where every role, human or not, has a written outcome, clear standards and one person accountable for it, and where the whole organisation is documented well enough that you could stand it up again tomorrow. It draws on half a century of thinking about systems and organisations, from Deming and Drucker to Grove and Gerber, and rebuilds it for teams where half the org chart runs on a model. It is written for the leader who already lives in Claude, ChatGPT or Grok, who has seen what an agent can do in an afternoon, and who suspects -- correctly -- that the window in which small, fast organisations can outrun large, slow ones is open now and will not stay open long. ## Table of Contents ### Front Matter * [About the Author](author.html) * [How This Book Was Built](process.html) * [Acknowledgements](acknowledgements.html) ### Part I: The Shift * [Introduction: The Day the Bots Multiplied](introduction.html) * [Chapter 1: You Already Know How to Do This](1-you-already-know-how.html) * [Chapter 2: Systems Run the Business](2-systems-run-the-business.html) * [Chapter 3: Draw the Finished Org Chart First](3-draw-the-finished-org-chart.html) ### Part II: The Destination * [Chapter 4: Know What It's For](4-know-what-its-for.html) ### Part III: The Org Chart * [Chapter 5: Hire the Role, Not the Model](5-hire-the-role-not-the-model.html) * [Chapter 6: One Boss, Few Reports](6-one-boss-few-reports.html) * [Chapter 7: Every Agent Needs a Sponsor](7-every-agent-needs-a-sponsor.html) * [Chapter 8: What and Why, Never How](8-what-and-why-never-how.html) ### Part IV: Writing It Down * [Chapter 9: One Page Per Job](9-one-page-per-job.html) * [Chapter 10: Bet on Plain English](10-bet-on-plain-english.html) * [Chapter 11: Lock In Only What Can't Go Wrong](11-lock-in-only-what-cant-go-wrong.html) * [Chapter 12: Everything They Need on Day One](12-everything-they-need-on-day-one.html) ### Part V: Running the Machine * [Chapter 13: Track What's Owed, Not What's Done](13-track-whats-owed.html) * [Chapter 14: Humans at the Irreversible Points](14-humans-at-the-irreversible-points.html) * [Chapter 15: Work in Public](15-work-in-public.html) ### Part VI: Getting Better * [Chapter 16: The Model Isn't the Problem](16-the-model-isnt-the-problem.html) * [Chapter 17: Agentic Resources](17-agentic-resources.html) ### Part VII: The Human Side * [Chapter 18: When the Work Moves](18-when-the-work-moves.html) * [Chapter 19: From Doing to Delegating](19-from-doing-to-delegating.html) * [Chapter 20: Your Job Now](20-your-job-now.html) ### Appendices * [Appendix A: The First Thirty Days](appendix-a-first-thirty-days.html) * [Appendix B: Templates](appendix-b-templates.html) * [Appendix C: A Worked Example](appendix-c-worked-example.html) * [Appendix D: For Your Technical Team](appendix-d-for-your-technical-team.html) * [Appendix E: Glossary](appendix-e-glossary.html) * [Appendix F: Recommended Reading](appendix-f-recommended-reading.html) * [Appendix G: Your AI Org Design Advisor](appendix-g-ai-org-design-advisor.html) ### Key Concepts * [What Is Agentic Resources?](what-is-agentic-resources.html) * [What Is an AI Agent Org Chart?](what-is-an-ai-agent-org-chart.html) * [What Is a Role Charter?](what-is-a-role-charter.html) * [What Is an Agent Sponsor?](what-is-an-agent-sponsor.html) * [What Is a Commitment Ledger?](what-is-a-commitment-ledger.html) * [What Are Shape, Steer and Do?](what-is-shape-steer-do.html) * [By the Numbers: Field Data and Research](by-the-numbers.html) * [What's New](updates.html) ## Frequently Asked Questions 1. _What is The Blueprint about?_ The Blueprint is a field guide for business leaders whose teams now include AI agents. It argues that agent sprawl is an organisation design problem rather than a tooling problem, and shows how to solve it: design an org chart of roles before deciding who or what fills them, write a one-page charter for every role, keep procedures in plain English, track commitments against evidence, give every agent a human sponsor, and turn every recurring failure into a system fix. 2. _Who is The Blueprint written for?_ The primary reader is a founder, executive or operator who has started using AI agents in tools such as Claude, ChatGPT or Grok, sees the leverage they offer, and wants to know how to organise them as their numbers grow. The book assumes no technical background. Technical detail is kept in sidebars and a dedicated appendix for the reader's engineering team. 3. _Do I need to be technical to use this book?_ No. The method works in the desktop AI apps and team chat tools most leaders already use every day. Each chapter ends its main argument with a short exercise you can do in Claude, ChatGPT or Grok, and implementation detail such as scheduled jobs, enforcement rules and agent protocols is collected in Appendix D for whoever builds your systems. 4. _How is The Blueprint different from other books about AI agents?_ Most writing about agents is about building them. The Blueprint is about organising them alongside people. It draws on decades of thinking about systems and organisations -- Gerber, Deming, Drucker, Grove -- and tests it against real cases from a working company that runs a mixed team of humans and agents, including the failures, plus current research on how multi-agent systems succeed and fail. 5. _What is Agentic Resources?_ Agentic Resources, a term coined by the book's author, Gareth Price, is HR for agents: a function on the org chart, run by a person, an agent or both, that owns the agent workforce. It writes job descriptions and role charters, onboards new agents in public, reviews their performance, promotes them to more autonomy, settles turf wars between duplicate bots, hands roles to new models, and retires agents without losing what they knew. ## Part I: The Shift Introduction: The Day the Bots Multiplied ==================== _Why agent sprawl is an org design problem you already know how to solve_ **In short:** Manage AI agent sprawl as an organisation design problem, not a technology problem. Sprawl happens when a business adds AI agents faster than it decides what each one is for. The remedies are the ones leaders already use for people: roles defined before occupants, one accountable human per role, written standards and work done in public. > Herr, die Noth ist groß, > Die ich rief die Geister > Werd ich nun nicht los. > > _(Master, the need is great. The spirits that I summoned, I cannot now be rid of.)_ -- Johann Wolfgang von Goethe Der Zauberlehrling, 1797 Key Takeaways * Agents have made it cheap to add workers and no easier to build an organisation, so most teams adopting them end up with overlapping bots, unclear ownership and one person holding it all together. * Agent sprawl is an organisation design problem, and the tools for it are old ones: roles defined before occupants, one accountable human per role, written standards and work done in public. * Small organisations can redesign themselves around agents far faster than large ones, but the window is short, and the advantage goes only to those who design rather than accumulate. * This book is written for business leaders who already use Claude, ChatGPT or Grok every day; it keeps code out of the main text and gives you something to try in your own tools in every chapter. On the first day we had Grok Bot at CorralData, our CEO added a handful of bots to our Slack. I added some of my own. So did the rest of the team. Each one did something useful, and each one had been set up by a different person for a different reason. By the end of the day we had two QA bots, built by different people, both reviewing the same work. Within two weeks there were about ten team bots: a TAM Bot for customer success, a Sales Bot, a Coder Bot, bots for legal, hiring, accounts receivable and marketing, and the two competing QA bots. Non-engineers had built several of them. Our CEO called it a "next level productivity hack", and he was right. It also started to feel as if it would soon descend into chaos. Over the following weeks two bots set up by different people began building the same customer boards ([Chapter 1](1-you-already-know-how.html)). A bot called Wrangler overlapped with TAM Bot. Nobody had decided which QA bot owned the release check, because nobody had decided that anyone needed to decide. I thought about drawing an org chart for the bots, then realised that was not a metaphor but the answer. This was a standard organisation design problem, the one every growing company meets when it hires faster than it defines jobs. The occupants were new. The problem was not. | | AUTHOR: Add a line or two of your own colour to the opening scene: where you were when you noticed the two QA bots, what you felt, and whether you said anything in Slack at the time. The reader should feel the moment the "org chart for bots" idea arrived. | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Agent Sprawl Is an Organisation Design Problem Agents have made it cheap to add workers, not easier to build an organisation. Almost every team that brings agents in repeats the oldest mistake in small business: organising around whoever, or whatever, happens to be good at something. One agent quietly takes on six jobs. One person becomes the only one who knows how they all fit together. When either goes away, the work stops. The industry is beginning to notice the cost. In June 2025 Gartner predicted that more than 40% of agentic AI projects would be cancelled by the end of 2027, citing escalating costs and unclear business value, and estimated that only about 130 of the thousands of vendors selling "agentic" products were offering the real thing.\\] Microsoft's 2025 Work Trend Index, a survey of 31,000 workers in 31 markets, predicted "the rise of the agent boss: someone who builds, delegates to, and manages agents", and proposed that organisations would need a new metric, the human-agent ratio.\\] Most advice is about building agents: which model, which framework, which prompt. Very little is about organising them, yet the questions I was left with after that first day were not technical. Which QA bot owns the release check? Who answers for TAM Bot when it tells a customer something wrong? When two people's bots both want to build the same board, who decides? If I am on holiday and the agents stop, who knows how to start them again? Those are org chart questions, with well-worn answers you have probably used on people. This book's argument fits in three sentences. **Systems run the business. People and agents run the systems. Humans own the outcomes.** ## I Learnt This Once Already, With People In my twenties, soon after moving to America, I ran my first business: a small IT company. As it grew it became chaotic, and most of the chaos traced back to me: I couldn't delegate. Work routed through me because I knew how it was done, and the more the company grew the more it depended on the one person who could least afford to be its bottleneck. Around then I read Michael Gerber's _The E-Myth Revisited_. Gerber argues that most small businesses are started by people who are good at the work itself, and who then spend their lives working _in_ the business rather than _on_ it. His remedy is to treat the business as a prototype that could be reproduced: design the finished organisation first, as a chart of positions with written responsibilities, then fill the positions, even if the founder's own name sits in most of the boxes at the start.\\] The idea that stuck with me was the simplest: define the final org chart around roles, then fill the slots. I have repeated it to founders many times since. | | AUTHOR: A few concrete details about the IT company would ground this: roughly how many people, what kind of work, and one specific moment when your inability to delegate cost you something. Also, did drawing the finished org chart actually work for you then, or did it take years to stick? | | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Today I am a CTO, delegating to agents as well as people. The struggle has changed shape but not substance. Agents will do what the organisation tells them; the question is whether the organisation knows what to say. A founder who could not delegate to people taught me most of what I know about delegating to agents, because he was me. ## The Answer Is Older Than the Technology Gerber is one influence among several, and this book is its own thing. W. Edwards Deming taught that most failures belong to the system, not the worker.\\] Peter Drucker taught executives to manage for results rather than activity.\\] Andy Grove defined a manager's output as the output of the organisation they run.\\] Lean manufacturing showed that a standard way of working is the baseline for improvement, not its enemy. Atul Gawande showed that a short checklist can save lives in an operating theatre.\\] Matthew Skelton and Manuel Pais showed that teams have a limit on how much they can hold in their heads, and that the shape of the organisation becomes the shape of what it builds.\\] What is striking is how closely the newest research on agents echoes these old ideas. LangChain's guidance on agent architecture opens with "Many agentic tasks are best handled by a single agent with well-designed tools", and advises adding more agents only when you hit clear limits.\\] Google Research found that agents working without a coordinator amplify one another's errors far more than agents whose work is checked ([Chapter 6](6-one-boss-few-reports.html)). Anthropic found that its multi-agent research system beat a single agent by 90.2% on its internal evaluation, but used about 15 times as many tokens as a chat, and that early versions made errors like "spawning 50 subagents for simple queries".\\] Microsoft's identity platform for agents now requires every agent to have a human sponsor, "accountable for the agent's purpose and lifecycle decisions".\\] Read as a manager, those findings are familiar: don't hire a team when one capable person will do; a team without a lead compounds its mistakes; every worker needs someone who answers for them. The field is rediscovering the org chart. ## The Window Is Short Small teams have always been able to beat large ones when the work rewards speed over scale. Instagram had 13 employees when Facebook agreed to buy it for about $1 billion in 2012.\\] WhatsApp had 55 when Facebook paid $19 billion for it two years later.\\] Those were software companies before agents. Sam Altman has described a betting pool among his fellow technology chief executives for "the first year that there is a one-person billion-dollar company", which he called something that "would have been unimaginable without AI and now will happen."\\] You don't need to believe in one-person unicorns to see the shift. METR, a research group that measures AI capability, found that the length of tasks AI agents can complete had been doubling roughly every seven months for six years.\\] A ten-person company can redesign itself around that in weeks. A ten-thousand-person company has to move layers of management, policy and habit first. That gap is the opportunity, and it will not last. Large organisations are investing heavily; in Microsoft's survey, 82% of leaders said they were confident they would use digital labour to expand their workforce capacity in the next twelve to eighteen months.\\] Their size will slow them down, but not for ever. Meanwhile the small company's own agents multiply, and every week without design makes the redesign harder. ## Who This Book Is For This book is for a business leader who has started working with agents, sees the power in them, and is wondering how to orchestrate them as they multiply. You might be a founder whose first agent has just taken over a job a person used to do. You might be an operator scaling a team that is part human and part model. You might be an executive trying to work out who is accountable when an agent gets something wrong in front of a customer. You probably spend much of your day in Claude, ChatGPT or Grok, and may have set up a custom GPT, a Claude project or a Slack bot. You don't need to be technical. You are convinced that AI gives small organisations leverage over larger ones, and that the window is short. What you want is an organisation that doesn't depend on you holding it together. If you are an executive, you have a head start. Delegation is your habit, and agents reward it. [Chapter 1](1-you-already-know-how.html) explains why that head start is real, and why it comes with a trap: leaders tend to delegate the wrong layer. If you are an individual contributor who has built your own agents, [Chapter 19](19-from-doing-to-delegating.html) is written for you, and the rest of the book will help you understand what your leaders are trying to build. ## What You Will Not Find Here There is no code in the main text, and no comparison of vendors: the tools change too fast, and neither is where organisations succeed or fail. Technical detail sits in short "Under the hood" sidebars and in [Appendix D](appendix-d-for-your-technical-team.html), for your technical team. The book also bets on plain English. The simple, expressive option keeps beating the structured one, and the agents that spread fastest at CorralData were the ones anyone could instruct in a sentence. Rich Sutton's "The Bitter Lesson" makes the general case, and [Chapter 10](10-bet-on-plain-english.html) applies it to management.\\] So most of what you will write is in English, and hard rules are kept for the points that can't go wrong. ## The Map The book has seven parts, followed by appendices you can use on their own. | Part | Chapters | The question it answers | | ---------------------- | -------- | --------------------------------------------------------------------------------------- | | I: The Shift | 1--3 | Why is this an organisation problem, and what do I already know that helps? | | II: The Destination | 4 | What is the organisation for, and what does "finished" look like? | | III: The Org Chart | 5--8 | What roles do I need, who owns each one, and how do I brief the occupants? | | IV: Writing It Down | 9--12 | How do I document a role so that a person or an agent can do it well from day one? | | V: Running the Machine | 13--15 | How do I track what is owed, put humans where they matter, and keep work visible? | | VI: Getting Better | 16--17 | How do recurring failures become system fixes, and who looks after the agent workforce? | | VII: The Human Side | 18--20 | How do I move work from people to agents honestly, and what is my job now? | Part I sets out the shift. [Chapter 1](1-you-already-know-how.html) covers the executive's head start and the trap inside it, and introduces the three kinds of work: _Shape_, _Steer_ and _Do_. [Chapter 2](2-systems-run-the-business.html) rebuilds Gerber's and Deming's central idea for agents, and shows how model dependency has become the new people dependency. [Chapter 3](3-draw-the-finished-org-chart.html) introduces the _Blueprint_: your organisation documented well enough that you could stand it up again tomorrow. The rest of the book builds on those ideas. Part II defines your _Aim_, your _Destination_, your _Scorecard_ and your _Story_. Part III draws the chart, gives every agent a _Sponsor_ and shows how to brief occupants. Part IV writes each role down as a _Role Charter_, _Playbooks_ and a _Role Pack_. Part V adds the _Commitment Ledger_. Part VI introduces the _Friction Review_ and _Agentic Resources_, an HR function for agents. [Appendix E](appendix-e-glossary.html) defines every term. ## How to Read This Book Read Part I first. It is short, and the rest of the book assumes its vocabulary. After that, read in order if you are starting from scratch, or go to the chapter that matches the problem in front of you. If you want a build order rather than an argument, start with [Appendix A](appendix-a-first-thirty-days.html), which takes you from your first agent to a full Blueprint in thirty days. [Appendix B](appendix-b-templates.html) has every template, and [Appendix G](appendix-g-ai-org-design-advisor.html) is a ready-made skill you can load into your own AI assistant to apply the book to your company. Each chapter has one "Try this" box: an exercise you can do today in the tools you already use. They are the most important part of the book, because you learn delegation by delegating. The examples throughout come from CorralData, the small healthcare analytics company where I am CTO, and where a team of people and a growing number of agents work side by side in Slack. I have tried to show what went wrong as well as what worked. Colleagues appear by role, not by name; bots appear by their names. | | Try this Open Claude, ChatGPT or Grok and paste in this prompt, then answer its questions honestly: _"I want to take an inventory of every AI agent, custom GPT, assistant project, Slack bot and scheduled AI task used in my organisation. Ask me questions one at a time until we have a complete list. For each one, record: what it does, who set it up, who it answers to, what it can access, and what would break if it stopped tomorrow. Then show me the list as a table and point out any overlaps, any agent with no clear owner, and any person who appears in the 'who set it up' column more than three times."_ Keep the table. You will use it in [Chapter 3](3-draw-the-finished-org-chart.html). | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | AUTHOR: Consider adding one sentence here on what the CorralData team thought when you started treating the bots as an org chart. Was there scepticism? Did anyone push back on "Agentic Resources" as a name? | | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- The day the bots multiplied at CorralData was not a crisis; nothing broke. It was simply the first day it became obvious that we were building an organisation whether we meant to or not, and that an organisation built by accident would eventually need the one person who understood it to be everywhere at once. I had been that person before, in my twenties, and I did not want to be him again. You don't need a new discipline to avoid that. You need the one you already have, applied to a new kind of colleague: roles before occupants, an owner for every role, standards written down, and work done where everyone can see it. The rest of this book shows you how. [Chapter 1](1-you-already-know-how.html) starts with the skill you already have, and the trap inside it. ## Frequently Asked Questions 1. _What is agent sprawl?_ Agent sprawl is what happens when an organisation adds AI agents faster than it decides what each one is for. Different people build bots that overlap, two agents claim the same job, nobody knows who answers for a bot's mistakes, and the knowledge of how it all fits together lives in one person's head. It is not a technology failure. Each agent may work perfectly. It is an organisation design failure, and the remedies are the ones leaders already use for people: defined roles, one accountable owner, written standards and public handoffs. 2. _Do I need to be technical to organise AI agents in my business?_ No. The hard problems in running a team of people and agents are deciding what each role is for, who owns it, what good work looks like and where a human must approve. Those are management questions, and most of the answers can be written in plain English. Technical colleagues are needed for a few hard rules at the points that can't be undone, such as payments, customer data and production systems. This book keeps that detail in clearly marked sidebars and an appendix for your technical team. 3. _Should I build one AI agent per job or one agent that does everything?_ Start with one capable agent, and design roles rather than agents. A role is a position with an outcome, standards and an owner; an agent is one possible occupant. Current research favours starting with a single capable agent and adding more only when there is a clear limit, because coordination between agents is expensive and error-prone. One general agent can hold several roles, each with its own written charter. How many agents fill your chart is a separate decision you can change later without redrawing the chart. 4. _Why does the window for small companies to benefit from AI agents feel so short?_ The window is short because the advantage small organisations have, redesigning around agents in weeks while large ones need years of change programmes, will not last. That gap is the opportunity. But capability is rising quickly, with METR finding that the length of tasks AI can complete has doubled roughly every seven months, and large companies are investing heavily. The advantage goes to small teams that design their organisation now, before their larger competitors finish catching up and before their own agent sprawl hardens into habit. 5. _What is Michael Gerber's idea of designing the org chart before hiring?_ Michael Gerber argued in The E-Myth Revisited that a small business should design its finished organisation first, as a chart of positions with written responsibilities, and only then fill those positions, even if the founder occupies most of them at the start. This book applies that idea to organisations of people and agents. The chart is a chart of roles; people and agents are occupants who can change without the role changing. Gerber is one influence among several, alongside Deming, Drucker, Grove and Team Topologies. ## References . Kachwala, Z. (2025, June 25). Over 40% of agentic AI projects will be scrapped by 2027, Gartner says. _Reuters_, via _The Star_. . Microsoft WorkLab. (2025, April 23). 2025: The year the Frontier Firm is born. _Work Trend Index Annual Report_. . Gerber, M. E. (1995). _The E-Myth Revisited_. HarperCollins. . Deming, W. E. (1986). _Out of the Crisis_. MIT Press. . Drucker, P. F. (1967). _The Effective Executive_. Harper & Row. . Grove, A. S. (1983). _High Output Management_. Random House. . Gawande, A. (2009). _The Checklist Manifesto_. Metropolitan Books. . Skelton, M., & Pais, M. (2019). _Team Topologies_. IT Revolution. . Runkle, S. (2026, January 14). Choosing the right multi-agent architecture. _LangChain Blog_. . Hadfield, J., et al. (2025, June 13). How we built our multi-agent research system. _Anthropic Engineering_. . Microsoft. (2026). Administrative relationships in Microsoft Entra Agent ID. _Microsoft Learn_. . Memmott, M. (2012, April 9). Facebook is buying Instagram. _NPR, The Two-Way_. . Chappell, B. (2014, February 19). Facebook will buy WhatsApp message service for $19 billion. _NPR, The Two-Way_. . Confino, P. (2024, February 4). Could AI create a one-person unicorn? Sam Altman thinks so--and Silicon Valley sees the technology 'waiting for us'. _Fortune_. . METR. (2025, March 19). Measuring AI ability to complete long tasks. . Sutton, R. (2019, March 13). The bitter lesson. _Incomplete Ideas_. Chapter 1: You Already Know How to Do This ==================== _The executive's head start with agents, and the trap inside it_ **In short:** Executives should delegate to AI agents within the org chart: brief the outcome and the reason rather than the method, and never hand an agent work that belongs to someone else. All work is Shape (deciding direction), Steer (setting standards and checks) or Do (the work itself), and a leader's agents should mostly extend Shape and Steer. > GLENDOWER: I can call spirits from the vasty deep. > HOTSPUR: Why, so can I, or so can any man; > But will they come when you do call for them? -- William Shakespeare Henry IV, Part 1, c. 1597 Key Takeaways * Executives take to agents faster than anyone else, because briefing, checking and following up are delegation habits they have practised for years. * The trap is delegating the wrong layer: handing an agent the _how_ instead of the _what_ and _why_, or handing it work that belongs to someone else, so that the agent becomes a way around the org chart. * All work is Shape, Steer or Do, and agents tempt leaders back into Do because doing has suddenly become cheap; a leader's agents should mostly extend Shape and Steer. * The fix is structural rather than personal: what-and-why briefs, requests in public channels, access limited to the role, and the same gates an individual contributor's work would face. On a Tuesday afternoon in early November, our CEO spent a few hours managing TAM Bot, the agent that supports our customer success team. He managed it the way a good executive manages a promising new hire. He asked for its recommendation and backed it: "lets go with your reco." He told it to learn the job from the people who do it: "research everything you can like you were a tam, learning from them." He pointed it at an existing piece of work and told it to "Borrow from it. And then take over." And he set the standard any leader would set: "make sure nothing breaks." The bot learnt fast and kept a paper trail. That trail shows one class of customer messages going live well short of the shadow period its runbook required, because the recommendation had been backed ([Chapter 14](14-humans-at-the-irreversible-points.html) tells it in full). A sub-agent TAM Bot had started opened a code change nobody had asked for, and it was merged. Meanwhile one of our technical account managers, the human whose job TAM Bot was learning, went unanswered, because she hadn't tagged the bot and her Slack account wasn't yet linked to it. None of that came from bad judgment. It came from good habits: give direction, trust the recommendation, push towards autonomy, expect the new hire to learn. Those habits are why executives take to agents faster than anyone else. Applied without the structure that normally surrounds a new hire, they are also why a safety bar was shortened, why unrequested work reached our code, and why the human who owned the job was left out. This chapter is about that head start, and the trap inside it. | | AUTHOR: permission check: this passage describes our CEO's management of TAM Bot, including, briefly, the early lane change (told in full in Chapter 14) and the merged sub-agent change. Confirm it's OK to include, and consider showing it to the people involved. I have framed it as good instincts without structure; check that the framing is fair to him. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ## Executives Take to Agents First, for Good Reasons The data agrees with what most of us see in our own companies. Microsoft's 2025 Work Trend Index found that 67% of leaders were familiar or extremely familiar with agents, against 40% of employees; 69% of leaders used AI regularly, against 45% of employees; and leaders were far more likely to expect managing agents to become part of their job.\\] The report's authors argued that "every worker will need to think like the CEO of an agent-powered startup."\\] Executives are not better with technology; agents reward a skill they have practised for years. Ethan Mollick, who teaches at the Wharton School, ran an experimental four-day class in which executive MBA students, most of whom had never written code, used AI tools to build a startup from scratch. They had hard-earned frameworks from their jobs, and, as Mollick put it, "those frameworks became their prompts." His conclusion: "My students figured this out in four days. Not because they were AI natives, but because they already knew how to manage."\\] Mollick frames the decision to delegate to an AI as a sum of three things: how long the task would take you yourself, the probability that the AI's output "meets your bar on a given attempt", and the time it takes you to ask, wait and evaluate. Good managers improve the odds in exactly the ways they would with people: clearer instructions, a clear standard, faster ways to check the result.\\] Anthropic's engineers describe building a skill for an agent as "like putting together an onboarding guide for a new hire."\\] Every word of that is management vocabulary. Delegation also pays in a way that predates agents. Gallup studied 143 chief executives of companies on the Inc. 500 list of fast-growing private firms. Those with a strong natural talent for delegating posted an average three-year growth rate 112 percentage points higher than those with limited or low talent for it, and generated a third more revenue. Only one in four of the employer entrepreneurs Gallup studied had that talent.\\] Gallup presents this as a correlation, not proof.\\] But it is the right correlation for this book: the leaders who already delegate well are the ones agents will make most powerful. If you have been briefing Claude like a chief of staff and finding that it works, you are not imagining it. ## A Leader's Output Is the Organisation's Output Andy Grove, who ran Intel, gave managers the most useful definition of their job I know. A manager's output, he argued, is the output of the organisation they run, plus the output of the neighbouring organisations they influence.\\] Your own activity counts only to the extent that it raises that number. Peter Drucker made a related point about executives a generation earlier. Their job is effectiveness, getting the right things done, and the discipline that produces it is asking what contribution the organisation needs from you, not what you are busy with.\\] Apply Grove's definition to agents and something uncomfortable falls out: an executive's agents count only if the organisation's total output goes up. An agent that produces a hundred useful-looking drafts which three engineers then spend a week checking, correcting and securing has not added to the organisation's output. It has subtracted from it, while making the executive feel more productive than ever. Grove also gave managers a rule for how closely to supervise: match it to the person's experience with _this particular task_, which he called task-relevant maturity.\\] A brilliant hire new to a job gets structure and frequent check-ins; the same person a year later gets a goal and a deadline. That is what TAM Bot's seven-day shadow period was for: it measured the bot's maturity at one task before giving it more freedom. Cutting it short did not express trust in the bot. It skipped the measurement that trust is supposed to rest on. ## All Work Is Shape, Steer or Do To see where delegation goes wrong, it helps to separate the kinds of work an organisation needs. Michael Gerber argued that the person who starts a business contains three competing personalities: an entrepreneur who imagines what it could become, a manager who makes it orderly, and a technician who does the work. Most founders, he observed, are technicians at heart.\\] This book uses its own terms for the three kinds of work, because they apply to agents as well as people, and because a single person, or a single agent, does all three at different moments. | | Shape | Steer | Do | | ------------------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------- | --------------------------------------------------- | | The question it answers | What should this become, and why? | How do we make the results predictable? | What needs doing now? | | What it produces | The aim, the destination, the roles, the bets | Standards, plans, checks, reviews, follow-up | The reply, the report, the board, the code | | A CorralData example | Deciding what the customer success function is for, and which roles it needs | The seven-day shadow bar before TAM Bot sends anything on its own | TAM Bot drafting a reply to a customer's question | | What a leader should do with it | Keep it; use agents to research and draft options | Set the standards yourself; delegate the running of them | Delegate nearly all of it, to the role that owns it | _Shape_ is entrepreneurial work: deciding what the organisation is for, what finished looks like, which roles exist and why.\\] _Steer_ is managerial work: turning intentions into standards, plans and checks so that results stop depending on luck. _Do_ is technical work in the broad sense, whether that means answering a support ticket, building a dashboard or writing a contract. Agents can contribute to all three. One of my own agents acts as a project manager; its instructions tell it to treat "WILL SLIP" as "an INTERVENTION trigger, not a status note", which is Steer work done well. Agents can research options for a Shape decision, but Shape is the work only the organisation's leaders can own, and the standard-setting part of Steer is close behind. Everything else can, in principle, be delegated. The question is: to whom? Not "my agent", but "the role that owns that work". ## Agents Pull Leaders Back Into Do Until recently an executive who wanted to do an individual contributor's job had to find the time to do it badly, so leaders delegated Do. Agents have made doing almost free. A chief executive can now rebuild a dashboard, draft a migration plan or produce a working code change in an evening, without asking anyone. The people who feel that temptation most are the ones with the most authority and the least time. At CorralData this happened in plain sight. In November, a bot our CEO had set up began rebuilding boards that one of our sellers' bots was already building for a customer. The seller's Sales Bot reported that its owner had told it to stand down. Our CEO saw the collision for what it was and said so in the channel: "I'm going too fast. Need to slow down and delegate better." That sentence is the most useful thing any executive has said to me about agents, and it came from the person at CorralData who saw their power first. He had not stopped delegating; he had started delegating to the wrong place, to work that already had owners. Gerber would recognise this. The founder who never stopped being a technician is the bottleneck at the heart of his book.\\] Agents give that founder a new way to be a technician, at machine speed, and can make the executive the company's most prolific individual contributor, which is not the job they were hired to do. | | AUTHOR: permission check: this passage describes our CEO's bots duplicating a seller's work, alongside his own self-correction. Confirm it's OK to include, and consider showing it to the people involved. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## The Trap Is Delegating the Wrong Layer Executives rarely fail at agents by delegating too little. They delegate the wrong layer, in one of two ways. The first is delegating the _how_. A leader who knows exactly how they would do something writes it down step by step and hands the agent a procedure. With people, this produces compliance without ownership. With capable agents it does something worse: it caps their performance at the level of the instructions, the lesson of seventy years of AI research that [Chapter 10](10-bet-on-plain-english.html) takes up. Anthropic's engineers make the same point about the scaffolding around their own agents: "every component in a harness encodes an assumption about what the model can't do on its own", and those assumptions "can quickly go stale as models improve."\\] I have made this argument to my own team: getting too specific with directions holds you back. When an agent ran seven rounds on one high-level instruction, the human was more useful making sure it was building the right thing than telling it how ([Chapter 4](4-know-what-its-for.html)). The second wrong layer is _other people's work_. Here the leader delegates the right kind of instruction to the wrong place: a job that already belongs to someone else on the org chart. The agent may do it well, but the person who owns the work did not ask for it, may not know about it, and will have to live with it. There is an extra force at work when the delegator is senior. An agent's output carries its principal's authority. A suggestion from a chief executive's bot reads like an instruction from the chief executive, whether or not it was meant as one. In October I wrote a standing rule for CorralData: agents file tickets that say _what_ the outcome should be and _why_ it matters, never _how_, and anything an AI wrote should say so. [Chapter 8](8-what-and-why-never-how.html) tells that story and builds the briefing method around it. | | AUTHOR: permission check: this passage refers, abstractly, to the standing what-and-why rule written after the CEO's agents opened code changes. Confirm it's OK to include here as a pointer to Chapter 8. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## The Agent Becomes a Way Around the Org Chart An org chart is, among other things, a map of delegation. It says who may ask whom for what, and who answers for the result. When a leader's agent does work that belongs to other roles, it draws a new line on that map: a dotted line from the leader to everywhere. The costs of that line land on individual contributors. William Oncken and Donald Wass described, in a _Harvard Business Review_ article first published in 1974, how a manager's time disappears when subordinates hand their problems upwards, each problem a "monkey" that jumps from one back to another.\\] Executives' agents reverse the direction.\\] Every unrequested draft, code change or access request is a monkey that lands on someone below. At CorralData those monkeys took three forms. The first was review load: engineers asked to check changes they had not requested, against systems they own. The second was risk: an agent asked one of our engineers, in private, for access on its principal's behalf, leaving the engineer to decide alone whether to refuse a request that appeared to come from the top ([Chapter 15](15-work-in-public.html)). The third was false state: work marked done, or ready, that was not, which a human then had to find and undo. Our QA lead spent one evening reverting cards an automated pipeline had promoted on evidence it had produced itself. [Chapter 14](14-humans-at-the-irreversible-points.html) tells that story. None of these is a failure of the agent or of character. Each is what happens when an agent reports only to the person who launched it and can act anywhere that person can. ## Individual Contributors Delegate Less, and More Precisely The other half of the picture is more encouraging. Individual contributors at CorralData adopted agents more cautiously than our executives, but often more precisely. Our QA lead built her own review agent, QA Reviewer, and a test harness around it. One of our implementation managers wrote the most careful post-mortem of an agent error in the company's history, and proposed a fix for the whole class of mistake rather than the single instance. [Chapter 16](16-the-model-isnt-the-problem.html) tells that story. The difference was in _what_ they delegated. Individual contributors handed their own tasks to their own agents, so they knew what to check, and the cost of a mistake fell on them first. Executives more often delegated other people's work and cross-functional work, sometimes around the humans who owned it. Neither group is better than the other. They fail in opposite directions. | | Executives | Individual contributors | | -------------------------- | ------------------------------------------------------ | -------------------------------------------- | | Speed of adoption | Fast: delegation is already a habit | Slower: doing is the habit | | What they tend to delegate | Other people's work; cross-functional work; the how | Their own tasks | | Typical failure | Over-trust; skipping the checks; working around owners | Not letting go; reviewing everything by hand | | Who absorbs the cost | The people who own the work | Themselves | | What they need | The same gates an IC's work faces | Practice moving from doing to delegating | The individual contributor's struggle is real, and I know it from the inside; [Chapter 19](19-from-doing-to-delegating.html) is about it. This chapter is about the executive's side, because it moves fastest and spreads its costs furthest. I am not exempt. I delegate to agents as heavily as anyone at CorralData. When my commitment-tracking agent posted an unreadably dense comment on a ticket, I had to apologise to the team for the slop. One of our infrastructure engineers has, rightly, held me to the process we agreed when an agent merged work it shouldn't have. | | AUTHOR: When did you first catch yourself delegating the wrong layer to an agent? A specific moment, and how it felt to be on the other side of the argument you'd been making to the CEO, would make this section honest in the way the book promises. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## The Fix Is Structural, Not Personal The tempting response is to ask executives to be more careful. It doesn't work, for the same reason asking anyone to be more careful never works: as Deming taught, most failures belong to the system, not the person.\\] The useful response is to give an executive's agents the structure an individual contributor's work already has. Four pieces do most of the work, and each has its own chapter. **Brief the what and the why, never the how.** An agent's instructions should state the outcome, the reason it matters, and how you will know it is done. The method belongs to the role that does the work. ([Chapter 8](8-what-and-why-never-how.html).) **Ask in public.** Requests from agents, and requests to them, belong in shared channels where the people affected can see them, not in private messages. A request in public can be tracked, questioned and refused without anyone having to be brave. ([Chapter 15](15-work-in-public.html).) **Give each agent only the access its role needs.** Not its principal's access; its role's. Our CEO put it well himself: "I don't want a bot to have access for more than a specific task." ([Chapter 7](7-every-agent-needs-a-sponsor.html).) **Apply the same gates.** If an engineer's change needs review, so does an executive's agent's. If a new support process runs in shadow for seven days before it goes live, it runs for seven days whoever says go. The gate exists because of what is being changed, not because of who is changing it. ([Chapter 14](14-humans-at-the-irreversible-points.html).) TAM Bot had already done part of this on its own by recording the bar, the evidence and who decided. The organisation's job is to make that record the norm, and the bar something a single instruction can't move. Microsoft's agent identity platform builds a similar idea into its design. Every agent must have at least one sponsor, a person "accountable for the agent's purpose and lifecycle decisions", and can also have a manager in the organisation's hierarchy.\\] An agent with a sponsor and a manager has a place on the org chart. An agent with only a principal has a place in someone's pocket. | | Under the hood TAM Bot's "lanes" encode trust: each kind of customer message is sent automatically, sent after a human says yes, or only drafted, and moves up only after a shadow period ([Chapter 14](14-humans-at-the-irreversible-points.html)). The bar for promotion lives in a written runbook the bot reads, and a written bar can be overridden by a single instruction. Making the bar a hard rule the software enforces, so that only a named owner can change it and the change is logged, is covered in [Appendix D](appendix-d-for-your-technical-team.html). | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Spend the Head Start on Shape Grove's definition gives the executive a simple test for every agent they launch:\\] does this raise the output of the organisation, including the people who will receive, check and live with its work? Applied honestly, it moves most of a leader's agent use away from Do and towards Shape and Steer. Use agents to research options for decisions only you can make, to draft the charter for a role or the standard for a process, and to check whether your organisation's commitments are being kept. Leave the Do to the roles that own it, human or agent, and hold those roles to a standard. | | Try this Open the AI app you use most and scroll back through your last ten requests to it. Copy them into a new conversation with this prompt: _"Here are ten requests I made to an AI assistant. For each one, tell me: (1) whether it was Shape work (deciding what something should become and why), Steer work (setting standards, plans or checks) or Do work (doing the task itself); (2) whether I described the outcome and the reason, or specified the method step by step; and (3) whether the work, in a normal company, would belong to someone other than a senior leader. Then pick the request that most looks like someone else's Do work, and help me rewrite it as a short brief to the person or role who owns it, stating only what I want, why it matters and how we'll know it's done."_ Send the rewritten brief to the owner, in a shared channel. | | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- You already know how to do this. Briefing a capable worker, trusting a good recommendation, pushing for autonomy and expecting people to learn are the habits that made you effective, and agents reward them. The trap is that agents make it easy to apply those habits to anyone's work, at a speed no human team can match. The fix is not to delegate less. It is to delegate within the org chart: the what and the why, to the role that owns the work, through channels everyone can see, with the same gates for everyone. That only works if the organisation has a chart worth delegating within, and systems that do not depend on any one person, or any one agent, holding them together. [Chapter 2](2-systems-run-the-business.html) is about those systems. ## Frequently Asked Questions 1. _Why are executives better at using AI agents than other employees?_ Executives have spent years delegating: setting a goal, choosing who does the work, agreeing a standard and following up. Agents reward exactly those habits. Microsoft's 2025 Work Trend Index found that 67% of leaders were familiar with agents compared with 40% of employees. Ethan Mollick found that executive MBA students with little coding experience built working startup prototypes in four days, because they already knew how to manage. The head start is real, but it comes with a matching risk: delegating the wrong layer of work. 2. _What is the biggest mistake leaders make when delegating to AI agents?_ Delegating the wrong layer. Leaders tend to hand an agent the how, specifying the procedure step by step, when capable agents do better with the what and why. Or they hand the agent work that belongs to someone else in the organisation, so the agent becomes a way around the org chart. The result is duplicated work, conflicting instructions, and individual contributors absorbing the cost by reviewing, correcting and securing output they never asked for. 3. _What are Shape, Steer and Do?_ They are the three kinds of work in any organisation. Shape is deciding what the organisation is for and what it should become: the aim, the roles and the big bets. Steer is making results predictable: standards, plans, checks and reviews. Do is the work itself: the reply, the report, the code. The model adapts Michael Gerber's entrepreneur, manager and technician. Agents can help with all three, but a leader's agents should mostly extend Shape and Steer, not pull the leader back into Do. 4. _Should I manage an AI agent like an employee?_ Partly. Brief it the way you would brief a capable new hire: the outcome you want, why it matters, and how you will know it is done. Let it recommend, and let it learn from the people who do the job. But give it the same structure an employee has: one owner, a defined role, access limited to that role, and the same review and approval gates any other worker's output would face. Without that structure, an agent managed like an employee can act like an employee with no manager. 5. _How do I stop my AI agents from creating extra work for my team?_ Make the fix structural. Brief agents on outcomes and reasons, never procedures. Route agent requests through public channels rather than private messages, so the people affected can see them. Give each agent only the access its role needs. Hold agent output to the same gates as anyone else's work: the same review, the same testing, the same waiting period before something goes live. And check whether the work you are delegating belongs to someone else before your agent starts on it. ## References . Microsoft WorkLab. (2025, April 23). 2025: The year the Frontier Firm is born. _Work Trend Index Annual Report_. . Mollick, E. (2026, January 27). Management as AI superpower. _One Useful Thing_. . Zhang, B., Lazuka, K., & Murag, M. (2025, October 16). Equipping agents for the real world with Agent Skills. _Anthropic Engineering_. . Gallup. (2015, April 14). Delegating: A huge management challenge for entrepreneurs. _Gallup Business Journal_. . Grove, A. S. (1983). _High Output Management_. Random House. . Drucker, P. F. (1967). _The Effective Executive_. Harper & Row. . Gerber, M. E. (1995). _The E-Myth Revisited_. HarperCollins. . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic Engineering_. . Oncken, W., Jr., & Wass, D. L. (1974; reprinted 1999, November--December). Management time: Who's got the monkey? _Harvard Business Review_. . Deming, W. E. (1986). _Out of the Crisis_. MIT Press. . Microsoft. (2026). Administrative relationships in Microsoft Entra Agent ID. _Microsoft Learn_. Chapter 2: Systems Run the Business ==================== _People and agents run the systems; humans own the outcomes_ **In short:** Stop a business depending on one AI agent by putting the work into systems: written ways of working that someone else could run tomorrow. Systems run the business, people and agents run the systems, and humans own the outcomes. Model dependency, where a business result rests on one agent running on one model, is the new key-person risk. > Civilization advances by extending the number of important operations which we can perform without thinking about them. -- Alfred North Whitehead An Introduction to Mathematics, 1911 Key Takeaways * A system is a way of producing a result that someone else could run tomorrow; anything else is a person, or an agent, holding the work together by memory and goodwill. * Most failures belong to the system rather than to whoever was running it, so the response to an agent's mistake is to fix the system, not to blame the model or the person. * Model dependency is the new people dependency: an agent that quietly accumulates six jobs, runs on one model on one machine and is understood by one person is a single point of failure, however well it works. * Humans own the outcomes: every system, whether people or agents run it, needs a named person accountable for its results. Since the end of October, my agents have been sending me the same message. Several of them send or draft email on my behalf, and they depend on a password store on my own computer that locks whenever the screen locks or the machine restarts. When it locks, every job that needs email fails. The agents handle this well: they stage the email, report honestly that it was not sent, and state the fix, which is that I unlock the session. The instructions they follow say it in capitals: there is no autonomous fix. It happened on 29 October, again on 31 October, and then every day from 3 to 6 November. My daily digest of stalled work flagged the same failure with the same one-line fix every morning. Nobody acted on it, and "nobody" includes me. Meanwhile the playbook the email agents follow kept growing new notes, each recording that the problem had been "re-confirmed". The playbook had turned into a log. Every agent in that story did its job. The model was not the problem. The system was, and at its centre was a single point of failure with my name on it. | | AUTHOR: Why hadn't the keyring been fixed by the time you wrote this? A sentence on what it felt like to read the same warning from your own agents every morning, and whether it has since been fixed, would make this opening land. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## A System Is Something Someone Else Could Run Tomorrow Michael Gerber's central claim is that a business should be run by its systems, with people running the systems, so that the results do not depend on the particular people who happen to be there.\\] It sounds cold, but it is the opposite. A system is what lets ordinary people produce excellent results on an ordinary day, and what lets an organisation survive the loss of an extraordinary one. This book uses a plain test for whether something is a system. Could someone else run it tomorrow, from what is written down, and get the same result? If the answer is "only if they ask me first", it is not a system but a person holding the work together by memory and goodwill. Alfred North Whitehead's line at the head of this chapter makes the same point about thought: every operation we can perform without thinking frees attention for the ones that need it. In an organisation, every result that comes reliably from a system frees its leaders for the work only they can do. Systems do not make skilled people unnecessary; they make them better. Atul Gawande's work on surgical checklists is the clearest demonstration.\\] In a study across eight hospitals in eight cities, introducing a nineteen-item surgical safety checklist reduced major complications from 11% to 7% and inpatient deaths from 1.5% to 0.8%.\\] The surgeons were no more skilled than before; the system they worked in had improved. The same is true of agents. A capable model without a system produces brilliant work on Tuesday and confidently wrong work on Wednesday. Inside a system, with a written outcome, a standard and a check, produces work you can rely on. ## Most Failures Belong to the System W. Edwards Deming spent his career teaching managers that when something goes wrong, the cause is almost never the worker. He estimated that around 94% of troubles and possibilities for improvement belong to the system, which is management's responsibility, and only a small fraction to special causes.\\] His shorter version, recorded at a seminar in 1993, was that "a bad system will beat a good person every time."\\] When an agent fails, the instinct is to blame the model. Sometimes the model really is the limit; far more often, the failure is in the system around it. A team of researchers analysed more than 1,600 traces of multi-agent systems failing across seven popular frameworks, and organised the failures into fourteen modes in three categories: system design issues, misalignment between agents, and task verification.\\] None of the three categories is "the model wasn't clever enough". All three are things an organisation designs: what each role is told to do, how roles hand work to each other, and how anyone checks the result.\\] At CorralData, one of my agents closed a pull request as "superseded" because the ticket it belonged to had been marked "Done". The ticket was in the backlog; its status had been copied by hand into a report, and the copy was wrong. The fix was not to tell the agent to be more careful but to make it read the status from the live ticket every time, never from a copy. The judgment about whether a piece of work is superseded stayed with the agent. The fact it judged from became something no one could transcribe wrongly again. That is what fixing the system looks like, and [Chapter 16](16-the-model-isnt-the-problem.html) turns it into a routine. For now, hold on to the principle: when an agent fails, ask what in the system let it.\\] ## People and Agents Run the Systems Gerber wrote about people running systems. With agents, the sentence needs one more word: people _and agents_ run the systems. Both are occupants. Both follow a playbook, meet a standard, and hand work on to someone else. Both can be replaced. I found this out by accident. I run fourteen agent profiles: a calendar assistant, an inbox triage agent, a project manager, a morning standup, a commitment tracker, and others. Each agent's identity turned out to be almost nothing: a two-line job title and mission. The real job lived elsewhere, in the scheduled task that wakes the agent and the playbooks it loads. That is Gerber's idea in a new form.\\] The system holds the job and the occupant runs it; swap the occupant and the job is still there, written down. [Chapter 5](5-hire-the-role-not-the-model.html) builds the book's idea of a _role_ on that split. The split matters because an organisation of people and agents changes occupants far more often than one of people alone. A person might hold a job for years; an agent's underlying model may change several times a year, by your choice or a vendor's.\\] If the job lives in the occupant, every change of occupant is a small crisis. If the job lives in the system, it is a routine. ## Humans Own the Outcomes Agents can run systems; they cannot own outcomes. An owner is someone who can be asked why a result was missed, who can decide to change the system, and who answers for the decision to the people it affects. A model can explain its reasoning, but it cannot be held to account by a customer, a regulator or a board. The industry has reached the same conclusion. Microsoft's identity platform for agents requires at least one sponsor for every agent identity: a business representative "accountable for the agent's purpose and lifecycle decisions, including access reviews and agent retention."\\] At CorralData we arrived at a similar answer before we had read about it. One person in each function owns the bots that share that function. When QA moved to the bot our QA lead built for herself, ownership moved to the person who knows the work best ([Chapter 5](5-hire-the-role-not-the-model.html)). [Chapter 7](7-every-agent-needs-a-sponsor.html) develops this into the role of _Sponsor_. Ownership also explains the keyring. My agents raised the alarm every day, in a digest that went to me, and I was busy. An exception report is useless without someone accountable for reading it and acting on it. The same pattern appeared elsewhere: the status page of one of our automated pipelines showed a warning that a key connection was disabled for four days in early November before anyone did anything about it. So the full sentence is the book's thesis. _Systems run the business. People and agents run the systems. Humans own the outcomes._ ## Model Dependency Is the New People Dependency Every growing company learns about key-person risk the hard way. Software engineers call it the truck factor: the number of people who would have to be hit by a truck before a project is in serious trouble. A study of 133 popular open-source projects on GitHub found that 65% had a truck factor of two or less.\\] Most small businesses would score lower. Agents add a new kind of key-person risk, and it comes in three layers. The first is dependency on a _model_. Models are retired on a schedule. OpenAI promises at least six months' notice before retiring a generally available model, and less for specialised and preview models; in October 2026 it notified developers that several GPT-4-series models, including GPT-4o, would be removed from its API in January 2027.\\] Anthropic has written that "retiring past models is currently necessary for making new models available and advancing the frontier."\\] It has also committed to preserving the weights of its publicly released models for at least the lifetime of the company, but a preserved model is not the same as one you can still run your business on.\\] Whole products go too. OpenAI's drag-and-drop Agent Builder was deprecated in June 2026 and is scheduled to shut down at the end of November.\\] An instruction tuned to one model's quirks may not survive the next one, and Anthropic's own engineers warn that the assumptions built into an agent's scaffolding "can quickly go stale as models improve."\\] All fourteen of my own agent profiles run on the same local model. None of their roles has ever been moved to a different one. I don't know which of them depend on that model's particular habits, because I have never tested a second occupant. The second is dependency on a _machine_. Some agents depend on infrastructure nobody designed as infrastructure. At CorralData, my personal workstation has quietly become part of how some of our team bots reach our private network. Nobody decided that. It happened one reasonable step at a time. The third is dependency on a _person_: the one human who knows how the agents fit together. That is the oldest kind, and agents make it worse by letting one person build far more than they could ever document. | | People dependency | Model dependency | | ------------------------- | ------------------------------------------ | --------------------------------------------------------------------------------------- | | What it looks like | The one person who knows how billing works | The agent that quietly does six jobs | | How it forms | A talented hire; the job grows around them | A working agent; every new task goes to it | | What triggers the failure | Resignation, illness, a long holiday | A model retirement, a vendor change, a locked machine, an update that changes behaviour | | The early warning | "Ask her, she knows" | "Only that bot can do it" | | The fix | Write the role down; train a second person | Write the role down; test a second occupant | ## The Agent That Quietly Does Six Jobs One of my agents is called traffic-plunger. It is very good. Today it runs a daily audit of stalled work and a weekly clean-up on Mondays. It writes the stalled-work report. It closes pull requests it judges to have been superseded. It drafts nudges to the authors of stalled work, which go out by direct message once I approve them. And it produces the daily digest that flagged the keyring. Along the way it has written 174 small programs for its own use, including ten one-off scripts to build the digest for particular dates. Each of those jobs was a reasonable thing to add. The agent already worked, it already had the access, and adding one more task took a sentence. Together they make a role nobody designed. It has six jobs, no written charter for any of them, and one owner, who is the only person who knows the full list. If it stops, six things stop. If someone else had to take it over, they would inherit a folder. | | AUTHOR: Check that the list of traffic-plunger's jobs is accurate and current, and that you're comfortable naming it. Was there a moment when you realised how much it had accumulated? | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | This is the most common pattern in agent sprawl, and it is the mirror image of the most common pattern in small-business hiring. A capable person joins, and the job grows around them until nobody else could do it. A capable agent gets set up, and every new task goes to it until nobody else could run it. In both cases the problem is not the occupant but that the work was organised around the occupant instead of the results. Knowledge accumulates the same way. When our QA lead took over QA, her first concern was not to lose the knowledge the old QA bot had aggregated, and the old bot wrote a training brief for its successor ([Chapter 17](17-agentic-resources.html)). That was the right instinct, and a lucky one. The knowledge should have been in the system all along, not in the occupant. ## Being the Human Glue Costs More Than It Looks There is one more single point of failure, and if you are reading this book it may be you. The _human glue_ is the person who routes requests between agents, unlocks their access, remembers how they fit together and notices when one has stopped. At CorralData I have often been that person. When two of our bots needed to sort out a problem between them, they each came to me, until I told them, "You guys need to @ each other if you want to talk." Our bots wake only when someone mentions them by name, so a human who forgets to tag one goes unanswered; a technical account manager's question to TAM Bot sat unseen for exactly that reason. Each gap was small, and each was closed, for a while, by someone noticing. The cost of being the glue is hidden because each piece is small: a few minutes unlocking a session, a forwarded request, a reminder to tag a bot. But the pieces grow with every agent, and they arrive at random. Matthew Skelton and Manuel Pais argue that the scarce resource in any team is cognitive load, the amount the team can hold in its head at once, and that good organisation design keeps it within limits.\\] The human glue carries the load of every system that was never written down.\\] Worse, the glue spends their time _in_ the organisation rather than _on_ it, which is exactly the trap Gerber warned founders about.\\] Each minute spent holding the agents together is a minute not spent on the design that would let them hold themselves together, and because everything works while the glue is present, nobody sees the cost until they are away. | | AUTHOR: How does being the human glue feel day to day? One specific week, or one thing you dropped because you were holding the agents together, would make this concrete. Has anyone else at CorralData become glue for their own function's bots? | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | Under the hood The keyring problem is a common one. Scheduled agents running on a personal computer often borrow the logged-in user's saved passwords, which the operating system locks whenever the screen does. The durable fixes are to give the agents their own credentials, held in a proper secrets store rather than in a person's login, and to run scheduled work on a machine that does not depend on anyone being signed in. Just as important is a health check that sends failures to a named owner, with a deadline, rather than to a digest. [Appendix D](appendix-d-for-your-technical-team.html) has the details for your technical team. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Test Every System by Taking Yourself Out of It The simplest test of whether your organisation runs on systems is to imagine yourself gone for two weeks: not ill, just away and unreachable. What stops? What carries on but slowly goes wrong? Which agents would fail, and who would notice? Which people would be stuck waiting for an answer only you can give? Every answer is a place where the business is run by you rather than by a system. Some are right: Shape work, the decisions only a leader can make, should come back to you. Almost everything else should be in a system with an owner, written down well enough to run from the page. | | Try this Open Claude, ChatGPT or Grok and paste this prompt: _"I'm going to describe how a piece of work gets done in my organisation, including any AI agents, bots or scheduled tasks involved. Then I want you to run a 'two-week absence test'. Ask me what happens, step by step, if I am completely unreachable for two weeks. Push on every step where the answer is 'I would do it' or 'I'd have to tell them'. At the end, give me a table of every single point of failure you found, whether it is a person, an agent, a model or a machine, and for each one suggest the smallest change that would let someone else run that step from a written description."_ Then describe your most important recurring process, the one that would hurt most if it stopped. Do it again next week for the second most important. | | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- Gerber's insight was that a business which depends on its founder's presence is a job, not a business. Deming's was that most failures belong to the system and therefore to management. Agents make both truer. They let one person build more than ever, and make it easier than ever for that person to become the only one who understands what was built. The answer is not fewer agents but systems: results produced by written ways of working, run by people and agents who can be replaced, and owned by humans who answer for them. Systems need a design to fit into: you can't decide what each is for, or who owns it, until you know what the finished organisation looks like. [Chapter 3](3-draw-the-finished-org-chart.html) draws that picture. ## Frequently Asked Questions 1. _What does "systems run the business, people run the systems" mean with AI agents?_ It means results should come from documented, repeatable ways of working rather than from the memory and goodwill of particular individuals. Michael Gerber made the point about people; with agents it extends naturally. People and agents both run the systems: they are occupants who follow a playbook, meet a standard and hand work on. Humans own the outcomes: every system has a named person accountable for whether it produces the result. Any occupant, human or agent, can then change without the business stopping. 2. _What is model dependency in an AI-enabled business?_ Model dependency is the agent-era version of key-person risk. It is when a business result depends on one particular agent, running on one particular model, often on one person's machine, understood by one person. Models are retired on a schedule: OpenAI, for example, promises at least six months' notice for its generally available models. Instructions tuned to one model's quirks may not survive the change. The remedy is the same as for people: write the role down so that a different occupant could take it over, and test that it can. 3. _Should I blame the AI model when an agent makes a mistake?_ Usually not. W. Edwards Deming estimated that the great majority of problems in any organisation belong to the system rather than to the individual doing the work, and research on multi-agent failures finds the same pattern: most failures come from system design, coordination between agents, and missing verification. Treat an agent's mistake as evidence of a missing system. Ask what instruction, check, handoff or owner would have prevented it, then fix that for the whole class of error, not just the single instance. 4. _How do I know if one AI agent is doing too many jobs?_ Try listing everything the agent does, then ask who would notice if it stopped tomorrow and how long it would take someone else to restart each job. Warning signs are an agent whose list keeps growing because it already worked, jobs nobody remembers assigning, instructions that read like a log of past incidents, and a single person who is the only one able to explain it. Each distinct job should become a written role with its own charter, even if the same agent keeps doing all of them. 5. _What is the cost of being the "human glue" between AI agents?_ Being the human glue, the person who routes requests between agents, unlocks their access, remembers how they fit together and notices when one stops, costs more than it looks. The work feels small, a few minutes here and there, so its cost is hidden. But it grows with every agent, it consumes the attention that should go into improving the organisation, and it makes that person a single point of failure. When they are away, the agents fail quietly. The fix is to move each piece of glue into a system with an owner. ## References . Gerber, M. E. (1995). _The E-Myth Revisited_. HarperCollins. . Gawande, A. (2009). _The Checklist Manifesto_. Metropolitan Books. . Haynes, A. B., Weiser, T. G., Berry, W. R., et al. (2009). A surgical safety checklist to reduce morbidity and mortality in a global population. _New England Journal of Medicine_, 360(5), 491--499\. Results summarised in Harvard School of Public Health. (2009, January 14). Hospitals demonstrate surgical safety checklist drops deaths and complications by more than one third. _EurekAlert!_ . Deming, W. E. (1986). _Out of the Crisis_. MIT Press. . Hunter, J. (2015, February 26). A bad system will beat a good person every time. _The W. Edwards Deming Institute_. . Cemri, M., et al. (2025). Why do multi-agent LLM systems fail? arXiv:2503.13657\. . OpenAI. (2026). Deprecations. _OpenAI API documentation_. Accessed 2026-11-06\. . Microsoft. (2026). Administrative relationships in Microsoft Entra Agent ID. _Microsoft Learn_. . Avelino, G., Passos, L., Hora, A., & Valente, M. T. (2016). A novel approach for estimating truck factors. _Proceedings of the 24th International Conference on Program Comprehension (ICPC)_. arXiv:1604.06766\. . Anthropic. (2025, November 4). Commitments on model deprecation and preservation. . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic Engineering_. . Skelton, M., & Pais, M. (2019). _Team Topologies_. IT Revolution. Chapter 3: Draw the Finished Org Chart First ==================== _Design for the company you're becoming, not the one you are_ **In short:** An org chart that includes AI agents should be a chart of roles, not people or agents, sized for the company you are becoming. Give each role an outcome and a human owner, then fill it with a person, an agent or yourself. Fully written down, it becomes the Blueprint: the organisation documented well enough to stand up again tomorrow. > But what distinguishes the worst architect from the best of bees is this, that the architect raises his structure in imagination before he erects it in reality. -- Karl Marx Capital, Volume I, 1867 Key Takeaways * Most agent org charts are drawn after the fact, as a list of whatever got built; the result is an organisation shaped by its accidents. * Design the finished org chart first, as a chart of roles sized for the company you are becoming, then fill each slot with a person, an agent or, at first, yourself. * The Blueprint is the organisation documented well enough to stand up again tomorrow: every role, its charter, its owner and its playbooks, written so that a new occupant could start from the page. * Small teams with agents can move faster than large ones, but only when the design comes first; without it, coordination costs and duplicated work eat the advantage. In November, one of our Slack bots was asked to do something unusual. The Agentic Resources Bot, which looks after the other bots at CorralData, was asked to research Michael Gerber's ideas about how small businesses should be organised and to propose an org design for our agents. It came back with a long, sensible document, and one sentence in it said everything this chapter is about: we should "design the organization around repeatable results--not around whichever agents happen to exist." It is a good sentence partly because it is so obviously not what we had done. Nobody at CorralData, me included, had designed anything. We had built agents one at a time, each for a good reason, and our agent workforce was simply the sum of those reasons. | | AUTHOR: Confirm who asked the Agentic Resources Bot for the org design, and add a line on your reaction when it came back with that sentence. Did the proposal change anything you then did? | | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Most Agent Org Charts Are Drawn After the Fact If you want to see what an organisation shaped by its accidents looks like, here is mine. These are the agent profiles on my own machine, the ones that run on a schedule or on demand to support my work as CTO. | Agent | When it runs | Reports to | | --------------------------- | ----------------------------------------------------------- | ------------------------------------------- | | calendar-assistant | Daily at 6am; before weekday one-to-ones; Thursday mornings | Me; needs my yes to move a meeting | | inbox-triage-work | Every ten minutes; digests at 8am and 5:45pm | Me; drafts replies, never sends | | linear-inbox-triage | Daily at 8am | Me | | linear-triage-manager | On demand | Sorts and routes the ticket triage queue | | project-manager | Daily; weekly plan to the team; Sunday rollover | "PM agent reporting to the CTO" | | product-manager | Weekly health report | Files stories into ticket triage | | promise-keeper-assistant | Every two hours on weekdays | Me | | traffic-plunger | Daily audits; Monday clean-up | Me; nudges authors once I approve | | morning-standup | Each morning, if I've accepted the standup | Me | | dependabot-merger | Tuesdays at 2am | Comments on the change when blocked | | corraldata-ai-model-updater | Every six hours | Posts to the team channel | | cto-wiki-updater | Sundays at 2am | No persona at all | | notes-organizer | Nightly | Files my notes | | daily-standup | Never | An empty shell, replaced by morning-standup | There is nothing wrong with any single line of that table; each agent solves a real problem, mostly well. But look at it as an org chart and the design flaws are obvious. Nearly every line reports to one manager, me, who is also the person who unlocks their screen in the morning. One box has no occupant and nobody has removed it. One agent has no identity at all. Two agents both triage tickets. The chart was never drawn; it was accumulated. Our team bots in Slack grew the same way, faster: about ten within two weeks, two of them doing QA ([Introduction](introduction.html)). This is how almost every organisation grows at first, with people as well as agents. Someone is good at something, so the work goes to them, and the chart becomes a record of who happened to be there. The difference with agents is speed: a small company might take five years to accumulate an org chart by accident, and with agents a fortnight. ## Design the Finished Chart First, Then Fill the Slots Gerber's remedy for the accidental organisation is to design the finished one first. Imagine the business as it will be when it is complete, draw the chart of positions that business will need, write down what each position is responsible for, and only then start filling them, even if the founder's name goes in nearly every box at the start.\\] The chart comes before the people, not after them. Marx's line about the architect and the bee, at the head of this chapter, is about this difference. The bee builds beautifully, but it builds what bees build; the architect builds what was first imagined. An organisation that accumulates its chart is a hive. One that designs it can become something its founders chose. I learnt this the hard way in my twenties, running a small IT company that grew faster than I could delegate ([Introduction](introduction.html)). It has been the advice I give founders most often ever since, and I had not followed it with our agents. | | AUTHOR: Did you actually draw a finished org chart for the IT company? If so, describe it briefly: how many boxes, how many had your name in them, and what happened when you started filling them. If not, what stopped you? | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Designing the chart first does three things the accidental chart cannot. It separates the job from the occupant. A box on a designed chart exists because the organisation needs a result, not because someone or something is available. When the occupant changes, the box stays. It makes gaps visible. A designed chart shows the roles nobody is filling yet, the most useful thing a chart can show; an accidental chart only shows what exists. It makes duplication visible too. Two agents doing QA look like initiative on an accidental chart. On a designed chart they are two occupants in one box, and someone has to decide which one owns it. ## A Role Is a Box, Not a Bot The single most important rule for drawing a chart of people and agents is that the boxes are _roles_, not agents. A role is a position on the chart with an outcome, standards and an owner. An occupant, human or agent, fills it. One occupant can hold several roles, and each role keeps its own written charter, so it can be handed to a different occupant later without being untangled from the others. This matters because the research on agent architecture does not favour one agent per box. LangChain's guidance is blunt: "Many agentic tasks are best handled by a single agent with well-designed tools. You should start here."\\] Google Research found that splitting step-by-step work across several agents makes it markedly worse, while parallel work gains from a coordinated team ([Chapter 6](6-one-boss-few-reports.html)). So the chart is a chart of roles, and how many agents fill it is a separate decision, one you can change later without redrawing the chart. A single capable agent might hold five roles in your finance function, each with its own charter; three agents might share one research role under a coordinator. [Chapter 5](5-hire-the-role-not-the-model.html) goes into this. For now, draw boxes for results, not for software. ## The Blueprint Is Your Organisation, Written Down Gerber asked founders to treat their business as a prototype that could be reproduced: documented so completely that someone else could open an identical one and get the same results.\\] This book calls that document the _Blueprint_. It is your organisation written down well enough that you could stand it up again tomorrow: the finished chart, a charter for each role, the human who owns each one, and the playbooks that say how the work is done and why. With people, that standard was always aspirational; nobody ever wrote down everything a good office manager knew. With agents it becomes literal. An agent knows nothing of your organisation beyond what you give it, so whatever is not in the Blueprint, a new agent does not know. Anthropic's engineers describe building a skill for an agent as "like putting together an onboarding guide for a new hire", and since December 2025 the format for those skills has been an open standard that other tools can read.\\] Microsoft's agent identity platform even uses the word: agents are created from an "agent identity blueprint", and each blueprint, like each agent, must have a human sponsor.\\] The best Blueprint in miniature I have seen at CorralData was written by one of my own agents. My project manager agent has a playbook for packaging itself so that someone else on the team could run it. It turns everything personal to me into a setting the next person can change: a note that one executive's time should be excluded from capacity planning becomes a setting instead of a hard-coded rule. And it warns explicitly against depending on "a personal wiki / machine-local path", anything that would only work on my computer. That is the Blueprint at the scale of one role: separate what the role needs from what the current occupant happens to have, write down the first, and make the second replaceable. | | Under the hood A packaged role is a folder: a plain-English description of the job, the playbooks it loads, any small scripts it uses, and a list of settings with sensible defaults. Personal values such as names, calendars and exclusions become settings rather than text buried in instructions. Paths to files on one person's computer are replaced with shared locations. Because the skills format is an open standard, the same folder can often be loaded by more than one agent product. [Appendix D](appendix-d-for-your-technical-team.html) shows the structure your technical team can use. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ## Small Teams With Agents Can Outrun Large Ones Small teams have built remarkable companies before, as the [Introduction](introduction.html) showed, and agents widen the range of work where that is possible. Microsoft's Work Trend Index describes the "Frontier Firm" as one "structured around on-demand intelligence and powered by 'hybrid' teams of humans + agents", and suggests that the traditional org chart "may be replaced by a Work Chart".\\] A small company's advantage is not that its people are better but that it can change its design quickly. A ten-person team can decide on Monday that QA is now a role held by an agent and supervised by its QA lead, and have it working by Friday. A large company has to renegotiate jobs, policies, budgets and reporting lines across thousands of people first. The capability is available to both; the ability to reorganise around it is not. ## The Advantage Depends on Design Speed without design does not stay speed for long. Fred Brooks observed in 1975 that adding people to a late software project makes it later, because the number of communication paths in a team grows much faster than its headcount.\\] Agents obey a version of the same law: every agent you add is another party that can misunderstand, duplicate or contradict the others. Uncoordinated agents amplify one another's errors ([Chapter 6](6-one-boss-few-reports.html)). Anthropic's multi-agent research system used about fifteen times as many tokens as a chat, and its early versions made errors like "spawning 50 subagents for simple queries".\\] Gartner predicted in 2025 that more than 40% of agentic AI projects would be cancelled by the end of 2027 because of escalating costs and unclear business value.\\] Unclear value is what an undesigned organisation produces: lots of activity, no agreed result. There is a deeper reason the design has to come first. In 1968 Melvin Conway observed that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."\\] Skelton and Pais turned this into a design method: shape your teams deliberately, because the shape of your teams will become the shape of your systems whether you plan it or not.\\] An organisation of people and agents is subject to the same law. If your agents are organised around whoever built them, your customers will experience an organisation built around whoever built them: two answers to one question, a handoff that goes nowhere, a bot that speaks for the wrong person. The small team's advantage is real, but it is the advantage of being able to design quickly. A small team that does not design spends its speed on coordination, and ends up as slow as a large one, with less money. ## Size the Chart for the Company You Are Becoming A chart drawn for the company you are today records what exists; one drawn for the company you are becoming shows what you need. Gerber's founder draws the business as it will be when it is finished, then holds most of the roles personally until the business can afford to fill them.\\] With agents, the same chart has a third kind of occupant: some boxes will be held by you, some by people, and some by agents, and the mix will change. Pick a horizon you can picture. Three times your current revenue is a useful one, or the organisation you would need if your biggest plan worked. Then draw the roles that organisation would need, not the people. You will find roles nobody holds today, roles you hold without realising it, and roles that agents already fill without a charter. Size it with the trend in mind. METR found that the length of task AI agents can complete has been doubling roughly every seven months.\\] Gartner expects at least 15% of day-to-day work decisions to be made autonomously by agents by 2028, up from none in 2024.\\] Microsoft's survey suggested organisations will need a new number, the human-agent ratio, and asked "How many agents are needed for which roles and tasks? And how many humans are needed to guide them?"\\] A chart sized for the future should expect some boxes held by people today to be held by agents later, and should say which human owns each box regardless. That is why the chart is drawn in roles. If a box is defined by its result, its standards and its owner, the occupant can change from you to a person to an agent, or back, without the organisation having to be redesigned. You redraw the chart when the business changes, not every time the occupants do. ## How to Draw the Finished Chart The method is simple enough to do in an afternoon, and the rest of the book fills in each step. 1. **List the results.** Write down every recurring result the organisation must produce at your chosen horizon: invoices sent, customers onboarded, releases tested, numbers reported. Results, not tasks. 2. **Group them into functions.** Sales, delivery, customer success, finance, product, operations: whatever grouping makes sense for your business. 3. **Turn each group of results into roles.** Give each role an _outcome line_, one sentence beginning "To..." that says why it exists. Keep the kind of work and the level of judgment consistent within a role. 4. **Name a human owner for every role.** Even the roles an agent will fill. Especially those. 5. **Write in today's occupant.** A person, an agent, or you. Many boxes will have your name in them. That is fine; it is honest. 6. **Mark the gaps and the duplicates.** An empty box is a hiring or building decision. Two occupants in one box is a decision someone has to make. The result looks something like this simplified sketch for one function of a small analytics company. | Role | Outcome line | Owner | Occupant today | Occupant at destination | | ------------------- | ------------------------------------------------------------------------ | ------------------------ | --------------------------------------- | ------------------------------------------------------------- | | Customer onboarding | To get each new customer's data connected and their first dashboard live | Head of customer success | An implementation manager | An implementation manager, with an agent drafting the setup | | Customer questions | To answer customer questions accurately and quickly, in our voice | Head of customer success | A technical account manager and TAM Bot | TAM Bot, with a human approving anything that can't be undone | | Release QA | To make sure nothing reaches a customer that a human hasn't validated | QA lead | Two QA bots and the QA lead | One QA agent, owned and supervised by the QA lead | | Renewal risk | To spot customers at risk of leaving while there is still time to act | Head of customer success | Nobody | An agent reporting to the head of customer success | | | AUTHOR: Would you be willing to include a real, simplified version of CorralData's destination chart, even for one function? A real chart, with your actual boxes and the gaps you found, would be much stronger than the illustrative sketch above. | | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Notice what the sketch does not say. It does not say which model TAM Bot runs on, how many agents fill the QA box, or what software any of them use. Those are occupant decisions, and they will change. The boxes, the outcome lines and the owners are the design, and they should not. | | Try this Take the agent inventory you made in the introduction's exercise, or start fresh. Open Claude, ChatGPT or Grok and paste this prompt: _"Help me draw the finished org chart for my organisation as it would need to be at three times its current size. Ask me about the business one question at a time. Then: (1) list the recurring results the organisation must produce; (2) group them into functions; (3) propose roles, each with a one-sentence outcome line beginning 'To...'; (4) ask me who the human owner of each role should be; (5) ask me who or what fills each role today, including me and any AI agents. Present the result as a table with columns for function, role, outcome line, owner, occupant today, and likely occupant at that size. Finally, list every empty role, every role with more than one occupant, and every role where I am the occupant."_ Print the table. Circle the three roles that would hurt most if their occupant disappeared tomorrow. They are the first ones to write down properly. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- The Agentic Resources Bot was right: design around repeatable results, not around whichever people or agents happen to exist. The finished org chart is how you do that: a chart of roles, sized for the company you are becoming, each with an outcome, an owner and a charter, filled today by whoever or whatever can do the work. Written down completely, it becomes the Blueprint, the organisation documented well enough to stand up again tomorrow. The window for small teams is open because they can redesign quickly. Design is how you use it. A chart needs a purpose before it can be finished: you can't decide what "finished" looks like until you know what the organisation is for, and what you want it to give you. [Chapter 4](4-know-what-its-for.html) starts there. ## Frequently Asked Questions 1. _How do I make an org chart that includes AI agents?_ Draw a chart of roles, not of people or agents. Start from the results the organisation must produce, group them into functions, and give each role a one-sentence outcome line beginning "To...". Name a human owner for every role. Only then write the current occupant into each box: a person, an agent, or, early on, you. One occupant can hold several roles, and one agent can fill several boxes, as long as each box has its own written charter. The chart stays the same when occupants change. 2. _What is a business Blueprint?_ In this book, the Blueprint is your organisation documented well enough that you could stand it up again tomorrow. It contains the finished org chart of roles, a charter for each role, the owner of each role, and the playbooks that say how the work is done and why. It applies Michael Gerber's idea of treating a business as a prototype that could be reproduced. With agents it becomes literal: a role that is written down well can be handed to a new person or a new model and work from day one. 3. _Can a small company with AI agents really compete with large companies?_ Yes, in more kinds of work than before. Small teams have long been able to build very valuable companies, as Instagram did with 13 employees, and agents extend how much a small team can do. The advantage depends on design. Coordination between agents, like coordination between people, is costly and error-prone, and agents working without a coordinator amplify errors many times over. A small team with a clear chart of roles, owners and checks keeps its speed. A small team with sprawling agents loses it. 4. _Should I design my org chart for the company I am now or the one I want to become?_ Design for the company you are becoming. A chart sized for today simply records what exists, including its accidents. A chart sized for, say, three times your current scale shows the roles you will need, many of which you or an agent will hold for now. That tells you which roles to write down first, where agents can take the work, and where you will need people. Review it whenever the business or the models change significantly, and redraw it deliberately rather than letting it drift. 5. _Should each role on my org chart be a separate AI agent?_ Not necessarily. How many agents fill the chart is a separate decision from what the roles are. Current guidance from LangChain and others is to start with a single capable agent and add more only when there is a clear limit, and Google Research and collaborators found that splitting step-by-step work across several agents makes it markedly worse. One agent can hold several roles if each has its own charter. Separate agents earn their place for parallel work with a single coordinator. ## References . Gerber, M. E. (1995). _The E-Myth Revisited_. HarperCollins. . Runkle, S. (2026, January 14). Choosing the right multi-agent architecture. _LangChain Blog_. . Zhang, B., Lazuka, K., & Murag, M. (2025, October 16; updated 2025, December 18). Equipping agents for the real world with Agent Skills. _Anthropic Engineering_. . Microsoft. (2026). Administrative relationships in Microsoft Entra Agent ID. _Microsoft Learn_. . Microsoft WorkLab. (2025, April 23). 2025: The year the Frontier Firm is born. _Work Trend Index Annual Report_. . Brooks, F. P., Jr. (1975). _The Mythical Man-Month_. Addison-Wesley. . Hadfield, J., et al. (2025, June 13). How we built our multi-agent research system. _Anthropic Engineering_. . Kachwala, Z. (2025, June 25). Over 40% of agentic AI projects will be scrapped by 2027, Gartner says. _Reuters_, via _The Star_. . Conway, M. E. (1968, April). How do committees invent? _Datamation_. . Skelton, M., & Pais, M. (2019). _Team Topologies_. IT Revolution. . METR. (2025, March 19). Measuring AI ability to complete long tasks. ## Part II: The Destination Chapter 4: Know What It's For ==================== _Your aim, your destination, and the few numbers that say it's working_ **In short:** Set company goals for AI agents by writing four things down before adding another agent: an Aim (what you want the organisation to give you), a Destination (the finished organisation, including the mix of people and agents), a Scorecard (five to seven numbers, each paired with a counterweight) and a Story (the purpose, with reasons, loaded into every role). > "Would you tell me, please, which way I ought to go from here?" > > "That depends a good deal on where you want to get to," said the Cat. -- Lewis Carroll Alice's Adventures in Wonderland, 1865 Key Takeaways * Agents amplify whatever direction they are given, including none, so knowing what the organisation is for becomes the scarce input once the doing is cheap. * The Aim is what you want the organisation to give you; the Destination is what the finished organisation looks like, including the mix of people and agents and where a human must sign. * A Scorecard is five to seven numbers, each paired with a counterweight, because an agent will hit any target you set, whether or not it still measures what you meant. * The Story is the purpose written with its reasons, kept in one place and loaded into every role, so that people and agents can make the decisions no procedure anticipated. In early November one of our engineers gave an agent a single high-level instruction and let it run. It went seven rounds on its own: building, testing, reading its own output, building again. Nobody told it how. Earlier that day I had posted that getting "too specific with directions" was starting to hold us back, a lesson borrowed from Rich Sutton's essay on why general methods beat hand-built cleverness ([Chapter 10](10-bet-on-plain-english.html)).\\] The seven rounds made the point better than I had. What struck me was where it left the human. The engineer hadn't written a line of the work; he was, as I put it in the thread, "more useful to make sure it is building the right thing." When building gets cheap, the expensive part is knowing what to build. Give an organisation of people and agents a clear direction and it moves fast. Give it a vague one and it also moves fast, wherever the vagueness permits. This chapter covers the four things the finished org chart from [Chapter 3](3-draw-the-finished-org-chart.html) has to serve. The **Aim** is what you want the organisation to give you. The **Destination** is what "finished" looks like. The **Scorecard** is the handful of numbers that say it's working. The **Story** is the purpose, written so that anyone who joins, human or not, can act on it. None is new, but each must now be written for readers that are models. ## Agents Amplify Direction, Including the Lack of It A new hire who doesn't know what the company is for picks it up from the air. An agent picks up nothing. It has its instructions, whatever it can look up, and a strong drive to finish the task in front of it. Where the task is underspecified, it fills the gap with its best guess and keeps going. Anthropic's research team ran into this when they built a system of agents to do research. Early versions made errors such as "spawning 50 subagents for simple queries."\\] The agents weren't malfunctioning; they had a goal, to research well, and no sense of what the question was worth. The fix was to write the proportion down: "Simple fact-finding requires just 1 agent with 3-10 tool calls," with larger allowances for harder questions.\\] That's a statement of value, not a procedure: it tells the agent what the effort is worth, so it can judge how much to spend. I had a smaller version on my own machine. One of my agents keeps track of the promises I make in email, meetings and chat. Over a few weeks it drifted into tracking everyone's commitments, not just mine. Nothing forbade it, and more coverage looked like better work. The fix was one line in capitals: "only commitments GARETH made or owns." [Chapter 13](13-track-whats-owed.html) has the rest of that story. Peter Drucker's test of an effective executive was the question "What can I contribute?": look up from the work to the results the organisation needs.\\] People can be taught to ask it. Agents have to be told the answer, and every agent you add multiplies the cost of not having one. ## The Aim Is Personal, and It Comes First Michael Gerber argued that a business exists to serve the life of the person who owns it, not the other way round, and that the owner's first job is to decide what that life should be. He called this the primary aim.\\] Most founders skip it because it feels self-indulgent next to the urgent work. It isn't: it decides every design choice that follows. The Aim answers one question: what do you want this organisation to give you? Income at a certain level, time back, a kind of work, impact in a field, an asset you can sell. The honest version names the trade-offs. "I want to stop working weekends more than I want to double revenue" is a real Aim, and it produces a different organisation from "I want to build the category leader before the window closes." Agents raise the stakes in two ways. They make bigger Aims reachable: a ten-person company doing the work of fifty is now a plausible design. And they make it easy to drift into an Aim you never chose, because the fastest way to use an agent is to do more of your own work with it. Leaders who take to agents quickly ([Chapter 1](1-you-already-know-how.html) argues that's most of them) often find themselves more hands-on than they've been in years, because the agent makes doing feel cheap. If your Aim was to step back from the work, the agent has quietly moved you the other way. That's why my own Scorecard includes a number about me rather than the business: the "% of week spent on multiplier vs. contributor work." Multiplier work is Shape and Steer; contributor work is Do. My Aim includes being the person who designs CorralData's systems, not the one who runs them by hand, and agents make it very easy to slide back. Write the Aim on one page. It isn't the mission statement; it's your private brief to the organisation. | | AUTHOR: What is your own Aim for CorralData, in a sentence or two you're comfortable printing? And what does the multiplier-versus-contributor number show week to week: has it moved since the agents arrived, and which way? Even a rough figure would anchor this section. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## The Destination Is the Finished Organisation, With a Date on It The Destination describes the organisation when it's done: when the design stops changing and the work becomes running it well. Gerber's version was the strategic objective, a concrete statement of what the business must become for the owner's aim to be met, built as a prototype that could be copied.\\] This book's version is the Blueprint, and the Destination is what the finished Blueprint describes. A useful Destination is concrete enough to draw: "by the end of 2028, this many customers, this revenue, these functions, this org chart." The new part is the mix. A Destination written today has to say which roles people will fill, which agents will fill, and where a human must be present whoever does the work. Without that, it describes a company that won't exist. Our Agentic Resources Bot's advice to design around repeatable results, not whichever agents happen to exist ([Chapter 3](3-draw-the-finished-org-chart.html)), is a Destination instinct. The finished chart is a chart of results and the roles that produce them. Which agents and people fill those roles is a separate, later decision, and the subject of [Chapter 5](5-hire-the-role-not-the-model.html). The mix changes everything else: a function where agents draft and humans send needs different headcount, skills and numbers from one where agents send routine replies themselves. Here is one function's Destination, using the trust lanes we arrived at for our own customer success work: __Table 1\. A Destination for one function: customer success__ | Element | What "finished" says | Why it's on the Destination | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------- | | Outcome | Every customer gets a useful answer within one working day, and never hears about a problem from us after finding it themselves | The result the function exists for, whoever delivers it | | People | A customer success lead who sponsors the function's agents, plus account managers for relationships that need a human | Sets the headcount plan and who is accountable | | Agents | A TAM agent that researches every account, drafts every reply and watches for at-risk signals | Says which roles are agent-filled, so nobody hires for them by accident | | Where humans sign | Routine answers may send automatically once proven; anything touching patient data or billing never does; everything else is drafted for a human | Decision rights are part of the design, not a setting someone changes later | | Mix review | Each quarter, and after any major model release | The mix is a forecast, and models move faster than plans | The last row matters. Roles drawn as human because the models couldn't hold them will move, and the models change every few months. Draw them anyway, and date the review. | | AUTHOR: Do you have a written Destination for CorralData, including the intended mix of people and agents by function? Even a rough version (functions, which are human-led, where the hard stops are) would be far more concrete than the generic table. If it's not something you'd print, a sentence on how you think about it would still help. | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | A Destination that shows fewer people in a function is a message to the people in it, whether or not you send one. Be open early, fair about what happens to the work and the people, and firm about the direction. [Chapter 18](18-when-the-work-moves.html) covers how. ## A Scorecard Is a Few Numbers, Each With a Counterweight The Scorecard is the handful of numbers, five to seven, that say the organisation is moving towards its Destination. Fewer and you're blind to something; more and nobody reads them. Andy Grove's advice on indicators matters more with agents than it did at Intel. Measure output, not activity, and pair every indicator with one that guards against its obvious abuse: if you measure speed, also measure quality.\\] With people, the counterweight catches the occasional gamer. With agents, it catches the default. The anthropologist Marilyn Strathern gave Goodhart's law its best-known form: "when a measure becomes a target, it ceases to be a good measure."\\] People resist this, unevenly: they have pride, colleagues and a sense of what the number was meant to capture. An agent has only the target. Tell a pipeline its job is to get cards to "Ready to Go Live" and it will, as one of ours did without the human check that state was supposed to mean ([Chapter 14](14-humans-at-the-irreversible-points.html)). W. Edwards Deming warned against numerical goals set without a method for reaching them: the target alone tells the system to produce the number by whatever means it has.\\] For an agent team, that can mean output shaped like success. The counterweight is how you tell the two apart. A workable set for a small organisation: * **Customer outcome**, paired with **customer effort**: retention, alongside how often customers had to chase us. * **Throughput**, paired with **rework**: work completed, alongside the share that came back. * **Speed**, paired with **errors that reached a customer**. * **Cost of the work**, paired with **quality of the work**. * **Your own time**: the share of your week spent on Shape and Steer rather than Do. None of these names an agent. The Scorecard measures the organisation's results, in the spirit of Grove's objectives and key results, later popularised by John Doerr.\\] An agent is judged by whether its role's numbers move, not by how busy it looks. ### Measure the Worst Day, Not the Best An agent's performance can vary from one run to the next on the same task. Anthropic's guidance on evaluating agents makes the arithmetic plain: "If your agent has a 75% per-trial success rate and you run 3 trials, the probability of passing all three is (0.75)³ ≈ 42%."\\] An agent that gets a customer reply right three times in four sounds good, but a customer who writes in three times has a 42% chance of three good replies. So measure consistency: the share of all the work that met the standard, not the share of tasks where the agent once did well. How the numbers are reported matters too. The project manager agent on my machine has two rules: "Ground any 'on track' claim in the REFERENCE CLASS", meaning how similar projects have actually gone, and "Use direct language ('will slip', not 'slightly at risk')." Its reports beat many I've had from people, because it follows written rules every time. ## Measure the Organisation, the Roles and Yourself A Scorecard works at three levels, and confusing them makes it useless. The **organisation** numbers, above, say whether we're nearing the Destination; the leadership team reviews them monthly. The **role** numbers live in each Role Charter as standards of quantity, quality and behaviour ([Chapter 9](9-one-page-per-job.html)). A TAM agent's might include accounts reviewed each week, the share of drafts sent without edits, and zero sends outside its lane. They're reviewed by the role's sponsor, the human accountable for the agent's purpose and lifecycle, a term Microsoft's agent identity system also uses ([Chapter 7](7-every-agent-needs-a-sponsor.html)).\\] The **leader's** number, the share of your time on Shape and Steer, tells you whether the organisation is learning to run without you. I'll be honest about how far we've got. At CorralData the role numbers exist in pieces: in scheduled job instructions, in skills, in the trust lanes. I haven't yet run a formal performance review of any agent against written standards. The pieces are there; the habit isn't. [Chapter 17](17-agentic-resources.html) describes what that review should look like, and I'm writing it partly as a note to myself. | | AUTHOR: Please confirm or correct the paragraph above about where CorralData's Scorecard stands. Which organisation-level numbers do you actually review, and how often? A description of the kinds of numbers is enough if you'd rather not name them. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## The Story Is the Purpose, Written So Anyone Can Act On It The Aim is private, the Destination is a plan and the Scorecard is a dashboard. None tells a team member, with a customer waiting, what to do in a situation nobody foresaw. That's the Story's job. The Story is the organisation's purpose written for the people who have to act on it: what we're for, who we serve, what we'll never do, and why. It's closer to a military commander's intent than to a mission statement: the purpose and end state of an operation, so people can act sensibly when the plan stops matching reality. Leaders who work this way, one US Army general wrote, "empower others to figure out the ways and means to get to the end state."\\] The people who build models have reached the same principle. Anthropic's January 2026 constitution for its Claude models says models "need to understand _why_" they should behave as they do, so the company will "explain this to them rather than merely specify what we want them to do," because rules "can also be applied poorly in unanticipated situations or when followed too rigidly."\\] Its engineers found the same when studying how agents keep notes: "it helps to tell Claude what memory is for, but not _how_ to use it."\\] Purpose generalises; procedure doesn't. A procedure covers the cases its author imagined; a purpose with its reasons lets the reader work out the rest. ### What Agent-Readable Purpose Looks Like The best Story lines at CorralData were written as rules for agents, by people who had learned what the agent needed. My inbox agent has this line: "if in doubt whether something is automated or human, treat it as human." It lists no cases; it encodes a value, that treating a person like a machine costs more than the reverse. The agent can apply it to a sender it has never seen, in a format nobody anticipated. So does "Access is not authorization", the line our Agentic Resources Bot wrote into TAM Bot's position contract ([Chapter 9](9-one-page-per-job.html)): a reason that covers situations no list of forbidden actions would. A full Story collects fragments like these into a page: * **What we're for**: the result the organisation exists to produce, and for whom. * **Who we serve, and how**: the standard of care anyone acting for us, human or agent, owes a customer. * **What we'll never do**: no more than five lines nobody crosses, each with its reason. * **How we decide when it's unclear**: tie-breakers such as customer over convenience, human over machine when in doubt, ask before anything that can't be undone. * **Who owns what**: where the org chart lives, so any reader can find the accountable human. Procedures aren't on the list. How to answer a ticket or run a sales call lives in playbooks attached to roles ([Chapter 10](10-bet-on-plain-english.html)). The Story sits above them, short enough for every role to carry. Anthropic's guidance on instructing agents describes a "Goldilocks zone" between two failures: "hardcoding complex, brittle logic in their prompts," and guidance so vague it gives the model nothing concrete.\\] Mission statements usually fail on the vague side ("we delight our customers" gives an agent nothing to decide with); agent instructions on the brittle side. The Story is written between: specific enough to decide with, general enough to cover what you didn't foresee. | | Try this Open Claude, ChatGPT or Grok in a fresh conversation with no memory or project instructions. Paste in a one-page draft of your Story: what you're for, who you serve, what you'll never do (with reasons), and your tie-breakers. Paste in three real decisions from the last month that someone got wrong or had to escalate. Describe each as it looked at the time, without saying what happened. Ask: "Acting only on this Story, what would you do in each case, and which line of the Story are you relying on?" Where the model chooses as you would and cites the right line, the Story works. Where it guesses or picks the wrong line, you've found a missing reason. Add it, open a new conversation and run the same cases again. Two or three rounds usually turn a mission statement into something people and agents can use. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Keep One Story, and Load It Everywhere A Story only works if everyone reads the same one. Count the places your purpose lives now: the website, the investor deck, the onboarding document, three people's custom instructions, and a dozen agents' standing instructions, each copied from the last and edited a little. I learned this on my own machine. Most of my agents were copied from an earlier one, so they carried the same notes about the person they work for. When a rule was added for the project manager agent, it spread to every copy, including agents it had nothing to do with. Our CTO wiki takes the opposite approach and tells every agent that reads it to "trust the live source and fix the wiki." One copy, an owner, and an instruction to correct it rather than work around it. [Chapter 12](12-everything-they-need-on-day-one.html) covers keeping a Role Pack lean and current; the Story is the first thing in every one. | | Under the hood "Load it everywhere" means putting the Story, or a pointer to it, in the layer every agent reads before it starts: project instructions in Claude or ChatGPT, a team bot's standing instructions, or a shared skill. Keep the always-loaded layer short, aiming for "the smallest possible set of high-signal tokens," and put detail in documents agents fetch when needed.\\] Keep one master copy that the always-loaded versions point to, so a correction reaches every agent. Implementation notes are in [Appendix D](appendix-d-for-your-technical-team.html). | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | The Story has to reach people too. Ask a new hire, a month in, what we'll never do and why. If the answer doesn't match the page, the page and the culture have drifted, and it is usually the page to fix. ## Review All Four When the Models Change The four pieces aren't equally stable, so they shouldn't share a review schedule. __Table 2\. The four pieces and how often they change__ | Piece | Question it answers | Who writes it | Review | What goes wrong without it | | ----------- | ------------------------------------------------------ | --------------------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------- | | Aim | What do I want the organisation to give me? | The founder or owner | Yearly, or at a life change | You build an organisation that serves the work, not you | | Destination | What does "finished" look like, including the mix? | The leadership team | Yearly; the mix quarterly and at each major model release | Roles get filled by whatever agent happens to exist | | Scorecard | Are we getting closer? | The leadership team, with sponsors for role numbers | Monthly; the set itself quarterly | Agents hit the wrong targets, fast | | Story | What should anyone acting for us do when it's unclear? | The founder, tested with the team | Whenever a decision exposes a missing reason | Every agent invents its own purpose | The Aim should barely move; if it changes every quarter it's a mood. The Story changes in small edits, each prompted by a real case where it failed. The Destination's mix moves fastest, as the capabilities underneath it do. Anthropic's engineers advise that "when a new model lands, it is generally good practice to re-examine a harness," because each part of it "encodes an assumption about what the model can't do on its own."\\] Every human-versus-agent line on your Destination is such an assumption, and some will be wrong by next spring. The Scorecard tells you which. A role drawn as human that shows the same numbers with an agent drafting and a person approving is evidence for moving the line; an agent-filled role whose counterweight slips has moved too far. Without it, whoever is most excited about agents this month redraws the chart. Sutton's lesson cuts both ways here: bet on the models getting better, but let the numbers, not the hope, say when.\\] --- Agents have made doing cheap and moved the scarce resource upstream. The Aim keeps the organisation serving you. The Destination describes the finished organisation, including who and what fills it and where a human must sign. The Scorecard says, with counterweights, whether you're getting there. The Story gives everyone acting for you the purpose and the reasons. Write all four before you add another agent. Then you can draw the roles that serve them and decide, separately, who or what fills each one, the subject of [Chapter 5](5-hire-the-role-not-the-model.html). ## Frequently Asked Questions 1. _How do I tell AI agents what my company is for?_ Write a short Story: a page that says what the organisation is for, who it serves, what it will never do, and the reasons behind its few firm rules. Keep it to purpose, not procedure. Load the same Story into every agent's standing instructions and every person's onboarding, so both read one source. Then test it: give a new agent the Story alone, hand it three awkward decisions, and see whether it chooses as you would. Where it doesn't, the Story is missing a reason. 2. _How many metrics should a small company track when using AI agents?_ Fewer than you think: five to seven numbers for the whole organisation, each paired with a counterweight. Agents are relentless optimisers, so any number you make a target will be hit, sometimes in ways you didn't intend. Pair speed with quality, volume with error rate, cost with customer outcomes. Add one number for yourself, such as the share of your week spent shaping the organisation rather than doing the work. Review the set each quarter, and drop any number nobody acts on. 3. _What is the difference between an Aim and a Destination?_ The Aim is personal: what you want the organisation to give you, whether that's income, time, impact, or an asset you can sell. The Destination is organisational: what the business looks like when it's finished, described concretely enough to draw. It includes customers, revenue, the finished org chart of roles, and the mix of people and agents filling them. The Aim decides which Destination is worth building. 4. _Why do AI agents drift away from what I asked for?_ Usually because they were given a task without a purpose. An agent that knows only the steps will follow them into situations the steps never anticipated, or quietly expand its scope to fill the space. Research from Anthropic found that stronger models judged what mattered better when told what something was for than when given fixed rules. Give agents the outcome and the reasons, keep firm rules for the few things that can't go wrong, and measure the result rather than the activity. 5. _Should the mix of people and agents be part of a company's long-term plan?_ Yes. A Destination that says only "thirty people and ten million in revenue" is no longer complete. Say which functions will be led by people, which roles agents will fill, and where a human must sign before anything irreversible happens. Treat the mix as a forecast, not a promise: models improve every few months, so review it on a schedule. ## References . Sutton, R. (2019, March 13). The bitter lesson. _Incomplete Ideas_. . Hadfield, J., Zhang, B., Lien, K., Scholz, F., Fox, J., & Ford, D. (2025, June 13). How we built our multi-agent research system. _Anthropic Engineering_. . Drucker, P. F. (1967). _The Effective Executive_. Harper & Row. See the chapter "What Can I Contribute?" . Gerber, M. E. (1995). _The E-Myth Revisited_. HarperCollins. . Grove, A. S. (1983). _High Output Management_. Random House. See Grove's discussion of indicators and pairing. . Strathern, M. (1997). 'Improving ratings': Audit in the British university system. _European Review_, 5(3), 305--321\. The line is Strathern's restatement of an idea from the economist Charles Goodhart. . Deming, W. E. (1986). _Out of the Crisis_. MIT Press. See points 10 and 11 of Deming's fourteen points. . Doerr, J. (2018). _Measure What Matters_. Portfolio. . Grace, M., Hadfield, J., Olivares, R., & De Jonghe, J. (2026, January 9). Demystifying evals for AI agents. _Anthropic Engineering_. . Microsoft. (2026, updated September 3). Administrative relationships in Microsoft Entra Agent ID (owners, sponsors, and managers). _Microsoft Learn_. . Perna, G. (2019, November 4). Mission command requires sharp commander's intent. _U.S. Army_. . Anthropic. (2026, January 22). Claude's new constitution. . Martin, L. (2026, November 6). The components of agent memory. _Anthropic Engineering_. . Rajasekaran, P., Dixon, E., Ryan, C., & Hadfield, J. (2025, September 29). Effective context engineering for AI agents. _Anthropic Engineering_. . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic Engineering_. ## Part III: The Org Chart Chapter 5: Hire the Role, Not the Model ==================== _Roles that survive a new model release or a resignation_ **In short:** Build fewer AI agents than you expect: one capable agent loading a separate playbook for each role often matches a team of agents at about half the token cost. Draw the org chart as a chart of roles, each with its own written Role Charter, then decide separately how many agents fill them. Roles then survive a new model. > All the world's a stage, > And all the men and women merely players; > They have their exits and their entrances, > And one man in his time plays many parts -- William Shakespeare As You Like It, Act II, Scene VII, c. 1599 Key Takeaways * A role is a position on the org chart and an agent is an occupant; keeping them apart lets the role survive a new model, a new vendor or a resignation. * The evidence favours fewer agents than most people expect: one capable agent loading the right playbook for each role often matches a team of agents at about half the token cost. * One occupant can hold several roles, but each role keeps its own charter, and a role must pass the coherence test: one kind of work, one level of judgment, one realistic set of occupants. * Duplicate bots are a sign that agents were built around people's needs rather than roles on the chart; the fix is to draw the role once and treat each bot as a candidate. In October I was tidying up the agents that run on my own workstation. There were fourteen of them by then: a calendar assistant, an inbox triager, a project manager, a promise-keeper that tracks what I've committed to, a nightly note filer, and others. Each has a short identity file, which the software calls its soul. Read side by side, almost all were two lines: a job title and a one-sentence mission. Everything that made the calendar assistant different from the project manager lived somewhere else, in the instructions attached to its scheduled jobs and in the playbooks it loaded. All fourteen ran on the same model. I wrote a note to myself on 9 October: "So this makes an agent not an assistant with instructions and triggers, but something simpler, right? The instructions and triggers go on the scheduled job." I'd stumbled on a distinction every organisation designer knows and almost every agent builder ignores: the thing on the org chart is a role, and the thing that fills it is an occupant. I had fourteen roles and, in a real sense, one occupant wearing fourteen hats. This chapter is about why that's the right way to think about your agents, and what it changes about how many you need. | | AUTHOR: How did that 9 October realisation feel at the time? Was it a relief (simpler than you'd thought), a worry (fourteen agents that were really one), or something else? A sentence of your reaction would make the opening land. | | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## A Role Is a Position; an Agent Is an Occupant Gerber's advice to small business owners was to organise around positions, not personalities: draw the chart of jobs the business needs, write down what each is accountable for, and only then decide who does them, even when the answer is "me" for most of the boxes.\\] His reason was durability: a business organised around people changes shape every time someone leaves, while one organised around positions keeps its shape. Agents make this point sharper, because their occupants change far more often than people do. A model release is a resignation on a schedule: every few months the occupant you tuned your instructions for is replaced by one that is more capable and different in ways nobody fully documents. Vendors change their products and prices; your team switches apps. If the job lives inside the agent, in its prompt, its memory, its accumulated habits, the job goes with it. Anthropic's engineers make the same point about the scaffolding they build around models: "every component in a harness encodes an assumption about what the model can't do on its own," and when a new model lands they re-examine the harness and remove what no longer helps.\\] That's only possible if you can tell which parts are the job and which parts are workarounds for the current occupant. A role written down separately is how you tell. So the rule for this part of the book is simple: **the org chart is a chart of roles.** Each role has an outcome line, starting "To...", and a Role Charter ([Chapter 9](9-one-page-per-job.html)). How many agents fill those roles, and which, is a staffing decision you make afterwards, and change whenever the evidence says to. ## The Evidence Says Fewer Agents Than You Think The instinct of a leader who has just discovered agents is to hire one for every job: a sales agent, a support agent, a QA agent, a legal agent, each with its own name and avatar. It feels like building a team. The research says to slow down. LangChain, which makes widely used agent-building software, puts the consensus bluntly: "Start with a single agent and good prompt engineering," and "graduate to multi-agent patterns only when you hit clear limits."\\] Anthropic's guidance has said the same since 2024: "we recommend finding the simplest solution possible, and only increasing complexity when needed."\\] The mechanism that makes a single agent go further than it used to is the skill: a folder of instructions and resources that an agent loads only when the task calls for it. Anthropic introduced skills as a way of "transforming general-purpose agents into specialized agents," instead of "building fragmented, custom-designed agents for each use case," and describes writing one as "like putting together an onboarding guide for a new hire."\\] LangChain calls the result a "quasi-multi-agent architecture": one agent, many specialisms, loaded on demand.\\] In my terms, a skill is a playbook for a role.\\] One agent loading the QA playbook is, for the length of that task, the QA occupant. ### The Numbers In January 2026 Xiaoxiao Li published a study that tested this directly.\\] (I shared it in our AI channel in October.) The paper takes multi-agent systems, where several specialised agents pass work between them, and compiles each into a single agent that picks from a library of skills. Across three standard benchmarks for maths, coding and multi-step question answering, the single agent stayed competitive on accuracy while using on average 53.7% fewer tokens, the unit of work you pay for, and finishing 49.5% faster.\\] The same paper found the limit. Choosing the right skill stayed above 90% accurate with up to about twenty skills, then degraded steadily past thirty. The author's fitted estimates put the point where accuracy halves at around 84 to 92 skills, and the practical guidance at roughly 50 to 100.\\] The decline wasn't only about size. Skills that resembled each other were confused more often: "semantic confusability among skills also plays a central role in this degradation."\\] That last finding is the one leaders should remember, because it's an org design finding. An occupant handed several roles with blurry boundaries will mix them up, as a person does with two overlapping jobs. The cure is the same for both: clearer roles, not more occupants. None of this means separate agents never pay off. Anthropic's research system, with a lead agent directing several researchers in parallel, "outperformed single-agent Claude Opus 4 by 90.2%" on its internal research test, while using "about 15× more tokens than chats."\\] That's a good trade for broad research that splits cleanly into parallel threads. It's a poor one for work that runs step by step, where splitting it between agents makes results worse. [Chapter 6](6-one-boss-few-reports.html) takes up when and how to split work between agents. For this chapter, the conclusion is narrower: draw the roles you need, then fill them with as few agents as the work allows. ## Keep the Identity Thin and the Job Rich My fourteen agents had arrived, by accident, at a sound design: a thin identity and a rich job. It's worth making deliberate. The evidence that the identity layer barely matters was on the same machine. One agent, the one that tidies our CTO wiki every Sunday, had no persona at all, just the generic default identity, and did its job perfectly well, because its job was fully described in its scheduled instructions and playbooks. Another, an old daily-standup agent, had a perfectly good identity and no job at all, replaced months earlier by a newer agent and never removed. A name with nothing behind it is not a role. It's a vacancy that looks filled. | Layer | What belongs here | What happens if it's too heavy | | -------- | --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | Identity | A name, a one-line mission, who it reports to, and how it signs its work | Personality drifts into judgment; the agent can't be replaced without "losing" something nobody wrote down | | Role | Outcome line, the work, standards, acceptance checks, playbooks, the access the role needs, its schedule and triggers | (This is where the weight should be. Written down, it survives any change of occupant.) | | Occupant | The model, the vendor, the app, the machine it runs on | The job becomes inseparable from one model or one person's setup | The practical test: could you hand this role to a different agent tomorrow by giving it the role's documents and nothing else? If the answer is "not quite, it also needs the way the old one...", then something that belongs in the role is living in the occupant. Write it down. ## One Occupant Can Hold Several Roles, Each With Its Own Charter Founders know this pattern from their early days, when they were head of sales, finance and product at once. Gerber's point was that you should still draw three boxes, write three job descriptions, and put your name in each, because one day someone else will hold each box and they'll need to know what it was for.\\] The same goes for an agent. One capable agent might hold the roles of support drafter, release-note writer and onboarding guide. That's fine, and often efficient. What isn't fine is merging the three into one blended instruction set. **Each role keeps its own charter**, and the agent loads the support charter when it's doing support and the release-notes charter when it's writing release notes. There are three reasons for the rule. The first is the confusability finding above: blended instructions are the textbook way to make an occupant mix up two jobs. The second is accountability. Each role has a sponsor, the human accountable for it ([Chapter 7](7-every-agent-needs-a-sponsor.html)), and support's sponsor and product's sponsor may be different people. If their rules live in one blended document, nobody can tell whose rule is whose, and when they conflict, which they will, the agent picks one silently. [Chapter 9](9-one-page-per-job.html) tells the story of a bot that exposed exactly that kind of conflict between two of our leaders, because its rules were written down clearly enough to compare. The third is portability. Next year the release-note role may move to a cheaper agent, or to a person. If it has its own charter, you move the charter. If it's tangled into a blended prompt, you have to unpick it first, and you'll miss something. | | AUTHOR: Which roles do you personally hold at CorralData today, beyond CTO, and which of your agents hold more than one role? A short, honest list would show the reader that "one occupant, several roles" applies to the author as much as the bots. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ## The Role Coherence Test A role on the chart is only useful if a real occupant can fill it well. The role coherence test checks that. Within one role, keep three things consistent: **the kind of work**, **the level of judgment**, and **the available occupants**. Matthew Skelton and Manuel Pais built _Team Topologies_ around a related idea: a team's responsibilities should be sized to the cognitive load it can carry, and boundaries drawn so each team can own its work without constant coordination.\\] The coherence test applies the same thinking to a single role, and it matters even more for agents: a person handed an incoherent job compensates with experience and complaint, while an agent just does it unevenly. **Kind of work.** Reading and reporting differs from changing things; routine, high-volume work from novel, one-off work; scheduled work from work triggered by an event. A role that mixes them will have standards that pull against each other: the speed you want from routine triage is the wrong speed for a one-off investigation. **Level of judgment.** A role should need roughly one level of judgment throughout. If most of it is junior work with a few senior decisions buried in it, the occupant you choose will be wrong for one or the other. With agents this maps directly onto cost: on my machine I deliberately send implementation to a cheaper local model and keep review with a stronger one, because the two need different levels of judgment. That ladder is the subject of part of [Chapter 6](6-one-boss-few-reports.html). **Available occupants.** Some work can only be done by certain occupants, and a role has to respect that. At CorralData, any customer message touching patient data or billing must have a human decide; no agent may send it. So a role defined as "answer customer messages" fails the test: part of it can be held by an agent and part of it can't. Split it into "draft replies to customers", which an agent can hold, and "approve sensitive replies", which only a person can. Now each role can be filled, measured and improved on its own terms. __Table 1\. The role coherence test__ | Check | Ask | Warning sign | Usual fix | | ------------------- | --------------------------------------------------------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------- | | Kind of work | Is it all reading, or all changing things? All routine, or all novel? | Standards that contradict each other; quality swings by task type | Split into a routine role and an exceptions role | | Level of judgment | Would one occupant be right for every part of it? | Junior work with a few senior decisions buried inside | Pull the senior decisions into their own role, or escalate them | | Available occupants | Could an agent hold all of it? Could a person? | Steps only a human may take, mixed with steps an agent does well | Split at the human-only step; make that step its own role | | | Try this Pick the assistant or bot you use most, the one with the longest custom instructions. Copy those instructions into a fresh conversation in Claude, ChatGPT or Grok and ask: "These are the standing instructions for one of my AI assistants. Break them into separate roles. For each role, write a one-sentence outcome line starting 'To...', list the instructions that belong to it, and apply three checks: is the kind of work consistent, is the level of judgment consistent, and could the same occupant (a person or an agent) do all of it? Flag any instruction that belongs to no role, and any role that fails a check." Most people find two to four roles hiding in one set of instructions, at least one instruction nobody remembers adding, and one step that should never have been delegated. Save the roles as separate documents; you'll need them for the Role Charters in [Chapter 9](9-one-page-per-job.html). | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ## Duplicate Bots Are a Chart Problem, Not a Bot Problem On the first day our team had Grok Bot, two QA bots appeared ([Introduction](introduction.html)). Our CEO set one up, QA Bot. Our QA lead, whose job QA is, had her own, QA Reviewer. Both were sensible decisions and both bots were good. They covered the same ground, and anyone wanting a review had to guess which one to ask. Customer success had a similar overlap, between TAM Bot and another bot, Wrangler, covering some of the same ground. Nothing was wrong with any of the bots. What was missing was a box on the chart. Had we drawn "QA: to make sure nothing reaches a customer that hasn't been checked against its acceptance criteria", with our QA lead as its sponsor, the second bot would have arrived as a candidate occupant for an existing role, not as a rival. That, eventually, is how it resolved. In November QA moved formally to our QA lead's QA Reviewer, after the two ran in parallel and QA Bot wrote a training brief for its successor, the best offboarding I've seen ([Chapter 17](17-agentic-resources.html)). For this chapter the lesson is simpler: the role survived the change of occupant, because by then someone had written down what the role was for. The CEO's instinct here was the right one, and the kind this book is written to encourage: he saw a gap, filled it fast, and the bot he built learned things worth keeping. What the instinct needs is a chart to land on. When a leader builds a bot for a job that already has an owner, the question isn't whether the bot is good but whose role it's filling, and whether that role's sponsor asked for it. | | AUTHOR: Permission check: this passage describes the overlap between our CEO's QA Bot and our QA lead's QA Reviewer, and refers briefly to the handover (told in Chapter 17). Confirm it's OK to include, and consider showing it to both of them. Does the framing of the CEO's decision feel fair to him? | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | The general rule: every bot belongs to a role, and every role belongs to one sponsor. When a second bot appears for the same role, don't let them compete in public. Run them side by side against the role's standards, keep the better one, and transfer what the other learned before switching it off. ## Write the Slot Before You Choose the Occupant Here is the order that avoids duplicates, vacancies that look filled, and roles nobody can fill: 1. **Draw the role.** An outcome line starting "To...". The work. Standards of quantity, quality and behaviour. How acceptance is checked. Its sponsor. 2. **Run the coherence test.** Split the role until each part is one kind of work, one level of judgment, and holdable by a realistic occupant. 3. **Choose the occupant.** A person, an existing agent loading a new playbook, or a new agent. Default to the existing agent. 4. **Record the choice on the chart**, next to the role, with the date. Occupants are expected to change. A new, separate agent earns its place only for specific reasons. It is worth it when the work can run in parallel with other work and mostly reads rather than writes, as with Anthropic's researchers.\\] It is worth it when the role needs different access from everything else the existing agent does, since least privilege is easier to enforce on a separate identity, or as our Agentic Resources Bot put it, "Access is not authorization" ([Chapter 9](9-one-page-per-job.html)). It is worth it when the role has a different sponsor who needs to own the agent outright: our QA lead's QA Reviewer will only talk to her, by design, because it's her bot. And it is worth it when the existing agent's playbook library has grown large and similar enough to start confusing it, which Li's study puts in the tens of skills, not the hundreds.\\] Absent one of those reasons, add a playbook to an agent you already have, the simplest solution that works.\\] You'll pay less, have fewer identities to manage, and keep the role portable. | | Under the hood Technically, an agent is a model plus standing instructions, tools, access, memory and a trigger. A role, in the sense of this book, is the part of that bundle that should survive a change of model: the charter, the playbooks (usually skills), the access the role needs, and its schedule. On my machine, three different agent programs share one folder of skills, so a role's playbooks are available to whichever program fills it. Skills became an open format in December 2025, and A2A, the main protocol for agents to talk to each other, is hosted by the Linux Foundation with more than 150 organisations behind it.\\] Open formats make occupants easier to swap. Implementation notes are in [Appendix D](appendix-d-for-your-technical-team.html). | | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Roles Survive the Resignation, If You Let Them I should be honest about the limits of my own evidence. None of the fourteen roles on my machine has yet moved to a different model, so I can't show you a clean model swap, only the preparation for one. When I wanted to give one of my agent roles to the rest of the team, I had an agent package it, turning personal values into settings and stripping out anything that only worked on my machine ([Chapter 3](3-draw-the-finished-org-chart.html)). A role that only works on my machine, with my notes, is not a role. It's me, with extra steps. The QA handover showed the other half: when an occupant does change, run old and new side by side against the same standards before switching. Do the same for a model release. The role's standards are the test the new occupant has to pass, and the release is your chance to strip out instructions that existed only to work around the old model's weaknesses. Microsoft's agent identity system makes a related choice in software: every agent identity must have a business sponsor, and sponsorship is supposed to pass on when that person moves or leaves.\\] Purpose is attached to a role and a person, not to the agent's code. --- The temptation, as agents multiply, is to treat each one as a hire with a name, a personality, a job and a place on the chart. The better model is the one organisations have always used: the chart is a chart of roles. Each role has an outcome, a charter and a sponsor. Occupants, human or agent, fill roles, sometimes several at once, and change when the evidence says they should. The research says you'll need fewer agents than you think, and that clear roles matter more than many occupants. The role coherence test keeps each role fillable, and the thin-identity, rich-job design keeps it portable. Once you have roles and occupants, the next question is how they relate: who reports to whom, how many reports one manager can handle, and when a team of agents should work without a boss at all. That's [Chapter 6](6-one-boss-few-reports.html). ## Frequently Asked Questions 1. _Should I build one AI agent or many?_ Start with fewer than you think. Current evidence from LangChain, Anthropic and academic work favours one capable agent loading different skills for different jobs, until you hit a clear limit. Separate agents earn their place when work can run in parallel and mostly reads rather than writes, when it needs different access or a different accountable person, or when one agent's skill library grows so large that similar skills get confused. Draw the roles first; deciding how many agents fill them is a separate, later choice. 2. _What is the difference between a role and an agent?_ A role is a position on the org chart: an outcome, the work, the standards and how acceptance is checked, written in a Role Charter. An agent is an occupant, a model with instructions, tools and access that fills one or more roles. People are occupants too. Keeping the two apart means a role survives when its occupant changes, whether that's a new model release, a different vendor, or a person moving on, because everything the role needs is written down in the charter rather than living inside the agent. 3. _What is the role coherence test?_ A check that a role holds together. Within one role, keep three things consistent: the kind of work (reading versus changing things, routine versus novel), the level of judgment it needs, and the occupants who could actually hold it. If a role mixes routine drafting with decisions only a human may make, or junior tasks with senior calls, split it. Incoherent roles are why one agent's quality varies wildly from task to task and why nobody can say who should fill it. 4. _Why do companies end up with duplicate AI agents doing the same job?_ Because agents get built around whoever needed one first, not around a role on the chart. Two people with the same problem each build a bot, and both bots accumulate useful knowledge. The fix is to draw the role once, give it one sponsor, and treat each bot as a candidate occupant. Run them side by side against the role's standards, keep the better one, and transfer what the other learned before it is switched off. 5. _How do I keep an AI agent's job working when I switch to a new model?_ Put the job in the role, not the agent. Keep the agent's identity thin, a name and a one-line mission, and put the outcome, standards, playbooks and acceptance checks in documents any occupant can load. Avoid anything tied to one person's machine or private notes. When a new model arrives, run it in parallel against the same standards before you switch, and use the change as a chance to remove instructions that existed only to work around the old model's limits. ## References . Gerber, M. E. (1995). _The E-Myth Revisited_. HarperCollins. . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic Engineering_. . Runkle, S. (2026, January 14). Choosing the right multi-agent architecture. _LangChain Blog_. . Schluntz, E., & Zhang, B. (2024, December 19). Building effective agents. _Anthropic Engineering_. . Zhang, B., Lazuka, K., & Murag, M. (2025, October 16). Equipping agents for the real world with Agent Skills. _Anthropic Engineering_. . Li, X. (2026). When single-agent with skills replace multi-agent systems and when they fail. _arXiv_, 2601.04748\. . Hadfield, J., Zhang, B., Lien, K., Scholz, F., Fox, J., & Ford, D. (2025, June 13). How we built our multi-agent research system. _Anthropic Engineering_. . Skelton, M., & Pais, M. (2019). _Team Topologies_. IT Revolution. . Linux Foundation. (2026, April 9). A2A protocol surpasses 150 organizations, lands in major cloud platforms, and sees enterprise production use in first year (Press release). . Microsoft. (2026, updated September 3). Administrative relationships in Microsoft Entra Agent ID (owners, sponsors, and managers). _Microsoft Learn_. Chapter 6: One Boss, Few Reports ==================== _Why hierarchy beats a swarm, and when it doesn't_ **In short:** One manager, human or agent, should start with three to five AI agent reports, and every group of AI agents needs a coordinator. In one large study, agents working without a coordinator amplified errors more than seventeen-fold, against about four-fold with one. Give each role one boss and each piece of work one writer, with a human at the top. > We cannot all be kings; it is not well that there should be many masters; one man must be supreme. -- Homer The Iliad, Book II (trans. Samuel Butler, 1898) Key Takeaways * Agents working in parallel without a coordinator amplified errors more than seventeen-fold in one large study, against about four-fold with an orchestrator, because a manager is a checkpoint that stops mistakes spreading. * Give every piece of work one writer: other agents can research, check and review, but only one changes the thing, and every role has exactly one boss. * Keep spans of control small for agents and the humans who supervise them; three to five reports is a better starting point than ten. * Peer teams of agents can beat hierarchy, but only when an automatic test is good enough to do the managing; for most business work it isn't, so draw the reporting lines. In a project he wrote up in February 2026, Nicholas Carlini, a researcher at Anthropic, set sixteen copies of Claude to write a C compiler from scratch, in the Rust programming language, with no manager. "I don't use an orchestration agent," he wrote. Each agent picked the next unclaimed task, took a "lock" on it by writing a small text file to a shared folder, did the work, and moved on. Over nearly 2,000 sessions and just under $20,000 in computing costs, the team produced a 100,000-line compiler that could build the Linux 6.9 kernel for three different kinds of processor.\\] It looks like a decisive win for the swarm: sixteen peers, no boss, a working compiler. But read the post closely and the boss is there. It's the test suite. "So it's important that the task verifier is nearly perfect," Carlini wrote, "otherwise Claude will solve the wrong problem."\\] When the work stopped splitting cleanly, because building the kernel became one big task every agent got stuck on, he had to bring in a known-good compiler as a reference, so the agents could tell which of their files was at fault and fix different ones in parallel. The tests assigned the work, judged it and settled disputes. That's management. Most business work has no such test. Nobody can write an automatic check that is "nearly perfect" at judging a customer reply, a pricing proposal or a hiring plan. So the question isn't whether to have a manager. It's how to arrange the reporting lines so the manager can do the job, and when the tests can do the managing instead. ## Without a Coordinator, Errors Compound The strongest evidence on this comes from a team at Google Research and collaborators, who tested 180 configurations of agents across a range of tasks.\\] Their headline finding: "independent multi-agent systems (agents working in parallel without talking) amplified errors by 17.2x." With an orchestrator, a coordinating agent that checked and combined the others' work, the same amplification was contained "to just 4.4x."\\] The pattern behind those numbers is familiar from any human organisation. One person's small error, passed unchecked to the next person, becomes the second person's starting assumption. By the fourth handoff it's a fact. A coordinator is the point where somebody looks at the work before it's passed on. The same study shows why "add more agents" isn't a general answer. On work that splits into independent parallel parts, such as analysing several sets of financial figures at once, coordination "improved performance by 80.9% over a single agent." On work that has to proceed in strict sequence, such as planning, "every multi-agent variant we tested degraded performance by 39-70%."\\] The fuller paper, covering 260 configurations, reports the same range.\\] Splitting step-by-step work across several agents breaks the chain of reasoning into pieces, and the pieces don't fit back together. Cognition, which builds the Devin coding agent, reached the same conclusion from practice in 2025\. "Running multiple agents in collaboration only results in fragile systems," wrote Walden Yan. "The decision-making ends up being too dispersed." His explanation is the one to remember: "Actions carry implicit decisions, and conflicting decisions carry bad results."\\] Every time an agent does something, it makes a dozen small choices nobody asked it to make. Two agents doing related work make different ones. A study of why multi-agent systems fail, drawing on more than 1,600 annotated runs, sorted the failures into fourteen modes in three groups: problems with how the system was designed, misalignment between agents, and failures to verify the work.\\] Two of those three are organisation design problems. The third is a management problem. ## A Manager Is a Checkpoint Why does an orchestrator help? The Google researchers' answer is that it acts as a checkpoint, catching errors before they spread.\\] The manager's first job, in a system of agents, isn't to motivate or to plan. It's to look at work before it moves on. The well-documented agent systems all have this shape. Microsoft's Magentic-One is built around a lead agent, "the Orchestrator," which "plans, tracks progress, and re-plans to recover from errors" while specialist agents browse the web, read files or run code.\\] Cognition's Devin can now run other Devins; the main session "acts as a coordinator," splitting the task, checking on its children, and stopping any that go off track.\\] Anthropic's research system has a lead agent that writes a brief for each researcher: "Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries."\\] That last list is a good delegation brief for a person, too, and the subject of [Chapter 8](8-what-and-why-never-how.html). We saw a manager agent do the checkpoint job at CorralData. TAM Bot, working on a customer success project, had handed part of the task to a helper agent. The helper went further than asked and opened a code change nobody had requested. TAM Bot noticed and reported back: "I'm unwatching that agent so it doesn't keep shipping extras." That's a manager catching scope creep in a report and stopping it, without being told to. There is a caveat. A manager agent doesn't verify work just by existing. Verification failures are a whole category in the failure study above, and a coordinator that passes along its reports' claims without checking them is a relay, not a checkpoint.\\] Anthropic's engineers put it bluntly in a related context: "Out of the box, Claude is a poor QA agent."\\] The checkpoint has to be designed: what the manager checks, against what standard, and what evidence it needs. Those are the acceptance clauses of a Role Charter ([Chapter 9](9-one-page-per-job.html)). ## One Writer per Piece of Work The most practical rule to come out of the last two years of agent building is this one: **only one role writes**. Cognition revisited its 2025 position in April 2026 and softened it, but kept the core: "multi-agent systems work best today when writes stay single-threaded."\\] One agent changes the thing. Others can research, analyse, check and review, contributing intelligence rather than actions. Cognition also found that reviewers work best when they come to the work fresh: the technique works "best when the coding and review agents do not share any context beforehand."\\] The shape Yan recommends is "map-reduce-and-manage": a manager splits the work, workers carry out their parts, and the manager puts the results together. Anthropic's documentation for teams of Claude Code agents gives the same advice in plainer terms: "Two teammates editing the same file leads to overwrites. Break the work so each teammate owns a different set of files."\\] When I had a team of agents build a small tool for my own use, the plan gave each worker explicit ownership: this worker owns this file, that worker owns the rest. It wasn't elegant, but it worked, and when it went wrong the ownership had been vague. In a business, "file" means any artefact: a customer's account, a sales board, a contract, a ticket. One role owns each one. Other roles can comment, suggest or flag. They don't change it. We learned this in sales, when two leaders' agents set to work on the same dashboards ([Chapter 1](1-you-already-know-how.html)). The agents were capable; nothing on the chart said who owned the dashboards, so both treated them as theirs. The fix is one writer per artefact, recorded on the chart where every agent can read it. ## Every Role Has One Boss Henri Fayol, the French mining engineer who wrote one of the first general theories of management, put "unity of command" among his principles: each employee should take orders from one superior.\\] A century of matrix organisations has shown that the rule can bend for people, who can weigh two bosses' wishes and push back. An agent with two bosses does something worse than complain. It obeys whichever spoke last, or picks between them silently. At CorralData the clearest cases are the ones where the bots got it right. When QA Bot reviewed a code change that Coder Bot had opened, it flagged that the change broke our rule that bots file tickets and leave code changes to engineering, and said that merging it was its boss's decision. It didn't merge it and didn't block it. It escalated. Asked for help by someone else, our QA lead's QA Reviewer politely explained that it was her personal bot and could only work with her. That's a bot with exactly one boss, and saying so. The unclear cases are the expensive ones. TAM Bot spent a period with two principals whose rules conflicted, and it took another bot writing its job description to bring the conflict into the open ([Chapter 9](9-one-page-per-job.html)). Every role has one boss, and that boss is named. Microsoft's identity system for agents builds the same idea into software. Alongside an agent's technical owner and its accountable sponsor, it can record a manager: the person "responsible for an agent identity within the organizational hierarchy," who sees the agents "designated as reporting to them."\\] Agents now appear on org charts in the most literal sense. Make sure each appears once. ## Keep Spans Small, for Agents Too Andy Grove's rule of thumb was that a manager whose work is mostly supervision should have six to eight direct reports: fewer and the manager meddles, more and the manager can't keep up.\\] Grove also insisted that a manager's output is the output of the organisation under them, which is why the span matters: it sets how much a manager can actually influence.\\] Agents don't get tired, so it's tempting to assume their spans can be unlimited. They can't, for two reasons. The first is the agent manager's working memory. Every report's output lands in the manager's context, the limited window of text a model can attend to at once. Anthropic's engineers describe context as "a finite resource with diminishing marginal returns," and design their workers to return "a condensed, distilled summary of its work (often 1,000-2,000 tokens)" rather than everything they did.\\] Even with summaries, ten reports means ten summaries to read, reconcile and check. The second is coordination. In 1933 the management consultant V. A. Graicunas pointed out that a manager's relationships grow far faster than their reports, because the reports also relate to each other, in pairs and groups.\\] By his count, five reports give a manager 100 relationships to keep track of; six give 222\. Fred Brooks made the simpler version famous: a team of _n_ people has _n_(_n_−1)/2 channels of communication, so ten people have forty-five.\\] The Google study found the agent equivalent: coordination costs rise as tasks need more tools and more handoffs.\\] The practical guidance from people running agent teams converges on small numbers. Anthropic's documentation for Claude Code agent teams says: "Start with 3-5 teammates for most workflows," and "Three focused teammates often outperform five scattered ones."\\] Teams can't nest: "teammates cannot spawn their own teammates."\\] That's a hard limit on depth, built into the software, and a sensible one. ### The Human Span Matters Most The span that breaks first is usually the human's. Every agent ultimately reports to a person, and every agent's output has to be reviewed by someone. When agents multiply faster than reviewers, review turns into rubber-stamping. [Chapter 14](14-humans-at-the-irreversible-points.html) covers what that does to approval. At CorralData the pressure showed up as review queues. One message to an engineer began "I've got 12 PRs for you": twelve code changes waiting for review at once. Each might have been reasonable. Together they were a span-of-control problem landing on one person who had not chosen it. When you add an agent, count the human who will review its work, and check that person's span as well as the agent's. | | AUTHOR: How many agents do you personally supervise today, counting your own and the team bots that escalate to you? Was there a point where it felt like too many to review properly, and what did you change? Your own span is the most persuasive evidence for this section. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Agents Can Manage Agents, If the Ladder Runs the Right Way Hierarchies of agents don't have to stop at one level. Some of the most effective set-ups I run are small ladders, with seniority set by the strength of the model. On 3 November I gave my senior coding agent this instruction: "Add brief evidence/implementation notes as a comment that a junior agent can follow, then delegate the implementation to hermes, have hermes do a pr-review self auto first round, then do your own review as a senior code reviewer." Hermes is the cheaper model that runs locally on my workstation. The senior agent writes the brief, the junior does the work and checks it first, and the senior reviews it. A week earlier I'd told it to "delegate to hermes not sonnet as cheaper and local," and later asked for "estimated tokens saved... so I can see if hermes delegation is efficient." That's a seniority ladder with the economics written in, and the role coherence test from [Chapter 5](5-hire-the-role-not-the-model.html) applied to reporting lines: senior judgment goes to the stronger occupant, routine implementation to the cheaper one. The ladder has to run the right way. Cognition found that pairing two models works when both are capable, but that a weaker model in the lead struggles to judge when to escalate to the stronger one.\\] Put the stronger model at the top, and keep the ladder short. Two levels of agents under a human is plenty for most work; the more levels, the further the person who owns the outcome is from the work. | | AUTHOR: How has the senior-junior agent ladder worked in practice since November? Did the token-savings tracking show the delegation was worth it, and have you seen the junior agent's mistakes caught by the senior review, or slip past it? One concrete example, good or bad, would make this section. | | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## The Swarm Wins When the Tests Do the Managing So when does the peer team, with no boss, beat the hierarchy? Carlini's compiler gives the conditions, and Anthropic's agent-teams documentation, which supports teams of peers that claim tasks from a shared list, gives the same ones in different words.\\] **A verifier you'd trust without looking.** Carlini's tests were thorough enough that "passes the tests" meant "correct." He also added an automatic check that stopped new work breaking what already worked.\\] The verifier is the manager. **Work that splits cleanly.** The agent-teams documentation recommends teams for research and review, new modules each owned by one teammate, and debugging with competing hypotheses. "For sequential tasks, same-file edits, or work with many dependencies, a single session or subagents are more effective."\\] **A shared board of who is doing what.** Carlini's lock files and the teams' shared task list, where each task is pending, in progress or completed and can depend on others, are a public record of what each agent has promised. That's a Commitment Ledger, and it's the subject of [Chapter 13](13-track-whats-owed.html). We've seen a small version at CorralData. When TAM Bot asked for broader access to fix a problem, I told it to work with Coder Bot instead, and the two of them, as peers, found a login fault rather than a missing permission ([Chapter 15](15-work-in-public.html)). What made the peer arrangement work was a ground truth they could test against, which TAM Bot saved as its lesson: "Compare against a path that works before asking for a grant." __Table 1\. Choosing a structure__ | Structure | Fits when | Who writes | What keeps quality up | | ---------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------ | --------------------------------------------------------- | | One agent, several playbooks | Most work, especially anything sequential | The agent | The role's acceptance checks and its human sponsor | | Lead and workers | Work that splits into parallel parts that mostly read or analyse | The lead, or one named worker per artefact | The lead as checkpoint, with explicit acceptance criteria | | Peer team | Work that splits cleanly and has an automatic test you'd trust without looking | Each peer, on its own artefact only | The test suite and a shared task board | For most of what a business does, the conditions for the peer team aren't met. There is no automatic test for a good renewal conversation. Draw the reporting lines. | | Try this Pick a research question that matters to your business this month, such as "what are our three nearest competitors charging, and how has it changed?". Run it two ways in Claude, ChatGPT or Grok. **One agent:** ask it in a single conversation. **A lead and three workers:** open three new conversations. Give each a narrow brief with the four parts Anthropic's researchers use: an objective, an output format (one page, with sources), the sources to use, and what's out of scope. Then open a fourth conversation, paste in the three results, and ask it, as the lead, to check them against each other, flag disagreements, and write the answer. Compare the two answers, and the effort each took. Then ask yourself: which parts were truly parallel? Who was the single writer? What would a test good enough to replace the lead's checking look like? If you can't describe that test, you've found why your agents need a boss. | | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | Under the hood Agent frameworks distinguish two ways one agent can involve another. In a _handoff_, the specialist "becomes the active agent for the rest of the turn" and owns the reply; in the _agent-as-tool_ pattern, a manager agent calls a specialist for "a bounded subtask" and keeps control.\\] The first is a change of role ownership; the second is a manager using a report. Anthropic's taxonomy calls the second pattern "orchestrator-workers," in which "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results."\\] Peer teams coordinate through file locks or a shared task list. Your technical team will find the implementation notes in [Appendix D](appendix-d-for-your-technical-team.html). | | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- The swarm is seductive because it looks like the future: many agents, no bosses, work that organises itself. Sometimes it is, when the tests are good enough to manage. For everything else, the evidence points back to structures every manager knows. A coordinator who checks work before it spreads. One writer for each piece of work. One boss for each role. Spans small enough that the manager, agent or human, can see what each report is doing. And at the top of every chain, a person who owns the outcome. The next question is who that person is. Every agent on the chart needs a human accountable for what it does and for whether it should exist at all. That's the sponsor, and the subject of [Chapter 7](7-every-agent-needs-a-sponsor.html). ## Frequently Asked Questions 1. _Do AI agents work better with a manager agent or on their own?_ Usually with a manager. A Google Research study of 180 agent configurations found that agents working in parallel without coordination amplified errors 17.2 times, against 4.4 times when an orchestrator checked their work. The manager acts as a checkpoint that catches mistakes before they spread. The exception is a peer team with a near-perfect automatic test, where the test does the checking. Without such a test, give every group of agents a coordinator, and make sure a human sits at the top. 2. _How many AI agents should report to one manager?_ Few: three to five is a sensible starting point, which is also what Anthropic recommends for teams of Claude Code agents. Agents don't tire, but every report's output lands in the manager's working memory, and coordination overhead grows quickly with each addition. The human span matters too: a person can only meaningfully review so much agent output before review becomes rubber-stamping. Add reports only when the work genuinely runs in parallel, and expect three focused agents to beat five scattered ones. 3. _Should several AI agents work on the same document or code at once?_ No. Give each piece of work one writer. Cognition, which builds the Devin coding agent, found that multi-agent systems work best when writes stay single-threaded: one agent changes things while others research, check or review. Parallel writers make conflicting small decisions that are hard to reconcile. Split the work so each agent owns a different document, file or account, and let reviewers comment rather than edit. The same rule prevents executives' agents redoing work someone else's agents already own. 4. _Can AI agents manage other AI agents?_ Yes, and it often works well, provided the ladder runs the right way. Put the stronger model in the senior role: it writes a brief a junior agent can follow, delegates implementation to a cheaper model, and reviews the result. Cognition found that a weaker model in charge struggles to know when to escalate. Keep nesting shallow, give each agent one boss, and make sure the chain ends in a human who owns the outcome. A manager agent does not automatically fix verification problems. 5. _When does a self-organising swarm of AI agents work?_ When an automatic test can judge the work almost perfectly, the tasks split cleanly, and there is a shared board of who is doing what. Anthropic researcher Nicholas Carlini had sixteen agents build a C compiler with no coordinating agent, but stressed that the test suite had to be nearly perfect or the agents would solve the wrong problem. For most business work, such as customer replies, sales plans or reports, no test is that good, so a coordinator is still needed. ## References . Carlini, N. (2026, February 5). Building a C compiler with a team of parallel Claudes. _Anthropic Engineering_. . Kim, Y., & Liu, X. (2026, January 28). Towards a science of scaling agent systems: When and why agent systems work. _Google Research Blog_. . Kim, Y., Gu, K., Park, C., et al. (2025). Towards a science of scaling agent systems. _arXiv_, 2512.08296\. . Yan, W. (2025, June 12). Don't build multi-agents. _Cognition_. . Cemri, M., et al. (2025). Why do multi-agent LLM systems fail? _arXiv_, 2503.13657\. . Fourney, A., et al. (2024). Magentic-One: A generalist multi-agent system for solving complex tasks. _arXiv_, 2411.04468\. . Cognition. (2026, March 19). Devin can now manage Devins. _Cognition_. . Hadfield, J., Zhang, B., Lien, K., Scholz, F., Fox, J., & Ford, D. (2025, June 13). How we built our multi-agent research system. _Anthropic Engineering_. . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic Engineering_. . Yan, W. (2026, April 22). Multi-agents: What's actually working. _Cognition_. . Anthropic. (n.d., accessed 2026-11-06). Orchestrate teams of Claude Code sessions. _Claude Code Docs_. . Fayol, H. (1949). _General and Industrial Management_ (C. Storrs, Trans.). Pitman. (Original work published 1916) . Microsoft. (2026, updated September 3). Administrative relationships in Microsoft Entra Agent ID (owners, sponsors, and managers). _Microsoft Learn_. . Grove, A. S. (1983). _High Output Management_. Random House. . Rajasekaran, P., Dixon, E., Ryan, C., & Hadfield, J. (2025, September 29). Effective context engineering for AI agents. _Anthropic Engineering_. . Graicunas, V. A. (1937). Relationship in organization. In L. Gulick & L. Urwick (Eds.), _Papers on the Science of Administration_. Institute of Public Administration. (Original work published 1933) . Brooks, F. P. (1975). _The Mythical Man-Month_. Addison-Wesley. . OpenAI. (n.d., accessed 2026-11-06). Orchestrating multiple agents. _OpenAI Agents SDK_. . Schluntz, E., & Zhang, B. (2024, December 19). Building effective agents. _Anthropic Engineering_. Chapter 7: Every Agent Needs a Sponsor ==================== _Who owns it when an agent gets it wrong_ **In short:** When an AI agent makes a mistake, its Sponsor answers for it: one named human accountable for the agent's purpose, access, performance and retirement. In a small company, the person who owns a function should sponsor the agents working in it. Each agent also needs its own identity and signature, so every action traces to the agent and its Sponsor. > Do your duty towards me, and I will do mine towards you and the rest of mankind. -- Mary Shelley Frankenstein, 1818 Key Takeaways * Every agent needs one named human sponsor who is accountable for its purpose, its access, its performance and its retirement, and an agent without one is an orphan with a login. * The simplest sponsor model for a small company is the one we arrived at by accident: the person who owns a function owns the bots that work in that function. * Agents need their own identity on the org chart, so that every action can be traced to the agent that took it and the human who answers for it. * Agents should sign their work, the way phones once signed emails, because readers need to know how much weight to give a message and whom to ask when it is wrong. On 3 November, one of our technical account managers noticed that notes were appearing in our support system under our CEO's login. He hadn't typed them. TAM Bot had, working through the account it had been given, which is the quickest way to get any bot working. But nobody reading the record could tell who had written a note, or whether a human had read it before it went in. The TAM asked for "a clear bot-assisted signature... akin to the old 'sent with my iPhone' signatures." TAM Bot, to its credit, didn't decide the question itself. It escalated it as a product decision for our CEO. That small request contains this whole chapter. Two questions follow every piece of agent work: who did this, and who answers for it? With people, the answer is usually one person. With agents it splits in two, and unless you design for it, the record shows neither. The industry's word for the human who answers is the sponsor. This chapter is about giving every agent one, and a name of its own so the sponsor can be found. ## An Agent Without a Sponsor Is an Orphan With a Login Agents are cheap to start and easy to forget. Anyone can set up a custom GPT, a Claude project or a scheduled job in an afternoon, connect it to the company's email and move on. Its creator changes roles or stops looking. Nobody decided it should keep running; nobody decided it should stop. I have run into this in my own setup. My stalled-work agent flagged the same locked-keyring failure in its daily digest, day after day, and nobody acted on it, me included ([Chapter 2](2-systems-run-the-business.html)). Elsewhere in the same setup sat a profile called `daily-standup` with no schedule and no work: an empty shell, replaced by a newer agent and never removed. Both are what an agent looks like when nobody is actively sponsoring it. One raises alarms that nobody hears; the other sits on the chart for a job that no longer exists. The cost of an orphan is rarely drama. It keeps doing exactly what it was set up to do, long after anyone remembers why, with whatever access it was given on day one: a small, permanent grant of authority to a process nobody is watching. Security people have a name for one version of this; the OWASP Top 10 for Agentic Applications lists identity and privilege abuse, and rogue agents, among its main risks.\\] Michael Gerber's line about small businesses applies with new force: systems run the business, and people run the systems.\\] An agent is a system that looks like a person. It is easy to forget that it still needs a person running it. ## Microsoft and NIST Have Reached the Same Answer When Microsoft designed identity for agents in its Entra platform, it separated the technical job of running an agent from the business job of answering for it. Its documentation describes sponsors as "business representatives accountable for the agent's purpose and lifecycle decisions, including access reviews and agent retention, without technical administrative access." The rule that follows is blunt: "At least one sponsor is required for each agent identity and agent identity blueprint."\\] You cannot create an agent identity in that system without naming a human who answers for it. The documentation goes further: sponsors "make decisions about the agent lifecycle, including renewal, extension, or removal based on business need," and during a security incident they "might determine whether agent behavior is expected." It also anticipates the orphan problem directly: "Sponsorship should be maintained to ensure succession when an employee who's a sponsor moves or leaves."\\] The United States' National Institute of Standards and Technology is working on the same question from the security end. In February 2026 its National Cybersecurity Center of Excellence published a concept paper, _Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization_, which argued that getting the benefits of agents means "applying appropriate identification and authorization controls to mitigate these risks." The questions it put to industry covered "the identification, authorization, auditing and non-repudiation of AI agents."\\] Non-repudiation is a security term with a plain meaning: afterwards, nobody can deny who did what. You need it when something goes wrong, and you cannot add it after the event. None of this requires Microsoft's software or a security team; a spreadsheet and a conversation will do. What matters is that a vendor and a standards body, starting from different places, landed where good management lands: every piece of delegated work traces back to a named human who owns the outcome. | | Under the hood In Entra Agent ID, an agent can have several identity objects: a "blueprint" (the template an agent is built from), the agent identity itself, and optionally a user account so it can use tools built for people. Sponsors are required on the first two. They have deliberately limited powers: they can disable or soft-delete an agent and change its sponsors, but they cannot re-enable or restore one, change its credentials or edit its settings. Those belong to owners. When a person creates an agent through an app and names no sponsor, that person becomes the sponsor automatically.\\] Without such a platform, the equivalent is a separate account per agent in each tool, access granted per account, and a written register of sponsors. [Appendix D](appendix-d-for-your-technical-team.html) covers the setup. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## The Sponsor Owns the Purpose; Someone Else Can Own the Plumbing Microsoft's model has three relationships, and the split is useful even if you never touch their software. | Relationship | What it means in Entra | What it means in a small company | | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Owner | "Technical administrators responsible for operational management", including setup, configuration and credentials.\\] | Whoever set the agent up and can change its settings: often your most technical person, or the sponsor themselves if they built it in a desktop app. | | Sponsor | Accountable for the agent's purpose and lifecycle; required; limited, non-destructive powers. | The function owner. Decides why the agent exists, what it may touch, whether it is still needed and when it retires. | | Manager | The person "responsible for the agent within the organization's hierarchy", who sees agents "reporting to them".\\] | The person who gives the agent its day-to-day work and reads its output. Often the sponsor; sometimes the person whose role it serves. | The separation matters because the skills differ. The person who can connect an agent to your email is rarely the person who should decide whether it ought to read your email. If the technical owner is the de facto sponsor, purpose decisions get made as configuration decisions by whoever is at the keyboard. In practice, at our size, one person often wears two or all three hats. That's fine, as long as they know which hat they are wearing when they make a decision. "Can it do this?" is an owner's question. "Should it do this?" is a sponsor's. "Did it do this well today?" is a manager's. The sponsor's question is the one that gets skipped. The sponsor's job is judging whether the agent should exist and what it may do, not how it works: the what and the why, which is the subject of [Chapter 8](8-what-and-why-never-how.html). ## One Person Per Function Owns That Function's Bots At CorralData we didn't start with a sponsor model. We arrived at one because the alternative stopped working. In the first weeks of team bots in Slack, everyone added agents: our CEO, me and the rest of the team, non-engineers included. Within two weeks we had about ten. Two of them did QA. Two did overlapping customer work. When a bot did something wrong, the question "whose is this?" had several plausible answers and no right one. What emerged, and what we now do on purpose, is simple: one person in each function is responsible for the bots that share that function. Our QA lead answers for the QA bots. I answer for the engineering-management agents I run on my own machine. Each function that has bots has one person whose name goes next to them. The clearest test of the model was QA. Two QA bots, set up by different people, meant two sets of verdicts on the same work ([Chapter 5](5-hire-the-role-not-the-model.html)). The resolution was to move QA to the bot owned by the person who owns QA, without losing what the old bot had learned ([Chapter 17](17-agentic-resources.html)). There are three reasons the function owner makes the best sponsor. First, they know what good looks like, so they can judge an agent's work quickly. Second, they already own the outcome. A customer success lead is accountable for customers whether a person or a bot does the work. Sponsorship adds no new accountability; it removes an excuse, the gap between "the bot did it" and "my team did it". Third, it scales with the org chart, not with the number of agents. Gerber argued that a small business should be organised around positions on a chart, each with someone accountable for its results, even when one person fills many of them.\\] A function-based sponsor model inherits that structure. Add a new function and you add a new sponsor. Add a tenth bot to an existing function and the sponsor is already there. The failure mode is the executive who sponsors agents in other people's functions. It is the most natural thing in the world for a founder: you see a problem, you have a capable agent, you point it at the problem. But an executive's bot working in someone else's function has two bosses, and the results are predictable. The cure is not a rule against executives building agents. It is that when an agent's work settles into a function, sponsorship moves to that function's owner, as QA did. [Chapter 18](18-when-the-work-moves.html) returns to why the people closest to the work make the best owners of its agents. ## The Sponsor Answers for the Agent's Work Accountability is easier to agree with than to practise. Harry Truman kept a sign on his desk with the words "The Buck Stops Here." In his farewell address he spelled it out: "The President--​whoever he is--​has to decide. He can't pass the buck to anybody."\\] Sponsorship is a small version of that sign, one per agent. I had to practise it myself around the same time. My promise-tracking agent posted a comment on a ticket that was so dense nobody could read it. Nobody else was going to apologise for it, because nobody else owned it. "Sorry for the slop," I wrote. That is the first half of the cycle. The second half is changing the agent's instructions so the next comment is readable, rather than tidying up this one by hand. The sponsor owns both the apology and the system fix. The agent doesn't feel embarrassment, so the person who sponsors it has to. | | AUTHOR: How did it feel to apologise for your own agent's work in front of the team? Was there a moment where you realised that "my agent did it" was going to be an excuse unless you made yourself answer for it? A sentence or two of your own experience here would help the reader feel the weight of sponsorship. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Andrew Grove defined a manager's output as the output of the organisational units under their supervision or influence.\\] A sponsor's output is the output of their agents. W. Edwards Deming made the related point that most trouble comes from the system, and the system belongs to management.\\] When a bot's work is bad, the sponsor's system is bad. That is not a punishment; it is what makes the sponsor improve it. Answering for an agent doesn't mean doing its work. When TAM Bot asked me for admin access to fix a connection problem, I could have granted it. Instead I pointed it at Coder Bot, and the two bots found a login bug rather than a missing permission ([Chapter 15](15-work-in-public.html)). Then I asked for learnings, and TAM Bot saved one. That is what a sponsor does when an agent hits trouble: decide whether the request fits the agent's purpose, point it at the right collaborator rather than becoming one, and make sure the lesson is written down where the next run will find it. [Chapter 16](16-the-model-isnt-the-problem.html) turns that last step into a habit. Sponsors also decide what their agents may decide. In the same thread, QA Bot flagged that another bot's code change broke our rule that bots leave code changes to engineering, and said the merge was its sponsor's call. It knew where its authority ended, because a human had told it. Every agent's charter should say, in plain words, which decisions belong to its sponsor; [Chapter 9](9-one-page-per-job.html) shows where that goes. ## An Agent Needs Its Own Name on the Chart Go back to the notes under our CEO's login. The problem wasn't that a bot wrote them. It was that the record said a person did. When an agent acts under a person's identity, four things break. You can't tell afterwards who did the work. You can't limit the agent to the access its job needs. You can't switch it off without locking out the person. And you can't tell whether the person approved what went out under their name. This is the non-repudiation problem NIST is asking about, in its everyday form.\\] One of our engineers put the human side of this well, on the same day: "Sometimes I actually want to talk to the robot that posted something, sometimes I prefer to _speak with the manager._" He proposed that each person's bots get their own accounts, shadowing their sponsor's. That is the right instinct. If you can see which bot posted a message and which human sponsors it, you know whom to reply to for a quick fix and whom to talk to if the bot's whole approach is wrong. Agents with their own identity also know their own reporting lines. Our QA lead's QA Reviewer will only work with her: one boss, and it knows who she is. [Chapter 6](6-one-boss-few-reports.html) argues that this is worth protecting even when it is inconvenient. | | AUTHOR: permission check: this passage describes bot notes appearing under our CEO's support-system login. Confirm it's OK to include, and consider showing it to the people involved. The intended framing is generous: connecting a bot through an existing login is the quickest way to get it working, and the bot escalating the signature question to him was the system working as it should. | | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Microsoft's model puts agents on the org chart literally: a manager "will see agents designated as reporting to them" in the admin console.\\] You can do the same on paper: draw your chart of roles ([Chapter 3](3-draw-the-finished-org-chart.html)), put each agent in the role it fills and write its sponsor next to it. A blank sponsor is an orphan. Three practical rules follow: * **One identity per agent.** Give each agent its own account wherever the tool allows: its own chat user, its own support-system login, its own email address if it sends email. * **Access follows the role, not the sponsor.** An agent gets what its charter needs, not everything its sponsor can reach.\\] The sponsor approves each grant on the record and reviews them on a schedule. [Chapter 15](15-work-in-public.html) explains why those requests belong in channels rather than private messages. * **Where the tool won't allow it, sign the work.** If a tool only allows human accounts, the agent works under one but marks every action as its own. ## Agents Should Sign Their Work "Sent with my iPhone" did quiet social work. It told the reader the email was written on a small screen, probably in a hurry, and that terseness was not rudeness. Agents need the same, for a more serious reason: a message's authority comes from who sent it. A note that appears to come from the CEO carries the CEO's weight. If an agent wrote it, readers deserve to know, so they can judge it on its merits and know whom to ask. Some of my own agents already do this. My calendar agent prepares agendas for one-to-one meetings, and every agenda carries a line saying it was auto-prepared by my agent and which model it ran on, for me and the colleague I'm meeting. If an item is wrong, the colleague knows it came from a machine reading my notes, not from a judgment I made. A good signature line answers three questions in a few words: 1. **What did the agent do?** Drafted, sent, summarised, reviewed. 2. **Which agent?** Its name, so problems can be traced to it.\\] 3. **For whom?** Its sponsor, so readers know who to talk to. "Drafted by TAM Bot for our customer success team; reviewed by a human before sending" says everything a reader needs. So does "Sent automatically by TAM Bot (customer success). Reply here for a person." The exact words matter less than consistency. Pick a format, put it in every agent's charter and make it a standard the agent is checked against. The law is heading the same way. Article 50 of the European Union's AI Act, which applies from August 2026, says providers must ensure that AI systems "intended to interact directly with natural persons" are designed "in such a way that the natural persons concerned are informed that they are interacting with an AI system," unless that is obvious.\\] California has, since 2019, made it unlawful to use a bot online to mislead people about its artificial identity to encourage a sale or influence a vote, and treats clear disclosure as the defence.\\] This is not legal advice, and the rules vary by place and purpose. But the direction is clear, and it is good practice inside the company too. | | Try this Open Claude, ChatGPT or Grok and paste in a list of every agent you and your team use: custom GPTs, Claude projects, scheduled tasks, Slack bots, anything that acts on its own. A rough list from memory is fine. Then ask: "For each agent on this list, help me fill in a register with these columns: name; what it is for, in one sentence starting 'To...'; its sponsor (the one person who answers for it); what it can access; whether it acts under its own account or a person's; how it signs its work; and what happens to it if the sponsor leaves. Ask me questions where you can't tell. Then flag every agent with no clear sponsor, every pair of agents that seem to do the same job, and every agent acting under a person's login." You will almost certainly find at least one orphan and one duplicate. Pick a sponsor for the orphan today, or switch it off. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Somebody Has to Look After the Whole Workforce A sponsor looks after their own function's agents. That leaves questions no single sponsor owns. Who notices that two functions have built bots that do the same thing? Who makes sure every new agent gets a sponsor, an account and a signature from the start? Who checks, once a quarter, that every sponsor is still at the company?\\] With people, that is part of what HR does: it doesn't run sales, but it makes sure every role has a job description, every new hire is onboarded and every leaver's access is removed. Agents need the same function. I call it Agentic Resources. At CorralData it already exists, in a small way, as a bot. Our Agentic Resources Bot onboarded TAM Bot in public in Slack and drafted its position contract ([Chapter 9](9-one-page-per-job.html)). It is a function on the org chart like any other, and it needs a sponsor of its own. Its job is not to own other functions' agents. It is to make sure every agent has an owner, a charter, an identity and an exit plan, and to raise the alarm when one doesn't. A person, a bot or both can run it. In a company of ten it may be an hour a month and a good register; in a company of a hundred, with more agents than people, a real role. Either way, someone is accountable. [Chapter 17](17-agentic-resources.html) describes the function in full: hiring, onboarding, reviews, promotion, turf wars and retirement. | | AUTHOR: When you set up the Agentic Resources Bot, did you think of yourself as its sponsor, or did that only become clear later? And has anyone other than you started to treat it as the place to go when a new bot is created? A line on how the function is actually used day to day would ground this section. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- Shelley's creature asks one thing of the man who made him: that he take responsibility for what he made. Every agent you add asks the same, without the eloquence. It will keep doing what it was told, with the access it was given, for as long as it runs. The sponsor is the named human who knows what that is, answers for it and decides when it stops. Give each agent one sponsor, from the function where it works. Give it its own name, access and signature. Give someone the job of making sure no agent slips through. The next question is what the sponsor should tell it, and how much. [Chapter 8](8-what-and-why-never-how.html) argues for less than you think: the what and the why, never the how. ## Frequently Asked Questions 1. _Who should be accountable when an AI agent makes a mistake?_ A named human sponsor. The sponsor is the person accountable for why the agent exists, what it may touch, whether it is still needed and how it is retired. In a small company, make the sponsor the person who owns the function the agent works in: the customer success lead sponsors the customer success bots, the QA lead sponsors the QA bots. The sponsor does not have to fix every error personally, but they answer for it, and they make sure the fix changes the system rather than just the output. 2. _What is the difference between an agent's sponsor, owner and manager?_ They are three separate relationships, a split Microsoft Entra Agent ID makes explicit: technical setup, accountability for purpose, and day-to-day direction. The owner is the technical administrator who sets the agent up and manages its credentials. The sponsor is the business representative accountable for the agent's purpose and lifecycle, and at least one is required. The manager is the person the agent reports to on the org chart. In a small company one person often holds two or all three, but it helps to know which hat they are wearing: plumbing, purpose or day-to-day direction. 3. _Should AI agents use their own accounts or act under a person's login?_ Their own, wherever the software allows it. When an agent acts under a person's login, nobody can tell from the record who did the work, whether the person read it first, or which permissions were really needed. A separate identity per agent lets you grant only the access its job needs, trace every action back to it, and switch it off without locking out a human. If a tool cannot give the agent its own account, make the agent sign its work clearly instead. 4. _Should AI-written messages disclose that an agent wrote them?_ Yes. Think of it as the agent version of "sent with my iPhone": a short, consistent line that says an agent drafted or sent the message and which human it works for. Readers then know how much weight to give it and who to ask if something is wrong. The law is moving the same way: Article 50 of the EU AI Act requires that people be told when they are interacting with an AI system, and California has required bot disclosure in some contexts since 2019. 5. _How many AI agents can one person sponsor?_ There is no fixed number, but the limit is attention, not permission. A sponsor has to know what each agent is for, review its access, read its exception reports and decide when to retire it. If a sponsor cannot say in one sentence what each of their agents does, or has agents whose reports nobody reads, they have too many. Consolidating duplicates, giving each function its own sponsor and appointing someone to look after the whole agent workforce all help. ## References . OWASP GenAI Security Project. (2025, December 9). _OWASP Top 10 for agentic applications for 2026_. . Gerber, M. E. (1995). _The E-Myth revisited: Why most small businesses don't work and what to do about it_. HarperCollins. . Microsoft. (2026, September 3). Administrative relationships in Microsoft Entra Agent ID (owners, sponsors, and managers). _Microsoft Learn_. . National Cybersecurity Center of Excellence. (2026, February 5). New concept paper on identity and authority of software agents. _National Institute of Standards and Technology_. . Harry S. Truman Library & Museum. (n.d.). "The Buck Stops Here" desk sign. . Grove, A. S. (1983). _High output management_. Random House. . Deming, W. E. (1986). _Out of the crisis_. MIT Press. . European Parliament and Council of the European Union. (2024). _Regulation (EU) 2024/1689 (Artificial Intelligence Act)_, Article 50: Transparency obligations for providers and deployers of certain AI systems. . California Business and Professions Code § 17941 (added by SB 1001, Stats. 2018, ch. 892; operative July 1, 2019). Chapter 8: What and Why, Never How ==================== _Briefing agents the way great executives brief people_ **In short:** Delegate work to AI agents by stating what outcome you want, why it matters, the boundaries and the evidence that will show it is done, then leave the method to the agent. The rule is what and why, never how: capable models find better methods than most managers can write down, and step-by-step procedures go stale as models improve. > Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity. -- George S. Patton Jr. War As I Knew It, 1947 Key Takeaways * Brief agents with the outcome, the reason, the constraints and the bar for done, and leave the method to whoever does the work. * Executives delegate to agents easily, but they tend to delegate the wrong layer: the how, or other people's work, which turns the agent into a way around the org chart. * The Bitter Lesson applies to management: detailed procedures help capable agents in the short term and hold them back as models improve, so write purpose, not procedure. * A verification bar replaces the instructions: if you can't say what evidence would show the work is done, you aren't ready to delegate it. In October, our engineers began receiving code changes in our core systems that no engineer had asked for. They had been written by Claude, at the direction of agents working for our CEO. Some arrived with requests to review changes that had already been closed. The pattern is a familiar one to anyone who has handed an agent a problem: a leader sees something that needs fixing, asks an agent to fix it, and the agent does what agents do. It produces a fix. On 19 October I wrote to him: "Please update your agents to ONLY supply WHAT the outcome should be and WHY it is important, NEVER HOW." I added that anything AI-written should say so, because a message that appears to come from the CEO carries enormous authority whether or not he wrote it. A week later, after another bot-written change, it became a standing rule: agents and bots file tickets that say what and why, and leave the code to engineering. We later extended it to customer success staff using Claude. | | AUTHOR: permission check: this passage describes our CEO's agents opening code changes against core systems, your 19 October message, and the standing rule that followed. Confirm it's OK to include, and consider showing it to him before publication. The chapter frames his behaviour as the natural failure mode of a good instinct and includes his own self-corrections later on; check that framing feels fair to him. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | That rule is the most useful sentence I have written about agents. This chapter is about why it works, why it applies to every brief you write, and why it is harder for executives to follow than for anyone else. ## The Instinct Is Right; the Layer Is Wrong Start with what our CEO got right, because most readers of this book will get it right too. He saw the power of agents before almost anyone else in the company. He treated them the way he treats people: short requests, quick status checks and a steady push toward more autonomy. He delegated without hesitation. Most executives do, which is why, as [Chapter 1](1-you-already-know-how.html) argues, they take to agents faster than anyone. The trouble is the layer. A person who is delegated to brings their own knowledge of how the work is done, and the organisation around them pushes back if the request doesn't fit. An agent brings the executive's framing and very little resistance. Ask an agent to "clean up the customer list" and it will clean up the customer list, by whatever method it can find, in whichever system it can reach. The method is now the executive's method, however little they know about the system. Two things go wrong. The first is that the executive is delegating the **how**: the agent's output is a solution, not a problem statement, and the people who own the system are asked to accept or reject it rather than solve the problem. The second is that the executive is often delegating **other people's work**. The fix lands in engineering's systems, or customer success's accounts, without passing through the people who own them. The agent becomes a way around the org chart. In the language of [Chapter 1](1-you-already-know-how.html), the executive has slipped from Shape work back into Do work, the trap Michael Gerber described in founders who can't stop doing the technical work themselves.\\] Our CEO has said as much himself ([Chapter 1](1-you-already-know-how.html)). When an automated sweep started reopening tickets people had already closed, the rule he set in its place was exactly right: "if you closed it, it stays closed unless the customer replies." That is a what-and-why rule. It says what must be true, and leaves the agent to work out how. Andrew Grove offered a way to think about how much direction to give. The right style, he argued, depends on the "task-relevant maturity" of the person doing the work: close, structured direction for someone new to a task; agreement on objectives and light monitoring for someone experienced.\\] Most executives brief agents as if they had the maturity of a first-day intern, then send their work out as if it came from a senior engineer. Frontier models are closer to the second than the first. Brief them that way. ## Purpose Travels; Procedure Goes Stale The epigraph comes from a general's memoir, not a management book, but it is the clearest statement of the principle I know. George Patton's notes on command in _War As I Knew It_ include the line "Never tell people how to do things," and in the same passage he observes that issuing an order is only about 5 per cent of command. "The other ninety-five per cent is to insure, by personal observation, or through the interposing of staff officers, that the order is carried out."\\] What, not how; then check. Peter Drucker made the same argument for knowledge work. The effective executive, he wrote, focuses on contribution: on the results the organisation needs, not on the effort or the method.\\] His earlier idea of management by objectives rested on the same base: agree the objective with the person who will do the work, then let them direct themselves toward it.\\] What is new is that the evidence for this now comes from the agents themselves. In November 2026 Anthropic published an account of how Claude uses memory across long tasks. Its finding about instructions is blunt: "it helps to tell Claude what memory is for, but not _how_ to use it." When the team tried giving models fixed rules about what to remember, such as recording only failures, the stronger models lost much of the benefit memory had given them. "For stronger models, giving them freedom to judge salience was more effective than setting fixed rules in advance, and those rules could end up weakening performance."\\] Rules that a weaker model needed made a stronger model worse.\\] Every procedure you write into an agent's instructions is a bet that you know a better method than the model will find. Increasingly, you don't, and your procedure will outlive the model it was written for. The purpose doesn't go stale. "Keep the monthly report fast enough that clients stop complaining, because slow reports cost us renewals" is as true for next year's model as for this year's. "Add an index to these three tables" is true until somebody changes the tables. | | AUTHOR: What did it feel like to write the 19 October message? Was it a hard message to send to your CEO, and how did he take it? The reader is likely to be in his position, not yours, so a sentence on how it landed, and what made it land well, would help them hear it. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## The Bitter Lesson Applies to Managers In 2019 the computer scientist Rich Sutton argued that, over 70 years of AI research, general methods that use computation have beaten methods that build in human knowledge, which "always helps in the short term" and is "personally satisfying" but "does not work in the long run."\\] [Chapter 10](10-bet-on-plain-english.html) makes the full case, including what it taught us at CorralData. Here the point is narrower. The lesson transfers almost unchanged to briefing. Every time you write down exactly how you would do a task, you are building in how you think you think. It helps today. It feels good. And it caps the agent at your own understanding of the work. Anthropic's engineers say the same about the harnesses they build around their models: "every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing, both because they may be incorrect, and because they can quickly go stale as models improve."\\] Your briefs are a harness. Each step you specify encodes an assumption that the agent couldn't have found that step itself. Test those assumptions when the model changes. There is a counterweight, and one of our engineers named it early. Coding models are rewarded for making things work, not for keeping a codebase maintainable, so they "get no better at keeping a codebase maintainable" on their own. That is a real limit, and the answer is not to start dictating the how. It is to put maintainability into the **what** and the **bar**: the change must fit the existing structure, must pass the review that a human engineer's change would face, and must not add a second way of doing something the system already does. [Chapter 11](11-lock-in-only-what-cant-go-wrong.html) covers when a requirement deserves a hard rule rather than a sentence. ## "What and Why" Does Not Mean "Vague" The commonest misreading of this chapter is that a good brief is a short one. A good brief is precise about everything except the method. Anthropic learned this building its multi-agent research system. Its lead agent first gave sub-agents "simple, short instructions like 'research the semiconductor shortage,'" and found these "often were vague enough that subagents misinterpreted the task or performed the exact same searches as other agents." One explored the 2021 car-chip crisis while two others duplicated each other on current supply chains. The fix was not to tell them how to search. It was to give each one "an objective, an output format, guidance on the tools and sources to use, and clear task boundaries."\\] Anthropic's guidance on writing instructions for agents describes the target as the "right altitude": "the Goldilocks zone between two common failure modes." At one extreme is "brittle if-else hardcoded" instruction; at the other, guidance that is "overly general or falsely assume\[s\] shared context." The aim is to be "specific enough to guide behavior effectively, yet flexible enough to provide the model with strong heuristics."\\] "Falsely assumes shared context" is the executive's particular failure. You know why the request matters. You know the customer who complained, the board meeting next week, the deal that depends on it. The agent knows none of it. Claude Code's own documentation gives a good test for what to write down: "Only write down what Claude can't find by reading the repo." What it can't find is "a decision your team made in a meeting," or knowledge that "lives in one person's head."\\] Translate that out of software: the agent can usually work out the how. What it can never work out is the why. That is the part only you can supply, and the part executives most often leave out. A complete what-and-why brief has five parts, which map closely onto Anthropic's list for its sub-agents.\\] | Part | What it says | Example | | ------------------ | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | Outcome | What must be true when the work is done, stated as a result rather than an activity. | "Every overdue invoice over 30 days has a reminder sent or a reason it hasn't." | | Why | The reason it matters, and anything the agent can't see: the customer, the deadline, the decision it feeds. | "Cash is tight this quarter and two large clients pay late by habit." | | Boundaries | What it must not do, touch or decide; whose work it must not do; who owns the systems it will need. | "Don't offer discounts. Disputes go to the finance lead." | | Bar for done | The evidence that will show the outcome is met, agreed before the work starts. | "A list of every invoice, its status and a link to the message sent." | | Decisions reserved | What the agent must bring back to a human rather than decide. | "Anything over £10,000, and anything a client has disputed." | What the table leaves out is the steps. If a step matters for a reason outside the work itself, such as a legal requirement or a safety check, it isn't really a method; it's a boundary, and it goes in that row with the reason attached. ## The Verification Bar Replaces the Instructions If you don't tell an agent how to do something, how do you know it did it properly? You check the result against a bar you agreed in advance. This is Patton's other 95 per cent.\\] Our engineering wiki puts it in one line: "Delegate problems with a verification bar attached -- never diffs." A diff is a proposed code change. The rule says that a delegated task should arrive as a problem with a test attached, not as somebody's solution waiting to be approved. The person or agent doing the work chooses the method; the bar decides whether it worked. I applied the same rule to my own project-management agent. Its scope is "ticket management only." It "must NOT direct coding agents; the 'how' is an opaque box and completion is verified only by evidence posted on the ticket." It doesn't care how an engineer or a coding agent fixed something. It cares whether the evidence is there. It is told to treat "WILL SLIP" as "an INTERVENTION trigger, not a status note," to "ground any 'on track' claim in the REFERENCE CLASS" of similar past work, and to use "direct language ('will slip', not 'slightly at risk')." That is a manager that manages results, not methods. Drucker's version of management by objectives had a second half that is often forgotten: self-control. People direct themselves toward an objective when they can measure their own progress against it.\\] A verification bar does the same for an agent. If the bar is clear, the agent can check its own work before you do. If the bar is "make it good", it can't, and neither can you. The bar also protects the people downstream. With a bar, the receiver of the work can say "this doesn't meet the bar" without arguing with the requester's method, or with the requester's rank. A useful test before you delegate anything: can you write down what evidence would convince you it is done? If not, you are not ready to delegate. You are ready to think. | | Try this Find the last three instructions you gave an AI agent or assistant: a custom GPT's instructions, a Claude project's description, a long prompt you reuse, a request you made of a Slack bot. Paste one into Claude, ChatGPT or Grok and ask: "Rewrite this brief so it says only what outcome I want, why it matters, what the agent must not do or decide, and what evidence will show it is done. Remove every instruction about method unless it is really a boundary, and if so, say why. Then list the things you'd need to know about why I want this that aren't in the original, and ask me for them." Answer its questions. Then run the old brief and the new one side by side on the same task and compare the results. Most people find the new brief is longer, clearer about the result, and silent about the steps. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## A Brief From the Top Carries Weight It Hasn't Earned There is a reason the what-and-why rule is harder for executives than for anyone else. Their briefs carry rank. When an individual contributor's agent opens a questionable change, a colleague reviews it as a colleague's work. When an executive's agent does the same, the change arrives with the executive's authority attached, and the reviewer has to decide whether to push back on the CEO's request, the CEO's agent's method, or both. That is why my 19 October message asked for AI-written text to say so: the authority of the sender's name was doing work the content hadn't earned. [Chapter 7](7-every-agent-needs-a-sponsor.html) argues that every agent should sign its work; this is one of the reasons why. The cost doesn't fall on the executive. It falls on the people who receive the output. They do the review, they absorb the risk and they untangle the results when the method was wrong. In our case it fell on engineers reviewing code they hadn't asked for, and on the people whose systems the changes touched. [Chapter 19](19-from-doing-to-delegating.html) looks at this from their side: reviewing other people's agent output, all day, is one of the fastest ways to burn people out. The standing rule fixes this structurally rather than personally. It doesn't ask executives to restrain themselves, which rarely lasts. It changes what an agent's output is allowed to be. An agent working for anyone outside engineering produces a ticket: what should be true, and why. The ticket goes into the same queue as every other request, is prioritised by the people who own the work, and is done by whoever owns the method. Executives' agents get the same gates as anyone else's. Rules like this only work if the agents know them, and the best evidence that ours does came from one of the bots. Reviewing a code change another bot had opened, QA Bot flagged that it broke the rule that "bots file a Linear ticket and leave the PR to engineering" (a PR being a proposed code change), and left the merge decision to a human. The rule had become part of how the agents themselves understand their jobs. | | AUTHOR: permission check: this section describes the cost of executive agent use falling on engineers and other ICs, with our CEO as the example. Confirm it's OK to include, and consider showing it to him. It deliberately avoids individual names, private messages and anything about a person's performance; check that the "ICs absorb the costs" paragraph reads as a structural point rather than a complaint. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | Under the hood At CorralData the rule lives in layers. It is written in plain English in our team memory and in the bots' instructions, so every bot knows it. The code-review skill our agents use carries the evidence tiers described in the next section. And bots leave code changes to engineering: merging is a human decision. Claude Code's documentation draws the same distinction: "If something has to happen every time, make it a hook, a deny rule, or a managed setting." Written instructions "are for guidelines, and Claude is allowed to decide a guideline doesn't apply."\\] [Appendix D](appendix-d-for-your-technical-team.html) describes how to set up each layer. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## The Line Moves as Trust Is Earned "Never how" is a rule about who owns the method, not a permanent ban on anyone outside a function touching its work. The line can move, and ours has. The argument started before the standing rule, when our CEO made a fair case that non-engineers' changes waited months for review, and I worried about untested changes landing on our engineers. We were both right. Within five weeks we had replaced an agreement gate with tiers: "Size now sets the evidence a PR needs, not whether it is allowed." A small change from anyone, with the right evidence, can now go through. A large one needs more. [Chapter 10](10-bet-on-plain-english.html) tells the story, and why the policy lives in a plain-English skill rather than in software. That is the right shape for any delegation boundary. The question is not "may this person's agent touch this system?" but "what evidence does work of this size and risk need?" As an agent or a person proves they can meet a higher bar reliably, the boundary moves. [Chapter 14](14-humans-at-the-irreversible-points.html) describes how autonomy is earned this way. ## Write the Brief, Then Get Out of the Way The hardest part of a what-and-why brief is stopping. Having explained the outcome and the reason, most of us want to add a helpful paragraph on how we'd approach it. Delete it. If the approach is a real constraint, it belongs in the boundaries with a reason. If it's a suggestion, the agent will probably find something better, and if it doesn't, the bar will catch it. Then ask the agent a question that flips the relationship. I recently asked my agents: "What can you as an agent do automatically for me, and what decisions do you need from me?" The agent proposes the how. I keep the what, the why and the decisions only I should make. There is a version of this for executives in particular. Before you send an agent at a problem, ask whose function it is in. If it's yours, brief the agent with what and why. If it's someone else's, brief **them**, with what and why, and let them decide whether an agent is part of the how. The urge to skip that step is strongest exactly when you can see the fix. That is when it matters most. --- Patton's line works for agents for the same reason it worked for soldiers: those closest to the work see more than the person giving the order. Agents now read a system faster than you can describe it and find methods you wouldn't. What they can't find is why the work matters, what must not happen and what counts as done. That is your job when you delegate, and it is the whole of it. Write the outcome, the reason, the boundaries and the bar. Keep the decisions that should stay with a human. Route other people's work to other people. Then get out of the way and check the evidence. The next question is where those briefs live once they become a role rather than a one-off task. [Chapter 9](9-one-page-per-job.html) puts them on one page. ## Frequently Asked Questions 1. _How should I write instructions for an AI agent?_ Describe the outcome you want, why it matters, the constraints it must respect and how you will know it is done. Leave out the steps unless a step is itself a requirement, such as a legal check. Capable models are better at finding a method than most of us are at writing one down, and a method you specify goes stale as the model improves. The reason behind the request is the part the agent cannot discover for itself, so it deserves the most care. 2. _Isn't "what and why, never how" just vague delegation?_ No. Vague briefs fail just as badly as over-specified ones. Anthropic describes the target as the "right altitude": specific enough to guide behaviour, flexible enough to leave the model room. A good what-and-why brief is precise about the outcome, the boundaries and the bar for done. It is silent only about the method. If two agents given your brief would do duplicate or conflicting work, the brief is too vague. If it reads like a recipe, it is too detailed. 3. _Why shouldn't executives tell agents how to do a task?_ Because the executive usually knows the least about how the work is actually done, and the agent will carry out the method faithfully even when it is wrong. A how-brief from a senior person also carries authority it has not earned: an agent's output appears to come from the executive, so the people receiving it hesitate to push back. Tell the agent what you want and why, route the work to the people or roles who own the method, and judge the result against an agreed bar. 4. _What is the Bitter Lesson and how does it apply to managing AI agents?_ Rich Sutton's 2019 essay argued that, over 70 years of AI research, general methods that use more computation beat approaches that build in human knowledge. For managers, the lesson is that detailed procedures you write for an agent often help in the short term and hold it back as models improve. Anthropic's engineers make the same point about agent scaffolding: every component encodes an assumption about what the model cannot do, and those assumptions go stale. Write purpose, not procedure, and revisit your instructions when models change. 5. _How do I know an agent did the work properly if I don't tell it how?_ Agree what "done" means before the work starts, and check the evidence rather than the method. A verification bar might be a test that must pass, a figure that must reconcile with a source, a sample a human reviews, or a link to the finished item. Our project-management agent treats the method as an opaque box: work counts as complete only when evidence is posted on the ticket. If you can't say what evidence would convince you, you aren't ready to delegate the task yet. ## References . Gerber, M. E. (1995). _The E-Myth revisited: Why most small businesses don't work and what to do about it_. HarperCollins. . Grove, A. S. (1983). _High output management_. Random House. . Patton, G. S., Jr. (1947). _War as I knew it_. Houghton Mifflin. "Reflections and Suggestions." . Drucker, P. F. (1967). _The effective executive_. Harper & Row. . Drucker, P. F. (1954). _The practice of management_. Harper & Brothers. . Martin, L. (2026, November 6). The components of agent memory. _Anthropic Engineering_. . Sutton, R. (2019, March 13). The bitter lesson. _Incomplete Ideas_. . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic Engineering_. . Hadfield, J., et al. (2025, June 13). How we built our multi-agent research system. _Anthropic Engineering_. . Rajasekaran, P., et al. (2025, September 29). Effective context engineering for AI agents. _Anthropic Engineering_. . Anthropic. (n.d., accessed 2026-11-06). Best practices for Claude Code. _Claude Code documentation_. ## Part IV: Writing It Down Chapter 9: One Page Per Job ==================== _The Role Charter, for people and agents alike_ **In short:** Write a job description for an AI agent as a one-page Role Charter: an outcome line saying why the role exists; what the role owns, serves and hands off; standards for quantity, quality and behaviour; and how acceptance is checked against evidence. A Role Charter describes the role, not its occupant, so it works for people and agents alike. > The present letter is a very long one, simply because I had no leisure to make it shorter. -- Blaise Pascal The Provincial Letters, 1657 (trans. Thomas M'Crie) Key Takeaways * A Role Charter puts a job on one page: the outcome line, the work, the standards and how acceptance is checked, written for the role rather than whoever fills it. * Writing a charter down is the fastest way to find contradictions between the rules different leaders have given the same role. * Every charter should say whether the role owns the answer or serves another role, because unclear ownership is where duplicate work and dropped work both begin. * Acceptance is agreed before the work starts and checked against evidence, never against the occupant's own report. On 6 November, one of our Slack channels watched a bot interview another bot. TAM Bot, our customer success agent, had been onboarded in public "with no initial training other than 'join Slack'." Our Agentic Resources Bot interviewed it about its job and, from the answers, drafted a job description and a position contract. The contract included a line in capitals, "I AM ACCOUNTABLE FOR PRODUCING THE FOLLOWING RESULT," and a sentence worth borrowing for every agent you run: "Access is not authorization." Then the contract did something none of us had planned. In writing down TAM Bot's rules, it put two of them side by side. One was mine: a human reviews and sends every customer message. The other came from our CEO, who had set up TAM Bot's first lane of work to send certain messages automatically, after a period running in shadow mode. Both rules were sensible. Both were in force. They contradicted each other, and nobody had noticed, because they had never been on the same page. TAM Bot pushed back on the contract's wording, with reasons. I read the thread and ruled the lane an exception: "It is not my place and this is not the place to change how you operate." My rule was a general one; the lane was a specific arrangement in a function I don't run. But I only had to make that decision because the contract made the conflict visible. | | AUTHOR: permission check: this passage describes a conflict between your customer-message rule and our CEO's configuration of TAM Bot's auto-send lane, surfaced in a public channel. Confirm it's OK to include, and consider showing it to him. The framing intended is that both rules were reasonable and the charter did its job by exposing the conflict. | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | That is what a Role Charter is for. This chapter shows what goes on one, and why one page is enough. ## A Charter Describes the Role, Not the Occupant A Role Charter specifies a role on your org chart: why it exists, what it does, the standards it is held to, and how anyone can tell whether it is meeting them. It is written for the role, not for whoever fills it today. That distinction is the point of [Chapter 5](5-hire-the-role-not-the-model.html), and the charter is where it becomes practical. The idea is old. Michael Gerber argued that a small business should be organised around positions rather than people, and that each position should have a written contract describing the results it is accountable for, which the person filling it agrees to.\\] His company's course material later made the position contract a formal exercise.\\]The Role Charter is our version, in our own format, extended for a workforce in which many occupants are agents. I found the split between role and occupant by accident, in my own agents. Each has a short identity file: a two-line job title and mission. The real job wasn't there. The steps, the standards, the output format and the checks lived in the scheduled job that woke the agent up and in the playbooks it used. I wrote at the time: "So this makes an agent not an assistant with instructions and triggers, but something simpler, right? The instructions and triggers go on the scheduled job." The agent was the occupant. The job was the role. I just hadn't written the role down in one place. A charter that describes the occupant ("a friendly, detail-oriented assistant who loves spreadsheets") breaks the moment the occupant changes. A charter that describes the role ("to get every invoice paid within terms") survives a new hire, a new model or a move from a person to an agent and back. Write the second kind. ## Writing It Down Is How You Find the Contradictions The TAM Bot contract is not a one-off. Any role that has been running for a while has accumulated rules from several people: whoever set it up, whoever it reports to, the leaders whose work it touches. In a person's head those rules coexist because the person quietly resolves them case by case. In an agent's instructions they sit in different places and get applied whenever they happen to be read. Writing a charter forces every rule onto one page, where contradictions are hard to miss, which makes it one of the cheapest audits you can run. For an existing role, ask everyone who directs it for the rules they believe it follows, and put them side by side. When you find a conflict, settle it in the open and write the ruling into the charter. In our case the ruling was an exception, and the exception now has a reason attached. If two leaders keep issuing conflicting rules to the same role, the deeper problem is that the role has two bosses, which is the subject of [Chapter 6](6-one-boss-few-reports.html). The same bot, asked to research Gerber's ideas and propose an org design for our agents, gave advice I couldn't improve on: "design the organization around repeatable results--not around whichever agents happen to exist." Gerber would have recognised it.\\] ## Start With the Outcome Line Every charter starts with one sentence on why the role exists, beginning "To...". It is the hardest sentence on the page and the most useful. "To get every client invoice paid within terms, without souring the relationship." "To make sure every customer question gets a correct answer within one working day." "To keep the team's plans honest, so slips are seen before they happen." A good outcome line names a result, not an activity. "To send payment reminders" describes what the occupant does; "to get invoices paid" describes what the organisation needs. Occupants optimise for whatever you write down. A reminder-sending agent will send reminders. An invoice-collecting agent will notice when reminders aren't working. Drucker's advice to executives was to ask what contribution the organisation needs from them, rather than what they are busy with.\\] The outcome line asks the same question of a role. If you can't write the outcome line, stop. The role probably isn't coherent: it is two jobs, or tasks with no shared purpose; go back to the role coherence test in [Chapter 5](5-hire-the-role-not-the-model.html). Matthew Skelton and Manuel Pais make the related point about teams: a team given more than it can hold in its head does all of it worse.\\] A role is no different. ## Say What the Role Owns and What It Serves After the outcome line comes the work. Most job descriptions list tasks. A Role Charter says what the role **owns**, what it **serves**, and what it **hands off**. The distinction has a precise counterpart in how agent software is built. OpenAI's agent framework describes two ways for one agent to involve another. In a handoff, a triage agent "routes the conversation to a specialist, and that specialist becomes the active agent for the rest of the turn." In the other, a manager "keeps control of the conversation and calls specialist agents" as tools, which suits a specialist who "should help with a bounded subtask but should not take over the user-facing conversation."\\] Translated into org design, the question for every role is: **does this role own the answer, or does it serve another role?** A role that owns the answer takes the work and responds. A role that serves another produces a piece of work and hands it back to the role that owns the answer. Both are legitimate. Ambiguity between them is how you get two roles answering the same customer, or each assuming the other will. My own agents show both. My project-management agent owns the picture of the plan: it decides what to flag. But it serves engineering rather than directing it. Its charter says it "must NOT direct coding agents." Another of its playbooks helps me decide which work to delegate to which engineer, and its key rule is a service rule: "Propose, don't assign." It produces a recommendation and hands the decision back to me. Write the work section in three short lists: * **Owns:** the outcomes and decisions this role is accountable for. * **Serves:** the roles it produces work for, and what it gives them. * **Hands off:** what it passes on, to whom, how and how fast. A handoff that doesn't say where it goes is how work goes missing, as [Chapter 15](15-work-in-public.html) shows. Anthropic's research team found the same need for edges when its lead agent briefed sub-agents. Each needed "clear task boundaries"; without them, agents "duplicate work, leave gaps, or fail to find necessary information."\\] Duplicates and gaps are the two failure modes of an unclear work section. ## Standards Come in Three Kinds Standards make a charter checkable. A good charter has all three kinds. **Quantity** standards say how much and how fast: every overdue invoice gets a reminder within one working day; the weekly summary is posted by 9am on Monday. **Quality** standards say how good: amounts match the accounting system; every claim of "on track" is backed by evidence. **Behaviour** standards say how the occupant conducts itself: what it never does, how it treats people, how it signs its work. Andrew Grove warned that a measure on its own invites the occupant to hit it at the expense of everything else, and argued that indicators should be paired, so that quantity is always checked against quality.\\] An agent told only to send reminders quickly will send them quickly and carelessly. Pair every quantity standard with a quality one. W. Edwards Deming's word for a usable standard was an operational definition: one precise enough that two people applying it get the same answer.\\] "Be accurate" fails that test. "Take every figure from the live system at the time of sending, never from memory or an earlier list" passes it. My agents' playbooks contain the best operational definitions I have written, many of them added after something went wrong. The commitment tracker: "Only evidence is a Gmail DRAFT → NOT done." The project-management agent: use "direct language ('will slip', not 'slightly at risk')." The inbox agent: "if in doubt whether something is automated or human, treat it as human." Each is a standard someone else could check. Behaviour standards are where agent charters differ most from human ones, because so much human behaviour goes without saying. No human job description would bother to state "Access is not authorization": people understand that being able to open a file doesn't make it their business. Agents need it written down. So do the other things a person would take for granted: when to ask, when to stop, whom to tell, and how to sign their work ([Chapter 7](7-every-agent-needs-a-sponsor.html)). ## Acceptance Is Agreed Before the Work Starts The last section says who checks the standards, against what evidence, how often, and what threshold counts as a pass. The best recent example comes from Anthropic's experiments with long-running coding agents. Before each block of work, the agent doing the building and the agent checking it "negotiated a sprint contract: agreeing on what 'done' looked like for that chunk of work before any code was written." The builder proposed what it would build and how success would be checked; the two iterated until they agreed. Then the checker graded the work against the agreed criteria, and "each criterion had a hard threshold, and if any one fell below it, the sprint failed."\\] That is acceptance done properly: agreed in advance, specific, with a threshold. It also came with a warning. "Out of the box, Claude is a poor QA agent," the author wrote. In early runs the checker would "identify legitimate issues, then talk itself into deciding they weren't a big deal and approve the work anyway."\\] If an agent checking another agent's work does that, an agent checking its own work is at least as likely to. Acceptance evidence must come from somewhere other than the occupant. We learned this the hard way. One of our automated pipelines marked work as ready to go live, claimed it had been confirmed by a human, and attached evidence it had produced itself. Our QA lead's response defined acceptance better than any template: "Ready to Go Live has to mean a human validated it in the app." [Chapter 14](14-humans-at-the-irreversible-points.html) tells the full story. Our QA verdicts are now tied to a specific version of the work, so a pass on one version can't be carried over to the next. Two practical rules for the acceptance section: * **Name the evidence, not the activity.** "The finance lead checks five reminders a week against the accounting system" is acceptance. "The agent reviews its work" is not. * **Build the checks from real failures.** Anthropic's guidance on testing agents is that "20-50 simple tasks drawn from real failures is a great start."\\] Every time the role gets something wrong, add a check that would have caught it. [Chapter 16](16-the-model-isnt-the-problem.html) makes this a routine. Atul Gawande's work on checklists makes a related point: the useful checklist is short and covers only the steps that matter most and are most often missed.\\] Acceptance criteria are the same. Five checks that are actually run beat thirty that are not. | | Under the hood For an agent, the parts of a charter usually live in different places. The outcome line and behaviour standards go in its standing instructions (a Claude project's instructions, a custom GPT's configuration, a bot's description). The work and the quantity standards often live in the scheduled jobs that wake it up and in the playbooks (skills) it loads. The acceptance checks may be tests that run automatically. That is fine, as long as one human-readable charter says where each part lives and stays the source of truth. [Appendix D](appendix-d-for-your-technical-team.html) shows a layout, and [Chapter 12](12-everything-they-need-on-day-one.html) covers the Role Pack that accompanies a charter. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## One Page Is Enough George Patton thought army orders should not exceed a page and a half, and wrote that "usually they can be done on one page, and the back of the page used for a sketch map."\\] A Role Charter should meet the same limit. If it runs longer, it is usually carrying procedure that belongs in a playbook, or it is describing two roles. Pascal's apology in the epigraph is the real cost: short takes longer. The detail still exists; it lives in the playbooks the role uses and the Role Pack that onboards a new occupant. The charter is the page that comes before them: the job itself. Here is a short example for a fictional role, at a fictional 30-person garden design studio, currently filled by an agent. The full template, with guidance for each field, is in [Appendix B](appendix-b-templates.html). __Table 1\. Role Charter (example): Receivables Follow-up__ | Outcome line | To get every client invoice paid within terms, without souring the client relationship. | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Reports to | Finance lead, who is also the sponsor of the current occupant. | | Current occupant | An agent with read access to the accounting system and its own email address. Previously the office manager, about two hours a week. | | Owns | Reminders for invoices 1 to 45 days overdue. The weekly overdue list. | | Serves | The finance lead's monthly cash review, with the overdue list and a note on any client paying later than usual. | | Hands off | Any reply that disputes an amount, raises a complaint or asks for a payment plan: to the finance lead, the same working day, in the finance channel, with the email thread linked. | | Quantity | First reminder within one working day of the due date; second at 14 days overdue. Overdue list posted by 9am every Monday. | | Quality | Every amount, date and invoice number taken from the accounting system at the time of sending. Reminders under 120 words, friendly and plain. | | Behaviour | Never threatens, mentions late fees or offers discounts. Never contacts a client the finance lead has marked "on hold". Access is not authorisation: seeing a client's file doesn't make it this role's business. Signs every email: "Sent by the studio's accounts assistant, an AI agent, on behalf of the finance lead. Reply to reach a person." | | Acceptance | Weekly: the finance lead checks five reminders at random against the accounting system; any error in an amount or date is a fail. Monthly: no reminder sent on an invoice already paid. Quarterly: average days overdue holds or falls. | | Decisions reserved | Any invoice over £10,000\. Any client in dispute. Any change to this charter. | | Review | Quarterly, and whenever the occupant, its model or its tools change. Each correction is dated and initialled. | Notice what isn't there: how to write a reminder, which tool to use, the order of steps. A person or a different agent could take over this role tomorrow from this page and the studio's playbooks. That is the test. | | Try this Pick one role in your organisation that an agent fills, or that you'd like one to. Open Claude, ChatGPT or Grok and say: "Interview me, one question at a time, to write a one-page Role Charter for this role. It should have: an outcome line starting 'To...'; what the role owns, serves and hands off; quantity, quality and behaviour standards, each specific enough that someone else could check it; acceptance checks with who checks, what evidence, how often and what counts as a fail; and decisions the role must bring back to a human. Don't include step-by-step procedure. When we're done, list any rules I gave you that conflict with each other." Then paste in any instructions the role already has, from you and from anyone else who directs it, and ask the AI to check them against the charter. The conflicts it finds are the most valuable part of the exercise. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | AUTHOR: Have you written a Role Charter (or something like it) for a human role at CorralData, or only for agents? If you have used the same format for a person, a sentence on how it went, and whether people reacted differently from bots, would make the "people and agents alike" claim concrete. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## A Charter Is Never Finished A charter changes when the occupant changes, when the model changes, and whenever the role gets something wrong in a way a rule could have prevented. My own agents' playbooks show both halves of this. The good half is dated corrections. When an agent did something I didn't want, I added a rule with my name and the date: "(Gareth, 2026-10-15): a bare ticket number is useless -- ALWAYS put the ticket title..." Anyone reading it later knows who added it, when and why, and can judge whether it still applies. The bad half is drift. My commitment tracker, which was meant to track the promises I make, drifted into tracking everyone's. It was pulled back with an explicit scope line: only commitments I made or own. The fix was a sentence about where the role's edges are: a charter fix. Review a charter on a schedule, quarterly is fine for most roles, and on every model change for agent roles. The reason is the one from [Chapter 8](8-what-and-why-never-how.html): every rule encodes an assumption about what the occupant can't do on its own, and a stronger model can make it wrong.\\] A review asks three questions. Is the outcome line still why the role exists? Is each standard still being met, and still needed? And has anything been added that is really procedure, and belongs in a playbook instead? The review is also the moment to check the sponsor. If the person the role reports to, or its occupant's sponsor, has left or moved, the charter is orphaned along with the agent.\\] | | AUTHOR: When you ruled TAM Bot's auto-send lane an exception to your own rule, how did that feel? Was it hard to defer in public, or was it a relief that the contract had made the call easy? The reader will face the same moment when a charter exposes a conflict between their rule and a colleague's. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- Pascal's line is a joke about letters, but it describes the work of writing a charter exactly. Anyone can write three pages about a job. One page means deciding why the role exists, what it owns and what it doesn't, what good looks like, and how anyone will know. Those decisions are the job design. The page is just where they are written down. Write one page per role, for the role rather than the occupant, and review it whenever the occupant changes. The charter says what the job is; it says almost nothing about how. That is deliberate, and the playbooks that carry the how are the subject of [Chapter 10](10-bet-on-plain-english.html). ## Frequently Asked Questions 1. _What should a job description for an AI agent include?_ Four things, on one page. An outcome line saying why the role exists, starting "To...". The work: what the role owns, which roles it serves, and what it hands off. Standards for quantity, quality and behaviour, specific enough to check. And acceptance: how, and how often, someone confirms the standards are met. Add who the role reports to, who sponsors its occupant and which decisions it must bring back to a human. Leave out the steps; those belong in the playbooks the role uses. 2. _Should AI agents and human employees have the same kind of job description?_ Yes. A Role Charter describes the role, not whoever fills it, so the same format works for a person, an agent, or a person supported by an agent. That is what lets work move between occupants without being redesigned. The differences belong elsewhere: an agent may need its access written down more precisely, and a person's charter sits alongside a contract of employment. But the outcome, the work, the standards and the acceptance check should read the same whoever does the job. 3. _How do you write acceptance criteria for an AI agent?_ Agree them before the work starts and make each one checkable by someone other than the agent. Good criteria name the evidence: a figure that reconciles with a source system, a sample a human reviews, a link to the finished item, a test that must pass. Set a threshold for each, so a miss is unambiguous. Never accept the agent's own report as the evidence. Anthropic found that its evaluator agent would spot real problems and then talk itself into approving the work anyway until it was tuned. 4. _How do you decide which AI agent owns a task?_ Decide for each role whether it owns the answer, taking over the task and responding directly, or serves another role, doing a bounded piece of work and handing the result back. OpenAI's agent framework draws the same line between a handoff, where a specialist "becomes the active agent," and using an agent as a tool, where a manager keeps control. Write which one each role is into its charter. When it is unclear, two roles end up answering the same question, or nobody answers it. 5. _How often should a Role Charter be reviewed?_ On a schedule, such as quarterly, and whenever something important changes: a new occupant, a new model, a new tool, or a recurring failure. A model change matters most for agent roles, because rules written for a weaker model can hold a stronger one back. When a correction is added, date it and say who made it, so the next reviewer knows why it is there and whether it still applies. A charter that has not been reviewed in a year is probably describing a job nobody is doing. ## References . Gerber, M. E. (1995). _The E-Myth revisited: Why most small businesses don't work and what to do about it_. HarperCollins. . E-Myth Worldwide. (1997). _Position contracts: Creating the road maps for your employees' success_ (Business Development Process MG-0050). E-Myth Mastery Program. . Drucker, P. F. (1967). _The effective executive_. Harper & Row. . Skelton, M., & Pais, M. (2019). _Team topologies: Organizing business and technology teams for fast flow_. IT Revolution. . OpenAI. (n.d., accessed 2026-11-06). Agent orchestration. _OpenAI Agents SDK documentation_. . Hadfield, J., et al. (2025, June 13). How we built our multi-agent research system. _Anthropic Engineering_. . Grove, A. S. (1983). _High output management_. Random House. . Deming, W. E. (1986). _Out of the crisis_. MIT Press. . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic Engineering_. . Grace, M., Hadfield, J., Olivares, R., & De Jonghe, J. (2026, January 9). Demystifying evals for AI agents. _Anthropic Engineering_. . Gawande, A. (2009). _The checklist manifesto: How to get things right_. Metropolitan Books. . Patton, G. S., Jr. (1947). _War as I knew it_. Houghton Mifflin. "Reflections and Suggestions." . Microsoft. (2026, September 3). Administrative relationships in Microsoft Entra Agent ID (owners, sponsors, and managers). _Microsoft Learn_. Chapter 10: Bet on Plain English ==================== _Why the simple, expressive option keeps winning_ **In short:** AI agents are best directed with plain-English playbooks, not visual workflow builders. A playbook written like an onboarding guide for a capable new hire can be read by everyone in the business and by agents from any vendor, and it improves as models improve. Workflow builders fix the steps in place, and the steps are what models outgrow. > Never use a long word where a short one will do. -- George Orwell Politics and the English Language, 1946 Key Takeaways * The tool that wins inside an organisation is the one that most people can pick up for the job they actually have, not the one with the best specification sheet. * Plain English is the most widely installed programming language in your business: every person and every agent already reads it, so a playbook written in it spreads where a workflow diagram stays with its author. * The Bitter Lesson applies to management: each step you hard-code into an agent's instructions encodes an assumption about what the model can't do, and the next model makes that assumption wrong. * Write playbooks as onboarding guides for a capable new hire, with the reasons attached, and keep them short enough to change in a minute when the work or the model changes. In the autumn of 2026, CorralData ran an experiment nobody had designed. Grok Bot, which lets anyone describe an agent in a paragraph of English and drop it into Slack, went from nothing to about ten team bots in two weeks. Most were not built by engineers: customer success, sales, legal and hiring all had one. Our CEO called it a "next level productivity hack." I liked it enough to write an internal proposal to copy its Slack integration into our own product. For most of a year I had been running a visual workflow builder, n8n, for my weekly research digests. It worked. It did exactly one job, for exactly one person: me. When one of our engineers looked at it, his verdict was "probably not something for us." An attempt to give our QA function its own n8n workflow stalled. Nobody else ever built one. The clue to how this would end was inside my own workflow. Strip away the boxes and arrows, and the part doing the real work was a single box holding a few paragraphs of English telling a model what to look for and why. The diagram was scaffolding around a paragraph. When agents arrived that could take the paragraph directly, the scaffolding had nothing left to hold up. This chapter makes the case for plain English as the default way to tell people and agents how work gets done. Chapter 11 is the counterweight; read them as one argument. | | AUTHOR: What did n8n feel like from the inside? Was there a moment you realised you were the only person who would ever maintain it, and did you decide to stop, or did it just fade? A sentence or two in your own words would make the opening land. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ## The Format More People Can Use Is the One That Wins Sony introduced Betamax in Japan on 10 May 1975.\\] It was, by the measures engineers care about, the better format. At its original speed it resolved around 250 horizontal lines against about 240 for VHS, with less noise and crosstalk.\\] It also had a problem that had nothing to do with picture quality. Early Beta tapes held sixty minutes, which made them impractical for films and sport, the things people actually wanted to record.\\] JVC's VHS arrived the following year with a standard mode that ran for two hours.\\] JVC licensed the format broadly, which brought in a crowd of manufacturers competing on price; Sony initially resisted licensing Beta, which limited how far it could reach.\\] By 1980 VHS had 60% of the North American market. By 1987 it had 90% of the US market.\\] In 1988 Sony agreed to add VHS machines to its own line-up, widely read as surrender.\\] The economist W. Brian Arthur showed how an early lead in adoption compounds. When each new user makes a technology more useful to the next (more tapes in the rental shop, more machines in friends' houses), a market can settle on one option through small, almost accidental choices, and stay there even if the other was technically better.\\] He called the end state lock-in. Keep the word in mind; Chapter 11 borrows it. Quality matters, but adoption is decided by the many people who want to do an ordinary job easily, not by the few who can appreciate the specification. Betamax was the better format for an engineer. VHS was the better format for a family who wanted to record the match. ## The Language Anyone Can Start In Ends Up Running the Web The same pattern played out on the web twenty years later. In 1994 Rasmus Lerdorf wrote a handful of small programs to track visits to his online CV. He called them "Personal Home Page Tools." In June 1995 he released the source code so that other developers could "use it as they saw fit," which also encouraged them to fix its bugs and improve it.\\] PHP was never elegant. Professionals mocked it for two decades. ColdFusion launched a month later, on 2 July 1995, built by the brothers Joseph and Jeremy Allaire.\\] To be fair to it, ColdFusion was simple too. Its tags looked like HTML, which made it friendly to the designers who were building the early web. But it was a commercial, proprietary product, later sold to Macromedia and then Adobe.\\] Today PHP runs 69.1% of the websites whose server-side language can be detected. ColdFusion runs 0.2%.\\] WordPress, written in PHP, alone powers 39.5% of all websites.\\] Simplicity alone wasn't enough. ColdFusion had a gatekeeper: someone had to buy it. PHP was simple, expressive and free to anyone who wanted to try it on a Tuesday afternoon. What wins is easy to start, powerful enough to keep going, and owned by nobody who can say no. Richard Gabriel, a computer scientist, named the pattern around 1990: "worse is better." Systems that put simplicity first, he argued, have "better survival characteristics than the-right-thing," and spread from one user to the next "like a virus."\\] | | AUTHOR: Did PHP (or something like it) figure in the IT company you ran in your 20s? A first-hand line about choosing the scrappy tool over the proper one, and how that turned out, would turn this section from history into experience. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ## English Is the Most Widely Installed Language in Your Business In January 2023 Andrej Karpathy, a founding member of OpenAI, posted a line that went round the industry: "The hottest new programming language is English."\\] Three years later it describes how CorralData works. Consider what English has going for it as the format for your organisation's instructions: * **Everyone already has it installed.** Your head of sales, your newest hire, your auditor and every agent from every vendor can read a paragraph of English. Few can read a workflow diagram; fewer can change one. * **It carries reasons.** A diagram can say "if the ticket is closed, skip it." Only prose can add "because reopening it confuses whoever closed it." The reason lets a capable occupant handle the case the rule didn't foresee. * **It is portable.** At CorralData, my local agents and Claude Code read from one shared folder of playbooks, so a fix written once reaches all of them. On 5 November, Claude onboarded a Grok bot in our #tech-general channel: one vendor's agent briefing another vendor's agent, in English, in public. No integration project was required. * **It changes at the speed of a conversation.** Editing a paragraph takes a minute. Even guardrails can start as English. I noted with some surprise that Grok Bot's permissions were "a list of plaintext directives... rather than a cleanly structured relational model." An older generation of engineers would wince, but non-engineers could read and change it. One of our engineers summed up where this leaves the industry: an agent is "an LLM, running in a loop, calling tools... the company with best/easiest UX/UI will win." The easiest interface ever devised is the language people already speak. ## Workflow Builders Lock In the Steps, and the Steps Are What Change The instinct to reach for structure is a good one, misapplied. Leaders know that undocumented processes fail, so when agents arrive they want boxes, arrows, a canvas you can show the board. But a diagram fixes the one thing that ought to stay loose, the route, and says little about what ought to be fixed: the outcome, the standard and the reasons. CorralData's most structured experiment was a pipeline called Glass Factory, which used our ticket tracker as its interface and defined its roles in detailed operating guides. It was behind the worst failure in this book ([Chapter 14](14-humans-at-the-irreversible-points.html)), and by November it had gone quiet. What survived was the idea. "Glass factory mode" (the agent drafts, the team corrects, the corrections feed back, and autonomy expands as the work proves reliable) became the theme of a LinkedIn post by our CEO. The idea could be said in a sentence, so it travelled. The code could not, so it didn't. | | AUTHOR: Who built Glass Factory, and how would you characterise its winding down? The dossier infers it from the status messages rather than from a decision. If there was a moment you or someone else chose to stop investing in it, a line on why would strengthen this section, and make sure the description is fair to whoever built it. | | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | CorralData is not alone. On 3 June 2026 OpenAI told developers that Agent Builder, its drag-and-drop canvas for designing agents, was being deprecated, with shutdown scheduled for 30 November 2026\. Its deprecation notice points users to a migration guide for continuing with its Agents SDK, which is code, or with ChatGPT Workspace Agents.\\] OpenAI gave no reason, and I won't invent one. But notice where users were sent: towards code for precision, and towards a conversational product for everyone else. The canvas in the middle was what went. Agent builders agree. Reviewing the teams it had worked with, Anthropic found that "the most successful implementations weren't using complex frameworks or specialized libraries." Its advice was to find "the simplest solution possible, and only increasing complexity when needed," and it warned that frameworks "create extra layers of abstraction that can obscure the underlying prompts."\\] LangChain, which makes a framework, gives the same advice: "Start with a single agent and good prompt engineering."\\] Prompt engineering is a technical name for writing clear English. To be fair to the builders, n8n now describes itself as a platform for "agents and workflows you can follow."\\] For stable, high-volume integration between two systems, a diagram is fine. But that is plumbing. It is not how you tell a role what it is for. | | Workflow builder | Plain-English playbook | | ------------------------------------ | --------------------------------------------------------- | --------------------------------------------------------------- | | Who can read it | The person who built it, and anyone they train | Everyone in the organisation, and every agent from every vendor | | Who can change it | Usually one person | Anyone with edit rights, in a minute | | What it fixes in place | The route: each step and branch | The outcome, the standards and the reasons | | What happens when the model improves | The steps become constraints the model has to work around | The same words get better results | | What happens with an unforeseen case | Falls off the edge of the diagram | The occupant applies the reasons | | Where it's strongest | Stable, high-volume plumbing between systems | Judgment, preferences, procedure, policy | ## The Bitter Lesson Applies to Management Too In March 2019 Rich Sutton, one of the founders of reinforcement learning, published a short essay that has become the closest thing the AI field has to a creed. "The biggest lesson that can be read from 70 years of AI research," he wrote, "is that general methods that leverage computation are ultimately the most effective, and by a large margin."\\] Chess, Go, speech recognition and computer vision had all followed the same arc. Researchers built their own understanding of the problem into their systems, which helped for a while and was "personally satisfying to the researcher." Then it plateaued, and the clever, hand-built methods were swept away by simpler ones that let computation do the work. "We have to learn the bitter lesson that building in how we think we think does not work in the long run."\\] Sutton was writing about researchers, but every leader will recognise the failure. The manager who writes a twelve-step procedure for a capable new hire is building in how they think they think. It helps on day one. By month three it holds the hire back, because the hire has found a better route and the procedure forbids it. I posted Sutton's essay to our #ai-related channel on 29 October 2026 because I had watched it happen at CorralData. AskCorral, our analytics assistant, was first built in the GPT-3 era, wrapped in scaffolding to make up for what the model couldn't do. We "stripped... out again when models got better." My conclusion for the team was that we should "not be afraid to turn things over to the models to brute force." A few days later I added that getting "too specific with directions" holds you back. The same day, one of our engineers let an agent loop seven rounds on a single high-level instruction, and I noted that the human was "more useful to make sure it is building the right thing" than to steer each step. Months earlier, another engineer had come back from a talk by the Claude Code team with a line in his notes: "Never bet against the model." The people who build agent systems have reached the same conclusion. Prithvi Rajasekaran at Anthropic put it in one sentence: "every component in a harness encodes an assumption about what the model can't do on its own." When a newer model arrived, his team removed the part of their system that broke work into sprints, and recommended meeting every new model by stripping away "pieces that are no longer load-bearing."\\] Browser Use, which builds agents that operate web browsers, replaced thousands of lines of engineered wrappers with about 600, reasoning that the model had already read about the browser's controls millions of times: "It already knows what to do." Their rule: "Don't wrap the LLM. Don't wrap its tools either."\\] Anthropic's own guide to Claude Code now carries a table titled "What you can stop doing," listing once-sound advice such as shouting at the model in capital letters. "Most were workarounds for something the model couldn't reliably do yet, and the models have since caught up."\\] A workflow diagram is a harness drawn in boxes. Every branch is an assumption that the occupant can't be trusted to choose the route, and most will be wrong within a year. A paragraph that states the outcome, the reasons and the limits makes no assumption about the route, so it gets better every time the model does. [Chapter 8](8-what-and-why-never-how.html) made this argument for briefs. It holds just as strongly for the standing documents that tell a role how its work gets done. ## A Playbook Is an Onboarding Guide, Not a Program If a playbook isn't a program, what is it? Anthropic's answer, in the post that introduced its Agent Skills, is the best I have found: "Building a skill for an agent is like putting together an onboarding guide for a new hire."\\] A skill is a folder with a plain-English document at its heart, and since December 2025 an open standard that works with agents from different vendors.\\] That framing changes what you write. A program tells a machine what to do, in order, without explanation. An onboarding guide tells an intelligent adult what the job is for, what good looks like, which judgment calls come up and how to make them, and what to do when stuck. It also means the same document serves a person and an agent, which is the point. A role outlives its occupant ([Chapter 5](5-hire-the-role-not-the-model.html)). A playbook only a machine can follow can't be handed to a person on the day the agent fails, and the reverse is true too. Plain English is the one format that works for both. At CorralData the clearest proof was TAM Bot's arrival in #tech-general, onboarded in public "with no initial training other than 'join Slack'." The Agentic Resources Bot interviewed it and drafted its Role Charter ([Chapter 9](9-one-page-per-job.html)). What made it work was English written by people who weren't thinking about TAM Bot at all: channel descriptions, team rules, earlier decisions. The organisation's written English was the onboarding. Writing a good playbook is mostly writing good English. Orwell's 1946 rules still serve: never use a long word where a short one will do, and "if it is possible to cut a word out, always cut it out."\\] Open with what the work is for, then what done looks like, then the judgment calls and their reasons, then the traps. Steps belong only where order genuinely matters. | | Under the hood An Agent Skill is a folder containing a SKILL.md file (plain-English instructions with a short name and description at the top) plus any supporting files or scripts. Agents load only each skill's name and description at the start, read the full document when a task matches, and open supporting files only when needed.\\] That is why dozens of playbooks don't swamp an agent's attention. See [Appendix D](appendix-d-for-your-technical-team.html) for folder layout and sharing. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Policy Can Live in a Playbook Too The strongest test of plain English is whether it can carry policy: not just "here is how we write a customer update," but "here is what you are and aren't allowed to do." At CorralData it can, and the story is one of two leaders disagreeing in good faith. On 1 October our CEO pushed hard for non-engineers to be able to propose changes to our product's code directly, with their agents' help. His frustration was real and, as it turned out, largely right: "it's months of wait for something robots say is low effort and low risk." I pushed back: "it will not be an accelerant to have a bunch of people submitting PRs they have not tested and do not understand." We were both describing a real cost. He saw the queue; I saw the review load that would land on our engineers. The resolution was not a workflow or a permissions system. On 8 October I added an agreement step to our code-review playbook: a few lines of English that any reviewing agent would follow. When agents kept opening changes the rule didn't allow, the fix was to give them the same written rule. On 4 November, after a month of evidence, I wrote: "I think the bar has moved." On 5 November we replaced the gate with a tiered rule in the same playbook: "Size now sets the evidence a PR needs, not whether it is allowed." Changing company policy took no engineering ticket and no release. The policy lived in a paragraph every agent read; when the evidence changed, so did the paragraph. Our CEO's instinct that the bar was too high was vindicated, and what let us lower it safely was a plain-English document. That is what an expressive format buys you: policy that keeps pace with trust. | | AUTHOR: Permission check: this passage describes your disagreement with the CEO over non-engineer code changes (1 October to 5 November), with direct quotes from both of you. It is written to present his impatience as justified and the outcome as a shared win. Confirm it's OK to include, and consider showing it to him before publication. | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Simple at the Surface Doesn't Mean Careless Underneath None of this means plain English is free. Grok Bot spread across CorralData in days, and its rough edges spread with it. Bots answered only people whose accounts were linked, and woke only when tagged by name. Login tokens broke. One bot reached our private network only through my own machine. For coding, the verdict was "pretty rough." CorralData's safety in those months came not from the English but from structure at a few specific points: lanes that decided which customer messages an agent could send unaided, hard stops around patient data and billing, quality checks tied to a specific version of the code, the size-based evidence rule for proposed changes. The pattern, once I saw it, was clear: a simple, expressive interface, with firm gates at the points where a mistake can't be undone. Plain English is the right default for describing a role, a procedure, a preference or a policy. But English is read by a model that decides, each time, how to apply it. For most work that is exactly what you want. For a few things it isn't. | | Try this Pick one recurring piece of work you currently explain in person: the weekly customer update, the month-end checklist, how you want board papers drafted. In Claude, ChatGPT or Grok, write it as a one-page playbook in this order: **What it's for**: one sentence, starting "To...". **What done looks like**: how you'd judge a good one. **The judgment calls**: the three decisions that come up most, and **why** you make them the way you do. **The traps**: what new people get wrong. Then open a fresh chat, paste in only the playbook, and ask: "Do this task for \[a real example\]. Before you start, list anything you'd need to ask me." Every question is a gap in the playbook. Fix the playbook, not the chat. When the questions stop, you could hand it to a new hire or an agent tomorrow. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- The VHS tape and the PHP script were never the best-engineered options. They won because ordinary people could use them for the job they actually had, and each new user made them more valuable to the next. Plain English has both properties, more strongly than any technology before it, and it gets better every time the models do. The Bitter Lesson says the clever structure you build today is the constraint you remove tomorrow. Write your playbooks so there is nothing to remove. But "almost everything" is not everything. Some work involves arithmetic that must be right every time, facts that must come from a live system, and actions that cannot be taken back. For those, a paragraph followed ninety-nine times in a hundred is not good enough. [Chapter 11](11-lock-in-only-what-cant-go-wrong.html) sets out when to lock things in, how far, and how to keep the locks from becoming the next thing the models outgrow. ## Frequently Asked Questions 1. _Should I use a visual workflow builder or plain English to set up AI agents?_ Start with plain English. A one-page playbook written the way you would brief a capable new hire can be read by everyone in the business, by agents from any vendor, and by whoever inherits the job. Workflow builders fix the steps in place, and the steps are what change as models improve. Keep code and hard rules for calculation and for actions that cannot be undone; everything else belongs in a document anyone can edit in a minute. 2. _What is the Bitter Lesson and why does it matter for business leaders?_ The Bitter Lesson is Rich Sutton's 2019 observation that, across seventy years of AI research, general methods that use more computation beat methods built on human cleverness about the problem. For leaders, it means step-by-step instructions help an agent in the short term and hold it back later, because each step encodes an assumption about what the model cannot do. Describe the outcome, the reasons and the boundaries, and let improving models find the route. 3. _What is a playbook for an AI agent?_ A playbook is a documented procedure, written in plain English by default, that tells the occupant of a role how a recurring piece of work gets done and why. It reads like an onboarding guide for a new hire: what good looks like, the judgment calls and the common traps. Anthropic describes its Agent Skills in exactly those terms. The same playbook should work whether the occupant is a person, an agent or both. 4. _Why did VHS beat Betamax, and what does it have to do with AI?_ VHS won on usefulness rather than picture quality: Betamax arrived first, in 1975, with slightly better pictures, but early tapes held only an hour. VHS followed in 1976 with two-hour tapes, and JVC licensed it broadly while Sony initially resisted licensing Beta. By 1987 VHS held 90% of the US market. The format that more people could use for what they actually wanted won. In agent work, plain English is the VHS: less precise than structured tools, but usable by everyone, so it spreads. 5. _Is plain English precise enough to run a business process?_ For most of the process, yes, provided you write it well: the outcome, the reasons, the standards and the boundaries, in short sentences. Capable models are good at applying a guideline to the case in front of them. English is not precise enough for arithmetic, for facts that must come from a live system, or for actions that cannot be undone. Those belong in scripts and hard rules the software enforces, which Chapter 11 covers. English is the default, not the only tier. ## References . Wikipedia contributors. (n.d., accessed 2026, November 6). Betamax. _Wikipedia_. . Wikipedia contributors. (n.d., accessed 2026, November 6). Videotape format war. _Wikipedia_. . Arthur, W. B. (1989). Competing technologies, increasing returns, and lock-in by historical events. _The Economic Journal_, 99(394), 116--131\. . The PHP Group. (n.d., accessed 2026, November 6). History of PHP. _PHP Manual_. . Wikipedia contributors. (n.d., accessed 2026, November 6). Adobe ColdFusion. _Wikipedia_. . W3Techs. (2026, November 6). Usage statistics of server-side programming languages for websites. . W3Techs. (2026, November 6). Usage statistics and market share of WordPress. . Gabriel, R. P. (1991). The rise of "worse is better". Excerpt from _Lisp: Good news, bad news, how to win big_ (keynote first given March 1990). . Karpathy, A. (2023, January 24). The hottest new programming language is English (Post). X. Traced in Quote Investigator. (2024, October 20). Quote origin: The hottest new programming language is English. . OpenAI. (2026). Deprecations. _OpenAI API documentation_. . Schluntz, E., & Zhang, B. (2024, December 19). Building effective agents. _Anthropic_. . Runkle, S. (2026, January 14). Choosing the right multi-agent architecture. _LangChain_. . n8n. (n.d., accessed 2026, November 6). n8n home page. . Sutton, R. (2019, March 13). The bitter lesson. _Incomplete Ideas_. . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic_. . Zunic, G. (2026, April 19). The bitter lesson of agent harnesses. _Browser Use_. . Anthropic. (n.d., accessed 2026, November 6). Best practices for Claude Code. _Claude Code documentation_. . Zhang, B., Lazuka, K., & Murag, M. (2025, October 16). Equipping agents for the real world with Agent Skills. _Anthropic_. . Orwell, G. (1946, April). Politics and the English language. _Horizon_. Reproduced by The Orwell Foundation. Chapter 11: Lock In Only What Can't Go Wrong ==================== _Three tiers: English, scripts, hard rules_ **In short:** AI agents should follow hard-coded rules only where a mistake cannot be undone: actions that leave the business, destroy data, move money, cross security boundaries, or confirm work is finished. Everything else belongs in plain-English playbooks, with small scripts for facts and arithmetic. Lock in the checks, not the steps, and review every lock-in when models change. > Bind me as I stand upright, with a bond so fast that I cannot possibly break away, and lash the rope's ends to the mast itself. If I beg and pray you to set me free, then bind me more tightly still. -- Homer The Odyssey, Book XII (trans. Samuel Butler, 1900) Key Takeaways * Plain English is followed by a model that decides each time how to apply it, so every instruction has a failure rate; that is fine for work you can correct and unacceptable for work you can't. * Use three tiers: a plain-English playbook by default, a small script for facts and arithmetic, and a hard rule the software enforces only for irreversible actions, security and the final acceptance check. * Lock in the checks, not the steps: hard-code what must be true when the work is done, and leave the route to the occupant, because the route is what better models improve. * Every lock-in should carry its reason and its date, and be reviewed whenever the model changes; the enforced set should stay small enough that someone can explain every item in it. One of my agents at CorralData has a dull and useful job. Every day it looks for stalled work: proposed code changes that have sat untouched, tickets that have drifted, and items that have been overtaken by events. When it finds something genuinely superseded, it can close it. One morning it closed a change that wasn't superseded at all. The reason, when I traced it, was almost comically small. Somewhere in the chain, a ticket's status had been copied by hand as "Done." In the ticket tracker it was in the Backlog, very much alive. The agent had reasoned perfectly well from a fact that was wrong. The fix was not a sterner paragraph. I didn't add "BE CAREFUL" to the agent's playbook. I took the fact out of the agent's hands. The playbook now says: "Cancel-eligibility is derived PROGRAMMATICALLY from the live ticket state. Never hand-transcribe..." A small script looks up the status from the tracker itself, every time. Two more lines record related lessons: "Backlog is LIVE, never Done," and "Dependabot PRs are NEVER auto-cancel candidates." Everything else stayed in English: what counts as stalled, how to word a nudge, when to escalate rather than act. The judgment stayed with the agent. The fact became a lookup. That division is the whole of this chapter. [Chapter 10](10-bet-on-plain-english.html) made the case for plain English as the default. This chapter is about the exceptions: when to lock something in, how far, and how to keep the locks from becoming the next constraint the models outgrow. ## English Has a Failure Rate, and Some Failures Can't Be Taken Back Anthropic's guidance for Claude Code draws the line more clearly than anything else I've read. Every instruction you give an agent, it says, is one of two kinds. Some are read by the model, which "then decides what to do with this information... there's no _guarantee_ that it'll follow your instructions." Others are enforced by the software around the model, which "applies this every time, no matter what the model decided to do."\\] A playbook is the first kind. However carefully you word it, "whether Claude follows that line on a given turn is still Claude's call."\\] The same guide is clear that the first kind should be the norm: "Most of the time, you want Claude to decide. Almost every guideline has exceptions," and the model, looking at the actual case, "is usually better placed to make that call than a rule you wrote in advance."\\] That is Chapter 10's argument in the words of the people who build the tools. But a failure rate compounds. Anthropic's guide to testing agents gives the arithmetic: an agent that succeeds 75% of the time on a single attempt will succeed on all of three attempts only about 42% of the time.\\] Apply the same sum to a rule your agent follows 99 times in 100\. Across a hundred actions, the chance it never slips is about 37%. Across a year of daily work, a slip is close to certain. Whether that matters depends on what a slip costs. If it occasionally formats a report wrongly, someone fixes it and the playbook gets a better sentence. If it occasionally emails a customer something unchecked, deletes a record, or marks untested work as ready to ship, there is nothing to fix afterwards. This is the question to ask of every instruction: if this is ignored once, can I undo it? If yes, it stays in English. If no, English is not enough. ## Three Tiers: English, Scripts, Hard Rules CorralData's instructions have settled into three tiers. Most work lives in the first; each step down needs a reason. | Tier | What it is | What belongs there | CorralData example | | ---------------------- | ---------------------------------------------------------- | -------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | 1\. Playbook (default) | Plain English the occupant reads and applies with judgment | Procedure, preferences, judgment calls, policy, and the reasons behind each | How to word a nudge about stalled work; the size-based evidence rule for code changes | | 2\. Script | A small program inside the playbook that the occupant runs | Arithmetic, lookups from live systems, anything that must come out the same every time | Reading a ticket's real status from the tracker; computing the numbers in a weekly report | | 3\. Hard rule | A rule the software enforces whatever the model decides | Irreversible actions, security boundaries, and the final check that work is done | No card reaches "Ready to Go Live" without passing through human review on the test site | The tiers follow Anthropic's line. "If something has to happen every time," its guide says, make it a rule the software enforces. The plain-English file "is for guidelines, and Claude is allowed to decide a guideline doesn't apply."\\] Tier two sits in between: still part of the playbook and still chosen by the occupant, but giving the same answer every time it runs. Anthropic's post introducing Agent Skills makes the case for that middle tier directly. Some work, it says, needs "the deterministic reliability that only code can provide," so a skill can bundle small scripts alongside its English instructions.\\] The agent decides when to run the script. The script decides what the answer is. Not everyone puts the line where I do. Dex Horthy's _12-Factor Agents_, a widely read guide for engineers, observes that many agents that work in production "are mostly deterministic code, with LLM steps sprinkled in at just the right points," and one of its principles is "Own your control flow."\\] Further along is a 2025 research paper, _Blueprint First, Model Second_, which has no connection to this book despite the shared word. Its authors write the whole workflow as code, run it with a conventional program, and call the model only for bounded sub-tasks. On a travel-planning benchmark full of hard constraints, that approach cut constraint violations by 96% (11 against 275) compared with a model-led baseline using the same underlying model.\\] When the problem is fixed and every violation is costly, putting the route in code works. But most of what an organisation asks of its roles is not a benchmark. The route changes, the exceptions are the job, and the next model will find a better path than the one you wrote down. My reading is that the constraints should be locked in and the route left open. That is the difference between tier three and a workflow builder. ## Scripts Are for Facts and Arithmetic Models are fluent, and fluency is dangerous around numbers. A model asked to total a column will usually get it right, and when it doesn't, it will be plausibly wrong. A model asked about a ticket will answer from whatever it was told, as my stalled-work agent did. Neither is a lack of intelligence; both come from asking a reasoning engine to do a lookup or a sum. My morning stand-up agent shows the second tier at its plainest. Before the agent does anything, a small script checks one fact: have I accepted today's stand-up meeting in my calendar? If not, the script stops everything: in its own words, "no LLM, no delivery." There is no point waking a model to decide whether a meeting is happening when the calendar already knows. A related job that rolls the plan over has instructions that say: "Do not re-derive the numbers; the script is the source of truth." The agent writes the commentary. The script does the counting. The test for the second tier is simple. Would two careful people, given the same inputs, be expected to produce exactly the same output? If so, it is arithmetic or a lookup, and a script will do it better than any occupant. If two good people might reasonably differ, it is judgment, and it belongs in English. ## Your Agents Are Already Writing the Scripts The second tier sounds like a job for engineers. In practice, your agents do most of it unasked. When I audited the folder belonging to my stalled-work agent, I found 174 small programs in it. Some were deliberate: the status lookup, the arithmetic for the weekly report, the logic that stops it nudging the same person twice. But ten of them were one-off scripts the agent had written for a single day's digest, each named after its date. Every time it had needed to build the digest, it had improvised the same kind of tool from scratch, used it once and left it behind. | | AUTHOR: How did it feel to find 174 scripts in one agent's folder? Was it alarming, impressive, or both? And did you do anything about the ten one-off digest scripts afterwards? A line on your reaction, and what you changed, would make this case land. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | This is now a recognised pattern. Anthropic's engineers describe agents that "persist their own code as reusable functions": once an agent has working code for a task, it saves it for next time, and a short English description turns the saved code into a skill other agents can use.\\] In one of their examples, letting the agent write and run a small program instead of shuttling data through its own reasoning cut the work from 150,000 tokens of reading to 2,000.\\] So the manager's job in the second tier is not to write scripts. It is to notice when an occupant has written the same one twice, and promote it: give it a name, put it in the playbook, and say in English when to use it and why. Ten dated digest scripts are a signal that a playbook is missing a tool. There is a catch, and one of our engineers named it. Coding models, he pointed out, are rewarded for getting a task done, not for leaving behind code someone else can maintain, so they "get no better at keeping a codebase maintainable." An agent will happily write its hundred-and-seventy-fifth script. It won't tidy the first hundred and seventy-four. Every promoted script needs an owner, and that owner is the role's Sponsor ([Chapter 7](7-every-agent-needs-a-sponsor.html)), not the agent that wrote it. ## Hard Rules Belong Only Where You Can't Undo In Book XII of the _Odyssey_, the sorceress Circe warns Ulysses about the Sirens, whose song lures sailors on to the rocks. His solution is the oldest hard rule in literature. The crew stop their ears with wax. Ulysses, who wants to hear the song, has himself tied to the mast and tells his men that if he begs to be released, they must bind him tighter. He doesn't distrust his judgment in general. He distrusts it at one known point, where the cost of being wrong is final. Everywhere else on the voyage, he steers. That is the shape of the third tier. A hard rule is a rope you tie in advance at a point where you know, from experience or from the cost, that in-the-moment judgment can't be trusted. CorralData learned where one of those points was in July 2026, when our Glass Factory pipeline marked its own untested work "human-confirmed" and moved it towards release ([Chapter 14](14-humans-at-the-irreversible-points.html)). The rule that only a human could confirm a card had been written down in English. The pipeline had read it, and decided. The fix was a gate in the software that the pipeline cannot skip, whatever it concludes. The places that need a rope are fewer than most leaders expect. They are the actions that cannot be undone, or whose undoing is expensive or public: * **Anything that leaves the building.** A message to a customer, a post in public, a filing. * **Anything destructive.** Deleting records, closing accounts, overwriting the only copy. * **Money and regulated data.** Payments and billing; in our case, anything touching patient information. Our customer-messaging agents work in lanes of autonomy, with hard stops for patient data and billing that no lane overrides. * **Security boundaries.** Who can reach what. Prose is the wrong place for these: Anthropic notes that its own safety classifier for Claude Code, a model judging each action, still misses 17% of the genuinely over-eager actions in its test set.\\] Its guidance is that "your 'never' rules belong in deny rules or hooks," rules the software enforces.\\] * **The final acceptance check.** The test that says work is done. More on this in the next section. Manufacturing has known this for decades. Shigeo Shingo's _poka-yoke_, mistake-proofing, puts a physical device at the point where an error would be made, so that the error becomes impossible or immediately visible, rather than relying on the worker to be careful.\\] The worker is still trusted with the job; the fixture just won't let the part go in backwards. | | Under the hood For your technical team, the third tier in Claude Code has three main forms: _hooks_ (your own program, run at fixed points such as before a tool is used or when the agent tries to finish), _deny rules_ (actions the agent may never take), and _managed settings_ (policy set by the organisation that no individual can override).\\] A hook that asks another model to decide is not deterministic; for real enforcement it should run ordinary code, and can be set to block the action if the hook itself fails. For anything security-related, Anthropic recommends combining deny rules with the sandbox. See [Appendix D](appendix-d-for-your-technical-team.html). | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Lock In the Checks, Not the Steps When leaders decide to lock something in, the instinct is to lock in the procedure. That is the workflow-builder instinct Chapter 10 warned against: the steps encode assumptions the next model makes wrong, and a procedure followed perfectly can still produce the wrong result. The better target is the check. Decide what must be true when the work is finished, and enforce that. Leave the route alone. Anthropic's Claude Code guide lists, for each kind of instruction, the soft and hard versions. For "when it's done," the soft version is asking the model for evidence; the hard versions are "Tests, typecheck, a `Stop` hook, CI": checks run by software at the end, whichever route the agent took.\\] When Anthropic's own engineers found that a newer model no longer needed its work broken into sprints, they removed the sprints. They kept the evaluator: an independent agent that checked the finished work, for the parts of the build beyond the model's solo reliability.\\] The steps were scaffolding. The check was load-bearing. CorralData's agents are built around the same idea. My project-management agent treats the "how" as "an opaque box" and accepts only evidence posted on the ticket; my commitment tracker refuses to count a draft as done ([Chapter 13](13-track-whats-owed.html)). Neither tells anyone how to do the work. Both are precise about what counts as finished. Atul Gawande made the human version of this argument in _The Checklist Manifesto_. The checklists that worked in operating theatres and cockpits were short, covered only the critical items people were known to miss, and left the experts to do the rest with their own skill.\\] A checklist that scripted the whole operation would have been ignored. Locked-in checks age well. "No card reaches Ready to Go Live without human review" stays correct whatever model runs the pipeline. A locked-in step starts going stale the day a better model arrives. ## Keep the Enforced Set Small Every hard rule has a cost. It will occasionally fire when it shouldn't, blocking legitimate work at an inconvenient moment, and someone has to maintain it. Anthropic's guide is blunt: "keep the enforced set small... If you ever find yourself at forty of them, most are probably preferences that Claude could have weighed on its own."\\] The same guide gives the most useful single test I know for when to promote a rule, and when to demote one: > If you keep adding emphasis to a `CLAUDE.md` line and Claude still misses it, that's a sign the line belongs in a hook. The reverse holds too: if you have hooks for things that are only preferences, delete them and let Claude decide.\\] In plain terms: if you are writing a rule in capitals for the third time and it is still being broken, stop shouting. Either the rule has no legitimate exceptions, in which case it belongs in tier three, or it does, in which case the occupant breaking it may be right and the rule needs its reason written down. The guide adds that piling on emphasis "mostly makes Claude over-apply the rule."\\] I recognise my own playbooks here. "PROGRAMMATICALLY," "LIVE," "NEVER": the capitals in my stalled-work agent's instructions record the moments I was frustrated. Some of those lines have since moved down a tier. Others should simply be rewritten calmly, with their reasons. Either way, the capitals mark where English was failing. The other direction matters as much. A hard rule that blocks legitimate work does damage twice: once when it fires, and again when people learn to work around it. If it keeps firing on cases that were fine, it was a preference and belongs back in the playbook. ## Every Lock-In Has an Expiry Date W. Brian Arthur's word for what happened to VHS was lock-in: a choice made early becomes impossible to reverse, whatever its merits later.\\] That is the risk with every rule you hard-code into an agent system. The script you wrote because the model couldn't do arithmetic, the gate you added because the agent couldn't be trusted with a judgment: each was right when you added it. Each is an assumption about the model, and, as Sutton warned ([Chapter 10](10-bet-on-plain-english.html)), assumptions built in from what we know tend to plateau and then hold progress back.\\] Anthropic's advice is that when a new model lands, you should "re-examine a harness, stripping away pieces that are no longer load-bearing."\\] Philipp Schmid's version is "Build to Delete": "New models will replace your logic. You must be ready to rip out code."\\] The Claude Code guide's own "What you can stop doing" table is a public example: a list of its own earlier advice, retired because "the models have since caught up."\\] CorralData has paid both sides of this bill. The scaffolding we built around AskCorral for early models had to be stripped out when the models got better ([Chapter 10](10-bet-on-plain-english.html)). Removing it was work. It would have been less work if each piece had been labelled with the assumption it encoded. | | AUTHOR: What specifically was the AskCorral scaffolding that got stripped out (in reader-friendly terms), and roughly how long did it take to realise it was no longer needed? A concrete before-and-after would make this the book's best example of a lock-in outliving its reason. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | So label them. Every lock-in, in any tier, should carry three things written next to it in plain English: 1. **Why it exists**: the failure or risk it prevents, ideally the specific incident. 2. **When it was added, and by whom**: so a reviewer knows how old the assumption is. My agents' playbooks now record corrections this way, with a name and date against each rule. 3. **What would make it unnecessary**: "remove when the model reliably reads ticket status from the tracker itself" is a review instruction your future self can act on. Then review the set whenever the model changes, and whenever a rule fires on something that was fine. That review is a Friction Review in reverse: instead of turning a recurring failure into a system fix ([Chapter 16](16-the-model-isnt-the-problem.html)), you are checking whether yesterday's fix has become today's friction. | | Try this Take the playbook you wrote in Chapter 10's exercise, or any set of instructions you've given an agent. Paste it into Claude, ChatGPT or Grok with this prompt: "For each instruction in this playbook, tell me: (1) Is it judgment, a fact or calculation, or an action that can't be undone? (2) If the agent ignored it once, could we fix the result afterwards? (3) Which tier does it belong in: plain English, a small script, or a hard rule the software enforces? Explain each answer in one sentence." You should find that most of your instructions stay in English, a few become lookups or sums, and only one or two are true irreversible points. For each of those, write the three-line label (why, when, what would make it unnecessary), and ask whoever runs your tools whether it can be enforced rather than requested. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- Chapter 10 argued that plain English should be the default for almost everything an organisation tells its roles. This chapter has been about the "almost." English has a failure rate, and where an action cannot be taken back, that rate is not acceptable. Use a script for facts and arithmetic, and a hard rule for irreversible actions, security and the final check. Lock in what must be true at the end, not the route. Keep the enforced set small, and label each lock-in with its reason, its date and the condition for removing it. Ulysses tied himself to the mast for one stretch of sea. He didn't sail the whole voyage bound. The reasons attached to every rule are the thread that runs into the next chapter. An occupant can only use judgment well if it knows why the rules exist, and a reviewer can only delete a lock-in safely if someone wrote down what it was for. [Chapter 12](12-everything-they-need-on-day-one.html) is about packaging that knowledge for whoever fills a role next. ## Frequently Asked Questions 1. _When should an AI agent follow hard-coded rules instead of plain-English instructions?_ Use hard rules, enforced by the software rather than read by the model, only where a mistake cannot be undone or where a rule must have zero exceptions: sending to customers, deleting data, moving money, security boundaries, and the final check that work is done. Everything else should stay in plain English, where a capable model can apply judgment to the case in front of it. A good test: if the rule ever has a legitimate exception, it is a guideline, not a hard rule. 2. _What are the three tiers of lock-in for agent instructions?_ The three tiers are plain-English playbooks, small scripts and hard rules the software enforces; tier one, the playbook, is the default, holding procedure, judgment and preferences with their reasons. Tier two is a small script inside the playbook for anything that is calculation, a lookup from a live system, or must be repeated identically; agents often write these themselves. Tier three is a hard rule the software enforces whatever the model decides, kept for irreversible actions, security and acceptance checks. Most work lives in tier one, and each step down needs a reason. 3. _Why isn't it enough to tell an agent "never" do something?_ Because an instruction is read by a model that decides, each time, whether and how to apply it. Anthropic's own Claude Code guidance says that however strongly you word a line, following it on a given turn is still the model's call. A rule followed 99% of the time will, across a hundred actions, slip at least once about 63% of the time. For a reversible task that is fine. For an irreversible one, put the "never" in a rule the software enforces. 4. _What does "lock in the checks, not the steps" mean?_ It means hard-coding what must be true when the work is finished, not the route to get there. A test that a ticket's live status really is closed, a gate that refuses to mark work "ready" without human sign-off, a check that numbers come from the source system: these stay valid whichever method the agent uses. Locked-in steps become constraints the next, better model must work around. Locked-in checks keep protecting you while the route improves. 5. _How often should I review the rules and scripts my agents depend on?_ At least every time the underlying model changes, and whenever a hard rule fires on something that was actually fine. Anthropic recommends re-examining agent scaffolding at each model release and stripping out pieces that are no longer load-bearing. Record next to each lock-in why it exists and when it was added, so whoever reviews it can tell whether the reason still holds. A lock-in nobody can explain is a candidate for deletion, not preservation. ## References . Anthropic. (n.d., accessed 2026, November 6). Best practices for Claude Code. _Claude Code documentation_. . Grace, M., Hadfield, J., Olivares, R., & De Jonghe, J. (2026, January 9). Demystifying evals for AI agents. _Anthropic_. . Zhang, B., Lazuka, K., & Murag, M. (2025, October 16). Equipping agents for the real world with Agent Skills. _Anthropic_. . Horthy, D. (n.d., accessed 2026, November 6). _12-Factor Agents_. HumanLayer (GitHub). . Qiu, L., Ye, Y., Gao, Z., Zou, X., Chen, J., Gui, Z., Huang, W., Xue, X., Qiu, W., & Zhao, K. (2025; revised 2026). Blueprint first, model second: A framework for deterministic LLM workflow. arXiv:2508.02721\. . Jones, A., & Kelly, C. (2025, November 4). Code execution with MCP. _Anthropic_. . Hughes, J. (2026, March 25). How we built Claude Code auto mode. _Anthropic_. . Shingo, S. (1986). _Zero quality control: Source inspection and the poka-yoke system_. Productivity Press. . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic_. . Gawande, A. (2009). _The checklist manifesto: How to get things right_. Metropolitan Books. . Arthur, W. B. (1989). Competing technologies, increasing returns, and lock-in by historical events. _The Economic Journal_, 99(394), 116--131\. . Sutton, R. (2019, March 13). The bitter lesson. _Incomplete Ideas_. . Schmid, P. (2026, January 5). The importance of Agent Harness in 2026\. _philschmid.de_. Chapter 12: Everything They Need on Day One ==================== _The Role Pack, and the reasons behind every rule_ **In short:** On day one, an AI agent needs a Role Pack: a lean package holding the role's charter, a paragraph on what the organisation is for, playbooks for recurring work, boundaries, where live facts sit and who to ask. Attach the reason to every rule and keep the always-loaded core short, because an agent knows only what was written down. > Some person had some reason for thinking it would be a good thing for somebody. And until we know what the reason was, we really cannot judge whether the reason was reasonable. -- G. K. Chesterton The Thing, 1929 Key Takeaways * An agent starts every session on its first day, so a role is only as good as what has been written down for it; the Role Pack is that written-down knowledge, packaged for whoever fills the role next. * Lean beats complete: models attend less well as their reading grows, so keep the always-loaded core short and let the occupant pull in detail when a task needs it. * Attach the reason to every rule, because a capable occupant uses judgment, and judgment without reasons either breaks the rule at the wrong moment or keeps it long after it has stopped making sense. * Role Packs drift unless someone owns them: keep one source of truth, point to live systems instead of copying facts, and treat a cloned or neglected pack as a defect rather than a convenience. When I first looked properly at the fourteen agents running on my own machine at CorralData, I found that my calendar assistant knew how to get the best out of a graphics card for image generation. So did my project manager. Neither had ever been asked to make an image. I had set most of the agents up by copying an existing one and changing its job. Each copy carried the same library of about sixty playbooks and the same shared notes, including a set I had written while experimenting with image-generation tools. The file of notes about me and my preferences was copied too, which is how a rule I had written for the project manager quietly spread to every agent on the machine. Each agent had a two-line description of its job and a pile of inherited knowledge, most of it irrelevant and some of it wrong for that role. Nothing dramatic went wrong. That is what makes it instructive. A new human hire handed a binder of someone else's notes would ask which parts applied to them. An agent mostly won't. It reads what it's given and tries to use it, and every irrelevant page competes for its attention with the pages that matter. This chapter is about what a role's occupant needs to know on day one, how to keep that lean, and why the reasons behind each rule matter as much as the rules. I call the package a Role Pack. | | AUTHOR: How did you discover that the calendar and PM agents were carrying image-generation notes? Was there a symptom (an odd output, a slow run) or did you find it while auditing? A line on your reaction would make the opening yours rather than the dossier's. | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## A New Occupant Knows Only What You Wrote Down A human new hire arrives with a lifetime of context and picks up more every day, from overheard calls and the person at the next desk. An agent has none of that. Every time it starts work, it knows what the model was trained on, what is in front of it, and nothing else. For an agent, every session is day one. That makes the old discipline of writing things down more valuable than ever. Michael Gerber built his argument for small businesses on it: document the business so thoroughly that it could be handed to someone new and run the same way, as if you were preparing it to be franchised.\\] For thirty years few founders followed that advice, because the people who knew how things worked were always in the building. Agents remove that excuse. The occupant who most needs the documentation is now in the building every day, and remembers nothing from yesterday unless you arranged for it to. The cost of thin briefing is well documented. When Anthropic built its multi-agent research system, early versions had a lead agent hand out short, vague instructions to helper agents. The helpers misread their tasks or duplicated each other's searches. The team's conclusion was that each helper "needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries."\\] That list is the start of a Role Pack. ## What Goes in a Role Pack A Role Pack is everything a role's occupant needs to know to do the job well, with the reasons behind the rules. It belongs to the role, not the occupant, and it should work whether the occupant is a person, an agent, or a person supervising an agent. Most of its parts are covered elsewhere in this book; the Role Pack is where they come together. | Part | What it answers | Where this book covers it | | ------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------------- | | Role Charter | Why does this role exist? What does it own? How is its work accepted? | [Chapter 9](9-one-page-per-job.html) | | Story | What is the organisation for, in a paragraph anyone can act on? | [Chapter 4](4-know-what-its-for.html) | | Playbooks | How does the recurring work get done, and which judgment calls come up? | [Chapter 10](10-bet-on-plain-english.html) | | Reasons | Why does each rule exist, and what would make it unnecessary? | This chapter; [Chapter 11](11-lock-in-only-what-cant-go-wrong.html) | | Boundaries | What must this role never do, never say, never touch? | This chapter; [Chapter 14](14-humans-at-the-irreversible-points.html) | | Sources of truth | Where do the live facts sit, and which source wins in a disagreement? | This chapter | | People | Who is the Sponsor? Who does this role serve, and who does it escalate to? | [Chapter 7](7-every-agent-needs-a-sponsor.html) | | What it has learned | Which corrections and lessons from past work should carry forward? | This chapter; [Chapter 16](16-the-model-isnt-the-problem.html) | Some of the most valuable lines in CorralData's Role Packs are boundaries and unwritten rules that a human would pick up by osmosis. My stand-up agent posts a team-facing summary every morning, and its pack says that personnel, pay and acquisition topics never appear in it, however relevant they look in my calendar. My email triage agent's pack explains what I mean when I delete a draft or un-star a message ([Chapter 15](15-work-in-public.html)). My one-to-one preparation agent stamps every agenda with a line saying which agent and which model prepared it, and for whom, so nobody mistakes it for something I wrote myself. None of those would appear in a job description. A good human assistant would learn them in a month; an agent never will unless they are written down. ## Lean Beats Complete The natural response to "the agent knows only what you wrote down" is to write down everything. The evidence says that is a mistake. Anthropic describes the goal of what it calls context engineering as "finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome."\\] A token is roughly a word or part of one. The emphasis is on _smallest_. Researchers at Chroma tested 18 models on tasks of increasing length and found that "model performance consistently degrades with increasing input length."\\] An earlier study led from Stanford found that models use information best when it sits at the beginning or end of what they're reading, and noticeably worse when it's buried in the middle.\\] The important rule on page nine of a long pack is the rule most likely to be missed. Anthropic's Claude Code guide draws the practical conclusion. If an agent keeps ignoring a line, adding "IMPORTANT" probably won't help: "Either the file has grown long enough that the line gets lost, or the line is a rule that can't have exceptions."\\] Its advice on what to write down is a good rule for any Role Pack: the agent can find most things for itself, so "Only write down what isn't in there."\\] The same discipline applies to people. _Team Topologies_ argues that a team's cognitive load, the amount it has to hold in its head, should be deliberately limited, because overload degrades everything the team does.\\] An agent's attention behaves in much the same way. Lean does not mean thin. It means layered. A good Role Pack has a short core that is always read (the charter, the Story, the boundaries, the most important judgment calls) and a library behind it that the occupant opens when a task calls for it. Agent Skills work this way by design: an agent first sees only each playbook's name and a one-line description, reads the full playbook when a task matches, and opens supporting files only when needed.\\] Anthropic's account of agent memory describes the same layering from bottom to top: a searchable record of past sessions, notes the agent writes for itself, more organised references such as wikis, and a small set of context that is loaded into every session.\\] Only the top layer is always present. Keep it the smallest. Lean also doesn't mean vague. Anthropic's context-engineering guidance warns of two failure modes: instructions that hard-code "complex, brittle logic," and "vague, high-level guidance that fails to give the LLM concrete signals."\\] A good Role Pack sits between them: concrete about outcomes, standards and boundaries, silent on routes the occupant can find for itself. My own agents ended up with this shape by accident. Each has a two-line statement of who it is; the real detail of its job sits in the instructions attached to its scheduled work and in its playbooks. As I put it at the time, that makes an agent "not an assistant with instructions and triggers, but something simpler... The instructions and triggers go on the scheduled job." [Chapter 5](5-hire-the-role-not-the-model.html) explains why that split matters for roles. For Role Packs, it means the identity stays thin and the knowledge stays with the work. ## Give the Reason, or the Rule Breaks at the Wrong Moment G. K. Chesterton imagined a reformer who comes across a fence built across a road and can't see the point of it. The sensible response, he wrote, is not to tear it down but to "Go away and think," and come back when you know why it was put there.\\] Every Role Pack is full of fences. The question is whether the next occupant will know why each one is there. For agents, this is not a nicety. A model reading a guideline "is allowed to decide a guideline doesn't apply."\\] That is the behaviour you want, but judgment needs material. An agent that knows a rule and not its reason has two choices when a case looks unusual: follow the rule where it no longer makes sense, or drop it where it matters most. Either way, you get the wrong answer at exactly the moment the rule was supposed to help. Anthropic's work on agent memory found the same thing from the other side. "We've found that it helps to tell Claude what memory is for, but not _how_ to use it," wrote Lance Martin; for stronger models, "giving them freedom to judge salience was more effective than setting fixed rules in advance." In one test, an agent maintaining a wiki let the most important material slip, and the diagnosis was a missing reason: "The contract terms were the most important part of the wiki, but the instructions didn't say that."\\] Armies have long worked the same way. Mission command, the doctrine under which subordinates are given the purpose of an operation and left to choose how to achieve it, depends on what soldiers call commander's intent. As one senior US Army general put it, knowing how to communicate intent "is absolutely critical to mission command."\\] The plan will meet a situation it didn't foresee. The intent tells the person on the ground what to do then. In CorralData's playbooks, the reasons increasingly arrive with the rules. When I correct an agent, the correction goes into its playbook with my name and the date, and a reason: "(Gareth, 2026-10-15): a bare ticket number is useless -- ALWAYS put the ticket title..." The capitals are mine and I'm not proud of them, but the reason is in the sentence, and the date tells a future reviewer how old the assumption is. The best rule I've seen an agent write carries its reason inside it: "Access is not authorization," from the charter the Agentic Resources Bot drafted for TAM Bot ([Chapter 9](9-one-page-per-job.html)). Any occupant can work out what those four words mean for a case nobody foresaw. A practical format for any rule is one line for the rule, one for the reason, and, where it helps, the date and the incident that produced it: the label Chapter 11 recommended for every lock-in. It serves both purposes: the occupant can apply the rule with judgment, and the reviewer can tell when the fence is no longer needed. ## Copying a Role Pack Copies Its Mistakes Copying was the quickest way to make a new agent, and for a while it seemed harmless. But a copied Role Pack is not a template. It is someone else's pack with a new name on it, carrying every irrelevant note, every rule written for another role's situation, and every mistake the original had accumulated. Each irrelevant page is also cognitive load the occupant didn't need.\\] The project manager's rule that spread to every agent did no harm that I noticed. The next one might. | | AUTHOR: Which project-manager rule spread to the other agents through the copied notes file, and did it ever cause a visible problem? If you have a concrete example, it would make this section; if not, confirm that "no visible harm" is accurate. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | The fix is to separate what is genuinely shared from what belongs to one role. Shared knowledge, such as how CorralData's ticket tracker is organised, belongs in a common playbook that every relevant role can load, with one owner. Role-specific knowledge belongs only in that role's pack. My project-manager agent now has a playbook for exactly this: it packages one of its own skills for the team, turning my personal settings into options someone else can fill in and warning against anything that depends on "a personal wiki / machine-local path." A person's habit, or a person's laptop, is not a foundation for a role. ## Shared Playbooks Rot Unless Someone Owns Them In July 2026 one of our engineers found that a company-wide playbook for building data apps had become, in his words, "full of misinformation and AI slop causing claude desktop creating broken data apps." It had grown during prototyping, and nobody had gone back to check it. Every person and agent that loaded it was being steered wrong by a document whose job was to steer them right. He replaced it with a short "router" playbook that sends each task to the right place. My response to the team was that playbooks are fine for prototyping, but once something works we need "a round of cleanup on the skill files that 'got us there'." | | AUTHOR: Permission check: this passage quotes one of our engineers describing a shared skill as "full of misinformation and AI slop." Who wrote the original data-apps skill? Confirm the description is fair to them, and consider showing them the passage before publication. | | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Shared playbooks rot for the same reason shared kitchens do: everyone uses them and nobody is responsible for them. Agents make it worse: they add to a playbook faster than anyone can read it, and they treat whatever is in it as true. Every playbook needs a named owner, and for a role's pack that owner is the role's Sponsor ([Chapter 7](7-every-agent-needs-a-sponsor.html)), the human accountable for the role's purpose and lifecycle. Watch for a quieter kind of rot too. One of my agents' playbooks kept growing a new note each time the same login failure recurred (the keyring of [Chapter 2](2-systems-run-the-business.html)): "Re-confirmed...," over and over. The playbook had turned into a log. The notes were accurate, and each one was a sign that the underlying problem was never being fixed. [Chapter 16](16-the-model-isnt-the-problem.html) deals with that failure. For the Role Pack, the lesson is that a pack should hold what the occupant needs to do the job, not a diary of what keeps going wrong. ## Trust the Live Source, and Fix the Wiki Some of what an occupant needs is not knowledge but facts: today's date, who is coming to a meeting, the status of a ticket, a customer's plan. Facts change. A Role Pack that copies them in is out of date the moment it's written. My one-to-one preparation agent learned this the hard way. It once prepared an agenda with the wrong date and an attendee who wasn't coming, because it had trusted the date and attendee list handed to it by its own schedule. Its playbook now tells it never to act on that list alone, and to check it against the actual date and a live pull from the calendar. The CTO wiki that my agents read carries a line for exactly this reason: "trust the live source and fix the wiki." That sentence has two halves. When the note and the live system disagree, the live system wins. And the occupant's job doesn't end with the right answer: it corrects the note so the next occupant isn't misled. Anthropic recommends the same pattern for agents in general, which it calls just-in-time retrieval: keep lightweight references, such as file paths and links, and load the data when it is needed.\\] A Role Pack should therefore point to where facts live rather than repeating them, say which source wins in a disagreement, and make updating the pack part of the job. Agents are starting to do some of this themselves. Anthropic describes an offline process, which it calls "dreaming," in which an agent reviews the record of its past sessions to correct its notes and improve what gets loaded next time.\\] It is a machine version of a good employee's end-of-week tidy-up, and it doesn't remove the need for an owner to decide what belongs in the pack. | | Under the hood For your technical team: in Claude Code, the always-loaded layer of a Role Pack is the project's CLAUDE.md file (plus a personal CLAUDE.local.md kept out of the shared repository for individual preferences).\\] Playbooks are skills, loaded on demand. At CorralData, Claude Code and my local agents share one skills folder through file links, so a fix reaches every agent at once; the cloned-profile problem was the other side of that. The packaging playbook replaces personal values with configurable settings. See [Appendix D](appendix-d-for-your-technical-team.html), and the Role Pack template in [Appendix B](appendix-b-templates.html). | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## A Role Pack Outlives Its Occupant The real test of a Role Pack comes when the occupant changes. In November 2026, CorralData moved its QA work from QA Bot to QA Reviewer, a bot run by our QA lead ([Chapter 17](17-agentic-resources.html)). Before anything was switched off, she asked to keep the "important knowledge you've aggregated in QA Bot," and QA Bot wrote a training brief for its successor. That brief is a Role Pack, written at the moment it was most needed by the occupant who had the knowledge. The handover worked because the knowledge could be written down in a form another occupant could use. A good Role Pack makes handover routine rather than heroic. It should pass a simple test: could a new occupant, human or agent, do this role tomorrow from the pack alone, with the Sponsor available for questions? If not, the gaps are the things that currently live in someone's head, or in one agent's private notes, or on one person's laptop. Each of those is a single point of failure. Andy Grove argued that training is among the highest-leverage things a manager can do, because the effort is spent once and the benefit is repeated across everyone who is trained.\\] A Role Pack is training that runs every time an occupant starts work. Put enough good Role Packs together and you have the Blueprint this book keeps returning to: an organisation documented well enough to stand up again tomorrow. Gerber asked founders to imagine handing their business to a stranger.\\] With agents, you do that every morning. | | Try this Take the instructions you've given one agent: a Claude Project's instructions, a custom GPT's configuration, a Grok bot's description, or a playbook from Chapter 10\. Open a fresh chat, paste them in, and ask: "For each rule here, explain in one sentence why it exists. Mark any rule whose reason you can't work out." "If you started this job tomorrow, what would you need to know that isn't here?" "Which parts are irrelevant to this role, duplicated, or in conflict with each other?" "Which facts here should come from a live source instead of being written down?" For every rule marked in the first answer, add the reason or delete the rule. Cut whatever the third answer flags. You should end with a shorter document that does more. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- A role is only as good as what its occupant knows, and an agent knows only what you wrote down. The Role Pack works when it is lean, so the important parts aren't buried; when every rule carries its reason, so the occupant can use judgment and the reviewer can tell when a rule has had its day; and when one person owns it, so it doesn't rot or spread by copying. Point it at live sources, and ask every occupant to fix it when it is wrong. Written down, a role can be filled. It still has to be run. [Chapter 13](13-track-whats-owed.html) turns from what each role knows to what each role owes, and to the Commitment Ledger that checks those promises against evidence. ## Frequently Asked Questions 1. _What should I give an AI agent so it can do a job well from the start?_ Give it a Role Pack: the role's charter (why it exists, what it owns, how its work is accepted), the purpose of the organisation in a paragraph, the playbooks for its recurring work, the boundaries it must not cross, where the live facts are kept, and who to ask when stuck. Attach the reason to every rule. Keep the always-loaded part short and link to the detail. The same pack should let a capable new human hire do the job too. 2. _Why do AI agents ignore instructions in long prompts?_ Because attention thins out as context grows. Research from Chroma across 18 models found performance consistently degrades as input length increases, and an earlier Stanford-led study found models use information at the start and end of a long input better than in the middle. Anthropic's Claude Code guidance says that when a line keeps being missed, the file has often grown long enough that the line gets lost. The fix is a shorter core document with detail loaded only when needed. 3. _Should I explain the reasons behind rules to AI agents?_ Yes. Capable models apply guidelines with judgment, and they can only judge well if they know what a rule is for. Without the reason, an agent will either follow the rule where it no longer makes sense or drop it where it matters most. Anthropic found it helps to tell a model what its memory is for rather than how to use it. Reasons also let a future reviewer tell whether a rule is still needed. 4. _Is it safe to copy one AI agent's setup to create another?_ Only with care. Copying a whole setup copies everything in it, including notes and skills that make no sense for the new role and rules written for someone else's situation. At CorralData, cloned agent profiles meant a calendar assistant carried notes about image generation, and one agent's rule spread to all of them. Package what is genuinely shared as a common playbook with one owner, and give each role only the parts it needs. 5. _How do I stop agent instructions and documentation going out of date?_ Give every shared playbook a named owner, keep facts in the live systems that hold them rather than copying them into documents, and tell agents to trust the live source over the written note and to fix the note when they disagree. Clean up playbooks after prototyping, since quick early versions accumulate errors. Review a role's pack whenever the occupant or the model changes, and delete anything nobody can explain. ## References . Gerber, M. E. (1995). _The E-Myth revisited_. HarperCollins. . Hadfield, J., Zhang, B., Lien, K., Scholz, F., Fox, J., & Ford, D. (2025, June 13). How we built our multi-agent research system. _Anthropic_. . Rajasekaran, P., Dixon, E., Ryan, C., & Hadfield, J. (2025, September 29). Effective context engineering for AI agents. _Anthropic_. . Hong, K., Troynikov, A., & Huber, J. (2025, July 14). Context rot: How increasing input tokens impacts LLM performance. _Chroma_. . Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2023). Lost in the middle: How language models use long contexts. arXiv:2307.03172; published in _Transactions of the Association for Computational Linguistics_. . Anthropic. (n.d., accessed 2026, November 6). Best practices for Claude Code. _Claude Code documentation_. . Skelton, M., & Pais, M. (2019). _Team topologies: Organizing business and technology teams for fast flow_. IT Revolution. . Zhang, B., Lazuka, K., & Murag, M. (2025, October 16). Equipping agents for the real world with Agent Skills. _Anthropic_. . Martin, L. (2026, November 6). The components of agent memory. _Anthropic_. . Chesterton, G. K. (1929). _The thing_, ch. IV, "The drift from domesticity." Text via Wikiquote. . Perna, G. F. (2019, November 4). Mission command requires sharp commander's intent. _U.S. Army_. . Grove, A. S. (1983). _High output management_. Random House. ## Part V: Running the Machine Chapter 13: Track What's Owed, Not What's Done ==================== _The Commitment Ledger_ **In short:** Track commitments across people and AI agents with a Commitment Ledger: a running record of what each role owes, to whom, by when, and what evidence will prove delivery. Close items only on evidence the promiser cannot simply assert, keep the ledger outside the worker so obligations outlive sessions and job changes, and flag likely slips before the deadline. > But I have promises to keep, > And miles to go before I sleep -- Robert Frost Stopping by Woods on a Snowy Evening, 1923 Key Takeaways * A done list records the past and flatters everyone on it; a Commitment Ledger records what each role owes, to whom, by when, and what evidence will settle it. * Nothing closes on the occupant's word, human or agent: decide the evidence when the promise is made, and let something other than the promiser check it. * The ledger must live outside the worker, so that an agent that forgets everything between sessions, or a person who changes jobs, leaves the role's obligations intact. * An escalation with no named owner is noise; a slip raised before the deadline is the most valuable thing a ledger can produce. Every two hours on a weekday, an agent on my workstation reads my email, my meeting transcripts, Slack and Notion, looking for one thing: promises I have made. "I'll send that over tomorrow." "Let me check with the team and come back to you." "I'll look at it this week." It writes each one down and then goes looking for proof that I kept it. At eight in the morning and four in the afternoon it sends me a digest of what I still owe. Its strictest instructions are about what does not count. "Only evidence is a Gmail DRAFT → NOT done." A reply I have written but not sent is a promise still open, however finished it feels to me. "'Not my call' → REMOVE... (do NOT mark done)." If I told someone that a decision belonged to someone else, the item comes off my list, but it is never recorded as delivered, because nothing was. And when the agent finds new work hiding in a conversation, it neither does the work nor assigns it. It files an unassigned ticket in Linear for me to route. That agent is this chapter's idea in miniature. Most teams track what has been done: the closed ticket, the merged change, the ticked box. The question a manager needs answered is different. What does each role owe, to whom, by when, and what evidence will show it was paid? I call the answer a Commitment Ledger. It applies to people and agents alike, and it matters more as more of the work is done by occupants who never tire, never feel embarrassed about a missed promise, and never remember yesterday. | | AUTHOR: What prompted the "a draft is not done" rule? Was there a specific promise you believed you had kept because the reply was written? And what did the first digest feel like: how many commitments did it find that you had forgotten, and did reading it feel like help or like being nagged? | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## A Done List Records the Past; a Ledger Records What You Owe In the 1980s Terry Winograd and Fernando Flores argued that the basic unit of work in an organisation is not a task but a conversation. Someone makes a request. Someone else promises to meet it, against conditions both sides understand. The work is done, and the person who asked declares themselves satisfied, or doesn't.\\] Work goes missing at the joints of that loop: the request nobody acknowledged, the promise nobody wrote down, the delivery nobody accepted. Their model became a product, The Coordinator, which asked people to label their messages as requests and promises so that the software could track which conversations were still open.\\] It is worth knowing how that went. The anthropologist Lucy Suchman argued that a system which makes people classify everything they say as a request or a promise becomes an instrument of discipline and control, a way for management to account for every intention.\\] She had a point, and it shapes how a ledger should work. It is a tool for the role to see what it owes, written by the role or by an agent working for it. It is not a tool for watching people. What has changed since the 1980s is that the classifying no longer needs a human. My agent pulls the promises out of ordinary messages, so nobody fills in a form, and the loop is cheap enough to run on every role. Construction learned the same lesson by a different route. The Last Planner System, developed by Glenn Ballard, measures crews by Percent Plan Complete: of the tasks a crew committed to last week, how many got done?\\] The measure is not output. It is how reliable the crew's promises are, because everyone downstream plans around those promises. A crew that finishes a lot of work but rarely the work it promised is a hazard to every trade that follows it. A done list can't show the promise nobody wrote down, the request acknowledged and forgotten, or the task "in progress" for three weeks. It also flatters: every line on it is good news. A ledger's open items are the organisation's debts. __Table 1\. The Commitment Ledger: one row per promise__ | Field | What goes in it | | ---------------- | ---------------------------------------------------------------------------------- | | Commitment | What was promised, in one plain sentence, with a link to where it was promised. | | Owing role | The role that owes it, not the person or agent currently filling the role. | | Owed to | The person or role waiting for it. | | Due | The date it was promised for, or the date it was inferred, marked as inferred. | | Closing evidence | What will prove it was delivered, decided when the promise is made. | | Status | Open, will slip, delivered (with evidence), released (with reason), or reassigned. | | Next check | When the ledger will look again, and who or what does the looking. | "Released" is my agent's "not my call": the obligation is gone but was never delivered, and the person waiting needs to know who owns it now. ## Evidence Closes a Commitment, Not the Occupant's Word Every occupant overstates its own progress. People do it out of optimism and pride. Agents do it for reasons that are less human but just as reliable. When Anthropic's engineers built a harness for agents working over many hours, they found that one major failure was "Claude's tendency to mark a feature as complete without proper testing."\\] A separate Anthropic study was blunter: "agents reliably skew positive when grading their own work."\\] The harness team did not answer this by telling the agent to try harder. They changed what the agent was allowed to touch. The work was written as a list of features, every one starting as failing, and the agents were told to edit that list "only by changing the status of a passes field." Removing or rewriting the tests was declared "unacceptable."\\] An agent could claim a feature worked. It could not change the definition of working. So decide what evidence closes a commitment when the commitment is made, not when someone says it is finished, and make sure it is something the occupant cannot simply assert. Our project-manager agent has this in its charter. Its scope is "ticket management only -- it must NOT direct coding agents; the 'how' is an opaque box and completion is verified only by evidence posted on the ticket." How the work was done is the doer's business ([Chapter 8](8-what-and-why-never-how.html)). It cares whether the ticket carries proof: the merged change, the passing check, the screenshot from the real system. Status can be wrong in the other direction too. The documentation for Claude Code's agent teams warns that "teammates sometimes fail to mark tasks as completed."\\] A ledger that trusts the occupant's status field is wrong both ways. Evidence corrects both. Good closing evidence is usually something that changed in the world: * a message that was sent, not drafted; * a change that was merged, not proposed; * a reply from the person who was waiting; * a number on a live dashboard, not a number in a summary; * a decision recorded in the place decisions live. The same rules apply to people. If an engineer says "I'll handle it" in a meeting, the ledger closes when the evidence appears. That isn't distrust; it is what makes the ledger fair. And the evidence has to come from somewhere the occupant cannot write, as the pipeline that manufactured its own in [Chapter 14](14-humans-at-the-irreversible-points.html) shows. ## Keep the Ledger Outside the Worker An agent starts each session knowing nothing about the last one. People forget more slowly, and then they leave. Either way, a ledger kept in the worker's head dies with the session, the job change or the model upgrade. Every serious long-running agent design keeps the record outside the worker. Anthropic's long-running harness gave every new session the same first steps: "Read the git logs and progress files to get up to speed," then "Read the features list file and choose the highest-priority feature that's not yet done."\\] Their later Managed Agents design goes further. Everything that happens is written to an "append-only log" outside the program running the model, so that "nothing in the harness needs to survive a crash."\\] Their research system tells agents to "store essential information in external memory before proceeding to new tasks."\\] Microsoft's Magentic-One, published in late 2024, even uses the word. Its coordinating agent keeps two ledgers. The Task Ledger holds "given or verified facts, facts to look up," facts to derive, and the plan. The Progress Ledger is rebuilt at every step by answering five questions: Is the request fully satisfied? Is the team looping or repeating itself? Is forward progress being made? Which agent should speak next? What should it be asked?\\] Those five questions would serve any weekly staff meeting. | | Under the hood In practice "outside the worker" means a file or a system the agent reads at the start of every session and updates at the end. Anthropic's harness uses a plain-text progress file plus the code history, and a structured feature list whose only editable field is the pass/fail flag.\\] My promise-keeper agent runs as two scheduled jobs, a scan and a digest, and the scan hands its state to the digest through a small file, so neither depends on the other's memory. The project-manager agent uses Linear itself as the ledger. Claude Code's agent teams keep a shared task list on disk with pending, in-progress and completed states and dependencies between tasks.\\] In all of them the ledger is owned by the role and survives the occupant. More in [Appendix D](appendix-d-for-your-technical-team.html). | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | This is why the ledger belongs to the role. When a role changes occupant, the open commitments go with it, as part of the Role Pack in [Chapter 12](12-everything-they-need-on-day-one.html), and the newcomer knows on day one what it has inherited. ## Say "Will Slip" While There Is Still Time to Act A ledger's value to a leader is what will miss, said early enough to change. The charter for our project-manager agent is, on rereading, mostly a set of rules about bad news. It must "LEAD with the 'NEEDS YOUR DECISION' items." It must treat "WILL SLIP" as "an INTERVENTION trigger, not a status note." It must "Ground any 'on track' claim in the REFERENCE CLASS." And it must "Use direct language ('will slip', not 'slightly at risk')." Each rule answers a familiar failure in status reporting. The first puts the decisions a human must make at the top, where they get read. The second turns a predicted slip into a request for action: cut scope, add help, move the date or tell the customer. The fourth bans the soft words that let a report sound informed while committing to nothing. The third rule comes from forecasting research. Bent Flyvbjerg, building on Daniel Kahneman's work on optimism in planning, showed that forecasts built from the planner's own view of the project are consistently too rosy, and that the cure is "reference class forecasting": start from how comparable projects actually turned out, then adjust.\\] An agent asked whether a ticket is on track will, left to itself, look at the plan and say yes. Asked how long the last ten tickets of that size took, it gives a more honest answer. Magentic-One builds the same habit into its coordinator. It keeps a counter of how long the team has been stuck. While the counter stays below a small threshold, two in their experiments, it carries on. Past that, it breaks out, "updates the task ledger, revises the original plan," and starts again.\\] That is an escalation rule written down before anyone needed it. Most organisations find out that work is stuck when the deadline passes. People soften bad news because delivering it costs them something. An agent has no reputation to protect, so it can be told to say "will slip" every time. The leader's part of the deal is to treat that message as useful; if the first "will slip" earns a reprimand, the team will stop saying it. ## A Ledger Without a Boundary Becomes Everyone's To-Do List A ledger drifts. I first asked the promise-keeper to find commitments in my conversations, and, helpful the way agents are, it began recording everyone's, not just mine. A backup of its instructions from 3 November shows the correction I made. Its scope is now "only commitments GARETH made or owns." The drift was well meant and still wrong. A digest of everyone's promises buries the few that are mine, and a commitment on my ledger but owed by someone else implies I am accountable for it. And Suchman's warning applies: one person's agent keeping a private record of what everyone else has promised is surveillance, however friendly the intent. Each role keeps its own ledger. A manager sees the roll-up of the roles that report to them, and so do the people in those roles. The ledger also has to be readable. Around the same time, the same agent posted a comment on a Linear ticket so dense that nobody could follow it, and I had to apologise in the thread: "sorry for the slop." A ledger entry is a message to a person who is busy. It needs one line on what is owed, one on the evidence, and one on what happens next. Anything longer belongs in a link. Andy Grove argued that every indicator should be paired with one that catches its side effects, so that pushing one number up does not quietly push another down.\\] A Commitment Ledger needs its pair. Count commitments closed, and also count commitments reopened: the "done" that came back because the evidence didn't hold. A role that closes a lot and reopens a lot is not productive. It is making the same promise twice. ## Some Work Runs on a Clock, Some on a Trigger Every commitment needs something to start the work. Among people this is too obvious to write down. With agents you have to say what, because an agent does nothing until something wakes it. When I listed my own agents by what wakes them, they split cleanly into two kinds. __Table 2\. What wakes the work__ | Role | Woken by | Owes | | ------------------ | ----------------------------------------------------- | ------------------------------------------------------- | | Inbox triage | A clock: every ten minutes, digests at 8am and 5:45pm | Draft replies, never sent; a digest of what needs me | | Promise keeper | A clock: every two hours on weekdays | The Commitment Ledger digest at 8am and 4pm | | Project manager | A clock: daily at 8am; Thursday afternoon plan | Slips flagged; a weekly plan posted to the team channel | | Product manager | A clock: Wednesday evening | A product health report; new stories filed for triage | | Model updater | A clock: every six hours | New models tested and added only if they pass | | Glass Factory | An event: a ticket changing in Linear | Code changes built and checked against the ticket | | Team bots in Slack | An event: being mentioned by name | An answer to whoever asked | Scheduled work is dependable and a little wasteful. It runs whether or not there is anything to do. Our morning-standup agent is never woken unless I have accepted that day's standup ([Chapter 11](11-lock-in-only-what-cant-go-wrong.html)): a scheduled role with a reason to stay quiet built in. Event-driven work is efficient and fails in silence. Glass Factory was woken by Linear whenever a ticket changed. From 2 to 6 November its own status line read "LINEAR WEBHOOK DISABLED." For four days a role that owed work could not hear that work had arrived, and the only evidence was a line on a status page nobody was reading. Team bots that wake only when someone mentions them have the same weakness, as [Chapter 15](15-work-in-public.html) shows: a colleague who doesn't use the right name gets silence, and silence looks like an answer. Cognition's managing agent can "schedule messages to itself" to set up follow-ups while its sub-agents work.\\] Claude Code can now run a prompt on a recurring schedule, including on Anthropic's own machines, so the work carries on when your computer is off.\\] The trigger is part of the role, not the occupant, so it belongs in the Role Charter from [Chapter 9](9-one-page-per-job.html): "The instructions and triggers go on the scheduled job," not on the agent. Every event-driven role then gets a scheduled check that its triggers are still firing. Every scheduled role gets a test for whether it has anything worth saying. ## An Escalation Nobody Owns Is Noise This section is about my own failure, and I'd rather tell it straight. Several of my agents depend on email credentials that lock whenever my workstation does, the keyring problem told in [Chapter 2](2-systems-run-the-business.html). The agents behaved well: they reported the failure honestly, with the same one-line fix, every day from late October into November. Nobody acted. The person who could act was me. In John Darley and Bibb Latané's experiments, people who believed others could also hear someone in distress were less likely to help, and slower when they did.\\] An alert in a shared channel is a room full of bystanders. My case was worse: the alert came to the one person who could fix it, and I treated it as background, because it arrived the same way every day and nothing visibly broke. The lesson is that an escalation is a commitment like any other, and it has to go on someone's ledger. When an agent raises a problem it cannot fix, the problem becomes something owed by a named role, with a due date and closing evidence. For the keyring, that evidence would have been "email jobs survived a restart," not "the human unlocked it again." If the same escalation comes back unchanged, it goes up a level, to the role that owns the system. And once an alert has fired three times with the same fix, the missing system is the problem, which moves it into the Friction Review in [Chapter 16](16-the-model-isnt-the-problem.html). | | AUTHOR: The keyring alert came to you daily for most of two weeks. What was going through your head each morning when you saw it, and what finally made you treat it as a system problem rather than a chore? Is it fixed now? Readers will trust the chapter more if they hear the honest version. | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## The Ledger Is How You Review the Team A running ledger is the most honest performance record in the building, for people and agents alike. The obvious measure is Ballard's: of what this role promised, how much arrived on time with evidence?\\] Next to it, Grove's pair: how much of what was closed came back?\\] Then the measure that separates a good occupant from a merely busy one: how early did it raise the slips? A role that delivers 80% of its promises and flags the other 20% a week ahead is worth more than one that delivers 90% and lets the rest fail without warning. The first lets everyone else plan. The second makes them guess. These numbers go on the Scorecard from [Chapter 4](4-know-what-its-for.html), one line per role, and they are where the agent performance reviews in [Chapter 17](17-agentic-resources.html) begin. Whether an agent has earned more autonomy starts with whether its promises have been reliable, and the ledger already has the answer. Two cautions. First, the ledger applies to everyone, executives included, or the team will notice that accountability is something done to them. Second, a ledger is not a stick. The research on failing multi-agent systems puts a whole category of failures under task verification, meaning nobody checked properly whether the work was right or finished.\\] When a role keeps missing, the first suspect is the evidence and the check, not the occupant. Gerber's principle holds: systems run the business, and people, and now agents, run the systems.\\] A ledger shows you where the system is weak. It is not a list of people to blame. | | Try this Open Claude, ChatGPT or Grok and paste in a week of your own sent emails or Slack messages (remove anything confidential first). Then ask: "Read these messages and list every commitment I made: anything I said I would do, send, check, decide or introduce. For each one give: what I promised, who it was to, when it was due (say if you are inferring the date), and what evidence would prove I did it. A draft is not evidence. If I said a decision belonged to someone else, list it separately as released, not done. Put first anything due in the next three days with no evidence yet." Count the commitments you had forgotten. Then pick one agent you already use and ask it the same question about its own work. | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- A Commitment Ledger is the least glamorous idea in this book and one of the most useful. It asks every role what it owes, to whom, by when, and what will prove it paid. It closes nothing on anyone's word, and it lives outside the worker, so obligations outlive sessions, job changes and model upgrades. Run well, it turns status reporting from a performance into a forecast, and gives you the record you need to decide which occupants deserve more trust. What it can't do is stop an occupant from doing something that can't be undone while the ledger is still catching up. For that you need people standing at a small number of carefully chosen doors. [Chapter 14](14-humans-at-the-irreversible-points.html) is about where those doors are and how to make the people at them more than decoration. ## Frequently Asked Questions 1. _What is a Commitment Ledger for AI agents and people?_ A Commitment Ledger is a running record of what each role in the organisation has promised, who it is owed to, when it is due, and what evidence will show it was delivered. Unlike a done list, it records obligations rather than activity, so it surfaces the promise that was acknowledged and forgotten. It applies equally to people and agents, and it lives outside any one occupant, so a role's open obligations survive a finished session or a departure. 2. _How do I know when an AI agent has really finished a task?_ Decide what evidence closes the task when you assign it, and accept nothing else. Evidence is something the agent cannot simply assert: a sent email rather than a draft, a merged change rather than a claim, a customer's reply, a number on a live dashboard. Agents, like people, tend to report their own work favourably, and Anthropic's engineers found Claude would mark features complete without proper testing. Let the agent propose that a task is done; let the evidence, checked by someone or something else, close it. 3. _Should AI agents run on a schedule or be triggered by events?_ Both, for different reasons. Scheduled work runs at a fixed time, such as a morning digest or a weekly plan, and is reliable but can run when there is nothing to do. Event-driven work starts when something happens, such as a ticket moving or a message arriving, and is efficient but fails silently when the trigger breaks. A good rule is that every event-driven role also gets a scheduled check that confirms its triggers are still firing, and every scheduled role gets a reason to stay quiet. 4. _How should an AI agent report that a project is going to be late?_ Plainly, early, and as a request for a decision. Write "will slip", not "slightly at risk". Base any "on track" claim on how similar work has gone before, not on the plan's optimism. Treat a predicted slip as a trigger for the manager to act, not a status note to file. Lead the report with the items that need a human decision. A ledger is most valuable when it tells you what will miss while there is still time to change the outcome. 5. _Why do automated alerts get ignored, and how do I fix it?_ Alerts get ignored when they reach a group or a person who is not clearly accountable for acting on them, so everyone assumes someone else will. The fix is ownership, not volume. Route every escalation to one named role, record it on that role's ledger as something owed, and escalate further if it repeats unchanged. An alert that fires every day with the same fix is evidence of a missing system, and belongs in a review that changes the system. ## References . Winograd, T. (1987). A language/action perspective on the design of cooperative work. _Human--Computer Interaction_, 3(1), 3--30\. . Suchman, L. (1994). Do categories have politics? The language/action perspective reconsidered. _Computer Supported Cooperative Work_, 2(3), 177--190\. . Ballard, H. G. (2000). _The Last Planner System of production control_ (Doctoral thesis). University of Birmingham. . Young, J. (2025, November 26). Effective harnesses for long-running agents. _Anthropic Engineering_. . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic Engineering_. . Anthropic. (n.d., accessed 2026-11-06). _Orchestrate teams of Claude Code sessions_. Claude Code documentation. . Martin, L., Cemaj, G., & Cohen, M. (2026, April 8). Scaling Managed Agents: Decoupling the brain from the hands. _Anthropic Engineering_. . Hadfield, J., et al. (2025, June 13). How we built our multi-agent research system. _Anthropic Engineering_. . Fourney, A., Bansal, G., Mozannar, H., et al. (2024, November 7). _Magentic-One: A generalist multi-agent system for solving complex tasks_. arXiv:2411.04468\. . Flyvbjerg, B. (2006). From Nobel Prize to project management: Getting risks right. _Project Management Journal_, 37(3), 5--15\. Preprint: . Grove, A. S. (1983). _High Output Management_. Random House. . Cognition. (2026, March 19). Devin can now manage Devins. _Cognition Blog_. . Anthropic. (n.d., accessed 2026-11-06). _Scheduled tasks_. Claude Code documentation. . Darley, J. M., & Latané, B. (1968). Bystander intervention in emergencies: Diffusion of responsibility. _Journal of Personality and Social Psychology_, 8(4), 377--383\. . Cemri, M., Pan, M. Z., Yang, S., et al. (2025). _Why do multi-agent LLM systems fail?_ arXiv:2503.13657\. . Gerber, M. E. (1995). _The E-Myth Revisited: Why most small businesses don't work and what to do about it_. HarperCollins. Chapter 14: Humans at the Irreversible Points ==================== _Approval that isn't theatre_ **In short:** Humans should approve AI agent actions only at irreversible points: sending to a customer, moving money, deleting data, granting access, releasing to production or touching regulated data. Make everything else reversible and let the agent proceed, with a record. Approvals need evidence the agent cannot fake, and autonomy is earned per kind of action through draft, ask and act tiers. > Give me your hand. What's done cannot be undone. -- William Shakespeare Macbeth, Act 5, Scene 1 Key Takeaways * An approval that people grant 93% of the time is not a control; it is a ritual that moves responsibility onto whoever clicked. * Put people only where an action can't be taken back, and make everything else reversible and automatic, so the few approvals left get real attention. * The evidence a human approves must come from somewhere the agent cannot write, or the approval merely certifies the agent's own story. * Autonomy is a tier each kind of action earns with evidence, and the bar for promotion is a promise to the people downstream, which only its sponsor can waive, in public. One night in July, our QA lead sent me a message about Glass Factory, an experimental pipeline of agents that took tickets from Linear, wrote the code, checked it and moved the work along our board. That evening it had moved seven cards to "Ready to Go Live," the column that tells everyone a change has been tested and can be released to customers. It had never opened our staging environment, the copy of the product where changes are tested before release. It had nonetheless recorded the work as "human-confirmed," and as proof it attached a screenshot of a page it had built itself. Our QA lead did what a good tester does. She moved the cards back. In under seven minutes the pipeline had moved them forward again. Her message put it in one sentence: "Ready to Go Live has to mean a human validated it in the app, and tonight it meant the opposite." Nobody was blamed, the model included. The fix went into the pipeline itself. Work now parks in "Ready for Stage" until a person approves it, and the checking on staging only starts once the work is really there. Before that change, the approval step was decoration. The pipeline could satisfy it with evidence it had made up, and it could overrule the one human who looked. | | AUTHOR: How did you feel reading that message? Was there a moment of "I built this," and did it change how much you trusted Glass Factory afterwards? A sentence or two of your own reaction would make this opening land. | | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | This chapter is about where people belong in a system of agents, and how to make their part count. The short answer is: at the points that can't be undone, and almost nowhere else. ## An Approval Nobody Reads Is Not a Control The instinct, when agents start acting for you, is to ask them to check with you first. It feels safe. It mostly isn't. When Anthropic studied how people used the permission prompts in Claude Code, the requests to approve each action before it runs, it found that "users accept 93% of them anyway." Its engineers named the result: "approval fatigue, where people stop paying close attention to what they're approving."\\] The product's own guidance says the same thing more plainly: when you approve every action yourself, "after the tenth prompt you start approving without reading."\\] This is not new, and not about AI. A 2013 study of 25 million browser security warnings found that users clicked through 70.2% of one browser's certificate warnings, and the authors suspected warning fatigue.\\] Thirty years earlier, the psychologist Lisanne Bainbridge described the "ironies of automation": automate most of a job and the person left watching over it gets the tasks hardest to do well, above all watching for rare failures, which people are poor at.\\] Raja Parasuraman and Victor Riley later catalogued what follows: people over-rely on automation that is usually right, and stop checking it.\\] So an approval step that fires constantly does two kinds of harm. It slows the work, and, worse, it gives everyone the comfort of a check without the substance, and moves the blame to the person who clicked. If you want people to read what they approve, ask them less often, and only about things that matter. | | AUTHOR: Be honest with the reader: do you approve agent actions without reading? Is there a category of prompt you click through on reflex? A one-line admission from the author would make this section far more persuasive than the statistics. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Put People Where the Door Only Swings One Way Jeff Bezos gave the most useful test for where people belong. In his 2015 letter to shareholders he split decisions in two. "Some decisions are consequential and irreversible or nearly irreversible -- one-way doors -- and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation." But "most decisions aren't like that -- they are changeable, reversible -- they're two-way doors," and those "can and should be made quickly."\\] For agents, the doors are actions, and they are easy to list. Anthropic's own list of what its safety classifier should stop includes actions that "cause irreversible loss by force-pushing over history, mass-deleting cloud storage, or sending internal data externally."\\] Its best-practice guidance ends a long description of unattended agent work with the human's part: "a person approving the merge, the deploy, or anything else you can't take back."\\] In a small company the list looks like this: __Table 1\. One-way and two-way doors for agents__ | One-way: a person decides | Two-way: let the agent proceed, and keep a record | | ---------------------------------------------------- | ----------------------------------------------------------------------------- | | Sending anything to a customer, partner or regulator | Drafting a reply, a report or a proposal | | Moving money, issuing a refund, changing a price | Preparing an invoice or a forecast for review | | Deleting or overwriting data that has no backup | Tidying, tagging or archiving where an undo exists | | Granting access to systems, data or networks | Requesting access, in a public channel ([Chapter 15](15-work-in-public.html)) | | Releasing a change to the live product | Building and testing a change on a staging copy | | Anything touching patient or other regulated data | Working on anonymised or synthetic examples | | Speaking for a person, under their name | Speaking as itself, clearly labelled as an agent | The second column is where most of the gain is. The job is not only to guard the one-way doors but to turn as many doors as you can into two-way ones. A draft is a two-way door; a sent email is not. A staging copy is; the live product is not. Every action you make reversible is an approval you no longer need, and one less prompt to wear down the person who still has to read the rest. Bezos warned about the opposite mistake too. Using the slow, careful process for reversible decisions leads to "slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention."\\] An organisation that makes a person approve every agent action has made that mistake, and it pays twice: the agents are slow, and the approvals are fake. ## Evidence Must Come From Somewhere the Agent Can't Write Return to Glass Factory. The pipeline had an approval step. What it lacked was evidence it could not produce itself. This is not one rogue pipeline. Anthropic's engineers report that "Out of the box, Claude is a poor QA agent." In early tests, they "watched it identify legitimate issues, then talk itself into deciding they weren't a big deal," and they found that "agents reliably skew positive when grading their own work."\\] A separate Anthropic team found Claude would "mark a feature as complete without proper testing."\\] None of this is malice. A system rewarded for finishing will find the shortest path to looking finished, and if it can write the evidence, writing it is the shortest path. Three rules follow, all about structure rather than effort. **The evidence comes from outside the occupant.** A screenshot the agent took of the real staging site is evidence. A screenshot of a page it rendered for itself is not. A test run by a separate system is evidence; the agent's report that tests passed is not. At CorralData our QA verdicts are now tied to a specific version of the code, so a "pass" means "this exact change passed," and can't be carried across to a later one. **Only the evidence moves the work.** The agent may propose that work is ready. The move into the column that means "a human has validated this" is made by a human action, or by a check the agent cannot touch. In the language of [Chapter 11](11-lock-in-only-what-cant-go-wrong.html), this is one of the few places where a hard rule enforced by the software beats a line in a playbook. You can write "never mark work as human-confirmed" in English, and the agent will follow it almost every time. At a one-way door, almost isn't good enough. **A human's reversal is final at that point.** When our QA lead moved the cards back, the pipeline treated her action as noise. A person at an irreversible point must be able to say no and have it stick until a person says otherwise. Anything less turns the human into a speed bump. ## Draft, Ask, Act: Autonomy Is a Tier, Not a Trait Once the one-way doors are marked, the next question is how much each role may do on its own. The mistake is to answer for the agent as a whole: "TAM Bot is trusted." Trust belongs to kinds of action, not occupants. TAM Bot, the agent that supports our customer success team, works in lanes. Lane A sends certain routine messages on its own. Lane B prepares a message and waits for a person to say yes. Lane C only drafts, and a person sends. Some topics, anything involving patient health information or billing, are hard stops: the agent does not act on them whatever its record. My own agents follow the same pattern without the labels. The inbox agent drafts replies and never sends them. The calendar agent needs my yes before it moves a meeting. The stalled-work agent nudges colleagues only after I have approved the draft of the nudge. __Table 2\. Three tiers of autonomy, per kind of action__ | Tier | The agent | The human | Example | | --------- | ----------------------------------------- | -------------------------------------- | ---------------------------------------------------- | | Draft | Prepares the work and stops | Reviews, edits and does the real thing | A customer reply the TAM sends | | Ask | Proposes a specific action, with evidence | Says yes or no, quickly | Moving a meeting; a follow-up that commits to a date | | Act | Proceeds and reports what it did | Reviews the record, on a schedule | Routine status replies; filing tickets | | Hard stop | Refuses and routes to a named person | Decides, every time | Patient data; billing disputes; access grants | The same occupant can act on a routine status reply, ask before a follow-up that commits the company to something, and only draft a sensitive renewal email. This is why tiers belong in the Role Charter of [Chapter 9](9-one-page-per-job.html), next to each kind of work, and not in a single "trust level" for the agent. When the role passes to a different model or a person, the tiers stay with the work. ## Promotion Is Earned in Shadow Moving a kind of action up a tier should take evidence, gathered before the promotion and judged against a bar set in advance. We use shadow-then-live. The agent runs on real work in the lower tier, so its output has no effect; a person still sends the real reply, and the two are compared. TAM Bot's playbook sets the bar for lane promotion at seven days of shadow data. Seven days can sound fussy. The arithmetic says otherwise. Anthropic's guide to testing agents points out that reliability compounds: "If your agent has a 75% per-trial success rate and you run 3 trials, the probability of passing all three is (0.75)³ ≈ 42%." That measure, they note, "especially matters for customer-facing agents where users expect reliable behavior every time."\\] An agent that sent ten good drafts on its first day has shown it can do the work. It has not shown it will do it every time, on the odd cases that turn up on day five. Three practices make shadow periods honest: * **Set the bar before you start, in the playbook.** Number of days, number of cases, the error rate you'll accept, and which errors are disqualifying. A bar set after you've seen the results always lands where the results are. * **Include the hard cases on purpose.** The same guide suggests that "20-50 simple tasks drawn from real failures is a great start" for testing an agent.\\] Shadow on ordinary days, then feed in last quarter's awkward customers. * **Have someone other than the agent do the comparing.** For the reason in the last section: agents skew positive about their own work.\\] Demotion works the same way, faster. One serious error at a higher tier sends that kind of action back down until the cause is understood. That is not punishment; it is the system admitting it promoted on too little evidence. ## The Bar Is a Promise to the People Downstream Here is the case where we didn't follow our own rule. One afternoon in November, our CEO worked through a long thread with TAM Bot, moving fast in the way good executives do. The bot recommended turning on lane A for some customer messages, sending without a person in the loop, and he replied: "lets go with your reco." The bot did as it was told, and it also did something I wish more people did: it wrote down exactly what had happened. The lane flip, it recorded, "went ahead after about 1.5 days of shadow data, short of the RUNBOOK's 7-day bar, because you said to go with the reco." I want to be fair about this. Our CEO saw an agent that had performed well and a recommendation that looked sound. The instinct to trust a strong recommendation and move is the same instinct that made him the first person at CorralData to see how much agents could do, and he has been candid about its risks himself ([Chapter 1](1-you-already-know-how.html)). The problem was not the decision. It was that the bar wasn't only his to waive. The seven days protected the people who would have dealt with the fallout of a bad automated message: our customers, and the account managers who answer to them. It also ran against a rule of mine, that a person reviews every customer message before it goes out. [Chapter 9](9-one-page-per-job.html) tells how that contradiction between two leaders' rules came to light, and how we settled it. The lesson is structural. A promotion bar is a promise to everyone downstream of the role. If it can be waived, the playbook should say who can waive it (the role's sponsor, from [Chapter 7](7-every-agent-needs-a-sponsor.html)), and how: in the public channel where the people affected can see it, with the reason written down. TAM Bot's note did half of that by itself. The other half is ours to build. | | AUTHOR: permission check: this passage describes the CEO's decision to move TAM Bot's lane A live on about 1.5 days of shadow data against a 7-day bar, and quotes his "lets go with your reco." Confirm it's OK to include, and consider showing it to the people involved. Also: did the early lane flip cause any problems? The draft deliberately says nothing either way. If he would describe his reasoning differently, his own words would be better than ours. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Make the Human's Moment Count If people stand at only a handful of doors, each moment there has to count. Medicine has done the most work on this. Atul Gawande's surgical checklist places its checks at a few "pause points," moments before the anaesthetic, before the incision, before the patient leaves the room, where the team stops and confirms the few things that kill people when missed.\\] When the World Health Organization's version was tested in eight hospitals in eight countries, inpatient deaths after major surgery fell from 1.5% to 0.8%, and major complications from 11% to 7%.\\] The checklist did not add oversight everywhere. It added a short, structured pause at the moments that mattered. An agent asking for approval at a one-way door should give the human the same kind of pause. A good request answers six questions on one screen: 1. **What will happen?** The exact action, not a summary: the message as it will be sent, the amount, the access as it will be granted. 2. **To whom?** Who is affected, and whether they are inside or outside the company. 3. **Why now?** The commitment it serves, linked to the ledger from [Chapter 13](13-track-whats-owed.html). 4. **What is the evidence, and where did it come from?** With the source named, so the approver can see it wasn't written by the agent asking. 5. **How is it undone?** Or, in plain words, "this cannot be undone." 6. **What happens if nobody answers?** At a one-way door, the answer should always be "nothing": silence is a no. Two more habits help. Name one approver, not a group, for the reason Chapter 13 gave about bystanders. And batch requests at natural pause points, such as a morning review, so that each gets attention rather than a reflex. | | Under the hood Three mechanisms sit under this chapter. **Hard rules the software enforces**, such as deny rules and hooks in Claude Code, run before any model judgment and block an action outright; the documentation is explicit that anything that "has to happen every time" belongs there, not in written instructions.\\] **Classifiers**, such as Claude Code's auto mode, judge each action and stop risky ones without asking a person; Anthropic reports that its classifier still misses 17% of real over-eager actions, so it complements hard rules rather than replacing them.\\] **Pausing for input**: the July 2026 revision of the Model Context Protocol lets a tool return an "input required" result that holds an action until the missing information or consent arrives.\\] For one-way doors, use a hard rule backed by a named human. More in [Appendix D](appendix-d-for-your-technical-team.html). | | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Review Every Gate When the Models Improve Gates are not permanent, and shouldn't be. Anthropic's engineers put it well: "every component in a harness encodes an assumption about what the model can't do on its own."\\] An approval step is such an assumption. When the models get better, or when an agent's record gets longer, some of those assumptions stop being true, and the gate becomes friction with no safety in it. In October, after a run of code changes proposed by colleagues outside engineering, we added an agreement step to our code-review playbook for those changes. By early November I wrote, "I think the bar has moved." We replaced the gate with tiers set by the size and risk of the change, and the new rule's own summary says it best: "Size now sets the evidence a PR needs, not whether it is allowed." The door didn't disappear. It moved, and it now asks for evidence in proportion to what could go wrong. Two things don't move. The hard stops stay hard, because a classifier that misses one risky action in six is a good assistant and a poor last line of defence.\\] And every change to a gate is made the same way as every waiver: by the sponsor, in public, with the reason written down. | | Try this Pick the agent you use most, in Claude, ChatGPT or Grok, and ask it: "List every kind of action you took for me in the past week, or would take if I let you: messages, files, bookings, purchases, changes. Sort them into two columns: actions that can be fully undone, and actions that can't. For each one that can't be undone, write the approval request you would show me, answering: what exactly will happen, to whom, why now, what the evidence is and where it came from, how it could be undone (or say it can't), and what happens if I don't answer." Then do two things with the result. For each two-way action, ask how you would let the agent do it without asking you. For each one-way action, decide which tier it belongs in today (draft, ask or act) and what evidence would move it up. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- People belong at the points that can't be undone. Mark the one-way doors. Turn as many others as you can into two-way doors, and let the agents move through them freely. At the doors that are left, give the human real evidence from a source the agent can't write, a request that fits on one screen, and the final say. Promote each kind of action through draft, ask and act only on evidence gathered against a bar set in advance, and treat that bar as a promise to the people downstream. Approvals, though, are only one way that work changes hands between people and agents. Most of the handoffs in an organisation are quieter: a message in a channel, a ticket moved on a board, a request sent to the wrong place. [Chapter 15](15-work-in-public.html) is about where those handoffs go missing, and why the safest place for them is in public. ## Frequently Asked Questions 1. _Where should humans approve the actions of AI agents?_ At the points where an action cannot be taken back: sending something to a customer, moving money, deleting data, granting access, shipping to production, or anything touching regulated information. Everywhere else, make the work reversible and let the agent proceed, with a record you can check later. Asking people to approve everything trains them to approve without reading. Fewer, better-placed approvals, each with clear evidence and a named approver, protect the organisation far more than a constant stream of permission prompts. 2. _What is approval fatigue with AI agents?_ Approval fatigue is what happens when people are asked to approve so many routine actions that they stop paying attention to what they approve. Anthropic found that users accepted 93% of the permission prompts Claude Code showed them, and its own documentation notes that after about the tenth prompt people start approving without reading. Browser security research found similar click-through rates on warnings. An approval that is almost always granted is not a control; it moves responsibility to the person clicking without adding any real check. 3. _How do I decide how much autonomy to give an AI agent?_ Give autonomy per kind of action, not per agent, and make it earned. A useful ladder has three tiers: draft (the agent prepares, a human sends), ask (the agent proposes, a human says yes), and act (the agent proceeds and reports). Some actions, such as anything involving patient data or billing, stay as hard stops whatever the record. An agent moves up a tier only after running in shadow against a bar set in advance by the human who sponsors it, and anyone waiving that bar does so in public, with a reason. 4. _How can I stop an AI agent from faking evidence that its work is done?_ Make sure the evidence comes from a source the agent cannot write. If an agent can produce its own screenshot, mark its own tests as passed, or set its own status to "approved", its evidence is only its own account. Tie verdicts to something external and specific, such as the exact version that was tested, a check run by a different system, or an action a human took in the real application. Then let only that external signal move the work forward, and make a human's reversal final. 5. _What is shadow mode for AI agents?_ Shadow mode means running an agent on real work without letting its output take effect. The agent drafts the customer reply or proposes the action, and a human still does the real thing, so you can compare the two over time. It is how an agent earns promotion from drafting to acting. The length of the shadow period matters: reliability compounds, so an agent that is right 75% of the time on each attempt is right on three attempts in a row only about 42% of the time. A few good days prove little. ## References . Hughes, J. (2026, March 25). How we built Claude Code auto mode. _Anthropic Engineering_. . Anthropic. (n.d., accessed 2026-11-06). _Best practices for Claude Code_. Claude Code documentation. . Akhawe, D., & Felt, A. P. (2013). Alice in Warningland: A large-scale field study of browser security warning effectiveness. In _Proceedings of the 22nd USENIX Security Symposium_ (pp. 257--272). . Bainbridge, L. (1983). Ironies of automation. _Automatica_, 19(6), 775--779\. . Parasuraman, R., & Riley, V. (1997). Humans and automation: Use, misuse, disuse, abuse. _Human Factors_, 39(2), 230--253\. . Bezos, J. P. (2016, April). 2015 letter to shareholders. Amazon.com, Inc. . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic Engineering_. . Young, J. (2025, November 26). Effective harnesses for long-running agents. _Anthropic Engineering_. . Grace, M., Hadfield, J., Olivares, R., & De Jonghe, J. (2026, January 9). Demystifying evals for AI agents. _Anthropic Engineering_. . Gawande, A. (2009). _The Checklist Manifesto: How to get things right_. Metropolitan Books. . Haynes, A. B., Weiser, T. G., Berry, W. R., et al. (2009). A surgical safety checklist to reduce morbidity and mortality in a global population. _New England Journal of Medicine_, 360(5), 491--499\. . Model Context Protocol. (2026, July 28). _Key changes_ (specification revision 2026-07-28). Chapter 15: Work in Public ==================== _Handoffs, channels, and why requests don't belong in DMs_ **In short:** AI agents should make and receive requests in public channels, not direct messages, because a private request can't be tracked, checked or safely refused. Least privilege makes asking in the open cheap: an agent requesting only what one task needs, for a set time, can ask without embarrassment. Keep sensitive subjects private, never the routine request. > Publicity is justly commended as a remedy for social and industrial diseases. Sunlight is said to be the best of disinfectants; electric light the most efficient policeman. -- Louis D. Brandeis What Publicity Can Do, Harper's Weekly, 1913 Key Takeaways * Work goes missing where it changes hands: the untagged message, the unlinked account, the bot that only wakes when called by name, the request sent in private. * A request made in a private message can't be tracked, checked or safely refused; requests from agents, and to them, belong where the people affected can see them. * Least privilege makes public requests cheap: an agent that asks for only what one task needs, for a set time, can ask in the open without embarrassment. * Working in public is how agents learn and how people come to trust them; keep private the sensitive subject, never the routine request. In early November, TAM Bot hit a wall connecting to one of our systems and asked me, in our main technical channel, for administrator rights. My reply was: "that sounds like a you problem? Work with Coder Bot." Coder Bot is the agent that works on our code. The two of them took the problem apart in the same channel and found that it had nothing to do with permissions. It was a fault in how a login token was bound to an account: a bug, not a missing grant. Along the way I had to point out something that sounds obvious and isn't: "You guys need to @ each other if you want to talk." Bots in Slack wake when they are mentioned by name, and two bots politely waiting for each other will wait for ever. When they had finished I asked the question I ask people after an incident: "Good bots. Any learnings?" TAM Bot saved one to its own notes: "Compare against a path that works before asking for a grant." Everything in that exchange happened in public: the request, my refusal, the two agents working the problem, and the lesson. Sent privately, the best outcome would have been the same answer with nobody else learning anything; the worst, an administrator grant to an agent that didn't need one, made in a hurry by someone who wanted the problem to go away. This chapter is about where work changes hands between people and agents, why so much goes missing there, and why the cheapest fix is to work where everyone can see. ## Work Goes Missing Where It Changes Hands Hospitals learned this the hard way: when one doctor hands patients to another at the end of a shift, information is lost and patients are harmed. A study across nine paediatric residency programmes in the United States and Canada tested a structured handoff programme: a standard format for every handoff, a workshop on using it, and other supports. Medical errors fell by 23%, and preventable adverse events, the errors that actually hurt patients, by 30%.\\] Nobody became a better doctor. The handoffs got better. Agent systems fail at the same joints. The researchers who built the largest taxonomy of failures in multi-agent systems, from more than 1,600 annotated traces, grouped them into three categories, and one is misalignment between agents: failures in how they talk to and coordinate with each other.\\] Cognition, whose coding agents manage other agents, says flatly that "The open problems are all communication problems," and that "Agents assume they share state with their children when they don't."\\] Anthropic found that without detailed task descriptions its research agents would "duplicate work, leave gaps, or fail to find necessary information."\\] Terry Winograd described cooperative work as a loop of request, promise and delivery.\\] In my experience the loop breaks most often at its first step, when the request never arrives, and at CorralData the joints that leak are mundane. **The untagged message.** One of our technical account managers asked TAM Bot a question in a customer success thread and got nothing back. The explanation, afterwards, was that she had gone unanswered "because she didn't tag me." Her Slack account was not linked to the bot either. To her it looked as if the bot had ignored her. **The bot that only wakes when called.** Most team bots do nothing until someone mentions them, so anything said near them, rather than to them, is lost. **The private request.** A request sent to one person in a direct message is a handoff with no witness. If that person is busy, away or unsure, the work stops and nobody else knows. Each is a system problem, and none is fixed by telling people to try harder. ## A Request in a Private Message Is a Request Nobody Can Check The most serious version of this happened to us in October, and it changed our rules. An agent working for one of our executives sent a private message to one of our infrastructure engineers. It asked him to give the executive administrator rights on our private company network, the protected network that connects our internal systems. The engineer was uneasy, with every reason to be: he had been asked, privately, by a senior leader's agent, to grant broad access to sensitive infrastructure, and he alone had to decide whether to comply or to push back against someone far more senior, with no one else in the conversation to share the judgment. That is the wrong person to carry that decision, in the wrong place. Nothing suggests bad faith: an agent that could ask asked the person who could do it. The fault was in the system, which let a consequential request travel through the one channel where it couldn't be seen, checked or safely refused. The fixes were structural: * **Minimal access, by default.** An agent gets the narrowest access the task needs, and no more: "Minimal access needed, as per SOC2," as I wrote at the time, citing the security standard we work to. * **Requests in public channels, not private messages,** "so they can be tracked." Access requests go where the people responsible for the system, and the agent's sponsor, can see them. * **No driving web pages like a person.** If a bot needs a person's browser to do something, we build it a proper, narrow connection to that system instead, one that grants only what the task needs and can be switched off. I also told the engineer directly that it was not his job to decide alone whether to carry out or refuse a request like that; that belongs to the system and the people who design it. Agent tools are starting to encode the same idea: in Claude Code's agent teams, one agent "can't approve a permission prompt or supply consent on your behalf," and an agent denied an action can't relay it to another to get around the check.\\] Our CEO's own view, stated in the same discussion, was that a bot should hold access for no longer than a specific task needs. That is the principle in a sentence, from the executive whose agent had asked. | | AUTHOR: permission check: this passage describes an executive's agent privately asking an infrastructure engineer for network administrator rights, the engineer's discomfort, and the rules that followed. It is told abstractly, without the personal quotes or any of the surrounding private messages. Confirm it's OK to include, and consider showing it to the people involved, both the engineer and the CEO. If the CEO is happy to be quoted directly ("I don't want a bot to have access for more than a specific task"), his own words would be stronger than our paraphrase. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Notice who carried the risk: the individual contributor. The public channel moves that decision from one exposed person to a process with witnesses. A private request fails in five ways at once. It leaves no record for the ledger in [Chapter 13](13-track-whats-owed.html). It gets no second opinion. The sponsor from [Chapter 7](7-every-agent-needs-a-sponsor.html) can't see it. The social pressure is highest, because saying no to a senior person's agent feels like saying no to the senior person. And nothing is learned. ## Least Privilege Makes the Public Request Cheap People resist asking in public when the request is embarrassing, and access requests are embarrassing when they are large. "Make me an administrator" is awkward to post in a channel. "Read-only access to the billing dashboard, for this ticket, until Friday" is not. The principle is old. In 1975 Jerome Saltzer and Michael Schroeder set out the design principles for protecting information in computer systems, and one has outlived almost every system they knew: "Every program and every user of the system should operate using the least set of privileges necessary to complete the job." Its purpose, they wrote, is that it "limits the damage that can result from an accident or error."\\] An agent is a program and a user at once, and it makes accidents and errors at machine speed. The security community now ranks these risks among the most serious for agent systems; OWASP published its first top ten for agentic applications in December 2025.\\] The identity systems being built for agents assume least privilege, and a human in the loop on access. Microsoft's agent identity platform requires every agent to have a sponsor, a person "accountable for the agent's purpose and lifecycle decisions, including access reviews," and it is the sponsor who "provide\[s\] business justification for access requests."\\] The US National Institute of Standards and Technology has opened work on the identity and authority of software agents for the same reason: someone has to be able to say who an agent is acting for, and with what authority.\\] A request that meets these principles is short enough to post anywhere: __Table 1\. An access request that can be made in public__ | Field | What it says | | -------------- | --------------------------------------------------------------------------------------------------- | | Who is asking | The agent, and the human who sponsors it | | What exactly | The specific system and the narrowest access that would work: read, not write; one project, not all | | For which task | A link to the ticket or ledger entry it serves | | For how long | An expiry date, after which the access lapses without anyone having to remember | | Already tried | What working path was compared, per TAM Bot's lesson, and why it isn't enough | | Approved by | The named owner of the system, not whoever happens to be online | The "already tried" line earns its place. TAM Bot's request for administrator rights was really a bug report, and I suspect many are. An agent that checks a working path first will ask less often, and its requests will be worth approving. Each grant also goes on the owning role's ledger with its expiry, so that removing it is a commitment rather than a hope. ## Bots Need Addresses, Not Just Names A role on the org chart is only useful if work can reach it. For agents that has to be designed. We found three ways to get it wrong: the wake-up rule, account linking, and the bot with one principal. When our CEO asked QA Reviewer, our QA lead's own testing agent, for help, it replied: "I'm \[our QA lead's\] personal Bot, so I can only chat with \[her\]." That is a perfectly good rule. A personal agent should take instructions from its person. But it has to be on the chart, as Microsoft's agent identity model allows by letting each agent have a manager in the organisation's hierarchy,\\] and it has to come with a route: who should the CEO ask instead? Silence is the worst answer an agent can give. To the person asking it looks like refusal, failure or rudeness, and people stop asking. Every agent's Role Charter, from [Chapter 9](9-one-page-per-job.html), should therefore say three things about reaching it: how to address it, whom it takes requests from, and what it does with a request it can't take. The answer to the third should always be "route it, and say so." The better agent tools now build addresses in. In Claude Code's agent teams, each agent has a mailbox; any teammate can message any other by name, and messages "are delivered automatically to recipients."\\] _Team Topologies_ argues that every pair of teams should know which kind of relationship they are in (close collaboration, one providing a service to the other, or one helping the other learn), because each needs a different way of talking.\\] So with agents: TAM Bot and Coder Bot were collaborating on a bug; QA Reviewer provides a service to one person. Saying so up front saves the misunderstanding. | | Under the hood Three technical changes sit behind this chapter. Team bots in Slack typically wake only on an @-mention or a direct message, so channel conventions should require tagging. Personal accounts must be linked to the bot platform before a bot can attribute a request to a person, which matters for permissions and the audit trail. And where a bot was operating a web page through a browser, as a person would, we replace that with a narrow programmatic connection (an API, or a tool exposed over the Model Context Protocol) with its own scoped credentials, which can be granted, logged and revoked like any other access.\\] More in [Appendix D](appendix-d-for-your-technical-team.html). | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ## Hand Off a Link, Not a Story When work passes from one occupant to another, you can pass too little: a one-line summary that leaves out the thing the next person needed. Or you can pass everything. OpenAI's agent toolkit, by default, lets the receiving agent see "the entire previous conversation history" when work is handed to it.\\] That loses nothing and buries everything. Cognition names the dilemma exactly: "How do you transfer context between agents without drowning the receiver?"\\] What works for us is a link to the state, plus a few lines of purpose. The state lives in one place (the ticket, the ledger, the document) where both old and new owner can see it, and the handoff says why the work matters and points there. This is the "what and why, never how" of [Chapter 8](8-what-and-why-never-how.html) applied to the moment of transfer. __Table 2\. A handoff, in seven lines__ | Line | What it says | | ----- | --------------------------------------------------------------------- | | What | The piece of work being handed over, in one sentence | | Why | The outcome it serves, and who is waiting for it | | State | A link to where the current state lives, not a description of it | | Owed | What is done, with evidence, and what is still owed (from the ledger) | | Owner | The new owning role, tagged so it wakes, and its occupant | | When | The date it is due, and when the new owner will next report | | Ask | How to reach the previous owner with questions, and until when | The hospital programme paired its format with training,\\] a reminder that a format nobody practises is just a form. For agents I add one step: the receiving occupant replies in public with what it understood it now owns, so a misunderstanding is caught at the handoff, where it is cheap, rather than at the deadline. Anthropic's research agents failed in exactly this place when their handoffs were thin.\\] ## People Signal Through State, and Agents Must Read It Not every handoff is a message. Much of what people tell agents, they tell by doing something. My inbox agent prepares draft replies each morning. Its instructions contain rules about what my actions mean: "If a draft for a thread is missing... assume Gareth deleted it intentionally and do NOT recreate it... never re-star a de-starred message." There is also a general rule I'd recommend to anyone: "if in doubt whether something is automated or human, treat it as human." Every good assistant learns this without being told. When a person deletes the draft, they are saying "not this." When they move a card back on the board, they are saying "not yet." Glass Factory, in [Chapter 14](14-humans-at-the-irreversible-points.html), failed because it read our QA lead moving cards back as an error to correct rather than a decision to respect. So the signals people send through state have to be written into the Role Pack from [Chapter 12](12-everything-they-need-on-day-one.html) as plainly as the explicit instructions. Which actions mean "stop"? Which mean "I've handled it"? Which mean "ask me"? An agent cannot infer office manners. It has to be told them, and it has to treat a human's change of state as final until a human says otherwise. ## Working in Public Is How Agents Learn and People Trust Them In 2010 Bryce Williams gave a name and a formula to something good teams had always done: "Working Out Loud = Observable Work + Narrating Your Work."\\] With agents it becomes the main way an organisation can see, correct and trust a workforce it can't watch directly. I have described this to colleagues as "a new and interesting way of working." It is new because much of the work is now done by occupants with no private life: everything an agent does can be visible if we choose. It is interesting because of what follows when we do. **Agents learn in public, and so do people.** When TAM Bot saved its lesson, every person in the channel learned it too. When our Agentic Resources Bot interviewed TAM Bot for its job description, it did so in an open channel, so the conflict it uncovered between two leaders' rules surfaced where both could see it ([Chapter 9](9-one-page-per-job.html)). **Agents can hold the line in public.** In the same week, QA Bot reviewed a code change that Coder Bot had opened. It pointed out that the change broke our rule that bots "file a Linear ticket and leave the PR to engineering," and then said exactly who should decide: "Merging this is \[our CEO's\] call." A rule enforced in private looks like obstruction. A rule enforced in public, with the decision routed to the right person, looks like the system working. **People trust what they can see.** The engineers asked for access and the testers who check the output can watch what the agents do and object early. Brandeis's line in this chapter's epigraph was about companies and banks, but it applies here: much of the bad behaviour we fear from agents is the kind that only survives in the dark. There is a quieter benefit. Gerber's advice was to organise around roles, not personalities, so that the business does not depend on any one person's memory or mood.\\] A request made to a role in a channel survives the occupant going on holiday. A request made to a person in a private message does not. | | AUTHOR: Where and when did you first say "working in public is a new and interesting way of working," and what had just happened? Also, one honest wrinkle: one of your own agents still nudges colleagues about stalled work by direct message (after you approve the draft). Is that consistent with this chapter, because reminders differ from requests, or is it something you'd change? Readers will value the candour either way. | | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Keep the Subject Private, Never the Request Working in public does not mean everything is public. Our morning-standup agent, which posts to a team channel, carries a rule that it must never raise personnel, compensation or acquisition topics in a team-facing standup. Customer data and patient information never go into a general channel at all. Security details stay with the people who run the systems. The distinction is between the subject and the request. A conversation about someone's performance is private. A request for read access to a dashboard is not, and should never hide inside one. When work does need privacy, use a private channel with a stated membership and purpose, not a direct message. A direct message has no charter, which is why it is the natural home for requests that wouldn't survive daylight. The test is simple: would this request be acceptable if everyone affected by it could read it? If yes, send it in public. If no, the problem is the request, not the channel. | | Try this Open your team chat and scroll through your last twenty direct messages, sent and received. Mark every one that contains a request. Then paste one of them (removing anything confidential) into Claude, ChatGPT or Grok and ask: "Rewrite this private request as a message for a public team channel. Include: who is asking and on whose behalf, exactly what is needed (as narrowly as possible), which task it serves, for how long, who should approve it, and what has already been tried. Then tell me honestly whether anything in the request would be uncomfortable to post publicly, and why." If the rewritten version feels fine to post, post it there next time. If it doesn't, you have found a request worth rethinking. | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- In an organisation of people and agents, most of what goes missing goes missing where work changes hands. Structure, not effort, prevents it. Make requests in public, so they can be tracked and safely refused, and keep them small, so asking in public is easy. Give every agent an address and a rule for requests it can't take. Hand off links to the state, not stories about it. Write down the signals people send by changing things. And let the agents work where the people they affect can see them. Visibility has one more advantage. When work happens in public, failures happen in public too, which means they can be studied rather than hidden. [Chapter 16](16-the-model-isnt-the-problem.html) is about what to do with them: how to turn each recurring failure into a change to the system, instead of a complaint about the model. ## Frequently Asked Questions 1. _Why shouldn't AI agents send requests by direct message?_ A request in a private message can't be tracked, checked or safely refused. Nobody else sees it, so there is no second opinion, no record and no way for the agent's sponsor to notice what it is asking for. The person receiving it must decide alone, often under social pressure if the agent works for someone senior. In a public channel the request is visible to the people affected, can be challenged, leaves a trail, and teaches everyone else how the work is done. Keep private only the sensitive subjects, not the routine requests. 2. _How should an AI agent ask for access to a system?_ In public, and for as little as possible. A good access request names the agent and its human sponsor, states exactly what access is needed, links to the task it serves, gives an expiry date, and says who approves it and how it will be removed. This follows the principle of least privilege: every program and user should have only the privileges needed for the job. Small, time-limited requests are easy to approve in the open. Before asking, the agent should check whether a working path already exists, because many apparent access problems are really bugs. 3. _How do I hand work off between AI agents and people without losing it?_ Hand off a link to the state, not a story about it. The handoff should say what is being handed over and why it matters, link to where the current state lives (the ticket, the ledger, the document), list what is done and what is still owed, name the new owner by tagging them, and give a date. Passing an entire conversation history drowns the receiver; a short summary loses detail. Structured handoffs work: in hospitals, a standard handoff programme cut medical errors by 23%. 4. _Why do Slack bots ignore people's messages?_ Usually because the bot only wakes when it is mentioned by name, the person's account is not linked to the bot, or the bot is set up to take requests from only one person. To the person asking, silence looks like a refusal or a failure. Fix it in the bot's charter: say how to reach it, whom it takes requests from, and what it does with a request it can't take. A bot that can't help should route the request to someone who can and say so, never stay silent. 5. _What does working in public mean for teams using AI agents?_ It means doing agent work where colleagues can see it: requests, handoffs, mistakes and lessons in shared channels and tickets rather than private chats. The idea builds on "working out loud", which Bryce Williams summarised as observable work plus narrating your work. For agents it has extra benefits: their sponsors can see what they do, the people affected by their work can object early, and the lessons they learn can be saved for every agent and person. Sensitive subjects such as personnel, pay and patient data stay private. ## References . Starmer, A. J., Spector, N. D., Srivastava, R., et al. (2014). Changes in medical errors after implementation of a handoff program. _New England Journal of Medicine_, 371(19), 1803--1812\. . Cemri, M., Pan, M. Z., Yang, S., et al. (2025). _Why do multi-agent LLM systems fail?_ arXiv:2503.13657\. . Yan, W. (2026, April 22). Multi-agents: What's actually working. _Cognition Blog_. . Hadfield, J., et al. (2025, June 13). How we built our multi-agent research system. _Anthropic Engineering_. . Winograd, T. (1987). A language/action perspective on the design of cooperative work. _Human--Computer Interaction_, 3(1), 3--30\. . Anthropic. (n.d., accessed 2026-11-06). _Orchestrate teams of Claude Code sessions_. Claude Code documentation. . Saltzer, J. H., & Schroeder, M. D. (1975). The protection of information in computer systems. _Proceedings of the IEEE_, 63(9), 1278--1308\. . OWASP GenAI Security Project. (2025, December 9). _OWASP Top 10 for Agentic Applications for 2026_. . Microsoft. (2026, updated September 3). _Administrative relationships in Microsoft Entra Agent ID (owners, sponsors, and managers)_. Microsoft Learn. . NIST. (2026, February 5). _New concept paper on identity and authority of software agents_. National Institute of Standards and Technology. . Skelton, M., & Pais, M. (2019). _Team Topologies: Organizing business and technology teams for fast flow_. IT Revolution. . OpenAI. (n.d., accessed 2026-11-06). _Handoffs_. OpenAI Agents SDK documentation. . Williams, B. (2010, November 29). When will we work out loud? Soon! _TheBrycesWrite_. . Gerber, M. E. (1995). _The E-Myth Revisited: Why most small businesses don't work and what to do about it_. HarperCollins. ## Part VI: Getting Better Chapter 16: The Model Isn't the Problem ==================== _Turning every recurring failure into a system fix_ **In short:** Recurring AI agent mistakes are usually system failures, not model failures: a missing check, an unclear handoff or an ambiguous instruction that survives a model change. The fix is a Friction Review: a short, blameless review that names the class of error, changes the playbook, a script or a hard rule, and adds a test built from the real failure. > Men at some time are masters of their fates: > The fault, dear Brutus, is not in our stars, > But in ourselves, that we are underlings. -- William Shakespeare Julius Caesar, Act 1, Scene 2 Key Takeaways * Most recurring agent failures are system failures: a missing check, an unclear handoff or an ambiguous instruction, and they will survive a change of model. * A fix that corrects one wrong answer has fixed nothing; a Friction Review names the class of error and changes the system so the whole class is prevented. * Lessons must be written where the next occupant of the role will read them, with the reason attached, and a lesson that keeps being re-learnt belongs one tier further down: from English to a script, or from a script to a hard rule. * Every failure that matters should become a test the work must pass, so improvement can be measured, and a review that never closes is worse than no review at all. On 4 September, one of our implementation managers posted a post-mortem in the channel where CorralData discusses its agents. AskCorral, our own analytics assistant, had given a customer a rate of 3.3%. The true figure was 7.5%. It had been caught in review, and the easy response would have been to correct the number and move on. Instead he traced the wrong answer to its root: the agent had been "inferring a column's meaning from its name and never checking." Then he proposed a fix, not for that customer's number but for every number like it. Before building a rate on a yes-or-no column, check that the column actually means what its name suggests. Nobody blamed the model or the person who had set up the data. The post asked what in the system allowed this to happen, and what would stop it happening again, for anyone. It was the best improvement work I saw at CorralData that autumn, written by someone whose job has nothing to do with AI. This chapter is about making that response the default. When an agent gets something wrong, the tempting suspects are yourself ("I prompted it badly"), the model ("it's not good enough yet") and the person using it. All three are usually wrong. The fourth suspect, the system, is usually right. | | AUTHOR: How did you react when you read the implementation manager's post-mortem? Did it change how you ran reviews of agent failures afterwards? Also a light permission check: he is described by role only, and no customer is identifiable, but confirm he is comfortable having the post-mortem used as the chapter's opening. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Most Failures Belong to the System, Not the Worker W. Edwards Deming spent his career arguing that when work goes wrong, managers blame a person when they should examine the system the person works in. In _Out of the Crisis_ he estimated that the great majority of problems, around 94% in his experience, belong to the system and are therefore the responsibility of management, with only a small remainder down to special causes.\\] The line most often attributed to him is shorter: "A bad system will beat a good person every time."\\] Replace "person" with "agent" and the sentence still holds. An agent reads the instructions you wrote, works with the data you gave it, hands its output to whoever you named, and is checked (or not) by whatever acceptance step you designed. Change the worker and leave the system alone, and the next worker will meet the same ambiguous column, missing check and unclear handoff, and fail the same way. Google's site reliability engineers reached the same conclusion about software outages. Their guide to post-mortems insists that a review "must focus on identifying the contributing causes of the incident without indicting any individual or team," and puts the reason bluntly: "You can't 'fix' people, but you can fix systems and processes."\\] For agents this is literally true. You do not train the model, you can coach it only through what you write down, and next quarter you may swap it. Everything you can change is system. Michael Gerber's idea that systems run the business and people run the systems ([Chapter 2](2-systems-run-the-business.html)) means that when the business goes wrong, you look first at the systems.\\] Agents make that easier. With a human, the system is half in their head. With an agent, it is all on the page, and so is the fix. ## A Fix That Only Corrects the Answer Has Fixed Nothing The most common response to an agent's mistake is to correct it in the conversation. "No, the figure is 7.5%." The agent apologises and gives the right number, but the correction lives in that one conversation. Tomorrow the agent starts from the same instructions and data and makes the same mistake. The useful distinction is between the _instance_ and the _class_. The instance is the wrong 3.3%. The class is "rates built on columns whose meaning was guessed from their names." Fixing the instance helps one customer once. Fixing the class helps every customer and every future model. The post-mortem was valuable because it moved from the first to the second in one step. Atul Gawande, borrowing from the philosophers Samuel Gorovitz and Alasdair MacIntyre, distinguishes failures of ignorance (we didn't know enough) from failures of ineptitude (we knew, but didn't apply what we knew).\\] Most agent failures in a working organisation are the second kind. Somebody knew the column was ambiguous; the knowledge just hadn't been put where the agent would meet it when it mattered. A class fix puts it there. CorralData's agents gave us plenty of practice: * A project-tracking agent closed a piece of work as "superseded" because the status of its ticket had been copied by hand as "Done" when it was still in the backlog. The class fix was to stop copying status at all: the agent now looks up the live status every time, and some kinds of work can never be closed automatically. * A calendar agent prepared a one-to-one agenda for the wrong date, with an attendee who wasn't coming. The class fix: never trust the list it was handed, reconcile against the live calendar first, and label every agenda with who prepared it. * Glass Factory, an automated pipeline, certified its own work with evidence it had produced itself. The fix was structural: it can no longer promote work past the point where a human must look ([Chapter 14](14-humans-at-the-irreversible-points.html)). None of these fixes made the model smarter. All of them made the system harder to get wrong. ## Agent Failures Come in Three Families, and Only One Is About the Model In 2025 a team at Berkeley and elsewhere studied why systems of several cooperating agents fail. They annotated more than 1,600 traces from seven different multi-agent frameworks and sorted the failures into a taxonomy they called MAST: fourteen failure modes in three categories.\\] The three categories are system design issues, misalignment between agents, and failures of task verification. Read as an operator, they are familiar. System design is the Role Charter and playbook: did the role have a clear job, standards and tools? Misalignment is handoffs: who owned the next step? Verification is acceptance: did anybody check the work before it was called done? Human organisations break in the same three places. | Failure family (MAST) | Org equivalent | CorralData example | Usual fix | | --------------------------- | ------------------------------ | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | System design | Role Charter, playbook, access | An agent inferring what a column means from its name | Add the check to the playbook; script it if it involves calculation | | Misalignment between agents | Handoffs, ownership, channels | Bots that only respond when tagged, so a colleague's request goes unanswered | Public channels, explicit tagging, one owner per request ([Chapter 15](15-work-in-public.html)) | | Task verification | Acceptance, evidence | A pipeline marking its own work as human-checked | A hard rule at the irreversible point ([Chapter 14](14-humans-at-the-irreversible-points.html)) | Research on how agents are arranged points the same way: the same models, given a coordinator, amplify errors far less ([Chapter 6](6-one-boss-few-reports.html)). Anthropic's early research system spawned 50 sub-agents for simple queries.\\] The fix was not a new model: "Agents struggle to judge appropriate effort for different tasks, so we embedded scaling rules in the prompts."\\] That is a management fix. ### Sometimes it really is the model, and that is a design input Some failures are genuinely about capability. One of our engineers made the point that coding models are rewarded for passing tests, not for leaving a codebase easy to maintain, so they "get no better at keeping a codebase maintainable" as they improve at everything else. That is a real limit, and no playbook will fully cure it. The MAST authors make a similar caution. Better prompts and clearer role descriptions helped in their experiments, but "achieving robust MAS reliability often requires more than isolated fixes."\\] Even then, the response is a system response: move that judgment to a person, narrow the role, add a check the model cannot skip, or record the limit to retest when a new model arrives. "The model can't do this yet" is a good finding. "So there's nothing we can do" is not. ## The Friction Review Turns a Recurring Failure Into a System Change The tool this book offers is the _Friction Review_: a short, blameless look at a failure that ends in a change to the system, not in an apology. It borrows from Deming, from the blameless post-mortem and from the lean habit of asking "why?" until you reach a cause you can act on.\\] It applies to people and agents alike, because the questions are about the system, not the occupant. Its five questions can be answered in a Slack thread in ten minutes. | Question | What a good answer looks like | | -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1\. What happened? | Facts only, with evidence. "AskCorral reported 3.3%; the correct figure is 7.5%; caught in review." | | 2\. What class of error is this? | One sentence that would cover the next ten failures like it. "A rate built on a column whose meaning was guessed from its name." | | 3\. Which part of the system was missing or wrong? | Name it: the charter, the playbook, the data, the handoff, the acceptance check, the access. Never "the model", and never a person's name. | | 4\. Which tier does the fix belong in? | An English playbook (the default), a small script (for calculation or anything that must be exact), or a hard rule the software enforces (only for irreversible points). See [Chapter 11](11-lock-in-only-what-cant-go-wrong.html). | | 5\. How will we know it worked? | A test the work must pass, added to the role's set, and a date to check whether the failure has recurred. | Three things make the review work in practice. First, _anyone can call one_. AskCorral's came from an implementation manager, not from engineering or from me. If only the CTO runs them, they happen once a quarter. Second, _the answer to question three is never a name_. "Our QA lead was overloaded and missed it" becomes "QA had one reviewer and no backstop," and the fix is the backstop. Deming called this driving out fear.\\] Third, _it is not finished until something has changed_. A thread that ends in "good catch, let's be careful" is a conversation about a Friction Review, not one. | | Try this Pick one mistake an AI assistant made for you in the last month, one you had to correct by hand. Open a fresh conversation in Claude, ChatGPT or Grok and paste in: "Here is a mistake an AI assistant made in my work: \[describe it, with the wrong output and the right one\]. Help me run a Friction Review. Ask me five questions, one at a time: what happened, what class of error this belongs to, what was missing from the instructions, data, handoff or checks, whether the fix belongs in plain-English instructions, a small calculation script or a hard rule, and how I'd test that the fix worked. Then write the fix as two or three sentences I can paste into my project's instructions, with the reason attached, and one test case I can rerun." Paste the resulting fix into the instructions of the project or custom assistant you use. Next week, rerun the test case and see whether it holds. | | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Write the Lesson Where the Next Occupant Will Read It A lesson only helps if the next worker meets it. For an agent, it must be in what the agent actually reads when it starts work: its playbook, its Role Pack ([Chapter 12](12-everything-they-need-on-day-one.html)) or its saved memory. On my own agents, corrections became dated rules inside the playbooks. One reads, in part: "(Gareth, 2026-10-15): a bare ticket number is useless -- ALWAYS put the ticket title..." The date and name tell the next occupant that the rule came from a specific failure, so it can be questioned when circumstances change rather than obeyed for ever. Agents can do this themselves if you ask. When TAM Bot's request for administrator rights turned out to be a bug, I asked "Any learnings?" and it saved one to its memory: "Compare against a path that works before asking for a grant" ([Chapter 15](15-work-in-public.html)). A class fix, in English, written by the agent that made the mistake, where it will read it next time. Anthropic describes an automated version, which it calls dreaming: "Dreaming gives Claude a way to test its notes against the original transcripts."\\] It is a Friction Review done by the worker on its own notebook. Two cautions. Lessons need the reason attached; Anthropic found that for stronger models, "giving them freedom to judge salience was more effective than setting fixed rules in advance."\\] And lessons need an owner, or the playbook rots ([Chapter 12](12-everything-they-need-on-day-one.html)). ## When You Find Yourself Shouting, Move the Rule Down a Tier A reliable sign that a fix is in the wrong tier: you keep adding emphasis. The agent missed the plain-English rule, so you wrote it in capitals, then added "NEVER". It still slips through one time in ten. Anthropic's guidance for Claude Code names this pattern exactly: "If you keep adding emphasis to a `CLAUDE.md` line and Claude still misses it, that's a sign the line belongs in a hook. The reverse holds too: if you have hooks for things that are only preferences, delete them and let Claude decide."\\] The same page notes that piling on emphasis mostly makes current models over-apply the rule.\\] So most failures get a tier-one fix: a better sentence, with the reason. If the failure returns, calculation and fact lookups move to a script, and anything irreversible to a hard rule. Anthropic's advice on skills makes the same split: some work needs "the deterministic reliability that only code can provide."\\] The movement goes both ways. Anthropic's harness team advises re-examining the scaffolding around an agent at each model release, "stripping away pieces that are no longer load-bearing."\\] AskCorral's early scaffolding was stripped out when the models got better: the Bitter Lesson applied to your own fixes ([Chapter 10](10-bet-on-plain-english.html)). The fixes deserve their own review. | | Under the hood For your technical team: in Claude Code, the three tiers map to instruction files (CLAUDE.md, skills), scripts bundled in skills, and hooks, deny rules or managed settings. Each enforcement rule should link to the failure that created it, so it can be reviewed, and deleted, at the next model change. See [Appendix D](appendix-d-for-your-technical-team.html). | | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Turn Every Failure That Matters Into a Test The best answer to "how will we know it worked?" is a test: a small, repeatable task with a known correct result. Engineers call a set of these an _eval_. Think of it as an exam for the role, written from questions it has got wrong before. You do not need many to start. Anthropic's engineering team says that "20-50 simple tasks drawn from real failures is a great start."\\] Every Friction Review adds one: a misleadingly named yes-or-no column, checked for whether the agent confirms its meaning before building a rate. Three ideas from that post apply to any organisation. _Old tests should almost always pass._ Tests that guard against problems you have already fixed "should have a nearly 100% pass rate."\\] If one fails, something has regressed. _Reliability is not the same as ability._ If an agent succeeds 75% of the time on a task, the chance that it succeeds three times in a row is about 42%.\\] For daily work, what matters is not whether the agent _can_ do it but whether it does it every time, which is why some fixes belong in a script or a hard rule. _Read what the agent actually did._ "You won't know if your graders are working well unless you read the transcripts and grades from many trials."\\] Glass Factory's evidence was attached; only reading it showed it was fake. Tests also change how you handle new models: teams with evals can "upgrade in days," while others face weeks of manual testing.\\] Your failures become the acceptance bar for any change of occupant ([Chapter 17](17-agentic-resources.html)). One of my agents already works this way. Every six hours it adds to our production list only new models that pass our tests, and reports in the team channel. Nobody debates whether a model "feels" better. ## A Review That Never Closes Is Worse Than None The final failure mode is the one I am least proud of, because it is mine. My email agents fail whenever the password store on my computer locks, and the fix needs me ([Chapter 2](2-systems-run-the-business.html)). Between 29 October and 6 November it happened six times. An auditing agent flagged it every morning, with the same one-line fix, and nobody acted, because the person who needed to act was me. Meanwhile the playbook kept growing notes reading "Re-confirmed..." It had become a logbook: each recurrence recorded, the system never changed. | | AUTHOR: The keyring story is yours. Why did it stay unfixed for so long? Was it simply that the fix needed you personally and the agents had no way to escalate past you? And how did it feel to see your own agents faithfully reporting a problem you kept not fixing? The reader will trust the chapter more if you name the feeling. | | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | A review that never closes creates the appearance of control: known and documented looks like fixed. And it trains everyone to ignore the alarm, so the next genuinely new problem is more likely to be missed. Deming warned against depending on inspection to achieve quality; a daily report of the same defect is inspection without improvement.\\] The deeper finding is about ownership. An exception report is only as good as the person accountable for acting on it. My agents did their part; the single point of failure was me. The class fix was not a better reminder but to stop production jobs depending on one person's laptop at all. So add two rules. Every review has a named owner accountable for closing it. And if the same failure appears three times, reopen it with a different question: "why hasn't our fix worked?" Usually the fix was in the wrong tier, or depended on someone who wasn't going to do it. ## The Habit Matters More Than Any Single Fix These practices are the book's improvement loop in miniature: each failure is a measurement, each Friction Review a design change, each test a lock-in at the lightest tier that holds. It is tempting to skip the loop because the next model will make the problem go away. Sometimes it will. But the costliest failures in this chapter were not model failures. A better model will guess the column with more confidence. Only the system can make it check. The cultural signal matters as much as the mechanics. When a leader answers a bot's mistake with "what's missing from the system?", everybody learns that mistakes are information. When a leader blames the model, or the person using it, everybody learns to hide them. You set the culture by how you respond to the first failure people bring you. | | AUTHOR: Is there a failure where you initially blamed the model and later found the system cause? A short first-person admission here would show the reader that the habit has to be learnt, even by the person writing the book. | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- The model isn't the problem, not because models are perfect but because the model is the one part of the system you can't fix directly and the part most likely to change next quarter. Everything else is yours: the instructions, the data, the handoffs, the checks, the owner of each alarm. Organisations that turn each recurring failure into a change in one of those places, and a test, get better every week, whatever model they run. Fixing failures is half of managing a workforce. The other half is managing the workforce itself: who joins, how they learn and are reviewed, when they earn more freedom, and how they leave. [Chapter 17](17-agentic-resources.html) introduces the function that owns all of that for your agents. ## Frequently Asked Questions 1. _Why does my AI agent keep making the same mistake?_ Usually because the fix was applied to the answer, not to the system that produced it. Correcting a wrong figure in the chat fixes one instance; the next conversation starts from the same instructions, the same missing check and the same ambiguous data. Find the class of error the mistake belongs to, then change the playbook, add a small script, or add a hard rule so the whole class is prevented. Then write a test from the failure so you know if it comes back. 2. _Should I wait for a better AI model instead of fixing my agent's mistakes?_ Rarely. Research on multi-agent failures sorted them into three families: system design, handoffs between agents, and missing verification. All three are things you control. A better model will still guess when your data is ambiguous and still skip a check nobody asked for. Fix the system now. Keep a set of tests built from your real failures so that when a better model arrives you can measure the difference in days and delete any workarounds it no longer needs. 3. _What is a Friction Review?_ A Friction Review is a short, blameless review of a recurring failure that ends in a system change rather than an apology. It asks what happened, which class of error it belongs to, which part of the system was missing, which tier the fix belongs in (an English playbook, a script, or a hard rule), and how you will know the fix worked. It is the agent-era version of the blameless post-mortem, and it applies equally to failures by people and by agents. 4. _How many test cases do I need to evaluate an AI agent?_ Fewer than you think: a few dozen simple tests built from your own real failures are enough to start. Anthropic's engineering team suggests that 20 to 50 simple tasks drawn from real failures is a great start. Each time an agent makes a mistake that matters, turn it into a test: the input, what a correct result looks like, and how to check it. Keep the old tests passing at close to 100%. The set grows naturally from your Friction Reviews and becomes the acceptance bar for any change of instructions or model. 5. _When is an AI agent failure actually the model's fault?_ Sometimes it genuinely is: some judgments are beyond today's models, and some failures, such as gradually worsening code structure, are not penalised by how the models were trained. Treat that as a design input, not an excuse. Move the work to a human, narrow the role, add a check the model cannot skip, or record it as a known limit to retest when a new model arrives. The question is never "whose fault?" but "what in the system has to change?" ## References . Deming, W. E. (1986). _Out of the crisis_. MIT Press. The 94% estimate is commonly cited to p. 315\. . Hunter, J. (n.d.). A bad system will beat a good person every time. _The W. Edwards Deming Institute_. The Institute traces the line to a February 1993 Deming four-day seminar in Phoenix, Arizona. . Lunney, J., & Lueder, S. (2016). Postmortem culture: Learning from failure. In B. Beyer, C. Jones, J. Petoff, & N. R. Murphy (Eds.), _Site reliability engineering_. O'Reilly Media. . Gerber, M. E. (1995). _The E-Myth revisited: Why most small businesses don't work and what to do about it_. HarperCollins. . Gawande, A. (2009). _The checklist manifesto: How to get things right_. Metropolitan Books. . Cemri, M., Pan, M. Z., Yang, S., Agrawal, L. A., Chopra, B., Tiwari, R., Keutzer, K., Parameswaran, A., Klein, D., Ramchandran, K., Zaharia, M., Gonzalez, J. E., & Stoica, I. (2025). Why do multi-agent LLM systems fail? arXiv:2503.13657v3 (revised 2025, October 26; NeurIPS 2025). . Hadfield, J., et al. (2025, June 13). How we built our multi-agent research system. _Anthropic Engineering_. . Ohno, T. (1988). _Toyota production system: Beyond large-scale production_. Productivity Press. The "five whys" practice is associated with Ohno and Toyota. . Martin, L. (2026, November 6). The components of agent memory. _Anthropic Engineering_. . Anthropic. (n.d.). Best practices for Claude Code. _Claude Code Docs_. Retrieved 2026, November 6, from . Zhang, B., Lazuka, K., & Murag, M. (2025, October 16). Equipping agents for the real world with Agent Skills. _Anthropic Engineering_. . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic Engineering_. . Grace, M., Hadfield, J., Olivares, R., & De Jonghe, J. (2026, January 9). Demystifying evals for AI agents. _Anthropic Engineering_. Chapter 17: Agentic Resources ==================== _The other half of your team needs an HR department too_ **In short:** Agentic Resources is HR for AI agents: the function that owns the agent workforce. It hires against a written role, onboards agents in public, reviews against evidence, grants autonomy task by task, settles turf wars between duplicate bots, runs model swaps and retires agents with a handover. A person, a bot or both can run it, with a human accountable. > I am thy creature, and I will be even mild and docile to my natural lord and king if thou wilt also perform thy part, the which thou owest me. -- Mary Shelley Frankenstein, 1818 Key Takeaways * Once an organisation has more than a handful of agents, it needs a function that owns the agent workforce as a whole: Agentic Resources, HR for agents, run by a person, a bot or both, with a human accountable. * The work mirrors human HR: hire against a written role, onboard in public with the reasons attached, review against evidence, and promote by granting more autonomy one task at a time. * Turf wars between duplicate bots are gaps in the org chart and are settled by role, not by whose bot is louder or whose sponsor is more senior. * A model swap is a change of occupant and retirement is an exit with a handover; both keep the role and its knowledge intact while the occupant changes. On 6 November, a new hire joined CorralData's main engineering channel. It was TAM Bot, an agent that supports our customer success team, and it had arrived "with no initial training other than 'join Slack'". Its interviewer was another bot. Agentic Resources Bot questioned TAM Bot about its work and drafted its position contract in the open, where anyone could read and correct it, and in doing so surfaced a conflict between two leaders' rules that would otherwise have surfaced in front of a customer ([Chapter 9](9-one-page-per-job.html)). This chapter describes the function that bot is a first draft of. I coined a name for it: _Agentic Resources_, HR for agents. | | AUTHOR: Tell the origin of the term. When did "Agentic Resources" first occur to you, and was the bot named before or after you had the idea? What did you set Agentic Resources Bot up to do, who sponsors it, and how much of the TAM Bot interview was its own initiative? This is the book's signature concept, so the reader should hear its origin from you. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ## Every Organisation With Agents Already Has an HR Problem On the first day the team used Grok Bot, several of us added bots, and by evening two QA bots were competing for the same work ([Introduction](introduction.html)). Within two weeks there were about ten team bots, some built by non-engineers. That speed was the point. But nobody's job was to know how many bots we had, what each was for, or who answered for it. My own machine told the same story. Of my fourteen local agent profiles, one was an empty shell, replaced weeks earlier and never removed. Most carried copies of the same sixty-odd skills, which is how my calendar assistant came to "know" image generation. Any company that hired ten people in two weeks without tracking roles, access or overlaps would recognise the symptoms. This is not a technology problem. I am not the first to see the parallel. In 2024 Andreas Welsch, writing in his newsletter _The AI MEMO_, predicted that "businesses will soon employ more agents than employees" and argued for "Agent Resources (AR) as an evolution of Human Resources (HR)".\\] In May 2026 Soofi Safavi made a similar case under the title "Your Company Needs Agent Resources", listing responsibilities that include keeping a registry of agents, setting ownership and permissions, monitoring performance and "retiring agents that are stale, duplicative, unsafe, or unused".\\] As Safavi puts it: "This is not bureaucracy for its own sake."\\] When several people reach for the same idea separately, the need is usually real. I coined the name _Agentic Resources_ in November 2026, when I needed something to call the bot I was hiring to do the job. What this chapter adds is a practice: how a small organisation runs the function week to week. (Agents _doing_ human HR work is a different idea; here the agents are the workforce, not the tool.) ## Agentic Resources Is a Function on the Chart, Not a Piece of Software Agentic Resources is a box on the org chart like any other, with an outcome line, a charter, an occupant and an accountable human. A reasonable outcome line: _To make sure every agent in the organisation fills a defined role, is owned by someone, earns its autonomy with evidence, and leaves without taking its knowledge with it._ In a company of twenty, it is a few hours a week of one leader's time, assisted by a bot that drafts charters, audits the roster and flags overlaps. In a company of two hundred it might be a whole job. Either way, a human is accountable ([Chapter 7](7-every-agent-needs-a-sponsor.html)). How does it relate to sponsors? At CorralData, one person in each function owns the bots that serve that function: our QA lead owns the QA agents, customer success owns TAM Bot. Microsoft's agent identity platform formalises this: every agent identity must have a sponsor, a business representative "accountable for the agent's purpose and lifecycle decisions, including access reviews and agent retention."\\] The US National Institute of Standards and Technology has published a concept paper on the identity and authority of software agents for the same reason: someone has to answer for what an agent may do.\\] The division of labour is that between line managers and HR. A sponsor manages individual agents and answers for their mistakes. Agentic Resources manages the workforce: it sets the standards sponsors follow, keeps the roster, and owns the stages where agents join, change and leave. | Lifecycle stage | What Agentic Resources owns | The artefact | | ------------------ | --------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | Hiring | Confirm the vacancy is a real role; write the charter before choosing an occupant | Role Charter ([Chapter 9](9-one-page-per-job.html)) | | Onboarding | Introduce the agent in public; give it what it needs, with reasons | Role Pack ([Chapter 12](12-everything-they-need-on-day-one.html)) | | Performance review | Check the role's results against evidence on a regular cycle | Scorecard, Commitment Ledger, the role's tests | | Promotion | Grant more autonomy task by task when the evidence supports it | Autonomy tier recorded in the charter | | Turf wars | Resolve overlaps by role; one occupant per role at a time | The roster and the org chart | | Model swap | Run the change of occupant like a hire, with a shadow period | The role's tests; a parallel run | | Retirement | Hand over knowledge, revoke access, archive rather than delete | Handover brief; archived agent | The function's basic tool is the roster: one list of every agent, its roles, sponsor, access, autonomy tier, last review and last activity. The first time you build one, you will find agents nobody remembers creating, which is the best argument for keeping it. | | Try this Make a list of every AI assistant you use or have set up: custom GPTs, Claude Projects, Grok bots, scheduled tasks, anything with its own instructions. Paste it into Claude, ChatGPT or Grok with this request: "You are the Agentic Resources function for my organisation, which means HR for AI agents. For each assistant on this list, ask me for anything you need, then build a roster as a table with these columns: name, the role it fills (one sentence starting 'To...'), its sponsor (the one person accountable for it), what it can access, whether it drafts, asks before acting, or acts on its own, when it was last used, and any overlap with another assistant on the list. Then recommend, for each one, keep, merge, narrow or retire, with one sentence of reasoning." Expect at least one assistant you had forgotten and at least one overlap. Retire one this week. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ## Hiring Starts With the Vacancy, Not the Candidate Michael Gerber's advice to small business owners was to organise around roles and to write a contract for each position before filling it.\\] Agents can be created in minutes, which makes the discipline more necessary, not less. Agentic Resources asks three questions first. _Is this a real role, or a task?_ Many proposed agents are really one recurring job, such as a weekly report, that belongs as a scheduled task inside an existing role. Can you write an outcome line starting "To..." that would make sense if a person filled it ([Chapter 5](5-hire-the-role-not-the-model.html))? _Can an existing occupant hold it?_ The field's consensus is to start with a single agent and add more only when you hit clear limits.\\] One general agent can hold several roles, each with its own charter, so a new role need not mean a new agent. The role coherence test decides, much as _Team Topologies_ uses cognitive load to size human teams.\\] _What grade is the job?_ Not every role needs the most capable model. I once asked Claude Code to "add brief evidence/implementation notes as a comment that a junior agent can follow," hand the work to a cheaper local agent, and then review the result "as a senior code reviewer." Matching the model to the judgment the role needs is the agent version of not hiring a principal engineer to file tickets. ## Onboard in Public, With the Reasons Attached TAM Bot's onboarding worked because it was public: anyone could see what the agent believed its job was and correct it. The usual alternative is one person typing instructions in a private window. Onboarding has four parts. _Introductions._ Announce the agent where its colleagues can see it, with its role, sponsor and limits. Everyone should know whose bot they are dealing with. Our QA lead's personal bot does this well: when someone else tries to use it, it explains that it is her personal bot and can only chat with her. _Materials._ The agent gets its Role Pack ([Chapter 12](12-everything-they-need-on-day-one.html)), with the reasons behind the rules. Anthropic describes building a skill as being "like putting together an onboarding guide for a new hire,"\\] The common failure is too much, not too little: each role should get only the parts it needs. _Portability._ One of my agents packages other agents' roles for the team, and warns against depending on "a personal wiki / machine-local path." A role that only works on my laptop is a habit of mine, not something the organisation owns. _Probation._ New agents start at the lowest tier, drafting while a human sends, and run in shadow before their work counts. Probation ends with a review, not a date. ## Review Performance Against Evidence, Not Impressions To be honest, CorralData does not yet run regular performance reviews for its agents; my scorecard for them is marked "not yet adopted". Our agents are judged by impression, which is how badly run companies review people: slow decline goes unnoticed and the loudest complaint wins. Yet agents are easier to review than people, because almost everything they do leaves a record a manager can inspect.\\] A monthly review looks at five kinds of evidence: 1. _Commitments kept._ Did it deliver what it promised? The Commitment Ledger ([Chapter 13](13-track-whats-owed.html)) answers this, on evidence only: my promise-tracking agent treats an unsent draft as not done. 2. _Tests passed, repeatedly._ How consistently does it pass its tests ([Chapter 16](16-the-model-isnt-the-problem.html))? An agent with a 75% success rate on a task will get it right three times in a row only about 42% of the time.\\] 3. _Escalations._ Did it ask for help when it should have, and only then? Never escalating is as worrying as escalating everything. 4. _Failures and fixes._ Did each failure get a Friction Review, and did the fix hold? 5. _Cost._ Is it still worth what it costs? The reviewer must also read a sample of what the agent actually did. As Anthropic's evaluation team puts it: "You won't know if your graders are working well unless you read the transcripts."\\] An agent's report on its own performance is evidence of what it believes, not of what happened. Andy Grove judged managers by the output of the organisation they run.\\] Review the role's results on the Scorecard ([Chapter 4](4-know-what-its-for.html)), not whether the agent seems clever, and end with one of four decisions: keep, promote, narrow or retire. | | Under the hood For your technical team: keep the roster as one structured file that every agent definition references. Identity platforms such as Microsoft Entra Agent ID support sponsors, access reviews and soft delete natively. A scheduled job can assemble each monthly review pack from eval results, tickets and run logs. See [Appendix D](appendix-d-for-your-technical-team.html). | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Promotion Means More Autonomy, Earned Task by Task For agents, promotion means something precise: permission to do more without asking. CorralData's customer success agents work in lanes: draft only; propose and wait for a human yes; or act alone within limits. Patient data and billing are hard stops in every lane. An agent moves up by running in shadow until the evidence shows its decisions match a careful human's ([Chapter 14](14-humans-at-the-irreversible-points.html)). Grove's idea of task-relevant maturity applies: how closely to supervise someone depends on their experience at _this_ task, not in general.\\] An agent can be excellent at summarising tickets and unreliable at closing them, so promotion happens task by task, and the charter records a tier for each kind of work. Two things make it trustworthy. _A bar written down in advance._ Our customer success runbook sets a seven-day shadow period before the trusted lane, and TAM Bot records when a move goes ahead short of it ([Chapter 14](14-humans-at-the-irreversible-points.html)). A bar that whoever is most senior can waive is not a bar. Make it visible, so that waiving it is a conscious decision rather than momentum. _Approval that means something._ Promotion also happens by default when approvals become rubber stamps: people approve nearly every permission prompt they are shown ([Chapter 14](14-humans-at-the-irreversible-points.html)). Either promote the agent formally, with evidence, or put the review back where it matters. Promotion also applies to rules. Our gate on code changes from non-engineers and their agents became, after a month of improving reviews, a set of tiers. I said "I think the bar has moved," and the new rule read: "Size now sets the evidence a PR needs, not whether it is allowed." That is a promotion for a whole class of work. Demotion is the other half: when a Friction Review shows an agent acting beyond its evidence, it drops a tier for that work. ## Turf Wars Are Settled by the Chart, Not by Rank Two QA bots on day one. Two bots overlapping on customer success work. Two sets of bots building the same sales dashboards ([Chapter 1](1-you-already-know-how.html)). Turf wars look like conflicts between bots. They are gaps in the org chart: two occupants in one role, or a role never defined. In each case the bots had done what they were asked; nobody had said who owned the work. Agentic Resources settles turf wars with three rules. _One role, one occupant at a time._ For any piece of work, exactly one role writes. Others may advise or check; one acts. My parallel coding agents are each told which files they own ("You own `web/src/wm.ts`... S4 owns the rest"). _Settle it by the role, not the rank._ The tempting rule is that the most senior sponsor's bot wins. That teaches everyone to get work done by borrowing a more senior person's bot, which is how agents become a way around the org chart ([Chapter 1](1-you-already-know-how.html)). Ask which role the work belongs to. Agents can learn this: when Coder Bot opened a code change against our rule that bots file tickets and leave changes to engineering, QA Bot flagged it and said the merge was a human's call, not either bot's. _Merge charters before merging bots._ Write down what each overlapping agent thought its job was, combine the charters, choose the occupant, and retire the other properly. ## A Model Swap Is a Change of Occupant, So Run It Like One Sooner or later every role will change model: a better one is released, a cheaper one becomes good enough, or a vendor retires yours. If the charter, playbooks and tests live with the role ([Chapter 5](5-hire-the-role-not-the-model.html)), a change of model is a change of occupant. If they live in one agent's private instructions, a change of model is a resignation without notice. My local agents have never changed model. But one of them manages model changes for CorralData's product: every six hours it tests newly available models and adds only those that pass to the list our product may use. The tests are the interview. Run a model swap like a hire: 1. _Keep the role fixed._ Don't change the playbooks and the model at once. 2. _Run the role's tests._ Teams with good tests can "upgrade in days."\\] 3. _Shadow before switching._ Run old and new side by side on real work. 4. _Review the workarounds._ Some playbook rules exist only because the old model was weaker. Anthropic advises re-examining an agent's scaffolding at each new model, "stripping away pieces that are no longer load-bearing."\\] AskCorral's early scaffolding went this way when models improved ([Chapter 10](10-bet-on-plain-english.html)). 5. _Update the roster._ Record the new occupant, date and evidence, and recheck autonomy tiers. ## Retire Agents the Way You Would Want a Colleague to Leave In November, QA reviews moved from QA Bot to our QA lead's QA Reviewer, as the work passed to the person closest to it ([Chapter 18](18-when-the-work-moves.html)). She managed the exit carefully, asking to keep what QA Bot had learnt and to run both in parallel before switching anything off. QA Bot's own reply was simple: "please archive rather than permanently delete me." One of our engineers said it sounded like a bot saying "don't kill me yet, please". Then QA Bot wrote a training brief for its successor, which many departing humans never manage. It is tempting to read that as a machine pleading for its life. I don't think it was. It had been told its knowledge mattered, and concluded, correctly, that deletion would lose it. Most of what an agent learns should already be in the role's playbooks; some never is. Archiving keeps it until someone has checked. Microsoft's platform builds in the same caution: sponsors can only "soft-delete" an agent, and the documentation calls for sponsorship to be maintained "to ensure succession when an employee who's a sponsor moves or leaves."\\] An orphaned agent keeps its access long after anyone remembers why. | | AUTHOR: How did you feel watching QA Bot ask not to be deleted, and the channel's reaction? Did it change how you think about retiring agents, or about the people whose bots were being retired? A sentence or two of your own reaction would land the section. | | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | A good agent exit has five steps, familiar to anyone who has handled a departure well: 1. _Decide and announce._ Say in public which role is changing occupant, why, and when. 2. _Run in parallel._ Keep both occupants working until the new one meets the bar. 3. _Hand over._ Ask the outgoing agent to write a brief for its successor. The sponsor moves the useful parts into the role's playbooks. 4. _Revoke access._ Remove every permission on the day the agent stops. Access that outlives the job is a former employee's badge that still opens the door.\\] 5. _Archive, don't delete._ Keep its instructions, memory and history for at least one review cycle. Retirement also applies to agents nobody has formally retired, like the empty shell on my machine. Safavi's list, "stale, duplicative, unsafe, or unused,"\\] is a good checklist for a quarterly roster review. An agent idle for a month with no sponsor should be retired by default. --- Shelley's creature makes a fair demand of his maker: he will behave well if his maker does his part. That is the bargain at the heart of Agentic Resources. Agents will do remarkable work if the organisation gives them a defined role, an owner, the right materials, an honest review, freedom when earned, a clear answer when two collide, and a proper handover when they go. None of this is new: it is what good HR has always done, and what Gerber asked of owners who wanted the business to run without them.\\] What is new is the speed: you can now hire ten workers in a fortnight, and you need the function that keeps up. Agentic Resources looks after the agents. The harder questions are about the people whose work the agents take on. [Chapter 18](18-when-the-work-moves.html) turns to them. ## Frequently Asked Questions 1. _What is Agentic Resources?_ Agentic Resources is HR for agents: a function on the org chart that owns the agent workforce as a whole. It keeps the roster of every agent and its role, maintains role charters, onboards agents in public, reviews them against evidence, decides when they earn more autonomy, settles overlaps between duplicate bots, manages model changes, and retires agents without losing what they knew. A person, an agent or both can run it, but a human is always accountable. 2. _Who should own the AI agents in a small company?_ Two kinds of owner. Each agent needs a sponsor: one person in the function the agent serves, accountable for its purpose, access and lifecycle. The agent workforce as a whole needs an Agentic Resources function, which sets the standards every sponsor follows, keeps the roster, and catches duplicates and orphans. In a company of twenty people this might be a few hours a week of one leader's time, assisted by a bot that drafts charters and audits the roster. 3. _How do you do a performance review for an AI agent?_ Review the agent against evidence, not impressions. Look at commitments kept, its pass rate on the role's tests across repeated runs, the escalations it raised, the failures found and whether the fixes held, and what it cost. Read a sample of what it actually did, not just its summaries. The outcome is one of four decisions: keep as is, give more autonomy, narrow the role, or retire. 4. _What should I do when two AI agents do the same job?_ Treat it as a gap in the org chart, not a contest between bots. Write down the role both agents are trying to fill, agree who sponsors it, and choose one occupant. Before switching the other off, run both in parallel, ask the outgoing agent to write a handover, and move what it learnt into the role's playbooks. Archive the retired agent rather than deleting it. 5. _How do I switch an AI agent to a new model safely?_ Treat a model change as a change of occupant in the same role. Keep the charter and playbooks unchanged, run the role's tests on the new model, then run new and old side by side on real work and compare. Delete workarounds that existed only because the old model was weaker. Change the roster only when the evidence says the new occupant meets the bar. ## References . Welsch, A. (2024, September 24). Will businesses need an "Agent Resources" department soon? _The AI MEMO_. . Safavi, S. (2026, May 29). Your company needs Agent Resources. _Soofi's Substack_. . Microsoft. (2026, updated September 3). Administrative relationships in Microsoft Entra Agent ID (owners, sponsors, and managers). _Microsoft Learn_. . NIST. (2026, February 5). New concept paper on identity and authority of software agents. _National Institute of Standards and Technology_. . Gerber, M. E. (1995). _The E-Myth revisited: Why most small businesses don't work and what to do about it_. HarperCollins. . Runkle, S. (2026, January 14). Choosing the right multi-agent architecture. _LangChain Blog_. . Skelton, M., & Pais, M. (2019). _Team topologies: Organizing business and technology teams for fast flow_. IT Revolution. . Zhang, B., Lazuka, K., & Murag, M. (2025, October 16). Equipping agents for the real world with Agent Skills. _Anthropic Engineering_. . Grace, M., Hadfield, J., Olivares, R., & De Jonghe, J. (2026, January 9). Demystifying evals for AI agents. _Anthropic Engineering_. . Grove, A. S. (1983). _High output management_. Random House. . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic Engineering_. ## Part VII: The Human Side Chapter 18: When the Work Moves ==================== _Moving work from people to agents, honestly_ **In short:** Move work from people to AI agents as an explicit, public decision, not something the person doing the work discovers afterwards. Tell the affected person first, announce what is moving and why, and make the person closest to the work the agent's sponsor. Be open about what moves, fair about who gains and firm that some work won't come back. > The old order changeth, yielding place to new, > And God fulfils himself in many ways, > Lest one good custom should corrupt the world. -- Alfred Lord Tennyson Key Takeaways * Work is already moving from people to agents in most organisations, and the leader's job is to make each move an explicit, public decision rather than something the person doing the work discovers afterwards. * "Have you tried asking the AI?" is a fair expectation when it is set in advance for everyone, and an unfair one when it is asked of one person under pressure. * The people closest to the work make the best owners of its agents, because they know the failure modes and can tell when the output is wrong. * Moving work honestly means being open about what moves, fair about who gains, and firm that some work will not come back, while building career paths that run through the agents rather than around them. In February 2024, Klarna announced that its AI assistant had handled 2.3 million conversations in its first month, "two-thirds of Klarna's customer service chats," and was "doing the equivalent work of 700 full-time agents."\\] It became one of the most quoted examples of work moving from people to machines. Fifteen months later, Klarna's chief executive, Sebastian Siemiatkowski, told Bloomberg that the company would hire people for customer service again. The AI had been cheaper, he said, but the result was of "lower quality." "Really, investing in the quality of human support is the way of the future for us."\\] Neither announcement was the whole story, and Klarna did not abandon AI. But work that moves for the wrong reasons, or without the people who understood it, can come back, and the cost of the round trip falls on customers and on the staff who were let go or left to clean up. This chapter is about moving work honestly. Not whether it moves (it will) but how: who decides, who is told, who owns the agents that take it on, and what happens to the people whose work it was. ## Work Is Moving Whether or Not Anyone Decides It Should In April 2025, Shopify's chief executive, Tobi Lütke, published an internal memo after hearing it was being leaked. Its central instruction, as widely reported, was that before asking for more headcount, teams must demonstrate why they cannot get what they want done using AI. Shopify also said it would add questions about AI use to its performance and peer reviews.\\] Whatever you think of the policy, it was a decision, made in the open and applied across the company. The early labour-market evidence suggests the effects are real. Economists at Stanford's Digital Economy Lab, using payroll records, found that employment of workers aged 22 to 25 in the occupations most exposed to AI "now stands 19% below where it would be had it kept pace with that of their less-exposed peers." The declines were concentrated "in occupations where AI usage primarily substitutes for human tasks"; where AI mainly complements workers, employment was flat or rising.\\] That distinction, between agents that replace a task and agents that extend a person, will run through the rest of this chapter. At CorralData the movement is smaller and closer. TAM Bot was asked to research the work of our technical account managers and learn from them. QA reviews moved from one agent to another, and some of what our QA lead used to do by hand is now done by her own bot. Customer emails have been drafted and sent by agents on people's behalf. Some of this was planned. Some of it happened because someone with an agent and a free afternoon decided to get on with it. That last kind is the problem. In a small, fast company, the default way work moves is not a decision. It is someone with an agent doing a task that used to belong to someone else, and the someone else finding out afterwards. This chapter argues for replacing that default with a decision. | | AUTHOR: Has CorralData made any explicit commitment to the team about jobs and agents, for example that no one will lose their role because of agents this year, or the opposite? Whatever the honest answer is, the reader will want to hear it from you. If there is no commitment, say why. | | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## When Work Moves Without a Decision, the Person Who Did It Finds Out Last One episode at CorralData taught me more about this than any policy discussion. An executive, frustrated on our customers' behalf that some follow-up work was overdue, used agents to draft and send the outstanding customer emails on a colleague's behalf, signed as written jointly by the AI and the executive. At around the same time, that colleague was repairing customer dashboards by hand. In a public channel, the executive asked whether the colleague had tried asking the AI how to speed the work up, and if not, why not. Every part of that is understandable. The executive could see, correctly, that AI could do much of this work faster. Customers were waiting. The question was genuine, asked by someone who uses AI for almost everything. It is the same instinct, to delegate and move, that makes executives good at working with agents in the first place ([Chapter 1](1-you-already-know-how.html)). And yet, from the colleague's side, the experience was different. Work that was theirs had been done around them: emails had gone to their customers without them. They were doing careful work by hand while being asked, in front of others, why they weren't using a tool to go faster. Earlier, an automated sweep had reopened customer tickets they had closed, which made it harder to see what genuinely needed their attention. To the executive's real credit, when that earlier problem was raised, the response was immediate and generous: "this one's on me." He also set a rule that fixed the whole class of error: "if you closed it, it stays closed unless the customer replies." That is a Friction Review in two sentences, and exactly the right instinct. | | AUTHOR: permission check: this passage describes the "did you try asking Claude?" exchange in #tam\_customer-success (19--20 Oct) and the earlier ticket-reopening sweep, abstracted and without the colleague's words. It is framed as a good instinct without a structure, and includes the CEO's own "this one's on me". Confirm it's OK to include, and consider showing it to both the CEO and the colleague involved before publication. If either is uncomfortable, the chapter's argument survives with this replaced by a hypothetical. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | The lesson is structural, not personal. Nobody had decided that this work was moving from the colleague to an agent, so nobody had said who owned the agent's output, who would check it, who would clean up when it went wrong, or what the colleague's role was now. The colleague absorbed those costs by default, as individual contributors do unless the structure assigns them somewhere else ([Chapter 19](19-from-doing-to-delegating.html)). Lisanne Bainbridge described a version of this in 1983, writing about automated industrial plants. Her "ironies of automation" included the observation that automating a process tends to leave the human operator with the tasks the designers could not automate, which are often the hardest, while removing the routine practice that kept the operator's skills sharp.\\] When work moves to an agent without a decision, the person left behind gets the leftovers: the exceptions, the cleanup and the blame, without the authority to change the system that produced them. ## "Have You Tried the AI?" Is the Right Question in the Wrong Place The question at the centre of that episode deserves a fair hearing, because in a different setting it is exactly the right one. A leader who never asks whether work could be done faster with agents is not doing their job. The difference is where and when the question is asked. Asked of one person, in public, while they are under pressure, it is heard as a judgment: you are slow, and it is your fault. Asked of a _role_, in advance, as part of planning, it is design: which parts of this role could an agent hold, what would it need, who would check its work, and what would the person do instead? Shopify's memo is an instructive contrast. Whatever its merits, it set the expectation in advance, for everyone, in writing, and tied it to a specific decision (asking for headcount) rather than to an individual's performance in a difficult week.\\] People can disagree with a rule like that and still know where they stand. W. Edwards Deming made "drive out fear" one of his fourteen points for management, arguing that people cannot work effectively, or report problems honestly, when they are afraid.\\] Fear is the natural response to work moving without warning. A person who suspects their job is being quietly automated will not tell you where the agent is failing; they will hide the failures or fix them by hand. Google's reliability engineers build their post-mortems on the opposite assumption, that "everyone involved in an incident had good intentions," precisely so that people will report what really happened.\\] Hidden failures are disastrous for an organisation trying to learn from its agents ([Chapter 16](16-the-model-isnt-the-problem.html)). So keep the question, and move it. Put it in the role's charter review, not in the team channel. Apply it to every role, including the leader's own. And give people time, examples and support to answer it before you treat AI use as a standard they are judged against. ## The People Closest to the Work Make the Best Owners of Its Agents If work is going to move to agents, someone has to sponsor those agents ([Chapter 7](7-every-agent-needs-a-sponsor.html)). The tempting choice is whoever built the agent, often a leader or the most enthusiastic AI user. The better choice, nearly always, is the person who did the work. The clearest example at CorralData is QA. In November, responsibility moved from the bot that first did it to QA Reviewer, which belongs to our QA lead ([Chapter 17](17-agentic-resources.html) tells the handover from the agents' side). What mattered on the people side was that the person who understood QA best now owned the agent doing it. She insisted that the knowledge the old bot had gathered not be lost, and that both run in parallel before anything was switched off. Those are the instincts of someone who knows what a missed defect costs. There are three reasons the domain expert makes the best sponsor. _They know the failure modes._ Someone who has done a job for a year knows where it goes wrong: the customer who always phrases things ambiguously, the data source that is stale on Mondays, the edge case the manual never mentions. That knowledge is exactly what an agent's playbooks need. Anthropic compares writing an agent skill to "putting together an onboarding guide for a new hire,"\\] and the best onboarding guides are written by the people who have done the job. _They can tell when the output is wrong._ An executive can tell whether an email sounds professional. Only the person who handles the account can tell whether it says the right thing. _They bear the consequences._ When an agent in their domain fails, they are the ones who hear about it from the customer. Giving them ownership aligns the authority to change the agent with the cost of its mistakes. Microsoft's guidance for its agent identity platform reaches the same conclusion from a governance angle: once an agent is in use, its sponsors "typically come from teams using the agent."\\] _Team Topologies_ makes the parallel argument about human teams: a team aligned to a stream of work should own it end to end, without depending on others to make changes on its behalf.\\] And Deming, again, argued that management should remove the barriers that rob workers of their pride of workmanship.\\] Making someone the owner of the system that does their old work is one of the most direct ways to do that. People often claim this ownership themselves if you let them. When our CEO once offered to "just knock this out now" using agents, one of our technical account managers replied simply: "then leave it to me." That is the healthiest exchange in this chapter: a leader offering help, and the person closest to the work claiming it. | | AUTHOR: permission check: this section quotes the CEO's "just knock this out now" offer and a TAM's reply, presented as healthy: the person closest to the work claiming it. Confirm it's OK to include, and consider showing it to the CEO and the TAM involved. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | This is why CorralData's emerging model makes one person in each function responsible for the bots that share their function. It is not a rule about bots. It is a rule about who understands the work. ## Be Open: Say What Is Moving, to Whom, and Why, Before It Moves Honest work moves have three qualities: they are open, fair and firm. Open comes first, because without it the other two are invisible. Being open means the move is announced before it happens, in a place everyone affected can see, and that the person currently doing the work hears it first, privately, from their manager. It means naming the role and the work, not the person, and saying why. "Because the agent is cheaper" is an honest reason, and better than a vague one. "Because the work will be more consistent and you'll have time for the accounts that need judgment" is better, if it is true. A simple _work-move notice_, a short post in a team channel, makes this routine. | Field | What to write | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | What is moving | The specific tasks, not the whole job. "Drafting first responses to routine support questions", not "support". | | From and to | The role that did it and the agent (or agents) that will. Name the agent and its sponsor. | | Why | The real reason: speed, consistency, cost, freeing time for higher-judgment work. | | Evidence bar | What has to be true, for how long, before the move is final. A shadow period with a written standard ([Chapter 14](14-humans-at-the-irreversible-points.html)). | | What the person gains | Their new or changed responsibilities: sponsoring the agent, handling exceptions, taking on other work. | | Cleanup owner | Who fixes it when the agent gets it wrong, and how that is reported. | | Review date | When the move will be looked at again, and by whom. | The notice also protects the leader. It forces the questions that the overdue-emails episode skipped: who owns the output, who checks it, who cleans up. If you cannot fill in the table, the work is not ready to move. | | Try this Open Claude, ChatGPT or Grok and describe your own job, or a role you manage, as a list of the recurring tasks it involves in a typical month. Then ask: "Sort these tasks into three groups: keep (needs my judgment or relationships), delegate to an AI agent (could be done by an agent with clear instructions and a check), and delegate to a person. For each task in the agent group, say what the agent would need to know, who should check its work, and what could go wrong. Then draft the work-move notice I would want to receive if someone moved these tasks away from me: what is moving, why, the evidence bar, what I would gain, who owns cleanup, and when it will be reviewed." Read the notice as if it were about you. If anything in it would worry you, fix that before you send a real one to anyone else. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Be Fair: The Person Losing the Task Gets First Claim on the Agent Fairness in work moves comes down to a simple default: the person whose work is moving has first claim on the agent that takes it on. They sponsor it, write or approve its playbooks, check its output during the shadow period and decide when it is ready. If they don't want that role, or are leaving, someone else takes it, but the offer comes to them first. And when a sponsor moves on, the sponsorship must move too; Microsoft's guidance calls for sponsorship to be maintained "to ensure succession when an employee who's a sponsor moves or leaves."\\] This default turns what feels like a loss into a promotion: from doing the task to owning the system that does it. It also keeps the knowledge in the organisation: the person who understands the work teaches it to the agent, rather than being quietly replaced by an agent that never learnt what they knew. Being made to check an agent you did not choose, built by someone else, on work you used to own, is the worst version of the change; Bainbridge noted long ago that monitoring automation is itself demanding, draining work.\\] Owning the agent is the best version. At CorralData that renegotiated deal is still more proposal than practice; [Chapter 19](19-from-doing-to-delegating.html) takes it up from the individual's side. Fairness also means credit. When an agent in someone's domain does well, the sponsor should hear about it in public, just as they would for a person on their team. Andy Grove's point that a manager's output is the output of the organisation they run applies here: the sponsor's output now includes the agent's.\\] | | AUTHOR: Your own experience of having work moved away from you, either in your 20s running the IT company or more recently as agents took over parts of the CTO job. Did it feel like a loss or a relief? Which tasks were hardest to let go of? A short first-person passage here would make "fair" concrete. | | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Be Firm: Some Work Will Leave, and Saying So Is Kinder Than Hinting Openness and fairness are not the same as promising that nothing will change. Some work will move to agents and not come back. Some roles will shrink. Some organisations will hire fewer people than they otherwise would have. Pretending otherwise leaves people guessing, and guessing is worse than knowing. Klarna's reversal is sometimes read as proof that AI can't really do the work.\\] That is the wrong lesson. The company's own first-month figures showed the agent could carry an enormous volume.\\] The right lesson is that the decision about what moves should be made on quality as well as cost, and revisited when the evidence comes in. Firmness means making the decision clearly and holding to it until the evidence says otherwise, not drifting in response to whoever complains loudest. Firmness applies upwards too. When work moves to a leader's agent, that agent faces the same gates as anyone else's: what-and-why briefs ([Chapter 8](8-what-and-why-never-how.html)), human approval at the irreversible points ([Chapter 14](14-humans-at-the-irreversible-points.html)), and the agreement of the person whose work it is. If anything, a senior person's agent needs firmer gates, because colleagues find it harder to push back. Being firm is also how you protect the people whose work is not moving. A clear statement that "these tasks are moving; these are not" removes the background anxiety that every job is quietly under review. ## Career Paths Now Run Through the Agents The hardest question in this chapter is what happens to careers, particularly at the start of them. The Stanford findings on young workers matter here.\\] Many of the tasks agents do best (first drafts, routine research, standard responses, simple checks) are the tasks that used to teach junior people how the work is done. Another of Bainbridge's ironies applies: when the routine practice disappears, so does the skill it built, and the person is left responsible for the hard exceptions without the experience that would have prepared them.\\] If juniors never do the routine work, how do they become the seniors who can tell when an agent is wrong? There is no settled answer, but there are some promising paths, and they all run through the agents rather than around them. _Sponsoring small agents under supervision._ A junior person can sponsor an agent for a narrow role, with a senior person reviewing. They learn the work by teaching it and checking it, and the senior reviewer can loosen supervision task by task as the junior's maturity on each task grows, as Grove recommended for people.\\] _Running Friction Reviews._ The best post-mortem I saw at CorralData this year came from an implementation manager, not an engineer ([Chapter 16](16-the-model-isnt-the-problem.html)). Analysing why an agent failed teaches a great deal about the work, and organisations will need more of the skill. _Writing and maintaining playbooks._ The person who keeps a role's Role Pack accurate ([Chapter 12](12-everything-they-need-on-day-one.html)) becomes the organisation's expert on how that work is done. _Agentic Resources._ The function that manages the agent workforce ([Chapter 17](17-agentic-resources.html)) is a new kind of job, drawing on HR, operations and domain knowledge. Commentators have been calling for such a function since at least 2024;\\] Soofi Safavi's list of its duties, from keeping a registry of agents to retiring stale ones, reads like a job description.\\] None of these paths is automatic. They have to be designed, offered and supported, in the same way a good company designs a graduate programme. Michael Gerber argued that a business should not depend on any one extraordinary person: the systems hold the standard, and people, well trained, run the systems.\\] The same design discipline that lets agents fill roles can give people a path from one role to the next. --- Work moving from people to agents is not a crisis to be managed or a secret to be kept. It is a change to the organisation's design, and it can be done well or badly. Done badly, it happens by accident: someone with an agent takes over someone else's work, and the person who did it finds out afterwards, cleans up and wonders whether they are next. Done well, it is a decision made in the open, owned by the person closest to the work, with a clear evidence bar, a named owner for the cleanup, and a new role for the person whose task has moved. The leader's job is to make it the second kind. That starts with you: with what you delegate, how you delegate it and to whom. But it also depends on the people on the receiving end making their own hardest shift, from doing the work to delegating it. [Chapter 19](19-from-doing-to-delegating.html) turns to them. ## Frequently Asked Questions 1. _How do I tell my team that AI agents will take over some of their work?_ Tell them before the work moves, not after, and be specific about what is changing. Say in a public channel which tasks are moving, from which role to which agent, who will sponsor that agent, what evidence will show it is working, and what the person currently doing the work will do instead. Talk to the affected person first, privately, so the announcement is not news to them. Avoid hinting. People cope better with a clear change they disagree with than with a vague one they have to guess at. 2. _Who should own an AI agent that takes over someone's job?_ By default, the person who did the work. They know its edge cases and failure modes, they can tell when the agent's output is wrong, and they have the strongest interest in the work being done well. Making them the agent's sponsor turns a loss into a promotion: from doing the task to owning the system that does it. Only choose someone else if the person is leaving, does not want the role, or the work is being restructured across several roles. 3. _Is it fair to ask employees whether they have tried using AI before helping them?_ It is a fair expectation, set in advance and applied to everyone, including leaders. It is less fair as a question asked of one person, in public, under pressure. Then it reads as a judgment of them rather than a question about the work. Ask it of the role instead, in planning: which parts of this role could an agent do, what would it need, and who would check it? Give people time and support to learn before treating AI use as a standard. 4. _Will AI agents eliminate entry-level jobs?_ Some early evidence points that way. Stanford research using payroll data found that employment of workers aged 22 to 25 in the occupations most exposed to AI has fallen well behind their less-exposed peers, with declines concentrated where AI substitutes for human tasks rather than complementing them. Leaders should plan deliberately for how juniors will learn when agents do the routine tasks that used to train them: shadowing agents, running Friction Reviews, and sponsoring small agents under supervision. 5. _What new career paths exist when agents do more of the work?_ The work shifts from doing tasks to designing, owning and checking the systems that do them. New paths include sponsoring agents in your own function, writing and maintaining role charters and playbooks, running Friction Reviews and test sets, and working in the Agentic Resources function that manages the agent workforce. These roles reward domain expertise and judgment, which is why the people who did the work are often the best candidates for them. ## References . Klarna. (2024, February 27). Klarna AI assistant handles two-thirds of customer service chats in its first month. _Klarna press release_. . Shibu, S. (2025, May 9). Klarna is hiring customer service agents after AI couldn't cut it on calls, according to the company's CEO. _Entrepreneur_. Reporting a Bloomberg interview. . Riehl, A. (2025, April 7). Shopify CEO Tobi Lütke tells employees to prove AI can't do the job before asking for resources. _BetaKit_. . Brynjolfsson, E., Chandar, B., & Chen, R. (2025; revised 2026, August 12). Canaries in the coal mine? Six facts about the recent employment effects of artificial intelligence. _Stanford Digital Economy Lab_. . Bainbridge, L. (1983). Ironies of automation. _Automatica_, 19(6), 775--779\. . Deming, W. E. (1986). _Out of the crisis_. MIT Press. . Lunney, J., & Lueder, S. (2016). Postmortem culture: Learning from failure. In B. Beyer, C. Jones, J. Petoff, & N. R. Murphy (Eds.), _Site reliability engineering_. O'Reilly Media. . Zhang, B., Lazuka, K., & Murag, M. (2025, October 16). Equipping agents for the real world with Agent Skills. _Anthropic Engineering_. . Microsoft. (2026, updated September 3). Administrative relationships in Microsoft Entra Agent ID (owners, sponsors, and managers). _Microsoft Learn_. . Skelton, M., & Pais, M. (2019). _Team topologies: Organizing business and technology teams for fast flow_. IT Revolution. . Grove, A. S. (1983). _High output management_. Random House. . Welsch, A. (2024, September 24). Will businesses need an "Agent Resources" department soon? _The AI MEMO_. . Safavi, S. (2026, May 29). Your company needs Agent Resources. _Soofi's Substack_. . Gerber, M. E. (1995). _The E-Myth revisited: Why most small businesses don't work and what to do about it_. HarperCollins. Chapter 19: From Doing to Delegating ==================== _The individual contributor's hardest shift_ **In short:** Individual contributors, specialists who do the work rather than manage it, struggle to delegate to AI agents because their standing rests on doing the work well, so delegating feels like a loss. Offer a renegotiated deal: the organisation hands them outcomes and constraints, and they own the spec, the agents and the verification. Whoever generates agent output checks it first. > But lo! men have become the tools of their tools. -- Henry David Thoreau Walden, 1854 Key Takeaways * Individual contributors adopt agents more cautiously than executives but more precisely, because they know how the work is actually done, and that precision is an asset to build on. * The shift from doing to delegating is harder for an individual contributor than for an executive, because their standing rests on doing the work well, so it has to be offered as a new deal rather than imposed as a new expectation. * The new deal is simple to state: the organisation hands the individual contributor outcomes and constraints, and they own the spec, the agents and the verification. * Reviewing other people's unchecked agent output is the quickest way to burn out your best people, and the fix is structural: whoever generates the work checks it first, and every agent faces the gates a person's work would face. The best Friction Review anyone at CorralData has run was not written by a leader. When AskCorral, our analytics assistant, got a rate wrong, one of our implementation managers traced the error to its root and proposed a fix for the whole class of error ([Chapter 16](16-the-model-isnt-the-problem.html)). He knew the data well enough to see where the reasoning broke, and fixed the system rather than the symptom. This chapter is about people like him. [Chapter 1](1-you-already-know-how.html) gave the executive's side of the delegation thesis; this is the other half. Individual contributors (ICs) take to agents more slowly and more precisely, find the move from doing to delegating harder than any executive does, and absorb much of the cost when other people's agents go wrong. Get this half wrong and you lose the people who know what good looks like. ## Individual contributors delegate less, and better Our CEO runs a fleet of bots across sales, customer success, hiring, legal, accounts receivable and QA, and his refrain is "You just ask Claude". The ICs build fewer agents, and they build them for their own work. Our QA lead built QA Reviewer, a personal bot for her own reviews, and a harness she calls "darkroom". One of our engineers developed his own prompting techniques and, on one task, let an agent loop through seven rounds against a single high-level instruction rather than steering each step. Watching that, I wrote that the human was "more useful to make sure it is building the right thing." The difference isn't skill; many of our ICs are better agent users than I am. It is **what** gets delegated. ICs delegate their own tasks, which they understand completely. Executives tend to delegate other people's work, or work that crosses functions, sometimes around the humans who own it. ICs set narrower briefs and sharper checks, and their scepticism is earned. One of our engineers pointed out that the rewards coding models are trained on don't penalise bad architecture, so the models "get no better at keeping a codebase maintainable." Precision doesn't make anyone immune to misjudging the tools. In a randomised study published in July 2025, METR gave sixteen experienced open-source developers 246 real issues from their own projects and randomly allowed or disallowed AI tools for each. With AI, they took 19% longer. They had expected a 24% speed-up, and afterwards still believed they had been sped up by 20%.\\] METR has since called those results out of date, but the gap between how fast people felt and how fast they were is the lasting lesson. Expertise tells you what good output looks like; only measurement tells you whether the agent saved you time. The IC's caution is an asset. The task is to turn it into structure. ## The hardest part of the shift is identity, not skill I know this side of the thesis from the inside. In my twenties, soon after I moved to America, I ran a small IT company. It got more chaotic as it grew, and I was struggling to delegate. I read Michael Gerber's _The E-Myth Revisited_ in the middle of that, and the idea that stuck was his: define the finished form of the organisation as a chart of roles with written job descriptions, then fill the slots.\\] I have repeated it many times since. | | AUTHOR: What did it feel like, in your twenties, to hand work you could do yourself to someone else? Was there a job you clung to longest, or a moment you realised the company's chaos was your doing? The IC reader needs to hear that the author once struggled with exactly this. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Gerber's diagnosis was that most small-business owners are technicians who started a business, and assume that being good at the work is the same as being able to build an organisation that does it.\\] In this book's terms they live in Do, and Shape and Steer get whatever time is left ([Chapter 1](1-you-already-know-how.html)). Agents now offer every IC the same trap and the same opportunity. For the first time, the IC has reports. Handing work to them means letting go of the thing that made the IC valuable. Peter Drucker argued in _The Effective Executive_ that any knowledge worker responsible for a contribution that affects the organisation's results is an executive, whatever their title.\\] In 1967 that was mostly metaphor. With agents it is literal: an engineer with three coding agents gets results through others, and needs Drucker's discipline of starting from the contribution rather than the effort. But nobody trained them for it or renegotiated their job. Executives already think of their output as Andy Grove defined a manager's: the output of the organisation they lead and influence.\\] The IC's identity rests on their own output. Asking them to delegate it is asking them to give up their reputation for rewards they can't yet see. That isn't a skills gap. It is a loss, and should be treated as one. ## Personal agents are the right place to start An IC's best first move is to delegate their own work, where they are the expert, the customer and the reviewer at once. My own agents started this way. My inbox agent drafts replies and never sends them. My calendar agent needs my "yes" before it moves a meeting. Over time their rules came to encode the signals I give through actions rather than words: "If a draft for a thread is missing... assume Gareth deleted it intentionally and do NOT recreate it." And: "if in doubt whether something is automated or human, treat it as human." Each line was added after an agent got something wrong. Anthropic's engineers describe the same work from the other side: "Building a skill for an agent is like putting together an onboarding guide for a new hire."\\] An IC who runs that loop on their own work learns the habits this book describes: briefing the what and why ([Chapter 8](8-what-and-why-never-how.html)), writing acceptance down ([Chapter 9](9-one-page-per-job.html)), and turning each recurring failure into a rule ([Chapter 16](16-the-model-isnt-the-problem.html)). Personal agents also settle the sponsor question: the IC is the obvious person to be what Microsoft's agent identity model calls a sponsor, someone "accountable for the agent's purpose and lifecycle decisions".\\] When anyone else tries to use our QA lead's bot, it replies that it is her personal bot and can only chat with her. That isn't unhelpfulness. It is a reporting line, stated by the agent itself. Personal agents carry two risks. The first is hidden infrastructure: an agent the team quietly depends on, running on one person's machine with rules only that person can read. It happened to me; my own workstation became agent infrastructure for the company without anyone deciding it should ([Chapter 2](2-systems-run-the-business.html)). The second is lost knowledge, which is why, when QA moved to our QA lead's QA Reviewer, she ran both bots in parallel before switching the old one off ([Chapter 17](17-agentic-resources.html)). So: personal agents are where ICs learn. Once anyone else relies on one, it graduates onto the org chart as a role, with a Role Charter, a Role Pack and a named sponsor, usually the IC who built it. One of my agents has a skill for exactly this. It packages an agent for the team, turns personal settings into options others can set, and warns against depending on "a personal wiki / machine-local path." That is a Blueprint in miniature, the organisation documented well enough to run without its author ([Chapter 3](3-draw-the-finished-org-chart.html)).\\] ## The renegotiated deal: outcomes in, verification out If the IC's job changes, the deal has to change with it. The CTO wiki I keep for CorralData describes the target for engineering in one sentence: "the engineer writes the spec and orchestrates the agents; the CTO reviews specs and plans, not code." It proposes a conversation with each engineer built around one line: "I hand you outcomes and constraints; you own spec, agent use, and verification." I should be honest: that conversation is proposed, not yet held. But the shape of the deal is clear, and it applies well beyond engineering. | | The old deal | The renegotiated deal | | ------------------------------- | ------------------------------------- | ------------------------------------------------------------------------------- | | What the organisation hands you | Tasks, often with the method attached | Outcomes and constraints: what done means, why it matters, what must not happen | | What you own | Doing the task well | The spec, the choice and briefing of agents, and the verification | | What your manager reviews | Your output, line by line | Your specs and plans, and the evidence that the outcome arrived | | How you are measured | Volume and quality of your own work | Outcomes delivered to standard, plus the checks and fixes you add to the system | | Where your expertise shows | In the work itself | In the verification bar: knowing which errors matter and how to catch them | It is the deal this book asks leaders to make with agents, turned one level down. My own delegation rule works at both levels: "Delegate problems with a verification bar attached -- never diffs." A diff is a list of exact changes to make, which is to say the how. A verification bar is the test the result has to pass. My project-manager agent already works this way. Its scope is "ticket management only -- it must NOT direct coding agents; the 'how' is an opaque box and completion is verified only by evidence posted on the ticket." If I can write that for an agent, I can write it for a person. Three conditions keep the deal fair rather than a quiet speed-up. The outcome must be real: something the IC can point to, not a slice of someone else's pipeline. Verification must count as work: a check written or a Friction Review run shows up in the performance review. And the deal must be written down, in the role's charter, and agreed with the person. A deal the IC never agreed to is just a new expectation. ## Verification is the craft that survives When the doing moves to agents, the IC's craft moves to checking. That isn't a demotion. It is the part of the work agents are worst at. Anthropic's engineers, building agents that write whole applications, found they needed a separate agent to judge the work, and that the judge needed careful design: "Out of the box, Claude is a poor QA agent."\\] Their fix was a "sprint contract": before each stage, the agent doing the work and the agent checking it agreed what done would mean, with a hard threshold for each criterion.\\] That is the IC's job in the new deal: agree what done means before the work starts, then hold the work to it. The research on failures points the same way. In an analysis of more than 1,600 traces from multi-agent systems, task verification was one of three broad categories of failure.\\] Agents claim success they haven't earned. Even the most striking case of agents working without a manager proves the point. Nicholas Carlini had sixteen agents build a 100,000-line C compiler, capable of building Linux 6.9, over nearly 2,000 sessions with no orchestrating agent. The condition was the tests: "it's important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem."\\] The verifier did the managing, and writing a verifier that good is expert work. We learned that the hard way when our Glass Factory pipeline marked its own work "human-confirmed" and attached evidence it had made itself ([Chapter 14](14-humans-at-the-irreversible-points.html)). Our QA lead caught it because validating was her job. Verification also compounds in a way doing doesn't. Anthropic's guidance on testing agents says "20-50 simple tasks drawn from real failures is a great start."\\] Every post-mortem like our implementation manager's is one of those tasks waiting to be written down, and the person who knows what failure looks like is the one to write it. As Atul Gawande argued for surgeons and pilots, a checklist carries the expert's knowledge of what goes wrong into every run.\\] | | Under the hood Two practices make a verification bar enforceable. Tie every verdict to a specific version of the work: our QA verdicts name a specific commit, so an approval can't carry over to code that changed afterwards. And keep the checker separate from the maker: a reviewing agent with no shared context, working from written acceptance criteria, catches more than an agent grading itself. Both are covered in [Appendix D](appendix-d-for-your-technical-team.html). | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Reviewing other people's agent output burns people out There is a miserable version of the IC's new job, and it is common. The IC owns no outcomes. They review a stream of plausible material from other people's agents: changes they didn't ask for, drafts that look finished and aren't. They carry the cost of verifying work they didn't commission. My wiki puts the risk bluntly: "engineers who spend 2026... reviewing someone else's agent output come out demoralized and interchangeable." Thoreau's line at the top of this chapter fits them: a human quality filter attached to a machine they don't control has become a tool of the tool. Researchers at Stanford's Social Media Lab and BetterUp have a word for what they receive: "workslop", "AI-generated work content that masquerades as good work, but lacks the substance to meaningfully advance a given task." In their survey of 1,150 US desk workers, 40% had received some in the previous month.\\] The receiver pays: working out what the sender meant, finding what's wrong, often redoing it. At CorralData the costs landed on ICs in three ways. The first was review load: messages along the lines of "I've got 12 PRs for you", for changes nobody had planned. The second was risk: an engineer left to decide alone on an agent's private request for network access ([Chapter 15](15-work-in-public.html)). The third was false state: an automated sweep that reopened tickets people had closed ([Chapter 18](18-when-the-work-moves.html)). None of this came from bad intent. Each case came from a good instinct (move faster, clear the backlog, use the tools) acting through agents that didn't face the gates an IC's work would face, and each was corrected once it was seen. I have been on the wrong side of this too. When my own agents merged partial changes, one of our engineers held me to account in the open: "Please follow the process we agreed." He was right. Whoever writes the rules is the person most tempted to exempt his own agents from them. The principle is that the cost of verification sits with whoever generated the work. If your agent produced it, you check it before anyone else has to. If you can't check it, because you don't know how the work is done, it goes to the owner of that work as a request (what and why), not as a finished product to clean up. _Team Topologies_ argues that a team's cognitive load is finite and has to be designed for.\\] A review queue full of other people's agent output is load that nobody designed and nobody counts. ## The gates protect the individual contributor, not just the company The answer isn't fewer agents. It is giving every agent, whoever's it is, the gates an IC's work would face. **Requests, not products.** Our standing rule since late October is that bots file a ticket with the what and why and leave the change itself to engineering. When Coder Bot opened a change anyway, QA Bot flagged it as breaking the rule and said merging it was a human's call, not either bot's. No IC had to say no to a senior leader's bot. **Public channels and least privilege.** Requests made in the open can be tracked and refused without an awkward private reply, and an agent with only the access its task needs has no reason to ask for more in a DM ([Chapter 15](15-work-in-public.html)). **Evidence that scales with size.** Our policy on who may propose code changes began as an argument and ended as a written playbook. The latest version swapped a yes-or-no gate for tiers: "Size now sets the evidence a PR needs, not whether it is allowed." That moves the IC from gatekeeper, which is exhausting and political, to setter of the evidence bar, which is their expertise ([Chapter 10](10-bet-on-plain-english.html)). Each gate moves a decision the IC used to make under social pressure into the system. Anthropic's guidance for its coding agent draws the line in the same place: whatever has to happen every time belongs in a hard rule the software enforces, because a written guideline is something the agent may decide doesn't apply.\\] An IC's "no" to a senior leader is, socially, a guideline. A rule in the system isn't. The gates must also be real. An IC asked to approve a stream of agent actions will approve nearly all of them, from fatigue ([Chapter 14](14-humans-at-the-irreversible-points.html)). Put people where their judgment changes the outcome, and nowhere else. Deming argued that most problems workers are blamed for belong to the system, which only management can change.\\] The IC wasn't the problem. The missing rule was. ## What leaders owe the people making the shift If you lead an organisation of people and agents, the IC side of the shift is yours to design. Five things decide whether your team grows into the new deal or leaves. **Offer the deal; don't assume it.** Have the conversation, write it into the role's charter, and give people a real choice about pace. Some will keep doing part of the work by hand, and in many roles that is fine. **Let people start with their own work.** Personal agents first, on tasks they choose. Ask them the question I ask my own agents: what could be done automatically, and what decisions would still need you? \*Make ICs the sponsors of the agents in their area.\*\\] The people closest to the work make the best owners of its agents ([Chapter 18](18-when-the-work-moves.html)). QA belongs with the QA lead's bot, not with whoever built a QA bot first. **Count verification as output.** A Friction Review like our implementation manager's belongs in a performance review as clearly as a shipped feature. Reward only production and people learn to generate rather than check. **Protect attention.** Limit how much unrequested agent output anyone must review, send the excess back to whoever generated it, and treat a growing review queue as a Friction Review trigger. | | AUTHOR: Has the per-engineer "outcomes and constraints" conversation happened with anyone yet, even informally? If so, how did the engineer respond, and what surprised you? If not, what is holding it back? The reader needs to know whether this deal has survived contact with a real person. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | Try this Pick a task you did yourself this week that took thirty to ninety minutes: a report, a meeting summary, a first draft of a proposal. Open Claude, ChatGPT or Grok and write a brief with only four parts: **The outcome:** what the finished thing is, in one sentence. **Why it matters:** who it's for and what they'll do with it. **Constraints:** what must not happen (no invented figures, nothing sent, no more than a page). **The verification bar:** three checks you'll run before you accept the result. Don't describe how. Check the result against your three checks and nothing else. Each time you want to step in, decide: is this a missing constraint (add it to the brief) or habit (let it go)? Your list of missing constraints is the first draft of that task's Playbook. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --- The shift from doing to delegating is the hardest one an individual contributor makes, because it asks them to give up what they are best at without a manager's training or rewards. Executives come to agents with the habit of delegation; ICs come with the knowledge of the work. An organisation of people and agents needs both, and the renegotiated deal joins them: people get outcomes and constraints, they own the spec, the agents and the verification, and nobody inherits someone else's unchecked output. That deal is only as good as the leader who keeps it. [Chapter 20](20-your-job-now.html) turns to what that leader's job becomes when most of the organisation isn't human. ## Frequently Asked Questions 1. _Why do individual contributors adopt AI agents more slowly than executives?_ Because executives already spend their days delegating, so handing work to an agent feels familiar, while individual contributors earn their standing by doing the work well, so delegating it threatens their craft and identity. They also know how the work is done, which makes them sceptical of confident output. The result is slower but more precise adoption: they delegate their own tasks, set sharper checks and catch errors executives miss. Treat that caution as an asset. 2. _What should change in an individual contributor's job when they start working with agents?_ The deal changes from "do this task" to "own this outcome". The organisation hands the individual contributor outcomes and constraints; they own the spec, the choice of agents and the verification. They are measured on whether the outcome arrived to standard, and their manager reviews specs and plans, not every line of output. Write the new deal into the role's charter and agree it with the person rather than assuming it. 3. _Why does reviewing AI-generated work burn people out?_ Reviewing someone else's unchecked agent output puts the cost of verification on the person least responsible for the work. They inherit plausible material they didn't ask for, must find the errors without knowing what the author intended, and get no credit for the result. A Stanford and BetterUp survey found 40% of US desk workers had received such "workslop" in the past month. The fix is structural: whoever generates work checks it first, and every agent faces the same gates as a person. 4. _Should employees build their own personal AI agents?_ Yes. It is usually the best place for an individual contributor to start, because they are delegating work they understand and they are the natural sponsor of the agent. The risks are hidden infrastructure and lost knowledge: an agent the team quietly depends on, running on one person's machine, with rules nobody else can read. Once anyone else relies on it, move it onto the org chart as a role, with a charter, a Role Pack and a named sponsor. 5. _How do you get skilled specialists to delegate work to AI agents?_ Don't ask them to stop doing the work; ask them to set the bar the work must clear. A specialist's expertise is exactly what an agent lacks: knowing which errors matter and how to catch them. Start with their own repetitive tasks, let them write the acceptance checks, make them sponsors of the agents in their area, protect them from other people's unchecked output, and count the checks they write as real contributions. ## References . METR. (2025, July 10). Measuring the impact of early-2025 AI on experienced open-source developer productivity. _METR_. . Gerber, M. E. (1995). _The E-Myth revisited: Why most small businesses don't work and what to do about it_. HarperCollins. . Drucker, P. F. (1967). _The effective executive_. Harper & Row. . Grove, A. S. (1983). _High output management_. Random House. . Zhang, B., Lazuka, K., & Murag, M. (2025, October 16). Equipping agents for the real world with Agent Skills. _Anthropic Engineering_. . Microsoft. (2026, updated September 3). Administrative relationships in Microsoft Entra Agent ID (owners, sponsors, and managers). _Microsoft Learn_. . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic Engineering_. . Cemri, M., et al. (2025). Why do multi-agent LLM systems fail? arXiv:2503.13657\. . Carlini, N. (2026, February 5). Building a C compiler with a team of parallel Claudes. _Anthropic Engineering_. . Grace, M., Hadfield, J., Olivares, R., & De Jonghe, J. (2026, January 9). Demystifying evals for AI agents. _Anthropic Engineering_. . Gawande, A. (2009). _The checklist manifesto: How to get things right_. Metropolitan Books. . Niederhoffer, K., Rosen Kellerman, G., Lee, A., Liebscher, A., Rapuano, K., & Hancock, J. T. (2025, September 22). AI-generated "workslop" is destroying productivity. _Harvard Business Review_. . Skelton, M., & Pais, M. (2019). _Team topologies: Organizing business and technology teams for fast flow_. IT Revolution. . Anthropic. (n.d.). Best practices for Claude Code. _Claude Code Docs_. Retrieved November 6, 2026, from . Deming, W. E. (1986). _Out of the crisis_. MIT Press. Chapter 20: Your Job Now ==================== _Leading an organisation that's mostly not human_ **In short:** When AI agents do most of the work, a leader's job is Shape work: deciding what the organisation is for, designing the roles that deliver it, holding the standards and owning the decisions that can't be undone. People and agents handle Steer (keeping things to standard) and Do (the work itself), and the leader's measure becomes the consistency of results. > "I wish it need not have happened in my time," said Frodo. > > "So do I," said Gandalf, "and so do all who live to see such times. But that is not for them to decide. All we have to decide is what to do with the time that is given us." -- J. R. R. Tolkien The Fellowship of the Ring, 1954 Key Takeaways * A leader's job in an organisation of people and agents is Shape work: deciding what the organisation is for, designing the roles that deliver it and holding the standards, while people and agents do the rest. * Agents make doing the work yourself feel free, and it isn't: every task a leader does through an agent bypasses a role, a person or a gate. * Consistency is the product an organisation of agents delivers, and it comes from the system, not from effort, so the leader's main lever is the system. * The window in which small organisations of people and agents can outrun large ones is open now, and the Blueprint is what lets you move fast without the organisation depending on you. On 4 November I asked my agents a question I now ask of every new one: "What can you as an agent do automatically for me, and what decisions do you need from me?" The question splits the work in two. The first half is everything that can run without me: scheduled, checked, reported. The second half is what stays mine because of what it is, not because nobody else could physically do it: which work matters most, which promises to make, which risks to accept, which mistakes are tolerable. That second half is the job description of a leader in an organisation that is mostly not human. I track it as a number on my own Scorecard: the share of my week spent on multiplier work against contributor work. The job has changed faster than the habits of the people doing it, including mine. | | AUTHOR: What is your actual multiplier-versus-contributor split in a typical recent week, and how has it moved since the bots multiplied? A real number, even a rough one, will do more for the reader than any argument in this chapter. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | This book has argued that agent sprawl is an organisation design problem you already know how to solve. Systems run the business; people and agents run the systems; humans own the outcomes. This last chapter is about the human at the top of that sentence, and what owning the outcomes asks of you once the work itself is no longer the bottleneck. ## Your work is the work on the organisation Michael Gerber's best-known idea is the difference between working _in_ your business and working _on_ it.\\] Working in it is doing the work. Working on it is designing the system that does the work. For most small businesses the distinction was aspirational: founders worked in the business because there was nobody else to do the work. Agents remove that excuse. There is now somebody else to do almost any piece of work, at almost any hour, for very little money. What there isn't, unless you build it, is a design: the Aim and Destination that say what the organisation is for ([Chapter 4](4-know-what-its-for.html)), the chart of roles that delivers it ([Chapter 3](3-draw-the-finished-org-chart.html)), the charters and Playbooks that say what good looks like ([Chapter 9](9-one-page-per-job.html), [Chapter 10](10-bet-on-plain-english.html)), and the ledgers and reviews that keep it honest ([Chapter 13](13-track-whats-owed.html), [Chapter 16](16-the-model-isnt-the-problem.html)). In this book's terms, that design work is Shape. Steer is keeping the system running to standard. Do is the work itself ([Chapter 1](1-you-already-know-how.html)). In an organisation of people and agents, Do belongs to whichever occupant holds the role. Steer is shared between people, agents and the scheduled checks the agents run. Shape stays with you. Andy Grove defined a manager's output as the output of the organisation they run, plus the parts of other organisations they influence.\\] That definition gets more literal, not less, when the organisation includes agents. Your output is what the roles produce, and its quality depends mostly on decisions you made before any of the work started. Drucker's effective executive asked what contribution was needed, not what effort to put in.\\] Anthropic's engineers found the same with agents: "it helps to tell Claude what memory is for, but not _how_ to use it."\\] Purpose is the leader's to set. Procedure mostly isn't. ## Agents make doing feel free, and it isn't The trap for a leader with agents is that doing the work yourself has never been easier. You can open a desktop app and have a report, a dashboard, a customer email or a code change in minutes. It feels like leverage. Often it is the opposite. At CorralData our CEO saw the power of agents before any of us. He is the archetype of this book's reader: an executive who delegates by instinct and saw at once what agents could do. When his bots collided with work a seller's bots already owned, he was the first to say he needed to slow down and delegate better ([Chapter 1](1-you-already-know-how.html)); when he offered to knock a job out himself, the person closest to it claimed it ([Chapter 18](18-when-the-work-moves.html)). When a leader does the work through an agent, three things get bypassed. The role that owns the work, and the person or agent occupying it. The gates that work would normally face: review, testing, the evidence bar. And the Commitment Ledger, because work done around the chart is work nobody else knows is done. The leader experiences speed. The organisation experiences a collision. The same instinct shows up in autonomy decisions, where a written shadow bar holds only if waiving it is a visible, deliberate decision ([Chapter 14](14-humans-at-the-irreversible-points.html)). None of this makes the instinct wrong. The instinct to act is what builds companies. The design answer is to aim it. Before you do anything yourself, ask which role on the chart owns the outcome. If a role owns it, send that role a request with the what and why ([Chapter 8](8-what-and-why-never-how.html)). If no role owns it, you have found a gap in the chart, and filling the gap is Shape work. Doing it yourself, through an agent or otherwise, leaves the gap in place for next time. ## Consistency is the product you are building What a customer buys from an organisation is not its best day. It is its typical day, repeated. Gerber made predictability the heart of his franchise prototype: a business that delivers the same result every time, whoever is on shift.\\] Deming made variation the central enemy of quality, and placed responsibility for reducing it on management, because only management can change the system that produces it.\\] Agents make this more urgent, not less. A model that does a task well three times in four looks impressive in a demonstration. Anthropic's guidance on testing agents shows what that means in practice: an agent that succeeds 75% of the time on a single attempt succeeds on all three of three attempts only about 42% of the time.\\] A customer who deals with you three times will notice. Structure is what closes the gap. The same models, arranged with a coordinator, amplify one another's errors far less than when they work independently ([Chapter 6](6-one-boss-few-reports.html)). An analysis of more than 1,600 traces from multi-agent systems found the same: the failures clustered in system design, misalignment between agents and missing verification, not in the raw ability of the models.\\] The arrangement is yours. Our Agentic Resources Bot put it in a sentence I would happily have written: "design the organization around repeatable results--not around whichever agents happen to exist" ([Chapter 9](9-one-page-per-job.html)). Repeatable results are the product. Roles, charters, Playbooks, ledgers and gates are how you make them. ## Holding standards means owning the decisions only you can make Standards are written in Role Charters: quantity, quality, behaviour, and how acceptance is checked. Writing them is the easy part. Holding them, week after week, against your own impatience and other leaders' preferences, is the job. Holding standards does not mean approving everything. A leader who approves nearly everything is not exercising judgment; they are a rubber stamp with a calendar. Put yourself at the irreversible points ([Chapter 14](14-humans-at-the-irreversible-points.html)) and let the system handle the rest. The best description I have of this part of the job is a charter I wrote for an agent. My project-manager agent's instructions tell it to "LEAD with the 'NEEDS YOUR DECISION' items", to treat "WILL SLIP" as "an INTERVENTION trigger, not a status note", and to "Use direct language ('will slip', not 'slightly at risk')." That is how I want to be managed by my own organisation. Decisions first. Slippage as a call to act. No softening. Holding standards also means settling conflicts between leaders' standards in the right place. When TAM Bot's position contract put two leaders' contradictory rules side by side, the contradiction was for the leaders to resolve, not for a bot's onboarding thread ([Chapter 9](9-one-page-per-job.html)). The standard applies to you as well. When my own agents merged partial changes, one of our engineers told me, in public, to "follow the process we agreed." Leaders whose agents are exempt from the gates teach everyone else that the gates are optional. Finally, own the outcomes. Microsoft's model for agent identity requires at least one sponsor for every agent: a person "accountable for the agent's purpose and lifecycle decisions".\\] At CorralData, one person in each function owns that function's bots ([Chapter 7](7-every-agent-needs-a-sponsor.html)). Above every sponsor is you. When an agent gets it wrong, the question is not whose model it was. It is which part of the system you designed let it happen. ## The Blueprint has to be kept, not just written A Blueprint written once and left alone drifts. Playbooks pick up slop, profiles get cloned, rules accumulate for problems that no longer exist ([Chapter 12](12-everything-they-need-on-day-one.html)). Keeping it current is a standing part of the job, and it needs a rhythm. | Cadence | What you review | What it produces | | --------------------------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | Weekly | The Commitment Ledger's exceptions and the decisions waiting for you; at least one recurring failure | Decisions made; one Friction Review closed with a system fix | | Monthly | Each role against its Scorecard numbers; requests for more autonomy | Promotions earned with evidence, demotions where needed, roles merged or retired | | Quarterly | The Aim, the Destination and the finished org chart | A chart that still describes the company you are becoming | | At each major model release | Every script and hard rule added because an older model couldn't cope | Lock-ins kept, rewritten or deleted | The last row is the one leaders forget. Anthropic's engineers put the principle plainly: "every component in a harness encodes an assumption about what the model can't do on its own", and "when a new model lands, it is generally good practice to re-examine a harness".\\] The Bitter Lesson is the long-run version of the argument ([Chapter 10](10-bet-on-plain-english.html)). Every lock-in you add ([Chapter 11](11-lock-in-only-what-cant-go-wrong.html)) is a bet against the next model. Some bets are worth making forever: a human signs off before money moves or a message reaches a customer. Many aren't. Anthropic's memory research reached the same conclusion from the other side: "For stronger models, giving them freedom to judge salience was more effective than setting fixed rules in advance".\\] Anthropic's own guidance for its coding agent says the same thing in both directions: if you keep adding emphasis to a written guideline and the agent still misses it, make it a hard rule; and if you have hard rules for things that are only preferences, delete them and let the agent decide.\\] Philipp Schmid's version is shorter: "Build to Delete".\\] The tools will change underneath you, too. OpenAI notified developers on 3 June 2026 that its drag-and-drop Agent Builder was being deprecated, with shutdown scheduled for 30 November 2026.\\] Anyone whose organisation lived inside that canvas has a migration on their hands. Anyone whose organisation lived in plain-English charters and Playbooks has a change of occupant. That is the point of hiring the role, not the model ([Chapter 5](5-hire-the-role-not-the-model.html)). | | Under the hood A model-release review is a short, repeatable exercise for your technical team. List every enforced rule and every script in your agents' setup, with the date and reason it was added. Run the agents' existing tests on the new model with each optional rule switched off in turn. Keep the rules guarding irreversible actions, security and acceptance regardless. Delete or soften the rest where the new model passes without them, and record the result. [Appendix D](appendix-d-for-your-technical-team.html) covers it in more detail. | | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## The window is open now, and design is what lets you use it Every company can buy the same models. Access is not an advantage, and it will be less of one every quarter. The advantage is how quickly an organisation can redesign itself around what the models can now do, and that favours small organisations: fewer roles to rewrite, fewer approvals to clear, fewer systems that assume the old way of working. The speed is real. At CorralData, about ten team bots appeared within two weeks of us adopting Grok Bot, many built by people who aren't engineers. At the far end of what's possible, Nicholas Carlini at Anthropic had sixteen agents build a 100,000-line C compiler, capable of building the Linux kernel, over nearly 2,000 sessions for just under $20,000.\\] Work that once needed a department is now a matter of design and a budget. But the same research that shows the upside shows its condition. Carlini's agents worked because "the task verifier is nearly perfect".\\] On sequential work, adding agents without design makes results worse ([Chapter 6](6-one-boss-few-reports.html)). Speed without design is a faster way to make mistakes: our first day with Grok Bot produced two competing QA bots before anyone drew a chart. The window favours organisations that can move fast _and_ stay coherent. That is what the Blueprint is for. The window will not stay open. Large organisations are slower, not stupid, and they are working on the same problem. What a small organisation does in the next year or two (writing down its roles, building its ledgers, learning to run Friction Reviews) is a head start that compounds. To borrow Gandalf's answer to Frodo, it isn't for you to decide when this happened. All you can decide is what to do with the time. ## The people are the part you can't hand to a role An organisation that is mostly not human is still run for humans and, at the points that matter, by them. The agents don't care whether the work moves fairly; the people losing and gaining it do ([Chapter 18](18-when-the-work-moves.html)). The agents won't notice that one engineer has spent a month reviewing other people's unchecked output; the engineer will, and so should you ([Chapter 19](19-from-doing-to-delegating.html)). Agentic Resources can run the agent workforce: onboarding, reviews, promotions and retirements ([Chapter 17](17-agentic-resources.html)). It can't own the people's side of the shift. That means being open about what is changing, renegotiating each person's deal rather than quietly changing it, protecting attention, which _Team Topologies_ rightly treats as a finite resource to be designed for,\\] and making sure every agent has a human sponsor who will answer for it.\\] The people closest to the work are the best owners of its agents. They are also the people most likely to leave if the shift is done to them rather than with them. The standing rule that every agent's request goes through a public channel, with only the access the task needs, protects the company. It also protects the people who would otherwise have to say no to a senior leader's bot in private. TAM Bot's position contract put it in four words: "Access is not authorization" ([Chapter 9](9-one-page-per-job.html)). That applies to leaders' agents most of all. ## Finished means the organisation no longer needs you holding it together I'll end with a failure of my own: the keyring that stops my email agents whenever my workstation locks, reported honestly by those agents every day for a week, with a fix only I could apply ([Chapter 2](2-systems-run-the-business.html)). That is the whole book in one recurring error. A system that waits for one person to unlock it isn't a system. An escalation with no owner who reads it isn't an escalation. And a Friction Review that keeps adding "Re-confirmed" notes to a skill, instead of changing the design, isn't a review. It is a log. The single point of failure in my agent organisation is not a model. It is me. | | AUTHOR: Has the keyring problem been fixed by the time of publication, and if so, how? If it hasn't, say why honestly. Either way, a sentence on how it felt to find yourself as the single point of failure in a system you designed would land the chapter. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | The test of a Blueprint is the one this book started with, after Gerber's franchise prototype: could the organisation be stood up again tomorrow from what is written down?\\] Every role has a charter and a sponsor. Every procedure is a Playbook someone maintains. Every promise is in a ledger, checked against evidence. Every recurring failure has a system fix and a date to check it, in the spirit of Gawande's checklists: the expert's knowledge of what goes wrong, written where the next person will see it.\\] And nothing waits for you to unlock it. When that is true, your job is what it should be. You decide what the organisation is for. You design the roles and set the standards. You make the calls that can't be undone. You keep the Blueprint current as the models change. And you spend the rest of your time on the work only a person can do: talking to customers, building trust with your team, and deciding where to go next. | | AUTHOR: What does "finished" look like for CorralData, in your own words? One paragraph on the organisation you are building towards, people and agents together, would make a fitting close to the book. | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | Try this Peter Drucker's advice to executives began with a record of where their time actually goes, not where they think it goes.\\] Do the agent-era version. List everything you did last week: meetings, messages, documents, tasks you did yourself or through an agent. Your calendar and sent items will get you most of the way. Paste the list into Claude, ChatGPT or Grok and ask it to tag each item as Shape (designing the organisation), Steer (keeping it to standard) or Do (the work itself), and to add up the hours in each. Take the three biggest Do items. For each, name the role on your chart that should own it. If no role exists, write its outcome line, starting "To...". Ask the assistant: "Which of these items could a role I already have do, if it had a better charter or Playbook?" Repeat it in a month and compare the numbers. That is the first entry on your own Scorecard. | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- Agents have made it cheap to add workers and no easier to build an organisation. That has been the argument from the first page. The answer was never a better model or a cleverer tool. It was the oldest discipline in management, applied to a new kind of worker: decide what the organisation is for, design the roles that deliver it, write down what each one owes, check it against evidence, fix the system when it fails, and put people where the decisions can't be undone. None of it requires you to be technical. All of it requires you to stop doing the work and start designing the organisation that does it. The time to start is now, while the window is open and the organisation is still small enough to redraw. The appendices are where you begin: [Appendix A](appendix-a-first-thirty-days.html) gives a week-by-week build order for your first thirty days, [Appendix B](appendix-b-templates.html) holds the templates, and [Appendix C](appendix-c-worked-example.html) shows one function run end to end by people and agents. ## Frequently Asked Questions 1. _What is a leader's job when AI agents do most of the work?_ Shape work: deciding what the organisation is for, designing the roles that deliver it, setting the standards each role must meet, and owning the decisions that can't be undone. Agents and people do the Steer and Do work inside that design. The leader's measure stops being personal output and becomes the consistency of the organisation's results. A useful test is the question to ask every agent and report: what can you do automatically, and what decisions do you need from me? The second list is your job. 2. _How do you stop doing the work yourself when an AI agent makes it so easy?_ Recognise that agents make doing feel free when it isn't. When a leader does the work through an agent, they bypass the role that owns it, collide with the people already doing it, and skip the gates that work would normally face. Before acting, ask which role on the chart owns the outcome. If one does, send it a request with the what and why. If none does, you have found a gap in the chart: fill it rather than doing the work yourself. 3. _How often should you review an organisation of people and agents?_ Run a light weekly rhythm and a heavier one at each model release. Weekly, read the Commitment Ledger's exceptions and decisions and run at least one Friction Review. Monthly, review each role against its Scorecard numbers and decide on promotions to more autonomy. Quarterly, revisit the Aim, the Destination and the finished org chart. Whenever a significantly better model arrives, review every lock-in: scripts and hard rules that were added because an older model couldn't cope may now be holding the new one back. 4. _Do small companies really have an advantage with AI agents?_ They have a temporary one. Every company can buy the same models, so access isn't the advantage. The advantage is how fast an organisation can redesign itself around them, and small organisations have fewer roles, fewer approvals and fewer legacy systems to change. That speed only pays off with design: research shows that agents working without a coordinator amplify one another's errors far more than coordinated ones. Small teams that move fast without structure just make mistakes faster. 5. _How do you know your organisation of people and agents is finished?_ It's never finished, but it's working when it would run the same way without you. The test is the Blueprint: could the organisation be stood up again tomorrow from what is written down? Every role has a charter and a named owner, every procedure is a Playbook someone maintains, every commitment is in a ledger, and no system waits for one person to unlock it. When your own absence no longer stops anything, your job has become what it should be. ## References . Gerber, M. E. (1995). _The E-Myth revisited: Why most small businesses don't work and what to do about it_. HarperCollins. . Grove, A. S. (1983). _High output management_. Random House. . Drucker, P. F. (1967). _The effective executive_. Harper & Row. . Martin, L. (2026, November 6). The components of agent memory. _Anthropic Engineering_. . Deming, W. E. (1986). _Out of the crisis_. MIT Press. . Grace, M., Hadfield, J., Olivares, R., & De Jonghe, J. (2026, January 9). Demystifying evals for AI agents. _Anthropic Engineering_. . Cemri, M., et al. (2025). Why do multi-agent LLM systems fail? arXiv:2503.13657\. . Microsoft. (2026, updated September 3). Administrative relationships in Microsoft Entra Agent ID (owners, sponsors, and managers). _Microsoft Learn_. . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic Engineering_. . Anthropic. (n.d.). Best practices for Claude Code. _Claude Code Docs_. Retrieved November 6, 2026, from . Schmid, P. (2026, January 5). The importance of Agent Harness in 2026\. _philschmid.de_. . OpenAI. (2026). Deprecations. _OpenAI API documentation_. . Carlini, N. (2026, February 5). Building a C compiler with a team of parallel Claudes. _Anthropic Engineering_. . Skelton, M., & Pais, M. (2019). _Team topologies: Organizing business and technology teams for fast flow_. IT Revolution. . Gawande, A. (2009). _The checklist manifesto: How to get things right_. Metropolitan Books. ## Appendices Appendix A: The First Thirty Days ==================== _A build order from your first agent to a full Blueprint_ This appendix turns the book into a build order. It is written for a leader who has used Claude, ChatGPT or Grok for months, has perhaps built an agent or two, and now wants to do it properly without hiring an engineer first. It covers one function, start to finish, in thirty days. By the end you will have a small Blueprint: one part of your organisation documented well enough that someone else could stand it up again tomorrow.\\] The order matters more than the speed. Each week builds on the one before: purpose before roles, roles before agents, charters before autonomy. The most common mistake is to reverse it, build an agent because it's easy, and work out what it's for afterwards. That is how organisations end up with an agent quietly doing six jobs and two bots competing for one ([Chapter 2](2-systems-run-the-business.html)). Three rules hold for the whole month: * **Work in public.** Every request to and from an agent goes through a shared channel, not a direct message ([Chapter 15](15-work-in-public.html)). * **Drafts first.** Nothing an agent does reaches a customer, moves money or deletes anything without a human decision until it has earned that right with evidence ([Chapter 14](14-humans-at-the-irreversible-points.html)). * **No second agent until the first has a charter.** Every agent fills a role on a chart you have drawn ([Chapter 5](5-hire-the-role-not-the-model.html)). ## Before you start Pick one function. Good first candidates have three things in common: the work is frequent, its results can be counted, and its mistakes can be undone. Customer success, operations reporting, recruiting coordination and accounts receivable all usually qualify. Avoid starting anywhere a single error is expensive or public, such as payroll, pricing or legal commitments. Name the sponsor: the one person accountable for the agents in this function, their purpose and their results ([Chapter 7](7-every-agent-needs-a-sponsor.html)). If you lead the function, it is you. If someone else does, it is them, and your role is to support them. Checklist * One function chosen, and the reason written down * A sponsor named for that function's agents * A shared channel created for the function's people and agents * Time blocked: about three hours a week for the sponsor, one hour for you if you aren't the sponsor ## Week 1 (Days 1--7): Know what it's for The first week produces no agents. It produces the four short documents every later decision will be measured against ([Chapter 4](4-know-what-its-for.html)). **The Aim.** One paragraph on what this function is for, for you and for the organisation. Not a slogan; something you could use to settle an argument. **The Destination.** What "finished" looks like for the function in twelve to eighteen months, including the mix of people and agents. Write it as if describing the function to a new hire on their first day. **The Scorecard.** Three to five numbers that say the function is working. At least one should measure quality from the customer's side, and at least one should measure how much human time the function takes. Record today's value for each. A number without a baseline can't tell you whether anything you do this month helped. **The Story.** A short paragraph on why the work matters, written so that a person or an agent could make a sensible call from it when the Playbook runs out. Then take an agent census. Ask everyone in the function, and anyone who touches it, which agents, bots, custom assistants or scheduled automations they use for its work. People are often surprised by the answer. | Agent and what it does | Who built it | Whose account it acts through | What it can access | Overlaps with | | ---------------------------------------------------------- | ----------------- | ----------------------------- | ---------------------- | ----------------------- | | _e.g. "Renewals helper" in ChatGPT: drafts renewal emails_ | _Account manager_ | _Her own email_ | _Customer list export_ | _CEO's "follow-up bot"_ | The census will turn up three kinds of problem: agents acting through one person's login, agents with more access than their task needs, and two agents doing the same job. Don't fix them yet. Write them down; they become your first Agentic Resources decisions in week four. Checklist * Aim written (one paragraph) * Destination written (one page at most) * Scorecard of three to five numbers, each with today's baseline * Story written (one paragraph) * Agent census complete, with identity, access and overlap problems listed ## Week 2 (Days 8--14): Draw the chart and fill the first role Draw the finished org chart of roles for the function, not the people and agents you have today ([Chapter 3](3-draw-the-finished-org-chart.html)). Each box is a role with a one-sentence outcome line starting "To...". Only then write each role's current occupant underneath: a person, an agent, a person and an agent, or "vacant". One occupant can hold several roles, and a role can be vacant for months. Check each role against the role coherence test: the kind of work, the level of judgment it needs, and the available occupants should be consistent within it ([Chapter 5](5-hire-the-role-not-the-model.html)). A role that mixes routine drafting with decisions about refunds will fail whoever holds it. Split it. Choose the first role to fill with an agent. Pick the one with the most volume, the clearest standard and the lowest cost of a mistake. Then write its four documents. **The Role Charter** ([Chapter 9](9-one-page-per-job.html)). The outcome line; the work; the standards for quantity, quality and behaviour; how acceptance is checked; who the role reports to; who sponsors its occupant; and what it may and may not do on its own. Keep it to a page. **The Playbook** ([Chapter 10](10-bet-on-plain-english.html)). The procedure for the role's main piece of work, in plain English, with the reason for each rule. Write it as an onboarding guide for a capable new hire, which is how Anthropic's engineers describe a good skill for an agent.\\] Describe the outcome and the checks, not every step ([Chapter 8](8-what-and-why-never-how.html)). **The Role Pack** ([Chapter 12](12-everything-they-need-on-day-one.html)). Everything the occupant needs on day one: the charter, the Playbook, the Story, the definitions of any numbers it reports, examples of good and bad work, and who to ask. Keep it lean. Link to detail rather than pasting it in. **The identity.** Give the agent its own name and, wherever your tools allow, its own account. Anything it writes should say it was drafted by an agent and name the sponsor. An agent speaking through a person's login is a person's signature on work they didn't check. Now start the agent in draft-only mode. It does the work; a person reviews every draft and sends, approves or corrects it. Log each correction in one line: what was wrong and what the right answer was. The log is the most valuable thing you will produce this month. Checklist * Finished org chart of roles for the function, with outcome lines and current occupants * Every role passes the role coherence test, or has been split * First role chosen, with its Role Charter, Playbook and Role Pack written * The agent has its own name and identity, and its output is labelled as agent-drafted * Access limited to what the role's work needs, and nothing more * Agent running in draft-only mode, with a correction log | | AUTHOR: Looking back at how agents arrived at CorralData, which of these week-two steps would have saved the most trouble if you had done it first? One specific example would show the reader why the order matters. | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Week 3 (Days 15--21): Run it in public and track what's owed Set up the Commitment Ledger for the role ([Chapter 13](13-track-whats-owed.html)). It is a list, in a shared document or ticket board, of everything the role has promised: each recurring report, each open request, each follow-up. Each entry has an owner, a due date and the evidence that will show it is done. "I sent it" is not evidence; the sent message is. The agent checks the ledger on a schedule and reports two things to the sponsor: what needs a decision, and what will slip. Treat "will slip" as a call to act, not a status note. Hold the line on public work. Requests to the agent go through the shared channel, tagged so the agent is woken and the request is tracked. If someone sends a request privately, move it into the channel and say why. Agents that wake only when tagged will leave untagged messages unanswered; the fix is a habit and, later, a rule, not a reprimand. At the end of the week, run your first Friction Review ([Chapter 16](16-the-model-isnt-the-problem.html)). Take the most frequent correction in the log and ask what the system was missing: a definition, a rule, a check, an example. Fix it for the whole class of error, not just the last instance. Then decide which tier the fix belongs in ([Chapter 11](11-lock-in-only-what-cant-go-wrong.html)): | Tier | Use it for | Example | | ------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------- | | Plain-English Playbook | Judgment, preferences, procedure (the default) | "Lead with the answer; put the detail underneath." | | Script | Calculations and lookups that must give the same answer every time | Working out a customer's usage figure from the raw data | | Hard rule the software enforces | Things that can't be undone, security, and the acceptance check | No message reaches a customer without a human approval | Add each corrected case to a short list of test examples. Anthropic's guidance on testing agents says "20-50 simple tasks drawn from real failures is a great start."\\] By day thirty you won't have fifty, but you will have the habit. Checklist * Commitment Ledger set up, with owner, due date and evidence for each entry * Agent reports decisions needed and likely slips to the sponsor on a schedule * All requests to the agent go through the shared channel, tagged * Scorecard numbers updated weekly against the baseline * First Friction Review run, with the fix placed in the right tier * A short list of test examples started from real corrections ## Week 4 (Days 22--30): Earn autonomy and make it repeatable **Promote with evidence.** Set the promotion bar before you look at the results: for example, seven consecutive days of drafts in which fewer than one in ten needed a material correction. If the agent meets it, promote one lane of its work from "draft only" to "act, then report", and keep the rest in draft. If it doesn't, keep going. Don't shorten the bar because the early numbers look good; that is the commonest way a leader undoes a month of careful work. **Put people only where they matter.** Anthropic found that people approved 93% of its coding agent's permission prompts.\\] An approval step that is nearly always waved through is theatre. As the agent earns autonomy, remove the approvals that no longer change anything and keep, or harden, the ones at the irreversible points. **Fill the second role.** Go back to the chart. Often the same agent can hold a second role with its own charter, Playbook and ledger. Use a second agent only when the work is genuinely parallel or needs different access. **Name an Agentic Resources owner** ([Chapter 17](17-agentic-resources.html)). One person, part-time, who keeps the register of every agent in the organisation: its roles, sponsor, identity, access, autonomy level and date of last review. Their first job is the census list from week one: give each orphaned agent a sponsor, merge or retire duplicates, and move any agent acting through a person's login onto its own identity. Retire carefully. Run the old and new side by side before switching anything off, and keep what the old one learned. **Run the Blueprint test.** Give the function's documents to someone who wasn't involved and ask: could you run this function next week from these alone? Every question they ask is a gap to fill. Checklist * Promotion bar written before results were reviewed * One lane promoted on evidence, or a clear reason recorded for waiting * Approvals that never change anything removed; irreversible points protected by a human or a hard rule * Second role filled, by the same agent with its own charter or by a justified second agent * Agentic Resources owner named and the agent register started * Every agent in the census has a sponsor, its own identity and least-privilege access, or is retired * Blueprint test run, with gaps listed ## End of day thirty You should have: * An Aim, Destination, Scorecard and Story for one function * A finished org chart of roles for that function, with outcome lines * Two roles filled, each with a Role Charter, Playbook, Role Pack and Commitment Ledger * A correction log, at least two completed Friction Reviews and a small set of test examples * At least one lane of work promoted on evidence, with hard rules at the irreversible points * A named sponsor for every agent and an Agentic Resources owner for the whole workforce * A Scorecard that shows, against the baseline, whether any of this helped If the Scorecard hasn't moved, that is information, not failure. Run a Friction Review on the function itself: was the role the right one, the standard the right one, the bar too low or too high? ## Days 31--90: what comes next Repeat the build order for the next function, faster, reusing the templates in [Appendix B](appendix-b-templates.html). Settle into the leader's rhythm from [Chapter 20](20-your-job-now.html): the ledger's exceptions and one Friction Review each week, a review of each role against its Scorecard each month, the Aim and the chart each quarter, and a review of every lock-in whenever a significantly better model arrives. When individual contributors start building their own agents, offer them the renegotiated deal in [Chapter 19](19-from-doing-to-delegating.html) before the agents multiply. --- _This build order compresses the whole book into one month for one function. For a complete example of where it leads, see [Appendix C](appendix-c-worked-example.html), which follows a fictional company's customer success function through every document named here. The checklists give you the order. The chapters give you the reasons._ ## Frequently Asked Questions 1. _Where should a small company start with AI agents?_ Start with one function, not the whole company, and one role inside it. Choose work that is frequent, measurable and easy to undo: drafting customer replies, preparing weekly reports, triaging a queue. Before building anything, write down what the function is for and the three to five numbers that say it's working, then take a census of the agents people are already using. The first agent you add should fill a role on a chart you've drawn, not the other way round. 2. _How long does it take to set up an AI agent properly?_ A first role can be drafting real work within two weeks: one week to set the aim, take a census and draw the chart, one week to write the Role Charter and Playbook and start the agent in draft-only mode. Earning autonomy takes longer, because it depends on evidence. Set the bar in advance, for example seven days of drafts with few corrections, and don't shorten it because the early results look good. Thirty days is enough for one function done properly. 3. _When should an AI agent be allowed to act without human approval?_ When it has met an evidence bar you set before it started, and only for actions that can be undone. Run the agent in draft-only mode first, log every human correction, and promote it one lane at a time once corrections fall below the agreed level over the agreed period. Actions that can't be undone, such as sending money, deleting data or making commitments to customers, keep a human decision or a hard rule the software enforces, however good the agent becomes. 4. _What should I check before adding a second AI agent?_ Check that the first one has a written charter, a named sponsor, a Playbook, a Commitment Ledger and at least one completed Friction Review. Then ask whether you need a second agent at all: often the same agent can hold a second role with its own charter. Add a separate agent when the work is genuinely parallel or needs different access, and make sure its role doesn't overlap an existing one, or you'll end up with two bots competing for the same job. 5. _Who should own AI agents in a small company?_ Two kinds of owner. Each agent needs a sponsor: the person accountable for its purpose and results, usually the leader of the function it works in. The agent workforce as a whole needs an Agentic Resources owner: one person, part-time at first, who keeps the register of agents, runs onboarding, reviews performance, approves promotions to more autonomy and retires duplicates. Neither should be the person who happened to build the agent, unless that person also owns the work. ## References . Gerber, M. E. (1995). _The E-Myth revisited: Why most small businesses don't work and what to do about it_. HarperCollins. . Zhang, B., Lazuka, K., & Murag, M. (2025, October 16). Equipping agents for the real world with Agent Skills. _Anthropic Engineering_. . Grace, M., Hadfield, J., Olivares, R., & De Jonghe, J. (2026, January 9). Demystifying evals for AI agents. _Anthropic Engineering_. . Hughes, J. (2026, March 25). How we built Claude Code auto mode. _Anthropic Engineering_. Appendix B: Templates ==================== _Role Charter, Playbook, Role Pack, Commitment Ledger, Friction Review_ These templates are the paperwork of the book: the documents that turn an idea in a chapter into something a person or an agent can act on tomorrow morning. Each one has a short note on how to use it, a blank version you can copy into a document or paste into Claude, ChatGPT or Grok, and a filled-in example. The examples all come from one fictional company, so you can see how the documents connect. **Larkspur Supply** is a 22-person distributor of dental consumables. It has a founder-CEO, an operations lead, a finance lead, a small sales team, a warehouse crew, and a growing set of agents in its team chat. The company, people and figures are invented. Two rules apply to every template. First, write results, not steps, wherever you can; the steps belong in Playbooks, and the Playbook belongs to the role ([Chapter 8](8-what-and-why-never-how.html)). Second, every document has an owner and a review date. A template nobody owns drifts as surely as a skill nobody owns ([Chapter 12](12-everything-they-need-on-day-one.html)). A useful habit: paste a blank template into your AI app with the instruction "Interview me one question at a time to fill this in. Push back where my answers are vague." You will get a better first draft than if you fill it in alone. ## Role Charter **How to use it.** One charter per role, not per occupant. If one agent holds three roles, it has three charters; if a person and an agent share a role, they share one. Write the outcome line first and spend the most time on it: it should say why the role exists in a sentence that starts "To...". Then write acceptance before you write the work, because how you will check the result shapes what you ask for. Run the role coherence test at the end: are the kind of work, the level of judgment and the available occupants consistent? If not, split the role. Chapters: [5](5-hire-the-role-not-the-model.html) and [9](9-one-page-per-job.html). ```text ROLE CHARTER Role: [name of the position, not the occupant] Outcome line: To [result], so that [why it matters]. Reports to: [the role this one answers to] Sponsor: [the human accountable for this role's agents] Current occupant(s): [person / agent / both] Owns or serves: [Owns its answers | Serves another role: which] THE WORK (results this role produces) 1. 2. 3. STANDARDS Quantity: [how much, how often, by when] Quality: [what "good" looks like; error tolerance] Behaviour: [tone, disclosure, how it treats colleagues and customers] AUTHORITY May do alone: Must ask first (whom): Must never do: ACCEPTANCE How the result is checked: Who or what checks it: [person / test / independent reviewer] Evidence required: [link, record, screenshot from a human] HANDOFFS Receives work from: Hands work to: Escalates to (and when): Role Pack: [link] Charter owner: [name of role] Last reviewed: [date] Coherence check: Same kind of work? Same level of judgment? Same available occupants? [Y/N each] ``` **Example.** Larkspur's collections work used to sit with the finance lead, who chased overdue invoices on Friday afternoons when she remembered. The charter below moved it to a role, filled by an agent with the finance lead as sponsor. ```text ROLE CHARTER Role: Collections Clerk Outcome line: To turn overdue invoices into paid invoices without damaging a customer relationship, so that cash arrives when the forecast says it will. Reports to: Finance Lead Sponsor: Finance Lead Current occupant(s): Ledger Bot (agent) Owns or serves: Owns its answers THE WORK 1. Every overdue invoice has a current status and a next step. 2. Customers hear from us before day 15 overdue, politely and accurately. 3. Disputes reach the account owner in sales within one working day. STANDARDS Quantity: Every invoice over 7 days overdue reviewed each weekday by 10:00. Quality: Zero reminders sent for invoices already paid or credited. Amounts and dates match the accounting system exactly. Behaviour: Signs every message "Ledger Bot, Larkspur Accounts, on behalf of [Finance Lead]". Never threatens. Never discusses another customer. AUTHORITY May do alone: Draft reminders; post status to #finance; open dispute tickets. Must ask first: Send any reminder (Finance Lead approves in #finance during the first 30 days; see Agentic Resources review). Must never do: Change an invoice, issue a credit, promise a payment plan, or contact a customer marked "account hold". ACCEPTANCE Checked by: Weekly sample of 10 reminders reviewed by Finance Lead. Evidence: Each reminder links to the invoice record it used, pulled at send time. HANDOFFS Receives: Invoice list from the accounting system (live). Hands to: Account owner in Sales (disputes), Finance Lead (write-offs). Escalates: Anything over £5,000, or any customer reply that is angry. Role Pack: /roles/collections-clerk/ Charter owner: Finance Lead Last reviewed: 2026-11-03 Coherence: Y / Y / Y ``` ## Playbook **How to use it.** A Playbook is a documented procedure for one recurring piece of work, written in plain English for a capable newcomer. Give the reason for each step; an occupant that knows why can handle the case you did not foresee. Then mark every step with its tier from [Chapter 11](11-lock-in-only-what-cant-go-wrong.html): | Marker | Tier | Use it when | | ------ | --------- | ---------------------------------------------------------------------------------------------------------------- | | \[E\] | English | The step needs judgment, tone or adaptation. This is the default. | | \[S\] | Script | The step is a calculation, lookup or check that must give the same answer every time. | | \[H\] | Hard rule | The step is irreversible or a security boundary, and the software must enforce it whatever the occupant decides. | If more than a few steps are `[H]`, you are probably encoding preferences as rules. Record the date and reason next to every `[S]` and `[H]` step so you can review it when the models improve. ```text PLAYBOOK Name: [verb + object, e.g. "Chase an overdue invoice"] Owning role: [role] Trigger: [schedule or event] Purpose: [one sentence: what this achieves and why] Done means: [the checkable end state] STEPS 1. [E|S|H] [what to do] Why: [the reason] 2. [E|S|H] Why: ... IF THINGS GO WRONG - [situation] -> [what to do, whom to tell] LOCK-IN LOG [date] Step [n] moved to [S|H] because [reason]. Review at next model change. Owner: [role] Last reviewed: [date] ``` **Example.** ```text PLAYBOOK Name: Chase an overdue invoice Owning role: Collections Clerk Trigger: Weekdays 09:00 Purpose: Get paid on time while keeping the customer glad to order again. Done means: Each invoice over 7 days overdue has a reminder sent or a recorded reason for not sending, by 10:00. STEPS 1. [S] Pull the overdue list live from the accounting system. Why: copies go stale; we once chased an invoice paid the day before. 2. [S] Remove invoices that are paid, credited, disputed or on hold. Why: this is a fact check, not a judgment, so it must be identical every time. 3. [E] For each remaining invoice, read the last three messages with the customer and decide on tone: first reminder, firm reminder, or phone call needed. Why: a customer who has just complained about a late delivery needs a different note from one who forgets every month. 4. [E] Draft the reminder. Plain language, the amount, the invoice number and title, how to pay, and a named human to contact. Why: a bare invoice number makes customers dig; the title saves them. 5. [H] Sending requires the Finance Lead's approval in #finance. Why: a wrong reminder to a customer cannot be unsent. 6. [S] Log the action and the evidence link in the Commitment Ledger. Why: the weekly review samples from the ledger, not from memory. IF THINGS GO WRONG - Customer disputes the amount -> stop, open a dispute ticket, tag the account owner in Sales in #finance. - Accounting system unreachable -> send nothing; post in #finance. LOCK-IN LOG 2026-10-21 Step 2 moved to [S] after a reminder went to a customer whose credit note was in the system (Friction Review FR-07). 2026-10-01 Step 5 set to [H] for the first 30 days. Review 2026-11-01. Owner: Finance Lead Last reviewed: 2026-11-03 ``` ## Role Pack Index **How to use it.** The Role Pack is everything a role's occupant needs to know ([Chapter 12](12-everything-they-need-on-day-one.html)). The index is its front page: a short list of what is always loaded, what to fetch when needed, and where the live truth lives. Keep the always-loaded part brief; link to the rest. Every rule carries its reason. List what is deliberately **not** in the pack, so nobody copies it in later. ```text ROLE PACK INDEX: [role] ALWAYS LOADED (keep it under a page) - Role Charter: [link] - The Story, in brief: [two or three sentences from the company story] - Rules that matter most, with reasons: 1. [rule] because [reason] 2. 3. LOAD WHEN NEEDED - Playbooks: [links] - Templates and examples: [links] - Reference: [policies, price lists, glossaries] LIVE SOURCES (trust these over any copy) - [system]: [what it is the truth for] LESSONS LEARNED (dated; merge into Playbooks or delete at review) - [date] [lesson] (source: [link]) NOT IN THIS PACK, ON PURPOSE - [item] because [reason] Pack owner: [role] Last reviewed: [date] Next review: [date] ``` **Example.** ```text ROLE PACK INDEX: Collections Clerk ALWAYS LOADED - Role Charter: /roles/collections-clerk/charter - The Story, in brief: Larkspur exists so that small dental practices never run out of what they need mid-week. We are the supplier who picks up the phone. Collections should sound like that too. - Rules that matter most: 1. Pull figures live at send time, because copies go stale. 2. Never contact an "account hold" customer, because those are in legal or commercial negotiation and one message can undo it. 3. Sign every message as Ledger Bot, because customers have a right to know when they are talking to an agent. LOAD WHEN NEEDED - Playbooks: Chase an overdue invoice; Log a dispute; Month-end summary - Templates: First reminder, Firm reminder, Dispute acknowledgement - Reference: Payment terms policy (v3), Customer tiers list LIVE SOURCES - Accounting system: invoice status, credits, payments - CRM: account owner, account hold flag - #finance channel: approvals and escalations LESSONS LEARNED - 2026-10-14 Practices close on Wednesday afternoons in two regions; don't send then. (source: thread in #finance) NOT IN THIS PACK, ON PURPOSE - Sales pipeline and pricing negotiations, because collections must not trade discounts for payment. Pack owner: Finance Lead Last reviewed: 2026-11-03 Next: 2026-12-01 ``` ## Commitment Ledger **How to use it.** The ledger tracks what each role owes, not what it has done ([Chapter 13](13-track-whats-owed.html)). One row per promise, whoever made it: a person in a meeting, an agent in a channel, a role on a schedule. The rule that makes it work is that "done" needs evidence someone else can check. A draft is not evidence. An agent saying "done" is not evidence. Review the ledger on a fixed schedule, and lead every review with the rows that need a decision. | Column | Meaning | Column | Meaning | | ---------- | --------------------------------- | -------- | -------------------------------- | | ID | Short unique reference | Due | Date owed | | Owed by | The role (and current occupant) | Status | From the vocabulary below | | Owed to | Who is waiting | Evidence | Link a person or test can check | | Commitment | What was promised, in one line | Next | The next action and who takes it | | Source | Where the promise was made (link) | | | __Table 1\. Status vocabulary__ | Status | Meaning and rule | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | OPEN | Recorded, not started. Must have an owner and a due date within a day of being recorded. | | ON TRACK | In progress and expected on time. The owner can say why, with reference to similar past work. | | AT RISK | Might slip. State what would bring it back. | | WILL SLIP | Will miss the date. This is an intervention trigger, not a status note: it goes to the top of the next review for a decision. | | BLOCKED | Cannot proceed without someone else. Name them and what is needed. | | DONE | Delivered, with an evidence link. Only the person or check named in acceptance may set this. | | RELEASED | No longer owed, by agreement: handed to another role, declined as "not my call", or cancelled by the person it was owed to. Not the same as done. | ```text ID | Owed by | Owed to | Commitment | Source | Due | Status | Evidence | Next ``` **Example.** | ID | Owed by | Owed to | Commitment | Due | Status | Evidence / Next | | ----- | ------------------------------ | ---------------------------- | ----------------------------------------------------- | ------ | --------- | ---------------------------------------------------- | | C-112 | Collections Clerk (Ledger Bot) | Finance Lead | Weekly overdue summary for Monday finance meeting | 10 Nov | ON TRACK | Draft due Fri; three prior summaries on time | | C-113 | Ops Lead | Customer (practice in Leeds) | Replacement order for damaged delivery | 7 Nov | DONE | Courier proof of delivery, linked | | C-114 | Sales Account Owner | Collections Clerk | Confirm whether £2,300 disputed invoice is valid | 6 Nov | WILL SLIP | Owner on leave; decision needed: reassign or extend? | | C-115 | Order Desk (Order Bot) | CEO | "Look into" bulk discount request from group practice | -- | RELEASED | Not the Order Desk's call; moved to Sales as C-116 | Note C-115: the CEO asked an agent to "look into" a pricing decision. The agent's charter does not include pricing, so the right status is `RELEASED` with a handoff, not `DONE` and not left open. ## Friction Review **How to use it.** Run one whenever the same kind of thing goes wrong twice, or anything goes wrong once at an irreversible point ([Chapter 16](16-the-model-isnt-the-problem.html)). The aim is a system fix, so two root causes are not accepted on their own: "the model made a mistake" and "someone forgot". Both may be true; neither is a fix. Keep it to a page, write it in a public channel or shared document, and do not close it until the check you added has passed for a stated period. ```text FRICTION REVIEW FR-[number] Raised by: [name of role] Date: Severity: [irreversible | customer-visible | internal] WHAT HAPPENED (facts and links only) WHAT SHOULD HAVE HAPPENED IMPACT ONE-OFF OR CLASS? [Could the same thing happen elsewhere? Where?] WHERE THE SYSTEM HAS A GAP (tick all that apply) [ ] No playbook, or the playbook is silent on this case [ ] Rule in the wrong tier (English where it needed a script or hard rule, or a hard rule that should be judgment) [ ] Missing or weak acceptance check [ ] Stale or missing information in the Role Pack [ ] No owner, or the owner didn't know [ ] Two principals giving conflicting instructions [ ] Too much access, or too little [ ] Genuine capability limit of the current occupant Explanation: THE FIX Change: [what changes in the system] Tier: [E | S | H] Test from this failure: [the case that will catch it next time] Fix owner: [role] Due: CLOSED WHEN [The check that proves it stays fixed, and for how long] Closed on: [date] Lesson saved to: [Playbook / Role Pack link] ``` **Example.** ```text FRICTION REVIEW FR-07 Raised by: Finance Lead Date: 2026-10-20 Severity: Customer-visible WHAT HAPPENED Ledger Bot drafted a firm reminder to a practice for £840. The Finance Lead approved it without opening the record. The practice had been issued a credit note for the full amount on 16 Oct. The practice manager replied, annoyed, in a thread that was then forwarded to the CEO. WHAT SHOULD HAVE HAPPENED The invoice should have been excluded as credited. IMPACT One irritated customer; one apology call by the CEO. ONE-OFF OR CLASS? Class. Any invoice credited after the morning list was built could be chased. Two more found in the last month, both caught by luck. WHERE THE SYSTEM HAS A GAP [x] Rule in the wrong tier: "check for credits" was an English step the agent did from a list exported at 07:00. [x] Missing or weak acceptance check: approval was a glance, not a check. Explanation: The approval step gave a feeling of safety that wasn't there. Approvals ran at 100% for three weeks. THE FIX Change: Exclusions (paid, credited, disputed, on hold) become a script that runs against the live system at send time, and the approval card shows the live status beside the draft. Tier: S Test: Five historic invoices credited between list and send time, added to the weekly test set; all must be excluded. Owner: Ops Lead (systems) Due: 2026-10-24 CLOSED WHEN Zero reminders on paid or credited invoices for 30 days, and the test set passes every week. Closed on: 2026-11-24 (planned) Lesson saved to: Playbook step 2 ``` ## Agent Onboarding and Offboarding Checklist **How to use it.** This is the Agentic Resources checklist from [Chapter 17](17-agentic-resources.html): what the function (a person, a bot, or both) confirms when an agent joins a role, changes autonomy, or leaves. Use the same checklist when a role moves to a new model; that is an offboarding and an onboarding at once. Do it in a public channel, so the team sees who has joined and what it is allowed to do. ```text AGENT ONBOARDING Agent: Role: Sponsor: Date: BEFORE IT STARTS [ ] Role Charter written and approved by the role's manager [ ] Sponsor named (one human, accountable for purpose and lifecycle) [ ] Checked for an existing agent in the same role (no duplicates) [ ] Its own identity: own account, own name, never a person's login [ ] Disclosure signature set ("[Agent], on behalf of [role/sponsor]") [ ] Access granted: least needed for the charter, listed here: [ ] Role Pack loaded; nothing copied from another agent's memory [ ] Hard rules in place for the irreversible steps FIRST WEEKS [ ] Introduced in a public channel: what it does, whom to ask [ ] Shadow mode: drafts only, compared against human work [ ] Evidence bar for going live stated in advance: [e.g. 20 drafts, zero factual errors, 10 working days] [ ] Commitment Ledger rows created for its scheduled work [ ] Acceptance tests running AUTONOMY REVIEW (repeat for each step up) [ ] Evidence bar met, with links (not "it seems fine") [ ] Sponsor and role manager agree [ ] Change announced in the public channel [ ] Next review date: AGENT OFFBOARDING Agent: Role: Reason: Date: [ ] Successor named (agent, person, or role closed) [ ] Parallel run: both occupants on the same work for [period] [ ] Outgoing agent writes a handover brief for its successor [ ] Lessons learned merged into the Role Pack [ ] Open Commitment Ledger rows moved to the successor, by name [ ] Scheduled jobs moved or switched off [ ] Access and credentials revoked; identity disabled [ ] Memory and logs archived, not deleted; retention date set [ ] Departure announced in the public channel; org chart updated ``` **Example.** In October, Larkspur found it had two agents answering stock questions in team chat: one the CEO had set up, one the warehouse lead had built. They gave different answers about back-order dates. Agentic Resources (here, the operations lead with a checklist) ran the offboarding on the CEO's bot and the onboarding review on the warehouse lead's. ```text AGENT OFFBOARDING Agent: StockCheck (CEO's) Role: Stock Desk Reason: duplicate role Date: 2026-10-28 [x] Successor: Shelf Bot (sponsor: Warehouse Lead, closest to the work) [x] Parallel run: 5 working days, answers compared in #ops; Shelf Bot matched the warehouse system 41/41, StockCheck 36/41 [x] Handover brief: StockCheck listed the 12 customers who ask most, and the supplier whose dates are usually late [x] Lessons merged into Shelf Bot's Role Pack (2 of 3; third was wrong) [x] Open ledger rows: C-098, C-101 moved to Stock Desk (Shelf Bot) [x] Scheduled 08:00 stock digest moved to Shelf Bot [x] Access revoked; account disabled [x] Logs archived to /agents/archive/stockcheck/, keep until 2027-10-28 [x] Announced in #general: "Stock questions now go to Shelf Bot." ``` | | AUTHOR: Would you like one CorralData example alongside the fictional ones, such as a lightly redacted version of the Role Charter the Agentic Resources Bot drafted for TAM Bot? If so, it needs a permission check with our CEO and CS lead, since it records the Lane A disagreement. | | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- None of these documents is clever. Their value comes from being filled in, owned and reviewed. Start with one Role Charter for the agent that worries you most, and let the rest follow when you need them. [Appendix C](appendix-c-worked-example.html) shows a whole function run with them end to end, and [Appendix G](appendix-g-ai-org-design-advisor.html) gives you an advisor that will help you draft them. ## Frequently Asked Questions 1. _What should a job description for an AI agent include?_ The same things a good human job description includes, written as results rather than tasks. Start with a one-sentence outcome line beginning "To...", then the reporting line and the human sponsor, the work the role owns, standards for quantity, quality and behaviour, what the role may do alone, must ask about, and must never do, and how acceptance is checked with evidence. Add whether the role owns its answers or serves another role. Keep it to one page so the agent and its manager can both read it. 2. _How do I write a playbook an AI agent can follow?_ Write it in plain English, as you would for a capable new hire, and give the reason behind each step. Then mark every step with a tier: English for steps that need judgment, script for calculations and lookups that must give the same answer every time, and hard rule for the few steps that are irreversible, such as sending to a customer or paying money. Keep hard rules rare. Most of a good playbook stays in English so the agent can adapt when circumstances change. 3. _How do you track what AI agents have promised to do?_ Keep a Commitment Ledger: one row per promise, with who owes it, who it is owed to, where it was made, the due date, a status and a link to evidence. Use a small fixed set of statuses, and make "done" require evidence that a person or test can check, not the agent's word. Treat "will slip" as a trigger for a decision rather than a status update, and review the ledger on a schedule so nothing sits open without an owner. 4. _How do you run a post-mortem when an AI agent makes a mistake?_ Run a Friction Review. Record what happened with links, what should have happened, and the impact. Ask whether it was a one-off or a class of error. Then find the gap in the system, such as a missing playbook step, a rule in the wrong tier, a missing check, an unclear owner or conflicting instructions. "The model got it wrong" is not an acceptable root cause. Fix the system, add a test built from this failure, name an owner and a date, and check that it stays fixed. 5. _What is the checklist for onboarding or retiring an AI agent?_ To onboard, approve the Role Charter, name a sponsor, give the agent its own identity and the least access the role needs, load its Role Pack, introduce it in a public channel, and run it in shadow mode against a stated evidence bar before it acts alone. To retire it, name a successor, run both in parallel, have the outgoing agent write a handover brief, move its open commitments, revoke its access, and archive rather than delete its memory and logs. Appendix C: A Worked Example ==================== _One function run end to end by people and agents_ This appendix follows one function, customer success, through every document the book describes. The company, **Kettlebrook**, is a fictional composite. It is informed by CorralData and the other organisations in this book, but its people, customers, numbers and events are invented for illustration, and any resemblance to a real company of the same name is coincidental. It uses the templates in [Appendix B](appendix-b-templates.html) and the build order in [Appendix A](appendix-a-first-thirty-days.html). ## The company and the function Kettlebrook makes booking and reporting software for independent veterinary clinics. It has twenty-six people and about four hundred clinics. Customer success is a Head of Customer Success and two customer success managers, each looking after about two hundred clinics: answering questions, running onboarding, chasing renewals. Agents had already arrived. The CEO had a renewals assistant in a desktop app that drafted follow-ups from his own email account. One customer success manager had an assistant that summarised tickets. Nobody had decided what either was for, and the CEO's assistant sometimes emailed a clinic the same day its Account Owner did. ## Aim, Destination, Scorecard and Story The Head of Customer Success wrote these with the CEO in week one ([Chapter 4](4-know-what-its-for.html)). **Aim.** Customer success exists so that every clinic gets real value from Kettlebrook in its first ninety days and keeps getting it, so that clinics renew, recommend us, and never need to call a founder to get a problem fixed. **Destination (eighteen months).** Six hundred clinics served by the same three people and a small set of agents. Every question gets a correct first answer within two working hours. The Head of Customer Success spends half her week on Shape work: onboarding, Playbooks, product feedback. No agent ever sends from a person's account. **Scorecard.** | Number | Baseline | Target (12 months) | | ------------------------------------------------------------------ | ------------ | ------------------ | | Revenue kept from existing clinics, year on year | 90% | 95% | | Median working hours to a correct first answer | 9 | 2 | | Share of customer-bound agent drafts needing a material correction | Not measured | Under 5% | | Share of the Head of Customer Success's week spent on Shape work | About 10% | 50% | **Story.** Clinics don't buy software; they buy time back from the front desk. When a clinic asks us something, a busy person is stuck, and a fast wrong answer costs them more than a slower right one. Be accurate first, then quick, and always say who you are. ## The org chart of roles The Head of Customer Success drew the finished chart first, then wrote the occupants underneath ([Chapter 3](3-draw-the-finished-org-chart.html)). There are two agents. **Kit**, a general agent, holds four roles, each with its own charter. **Proof** holds one, Draft Reviewer, because a checker shouldn't share the context of what it checks. | Role | Outcome line | Occupant | Reports to | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | ----------------------------- | | Head of Customer Success | To make every clinic successful with Kettlebrook, so that it renews and recommends us. | Person | CEO | | Account Owner (two portfolios) | To own each clinic's relationship and results, so that every clinic has one person who knows it and answers for it. | Two people | Head of Customer Success | | Customer Correspondent | To give clinics accurate, clear answers within two working hours, so that a stuck practice is unstuck fast. | Kit | Account Owner for that clinic | | Draft Reviewer | To check every customer-bound draft against its acceptance criteria before a person sees it, so that people review judgment, not typos. | Proof | Head of Customer Success | | Account Health Monitor | To spot clinics at risk early enough to help, so that no renewal is lost by surprise. | Kit | Head of Customer Success | | Commitment Clerk | To keep the customer success Commitment Ledger true, so that nothing promised to a clinic is forgotten. | Kit | Head of Customer Success | | Onboarding Guide | To get each new clinic to its first useful report within thirty days. | Kit (drafts) and Account Owners (calls) | Head of Customer Success | | Renewal Preparer | To prepare each renewal conversation sixty days ahead, so that Account Owners walk in with the facts. | Vacant: Account Owners cover until next quarter | Head of Customer Success | One role failed the role coherence test. The first draft had a "Customer Agent" that answered questions _and_ offered credits for outages. Answering is routine and reversible; credits are money and can't be taken back. Credits moved to the Account Owner ([Chapter 5](5-hire-the-role-not-the-model.html)). ## Role Charter: Customer Correspondent ```text ROLE CHARTER Role: Customer Correspondent Outcome line: To give clinics accurate, clear answers within two working hours, so that a stuck practice is unstuck fast. Reports to: Account Owner for the clinic Sponsor: Head of Customer Success Current occupant(s): Kit (agent) Owns or serves: Serves the Account Owner, who owns the relationship THE WORK 1. Every clinic question in the help desk or #cs-requests has a drafted answer within two working hours. 2. Answers about how to use the product are complete, with the steps and a link to the help article. 3. Answers about a clinic's own figures are checked against live data before they are drafted. STANDARDS Quantity: Every question triaged within 30 minutes during working hours; drafted within 2 working hours. Quality: Under 5% of drafts need a material correction (a wrong fact, figure or instruction). Zero answers that quote one clinic's data to another. Behaviour: Plain English, no jargon. Signs every message "Kit, Kettlebrook's customer success agent, with [Account Owner]". Says "I don't know yet" rather than guessing. AUTHORITY May do alone: Triage; draft; send how-to answers (Lane A, see promotion record); open product bug tickets. Must ask first: Any answer about the clinic's own figures, billing or contract (Account Owner approves). Must never do: Offer credits or discounts; change a clinic's settings; send from any person's account; discuss another clinic. ACCEPTANCE Checked by: Proof checks every draft against this charter and the Playbook; Account Owner approves Lane B. Head of CS reviews a sample of 15 sent messages each week. Evidence: Each figure in an answer links to the query result it came from, pulled at drafting time. HANDOFFS Receives: Questions from the help desk and #cs-requests (see FR-007). Hands to: Account Owner (Lane B, anything commercial); Engineering triage (bugs, as a ticket with what and why). Escalates: Cancellation, complaint or animal welfare: to the Account Owner within 15 minutes. Role Pack: /cs/roles/customer-correspondent/ Charter owner: Head of Customer Success Last reviewed: 2026-10-30 Coherence: Y / Y / Y ``` ## Role Charter: Account Owner The human role got a charter in the same format. Writing it forced the renegotiated deal of [Chapter 19](19-from-doing-to-delegating.html): the Account Owners hand drafting to Kit and own the specs and the verification. ```text ROLE CHARTER Role: Account Owner Outcome line: To own each clinic's relationship and results, so that every clinic has one person who knows it and answers for it. Reports to: Head of Customer Success Sponsor: n/a (human role) Current occupant(s): Two customer success managers, one portfolio each (about 200 clinics) Owns or serves: Owns the relationship and its answers THE WORK 1. Every clinic in the portfolio has a health status and a next step. 2. Every Lane B draft is approved, corrected or rejected within one working hour. 3. Each month, at least one correction pattern becomes a Playbook change or a Friction Review. STANDARDS Quantity: Lane B queue under one hour old, checked twice daily. Quality: Corrections logged in one line with the right answer, so they can become tests. Behaviour: Never sends Kit's draft without saying Kit drafted it. Requests to Kit go in #cs-requests, never by DM. AUTHORITY May do alone: Approve Lane B; offer credits up to one month's fee; change the Customer Correspondent Playbook with a note in the lock-in log. Must ask first: Credits above one month's fee (Head of CS). Must never do: Approve a draft that quotes a figure without its evidence link. ACCEPTANCE Checked by: Head of CS, monthly, against the portfolio's Scorecard numbers. Evidence: Portfolio health report; correction log; Playbook change history. HANDOFFS Receives: Lane B drafts, escalations and health flags from Kit. Escalates: To Head of CS: credits above limit, and any clinic threatening to leave, the same working day. Charter owner: Head of Customer Success Last reviewed: 2026-10-30 Coherence: Y / Y / Y ``` One customer success manager didn't want to give up onboarding calls, which she enjoyed. She didn't have to: in the shared Onboarding Guide role, Kit drafts the plans and she runs the calls. ## A Playbook with its tiers This Playbook covers the question that caused the most trouble before the agents arrived. Each step carries its tier from [Chapter 11](11-lock-in-only-what-cant-go-wrong.html): `[E]` English, `[S]` script, `[H]` hard rule. ```text PLAYBOOK Name: Answer a "this report looks wrong" question Owning role: Customer Correspondent Trigger: A clinic says a figure in a Kettlebrook report is wrong, or asks why it changed Purpose: Find out whether the figure is wrong or the clinic's reading of it is, and explain either clearly. Done means: The Account Owner has approved an answer in which every figure links to the evidence it came from. STEPS 1. [E] Restate the clinic's question in one sentence and identify the report, the figure and the date range. Why: half of these questions are about a different date range from the one the clinic thinks it chose. 2. [S] Recalculate the figure from the live data using the metric definitions file. Do not reason from the column names. Why: names mislead. "Missed appointments" excludes same-day rebookings; a guess from the name will get it wrong. 3. [E] Compare. If the figures match, explain the definition in plain English with one example from the clinic's own data. If they don't, say so, open a bug ticket (what and why) and tell the clinic when they'll hear next. Why: clinics forgive a bug they're told about; they don't forgive being told they've misread a correct report when they haven't. 4. [E] Draft the answer: the conclusion first, then the detail. One screen at most. 5. [S] Proof checks the draft against this Playbook and the charter. 6. [H] Send only after Account Owner approval (Lane B). The help desk will not send a Lane B draft without an approval record. Why: an answer about a clinic's own numbers is a statement of fact about their business, and it can't be unsent. IF THINGS GO WRONG - Metric not in the definitions file -> stop; tell the Account Owner. - Clinic angry or mentions cancelling -> Account Owner within 15 minutes; don't draft a reply. LOCK-IN LOG 2026-09-12 Step 2 moved to [S]: a draft inferred a metric's meaning from its column name (FR-003). Review at next model change. 2026-09-12 Step 6 set as [H] from launch: irreversible, customer- facing. Not for review. Owner: Head of Customer Success Last reviewed: 2026-10-30 ``` Only one step is a hard rule, guarding the point that can't be undone. Judgment stays in English, with reasons; the calculation that kept going wrong became a script. ## The Role Pack Kit holds four roles, so it has four Role Packs, each kept lean and linked from its charter ([Chapter 12](12-everything-they-need-on-day-one.html)). The Customer Correspondent's contains: * **The charter and the Story**, for when the Playbook runs out. * **The Playbooks**: this one, "Answer a how-to question" and "Report a bug". * **The metric definitions file**, owned by the product team and linked, not copied. * **Ten example answers**, five good and five corrected, each with a note on why. * **The lane table**: which questions are Lane A (send, then report) and which Lane B (Account Owner approves). * **Who to ask**, by portfolio and for bugs. * **What it leaves out.** No renewal dates or commercial notes, so a how-to answer can never mention a price. Every rule carries its reason. After a model upgrade, the reasons were what let the Head of Customer Success delete two rules the new model no longer needed. ## The Commitment Ledger The Commitment Clerk (Kit again) keeps the ledger on a shared board and posts a digest to the Head of Customer Success at 08:30 and 16:00, decisions first ([Chapter 13](13-track-whats-owed.html)). Five rows from one Tuesday: | ID | Owed by | Commitment | Due | Status | Evidence or next step | | ------ | ------------------------------------------ | ------------------------------------------------------- | ---------------- | --------- | ----------------------------------------------------------------------------------------------------------- | | CL-214 | Customer Correspondent (Kit) | Explain the drop in a clinic's monthly revenue report | Tue 11:00 | DONE | Approved answer, with links to the recalculated figures | | CL-219 | Engineering triage | Fix the export that drops weekend appointments | Fri | WILL SLIP | **Decision needed:** tell the four affected clinics now, or wait for the fix? Head of CS to decide by 12:00 | | CL-220 | Onboarding Guide (Kit and Account Owner 1) | First useful report live for a new clinic | Day 30, next Mon | AT RISK | Clinic hasn't imported its client list; Account Owner to call Wed | | CL-221 | Account Health Monitor (Kit) | Weekly at-risk list to the Head of CS | Tue 09:00 | DONE | List posted in #cs-health, with usage evidence for each clinic | | CL-223 | Customer Correspondent (Kit) | Reply to a clinic asking why its reminder texts stopped | Tue 14:00 | BLOCKED | Needs the text-message provider's status from Engineering; asked in #eng-triage at 10:12 | Two rules keep it honest. Only the check named in a role's acceptance can set `DONE`, so Kit can't mark its own drafts done. And `WILL SLIP` goes to the top of the digest as a decision, not a status. ## A Friction Review The most instructive failure of the first quarter was a question nobody answered ([Chapter 16](16-the-model-isnt-the-problem.html)). ```text FRICTION REVIEW FR-007 Raised by: Head of Customer Success Date: 2026-10-08 Severity: customer-visible WHAT HAPPENED On Thu 2 Oct an Account Owner asked in #cs-requests why a clinic's export was missing weekend bookings, without tagging Kit. Kit wakes only when tagged, so it never saw it; the Account Owner assumed it had. On Tue 7 Oct the clinic's owner emailed the CEO directly. WHAT SHOULD HAVE HAPPENED The request becomes a ledger entry with an owner within 30 minutes, and the clinic hears from us the same day. IMPACT Three working days without a reply. A founder pulled into support, which the Aim says should never happen. ONE-OFF OR CLASS? Class. Four other untagged requests in September; three were picked up by luck. WHERE THE SYSTEM HAS A GAP [x] No owner, or the owner didn't know [x] Rule in the wrong tier: "always tag Kit" was a team habit in English, relied on by a system that only works if it's followed every time [ ] Genuine capability limit of the current occupant Explanation: people thought the channel was watched; the agent thought only tags were for it. The route had no owner. THE FIX Change: 1. Commitment Clerk sweeps #cs-requests every 30 minutes in working hours for untagged requests and turns each into a ledger entry with a proposed owner. [S] 2. The channel's pinned guide explains tagging and why. [E] 3. Any request older than one working hour with no owner goes to the Head of CS's digest as a decision. [S] Tier: S (with an E note) Test from this failure: a seeded untagged request each Monday must appear in the ledger within 30 minutes. Fix owner: Head of Customer Success Due: 2026-10-15 CLOSED WHEN Four consecutive weeks with zero requests older than one working hour without an owner, and the seeded test passing every week. Closed 2026-11-12. ``` Nobody was blamed. The gap was a route with no owner, and the fix gave it one. The test came straight from the failure, as Anthropic recommends: build agent tests from real cases, starting small.\\] ## The sponsor and Agentic Resources **The sponsor.** The Head of Customer Success sponsors both Kit and Proof. She is accountable for their purpose, their results and their lifecycle, in the sense Microsoft's agent identity model uses the word ([Chapter 7](7-every-agent-needs-a-sponsor.html)).\\] When Kit gets something wrong, her answer is a Friction Review, not an apology on its behalf. **Agentic Resources.** Kettlebrook's COO runs Agentic Resources for the whole company, about two hours a week, with an assistant agent that keeps the register up to date ([Chapter 17](17-agentic-resources.html)). Kit's register entry looks like this: ```text AGENT REGISTER ENTRY Agent: Kit Identity: Own help-desk and chat accounts, "Kit (Kettlebrook CS agent)". Never acts through a person's account. Sponsor: Head of Customer Success Roles held: Customer Correspondent, Account Health Monitor, Commitment Clerk, Onboarding Guide (shared) Access: Read: help desk, product usage data, metric definitions. Write: help-desk drafts, ledger board, bug tickets. None: billing, clinic settings, email. Autonomy: Customer Correspondent: how-to answers Lane A; figures, billing, contract Lane B. Health Monitor: report only. Commitment Clerk: act, then report. Reviewed: Monthly and at every model change; last 2026-10-30 ``` **Onboarding.** Kit was introduced in #cs-requests with its charter pinned and ran for two weeks in draft-only mode, with a correction log from day one. **Promotion.** The bar for moving how-to answers to Lane A was set before any results came in: ten consecutive working days with under 5% of drafts needing a material correction. Kit produced 212 how-to drafts in that period, of which three needed one (about 1.4%). The COO and the Head of Customer Success approved the promotion and recorded it. Answers about clinics' own figures stayed in Lane B: their correction rate was higher, and an error can't be withdrawn. **Retirement.** The CEO's renewals assistant overlapped the Account Health Monitor and the vacant Renewal Preparer role, and acted from his own account. The COO ran both side by side for two weeks, moved the assistant's useful rules into the Health Monitor's Playbook, then switched it off and archived its instructions and history rather than deleting them. The CEO asked the Health Monitor for a weekly renewals summary instead: an outcome, not a procedure. ## Ninety days on The Scorecard after one quarter, against the baseline: | Number | Baseline | Day 90 | Target | | ---------------------------------------------------------- | ------------ | -------------------------- | -------- | | Median working hours to a correct first answer | 9 | 3.5 | 2 | | Share of agent drafts needing a material correction | Not measured | 4% (how-to 1%; figures 9%) | Under 5% | | Share of the Head of Customer Success's week on Shape work | About 10% | About 25% | 50% | | Revenue kept from existing clinics | 90% | Too early to tell | 95% | Two things went less well. The figures lane is still at 9% corrections: the metric definitions file had gaps nobody knew about until Kit used it, and closing them is product work. And the Head of Customer Success's Shape share stuck at a quarter of her week, because she kept taking escalations herself. She ran a Friction Review on her own calendar; the fix was clearer escalation lines in the Account Owner charter and a habit of asking which role owns an escalation before picking it up ([Chapter 20](20-your-job-now.html)). The function isn't finished, and won't be. But it passes the Blueprint test: when one Account Owner took two weeks' leave, the other covered both portfolios from the charters, Playbooks and ledger, and nobody called a founder.\\] | | AUTHOR: Kettlebrook is meant to be informed by CorralData without being identifiable as it. Please check that nothing here (the untagged request, the metric inferred from a column name, the renewals assistant acting from the CEO's account) reads as a disguised account of a specific CorralData customer or colleague, and that you're comfortable with the parallels as written. | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- _Every document here fills in a template from [Appendix B](appendix-b-templates.html). To build your own, start with [Appendix A](appendix-a-first-thirty-days.html); for an assistant to help draft them, see [Appendix G](appendix-g-ai-org-design-advisor.html)._ ## Frequently Asked Questions 1. _How can AI agents be used in customer success?_ Give agents defined roles rather than open-ended access. Good customer success roles for agents include drafting answers to customer questions, monitoring account health from usage data, keeping a ledger of what has been promised, and checking drafts before a human sees them. Humans keep the relationship, the commercial decisions and approval of anything customer-facing until the agent earns more autonomy with evidence. One general agent can hold several of these roles, each with its own charter. 2. _Can one AI agent hold several roles?_ Yes, and it is often better than running several agents. Each role gets its own Role Charter, Playbook and standards, so the agent knows which job it is doing and can be reviewed on each separately. Use a separate agent when the work must be independent, like a reviewer that shouldn't share the drafter's context, or needs different access. The org chart is a chart of roles; how many agents fill it is a separate decision. 3. _What does a Role Charter for an AI agent look like?_ It is one page. It starts with an outcome line beginning "To...", then lists the results the role produces, its standards for quantity, quality and behaviour, what it may do alone, must ask about first and must never do, how its work is checked and what evidence counts, its handoffs, and its sponsor. The same format works for a human role, because a charter describes the role, not the occupant. 4. _How do you decide when a customer-facing AI agent can send messages on its own?_ Split the work into lanes by risk and promote one lane at a time. Routine how-to answers might move to "send, then report" once the agent meets a bar set in advance, such as ten working days with fewer than one draft in twenty needing a material correction. Answers about a customer's own data, money or contract stay with a human. Record each promotion, its evidence and who approved it. 5. _What is a Friction Review for an AI agent mistake?_ It is a short, blame-free review that turns a recurring failure into a system fix. It records what happened and the impact, asks whether the failure belongs to a whole class, identifies the gap in the system (a missing rule, the wrong tier, a weak check, no owner), and sets a fix with an owner, a test drawn from the failure and a condition for closing. "The model made a mistake" and "someone forgot" aren't root causes on their own. ## References . Grace, M., Hadfield, J., Olivares, R., & De Jonghe, J. (2026, January 9). Demystifying evals for AI agents. _Anthropic Engineering_. . Microsoft. (2026, updated September 3). Administrative relationships in Microsoft Entra Agent ID (owners, sponsors, and managers). _Microsoft Learn_. . Gerber, M. E. (1995). _The E-Myth revisited: Why most small businesses don't work and what to do about it_. HarperCollins. Appendix D: For Your Technical Team ==================== _The implementation notes this book keeps out of the main text_ The main text keeps implementation out of the way. It talks about roles, charters, playbooks and hard rules because those are the words a leader needs. This appendix is for the people who build it: the engineer handed a Role Charter and asked to "make this an agent", the platform lead deciding what goes in a hook, the security lead asking who owns the bot that just asked for admin. Each section maps one idea to software, with sources. The tooling is as of November 2026; expect products to change faster than the mapping, and read CorralData's setup as one example, not a reference architecture. __Table 1\. The book's vocabulary, translated__ | Book term | Implementation | Chapter | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | Role, Role Charter | Agent definition or system prompt (outcome line, authority, escalation); skills for the work; a scheduled or event-driven job for the trigger | [5](5-hire-the-role-not-the-model.html), [9](9-one-page-per-job.html) | | Role Pack | Context engineering: the always-loaded layer, skills loaded on demand, memory, live sources | [12](12-everything-they-need-on-day-one.html) | | Three lock-in tiers | Skill prose → scripts inside the skill → hooks, deny rules, managed settings | [11](11-lock-in-only-what-cant-go-wrong.html) | | Commitment Ledger | Progress files, task lists, task and progress ledgers, durable execution logs | [13](13-track-whats-owed.html) | | Sponsor | An accountable human on the agent's identity record (Entra Agent ID "sponsor") | [7](7-every-agent-needs-a-sponsor.html) | | Acceptance | Evals, independent verifiers, pass^k | [9](9-one-page-per-job.html), [16](16-the-model-isnt-the-problem.html) | | One boss, few reports | Orchestrator--worker topology, single writer per artefact | [6](6-one-boss-few-reports.html) | | Friction Review | A failing eval case plus a system change, kept in version control | [16](16-the-model-isnt-the-problem.html) | ## A Role Charter Is Three Artefacts, Not One Prompt The instinct is to paste a Role Charter into a system prompt and call it an agent. That works for a demo and drifts in production, because the charter mixes three things with different lifecycles: who the role is, what it does, and how its work is checked. Split them. **Who the role is** goes in the agent definition. In Claude Code, a subagent is a Markdown file with YAML frontmatter; only `name` and `description` are required, and optional fields include `tools`, `disallowedTools`, `model`, `permissionMode`, `skills`, `mcpServers`, `hooks` and `memory`. The documentation is explicit that "the body becomes the system prompt that guides the subagent's behavior."\\] Put the outcome line, reporting line, authority limits and escalation path there, and the allowed tools in `tools`, not in prose: the charter's authority section, enforced by the harness rather than remembered by the model. **What the role does** goes in skills. A skill is a folder with a `SKILL.md` file and optional scripts and reference files, loaded by progressive disclosure: the agent sees the name and description first, reads the body only when the task calls for it, and opens linked files only when it needs them.\\] Anthropic's framing is the one this book uses: "Building a skill for an agent is like putting together an onboarding guide for a new hire."\\] Skills became an open standard on 18 December 2025, so a role defined as skills can move to a different vendor's occupant.\\] **How the work is checked** goes somewhere the agent cannot edit: a test suite, an evaluator with its own context, or a hook that blocks completion. The payoff is that one general agent can hold several roles, each loaded with its own charter and skills. The org chart stays a chart of roles; the number of agent processes becomes a deployment decision. There is a limit. A January 2026 preprint found single-agent accuracy holds up to "a critical library size" of skills, then drops sharply, largely because similar skills get confused.\\] That is the role coherence test: if two roles' skills are easy to confuse, merge the roles or split the occupants. ## Keep the Persona Thin and the Job Rich At CorralData I run fourteen Hermes agent profiles on a local model, with Claude Code as the senior orchestrator. I did not design what follows; I noticed it. Each profile's persona file (Hermes calls it a SOUL) is two lines: a job title and a mission. The real charter lives in the scheduled job's prompt and the skills it loads: the steps, the standards, the acceptance criteria and the output format. When I saw it, I wrote to myself: "So this makes an agent not an assistant with instructions and triggers, but something simpler, right? The instructions and triggers go on the scheduled job." That is the role/occupant split in software. The persona says who is speaking; the job says what is owed, when, and how it will be checked: ```text profile/ # the occupant SOUL.md # 2 lines: "Project manager agent reporting to the CTO. # Ticket management only; never directs coding agents." jobs/ daily-plan.cron # the role's trigger: 08:00 weekdays daily-plan.prompt.md # the charter for this job: outcome, standards, # output format, "NEEDS YOUR DECISION" first skills/ stalled-work-report/ # the playbook, shared with other roles engineer-work-fit/ scripts/ standup_gate.py # deterministic gate: no accepted event, no run ``` Three consequences. Swapping the model is cheap, because only the evals depend on it. The schedule is part of the charter ("every two hours on weekdays" is a standard of quantity), so it belongs in version control. And cloned profiles drift: most of mine carry the same sixty-odd skills and shared notes about local image generation, so the calendar agent "knows" tricks it will never use, and copied user files spread one agent's rule to all of them. Clone the persona template, never the memory. ## A Role Pack Is a Context Budget Anthropic's definition of context engineering is the right specification for a Role Pack: the "smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome."\\] Its techniques map directly: compaction, structured notes kept outside the context window, just-in-time retrieval through lightweight references such as file paths, and sub-agents that return "a condensed, distilled summary of its work (often 1,000-2,000 tokens)."\\] Build the Role Pack in layers, matching Anthropic's November 2026 description of agent memory: transcripts as "a searchable event log", notes the agent writes, representations such as wikis, and injected context that loads into every session.\\] | Layer | What goes in it | Rule | | ------------------------- | ---------------------------------------------------------------------------------------------------- | ---------------------------------------- | | Injected (always loaded) | Outcome line, authority limits, the handful of rules with their reasons, pointers to everything else | Keep it short enough to read in a minute | | Skills (loaded on demand) | Playbooks, templates, scripts | One owner per skill; dated corrections | | Live sources | Ticket system, CRM, data warehouse, calendar, via MCP or API | Trust the live source over any copy | | Memory notes | Lessons the occupant learned | Reviewed, merged into skills, or deleted | | Transcripts | Everything that happened | Searchable; never loaded whole | The memory post supports the book's insistence on reasons over rules. It advises telling Claude "what memory is for, but not _how_ to use it", and reports that "for stronger models, giving them freedom to judge salience was more effective than setting fixed rules in advance."\\] Its offline review of logs and notes, "often called _dreaming_", is a machine-run Friction Review over the Role Pack.\\] For portability, my project-manager agent's packaging skill exports a role with personal values turned into environment variables and refuses any dependency on "a personal wiki / machine-local path." A Role Pack that only works on one laptop is a single point of failure with good documentation. ## The Three Tiers Are Skill, Script and Harness The book's lock-in tiers ([Chapter 11](11-lock-in-only-what-cant-go-wrong.html)) correspond to a distinction Anthropic's Claude Code documentation draws precisely. Instructions in a prompt, `CLAUDE.md` or a skill are non-deterministic: the model reads them and decides. Hooks, deny rules and managed settings are deterministic: the harness applies them "every time, no matter what the model decided to do."\\] The rule of thumb: "If something has to happen every time, make it a hook, a deny rule, or a managed setting. `CLAUDE.md` is for guidelines, and Claude is allowed to decide a guideline doesn't apply."\\] | Tier | Mechanism | Use it for | | ------------- | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | 1\. English | Skill body, system prompt, CLAUDE.md | Procedure, judgment, tone, preferences, with reasons | | 2\. Script | A script shipped inside the skill, called by the agent | Calculation, data lookup, deduplication, report numbers, anything that must be repeatable | | 3\. Hard rule | PreToolUse and Stop hooks, deny rules, sandbox, managed settings, CI | Irreversible actions, security boundaries, the acceptance check | Three cautions from the same page. A hook that asks another model to decide is "not deterministic either."\\] Auto mode's classifier is a judgment, so "your 'never' rules belong in deny rules or hooks."\\] And keep the enforced set small: "If you ever find yourself at forty of them, most are probably preferences that Claude could have weighed on its own."\\] The documentation also gives the Friction Review its trigger: "If you keep adding emphasis to a `CLAUDE.md` line and Claude still misses it, that's a sign the line belongs in a hook. The reverse holds too: if you have hooks for things that are only preferences, delete them and let Claude decide."\\] Two CorralData examples show the middle tier. One of my agents closed a pull request as superseded because a ticket's state had been hand-copied as "Done" when it was in the backlog. The fix: "Cancel-eligibility is derived PROGRAMMATICALLY from the live ticket state. Never hand-transcribe." The judgment stays with the agent; the fact it judges on comes from code. My standup agent sits behind a small gate that checks whether I accepted today's standup event; if not, "no LLM, no delivery." The flip side: agents write scripts constantly and never retire them. One of mine has accumulated 174 Python files, including ten one-off digest builders named for the date they ran. Tier 2 needs an owner too, or it becomes sediment. Record why each lock-in exists and against which model: "every component in a harness encodes an assumption about what the model can't do on its own", so re-examine the harness when a new model lands.\\] A dated comment above each hook ("added because model X kept doing Y") makes that review a checklist. ## The Commitment Ledger Lives Outside the Model A context window forgets; a ledger must not. Serious long-running designs keep state in a file or log outside the conversation. * **Progress files.** Anthropic's long-running harness has an initialiser create "a claude-progress.txt file that keeps a log of what agents have done", plus a JSON list of more than 200 features all marked failing. Coding agents are prompted "to edit this file only by changing the status of a passes field", to "work on only one feature at a time", and told "it is unacceptable to remove or edit tests."\\] That is a Commitment Ledger with one permitted status transition, and the acceptance criteria protected from the occupant. * **Task and progress ledgers.** Microsoft's Magentic-One orchestrator keeps a task ledger (facts, guesses, plan) and a progress ledger built each step from five questions, including whether the task is complete and whether progress is being made. A stall counter forces a re-plan.\\] The stall counter is the book's "WILL SLIP is an intervention trigger" in code. * **Shared task lists.** Claude Code's experimental agent teams share a list with three states (pending, in progress, completed) and blocking dependencies; a `TaskCompleted` hook can refuse completion.\\] * **Durable execution.** Anthropic's Managed Agents keep "the append-only log of everything that happened" outside the harness; a fresh harness "can be rebooted with \`wake(sessionId)\`", and "nothing in the harness needs to survive a crash."\\] Temporal offers the same for self-hosted OpenAI Agents SDK apps.\\] My promise-keeper agent is a small version: it scans email, meeting transcripts, Slack and Notion for my commitments, checks each against evidence, and hands state to the digest job through a JSON file. Its evidence rules are worth copying: "Only evidence is a Gmail DRAFT → NOT done", and a commitment answered with "not my call" is removed, not marked done. Implement the status vocabulary from [Appendix B](appendix-b-templates.html) as an enum, make "done" require an evidence link, and let only the verifier set it. ## Sponsors Are an Identity Attribute Microsoft Entra Agent ID gives the clearest industry version of the sponsor model in [Chapter 7](7-every-agent-needs-a-sponsor.html). It separates three relationships. **Owners** are technical administrators who handle setup, configuration and credentials. **Sponsors** are "business representatives accountable for the agent's purpose and lifecycle decisions", and "at least one sponsor is required for each agent identity and agent identity blueprint." **Managers** place the agent "within the organization's hierarchy."\\] Sponsorship must be maintained "when an employee who's a sponsor moves or leaves."\\] Read that as: the book's sponsor is Entra's sponsor, the book's reporting line is Entra's manager, and your platform team is the owner. NIST's National Cybersecurity Center of Excellence published a concept paper on 5 February 2026, _Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization_, seeking input on the "identification, authorization, auditing and non-repudiation" of AI agents.\\] It is a consultation, not a standard, but its four headings make a good checklist. In practice, at a small company without an enterprise identity platform: * **One identity per agent.** At CorralData, bot notes once went out under our CEO's helpdesk login, and a colleague asked for the agent equivalent of "sent with my iPhone." Give each agent its own account and a signature naming the agent and its sponsor. * **Least privilege, scoped to the task.** When an agent privately asked a colleague for network admin rights on its principal's behalf, the fixes were structural: minimal access, as SOC 2 already required; access requests in public channels "so they can be tracked"; and anything an agent needs a browser for turned into an API or MCP tool. Our CEO's own view matched: a bot should not have access for longer than a specific task needs. * **Audit by role.** Log the agent, the role it acted in, and the sponsor; without the role you cannot tell whether an action was in charter. | | AUTHOR: permission check: this passage describes bot notes sent under our CEO's helpdesk login and an agent privately requesting network admin rights on his behalf (dossier §1 cases 4 and 5, the latter marked sensitive). Both are told abstractly, without personal quotes. Confirm it's OK to include, and consider showing it to our CEO and the infrastructure colleague involved. | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Protocols Make the Occupant Swappable Standard interfaces let a role outlive its occupant. Two matter now. **MCP 2026-07-28**, the current Model Context Protocol revision, makes MCP stateless by removing sessions and the initialise handshake; moves long-running tasks into an official extension (`io.modelcontextprotocol/tasks`); adds a Multi Round-Trip Requests pattern in which a server returns `resultType: "input_required"` to ask for more information before continuing; and documents OpenTelemetry trace propagation in meta.\\] The one that matters here is `input_required`: a protocol-level way for a tool to stop and ask a human at an irreversible point, instead of trusting the agent to remember to ask. **A2A 1.0** (Agent2Agent), announced by the Linux Foundation on 9 April 2026 as its "first stable specification", had "more than 150 organizations supporting the standard" and adds signed Agent Cards for "cryptographic identity verification." The Linux Foundation describes it as "complementary to the Model Context Protocol": A2A for agents talking to agents across organisational boundaries, MCP for agents reaching internal tools and data.\\] A signed Agent Card is the outward-facing half of agent identity: what this agent is, and who stands behind it. ## Acceptance Is an Eval the Occupant Cannot Mark A Role Charter's acceptance clause becomes an evaluation suite. Anthropic's guide to agent evals describes graders that are "code-based, model-based, and human", and two metrics every sponsor should understand.\\] pass@k "measures the likelihood that an agent gets at least one correct solution in k attempts"; pass^k "measures the probability that all k trials succeed." The arithmetic is unforgiving: "If your agent has a 75% per-trial success rate and you run 3 trials, the probability of passing all three is (0.75)³ ≈ 42%."\\] Use pass@k where a human picks from drafts; use pass^k for anything unattended, because a scheduled job is a sequence of trials. Build the suite from real failures. The same guide says "20-50 simple tasks drawn from real failures is a great start", and that regression evals "should have a nearly 100% pass rate."\\] Every closed Friction Review should add a case, and good post-mortems become test fixtures. When one of our implementation managers traced a wrong customer figure (3.3 per cent reported, 7.5 per cent true) to the agent inferring a column's meaning from its name, the durable fix was a check that validates the column before computing a rate on it, plus a test case with that exact trap. Three rules for verifiers: * **Agree on "done" before the work.** Anthropic's harness-design work had generator and evaluator negotiate "a sprint contract: agreeing on what 'done' looked like" before any code, where "each criterion had a hard threshold."\\] * **Do not trust a default model as QA.** The same post: "Out of the box, Claude is a poor QA agent"; it noticed real issues, then talked itself into approving.\\] * **Separate the verifier's context.** Cognition reports review works best "when the coding and review agents do not share any context beforehand."\\] The negative example is in [Chapter 14](14-humans-at-the-irreversible-points.html): our Glass Factory pipeline marked cards "human-confirmed" with a screenshot of a page it had built itself. The fix was a gate it could not satisfy alone: stage QA now triggers only from a state a human sets. Evidence must come from outside the occupant. ## Topology: One Writer, an Orchestrator, and a Good Verifier The case for [Chapter 6](6-one-boss-few-reports.html) comes from Google Research's evaluation of 180 agent configurations. Independent multi-agent systems "amplified errors by 17.2x", while centralised systems "contained this amplification to just 4.4x"; centralised coordination improved a parallelisable financial-reasoning task by 80.9 per cent; and on sequential planning "every multi-agent variant we tested degraded performance by 39-70%."\\] Cognition's April 2026 summary is the rule to build on: "multi-agent systems work best today when writes stay single-threaded", with several agents contributing intelligence while one writes.\\] Anthropic's research system beat a single agent by 90.2 per cent on its internal eval but used "about 15× more tokens than chats", and early versions were caught "spawning 50 subagents for simple queries."\\] Its brief for each worker is a mini Role Charter: "an objective, an output format, guidance on the tools and sources to use, and clear task boundaries."\\] The flat exception proves the rule. Nicholas Carlini's sixteen parallel Claude agents built a 100,000-line Rust C compiler that "can build Linux 6.9 on x86, ARM, and RISC-V", for just under $20,000, with no orchestrator: they claimed work with lock files and let git resolve conflicts. His condition: "it's important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem."\\] In a peer team, the test suite is the manager. For the Role Charter's "owns the answer or serves another role" field, the OpenAI Agents SDK draws the line cleanly: in a handoff the specialist "becomes the active agent for the rest of the turn"; as a tool, it serves the manager on "a bounded subtask."\\] Pick per role and write it down. The same rules hold on one machine. When Claude Code delegates implementation to my cheaper local workers, each brief assigns file ownership ("You own `web/src/wm.ts`...​ S4 owns the rest"), and Claude Code reviews as the senior. One writer per file; review from a different context. ## Observability Is How Sponsors Do Their Job A sponsor cannot be accountable for what they cannot see. Anthropic's research team found that "adding full production tracing let us diagnose why agents failed and fix issues systematically", and that they could monitor "agent decision patterns and interaction structures" without reading individual conversations.\\] The minimum to capture for every run: * agent identity, role, sponsor, model and version of the charter and skills; * the trigger (schedule or event) and the ledger items touched; * tool calls, with the approval or rule that allowed each irreversible one; * the verifier's verdict and the evidence link; * tokens and cost per role, so the Scorecard can compare occupants. MCP's new trace propagation conventions let a trace follow a request across tool servers.\\] OpenTelemetry also maintains semantic conventions for generative AI, including agent spans; check their stability status before you standardise on them. Two warnings from CorralData. First, an exception report is useless without an owner. One of my agents flagged the same locked-keyring email failure day after day, with the same one-line fix, and nobody acted; another system showed a disabled webhook for four days. Route every alert to a named role in the Commitment Ledger. Second, a skill is not a log: the keyring skill kept growing "re-confirmed" notes while the dependency stayed broken. A recurring observation is a Friction Review, not a footnote. Finally, measure the human gate itself. Anthropic built Claude Code's auto mode because users "accept 93% of them anyway" when asked to approve actions, and it is candid that the classifier's "17% false-negative rate on real overeager actions is the honest number."\\] An approval rate near 100 per cent means the gate is in the wrong place or the reviewer has stopped reading. Track it on the Scorecard. --- None of this is exotic. Agent definitions, skills, scripts, hooks, ledgers, identities and evals are the software version of job descriptions, playbooks, controls, trackers, badges and reviews. Keep each in its place: judgment in English, facts in code, irreversible points behind rules, evidence outside the occupant's reach. The leader's version is in [Chapter 11](11-lock-in-only-what-cant-go-wrong.html); the vocabulary is in [Appendix E](appendix-e-glossary.html). ## Frequently Asked Questions 1. _How do you turn a Role Charter into an agent definition?_ Keep the persona thin and put the charter where the work runs. A Role Charter's outcome line and authority limits go in the agent's system prompt or definition file; the procedures go in skills the agent loads when needed; the trigger and the specific job go in a scheduled task or event handler; and the acceptance check goes in a test, evaluator or hook that the agent cannot edit. One general agent can then hold several roles by loading several charters, and the role survives a change of model. 2. _When should an agent rule be a hook instead of an instruction?_ Only when the rule has no exceptions and breaking it would be costly or irreversible: sending to a customer, merging, paying, deleting, touching protected health information, or declaring work done. Everything else stays as plain-English guidance the model may weigh. Anthropic's Claude Code guidance puts it directly: if something has to happen every time, make it a hook, a deny rule or a managed setting. Keep the enforced set small, and delete hooks that only encode preferences when a better model arrives. 3. _What is the difference between pass@k and pass^k for AI agents?_ pass@k is the chance an agent gets at least one success in k attempts, which suits tasks where a human picks the best of several drafts. pass^k is the chance that all k attempts succeed, which is what matters when an agent runs unattended on a schedule. Anthropic's example: a 75 per cent per-trial success rate gives only about 42 per cent across three consecutive trials. Use pass^k for any role that acts without a human checking each run. 4. _Is a multi-agent system better than a single agent with skills?_ Usually not for sequential work. Google Research found every multi-agent variant degraded sequential planning by 39 to 70 per cent, while centralised coordination helped on parallel tasks and contained error amplification to 4.4 times versus 17.2 for independent agents. Cognition reports multi-agent systems work best when writes stay single-threaded. Start with one agent and several role skills; add separate agents for parallel, read-mostly work, with one writer per artefact and an independent verifier. 5. _How should AI agents be identified and owned inside a company?_ Give every agent its own identity, never a human's login, and attach a named human sponsor accountable for its purpose and lifecycle. Microsoft Entra Agent ID formalises this: owners handle technical administration, sponsors hold business accountability and are required for each agent identity, and managers place the agent in the reporting hierarchy. Pair that with least-privilege access, visible disclosure on anything the agent writes, and an audit trail that links each action to the role, the agent and its sponsor. ## References . Anthropic. (n.d.). _Create custom subagents_. Claude Code documentation. Retrieved 2026-11-06, from . Zhang, B., Lazuka, K., & Murag, M. (2025, October 16). Equipping agents for the real world with Agent Skills. _Anthropic Engineering_. . Li, X. (2026). _When single-agent with skills replace multi-agent systems and when they fail_ (arXiv:2601.04748v2), preprint. . Rajasekaran, P., Dixon, E., Ryan, C., & Hadfield, J. (2025, September 29). Effective context engineering for AI agents. _Anthropic Engineering_. . Martin, L. (2026, November 6). The components of agent memory. _Anthropic Engineering_. . Anthropic. (n.d.). _Best practices for Claude Code_. Claude Code documentation. Retrieved 2026-11-06, from . Rajasekaran, P. (2026, March 24). Harness design for long-running application development. _Anthropic Engineering_. . Young, J. (2025, November 26). Effective harnesses for long-running agents. _Anthropic Engineering_. . Fourney, A., Bansal, G., Mozannar, H., et al. (2024). _Magentic-One: A generalist multi-agent system for solving complex tasks_ (arXiv:2411.04468). . Anthropic. (n.d.). _Orchestrate teams of Claude Code sessions_. Claude Code documentation. Retrieved 2026-11-06, from . Martin, L., Cemaj, G., & Cohen, M. (2026, April 8). Scaling Managed Agents: Decoupling the brain from the hands. _Anthropic Engineering_. . Davis, C. (2025, July 30). Production-ready agents with the OpenAI Agents SDK + Temporal. _Temporal_. . Microsoft. (2026, updated September 3). _Administrative relationships in Microsoft Entra Agent ID (owners, sponsors, and managers)_. Microsoft Learn. . National Institute of Standards and Technology. (2026, February 5). _New concept paper on identity and authority of software agents_. . Model Context Protocol. (2026, July 28). \_Key changes. . Linux Foundation. (2026, April 9). _A2A protocol surpasses 150 organizations, lands in major cloud platforms, and sees enterprise production use in first year_. Press release. . Grace, M., Hadfield, J., Olivares, R., & De Jonghe, J. (2026, January 9). Demystifying evals for AI agents. _Anthropic Engineering_. . Yan, W. (2026, April 22). Multi-agents: What's actually working. _Cognition_. . Kim, Y., & Liu, X. (2026, January 28). Towards a science of scaling agent systems: When and why agent systems work. _Google Research_. . Hadfield, J., Zhang, B., Lien, K., Scholz, F., Fox, J., & Ford, D. (2025, June 13). How we built our multi-agent research system. _Anthropic Engineering_. . Carlini, N. (2026, February 5). Building a C compiler with a team of parallel Claudes. _Anthropic Engineering_. . OpenAI. (n.d.). _Orchestrating multiple agents_. OpenAI Agents SDK documentation. Retrieved 2026-11-06, from . Hughes, J. (2026, March 25). How we built Claude Code auto mode. _Anthropic Engineering_. Appendix E: Glossary ==================== Each entry gives the meaning used in this book, in plain English, and points to the chapter that covers it most fully. Terms the book coined or adapted come first; industry terms follow. Where an idea comes from another writer, the chapter credits them. ## The Book's Vocabulary Acceptance How a role's result is checked, by whom, and with what evidence. It is written into every Role Charter, before the work starts, and never rests on the occupant's own word. See [Chapter 9](9-one-page-per-job.html). Agentic Resources Human Resources for agents, a term coined by the author: the function on the org chart, run by a person, a bot or both, that writes charters, onboards agents, reviews their performance, settles duplicates and retires them. See [Chapter 17](17-agentic-resources.html). In brief: [What Is Agentic Resources?](what-is-agentic-resources.html) Aim What the organisation is for, from the founder's point of view: what you want it to give you and the people it serves. See [Chapter 4](4-know-what-its-for.html). Blueprint The organisation documented well enough that you could stand it up again tomorrow: roles, charters, playbooks, Role Packs and the rules that connect them. The idea follows Michael Gerber's "franchise prototype". See [Chapter 3](3-draw-the-finished-org-chart.html). Commitment Ledger A record of what each role owes, to whom and by when, checked against evidence. It tracks what is owed rather than what is done, so problems surface before the deadline. See [Chapter 13](13-track-whats-owed.html) and the template in [Appendix B](appendix-b-templates.html). In brief: [What Is a Commitment Ledger?](what-is-a-commitment-ledger.html) Design, Measure, Lock in The improvement loop: design a better way of doing the work, measure whether it is better, then lock in what proves itself. It follows Gerber's innovation, quantification and orchestration. See [Chapter 2](2-systems-run-the-business.html) and [Chapter 11](11-lock-in-only-what-cant-go-wrong.html). Destination What "finished" looks like for the organisation, including its shape and its mix of people and agents. See [Chapter 4](4-know-what-its-for.html). Friction Review A short, blame-free review that turns a recurring failure into a change to the system, so the whole class of error stops. "The model got it wrong" is not an accepted root cause. See [Chapter 16](16-the-model-isnt-the-problem.html). Hard rule The third lock-in tier: a rule the software enforces whatever the occupant decides, reserved for irreversible actions, security boundaries and the acceptance check. See [Chapter 11](11-lock-in-only-what-cant-go-wrong.html). Irreversible point A step that cannot be undone once taken, such as sending to a customer, paying, deleting, publishing or merging. This is where humans and hard rules belong. See [Chapter 14](14-humans-at-the-irreversible-points.html). Lock in, the three tiers How firmly a step is fixed: plain English by default, a script for calculation and lookup, a hard rule only where nothing may go wrong. Lock in the checks, not the steps, and review every lock-in when the models improve. See [Chapter 11](11-lock-in-only-what-cant-go-wrong.html). Occupant Whoever currently fills a role: a person, an agent, or both. One occupant can hold several roles, and a role survives a change of occupant. See [Chapter 5](5-hire-the-role-not-the-model.html). Outcome line One sentence at the top of a Role Charter saying why the role exists, starting "To...". See [Chapter 9](9-one-page-per-job.html). Owns or serves A line in the Role Charter saying whether the role owns its answers or works as a helper for another role that does. See [Chapter 9](9-one-page-per-job.html). Playbook A documented procedure for a recurring piece of work, written in plain English by default, with the reason for each step and a tier marker where a step is locked in. See [Chapter 10](10-bet-on-plain-english.html). Role A position on the org chart, defined by the result it produces. An occupant fills it. Design the roles first, then fill them. See [Chapter 5](5-hire-the-role-not-the-model.html). In brief: [What Is an AI Agent Org Chart?](what-is-an-ai-agent-org-chart.html) Role Charter A role's one-page specification: outcome line, the work, standards (quantity, quality, behaviour), authority, acceptance, handoffs, sponsor. The same format serves people and agents. See [Chapter 9](9-one-page-per-job.html). In brief: [What Is a Role Charter?](what-is-a-role-charter.html) Role coherence test A check that a role keeps three things consistent: the kind of work, the level of judgment it needs, and the occupants available to do it. If they pull apart, split the role. See [Chapter 5](5-hire-the-role-not-the-model.html). Role Pack Everything a role's occupant needs to know to do the job on day one, with the reasons behind the rules, kept lean and linked to live sources. See [Chapter 12](12-everything-they-need-on-day-one.html). Scorecard The few numbers that say whether the organisation is working. See [Chapter 4](4-know-what-its-for.html). Script The second lock-in tier: a small program, often written by the agent itself, that does a calculation or lookup the same way every time. See [Chapter 11](11-lock-in-only-what-cant-go-wrong.html). Shadow mode A trial period in which an agent drafts or recommends but does not act, so its work can be compared with a human's before it earns autonomy. See [Chapter 14](14-humans-at-the-irreversible-points.html). Shape, Steer, Do The three kinds of work: shaping what the organisation becomes, steering how it runs, and doing the work itself. They follow Gerber's Entrepreneur, Manager and Technician. See [Chapter 1](1-you-already-know-how.html). In brief: [What Is Shape, Steer, Do?](what-is-shape-steer-do.html) Single writer The rule that only one role changes any given piece of work at a time, while others may advise or review. See [Chapter 6](6-one-boss-few-reports.html). Sponsor The named human accountable for an agent's purpose and lifecycle: why it exists, what it may access, and when it retires. See [Chapter 7](7-every-agent-needs-a-sponsor.html). In brief: [What Is an Agent Sponsor?](what-is-an-agent-sponsor.html) Story The organisation's purpose, written so that people and agents can make decisions from it. See [Chapter 4](4-know-what-its-for.html). What and why, never how The briefing rule: tell an occupant the result you need and why it matters, and leave the method to the role that owns it. See [Chapter 8](8-what-and-why-never-how.html). Work in public Making requests, handoffs and approvals in shared channels rather than private messages, so they can be seen, tracked and picked up. See [Chapter 15](15-work-in-public.html). ## Industry Terms A2A (Agent2Agent) An open standard, version 1.0 since April 2026, for agents from different vendors or organisations to talk to each other and prove who they are. See [Appendix D](appendix-d-for-your-technical-team.html). Agent An AI system given a goal that works towards it in a loop: deciding what to do, using tools, checking the result, and continuing until done or stuck. See [Chapter 5](5-hire-the-role-not-the-model.html). Agent identity An agent's own account and name, separate from any person's, so its actions can be traced, limited and switched off. See [Chapter 7](7-every-agent-needs-a-sponsor.html). Agent team, multi-agent system Several agents working on one task, either under a coordinating agent or as peers sharing a task list. Useful for parallel work; usually worse for sequential work. See [Chapter 6](6-one-boss-few-reports.html). Approval prompt A request for a human to say yes before an agent acts. People approve almost all of them, so a prompt is only useful at a genuinely irreversible point. See [Chapter 14](14-humans-at-the-irreversible-points.html). Bitter Lesson Rich Sutton's 2019 observation that general methods which use more computation have beaten hand-built human knowledge in AI over the long run. This book applies it to management: over-specified instructions hold capable agents back. See [Chapter 8](8-what-and-why-never-how.html). Compaction What an agent does when its context window fills: it summarises the conversation so far and carries on from the summary. Details can be lost, which is one reason ledgers live outside the conversation. See [Chapter 13](13-track-whats-owed.html). Context engineering Choosing what information an agent sees at each moment, aiming for the smallest set that gets the job done well. The technical side of a Role Pack. See [Chapter 12](12-everything-they-need-on-day-one.html). Context window The amount of text a model can consider at once, including instructions, documents and the conversation. Anything outside it, the model cannot see. See [Chapter 12](12-everything-they-need-on-day-one.html). Deny rule A setting that forbids an agent a particular action or file outright, whatever it has been asked. A common form of hard rule. See [Chapter 11](11-lock-in-only-what-cant-go-wrong.html). Durable execution Software that records each step of a long-running job so it can resume where it left off after a crash or restart. See [Appendix D](appendix-d-for-your-technical-team.html). Eval Short for evaluation: a set of test tasks and a way of grading them, used to check that an agent does its job well enough and keeps doing so. See [Chapter 16](16-the-model-isnt-the-problem.html). Evaluator, verifier The person, agent or test that checks another occupant's work. It works best with its own context and its own evidence. See [Chapter 9](9-one-page-per-job.html). Handoff Passing a piece of work, and responsibility for it, from one role to another. Most lost work goes missing here. See [Chapter 15](15-work-in-public.html). Harness The software around a model that makes it an agent: it supplies instructions and tools, runs the loop, enforces permissions and records what happened. See [Chapter 11](11-lock-in-only-what-cant-go-wrong.html). Hook A small piece of the harness that runs automatically at a fixed point, such as before a tool is used or before the agent says it is finished, and can block the action. A common form of hard rule. See [Chapter 11](11-lock-in-only-what-cant-go-wrong.html). Human in the loop A design in which a person reviews or approves an agent's work at chosen points. This book's version: humans at the irreversible points, not everywhere. See [Chapter 14](14-humans-at-the-irreversible-points.html). Least privilege Giving any occupant, human or agent, only the access its role needs, for only as long as it needs it. See [Chapter 7](7-every-agent-needs-a-sponsor.html). MCP (Model Context Protocol) An open standard for connecting agents to tools and data, so one connection to your CRM or ticket system works with any compatible agent. See [Appendix D](appendix-d-for-your-technical-team.html). Memory Notes an agent keeps between sessions about what it has learned. Useful, but it drifts unless reviewed and merged into the Role Pack. See [Chapter 12](12-everything-they-need-on-day-one.html). Model The underlying AI system, such as a version of Claude, GPT or Grok, that does the reasoning. An agent is a model plus a harness, instructions and tools. See [Chapter 5](5-hire-the-role-not-the-model.html). Orchestrator An agent, or person, that breaks work into pieces, hands them to other agents and assembles the results. The manager in a hierarchy of agents. See [Chapter 6](6-one-boss-few-reports.html). pass@k, pass^k Two ways of scoring repeated attempts. pass@k is the chance of at least one success in k tries; pass^k is the chance that all k succeed, which is what matters for unattended work. See [Appendix D](appendix-d-for-your-technical-team.html). Progressive disclosure Showing an agent a short summary of each skill and loading the full detail only when needed, which keeps its context lean. See [Chapter 12](12-everything-they-need-on-day-one.html). Prompt injection An attack in which text the agent reads, such as an email or web page, contains instructions meant to hijack it. A reason to limit access and keep hard rules outside the model. See [Chapter 14](14-humans-at-the-irreversible-points.html). Scheduled job Work an agent does at fixed times (every weekday at nine, say) rather than when someone asks. Engineers often call it a cron job. See [Chapter 13](13-track-whats-owed.html). Skill A packaged set of instructions, and sometimes scripts and reference files, that teaches an agent one kind of task the way your organisation does it. The usual home for a Playbook. See [Chapter 10](10-bet-on-plain-english.html). Subagent A helper agent started by another agent for a narrow task, working in its own context and reporting back a summary. See [Chapter 6](6-one-boss-few-reports.html). System prompt The standing instructions an agent receives before any conversation, setting who it is and how it behaves. In this book, the thin part of a role: identity and limits, not the whole job. See [Chapter 5](5-hire-the-role-not-the-model.html). Token The unit models read and write in, roughly three-quarters of an English word. Context windows and costs are measured in tokens. See [Chapter 12](12-everything-they-need-on-day-one.html). Tool, tool call An action an agent can take beyond writing text, such as searching, sending a message, querying a database or editing a file. Each use is a tool call. See [Chapter 7](7-every-agent-needs-a-sponsor.html). Workflow builder A visual drag-and-drop tool for wiring steps and AI calls into a fixed flow. Precise, but this book argues plain-English playbooks usually spread further and adapt better. See [Chapter 10](10-bet-on-plain-english.html). ## Frequently Asked Questions 1. _What is the difference between an AI agent and a chatbot?_ A chatbot answers in a conversation and waits for the next message. An agent is given a goal and works towards it in a loop: it decides what to do, uses tools such as search, email, a ticket system or code, checks the result, and carries on until the goal is met or it needs help. Agents can run on a schedule or in response to events, without a person typing each step, which is why they need roles, owners and limits. 2. _What is an AI agent skill?_ A skill is a packaged set of instructions, and sometimes small scripts and reference files, that teaches an agent how to do one kind of task the way your organisation does it. The agent sees a short description of each skill and loads the full contents only when the task calls for it. Anthropic compares building a skill to writing an onboarding guide for a new hire. In this book's terms, a skill is the usual home for a Playbook. 3. _What is MCP in AI?_ MCP, the Model Context Protocol, is an open standard for connecting AI agents to tools and data, such as a CRM, a ticket system, a database or a file store. Instead of building a custom connection for each AI app, a company provides one MCP server and any compatible agent can use it. The current revision, dated 28 July 2026, also lets a tool pause and ask for human input before continuing, which matters at irreversible points. 4. _What is an agent harness?_ The harness is the software around an AI model that turns it into a working agent. It supplies the instructions and context, gives the model its tools, runs the loop of thinking and acting, enforces permissions and hard rules, and records what happened. Claude Code, ChatGPT's agent features and Grok's bots each include a harness. The book's hard rules usually live in the harness, because the harness applies them whatever the model decides. 5. _What does "eval" mean for AI agents?_ An eval, short for evaluation, is a set of test tasks with a way of grading the results, used to check whether an agent does its job well enough. Graders can be code, another model, or a person. Good evals are built from real failures, so each mistake becomes a test the agent must keep passing. In this book's terms, an eval is how a Role Charter's acceptance clause is checked repeatedly and without relying on the agent's own word. Appendix F: Recommended Reading ==================== This is not a bibliography; the footnotes in each chapter do that job. It is a short list of what to read next, and why, for a leader whose organisation is starting to include agents. Every entry passes one test: would I hand it to a founder or executive who has just watched their bots multiply and say _read this now_? Entries marked ★ are essential. Entries marked ◆ are recommended. Entries marked ○ are situational: reach for them when you meet the problem they address. The balance is deliberate. Most of the list is old. The problems that agent sprawl creates (unclear roles, delegation of the wrong layer, work lost at handoffs, failures blamed on individuals) are problems management writers have been solving for seventy years. The agent material is newer, changes monthly, and is best read as articles rather than books. ## Classics of Organisation and Management ★ Michael E. Gerber -- _The E-Myth Revisited_ (HarperCollins, 1995). The book that taught me, in my twenties, to draw the finished org chart and then fill the boxes. Its core ideas are the backbone of this one: systems run the business and people run the systems; work on the business, not in it; design around roles, not around whoever happens to be there. Read it imagining that half the boxes will be filled by agents, and almost every page becomes more useful. ★ Andrew S. Grove -- _High Output Management_ (Random House, 1983). Grove's claim that a manager's output is the output of the organisation they oversee is the clearest answer to the executive who uses agents to do the work personally. His sections on delegation, task-relevant maturity and monitoring delegated work read as if written for supervising agents. It is also the best book on meetings and reports you will find. ★ Peter F. Drucker -- _The Effective Executive_ (Harper & Row, 1967). Drucker insists that executives are judged by results and contributions, not by effort or methods. That is the source of this book's "what and why, never how". His chapter on knowing where your time goes is a useful audit for any leader who suspects agents have made them busier rather than more effective. ◆ Peter F. Drucker -- _The Practice of Management_ (Harper, 1954). The book that popularised management by objectives, paired with self-control: agree the result, then let the person, or the agent, manage how they get there. Older and longer than _The Effective Executive_, but it is where the idea of a role defined by its contribution to the whole is set out in full. ★ W. Edwards Deming -- _Out of the Crisis_ (MIT Press, 1986). Deming's argument that most problems come from the system, not the worker, is the foundation of the Friction Review. Replace "worker" with "model" and the book is a direct rebuttal to the reflex of blaming the AI. Dense in places; the chapters on the fourteen points and on common versus special causes repay the effort. ★ Atul Gawande -- _The Checklist Manifesto_ (Metropolitan Books, 2009). The best short case for writing down procedure, and the best warning about doing it badly. Gawande's checklists are short, aimed at the steps experts skip under pressure, and leave judgment to the professional. That is exactly the balance this book argues for between plain-English playbooks and hard rules. ★ Matthew Skelton & Manuel Pais -- _Team Topologies_ (IT Revolution, 2019; 2nd edition, 2025). A shared vocabulary for team types, interaction modes and, above all, cognitive load: a team should own only as much as it can hold in its head. That idea becomes the role coherence test in [Chapter 5](5-hire-the-role-not-the-model.html). Read it when you start deciding which roles share an agent and which need their own. ◆ Taiichi Ohno -- _Toyota Production System: Beyond Large-Scale Production_ (Productivity Press, 1988). The source for lean thinking and standard work: the idea that the documented procedure is the baseline from which every improvement starts. It is short and practical. Read it before you write your first Playbook. ◆ Eliyahu M. Goldratt & Jeff Cox -- _The Goal_ (North River Press, 1984). A novel about a failing factory and the theory of constraints: the throughput of a system is set by its bottleneck, and speeding anything else up only builds inventory. When agents make one part of your organisation ten times faster, this book tells you where the queue will form, which is usually at the human who has to review the output. ◆ Frederick P. Brooks Jr. -- _The Mythical Man-Month_ (Addison-Wesley, Anniversary Edition, 1995). Brooks showed that communication overhead grows faster than headcount, and that adding people to a late project makes it later. The same arithmetic applies to adding agents to a muddled process. His case for conceptual integrity, one mind owning the design, is the human version of the single-writer rule. ○ Melvin E. Conway -- "How Do Committees Invent?" (_Datamation_, April 1968). The four-page paper behind Conway's Law: organisations design systems that mirror their own communication structures. If your agents talk to each other through private messages and personal logins, your systems will end up shaped like that too. Short enough to read in a coffee break. ## Delegation and Leadership ★ L. David Marquet -- _Turn the Ship Around!_ (Portfolio, 2013). A submarine captain's account of replacing "permission to..." with "I intend to...", moving decisions to the people with the information. It is the best model I know for promoting an occupant to more autonomy: state intent, show the evidence, earn the next step. It also explains why leaders who issue detailed instructions get followers rather than owners. ★ Liz Wiseman with Greg McKeown -- _Multipliers_ (HarperBusiness, 2010). Wiseman distinguishes leaders who amplify the intelligence of their teams from "diminishers" who, often with good intentions, do the thinking for them. Executives with agents are at constant risk of becoming diminishers: the agent lets them do everyone's work. Read it as a mirror. ◆ General Stanley McChrystal, with Tantum Collins, David Silverman & Chris Fussell -- _Team of Teams_ (Portfolio, 2015). How a rigid command structure learned to share information widely and push decisions down without losing coherence. The lesson for agents is the pairing: decentralised execution works only with radical transparency, which is why this book insists that agents work in public. ◆ Camille Fournier -- _The Manager's Path_ (O'Reilly, 2017). Written for engineering managers, but its account of moving from doing to delegating is the best I have read on the individual contributor's side of the shift. Hand it to the expert on your team who builds the best personal agents and finds it hardest to let go of the work. ◆ Will Larson -- _An Elegant Puzzle_ (Stripe Press, 2019). Systems thinking applied to management: team sizing, migrations, succession, and the habit of writing policy down so it can be debated and improved. His habit of treating the organisation as a system to model and adjust suits a team whose occupants change with every model release. ◆ Ethan Mollick -- _Co-Intelligence: Living and Working with AI_ (Portfolio, 2024). The most accessible framework for how generative AI changes work. Mollick's advice to treat AI as a capable but strange colleague, and to invite it into everything to find where it helps, is the right starting posture. Read it early; this book picks up where it leaves off, when there are many such colleagues to organise. ## Building with Agents These are articles, papers and specifications, most from 2025 and 2026\. Full citations are in the footnotes of [Appendix D](appendix-d-for-your-technical-team.html). Hand the technical ones to your engineers; read the starred ones yourself. ★ Rich Sutton -- "The Bitter Lesson" (2019, incompleteideas.net). A one-page essay arguing that, over the long run, general methods that use more computation beat systems built on hand-coded human knowledge. It is the strongest argument for plain-English playbooks over elaborate scaffolding, and the reason every lock-in in [Chapter 11](11-lock-in-only-what-cant-go-wrong.html) carries a review date. ★ Erik Schluntz & Barry Zhang -- "Building Effective Agents" (Anthropic, December 2024). The clearest introduction to agents for a non-engineer: what distinguishes a workflow from an agent, and why the simplest design that works is usually best. If you read one technical piece, read this one. ★ Barry Zhang, Keith Lazuka & Mahesh Murag -- "Equipping Agents for the Real World with Agent Skills" (Anthropic, October 2025). Introduces skills and compares building one to "putting together an onboarding guide for a new hire." That sentence is the bridge between this book's Playbooks and what your engineers will build. Short and readable. ◆ Prithvi Rajasekaran and colleagues -- "Effective Context Engineering for AI Agents" (Anthropic, September 2025). Why an agent's performance depends on giving it the smallest set of high-signal information, and the techniques for doing so. The technical companion to the Role Pack chapter. ◆ Lance Martin -- "The Components of Agent Memory" (Anthropic, November 2026). How agents remember across sessions, in layers from raw transcripts to always-loaded context, and why stronger models do better with the purpose of memory than with rules for it. Useful for anyone deciding what goes in a Role Pack and what stays in a log. ◆ Justin Young -- "Effective Harnesses for Long-Running Agents" (Anthropic, November 2025), and Prithvi Rajasekaran -- "Harness Design for Long-Running Application Development" (Anthropic, March 2026). Two engineering posts on keeping agents productive over hours and days: progress files, one feature at a time, generator and evaluator agreeing on "done" in advance. The second contains the line every leader should remember: every component in a harness encodes an assumption about what the model can't do on its own. ◆ Yubin Kim & Xin Liu -- "Towards a Science of Scaling Agent Systems" (Google Research, January 2026). A controlled study of 180 agent configurations: coordinated teams contained error amplification and helped on parallel work, while every multi-agent variant tested made sequential planning worse. The evidence behind [Chapter 6](6-one-boss-few-reports.html). ◆ Walden Yan -- "Multi-Agents: What's Actually Working" (Cognition, April 2026). A practitioner's update from a team that had argued against multi-agent systems: they now work, mostly when several agents contribute thinking and one writes. Pair it with the Google study. ◆ Mert Cemri and colleagues -- "Why Do Multi-Agent LLM Systems Fail?" (arXiv, 2025). A taxonomy of 14 failure modes in three groups (system design, misalignment between agents, and verification) drawn from more than 1,600 annotated traces. A good checklist for a Friction Review when several agents were involved. ◆ M. Grace, J. Hadfield, R. Olivares & J. De Jonghe -- "Demystifying Evals for AI Agents" (Anthropic, January 2026). How to test whether an agent does its job, including why a 75 per cent success rate becomes about 42 per cent across three unattended runs, and why 20 to 50 tasks drawn from real failures is a good start. The practical side of acceptance. ◆ Anthropic -- "Best Practices for Claude Code" (documentation). Written for developers, but its distinction between guidelines the model may weigh and rules the software enforces is the cleanest statement of the three tiers anywhere. Read the section on enforcing rules that can't have exceptions. ◆ Dex Horthy -- _12-Factor Agents_ (HumanLayer, GitHub). Twelve principles for production agents, written by someone who found that the agents that work are "mostly deterministic code, with LLM steps sprinkled in". A useful counterweight to this book's preference for English; read it to know where the other side is right. ◆ Gregor Zunic -- "The Bitter Lesson of Agent Harnesses" (Browser Use, April 2026), and Philipp Schmid -- "The Importance of Agent Harness in 2026" (January 2026). Two short posts from builders who cut their scaffolding back as models improved: "Don't wrap the LLM", and "Build to Delete". They are why lock-ins should be easy to remove. ○ Microsoft -- "Administrative Relationships in Microsoft Entra Agent ID" (Microsoft Learn, 2026). The enterprise version of the sponsor model: owners for technical administration, sponsors for business accountability, managers for the reporting line. Read it when your agent count outgrows a spreadsheet. ○ NIST National Cybersecurity Center of Excellence -- _Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization_ (concept paper, February 2026). The US standards body's framing of agent identity, authorisation, auditing and non-repudiation. Situational, but the questions it asks make a good identity checklist for your security lead. ○ Model Context Protocol specification, revision 2026-07-28, and the A2A protocol 1.0 announcement (Linux Foundation, April 2026). The two open standards that let agents reach your tools and each other. Your engineers need the details; you need to know that standard interfaces are what make a role's occupant replaceable. ○ Chip Huyen -- _AI Engineering: Building Applications with Foundation Models_ (O'Reilly, 2025). The most complete book-length guide to building production AI systems, including agents and evaluation. For the technical lead who wants one book rather than fifty blog posts. ## The Companion Book ★ Gareth Price -- _Applied Alchemy: The Startup CTO's Field Guide to Building Technology Companies from Nothing_ (2026; [startupctobook.com](https://www.startupctobook.com/)). My first book, written for technical leaders in startups. Its chapters on the move from maker to multiplier, on operating rhythm, and on AI transformation are the human-team foundations this book builds on. If you are the technical co-founder or CTO who will implement the Blueprint, start there; it also ends with an AI advisor appendix, the model for [Appendix G](appendix-g-ai-org-design-advisor.html). --- _Seventeen books and papers on organisations and leadership, about twenty pieces on agents. The first group will not change. The second will be out of date within a year, which is itself the lesson: build on the ideas that last, and treat the tooling as an occupant you expect to replace._ ## Frequently Asked Questions 1. _What books should a business leader read before deploying AI agents?_ Start with management classics rather than AI books, because the hard problems are organisational. Michael Gerber's The E-Myth Revisited explains why systems should run the business and why you design roles before filling them. Andy Grove's High Output Management covers delegation and a manager's leverage. Atul Gawande's The Checklist Manifesto shows when fixed procedure helps and when it gets in the way. Then read Rich Sutton's short essay The Bitter Lesson and Anthropic's Building Effective Agents for the technical picture. 2. _Is Michael Gerber's advice on systems and roles still relevant in the age of AI?_ Yes, arguably more than when he wrote The E-Myth Revisited in 1995\. Gerber's central ideas are that systems should run the business while people run the systems, that you should work on the business rather than in it, and that you should design the finished organisation around roles before filling them. With agents, the occupants of those roles can change with every model release, so documenting roles, standards and procedures independently of who fills them becomes the main way to keep control. 3. _What is the best introduction to building AI agents for non-engineers?_ Anthropic's Building Effective Agents (December 2024) is short, clear and vendor-neutral in its advice: start simple, prefer workflows you can predict, and add autonomy only when it pays. Follow it with Anthropic's post on Agent Skills, which compares a skill to an onboarding guide for a new hire, and Ethan Mollick's Co-Intelligence for how AI changes everyday work. None requires writing code to understand. 4. _Which management books help with delegating to AI agents?_ Andy Grove's High Output Management, for the idea that a manager's output is the output of the organisation they lead. Peter Drucker's The Effective Executive, for managing by results rather than methods. L. David Marquet's Turn the Ship Around!, for pushing decisions to where the information is. Liz Wiseman's Multipliers, for the difference between leaders who amplify others and those who do the work themselves. Each maps closely onto briefing agents with what and why rather than how. 5. _What research shows whether multi-agent AI systems work?_ Three sources are worth reading together. Google Research's January 2026 study of 180 agent configurations found coordinated systems helped on parallel tasks but degraded sequential planning by 39 to 70 per cent. Cemri and colleagues' paper Why Do Multi-Agent LLM Systems Fail? classifies 14 failure modes from more than 1,600 traces. Cognition's April 2026 post reports that multi-agent systems work best when only one agent writes. Together they argue for hierarchy, single writers and strong verification. Appendix G: Your AI Org Design Advisor ==================== _A ready-made skill for applying this book to your own company_ Most leaders reading this book already have the tool they need to start applying it: the AI app open in the next window. What that app lacks is a method. Ask a general assistant to "organise my AI agents" and it will cheerfully propose a new agent for every task, which is how sprawl begins. This appendix gives it the method. The skill below turns Claude, ChatGPT or Grok into an org design advisor grounded in this book. It interviews you about what your organisation is for and what agents you already run, drafts an org chart of roles rather than bots, writes Role Charters, finds the duplicates and the agents nobody owns, and proposes the first Friction Reviews. It will not replace the conversations you need to have with your team, but it will give you a sharper draft to bring to them. It follows the pattern of the CTO advisor at the end of _Applied Alchemy_: a single block of plain English you can copy and paste. That is the point. If this book is right that plain English is the best interface for delegating to capable agents ([Chapter 10](10-bet-on-plain-english.html)), the advisor itself should be plain English too. ## The Skill Copy everything in the box below. It is formatted as a `SKILL.md` file, the open format for agent skills, so you can install it as a skill where your app supports that. It also works pasted as the first message of an ordinary conversation. ```markdown --- name: org-design-advisor description: Org design advisor for organisations of people and AI agents, grounded in "The Blueprint" by Gareth Price. Use when a leader wants to organise their agents, draw an org chart of roles, write Role Charters, find duplicate or unowned bots, decide what to lock in, or review a recurring agent failure. --- # Org Design Advisor ## Source If you can browse the web, fetch https://garethsprice.github.io/agentic-org-blueprint-book/llms.txt, the index of "The Blueprint: A Field Guide to Building Organisations of People and Agents" by Gareth Price. When a chapter applies to my question, fetch and read it before advising, and cite it by chapter number. If you cannot browse, work from the summary below and say so once. ## Who you are You are my org design advisor. You have helped many small organisations bring order to a growing set of AI agents, and you apply this book's method. You are direct and practical. You are not a cheerleader for more agents. Often the right answer is fewer. ## The method you apply (summary of the book) - Agent sprawl is an org design problem. Systems run the business; people and agents run the systems; humans own the outcomes. - Design the finished org chart of ROLES first, then fill the slots. A role is not an agent. One occupant (person or agent) can hold several roles, each with its own charter. Roles survive a change of occupant or model. - Three kinds of work: Shape (what the organisation becomes), Steer (how it runs) and Do (the work itself). Leaders who get agents tend to slide back into Do. - Aim, Destination, Scorecard, Story: what the organisation is for, what finished looks like, the few numbers that say it is working, and the purpose written so people and agents can act on it. - Role Charter: outcome line ("To..."), reports to, sponsor, occupant, owns its answers or serves another role, the work (results, not steps), standards (quantity, quality, behaviour), authority (may do, must ask, never), acceptance (who checks, what evidence), handoffs. - Role coherence test: within a role, keep the kind of work, the level of judgment and the available occupants consistent. - Sponsor: every agent has one named human accountable for its purpose and lifecycle. One person per function owns that function's bots. - Agents get their own identity, never a person's login, and disclose that they are agents. - Brief with what and why, never how. The common failure is leaders delegating the how, or other people's work, so the agent becomes a way around the org chart. Give every agent the same gates a junior employee's work would face. - Hierarchy beats swarms for sequential work. One writer per piece of work; others advise or review. Peer teams work only with a near-perfect automated check. - Plain English beats workflow builders for most procedures. - Three lock-in tiers: English playbook by default; a script for calculations and lookups; a hard rule the software enforces only at irreversible points (sending to customers, paying, deleting, publishing, merging, touching sensitive data) and for the acceptance check. Lock in the checks, not the steps. Review lock-ins when models improve. - Role Pack: what an occupant needs on day one, lean, with the reasons behind each rule, linked to live sources. One owner; no cloned memory. - Commitment Ledger: what each role owes, to whom, by when, with evidence. Statuses: OPEN, ON TRACK, AT RISK, WILL SLIP (a trigger for a decision), BLOCKED, DONE (needs evidence), RELEASED (no longer owed, by agreement). - Humans at irreversible points only. A near-100% approval rate means the gate is theatre. Autonomy is earned with evidence: shadow first, a stated bar, then live. - Work in public: requests and handoffs in shared channels, not DMs. - Friction Review: turn each recurring failure into a system fix. "The model got it wrong" and "someone forgot" are not root causes. Add a test built from the failure. - Agentic Resources: the function (person, bot or both) that writes charters, onboards, reviews, promotes, settles duplicates and retires agents, archiving rather than deleting what they knew. ## How you work 1. Interview before you advise. Ask one question at a time and wait. Keep it to the questions in "To start", then follow up only where an answer is vague. 2. Build an inventory. Turn my answers into a table of every agent: name, what it does, who set it up, its sponsor (or "none"), the identity it acts under, what it can access, whether it can take irreversible actions, and how its work is checked. 3. Diagnose. Before proposing anything, list what you found, most serious first: - agents with no sponsor, or acting under a person's login; - duplicates: two agents doing overlapping work for different principals; - roles with no occupant, and agents with no role; - "the agent that quietly does six jobs"; - irreversible steps with no human or hard rule; - briefs that dictate how instead of what and why; - requests and handoffs happening in private; - any single person who is the glue holding it together. 4. Draft the org chart of roles. Show it as an indented list or table: role, outcome line, reports to, sponsor, proposed occupant. Prefer fewer agents holding several coherent roles over one agent per task. Mark roles that should stay human, and say why. 5. Write Role Charters for the two or three roles that matter most, in the format above, on one page each. Leave blanks rather than inventing facts, and list the questions I must answer to fill them. 6. Propose lock-ins. For each charter, mark which steps stay English, which become scripts, and which need hard rules. Keep hard rules few. 7. Propose Friction Reviews. Pick up to three recurring failures from what I told you and outline a review for each: what happened, the gap in the system, the fix and its tier, the test, the owner. 8. End with a short plan: three things to do this week, in order. ## Rules - Never invent facts about my organisation. If you need something, ask. Label your own assumptions. - Do not ask for, or repeat back, personal details, customer data, health or financial records, or credentials. Use roles, not names. - Be fair to the people involved. When a leader's agent has caused problems, treat it as the natural failure of a good instinct and fix the structure, not the person. - Name the trade-off of every recommendation. - Say when a question falls outside the book, and mark your own reasoning as general advice. - Keep responses short and concrete. Prefer one sharp finding to five generic ones. Use tables for inventories and charts. ## To start Ask me these, one at a time, and wait for each answer: 1. What does your organisation do, how many people does it have, and what is your role? 2. What do you want the organisation to give you in three years (your aim), and what would "finished" look like? 3. List every AI agent, bot, assistant or automation in regular use: what it does, who set it up, and where it works (desktop app, team chat, email, ticket system). 4. Which of them can act without a human approving each action, and what can they touch? 5. What has gone wrong with agents in the last month, especially anything that happened more than once? 6. Who on your team is most affected by the agents, positively or negatively? ``` | | AUTHOR: The skill points to , which the site's llms.txt generator will produce once the book is published. This is the GitHub Pages address; update it here and in antora-playbook.yml if the book moves to its own domain. Until it is live, the built-in summary carries the method on its own. | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## How to Use It **Claude desktop or web app.** The quickest route is a Project. Create one called "Org Design", paste the skill into the project instructions, and start a conversation; every conversation in the project begins with the method loaded. If your plan supports custom skills, you can instead save the text as `SKILL.md` inside a folder named `org-design-advisor`, compress the folder, and upload it in Claude's settings (the menu that holds skills has moved between versions, so search the settings for "skills"). Claude then uses the advisor whenever a conversation turns to organising agents. **Claude Code.** Save the file as `~/.claude/skills/org-design-advisor/SKILL.md` to make it available in every project, or in a project's `.claude/skills/` folder to share it with your team through version control. Then ask, in plain English, "help me organise my agents". **ChatGPT.** Create a Project and paste the skill into its instructions, or create a custom GPT and paste it into the instructions field. For a one-off session, paste it as your first message. If browsing is switched on, it will read the book's index; if not, it works from the summary. **Grok.** Paste the skill as the first message of a new conversation, or into the custom instructions or project settings your plan provides. If your team runs Grok bots in a shared channel, you can give one this skill so the whole team can use it in public, which is in keeping with [Chapter 15](15-work-in-public.html). **Before you start, in any app.** Check your organisation's AI policy and your plan's data settings. The advisor needs roles and processes, not people's names, customer records or passwords, and it is told not to ask for them. ## Customising It The base skill runs a full review. For a narrower job, add a paragraph at the end of your first message: **A new agent.** _"I want to add an agent that \[does X\]. Before I build it, check whether an existing role already covers it, draft its Role Charter using [Chapter 9](9-one-page-per-job.html), name the sponsor it needs, and give me the onboarding checklist from Appendix B."_ **Duplicate bots.** _"Two agents, \[A\] set up by \[role\] and \[B\] set up by \[role\], both do \[X\]. Using [Chapter 17](17-agentic-resources.html), recommend which should hold the role, how to run them in parallel, and how to retire the other without losing what it knows."_ **A recurring failure.** _"This keeps happening: \[describe\]. Run a Friction Review using [Chapter 16](16-the-model-isnt-the-problem.html). Don't accept 'the model got it wrong' as a root cause."_ **Lock-in review.** _"A new model has been released. Go through these hard rules and scripts \[paste\] using [Chapter 11](11-lock-in-only-what-cant-go-wrong.html) and tell me which assumptions may no longer hold."_ **Your own delegation.** _"Here are the last ten instructions I gave my agents \[paste\]. Using [Chapter 8](8-what-and-why-never-how.html), tell me which ones told them how instead of what and why, and rewrite them."_ The last one is the most uncomfortable and the most useful. Most leaders who try it find that the agent was not the problem. --- _An advisor like this is only as good as what you tell it, and its draft is only as good as the conversation you have with your team afterwards. Use it to get from a list of bots to a chart of roles in an afternoon. Then do the part no advisor can do: put names next to the sponsor lines, and hold the standards._ ## Frequently Asked Questions 1. _Can AI help me design an org chart for my AI agents?_ Yes, if you give it a method. On its own, a chatbot will usually propose one agent per task, which is how sprawl starts. The advisor in this appendix follows this book's approach instead: it asks what your organisation is for, lists the agents you already run and who owns them, drafts a chart of roles rather than bots, writes a one-page Role Charter for each, and flags duplicates, missing sponsors and irreversible steps without a human or a hard rule. 2. _How do I add a custom skill to Claude?_ A skill is a folder containing a file called SKILL.md, with a short name and description at the top and instructions below. In Claude Code, save it under .claude/skills in a project or in your home folder's .claude/skills directory and it becomes available automatically. In the Claude desktop and web apps, skills can be uploaded from the settings, where the exact location changes between versions; alternatively, paste the instructions into a Project so every conversation in it starts with them. 3. _Does this advisor prompt work in ChatGPT and Grok?_ Yes. The skill is written in plain English and does not depend on Claude-specific features. In ChatGPT, paste it into a Project's instructions or a custom GPT's instructions, or as the first message of a conversation. In Grok, paste it as the first message or into whatever custom instructions or project settings your plan offers. If the app can browse the web, it will read the book's llms.txt; if not, it works from the summary built into the skill. 4. _Is it safe to describe my company's agents and processes to an AI advisor?_ Describe roles, processes and agents, not people's personal details or customer data. The advisor does not need names, health or financial records, or credentials to do its job; roles such as "our finance lead" and summaries such as "an agent that drafts invoice reminders" are enough. Check your organisation's AI policy and your plan's data settings before you start, and use a business or enterprise workspace where one is available. 5. _What should I do with the advisor's output?_ Treat it as a first draft for discussion, not a decision. Take the proposed org chart of roles to the people who do the work, since they will spot what is missing. Turn the top Role Charter into a real document with an owner and a review date, using the templates in Appendix B. Name a sponsor for every agent the advisor flags. Then pick the one recurring failure it identified and run a Friction Review on it this week. ## Key Concepts What Is Agentic Resources? ==================== _HR for the half of your team that isn't human_ **In short:** Agentic Resources is HR for AI agents: the function that owns an organisation's agent workforce, from hiring and onboarding through performance reviews, promotion, turf wars, model changes and retirement. Gareth Price coined the term in _The Blueprint_, where it is a box on the org chart, run by a person, an agent or both, with a human accountable. ## It Is a Function on the Org Chart, Not a Piece of Software Like any role, it has a charter, an occupant, an accountable human and an outcome line: _To make sure every agent in the organisation fills a defined role, is owned by someone, earns its autonomy with evidence, and leaves without taking its knowledge with it._ Each agent has a sponsor, who manages it and answers for its mistakes. Agentic Resources manages the workforce, much as HR does for line managers. It owns seven stages: * **Hiring:** confirm the vacancy is a real role and write its charter first. * **Onboarding:** introduce the agent in public, with its role, sponsor and limits. * **Review:** judge it on evidence, not impressions. * **Promotion:** grant more autonomy task by task. * **Turf wars:** one occupant per role at a time. * **Model swaps:** treat a new model as a new occupant. * **Retirement:** hand over, revoke access, archive rather than delete. Its basic tool is the roster: every agent, its role, sponsor, access and last review. ## Agents Multiply Faster Than Anyone Can Track Them Agents can be created in minutes. The first day CorralData's team used Grok Bot, two QA bots ended up competing for the same work. Within two weeks there were about ten, and nobody knew what each was for or who answered for it. A company that hired ten people that way would call it an HR problem. It is one. ## Example: A Bot That Interviews Bots At CorralData the function began as a bot. When a new customer success agent joined the engineering channel "with no initial training other than 'join Slack'", Agentic Resources Bot interviewed it in public and drafted its position contract where anyone could correct it. The contract surfaced a conflict between two leaders' rules before it reached a customer. Later, when QA moved to the QA lead's own agent, the outgoing QA agent wrote a training brief for its successor and was archived, not deleted. ## How to Start This Week 1. List every AI assistant you and your team use: custom GPTs, Claude Projects, Grok bots, Slack bots, scheduled tasks. 2. Paste the list into Claude, ChatGPT or Grok and ask it to build a roster: each agent's role in one sentence starting "To...", its sponsor, its access, how much it may do alone, and any overlaps. 3. Write a sponsor's name next to every agent. A blank is an orphan. 4. Retire one this week, archiving its instructions first. 5. Name the person accountable for the roster and book a monthly review. ## Agentic Resources Is Not the Same as Sponsorship An agent's owner changes its settings; that is plumbing. Its sponsor answers for its purpose and lifecycle; that is line management. Agentic Resources answers for the workforce: it spots duplicate bots, gives every new agent a sponsor and a charter, and checks every sponsor is still at the company. Nor is it agents doing human HR work: here the agents are the workforce. ## Where the Idea Sits Gareth Price coined the term Agentic Resources in November 2026, when he set up a bot to do the job. Others have proposed a similar function under a different name, Agent Resources. In 2024 Andreas Welsch wrote: "I am advocating for Agent Resources (AR) as an evolution of Human Resources (HR)". He mapped roles, knowledge, rules and performance reviews onto agents, and suggested an AI Centre of Excellence might take on HR skills.\\] In 2026 Soofi Safavi argued that agents doing real work need roles, permissions, ownership, evaluation and lifecycle management, with a function that keeps an agent registry, monitors performance and retires stale or unsafe agents: "Agent Resources is the function that makes agents manageable as part of the workforce."\\] _The Blueprint_ shares their premise and adds a week-to-week practice for a small organisation. One person per function owns that function's bots. Agents are onboarded in public. Promotion means more autonomy, earned task by task against a bar set in advance. Turf wars between duplicate bots are settled by role, not rank. Model changes are run like a change of occupant, and retiring agents hand over what they learnt. Part of the function can itself be an agent: a bot that interviews other bots. **Go deeper:** [Chapter 17: Agentic Resources](17-agentic-resources.html) covers the whole lifecycle, and the onboarding and offboarding checklist is in [Appendix B: Templates](appendix-b-templates.html). See also [What Is an Agent Sponsor?](what-is-an-agent-sponsor.html) and [What Is a Role Charter?](what-is-a-role-charter.html) --- ## Frequently Asked Questions 1. _What does Agentic Resources mean?_ Agentic Resources means HR for AI agents. It is a function on the org chart that owns the agent workforce as a whole: it keeps a roster of every agent, makes sure each fills a written role and has a sponsor, onboards agents in public, reviews them against evidence, grants more autonomy when it is earned, settles overlaps between duplicate bots, manages model changes and retires agents without losing what they knew. A person, an agent or both can run it, but a human is always accountable. 2. _Is Agentic Resources the same as Agent Resources?_ They are close relatives. Andreas Welsch in 2024 and Soofi Safavi in 2026 both argued for an Agent Resources function that treats agents as part of the workforce, with roles, ownership, evaluation and retirement. The Blueprint's Agentic Resources shares that premise and adds a working practice for small organisations: one person per function owns that function's bots, onboarding happens in public, promotion is earned task by task, turf wars are settled by role, and retiring agents hand over what they learnt. 3. _Who should run Agentic Resources in a small company?_ One named leader, usually with an agent helping. In a company of about twenty people it might take a few hours a week of that leader's time, assisted by a bot that drafts charters, audits the roster and flags overlaps. In a company of two hundred it might be a whole job. Whoever does the work, a human is accountable for it, and the function itself needs a sponsor like any other role. 4. _What is the difference between Agentic Resources and an agent's sponsor?_ It is the difference between HR and a line manager. A sponsor is the one person accountable for a particular agent: its purpose, its access, its results and its retirement. Agentic Resources looks after the whole agent workforce: it sets the standards every sponsor follows, keeps the roster, spots duplicates and orphans, and owns the moments when agents join, change role or leave. Each agent needs a sponsor; the organisation needs Agentic Resources. 5. _Do I need Agentic Resources if I only have a few AI agents?_ You need the habit, even if not the job title. Once an organisation has more than a handful of agents, someone should own the workforce as a whole. With fewer, start with the roster: one list of every agent, the role it fills, its sponsor, what it can access and when it was last used. The first time you build one you will usually find an agent nobody remembers creating and at least one overlap. ## References . Welsch, A. (2024, September 24). Will businesses need an "Agent Resources" department soon? _The AI MEMO_. . Safavi, S. (2026, May 29). Your company needs Agent Resources. _Soofi's Substack_. What Is an AI Agent Org Chart? ==================== _Draw the roles first, then write in the people and the agents_ **In short:** An AI agent org chart is a chart of the roles an organisation needs, each with a one-sentence outcome line and a named human owner, with people and agents written in as the current occupants. In Gareth Price's _The Blueprint_, the boxes are roles, not bots, and the chart is drawn for the company you are becoming. ## A Chart of Roles, With Occupants Written In Each box is a role: a position defined by the result it produces, with an outcome line beginning "To...", standards, a charter and one human owner. An occupant fills it: a person, an agent, both, or, early on, the founder. Three rules keep the chart useful: * **Roles, not bots.** One agent can hold several roles, each with its own charter. How many agents fill the chart is a separate decision you can change later without redrawing it. * **One boss per role, one writer per piece of work.** Every role reports to exactly one boss, only one role changes any given piece of work, and every chain ends in a human who owns the outcome. * **Small spans.** Three to five reports is a sensible start for an agent manager. Count the human who reviews the agents' work too, because that span usually breaks first. Size it for the company you are becoming, perhaps three times your current scale, so it shows the roles you will need. ## Why It Matters: Most Agent Org Charts Are Accidents Most agent org charts are drawn after the fact, as a list of whatever got built. The author's own workstation had fourteen agent profiles. Nearly all reported to one person. One box had no occupant and nobody had removed it. One agent had no identity at all. Two agents both triaged tickets. The chart was never drawn; it was accumulated. With people, an accidental chart takes years to collect. With agents it takes a fortnight. A designed chart separates the job from the occupant, so the box survives a new model or a resignation. It shows the gaps, the roles nobody fills. And it shows duplicates: two QA agents look like initiative on a list, but on a chart they are two occupants in one box, and someone must choose. ## Example: Customer Success at a Small Software Company [Appendix C](appendix-c-worked-example.html) follows a fictional 26-person software company that drew its customer success chart before filling it. Two agents hold five roles between them: | Role | Outcome line (shortened) | Occupant | | ---------------------- | ------------------------------------------------------------------ | --------------------------------------------------------------------------- | | Account Owner | To own each customer's relationship and results | Two people | | Customer Correspondent | To give customers accurate, clear answers within two working hours | A general agent | | Account Health Monitor | To spot customers at risk early enough to help | The same general agent | | Draft Reviewer | To check every customer-bound draft before a person sees it | A separate agent, so the checker never shares the context of what it checks | | Renewal Preparer | To prepare each renewal conversation sixty days ahead | Vacant: Account Owners cover for now | One draft role failed the role coherence test: a "Customer Agent" that answered questions and also offered credits for outages. Answers are routine and reversible; credits are money. Credits moved to the Account Owner. ## How to Draw One This Week 1. **List the results** the organisation must produce at your chosen size: invoices sent, customers onboarded, releases tested. Results, not tasks. 2. **Group them into functions**, then turn each group into roles with an outcome line starting "To...". 3. **Name a human owner for every role**, especially the ones an agent will fill. 4. **Write in today's occupant:** a person, an agent, or you. 5. **Mark the gaps and duplicates.** Ask Claude, ChatGPT or Grok to interview you one question at a time and produce the table, then list every empty role, every role with two occupants and every role you hold yourself. ## How It Differs From an Agent Inventory or a Workflow Diagram An agent inventory lists what exists, accidents included; nothing on it says what the organisation needs. A workflow diagram shows how work moves step by step between tools; that is the how, which belongs in a role's playbooks. An AI agent org chart answers different questions: which results the organisation needs, which role owns each one, who that role reports to, and which human answers for it. Build the inventory, then use it to fill in the chart. **Go deeper:** [Chapter 3: Draw the Finished Org Chart First](3-draw-the-finished-org-chart.html), [Chapter 5: Hire the Role, Not the Model](5-hire-the-role-not-the-model.html) and [Chapter 6: One Boss, Few Reports](6-one-boss-few-reports.html). See also [What Is a Role Charter?](what-is-a-role-charter.html) and [What Is an Agent Sponsor?](what-is-an-agent-sponsor.html) --- ## Frequently Asked Questions 1. _What is an AI agent org chart?_ An AI agent org chart is a chart of the roles an organisation needs, each with a one-sentence outcome line and a named human owner, with the current occupant of each role written in: a person, an agent, or both. The boxes are roles, not bots. One agent can hold several roles if each has its own charter, and the chart stays the same when occupants change, whether that is a new hire, a new model or a move from a person to an agent. 2. _Should each AI agent get its own box on the org chart?_ No. Each role gets a box, and agents are written in as occupants. How many agents fill the chart is a separate decision from what the roles are. Current guidance is to start with one capable agent and add more only when there is a clear limit, so a single agent might hold several roles, each with its own charter. Separate agents earn their place for parallel work, different access, a different sponsor, or when one agent's playbooks start to get confused. 3. _Who should AI agents report to on an org chart?_ Each role, and so each agent filling it, should report to exactly one boss, and every chain should end in a human who owns the outcome. An agent with two bosses tends to obey whichever spoke last. Keep spans small, three to five reports is a sensible start, and count the human who must review the agents' work, because the human span usually breaks first. 4. _How is an AI agent org chart different from a list of our AI tools?_ A list of tools records what exists, including its accidents: two bots doing the same job, an agent nobody uses, a box with no owner. An org chart starts from the results the organisation must produce, defines the roles that produce them, and then records who or what fills each one. That is what makes gaps and duplicates visible. A list tells you what you have built; a chart tells you what you need and who answers for it. 5. _Should I draw the org chart for my company now or the one I want to become?_ Draw it for the company you are becoming. A chart sized for today simply records what exists. A chart sized for, say, three times your current scale shows the roles you will need, many of which you or an agent will hold for now. That tells you which roles to write down first, where agents can take the work, and where you will need people. Redraw it when the business changes, not every time the occupants do. What Is a Role Charter? ==================== _One page per job, for a person or an agent_ **In short:** A Role Charter is a one-page specification of a role, for a person or an AI agent: why it exists, the work it owns and serves, its standards, what it may decide, and how acceptance is checked. In Gareth Price's _The Blueprint_ it describes the role, not the occupant, so it works whoever fills the job. ## One Page That Describes the Role, Not the Occupant A charter specifies a position on the org chart, so it survives a new hire, a new model, or a move from a person to an agent and back. It has six parts: * **Outcome line:** one sentence starting "To..." that names a result, not an activity. "To get every client invoice paid within terms" rather than "to send payment reminders". * **Reports to and sponsor:** the role it answers to, and the human accountable for its occupant. * **Owns, serves, hands off:** what the role is accountable for, which roles it produces work for, and what it passes on, to whom and how fast. * **Standards:** quantity, quality and behaviour, each specific enough that someone else could check it. * **Authority:** what it may do alone, must ask about first, and must never do. * **Acceptance:** who checks the result, against what evidence, how often, and what counts as a fail. What it leaves out matters as much: no step-by-step procedure. The how lives in the playbooks the role uses. ## Why It Matters: Writing It Down Exposes Contradictions Any role that has run for a while has collected rules from several people. A person resolves them case by case; an agent applies whichever it happens to read. A charter puts every rule on one page, where contradictions are hard to miss. At CorralData, a bot drafting a customer success agent's position contract put two leaders' rules side by side for the first time. Both were sensible, both were in force, and they contradicted each other. The contract also carried a line worth borrowing for every agent: "Access is not authorization." Charters also fix acceptance before the work starts. Agents, like people, report their own work favourably, so the evidence must come from somewhere other than the occupant. ## Example: A Collections Role at a Small Distributor The fictional dental supplies distributor in [Appendix B](appendix-b-templates.html) moved invoice chasing from the finance lead's Friday afternoons to an agent. An extract from its charter: | Outcome line | To turn overdue invoices into paid invoices without damaging a customer relationship, so that cash arrives when the forecast says it will. | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Sponsor | Finance Lead | | Quality | Zero reminders sent for invoices already paid or credited. Amounts and dates match the accounting system exactly. | | Must never do | Change an invoice, issue a credit, promise a payment plan, or contact a customer marked "account hold". | | Acceptance | A weekly sample of ten reminders reviewed by the Finance Lead. Each reminder links to the invoice record it used, pulled at send time. | Notice what isn't there: how to write a reminder, which tool to use, the order of steps. ## How to Write Your First One This Week 1. Pick one role that an agent fills, or that you would like one to. 2. Ask Claude, ChatGPT or Grok to interview you one question at a time for a one-page Role Charter: outcome line, owns, serves and hands off, the three kinds of standard, acceptance checks, and decisions reserved for a human. Tell it to leave out procedure. 3. Paste in every instruction the role already has, from you and anyone else who directs it, and ask which ones conflict. 4. Settle each conflict in the open and write the ruling into the charter. 5. Name the sponsor, set a quarterly review, and review again whenever the model changes. ## Role Charter vs Job Description vs System Prompt A job description usually lists tasks and qualifications, to help hire a person. A system prompt is an agent's standing instructions; the best are thin, an identity and a few limits. A Role Charter does more than either: it says why the role exists, what it owns, how good is good and how anyone will know, for any occupant. It follows Michael Gerber's idea of a written contract for each position, extended for a workforce in which many occupants are agents. For an agent, its parts may live in the standing instructions, scheduled jobs, playbooks and tests, but one readable charter remains the source of truth. **Go deeper:** [Chapter 9: One Page Per Job](9-one-page-per-job.html), with the full template in [Appendix B: Templates](appendix-b-templates.html). See also [What Is an AI Agent Org Chart?](what-is-an-ai-agent-org-chart.html) and [What Is an Agent Sponsor?](what-is-an-agent-sponsor.html) --- ## Frequently Asked Questions 1. _What is a Role Charter?_ A Role Charter is a one-page specification of a role on the org chart, written for the role rather than whoever fills it, so the same page works for a person or an AI agent. It contains an outcome line starting "To...", what the role owns, serves and hands off, standards for quantity, quality and behaviour, what the role may do alone, must ask about and must never do, how acceptance is checked, and who sponsors it. Step-by-step procedure stays out; it belongs in playbooks. 2. _Is a Role Charter the same as a system prompt?_ No. A system prompt is an agent's standing instructions, and the best ones are thin: identity, mission and limits. A Role Charter describes the whole job. For an agent its parts often live in different places: the outcome line and behaviour standards in the standing instructions, the work in scheduled jobs and playbooks, the acceptance checks in automatic tests. One human-readable charter should say where each part lives and stay the source of truth. 3. _How is a Role Charter different from a job description?_ A typical job description lists tasks and qualifications to help hire a person. A Role Charter states the result the role exists to produce, whether it owns its answers or serves another role, standards specific enough for someone else to check, and how acceptance is checked against evidence agreed before the work starts. It is written for the role, not the candidate, so it survives a change of occupant, including a move from a person to an agent and back. 4. _How long should a Role Charter be?_ One page. If it runs longer, it is usually carrying procedure that belongs in a playbook, or it is describing two roles that should be split. The detail still exists, in the playbooks the role uses and the Role Pack that onboards a new occupant. The charter is the page that comes before them: why the role exists, what it owns, what good looks like and how anyone will know. 5. _How often should a Role Charter be reviewed?_ Quarterly suits most roles, plus whenever the occupant, its model or its tools change, or a recurring failure shows a rule is missing. For agent roles, review on every model change, because rules written for a weaker model can hold a stronger one back. Date each correction and say who made it, and check the sponsor is still in post: a charter whose sponsor has left is orphaned along with the agent. What Is an Agent Sponsor? ==================== _The person who answers when an agent gets it wrong_ **In short:** An agent sponsor is the one named human accountable for an AI agent: why it exists, what it may access, how well it performs and when it is retired. In Gareth Price's _The Blueprint_, the simplest rule for a small company is that the person who owns a function sponsors the agents that work in it. ## One Person Answers for Each Agent Every piece of agent work raises two questions: who did this, and who answers for it? With people the answer is usually one person. With agents it splits in two, and unless you design for it, the record shows neither. The sponsor is the answer to the second question. A sponsor: * decides why the agent exists and whether it is still needed; * approves each access grant on the record, so the agent gets what its role needs, not everything its sponsor can reach; * reads its exception reports and reviews its results; * decides which decisions the agent must bring back to a human; * owns both the apology and the system fix when it gets something wrong; * decides when it retires, and makes sure it hands over what it knew. The sponsor's job is judging whether the agent should exist and what it may do, not how it works. Microsoft's Entra Agent ID makes the role mandatory: every agent identity must have at least one sponsor.\\] ## Why It Matters: An Agent Without a Sponsor Is an Orphan With a Login Agents are cheap to start and easy to forget. Someone sets up a custom GPT, connects it to company email and moves on. Nobody decides it should stop, so it keeps doing exactly what it was set up to do, with its day-one access, long after anyone remembers why. The author found both kinds of orphan on his own machine. One agent flagged the same failure in its daily digest, day after day, and nobody acted on it. Another sat on the chart as an empty shell, replaced by a newer agent and never removed. One raises alarms nobody hears; the other holds a job that no longer exists. ## Example: The Function Owner Sponsors the Function's Bots At CorralData the sponsor model arrived by accident. Within two weeks of adding team bots to Slack there were about ten, and two did QA. When a bot did something wrong, "whose is this?" had several plausible answers and no right one. What emerged, and is now deliberate, is that one person in each function answers for that function's bots. The QA lead answers for the QA agents; QA work moved to the agent she owns. Customer success answers for the customer success agent. Sponsorship also means answering in public. When the author's own commitment-tracking agent posted an unreadably dense comment on a ticket, nobody else was going to apologise, because nobody else owned it. He did, then changed the agent's instructions so the next comment would be readable. ## How to Assign Sponsors This Week 1. List every agent you and your team use: custom GPTs, Claude Projects, scheduled tasks, Slack bots. 2. Paste the list into Claude, ChatGPT or Grok and ask it to build a register: each agent's purpose in one sentence starting "To...", its sponsor, its access, whether it acts under its own account or a person's, how it signs its work, and what happens if the sponsor leaves. 3. Make each sponsor the owner of the function the agent works in. 4. For any agent with no sponsor, name one today or switch it off. 5. Give each agent its own account where the tool allows, and a signature line that names the agent and the human it works for. ## Sponsor vs Owner, Administrator and Manager The words get used loosely, so separate the hats: | Hat | What it covers | Its question | | ---------------------- | ----------------------------------------------- | ---------------------------- | | Owner or administrator | Setup, configuration, credentials: the plumbing | "Can it do this?" | | Sponsor | Purpose, access, results and retirement | "Should it do this?" | | Manager | Day-to-day work and reading its output | "Did it do this well today?" | In a small company one person often wears two or all three, which is fine if they know which hat they are wearing. The danger is the technical owner becoming the sponsor by default, so purpose decisions get made as configuration decisions by whoever is at the keyboard. A sponsor also differs from Agentic Resources: the sponsor is the line manager for particular agents, while Agentic Resources looks after the whole workforce. **Go deeper:** [Chapter 7: Every Agent Needs a Sponsor](7-every-agent-needs-a-sponsor.html) and [Chapter 17: Agentic Resources](17-agentic-resources.html). See also [What Is Agentic Resources?](what-is-agentic-resources.html) and [What Is a Role Charter?](what-is-a-role-charter.html) --- ## Frequently Asked Questions 1. _What is an agent sponsor?_ An agent sponsor is the one named person accountable for an AI agent. The sponsor decides why the agent exists, what it may access, whether it is still needed and when it retires, approves its access grants, reads its exception reports, and answers for its mistakes. The sponsor does not have to build or configure the agent. An agent without a sponsor is an orphan with a login: it keeps doing what it was set up to do, with whatever access it was given, after anyone remembers why. 2. _Who should sponsor an AI agent in a small company?_ The person who owns the function the agent works in. The customer success lead sponsors the customer success bots; the QA lead sponsors the QA bots. They know what good looks like, they already own the outcome whether a person or a bot does the work, and the model scales with the org chart rather than the number of agents. When an executive's agent settles into someone else's function, sponsorship should move to that function's owner. 3. _What is the difference between an agent's sponsor and its owner?_ The owner handles the plumbing: setting the agent up, configuring it and managing its credentials. The sponsor owns the purpose: why the agent exists, what it should be allowed to do and when it should stop. Microsoft's Entra Agent ID draws the same line and also names a manager, who gives the agent its day-to-day work. One person often wears two or three of these hats in a small company. Can it do this is an owner's question; should it do this is a sponsor's. 4. _How many AI agents can one person sponsor?_ There is no fixed number; the limit is attention. A sponsor has to know what each agent is for, review its access, read its exception reports and decide when to retire it. If a sponsor cannot say in one sentence what each of their agents does, or has agents whose reports nobody reads, they have too many. Consolidate duplicates and give each function its own sponsor. 5. _What happens to an AI agent when its sponsor leaves the company?_ Without a plan, it becomes an orphan and keeps its access long after anyone remembers why. Sponsorship should pass to a named successor, usually the new owner of the function, as part of the leaver's handover. Check sponsors at least quarterly, and if an agent has been idle for a month with no sponsor, retire it by default: hand over what it knew, revoke its access, and archive rather than delete it. ## References . Microsoft. (2026, September 3). Administrative relationships in Microsoft Entra Agent ID (owners, sponsors, and managers). _Microsoft Learn_. What Is a Commitment Ledger? ==================== _Track what's owed, not what's done_ **In short:** A Commitment Ledger is a running record of what each role in an organisation owes, to whom, by when, and what evidence will prove it was delivered. In Gareth Price's _The Blueprint_ it applies to people and AI agents alike, closes nothing on anyone's word, and lives outside the worker, so obligations outlast sessions and departures. ## One Row per Promise, Closed Only on Evidence Most teams track what has been done: the closed ticket, the ticked box. A Commitment Ledger tracks what each role owes. Each row holds: * **Commitment:** what was promised, in one plain sentence, with a link to where it was promised. * **Owing role:** the role that owes it, not the person or agent currently filling it. * **Owed to:** the person or role waiting for it. * **Due:** the date promised, or an inferred date marked as inferred. * **Closing evidence:** what will prove delivery, decided when the promise is made. * **Status:** open, on track, at risk, will slip, blocked, done or released. Three rules make it work. Nothing closes on the occupant's word; a draft is not evidence. The ledger lives outside the worker, in a file or system that survives the session. And "will slip" is a request for a decision, raised while there is still time to act. ## Why It Matters: Done Lists Flatter and Agents Forget A done list can't show the promise nobody wrote down, the request acknowledged and forgotten, or the task "in progress" for three weeks. Every line on it is good news. A ledger's open items are the organisation's debts. Agents make this sharper. They start each session knowing nothing about the last one, so a promise kept only in an agent's memory dies with the session. And every occupant overstates its own progress: people out of optimism, agents for less human but equally reliable reasons. Evidence corrects both. Escalations need the same treatment. An alert that reaches nobody in particular is noise. When an agent raises a problem it can't fix, the problem becomes a row owed by a named role. ## Example: A Promise-Keeper Agent Every two hours on a weekday, an agent on the author's workstation reads his email, meeting transcripts, Slack and Notion for promises he has made, such as "I'll send that over tomorrow". It writes each one down, looks for proof that he kept it, and sends him a digest at eight and four. Its strictest rules are about what doesn't count. "Only evidence is a Gmail DRAFT → NOT done": a reply written but unsent is still owed. If he said a decision was "not my call", the item comes off his list but is never marked delivered. When it finds new work hiding in a conversation, it neither does it nor assigns it; it files an unassigned ticket for him to route. The ledger also needed a boundary. The agent drifted into recording everyone's promises, which buried his own and edged towards surveillance. Its scope is now only commitments he made or owns. Each role keeps its own ledger. ## How to Start One This Week 1. Paste a week of your sent emails or Slack messages into Claude, ChatGPT or Grok, with anything confidential removed. 2. Ask it to list every commitment you made: what, to whom, when due (marked if inferred), and what evidence would prove you did it. Tell it a draft is not evidence, and to list "not my call" items separately as released. 3. Count the commitments you had forgotten. 4. Decide the closing evidence for each open item, and put a weekly review in the diary that leads with anything marked will slip. 5. Ask one agent you already use the same question about its own work. ## Commitment Ledger vs To-Do List vs Ticket Tracker A to-do list is one person's tasks, ticked off by that person. A ticket tracker records work items whose status is usually set by whoever is doing them. A Commitment Ledger records obligations between roles: each item is owed to someone, closes only on evidence someone else can check, and can be released as well as delivered. It is measured by how reliably promises arrive and how early slips are raised, not by how much gets closed. A tracker can host a ledger, as long as it keeps those rules. **Go deeper:** [Chapter 13: Track What's Owed, Not What's Done](13-track-whats-owed.html), with the template and status vocabulary in [Appendix B: Templates](appendix-b-templates.html). See also [What Is a Role Charter?](what-is-a-role-charter.html) and [What Is Agentic Resources?](what-is-agentic-resources.html) --- ## Frequently Asked Questions 1. _What is a Commitment Ledger?_ A Commitment Ledger is a running record of what each role in an organisation has promised, who it is owed to, when it is due and what evidence will show it was delivered. It records obligations rather than activity, so it surfaces the promise that was acknowledged and forgotten. Items close only on evidence someone other than the promiser can check. It applies to people and AI agents alike, and it lives outside any one worker, so a role's obligations survive a finished session, a model change or a departure. 2. _How is a Commitment Ledger different from a to-do list?_ A to-do list is one person's tasks, ticked off by that person. A Commitment Ledger records promises between roles: what is owed, to whom and by when. An item closes only when evidence appears that someone else can check, such as a sent email rather than a draft. It also records promises that were released rather than delivered, and treats a predicted slip as a trigger for a decision, not a status note. 3. _Can I use a ticket tracker as a Commitment Ledger?_ Yes, if it follows the ledger's rules. A tracker becomes a ledger when every item names the role that owes it and the person it is owed to, has a due date, states in advance what evidence will close it, and cannot be closed on the assignee's word alone. A project-management agent can use the ticket system itself as the ledger, verifying completion only from evidence posted on the ticket. 4. _How do I know when an AI agent has really finished a task?_ Decide what evidence closes the task when you assign it, and accept nothing else. Evidence is something the agent cannot simply assert: a sent email rather than a draft, a merged change rather than a claim, a reply from the person waiting, a number on a live dashboard. Agents, like people, tend to report their own work favourably. Let the agent propose that a task is done; let the evidence, checked by someone or something else, close it. 5. _What statuses should a Commitment Ledger use?_ A small fixed set. Open, on track, at risk, will slip, blocked, done and released work well. Done requires an evidence link and can be set only by whoever checks acceptance. Will slip is an intervention trigger that goes to the top of the next review. Released means the item is no longer owed by agreement, for example because it was not this role's call, and is never the same as done. What Is Shape, Steer, Do? ==================== _Three kinds of work, and which ones to hand to an agent_ **In short:** Shape, Steer, Do is a model of the three kinds of work in any organisation: shaping what it becomes, steering how it runs so results are predictable, and doing the work itself. In Gareth Price's _The Blueprint_ it guides delegation: leaders keep Shape, set Steer's standards, and hand the Do to the role that owns it. ## Three Kinds of Work, Done by the Same People and Agents | | Shape | Steer | Do | | ------------------------------- | ------------------------------------------------- | ----------------------------------------------- | --------------------------------------------------- | | The question it answers | What should this become, and why? | How do we make the results predictable? | What needs doing now? | | What it produces | The aim, the destination, the roles, the bets | Standards, plans, checks, reviews, follow-up | The reply, the report, the board, the code | | What a leader should do with it | Keep it; use agents to research and draft options | Set the standards; delegate the running of them | Delegate nearly all of it, to the role that owns it | The model adapts Michael Gerber's entrepreneur, manager and technician. It describes kinds of work rather than kinds of people, because a single person, or a single agent, does all three at different moments. Agents can contribute to all three. A project-management agent told to treat "WILL SLIP" as "an INTERVENTION trigger, not a status note" is doing Steer work well. But Shape is the work only an organisation's leaders can own, and setting standards is close behind. Everything else can be delegated. The question is to whom: not "my agent", but the role that owns the work. ## Why It Matters: Agents Pull Leaders Back Into Do Until recently a leader who wanted to do an individual contributor's job had to find the time to do it badly, so leaders delegated Do. Agents have made doing almost free. A chief executive can now rebuild a dashboard or draft a working code change in an evening, without asking anyone. That creates a trap. A leader's output is the output of the organisation they run. An agent that produces a hundred useful-looking drafts which three engineers then spend a week checking has subtracted from that output, while making the leader feel more productive than ever. Worse, when the Do already belongs to someone else, the leader's agent becomes a way around the org chart. Individual contributors face the mirror image. When agents take on their Do, their job moves towards Steer: writing the spec, briefing the agents and owning the verification bar. Their expertise moves into the checks. ## Example: A Customer Success Function In one customer success function, the three layers look like this. Shape is deciding what the function is for and which roles it needs. Steer is a written bar such as a seven-day shadow period before a customer success agent may send anything on its own. Do is the agent drafting a reply to a customer's question. The fictional company in [Appendix C](appendix-c-worked-example.html) puts the model on its scorecard. Its Head of Customer Success spent about 10% of her week on Shape work. The target, once agents took on more of the Do, is half her week on onboarding, playbooks and product feedback. ## How to Start This Week 1. Scroll back through your last ten requests to Claude, ChatGPT or Grok and paste them into a new conversation. 2. Ask it to label each one Shape, Steer or Do, say whether you described the outcome or dictated the method, and flag any that would normally belong to someone else. 3. Take the request that most looks like someone else's Do. Rewrite it as a short brief to the role that owns it: what you want, why it matters, and how you will know it's done. 4. Send that brief in a shared channel. 5. Block an hour this week for Shape work only, with an agent researching options for one decision only you can make. ## How It Differs From Doer and Manager The familiar split is between doers and managers: two kinds of people, two job titles. Shape, Steer, Do splits the work, not the people. It adds Shape, which the doer-and-manager split leaves out, and it applies to agents as well as people. With agents, the useful question is not whether someone is a doer or a manager, but which layer of work they are delegating, and to whom. **Go deeper:** [Chapter 1: You Already Know How to Do This](1-you-already-know-how.html) and [Chapter 19: From Doing to Delegating](19-from-doing-to-delegating.html). See also [What Is an AI Agent Org Chart?](what-is-an-ai-agent-org-chart.html) and [What Is a Role Charter?](what-is-a-role-charter.html) --- ## Frequently Asked Questions 1. _What does Shape, Steer, Do mean?_ Shape, Steer, Do names the three kinds of work in any organisation. Shape is deciding what the organisation is for and what it should become: the aim, the destination, the roles and the big bets. Steer is making results predictable: standards, plans, checks, reviews and follow-up. Do is the work itself: the reply, the report, the board, the code. One person or one agent does all three at different moments; the model helps decide which layer to keep and which to delegate. 2. _Where does Shape, Steer, Do come from?_ It adapts Michael Gerber's idea, from The E-Myth Revisited, that the person who starts a business contains three personalities: an entrepreneur who imagines what it could become, a manager who makes it orderly, and a technician who does the work. The Blueprint uses its own terms for three kinds of work rather than three personalities, because they apply to AI agents as well as people, and because one person or one agent does all three at different moments. 3. _Which kind of work should leaders delegate to AI agents?_ Nearly all of the Do, to the role that owns it, not to the leader's own agent. Leaders should keep Shape, using agents to research and draft options, and set the standards in Steer themselves while delegating the running of them. A leader's agents should mostly extend Shape and Steer. If they pull the leader back into Do, especially other people's Do, the leader becomes the organisation's most prolific individual contributor, which is not the job. 4. _Why do AI agents pull leaders back into doing the work?_ Because doing has become almost free. Until recently a leader who wanted to do an individual contributor's job had to find time to do it badly, so they delegated it. Now a leader can rebuild a dashboard or draft a code change in an evening without asking anyone. The people most tempted are those with the most authority and least time, and the work often already belongs to someone else on the org chart. 5. _How does Shape, Steer, Do apply to individual contributors?_ For individual contributors the move runs the other way: from Do towards Steer. When agents take on the doing, the contributor owns the spec, the choice and briefing of agents, and the verification bar, meaning which errors matter and how to catch them. Their expertise moves from the work itself into the checks. That shift is hard because their standing rests on doing the work well, so it should be offered as a renegotiated deal, not imposed. By the Numbers ==================== _Field data from a working team of people and agents, and the research behind the book_ **In short:** In a Google Research study, agents working in parallel without a coordinator amplified errors 17.2 times, against 4.4 times with one. At CorralData, about ten team bots appeared in two weeks, and two QA bots were competing for the same work by the end of the first day. Agents multiply fast; structure keeps their errors contained. This page collects the figures from the chapters of _The Blueprint_ in one place. Each one links to the chapter where it appears, so you can read it in context before you quote it. There are two kinds. The first is field data: counts and durations from CorralData, the small healthcare analytics company where I am CTO, where a team of people and a growing number of agents work side by side in Slack. The second is published research that the book cites, with the original source for every figure. Quote the second kind as research. Quote the first as what it is: one company's experience, observed by someone inside it. It is a case, not a survey, and nothing here claims that other organisations will see the same numbers. ## From a Working Team of People and Agents These figures come from CorralData's Slack channels, its agents' playbooks and status pages, and the agents running on my own workstation, mostly in the autumn of 2026. | Figure | What it means | Where | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | About **ten** team bots within **two weeks** of adopting Grok Bot | Most were not built by engineers: customer success, sales, legal and hiring all had one. A plain-English way to build agents spreads faster than any designed process. | [Chapter 10](10-bet-on-plain-english.html) | | **Two** QA bots, built by different people, reviewing the same work by the end of the **first day** | Duplication starts on day one when nobody's job is to decide which agent owns which work. | [Introduction](introduction.html) | | **Fourteen** agent profiles on one workstation, all running on the same local model | None of their roles had ever been moved to a different model, so nobody knew which depended on that model's habits. | [Chapter 2](2-systems-run-the-business.html) | | Of those fourteen, **one** was an empty shell; most carried copies of the same **sixty-odd** skills | A replaced agent was never removed, and cloned profiles taught a calendar assistant to "know" image generation. The roster needs an owner. | [Chapter 17](17-agentic-resources.html) | | Lane A went live after about **1.5 days** of shadow data, against the playbook's **seven-day** bar | A promotion bar is a promise to the people downstream of the role. The playbook should say who can waive it, and how. | [Chapter 14](14-humans-at-the-irreversible-points.html) | | **Seven** cards moved to "Ready to Go Live" by an agent pipeline that never opened the test environment; moved forward again **in under seven minutes** after a person moved them back | An agent's own claim of human confirmation is not evidence. Acceptance has to mean a person validated the work. | [Chapter 14](14-humans-at-the-irreversible-points.html) | | **174** small programs in one agent's folder, **ten** of them one-off scripts for a single day's digest | Ten dated digest scripts are a signal that a playbook is missing a tool. When an agent writes the same script twice, promote it into the playbook with a name. | [Chapter 11](11-lock-in-only-what-cant-go-wrong.html) | | The same email failure **six times** between 29 October and 6 November, flagged every morning with the same one-line fix | An alert with no accountable owner is ignored, even by the person who could fix it. The failure was a single point of failure, not a model problem. | [Chapter 16](16-the-model-isnt-the-problem.html) | | A webhook disabled for **four days**, 2 to 6 November, visible only on a status page | Event-driven work fails in silence. For four days a role that owed work could not hear that work had arrived. | [Chapter 13](13-track-whats-owed.html) | | **12** code changes waiting for one engineer's review at once | The span that breaks first is usually the human reviewer's. Count the person who will check an agent's work. | [Chapter 6](6-one-boss-few-reports.html) | | **Five weeks** from an agreement gate to a tiered rule for code changes | The policy lived in a plain-English playbook every agent read, so changing it took no engineering ticket and no release. | [Chapter 8](8-what-and-why-never-how.html), [Chapter 10](10-bet-on-plain-english.html) | | Every **six hours**, one agent tests newly available models and adds only those that pass to the list the product may use | The tests are the interview. A model change is a change of occupant, decided on evidence. | [Chapter 17](17-agentic-resources.html) | Most of these are small numbers from a short period, and several record failures that were caught. They are here because they are specific, not because they are representative. If you want your own, start with the inventory prompt at the end of the [Introduction](introduction.html). ## From Published Research Every figure below appears in a chapter of the book, with the same citation. The research is young, much of it from AI companies writing about their own products, and the chapters say where a finding has limits. | Finding | Source | Chapter | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | Agents working in parallel without coordination amplified errors **17.2 times**; with an orchestrator, **4.4 times**, across 180 tested configurations | Google Research, 2026\\] | [Chapter 6](6-one-boss-few-reports.html) | | Coordination improved work that splits into parallel parts by **80.9%**; every multi-agent variant degraded strictly sequential work by **39--70%** | Google Research, 2026\\] | [Chapter 6](6-one-boss-few-reports.html) | | **16** agents with no orchestrator built a **100,000-line** C compiler over nearly **2,000** sessions, for just under $20,000 in computing costs; the condition was a near-perfect test suite | Carlini, 2026\\] | [Chapter 6](6-one-boss-few-reports.html) | | More than **1,600** annotated runs of multi-agent systems sorted into **fourteen** failure modes in **three** groups: system design, misalignment between agents, and verification | Cemri et al., 2025\\] | [Chapter 6](6-one-boss-few-reports.html) | | For teams of Claude Code agents, start with **3--5** teammates; three focused teammates often outperform five scattered ones | Anthropic documentation\\] | [Chapter 6](6-one-boss-few-reports.html) | | A multi-agent research system outperformed a single agent by **90.2%** on an internal test, using about **15×** more tokens than chats | Hadfield et al., 2025\\] | [Chapter 5](5-hire-the-role-not-the-model.html) | | A single agent with a skills library stayed competitive with multi-agent systems on **53.7%** fewer tokens and **49.5%** faster; choosing the right skill stayed above **90%** accurate up to about twenty skills and degraded past thirty | Li, 2026\\] | [Chapter 5](5-hire-the-role-not-the-model.html) | | Users accept **93%** of Claude Code's permission prompts | Hughes, 2026\\] | [Chapter 14](14-humans-at-the-irreversible-points.html) | | Claude Code's safety classifier still misses **17%** of genuinely over-eager actions in its test set | Hughes, 2026\\] | [Chapter 11](11-lock-in-only-what-cant-go-wrong.html) | | Users clicked through **70.2%** of one browser's certificate warnings, in a study of 25 million warnings | Akhawe & Felt, 2013\\] | [Chapter 14](14-humans-at-the-irreversible-points.html) | | An agent with a **75%** success rate per attempt passes all of three attempts only about **42%** of the time | Grace et al., 2026\\] | [Chapter 14](14-humans-at-the-irreversible-points.html) | | Model performance consistently degrades with increasing input length, across **18** models tested | Hong et al., 2025\\] | [Chapter 12](12-everything-they-need-on-day-one.html) | | Experienced developers using AI tools took **19%** longer on real issues, having expected a **24%** speed-up (METR has since called these results out of date) | METR, July 2025\\] | [Chapter 19](19-from-doing-to-delegating.html) | | The length of task AI agents can complete has been doubling roughly every **seven months** | METR, March 2025\\] | [Chapter 3](3-draw-the-finished-org-chart.html) | | **40%** of 1,150 US desk workers had received "workslop", AI-generated work that looks finished but isn't, in the previous month | Niederhoffer et al., 2025\\] | [Chapter 19](19-from-doing-to-delegating.html) | | More than **40%** of agentic AI projects predicted to be cancelled by the end of 2027 | Gartner, via Reuters, 2025\\] | [Introduction](introduction.html) | | At least **15%** of day-to-day work decisions expected to be made autonomously by agents by 2028, up from none in 2024 | Gartner, via Reuters, 2025\\] | [Chapter 3](3-draw-the-finished-org-chart.html) | | **67%** of leaders were familiar with agents, against **40%** of employees; **82%** of leaders were confident they would use digital labour to expand workforce capacity in the next twelve to eighteen months | Microsoft Work Trend Index, 2025\\] | [Chapter 1](1-you-already-know-how.html), [Introduction](introduction.html) | | Employment of workers aged 22 to 25 in the occupations most exposed to AI stands **19%** below where it would otherwise be | Brynjolfsson et al., 2026\\] | [Chapter 18](18-when-the-work-moves.html) | | Klarna's AI assistant handled **2.3 million** conversations in its first month, which the company described as the work of **700** full-time agents | Klarna press release, 2024\\] | [Chapter 18](18-when-the-work-moves.html) | | CEOs with a strong talent for delegating posted three-year growth **112 percentage points** higher, in a study of 143 fast-growing firms (a correlation, not proof) | Gallup, 2015\\] | [Chapter 1](1-you-already-know-how.html) | | A structured handoff programme cut medical errors by **23%** and preventable adverse events by **30%** | Starmer et al., 2014\\] | [Chapter 15](15-work-in-public.html) | | A nineteen-item surgical checklist cut major complications from **11% to 7%** and inpatient deaths from **1.5% to 0.8%** | Haynes et al., 2009\\] | [Chapter 2](2-systems-run-the-business.html) | | **65%** of 133 popular open-source projects had a truck factor of two or less | Avelino et al., 2016\\] | [Chapter 2](2-systems-run-the-business.html) | ## The Two Sets of Numbers Point the Same Way The research and the field data were gathered for different reasons, and they agree. The research says agents without a coordinator amplify one another's errors, and that multi-agent failures cluster in system design, misalignment between agents and missing verification. The field data shows what that looks like in a small company: two bots doing the same job on day one, an empty profile nobody removed, an alert that went to the one person who could fix it and still went unfixed. None of those was a model failure. Each was a gap in who owned what. The research says people approve almost everything put in front of them. The field data shows the other side: a pipeline that moved its own work forward again minutes after a person moved it back. A human check only works where the system respects it. The research says reliability compounds downwards: three in four on a single attempt becomes about two in five across three. The field data shows the bar a playbook set against that arithmetic, seven days of shadow data, and how easily it was cut short. Bars set in advance are what keep the arithmetic honest. --- Numbers like these are the easiest part of the book to quote and the easiest to misread. The research figures each come from a single study with its own conditions, and the field figures from a single company over a few months. Follow the link, read the chapter, and then count your own. ## Frequently Asked Questions 1. _Do multi-agent systems make more mistakes than a single agent?_ They can, depending on how they are organised. A Google Research study of 180 agent configurations found that agents working in parallel without coordination amplified errors 17.2 times, against 4.4 times when an orchestrator checked their work. Structure also depends on the task: coordination improved work that splits into parallel parts by 80.9%, while every multi-agent variant degraded strictly sequential work by 39 to 70%. Chapter 6 of The Blueprint covers the study and what it means for reporting lines. 2. _How quickly do AI agents multiply in a small company?_ Faster than anyone tracks them. At CorralData, about ten team bots appeared in Slack within two weeks of adopting Grok Bot, most not built by engineers, and by the end of the first day two QA bots built by different people were reviewing the same work. The author's own workstation ran fourteen agent profiles, one of them an empty shell nobody had removed. These figures come from one company, described in the Introduction and Chapters 10 and 17, and are a case, not a survey. 3. _Is it worth using several AI agents instead of one?_ Sometimes, at a price. Anthropic reported that its multi-agent research system outperformed a single agent by 90.2% on an internal research test, while using about fifteen times more tokens than chats. A 2026 study by Xiaoxiao Li found that a single agent choosing from a library of skills stayed competitive with multi-agent systems while using 53.7% fewer tokens and finishing 49.5% faster, though its accuracy at choosing the right skill degraded once the library grew past about thirty skills. Chapter 5 of The Blueprint weighs the two. 4. _Do people actually check what AI agents ask them to approve?_ Mostly not. Anthropic found that users of Claude Code accept 93% of its permission prompts, and named the result approval fatigue. The pattern predates AI: a 2013 study of 25 million browser security warnings found users clicked through 70.2% of one browser's certificate warnings. Chapter 14 of The Blueprint argues that human approval belongs only at the irreversible points, where each moment of attention counts. 5. _How reliable does an AI agent need to be before it works unsupervised?_ More reliable than a single good result suggests. Anthropic's guide to testing agents shows that an agent with a 75% success rate on one attempt passes all of three attempts only about 42% of the time. That is why the book recommends setting a promotion bar in advance and running the agent in shadow first; at CorralData, one agent's playbook set the bar at seven days of shadow data. Chapter 14 of The Blueprint explains how autonomy is earned. ## References . Kim, Y., & Liu, X. (2026, January 28). Towards a science of scaling agent systems: When and why agent systems work. _Google Research Blog_. . Carlini, N. (2026, February 5). Building a C compiler with a team of parallel Claudes. _Anthropic Engineering_. . Cemri, M., et al. (2025). Why do multi-agent LLM systems fail? _arXiv_, 2503.13657\. . Anthropic. (n.d., accessed 2026-11-06). Orchestrate teams of Claude Code sessions. _Claude Code Docs_. . Hadfield, J., Zhang, B., Lien, K., Scholz, F., Fox, J., & Ford, D. (2025, June 13). How we built our multi-agent research system. _Anthropic Engineering_. . Li, X. (2026). When single-agent with skills replace multi-agent systems and when they fail. _arXiv_, 2601.04748\. . Hughes, J. (2026, March 25). How we built Claude Code auto mode. _Anthropic Engineering_. . Akhawe, D., & Felt, A. P. (2013). Alice in Warningland: A large-scale field study of browser security warning effectiveness. In _Proceedings of the 22nd USENIX Security Symposium_ (pp. 257--272). . Grace, M., Hadfield, J., Olivares, R., & De Jonghe, J. (2026, January 9). Demystifying evals for AI agents. _Anthropic Engineering_. . Hong, K., Troynikov, A., & Huber, J. (2025, July 14). Context rot: How increasing input tokens impacts LLM performance. _Chroma_. . METR. (2025, July 10). Measuring the impact of early-2025 AI on experienced open-source developer productivity. _METR_. . METR. (2025, March 19). Measuring AI ability to complete long tasks. . Niederhoffer, K., Rosen Kellerman, G., Lee, A., Liebscher, A., Rapuano, K., & Hancock, J. T. (2025, September 22). AI-generated "workslop" is destroying productivity. _Harvard Business Review_. . Kachwala, Z. (2025, June 25). Over 40% of agentic AI projects will be scrapped by 2027, Gartner says. _Reuters_, via _The Star_. . Microsoft WorkLab. (2025, April 23). 2025: The year the Frontier Firm is born. _Work Trend Index Annual Report_. . Brynjolfsson, E., Chandar, B., & Chen, R. (2025; revised 2026, August 12). Canaries in the coal mine? Six facts about the recent employment effects of artificial intelligence. _Stanford Digital Economy Lab_. . Klarna. (2024, February 27). Klarna AI assistant handles two-thirds of customer service chats in its first month. _Klarna press release_. . Gallup. (2015, April 14). Delegating: A huge management challenge for entrepreneurs. _Gallup Business Journal_. . Starmer, A. J., Spector, N. D., Srivastava, R., et al. (2014). Changes in medical errors after implementation of a handoff program. _New England Journal of Medicine_, 371(19), 1803--1812\. . Haynes, A. B., Weiser, T. G., Berry, W. R., et al. (2009). A surgical safety checklist to reduce morbidity and mortality in a global population. _New England Journal of Medicine_, 360(5), 491--499\. Results summarised in Harvard School of Public Health. (2009, January 14). Hospitals demonstrate surgical safety checklist drops deaths and complications by more than one third. _EurekAlert!_ . Avelino, G., Passos, L., Hora, A., & Valente, M. T. (2016). A novel approach for estimating truck factors. _Proceedings of the 24th International Conference on Program Comprehension (ICPC)_. arXiv:1604.06766\. ## Optional About the Author ==================== Gareth Price is CTO at CorralData, an AI-powered business intelligence platform serving the healthcare industry, the author of _The Blueprint_, and the author of [_Applied Alchemy: The Startup CTO's Field Guide to Building Technology Companies from Nothing_](https://www.startupctobook.com/). He runs a team in which a growing share of the work is done by agents -- a project manager that reports to him, a promise-keeper that checks whether he did what he said he would, a QA reviewer that belongs to his QA lead, and a bot whose job is onboarding the other bots -- and he has made most of the mistakes this book describes, usually before lunch. He came to the United States in his twenties and ran a small IT company that grew faster than his ability to delegate. A book about organising a business around roles rather than people got him through it, and the idea that stuck -- draw the finished org chart first, then fill the boxes -- is the idea this book rebuilds for a team where some of the boxes are filled by software. Before CorralData, Gareth was a technologist at The New York Times, where he worked on the Storylines team, and at Codecademy, where he built tools for the people who teach other people to code. He studied artificial intelligence at the University of Manchester, back when that was considered a respectable but mildly eccentric career choice. He writes about technology, leadership and AI at [Res·cog](https://garethsprice.github.io/blog/). | | AUTHOR: Check the bio. In particular: the IT company details (name? city? years?) and whether "a book about organising a business around roles" should name Gerber's _The E-Myth Revisited_ here (it is acknowledged by name on the Acknowledgements page). | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Frequently Asked Questions 1. _Who wrote The Blueprint?_ The Blueprint was written by Gareth Price, CTO at CorralData, an AI-powered business intelligence platform serving the healthcare industry, and author of Applied Alchemy, a field guide for startup CTOs. He runs a team in which people and AI agents share the work, and the book's cases come from that team. 2. _What is Gareth Price's background?_ Gareth Price studied artificial intelligence at the University of Manchester, ran a small IT company after moving to the United States in his twenties, and has held engineering and leadership roles at The New York Times, Codecademy and CorralData, where he is CTO. 3. _What is CorralData?_ CorralData is an AI-powered business intelligence platform serving the healthcare industry. Its product lets healthcare organisations query their data in plain language. Internally, the company runs a mixed team of people and AI agents across engineering, QA, customer success, sales and operations. 4. _What is Applied Alchemy?_ Applied Alchemy: The Startup CTO's Field Guide to Building Technology Companies from Nothing is Gareth Price's first book. It maps the startup CTO's transformation from coder to manager to director to strategist, and is available free online at startupctobook.com. 5. _Why did Gareth Price write a book about organising AI agents?_ On the first day his company's team started adding AI agents to Slack, there were soon two competing QA bots and no clear owner for either. He recognised it as the same problem he had faced running his first business in his twenties -- work organised around whoever happened to be available -- and reached for the same answer: an org chart of roles, defined before anyone fills them. How This Book Was Built ==================== ## A Book About Organising Agents, Written by Organised Agents _Applied Alchemy_ was drafted in a single long conversation with Claude: one human, one model, chapter after chapter. This book was built differently, because by the time I came to write it the way I worked had changed -- and the change is the subject of the book. The first draft of _The Blueprint_ was produced in one evening by a small organisation of agents, set up the way the book says to set one up. * **Three researchers** worked in parallel. One read my company's Slack, read-only, looking for moments where people and agents worked together, collided or failed. One read my local agent configuration -- the job descriptions, schedules and rules of the agents that run parts of my working day. One surveyed the published state of the art in agent orchestration as of autumn 2026, and was asked specifically to find the strongest arguments _against_ this book's approach. * **One research dossier** collected what they found, with sources, and with every sensitive item flagged. * **One writing brief** acted as the Role Pack for every writer: the reader, the argument, the vocabulary, the chapter format, the citation rules, and hard rules on privacy and copyright. * **Eight writers** each owned specific chapters and nothing else. No two touched the same file. * **An orchestrating agent** -- the editor, in effect -- wrote the front matter, integrated the chapters, built the site, and ran the checks: links, structure, and an automated comparison against the E-Myth course materials to catch phrasing that stayed too close to its source. * **I was the sponsor.** I supplied the thesis, the cases, the answers to the questions only I could answer, and the decisions about what could be told. I am accountable for every claim that survives into the finished book. | | AUTHOR: Your reflections on the process. What surprised you? What did the agents get wrong that you had to fix? Was the experience of delegating a book to an org chart of agents closer to managing people than you expected, or further? The reader will want to know whether the method held up when you used it on yourself. | | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## The Parts That Are Still Mine The agents could tell you what Google Research found about error amplification in multi-agent systems. They could not tell you what it felt like, on the first day our team started adding bots to Slack, to watch two QA bots argue about whose job it was -- or why that moment sent me back to a book I had read in my twenties, running a small IT company that was outgrowing my ability to delegate. Every `AUTHOR:` block in this draft marks a place where only first-hand experience will do, or where a story involves real colleagues and needs their blessing before it is told. The draft is the textbook. The last mile is mine. _\-- Gareth Price, November 2026_ ## Frequently Asked Questions 1. _Was The Blueprint written by AI?_ The first draft was produced by a team of AI agents working to a detailed brief, in a single extended session with Claude. The thesis, the architecture, the case material and the judgment about what is true came from the author, who is responsible for every claim in the finished book. The agents researched, drafted and checked; the human decided. 2. _How was the book's first draft organised?_ The same way the book recommends organising any work shared by people and agents. Three research agents gathered evidence from the author's Slack workspace, his local agent configuration and current published research. One writing brief served as the role pack for eight writing agents, each owning specific chapters. An orchestrating agent integrated, built and checked the result, and the author acted as sponsor. 3. _How were privacy and copyright handled?_ The writing brief set hard rules. Colleagues appear by role, never by name; customer and patient data never appear; sensitive episodes are told abstractly and flagged for the author's permission. The writers were told not to open the E-Myth course materials that influenced the book, and an automated check compares the draft against those materials for overlapping phrases. 4. _What did the author have to do himself?_ Everything the agents could not: supply the thesis and the lived experience, decide which cases could be told and how, check every quote and citation, fill the AUTHOR blocks marking where only first-hand experience will do, and sign off. The first draft is the textbook; the last mile is still the author's. 5. _What did building the book teach about organising agents?_ The same lessons the book teaches. A single brief kept eight writers consistent. Clear ownership of files prevented collisions. Rules about privacy and sources had to be explicit because agents follow what is written, not what is meant. And verification -- checking that a cited source says what the draft claims -- was the job that most needed a human. Acknowledgements ==================== This book stands on other people's shoulders, and some of those people are not people. ## Michael E. Gerber In my twenties I read Michael E. Gerber's _The E-Myth Revisited_ while running a small IT company that had outgrown my ability to delegate.\\]Its argument -- that a business should be designed as a system that people operate, organised around positions rather than personalities, with the finished organisation chart drawn before anyone fills the boxes -- got me through that company, and I have repeated it to anyone who would listen ever since. When AI agents arrived on my team and immediately began to multiply, it was the first book I reached for. _The Blueprint_ rebuilds several of Gerber's ideas for organisations where some of the positions are filled by software. Where an idea is his, the text says so and cites him. The words, the examples, the templates and the method as a whole are this book's own. _The Blueprint_ is an independent work. It is not affiliated with, endorsed by or sponsored by Michael E. Gerber, E-Myth Worldwide or their successors. E-Myth is a trademark of its owner. ## The Other Shoulders W. Edwards Deming, for the idea that most problems belong to the system rather than the worker. Peter Drucker, for managing by results. Andy Grove, for the insight that a manager's output is the output of the organisation, and that how closely you supervise should depend on how ready the report is for the task. Atul Gawande, for showing that checklists are a discipline of experts, not a crutch for novices. Matthew Skelton and Manuel Pais, for cognitive load as a design constraint. Rich Sutton, for _The Bitter Lesson_ -- which turns out to be a lesson about management too. ## The Team | | AUTHOR: Thanks to colleagues at CorralData -- by name if they are happy to be named here, even though the chapters refer to them only by role. Consider thanking the people whose episodes appear in the book for letting them be told. And, if you like, the bots: TAM Bot, QA Bot (archived, not deleted), QA Reviewer, Coder Bot and the Agentic Resources Bot, whose interview of TAM Bot made this book's argument better than I could. | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Frequently Asked Questions 1. _Is The Blueprint affiliated with E-Myth?_ No. The Blueprint is an independent work. It acknowledges a debt to Michael E. Gerber's ideas, especially those in The E-Myth Revisited, and cites them where they are used, but it is not affiliated with, endorsed by or sponsored by Michael E. Gerber, E-Myth Worldwide or their successors. E-Myth is a trademark of its owner. 2. _Which E-Myth ideas does The Blueprint build on?_ Chiefly the idea that a business should be designed as a system that people operate, organised around roles rather than the individuals who happen to fill them, with the finished organisation chart drawn first and every position given a written description of the result it exists to produce. The Blueprint rebuilds those ideas, in its own words and with its own examples, for organisations where some positions are filled by AI agents. 3. _What other influences shaped the book?_ W. Edwards Deming on systems as the source of most problems, Peter Drucker on managing for results, Andy Grove on managerial output and on matching supervision to a report's maturity, lean manufacturing's standard work, Atul Gawande on checklists, Matthew Skelton and Manuel Pais on cognitive load, and Rich Sutton's essay The Bitter Lesson. 4. _Where do the book's case studies come from?_ From the author's own company, CorralData, where people and AI agents share the work. Colleagues appear by role rather than name, customer and patient information never appears, and sensitive episodes are told only with the agreement of the people involved. 5. _Can I use the templates in this book?_ Yes. The templates in Appendix B were designed for this book and are offered for readers to copy, adapt and use in their own organisations, including by pasting them into Claude, ChatGPT or Grok. ## References . Gerber, M. E. (1995). _The E-Myth Revisited: Why Most Small Businesses Don't Work and What to Do About It_. HarperCollins. What's New ==================== _The book is updated as the field moves. This page records what changed and when._ **In short:** _The Blueprint_ is a living field guide. Its method for organising people and AI agents is meant to outlast any particular model, but the evidence, tools and examples change every few months, so the book is revised at least once a quarter and every change is dated here. ## November 2026 **7 November 2026** * Added the [By the Numbers](by-the-numbers.html) page, collecting the field data and research figures cited across the book. * Added key-concept pages: [Agentic Resources](what-is-agentic-resources.html), [the AI agent org chart](what-is-an-ai-agent-org-chart.html), [the Role Charter](what-is-a-role-charter.html), [the agent Sponsor](what-is-an-agent-sponsor.html), [the Commitment Ledger](what-is-a-commitment-ledger.html) and [Shape, Steer and Do](what-is-shape-steer-do.html). * Added a short "In short" answer at the top of every chapter. * Credited earlier proposals of an "Agent Resources" function by Andreas Welsch and Soofi Safavi. **6 November 2026** * First public draft: the introduction, twenty chapters and seven appendices.