Ask Sarah, she knows!
The silent tax of never improving what works just well enough
Deep Dive #5 in “The Agentic Enterprise” Series
In 2019, a procurement team at a mid-sized German manufacturer still processed purchase orders the same way they had in 2012. Seven people back then, now twenty-three. The ERP system had been upgraded twice. The process hadn’t changed once.
I asked their team lead when they’d last redesigned the workflow. She laughed. “We talk about it every retrospective. Then Monday comes and there are 200 orders in the queue.”
Her team had adapted, of course. Workarounds layered on workarounds. A shared spreadsheet that tracked which supplier codes the ERP rejected. A naming convention for attachments that only three people understood. One colleague everyone called “the oracle” because she remembered which approval chains applied to which cost centres. The process hadn’t improved. It had accreted scar tissue.
Every capability operates in two modes simultaneously.
Operate means running instances through the capability: processing invoices, handling tickets, deploying releases, onboarding employees. The machine running.
Modify means improving the capability itself: redesigning the process, building better tooling, updating rules, eliminating friction. The machine getting better.
Organisations systematically underinvest in modify because operate is urgent and modify is merely important. Urgency always wins when people run at full utilisation.
James March nailed the dynamics in his 1991 paper “Exploration and Exploitation in Organisational Learning.” His argument was precise: exploitation (operating) returns are more certain and faster than exploration (modifying) returns. Rational local actors consistently choose exploitation. Not because they’re lazy. Because incentive structures reward delivery over improvement, certainty over experimentation.
March called the result the “success trap.” Organisations get very good at doing what they’ve always done, slightly better each year, right up until that capability is no longer what the market needs.
Toyota understood the trap and built a structural escape. Their production system makes improvement an operation, not an afterthought. Kaizen time is separated from production with its own allocation, its own metrics, its own reporting chain. Western companies that copied Toyota’s kanban boards without this structural commitment got prettier boards and no improvement culture. The tools were downstream of the architecture.
Google’s 20% time encoded the same principle. Modify time must be protected by policy, not left to individual initiative. Individual initiative is always outcompeted by organisational urgency.
Software engineering calls the accumulated deficit “technical debt.” But every organisation accumulates the same debt in its processes. Workarounds that should have been incorporated. Edge cases handled by asking Sarah because she knows. Automation deferred because “things will calm down.” They never calm down. The longer you defer modify, the more expensive it becomes.
Here’s where AI agents change the game.
In a traditional organisation, the operate-modify ratio is structurally forced toward 95/5 or worse. Humans spend nearly all their time running processes, with scraps left for improvement. The DevOps principle “you build it, you run it” tried to fix this by making the same team responsible for both modes. It helped. But the operational load still dominated.
AI agents can invert that ratio. When agents handle the operate mode (running instances through well-defined processes, executing routine work at scale) the humans in each capability cell are freed for modify. Instead of 80/20 operate-to-modify, you can approach 30/70 or even 20/80.
That procurement team I mentioned? Imagine their week restructured. The AI layer handles instance processing: routing purchase orders, applying approval rules, flagging exceptions. The team lead no longer spends Monday through Thursday clearing the queue. She spends it analysing why 8% of orders still require manual intervention, redesigning the skill to handle those cases, testing the redesigned process, monitoring the AI’s execution quality.
She becomes a capability engineer. Not a process operator.
The portfolio manager in the cell protects that modify time from being consumed by operate pressure. The structural equivalent of Toyota’s team leader with kaizen time, except now AI carries the operational load.
The risk is real and predictable. Organisations adopt AI for operate tasks, achieve the efficiency gains, then use the freed human capacity for more operate work. More volume. More throughput. The modify deficit persists despite the AI.
Every technology wave has produced this trap. Spreadsheets didn’t reduce finance team hours; they increased the volume of analysis. Email didn’t reduce communication overhead; it increased message volume. The tool that should create capacity for improvement instead gets used to do more of the same thing.
Avoiding the trap requires explicit architectural decisions.
Budget modify time as a percentage, not as leftover capacity. Start with 30% for mature capabilities, 50% for new ones. Zero modify time is never correct. It’s managed decline.
Track the ratio. Measure actual time on modify activities (process improvement, tooling, training) versus operate activities (running instances). Report it. What gets measured gets protected.
Vary the allocation by maturity. New capabilities need heavy modify investment, maybe 50/50, because the design is still being refined. Mature, stable capabilities can run at 80/20. But the allocation must be explicit, not assumed.
Make modify outcomes visible. An invoice processed is visible. A process improvement isn’t, until it reduces processing time by 15%. Build dashboards that show the modify dividend: cycle time trends, exception rates, automation coverage.
The modify deficit exists in your organisation right now. Audit one capability cell. Ask two questions. What percentage of time last month was spent running the process versus improving it? And what’s the list of known improvements you’ve been meaning to make?
The answers will reveal the deficit. The deferred improvements list is the debt backlog. The percentage split tells you whether the system can currently service it.
Then make one structural change. Protect four hours per week per person for modify activities. Not “if capacity allows.” Scheduled. Inviolable. See what happens over a quarter.
That procurement team lead? She told me something I haven’t forgotten. “We’re not bad at our jobs. We’re just never allowed to make them better.”
The agentic enterprise changes that equation. AI runs the machine. Humans improve it. Fund both.
Next in the series: Deep Dive #6, The Floor, Not the Ceiling, on how two-tier architecture gives you consistency without killing local intelligence.