Chapter 12: Everything They Need on Day One

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.^[1] 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."^[2] That list is the start of 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.

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

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

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.^[7] 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.^[8] 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.^[9] 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."^[3] 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 explains why that split matters for roles. For Role Packs, it means the identity stays thin and the knowledge stays with the work.

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

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."^[11] 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). 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 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.^[7] The project manager’s rule that spread to every agent did no harm that I noticed. The next one might.

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.

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

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), 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): "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 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.

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

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). 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.^[12] 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.^[1] With agents, you do that every morning.

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 turns from what each role knows to what each role owes, and to the Commitment Ledger that checks those promises against evidence.