Appendix D: For Your Technical Team
By Gareth Price · Last updated
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.
| 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 |
|
Role Pack |
Context engineering: the always-loaded layer, skills loaded on demand, memory, live sources |
|
Three lock-in tiers |
Skill prose → scripts inside the skill → hooks, deny rules, managed settings |
|
Commitment Ledger |
Progress files, task lists, task and progress ledgers, durable execution logs |
|
Sponsor |
An accountable human on the agent’s identity record (Entra Agent ID "sponsor") |
|
Acceptance |
Evals, independent verifiers, pass^k |
|
One boss, few reports |
Orchestrator–worker topology, single writer per artefact |
|
Friction Review |
A failing eval case plus a system change, kept in version control |
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."[1] 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.[2] 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."[2] Skills became an open standard on 18 December 2025, so a role defined as skills can move to a different vendor’s occupant.[2]
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.[3] 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:
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 runThree 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."[4] 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)."[4]
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.[5]
| 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."[5] Its offline review of logs and notes, "often called dreaming", is a machine-run Friction Review over the Role Pack.[5]
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) 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."[6] 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."[6]
| Tier | Mechanism | Use it for |
|---|---|---|
1. English |
Skill body, system prompt, |
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 |
|
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."[6] Auto mode’s classifier is a judgment, so "your 'never' rules belong in deny rules or hooks."[6] 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."[6]
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."[6]
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.[7] 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."[8] 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.[9] 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
TaskCompletedhook can refuse completion.[10] -
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."[11] Temporal offers the same for self-hosted OpenAI Agents SDK apps.[12]
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 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. 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."[13] Sponsorship must be maintained "when an employee who’s a sponsor moves or leaves."[13] 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.[14] 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.[15] 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.[16] 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.[17] 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%."[17] 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."[17] 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."[7]
-
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.[7]
-
Separate the verifier’s context. Cognition reports review works best "when the coding and review agents do not share any context beforehand."[18]
The negative example is in Chapter 14: 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 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%."[19]
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.[18] 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."[20] 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."[20]
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."[21] 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."[22] 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.[20]
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.[15] 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."[23] 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; the vocabulary is in Appendix E.
Frequently Asked Questions
-
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.
-
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.
-
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.
-
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.
-
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.