Optimizing the Agentic Workspace

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 recent parked actions and count two things: how many you approved and how many you denied. (There is no third bucket — a parked action is run as proposed or refused; the product has no edit-then-approve.)

A category you approved 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 denied 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 deny 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 signal that best resists self-deception, because it is about what happened rather than how the agent felt. The ledger records it: every time a human undoes an agent action, an 'undone' entry is written and tagged with whether the original ran in chat, on its own, or on a schedule, so you can filter the activity timeline to Undone and see exactly what got reversed and how it was running. The one thing the product does not yet do for you is tie a reversal automatically to the widening that preceded it — that correlation, watching the Undone stream in the weeks after you loosen a setting, is still yours to draw.

Use it as a ratchet on autonomy. Widen the delegation, then watch for reversals over the following fortnight. If none show up, the widening was earned; widen again. If a cluster of undos and rewrites appears, 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 you approve nearly always moves to allow or a budget. Any category you deny nearly always moves to block. What is left is the real queue.

Second, the overrides. Any Negation your overrides keep piling up against 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. Filter the ledger to Undone since the last widening: none means widen once more, a cluster 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 most of its steps are driven by a record the product actually keeps 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.