AI is a capability to be engineered, not a tool to be adopted
Most of what decides whether AI helps is not the model. It is the work around the model — who holds the intent, what context the system has, where the guardrails live, and whether anyone proved the outcome afterwards.
Who holds what
The useful question is not how much AI can do. It is which parts of the work a human must keep. Get that division wrong and you get output nobody can vouch for; get it right and AI removes most of the cost of finding out whether an idea works.
- The human keepsIntent, framing, and the definition of a good outcome. Judgment on trade-offs. Accountability for what ships — delegation never dissolves it.
- AI can carryInvestigation, reproduction, implementation, and the legwork of checking. Breadth a person does not have time for, at a speed that changes which problems are worth attempting.
This is why framing matters so much. How a problem is stated changes the solution that gets found, and AI will pursue a badly framed problem faster than a person would. The failure modes are specific and recognisable: confident fabrication, a plausible-but-wrong root cause, context quietly lost between steps, success reported without verification, agreement offered in place of judgment. Each one is caught by a different part of the loop below, which is the point of having a loop at all.
In practice this has meant running internal sessions and workshops, then building the orchestration a team actually uses — read-only access to internal systems, automated deployment testing wired into non-production environments and pipeline triggers — so that most of the work can happen through a chat interface without anyone having to be the bottleneck. An organization grows when capability spreads, not when it concentrates in whoever happens to know the system best.
None of this required replacing the systems the team already had, and that matters more than it sounds. Most AI adoption stalls because it arrives as a parallel way of working that competes with the real one. Orchestration is meant to improve the work already happening, on the tools already in use — which is also why the team kept working this way without me in the loop.
Dividing the work between models
Model choice is an engineering decision with a cost curve, not a preference. The arrangement I keep returning to: a stronger model holds the plan and owns the outcome, with smaller models doing scoped work beneath it as subagents. The owning model can then check and correct what comes back. That costs far less than running everything at the top tier, and produces better results than running everything at the bottom — but only because accountability stays in one place rather than being spread across whichever agent happened to touch the task last.
The lesson behind it was not a success. On a map-rendering performance problem I improved things substantially but fell short of what we were aiming for, mostly because I was running it alongside two other pieces of work. Someone else working the same problem, with a different model, got further. The model was not really the variable. Split attention was. AI makes it very easy to have several things in flight and mistake the motion for progress — which is why the human should stay on the primary outcome even when the agents can fan out.
The lifecycle
I wrote this up as an open framework because a way of working that only one person understands does not change how a team operates. Six stages, one principle each.
- OpportunityDefine the problem and the outcome worth pursuing. Start with the opportunity, not the tool.
- UnderstandEstablish the context needed to decide well. Never assume the context is sufficient.
- PlanChoose the focused path, boundaries, and ownership. Parallelize only what is genuinely independent.
- ExecuteDo the work, adapting as evidence changes direction. Delegation never dissolves accountability.
- ProofDemonstrate that the intended outcome actually happened. Prove outcomes, not activity.
- GrowFeed what was learned into the next cycle. Only validated experience becomes expertise.
When Proof fails, the loop returns to Understand rather than Execute. Repeatedly retrying a fix is the most common way AI-assisted work burns effort without moving.
Agentic workflows repeat. Orchestration learns.
Agents can act and workflows can repeat, but neither improves on its own. What makes the difference is that the next cycle starts from more than the last one did. This is an operating model, not a runtime — agent frameworks, workflow engines, and tool protocols sit inside it rather than compete with it.
Saying what the evidence actually is
The framework refuses to let “it worked” stand as a claim. Instead of a score, it asks for a sentence: what was checked, what was observed, and where you stopped. Four questions do the work — is someone asserting it or did someone verify it; does it hold up again; did the thing you cared about actually move; did it hold where it counts.
Stopping early is fine and often correct. Describing weak evidence in language that sounds strong is not. “Verified by a test that fails without the change, not yet seen in production” is a complete claim; “verified” on its own is not.
The same discipline governs how much autonomy AI is given. Widen what it decides where results of that kind have held up; keep human approval wherever a mistake is expensive or hard to reverse; take the scope back when the results stop holding. Per context, not globally.
Where it has been applied
The same instinct runs through the architecture work: put the rules where they hold on their own. A guardrail enforced by a content model or a type contract survives turnover, deadlines, and whoever is reviewing that day. A guardrail enforced by review does not. That matters more, not less, when AI is producing some of the work — a system that constrains what can be expressed is a system AI can be turned loose inside. Read-only access to production data is the same idea applied to blast radius: the safety does not depend on anyone remembering to be careful.
Answers when nobody is left to answer
Most organizations lose knowledge faster than they document it. The people who built a system move on, the mapping was always too large to write down, and what remains is a set of behaviours nobody can explain. Orchestration over read-only access to internal systems turns that from a staffing problem into a retrieval problem.
A production data issue had survived an overnight investigation: new listings were not appearing after repeated loads, the team that built the sync flow had left, and there were thousands of per-organization mappings with no documentation. Backtracking from the customer-visible symptom to the source located a single misconfigured flag between data ingestion and the database. A separate support case — saved favourites showing on desktop but not on mobile, caused by an email-relay service silently creating a second account — had been circulating between teams without a clear owner, and was answered the same way.
Neither answer required the original authors. That is the property worth designing for.
Composable content architecture
The content architecture behind a public website redesign: pages are composed from reusable, independently governed sections instead of hand-built templates, so a new page ships without a code change. 50 published pages across 8 page types run on it, with permitted nesting, layout variants, and required fields enforced by the model rather than by review.
The interesting part is who it moved the work to. A marketing team composes freely and stays inside brand standards because the standards are structural, not advisory.
Enterprise content API migration
A migration estimated at 8–10 weeks of team effort, executed in about a day. GraphQL to REST and .NET 9 MVC to .NET 10 Minimal APIs — roughly 7,800 lines across 200+ files replaced, with every route, JSON shape, and response envelope preserved so no consumer had to change.
That day is the execution. Testing and parity validation took another, and getting agreement to ship took longer than either — the work was not continuous. Writing the code stopped being the expensive part, which moves the bottleneck rather than removing it.
The speed is not the interesting part. An automated parity harness checked the new API byte-for-byte against live traffic across 36 endpoint cases, and both versions ran side by side with the API gateway pointing at the new one, so QA validated the real site and signed off — not just matching JSON. The limiting factor on work like this turns out to be having an objective way to verify it, not headcount.
A memory leak followed to its root cause
Recurring out-of-memory crashes in production were first stabilised with a blunt mitigation. The investigation then continued past the workaround — through load testing, heap snapshots, and production evidence — into React's Server Components renderer.
The root cause reduced to a one-file change, contributed upstream to React so other applications need not carry the same workaround. The mitigation it replaces was validated on the fleet first: the same image under sustained load restarted 113 times without the flag and zero times with it. A workaround resolves an incident; a root cause can resolve a class of them.
Reference implementations
Three patterns written up so other teams can reuse them: cross-team knowledge access, production exception remediation, and multi-repository defect remediation. The first is the one described above and has resolved real incidents. The other two have run on real work through existing review and deployment approvals, but none is an always-on capability or adopted across an organization, and each still depends on a person providing the map and holding the approvals.
Why any of this is written down
A team does not get better because one person got better. The framework is open, documented end to end, and shipped with a quickstart, a one-page working template, worked examples, an analysis of how AI fails at each stage, and field lessons from getting it wrong. It is feedback-driven and still changing as more evidence arrives.