C/AChief of Agents

Working with AI agents

Chief of Agents

A Chief of Agents is the person responsible for work done by AI agents.

This is how I do that while building software.

Six agents in dark suits with geometric cube heads, gathered against a warm orange background.

What a Chief of Agents does

Try each decision in a checkout project.

Choose the problem, assign the work, set boundaries, and review the result.

What you'll find here

When an agent deleted a screen

An agent removed a broken interface. The checks passed because the feature was gone. The example shows what the user lost.

The deleted screen
Screen removedThe user’s task disappears with it.
✓ Checks pass✕ User can’t finish
Read the full example

Start with one
complete path.

Start with a clear goal. Prove one journey, then leave a kit that lets the next agent continue.

Ask before you build

Let the agent interview you. Settle the decisions that would change the work before it starts.

Read the context
Resolve blocking questions
Record the decisions

The checkout goal is agreed. The payment provider is undecided and changes the integration. What should the agent do first?

One project, one playbook

Write down who the product serves, what it must do, and where its limits are.

Product + usersWho it serves. What it does.
Boundaries + outcomesWhat may change. What must work.
One project playbookThe decisions every agent reads.

Build a journey, not a layer

Connect one user action to a real result. A finished screen alone is not a working feature.

Finished layers ≠ a working product.

The first working thread

Prove one small journey all the way through before repeating it across the product.

One user action
InterfaceServiceDatabase
A visible result

Leave a takeover kit

Give the next person or agent enough context to continue without reading the whole chat.

Enough context to start cold.

The takeover kit

01 / CONTRACT

Product goal + journey map

The product, boundaries, and end-to-end outcomes.

02 / SCOPE

Work brief

Decisions, dependencies, and a clear test for done.

03 / INSTRUCTIONS

Next-chat instructions

The next task and where to begin.

04 / REALITY

Verified progress

The exact code version, proof, and unfinished work.

New chat. Same project.

The conversation can end. Save the decisions, code, and proof where the next agent can read them.

THE SAVED PROJECT CONNECTS THE CHATS
Shared code repositoryPlaybook · Current code · Verified progress

Agree on the product goal. Build the first complete journey. Save what works.

Build an organization.
Not a crowd of agents.

Divide the jobs. Share progress. Check the result independently.

More freedom, clearer rules

An agent can work longer on its own when it knows the goal, limits, and stopping point.

At the keyboard

The human continuously supervises the work.

Away from the keyboard

A written goal, task board, proof, and stopping point guide the work.

One captain, clear jobs

Give one lead responsibility for the result. Let builders do the work and separate reviewers check it.

One team leadOwns the result
BuildersImplement the work
Independent reviewersTest and inspect it
Shared task boardGoal · Changes · Proof · Progress · Limit
One lead brings the checked work together.

Three agents finished their pieces of onboarding. Who should check that a new user can complete the whole journey?

One job or a team?

Repeat a check for one job. Coordinate specialists when several jobs must come together.

Loop

Check and improve one result until it passes.

Graph

Give specialists separate jobs, then combine their checked results.

Pick a shape for the work

A straight path finishes once. A loop improves a result. A network brings specialists together.

Choose the simplest shape.

WorkProofOwner decision
One shared task board
Allowed work
What may change.
Changes
What changed.
Proof
What was checked.
Progress
What is done or blocked.
Limit
Where the run must stop.

Leave the keyboard.
Keep the boundaries.

Set the limits before you leave, then return to a reviewable result.

Before you step away

Agree on what can continue, what must stop, and which decisions need you.

PERMANENT FENCES

No secret exposure. No overwriting project history. No merge, live database change, or publication without the owner.

Keep going

Build · Test safely · Collect proof

Wait for the owner

Merge · Change live data · Publish

You’re away. The builder needs a product decision, but an independent test job is ready. How should the run continue?

Use the simplest route

Choose the shape your work needs. More moving parts mean more coordination.

Dependent steps that finish once

Sequence

A result that needs checking and improving

Loop

Specialists working in parallel

Graph

A run you can walk away from

Follow this 5–6 hour example. Safe work continues; a blocked job waits; the final decision stays with you.

Walk through an unattended run

Step through the run. Pause one job to see what keeps moving.

THE CONTRACT

Goal · Allowed actions · Limits · Test for done

5–6 HOURS AFK
BUILDReady
TESTReady
EVIDENCEReady
SHARED STATE Goal · Proof · Progress · Limit

Come back to proof

Review the completed work and its evidence. You should not have to supervise every step.

Review the evidence
Make the human decision
Approve the protected action

Deployment
is not proof.

Follow the change from your laptop to a real customer. Each checkpoint answers a different question.

From working code to real users

Take the change through checks, review, merge, deployment, and a live test.

Working code is the beginning.

APPLICATION CODE
    DATABASE READINESS
    Compatible database changeTest the databaseHuman approvalLive database checked
    The database must be ready before the owner merges the code.

    Keep secrets out of sight

    An API key is a password for a service. Files, terminal output, and process details can all expose it.

    Names in the code. Values in the secret store.

    Code + instructions

    Name the key you need. Never include its value.

    Names only
    When the application runs
    1. Secret store
    2. Runtime process
    3. Provider call
    Injected values can still appear in process output. Treat that output as a possible secret source.

    Give tests a sandbox

    Use separate data and permissions so testing a failure cannot hurt customers.

    Test sandbox

    Separate targetTest dataLimited permissionsTry. Fail. Reset.

    Live system

    Customer dataProduction permissionsProtected from tests

    Check the destination first

    A command on your laptop can still contact a live system. Check its target before it makes a call.

    A checkpoint before the first call

    Read the target
    Does it point to this computer?
    Local target → continue
    Remote target → stop before contacting it
    A local tool inherited a production URL and spent about $0.62.

    The database comes first

    Make the database ready before releasing code that depends on it. Keep previously applied changes intact.

    Verify the database change
    Approve the merge
    Deploy dependent code

    Nobody grades their own homework

    A second reviewer checks what changed and whether the intended user journey still works.

    INDEPENDENT REVIEW
    Builder proposes
    Independent checks
    Owner approves

    Count what the provider counts

    The provider reported over ten times our highest estimate. Tests were making live calls that automated checks never saw.

    THE USAGE LEAK
    HIGHEST ESTIMATE1×Baseline
    ACTUAL USAGE>10×Compared with the estimate

    One test run made 238 live requests. Automated checks had no service key, so they missed the leak.

    Same tests. Different access.

    On the laptop
    Key present
    Live calls
    Usage charged
    Automated checks
    No key
    No live calls
    Leak missed
    The fix belongs at the client boundary: block live calls during tests and record provider-reported units for permitted calls.

    Local tests show unexpected provider usage. Automated checks stay green because they have no service key. Where should the fix go?

    No feature, no bug

    Deleting a broken feature can make tests pass. The test must prove the user can still do the intended task.

    Follow the user’s action to the result

    1. Define task
    2. Include feature
    3. Show interface
    4. Keep state
    5. Take action
    6. Run service
    7. Save result
    8. Show success
    Every link must still exist. Removing the broken interface can make checks pass while erasing the outcome the user needed.

    Make the next agent
    harder to fool.

    Save useful lessons, and turn important ones into checks.

    New agent, same old mistakes

    Use past lessons to get oriented. Current code and approved rules decide what is true now.

    Current reality comes first

    Current code + signed governance

    Check what actually runs and what has been approved.

    Repository rules + project wiki

    Past decisions and project instructions explain the context.

    Durable memory

    Preferences and lessons help the next agent get started.

    Use remembered context to find the relevant truth, then verify it. It cannot overrule the system that runs.

    Turn the lesson into a guardrail

    After a serious failure, add a check or rule that catches it next time.

    Turn the incident into a control.

    01 / NAME IT & WRITE THE LESSON

    02 / PUT IT WHERE IT BELONGS
    Project wikiArchitecture · Decisions · History
    Repository rulesFailures every agent must read
    MemoryPreferences · Cross-session recall
    EnforcementHooks · Tests · CI · Permissions
    03 / THE NEXT AGENT REACHES THE PATH

    WARNED WITH EVIDENCE OR BLOCKED

    A local command accidentally reached production. You’ve written down the lesson. What prevents a repeat on a new agent run?

    Delegate the work.
    Keep accountability.

    Reuse good habits. Match the tools to the task. Keep control of the final decision.

    House rules

    A skill is a saved set of instructions. Use it to repeat a good habit without explaining it every time.

    Fix root causes.

    Do not hide symptoms or remove the intended feature.

    Prove it works.

    Use observable evidence at the layer the user experiences.

    Make good behavior reusable.

    Skills package interviews, handoffs, memory, and autonomous runs.

    Match the model to the job

    Spend stronger reasoning on difficult or risky work. Use faster models for routine tasks.

    Route models by the work.

    Builders and reviewers use separate model assignments. Keep one lead throughout a long unattended run.

    The Bottleneck Should Be You

    This is the Chief of Agents role: choose the problem, assign the work, set boundaries, and judge the result. Agents prepare it. You decide when it reaches the real world.

    Agents Do the Work

    Build → Test → ReviewYou Decide.

    The work keeps moving. Your judgment is the final gate.

    Merge to the main branch
    Production database changes
    Publication

    Keep approval of these decisions. Delegate everything else.

    The team has checked the work and prepared a release. Which arrangement keeps you at the right bottleneck?

    The Chief of Agents Toolkit

    Skills Library

    Find a skill for the job. See how I use it. Add it to your agent.

    89 skills and 1 review agent · 8 categories

    All Skills

    Browse the full toolkit or choose a task.

    89 skills and 1 review agent

    A few terms worth knowing.

    AFK

    Away from keyboard. Here, a bounded unattended run with a written contract and a human gate at the end.

    Agent

    A model-driven worker that reads context, uses tools, makes changes, and reports results within assigned permissions.

    PRD

    Product requirements document: the product contract, boundaries, outcomes, and governing decisions.

    Complete journey

    One end-to-end outcome that touches every technical layer required to make it work.

    Tracer bullet

    The first narrow, complete user journey, built to expose integration problems early.

    Takeover packet

    The documents and verified state a fresh person or agent needs to continue a slice.

    Worktree

    A separate Git working directory that lets workers use different branches without overwriting one another.

    Shared state

    Persisted information that aligns workers on scope, progress, evidence, status, and budget.

    Exit test

    An observable condition that defines when the task or slice is complete.

    Proof pack

    Tests, review findings, screenshots, logs, and verified state used to evaluate a completion claim.

    CI

    Continuous integration: automated checks against the proposed change before merge.

    CD

    Continuous deployment or delivery. In the example, an approved merge triggers automatic deployment.

    Compatible database change

    A database change that adds structure or permissions without removing behavior existing code still needs.

    Human gate

    A protected action that requires approval from an authorized person.

    Repository

    The saved project: code, documents, and a record of changes that a fresh agent can read.

    Merge

    Combine an approved code change with the main version of the project.

    Pull request

    A proposal to combine a code change, with its discussion, checks, and review.

    Loopback

    A network address that points back to this computer, rather than a remote system.

    API key

    A secret value that lets an application use a service. Treat it like a password.

    Skill

    A reusable instruction file that teaches an agent a particular habit or procedure.

    The Presentation and Companion Guide

    The presentation and its walkthrough, with internal details removed.

    Install Skills

    Copy this prompt and paste it into your coding agent. It includes sources, setup notes, and instructions to skip existing installs.

    Skill Details