Chapter 1: You Already Know How to Do This

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.^[1] The report’s authors argued that "every worker will need to think like the CEO of an agent-powered startup."^[1]

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."^[2]

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.^[2] Anthropic’s engineers describe building a skill for an agent as "like putting together an onboarding guide for a new hire."^[3] 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.^[4] Gallup presents this as a correlation, not proof.^[4] 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.

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.^[5] 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.^[6]

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.^[5] 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.

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.^[7] 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 is entrepreneurial work: deciding what the organisation is for, what finished looks like, which roles exist and why.^[7] 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".

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.^[7] 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.

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 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."^[8]

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).

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 tells that story and builds the briefing method around it.

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.^[9] Executives' agents reverse the direction.^[9] 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). 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 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.

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 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.

The individual contributor’s struggle is real, and I know it from the inside; Chapter 19 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.

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.^[10] 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.)

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.)

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.)

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.)

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.^[11] 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.

Grove’s definition gives the executive a simple test for every agent they launch:^[5] 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.

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 is about those systems.