Chapter 8: What and Why, Never How

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

Our CEO has said as much himself (Chapter 1). 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.^[2] 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.

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

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

Rules that a weaker model needed made a stronger model worse.^[6] 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.

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

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 covers when a requirement deserves a hard rule rather than a sentence.

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

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

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

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.

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

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

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

"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 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 describes how autonomy is earned this 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 puts them on one page.