Module 8 — The AI Agent: Governing It · Lesson 8.4
Runbooks, Goals and the Waiting-On Ledger
Encoding recurring procedure, standing objectives, and outcomes that arrive later
~11 min
What you'll learn
- Write a runbook that encodes a procedure rather than a wish
- Set goals the agent can meaningfully check progress against
- Use the waiting-on ledger for asynchronous outcomes
- Decide between a runbook, an automation, and a scheduled run
Asking the agent to do something is a transaction. These three tools are what make it a relationship: a procedure it knows, an objective it holds you to, and a memory of what it is still waiting on. They are the difference between an assistant you instruct each time and a colleague who knows the job.
Runbooks
A runbook encodes a procedure the agent can follow: the steps, the order, the checks. 'Onboard a new client' or 'close the month' or 'handle an incident' — the recurring sequences your team currently keeps in someone's head.
Writing one well looks like writing a good document for a new joiner. Be explicit about the order, and be explicit about the decision points — where the procedure branches and on what. A runbook that says 'check with the account manager if the value is above X' is a procedure; one that says 'use judgment' is a wish.
The payoff is not just automation. A written runbook is the first time most teams see their own process, and about half the value is discovering the steps nobody could name.
Goals
Goals are standing objectives the agent knows about and can check progress against.
The useful ones are measurable and time-bound. 'Reduce median cycle time on the platform project to under four days by the end of the quarter' is a goal the agent can report on. 'Improve delivery' is not.
What makes them worth setting rather than just tracking on a dashboard is that they change what the agent brings up. A goal is context: it is why an agent might mention, unprompted, that a change you just made moves you away from something you said mattered.
One caution: the goal-checking capability does work when it runs, which means it is not the free read it looks like. Treat 'check my goals' as an action with a cost rather than a refresh you hit repeatedly.
The waiting-on ledger
Some outcomes arrive later than the conversation: a reply to an email, an answer from a colleague, an external approval, a build that finishes.
The waiting-on ledger records those. The agent notes what it is waiting for, and follows up when the outcome arrives or fails to.
This fixes the specific failure where an agent does something useful and then never mentions how it turned out — you asked it to chase someone, it did, and neither of you ever closes the loop.
Use it explicitly: 'chase this and tell me when they reply' creates an entry. Then, periodically, look at what is open. An accumulating waiting-on ledger is a to-do list in disguise and deserves the same attention as any other queue.
Runbook, automation, or scheduled run?
These three overlap and choosing wrongly is a common source of duplicated machinery.
An automation rule is deterministic and event-driven: when a task becomes overdue, notify the assignee. No judgment, no model. Reach for it when the rule is simple and the trigger is an event in Kavanah.
A scheduled run is time-driven and agentic: every weekday at 8am, produce a work plan. Reach for it when you want output on a cadence and the output requires reasoning.
A runbook is procedure-driven: when someone invokes it, follow these steps with judgment at the marked points. Reach for it when the trigger is a human saying 'do the thing' and the thing has steps.
Mixing them up produces the classic mess: an automation that tries to encode judgment, or a scheduled run that reimplements a notification. Pick by the trigger — event, clock, or person.
Encode your recurring work
- 1
Write one runbook for a procedure you repeat
Ask the agent to help draft it. Be explicit about the branch points and what they depend on.
- 2
Set one measurable, time-bound goal
Something with a number and a date. It changes what the agent volunteers, not just what it reports.
- 3
'Chase this and tell me when they reply.' Then check the open ledger next week.
- 4
Audit your existing machinery for overlap
Automations, scheduled runs and runbooks doing similar things. Pick by trigger: event, clock, or person.
What to watch
- Runbook invocation rate
- How often each written runbook is actually used.
- Healthy signal: Regularly, or it encoded a procedure the team does not really run. Delete it rather than maintaining it.
- Open waiting-on entries
- How many recorded waits are still unresolved.
- Healthy signal: Small and turning over. A growing ledger is a to-do list nobody is working.
- Goal-check frequency
- How often goals are checked, given that checking does real work.
- Healthy signal: A cadence, not a reflex. Weekly is usually right; hitting it repeatedly is spend without new information.
Key takeaways
- ·A runbook encodes a procedure with explicit branch points; 'use judgment' is a wish, not a step.
- ·Half a runbook's value is discovering the steps of your own process that nobody could name.
- ·Goals must be measurable and time-bound to change what the agent volunteers.
- ·The waiting-on ledger closes the loop on outcomes that arrive after the conversation.
- ·Choose by trigger: event → automation, clock → scheduled run, person → runbook.
Next: the clock-driven one — scheduled autonomous runs, and how to set one up without buying a recurring bill for nothing.