Module 7 — Agentic Project Management · Lesson 7.4
Optimizing the Agentic Workspace
Reading your own approval history, override rate, and refusal ledger back to yourself — and what to change when
~14 min
What you'll learn
- Run a monthly tuning review from four signals the workspace already records
- Convert an approval history into action policies instead of approving forever
- Read an override rate as evidence about the rule, not about the person overriding
- Know the three failure modes of tuning: proxy chasing, felt productivity, and the silent ratchet
Everything so far is setup. Levels, policies, checkpoints, goals — you chose them all before you had any evidence, which means you chose most of them wrong. That is expected and fine. What is not fine is leaving them there. The good news is that you do not have to think your way to better settings. Your workspace has been recording the evidence the whole time: every action the agent took, every approval you granted, every recommendation you overrode, every piece of work the charter refused. Optimization is the discipline of reading those four records on a cadence and letting them move the settings. This lesson is that loop.
Stop asking how it is going
Start with the thing that does not work, because it is the thing everyone does: asking the team how the agent is doing.
Self-report about automation is unreliable in a specific, measured way. In a 2025 randomized trial, experienced open-source developers working in codebases they knew well were 19% slower when allowed to use AI tools — and believed the tools had made them about 20% faster. The perception and the fact did not merely differ in size; they pointed in opposite directions, and the developers held the wrong belief after having done the work (METR 2025).
That finding should end a certain kind of meeting. 'Is the agent helping?' is not a question a retro can answer, because the people in the retro have the same access to their own experience that those developers did. It is a question the ledger can answer. Everything below is a way of asking the ledger instead.
The same caution applies to your own confidence about your settings. If you feel like the approval queue is working, that feeling is not evidence.
Signal one — your approval history is a policy you have not written yet
Every parked action you approved is a small, dated, specific statement that this category of thing was fine. Thirty of them are a policy. You are just enforcing it by hand, one item at a time, forever.
The tuning move is mechanical. For each action category, look at the last month of parked actions and count: how many did you approve unchanged, how many did you edit, how many did you reject?
A category you approved unchanged nearly every time does not need approval. It needs allow, or allow-up-to-a-daily-budget if the risk is cumulative. Leaving it parked is not caution — it is a queue item that trains everyone to click through, which degrades the queue for the categories that genuinely need reading. Rubber-stamping is not free; it is paid for out of the attention available for real decisions.
A category you rejected nearly every time does not need approval either. It needs block. Every one of those queue items was a small tax on someone's day to reach a conclusion you had already reached.
The categories worth keeping parked are the ones with a genuine mix — where you approve some and reject some, because the decision actually depends on the specific action. That mix is the definition of a decision, and those are the only items that deserve a human.
Do this once and the queue usually shrinks by more than half. The agent gets more useful and you make fewer decisions, which feels like it should be a trade-off and is not — it is the same move, because the queue was never protecting you from the things you approved anyway.
Signal two — override rate is evidence about the rule
Kavanah records overrides in two places, and both are widely misread.
When the agent recommends an assignee and you pick someone else, that is an assignment override, and the workspace can log the recommendation, your choice, and optionally your reason. When the KVN gate refuses a piece of work and you insist anyway, the write proceeds but the hit is still recorded, stamped as an override.
The misreading is treating a high override rate as a discipline problem — as people ignoring the system. It is almost always the opposite. An override is a person with local knowledge disagreeing with a rule, and they are usually right, because they can see the specific case and the rule cannot. A rule that is overridden most of the time is not being flouted; it is wrong, or it is stale, and it has been wrong for however long the pattern has been running.
So read override rate as evidence about the rule:
A Negation that is overridden constantly is one the team has quietly stopped believing. Either the boundary genuinely moved and the charter has not caught up — in which case change the charter, which is one of the three honest responses to a refusal — or the Negation is written too broadly and is catching work it never meant to. Both are charter edits, not people problems.
An assignment recommendation overridden constantly for one member means the capability model is wrong about that member, usually because their declared skills are stale or their real strengths were never declared.
The corollary, from lesson 5.4 and worth repeating because it is the half people forget: a rule with zero hits is not necessarily healthy. It is either irrelevant or invisible, and those need opposite fixes. Silence is not success.
Signal three — the reversal rate, and the ratchet that only goes one way
The reversal rate from lesson 7.1 — how often a human undid, deleted, or rewrote something the agent did autonomously — is the closest thing this module has to a single honest number. It is the one metric that cannot be gamed by feeling good about the agent.
Use it as a ratchet on autonomy. Widen the delegation, watch reversal rate for a fortnight. If it stays flat, the widening was earned; widen again. If it rises, narrow back — not review harder. This distinction is the whole lesson. A rising reversal rate means you delegated past the agent's frontier, and the remedy for being past the frontier is to come back inside it, not to station a human at the edge. Stationing a human at the edge is exactly the arrangement the automation-bias evidence says fails.
The failure mode here has a name worth knowing: the silent ratchet. Autonomy is easy to widen and socially awkward to narrow — narrowing feels like admitting the agent is not working, or like distrusting the person who championed it. So teams widen on good weeks and never narrow on bad ones, and the setting drifts monotonically upward regardless of evidence. If you have never narrowed an autonomy setting, that is not because your widenings were all correct. It is because narrowing was never on the table.
Make it explicit: the monthly review can lower a level. Say so out loud, once, and it becomes a normal move rather than an indictment.
Signal four — what the agent is not being asked to do
The three signals above all read actions the agent took. The most valuable signal is the one with no rows: the work it was never asked for.
A persona nobody chats with, a runbook nobody starts, a scheduled digest nobody acts on, an autonomy ceiling nobody opted into. These leave no trace in any ledger, because absence does not log. But each one is a specific piece of evidence — that the capability was scoped wrong, or designed wrong, or that the team tried it once and quietly went back to the manual path.
This is where an agentic workspace actually dies, and it dies without an error. Nothing breaks. The runbooks sit there. The dashboard still renders. The setting is still on. It just is not doing anything, and because none of the ledgers has a row for did-not-happen, no review that only reads the ledgers will ever notice.
So the monthly review needs one question that is not a metric: what did we stand up that nobody used? Then either fix it or delete it. Deleting is usually right and almost never done, because a dormant capability costs nothing visible while a deleted one is an admission. But a workspace full of dormant machinery is one where nobody can tell which parts are load-bearing — and that is the state in which the next person to arrive trusts all of it equally.
The tuning review, in fifteen minutes a month
Put the four signals in an order and it is short.
First, the approval history. Any category approved-unchanged nearly always moves to allow or a budget. Any category rejected nearly always moves to block. What is left is the real queue.
Second, the overrides. Any rule overridden more than it is obeyed gets edited or retired this month — not discussed again next month. Any member whose assignment recommendations are consistently overridden gets their skill profile corrected.
Third, the reversal rate. Flat since the last widening means widen once more. Up means narrow. Explicitly allow narrowing.
Fourth, the absences. Name everything nobody used and either fix or delete it.
That is the loop. Its virtue is not sophistication — it is that every step is driven by a record rather than by a recollection, which is the only way to escape the trap the first section describes. A team that runs this four times has a workspace tuned by evidence. A team that reasons about it carefully every month for a year has a workspace tuned by whoever is most confident in the room.
Run the tuning review once
- 1
Open the activity ledger and filter to the last month
For each action category, count approved-unchanged, edited, and rejected. That table is your policy, written in your own past decisions.
- 2
Move every lopsided category out of the approval queue
Approved nearly always → allow, or a daily budget if the risk is cumulative. Rejected nearly always → block. Only genuine mixes stay parked.
- 3
Read the Negation ledger for overridden rules
A rule with a high override count is one the team has stopped believing. Change the charter or retire the rule — the overrides are the evidence, not the offence.
- 4
Name one thing nobody used, and delete it
A dormant persona, runbook, or scheduled digest. Deleting is usually right and almost never done. Absence leaves no ledger row, so it has to be raised deliberately.
The tuning dashboard
- Queue composition (approve / edit / reject per category)
- For each action category over the last month: the split between approved-unchanged, approved-with-edits, and rejected.
- Healthy signal: Our recommended read, not a measured finding: any category above roughly 90% in one column is a policy waiting to be written. Genuine mixes are the only items that deserve a human.
- Override-to-obey ratio, per rule
- For each Negation or recommendation rule: times overridden divided by times honoured.
- Healthy signal: Above 1 means the rule is wrong or stale, not that people are undisciplined. Zero in either column means the rule is invisible or irrelevant — check which before congratulating yourself.
- Reversal rate after a widening
- Change in the fraction of autonomous actions later undone, in the fortnight after an autonomy level or policy is loosened.
- Healthy signal: Flat means the widening was earned. Rising means narrow back — the frontier moved, and reviewing harder is the response the evidence says does not work.
- Dormant capability count
- Personas, runbooks, and scheduled runs with no invocation in 30 days.
- Healthy signal: Should be near zero, kept there by deletion rather than by hope. This is the only metric here with no ledger behind it — you have to go looking.
Key takeaways
- ·Do not ask how the agent is going. Self-report about automation points the wrong way — read the ledger instead.
- ·Your approval history is a policy you are enforcing by hand. Lopsided categories become allow or block; only genuine mixes deserve a queue.
- ·A high override rate is evidence the rule is wrong, not that people are undisciplined. Edit the charter.
- ·Use reversal rate as a ratchet — and make narrowing an explicitly allowed move, or the setting only ever drifts up.
- ·The most valuable signal has no ledger rows: the capability nobody used. Absence does not log, so ask for it deliberately.
That completes the course. The discipline it teaches has not changed in five thousand years — direct, allocate, feedback, consequence, against a clear statement of what you are for and what you refuse. What changed is that a system now absorbs a large share of the doing, which raises rather than lowers the premium on the deciding. The charter is where the deciding lives. Everything in this module is machinery for making sure the charter is what actually governs, rather than a document that agreed with whatever happened.
Sources
- 1.Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
Joel Becker, Nate Rush, Beth Barnes, David Rein (METR) · METR (arXiv:2507.09089) · 2025
The load-bearing source for section one: experienced developers were 19% SLOWER with AI on real tasks in codebases they knew, while believing they were ~20% faster. Perception and measurement pointed in opposite directions — which is why this lesson reads ledgers rather than running a retro.
- 2.Complacency and Bias in Human Use of Automation: An Attentional Integration
Raja Parasuraman, Dietrich H. Manzey · Human Factors 52(3), 381–410 · 2010
Cited for the narrow-back-don't-review-harder rule: automation bias occurs in experts as well as novices and 'cannot be prevented by training or instructions', so stationing a more careful human at the frontier is not an available fix. (Open-access copy from the second author's institution.)
- 3.Artificial Intelligence Risk Management Framework (AI RMF 1.0)
National Institute of Standards and Technology · NIST AI 100-1, U.S. Department of Commerce · 2023
The framework's MEASURE and MANAGE functions are explicitly iterative rather than one-time, and GOVERN is described as cross-cutting and continuous — the standards-world statement of this lesson's thesis that an agentic deployment is tuned on a cadence, not configured once.
- 4.2025 DORA Report — State of AI-assisted Software Development
DORA / Google Cloud · Google Cloud (~5,000 practitioners) · 2025
AI amplifies a team's existing discipline rather than substituting for it, and correlates with higher throughput alongside higher delivery instability — the reason tuning is a standing practice rather than a launch task.