Field Guide

AI-augmented program delivery

Everything I've learned running enterprise programs with AI in the loop, organised into one place. Not a case for adoption — most of that has already been made, badly. This is what actually changes on a live program once the machine is doing real work, and which parts of the job refuse to move.

Loy O'Kelley · Senior Program Manager, Transformation Executive · 20 field notes · Updated September 9, 2026

I run transformation programs for a living — government, financial services, healthcare, usually inherited mid-flight and usually late. Over the past two years AI has moved from a novelty on those programs to something that drafts the status report, grooms the RAID log, and flags the risk before a human does. That shift is real and I'm not interested in arguing against it.

What I am interested in is the part nobody puts in the vendor deck: the second-order effects. A program doesn't get better because a machine can write faster. It gets better or worse depending on what the organisation does about accountability, the honesty of its records, the volume of its alerts, and the skills its people stop practising. Those four things are where every AI-augmented program I've seen either compounds its discipline or quietly loses it.

The governing idea

Machines draft. Humans sign. You can delegate the labour of delivery — the drafting, the summarising, the pattern-matching across a record no person could read in a day. You cannot delegate the accountability for what the program does next. Every piece below is, in some form, an argument about where that line sits and what happens when an organisation lets it blur.

The five problems

Accountability — who owns the output
The record — whether the inputs are true
Early warning — signal versus noise
Capability — the skills nobody is practising
Operating — building the thing and keeping it alive

Problem 01

Accountability: someone still signs

This is the foundation, and it's the one organisations get wrong first. When a human drafts a status report, ownership is obvious — their name is on it and they read every line. When an agent drafts it, ownership becomes ambiguous exactly at the moment it matters most. The failure isn't that AI produces bad work; it's that nobody can say afterwards who checked it, what it was based on, or which human's judgment stands behind the number. Governance has to name that person explicitly, because the org chart no longer does it for you — and that obligation doesn't stop at your own badge line.

Problem 02

The record: garbage in, gospel out

Every AI capability a program wants rests on an assumption almost nobody checks first — that the system of record reflects reality. It usually doesn't. The old failure was at least visible: a stale deck looked stale, and an experienced reviewer discounted it on sight. AI removes that signal. It takes a board nobody has groomed and renders it as crisp, confident, executive-ready prose. The data didn't improve; it got laundered. And because the machine's output carries no hedge, the reader loses the oldest tell they had for when something is uncertain.

Problem 03

Early warning: signal, then noise

The most defensible thing AI does on a struggling program is buy time. It reads the entire record and surfaces trouble weeks before a human would — and on a program heading for a cliff, weeks are the whole game. But detection is the cheap half. An early-warning system that flags everything is indistinguishable from silence, because people learn to scroll past. The expensive half is triage: precedence, named owners, required dispositions, and the discipline to retire a rule that keeps crying wolf. What you want to know is never how much the system noticed. It's whether the humans still believe it.

Problem 04

Capability: the reps you stop taking

This is the slowest problem and the one with the longest tail. AI takes the routine work first, and the routine work is precisely where program judgment was built — the tedious reconciliation, the first draft of the risk register, the hundredth status report. Aviation ran this experiment decades ago and the finding was uncomfortable: pilots lost manual proficiency and were the last to know. Meanwhile the tools your team is actually using may not be the ones you approved, which means you can't govern the capability gap because you can't see the usage.

Problem 05

Operating: building it, then keeping it alive

The practical layer. What an AI-augmented PMO actually looks like, which tools do which job, and the two failure modes that kill more initiatives than any technical limitation: the pilot that works beautifully and never reaches production, and the automation that ships and then quietly rots because nobody owns it. Standing up an automation feels like deleting work. It isn't — you've converted visible manual work into invisible standing work that breaks silently. The build is the cheap part. The upkeep is the program.

Where this leaves you

If there's a single thread through all nineteen, it's that AI is an amplifier rather than a fix. It amplifies the discipline of the record, the clarity of your accountability, and the quality of your governance — and it amplifies the absence of those things just as efficiently, at higher speed and with better formatting. Programs that were honest before AI become faster and more honest. Programs that were negotiating yellow into green now do it in polished prose that nobody can argue with.

None of the work that fixes this is glamorous. It's naming owners, defining what "current" means for a field, assigning precedence to alerts, and deciding whose signature goes on the output. That work doesn't demo well and nobody gets promoted for it. It's also the only thing standing between an AI-augmented program and a very well-formatted failure.