Chapter 13: Track What’s Owed, Not What’s Done

In the 1980s Terry Winograd and Fernando Flores argued that the basic unit of work in an organisation is not a task but a conversation. Someone makes a request. Someone else promises to meet it, against conditions both sides understand. The work is done, and the person who asked declares themselves satisfied, or doesn’t.^[1] Work goes missing at the joints of that loop: the request nobody acknowledged, the promise nobody wrote down, the delivery nobody accepted. Their model became a product, The Coordinator, which asked people to label their messages as requests and promises so that the software could track which conversations were still open.^[1]

It is worth knowing how that went. The anthropologist Lucy Suchman argued that a system which makes people classify everything they say as a request or a promise becomes an instrument of discipline and control, a way for management to account for every intention.^[2] She had a point, and it shapes how a ledger should work. It is a tool for the role to see what it owes, written by the role or by an agent working for it. It is not a tool for watching people.

What has changed since the 1980s is that the classifying no longer needs a human. My agent pulls the promises out of ordinary messages, so nobody fills in a form, and the loop is cheap enough to run on every role.

Construction learned the same lesson by a different route. The Last Planner System, developed by Glenn Ballard, measures crews by Percent Plan Complete: of the tasks a crew committed to last week, how many got done?^[3] The measure is not output. It is how reliable the crew’s promises are, because everyone downstream plans around those promises. A crew that finishes a lot of work but rarely the work it promised is a hazard to every trade that follows it.

A done list can’t show the promise nobody wrote down, the request acknowledged and forgotten, or the task "in progress" for three weeks. It also flatters: every line on it is good news. A ledger’s open items are the organisation’s debts.

"Released" is my agent’s "not my call": the obligation is gone but was never delivered, and the person waiting needs to know who owns it now.

Every occupant overstates its own progress. People do it out of optimism and pride. Agents do it for reasons that are less human but just as reliable. When Anthropic’s engineers built a harness for agents working over many hours, they found that one major failure was "Claude’s tendency to mark a feature as complete without proper testing."^[4] A separate Anthropic study was blunter: "agents reliably skew positive when grading their own work."^[5]

The harness team did not answer this by telling the agent to try harder. They changed what the agent was allowed to touch. The work was written as a list of features, every one starting as failing, and the agents were told to edit that list "only by changing the status of a passes field." Removing or rewriting the tests was declared "unacceptable."^[4] An agent could claim a feature worked. It could not change the definition of working.

So decide what evidence closes a commitment when the commitment is made, not when someone says it is finished, and make sure it is something the occupant cannot simply assert.

Our project-manager agent has this in its charter. 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." How the work was done is the doer’s business (Chapter 8). It cares whether the ticket carries proof: the merged change, the passing check, the screenshot from the real system.

Status can be wrong in the other direction too. The documentation for Claude Code’s agent teams warns that "teammates sometimes fail to mark tasks as completed."^[6] A ledger that trusts the occupant’s status field is wrong both ways. Evidence corrects both.

Good closing evidence is usually something that changed in the world:

The same rules apply to people. If an engineer says "I’ll handle it" in a meeting, the ledger closes when the evidence appears. That isn’t distrust; it is what makes the ledger fair. And the evidence has to come from somewhere the occupant cannot write, as the pipeline that manufactured its own in Chapter 14 shows.

An agent starts each session knowing nothing about the last one. People forget more slowly, and then they leave. Either way, a ledger kept in the worker’s head dies with the session, the job change or the model upgrade.

Every serious long-running agent design keeps the record outside the worker. Anthropic’s long-running harness gave every new session the same first steps: "Read the git logs and progress files to get up to speed," then "Read the features list file and choose the highest-priority feature that’s not yet done."^[4] Their later Managed Agents design goes further. Everything that happens is written to an "append-only log" outside the program running the model, so that "nothing in the harness needs to survive a crash."^[7] Their research system tells agents to "store essential information in external memory before proceeding to new tasks."^[8]

Microsoft’s Magentic-One, published in late 2024, even uses the word. Its coordinating agent keeps two ledgers. The Task Ledger holds "given or verified facts, facts to look up," facts to derive, and the plan. The Progress Ledger is rebuilt at every step by answering five questions: Is the request fully satisfied? Is the team looping or repeating itself? Is forward progress being made? Which agent should speak next? What should it be asked?^[9] Those five questions would serve any weekly staff meeting.

This is why the ledger belongs to the role. When a role changes occupant, the open commitments go with it, as part of the Role Pack in Chapter 12, and the newcomer knows on day one what it has inherited.

A ledger’s value to a leader is what will miss, said early enough to change.

The charter for our project-manager agent is, on rereading, mostly a set of rules about bad news. It must "LEAD with the 'NEEDS YOUR DECISION' items." It must treat "WILL SLIP" as "an INTERVENTION trigger, not a status note." It must "Ground any 'on track' claim in the REFERENCE CLASS." And it must "Use direct language ('will slip', not 'slightly at risk')."

Each rule answers a familiar failure in status reporting. The first puts the decisions a human must make at the top, where they get read. The second turns a predicted slip into a request for action: cut scope, add help, move the date or tell the customer. The fourth bans the soft words that let a report sound informed while committing to nothing.

The third rule comes from forecasting research. Bent Flyvbjerg, building on Daniel Kahneman’s work on optimism in planning, showed that forecasts built from the planner’s own view of the project are consistently too rosy, and that the cure is "reference class forecasting": start from how comparable projects actually turned out, then adjust.^[10] An agent asked whether a ticket is on track will, left to itself, look at the plan and say yes. Asked how long the last ten tickets of that size took, it gives a more honest answer.

Magentic-One builds the same habit into its coordinator. It keeps a counter of how long the team has been stuck. While the counter stays below a small threshold, two in their experiments, it carries on. Past that, it breaks out, "updates the task ledger, revises the original plan," and starts again.^[9] That is an escalation rule written down before anyone needed it. Most organisations find out that work is stuck when the deadline passes.

People soften bad news because delivering it costs them something. An agent has no reputation to protect, so it can be told to say "will slip" every time. The leader’s part of the deal is to treat that message as useful; if the first "will slip" earns a reprimand, the team will stop saying it.

A ledger drifts. I first asked the promise-keeper to find commitments in my conversations, and, helpful the way agents are, it began recording everyone’s, not just mine. A backup of its instructions from 3 November shows the correction I made. Its scope is now "only commitments GARETH made or owns."

The drift was well meant and still wrong. A digest of everyone’s promises buries the few that are mine, and a commitment on my ledger but owed by someone else implies I am accountable for it. And Suchman’s warning applies: one person’s agent keeping a private record of what everyone else has promised is surveillance, however friendly the intent. Each role keeps its own ledger. A manager sees the roll-up of the roles that report to them, and so do the people in those roles.

The ledger also has to be readable. Around the same time, the same agent posted a comment on a Linear ticket so dense that nobody could follow it, and I had to apologise in the thread: "sorry for the slop." A ledger entry is a message to a person who is busy. It needs one line on what is owed, one on the evidence, and one on what happens next. Anything longer belongs in a link.

Andy Grove argued that every indicator should be paired with one that catches its side effects, so that pushing one number up does not quietly push another down.^[11] A Commitment Ledger needs its pair. Count commitments closed, and also count commitments reopened: the "done" that came back because the evidence didn’t hold. A role that closes a lot and reopens a lot is not productive. It is making the same promise twice.

Every commitment needs something to start the work. Among people this is too obvious to write down. With agents you have to say what, because an agent does nothing until something wakes it.

When I listed my own agents by what wakes them, they split cleanly into two kinds.

Scheduled work is dependable and a little wasteful. It runs whether or not there is anything to do. Our morning-standup agent is never woken unless I have accepted that day’s standup (Chapter 11): a scheduled role with a reason to stay quiet built in.

Event-driven work is efficient and fails in silence. Glass Factory was woken by Linear whenever a ticket changed. From 2 to 6 November its own status line read "LINEAR WEBHOOK DISABLED." For four days a role that owed work could not hear that work had arrived, and the only evidence was a line on a status page nobody was reading. Team bots that wake only when someone mentions them have the same weakness, as Chapter 15 shows: a colleague who doesn’t use the right name gets silence, and silence looks like an answer.

Cognition’s managing agent can "schedule messages to itself" to set up follow-ups while its sub-agents work.^[12] Claude Code can now run a prompt on a recurring schedule, including on Anthropic’s own machines, so the work carries on when your computer is off.^[13]

The trigger is part of the role, not the occupant, so it belongs in the Role Charter from Chapter 9: "The instructions and triggers go on the scheduled job," not on the agent. Every event-driven role then gets a scheduled check that its triggers are still firing. Every scheduled role gets a test for whether it has anything worth saying.

This section is about my own failure, and I’d rather tell it straight.

Several of my agents depend on email credentials that lock whenever my workstation does, the keyring problem told in Chapter 2. The agents behaved well: they reported the failure honestly, with the same one-line fix, every day from late October into November. Nobody acted. The person who could act was me.

In John Darley and Bibb Latané’s experiments, people who believed others could also hear someone in distress were less likely to help, and slower when they did.^[14] An alert in a shared channel is a room full of bystanders. My case was worse: the alert came to the one person who could fix it, and I treated it as background, because it arrived the same way every day and nothing visibly broke.

The lesson is that an escalation is a commitment like any other, and it has to go on someone’s ledger. When an agent raises a problem it cannot fix, the problem becomes something owed by a named role, with a due date and closing evidence. For the keyring, that evidence would have been "email jobs survived a restart," not "the human unlocked it again." If the same escalation comes back unchanged, it goes up a level, to the role that owns the system. And once an alert has fired three times with the same fix, the missing system is the problem, which moves it into the Friction Review in Chapter 16.

A running ledger is the most honest performance record in the building, for people and agents alike.

The obvious measure is Ballard’s: of what this role promised, how much arrived on time with evidence?^[3] Next to it, Grove’s pair: how much of what was closed came back?^[11] Then the measure that separates a good occupant from a merely busy one: how early did it raise the slips? A role that delivers 80% of its promises and flags the other 20% a week ahead is worth more than one that delivers 90% and lets the rest fail without warning. The first lets everyone else plan. The second makes them guess.

These numbers go on the Scorecard from Chapter 4, one line per role, and they are where the agent performance reviews in Chapter 17 begin. Whether an agent has earned more autonomy starts with whether its promises have been reliable, and the ledger already has the answer.

Two cautions. First, the ledger applies to everyone, executives included, or the team will notice that accountability is something done to them. Second, a ledger is not a stick. The research on failing multi-agent systems puts a whole category of failures under task verification, meaning nobody checked properly whether the work was right or finished.^[15] When a role keeps missing, the first suspect is the evidence and the check, not the occupant. Gerber’s principle holds: systems run the business, and people, and now agents, run the systems.^[16] A ledger shows you where the system is weak. It is not a list of people to blame.

A Commitment Ledger is the least glamorous idea in this book and one of the most useful. It asks every role what it owes, to whom, by when, and what will prove it paid. It closes nothing on anyone’s word, and it lives outside the worker, so obligations outlive sessions, job changes and model upgrades. Run well, it turns status reporting from a performance into a forecast, and gives you the record you need to decide which occupants deserve more trust.

What it can’t do is stop an occupant from doing something that can’t be undone while the ledger is still catching up. For that you need people standing at a small number of carefully chosen doors. Chapter 14 is about where those doors are and how to make the people at them more than decoration.