Every client is different: different stage, different technology maturity, different organisational culture, different definition of success. But after four companies, dozens of advisory engagements with founders and small to mid-market teams, and production AI systems across insurance, defence, healthcare, and enterprise software, I've developed a thinking structure that works.
This is not a proprietary framework with a trademarked name. It's the distilled approach of someone who has built, shipped, and scaled AI systems, and who knows the difference between what demos well and what works in production.
The three-arc engagement
Every engagement follows three arcs. The length of each varies, but the sequence doesn't.
Diagnostic
Before I build anything, I need to understand what's actually happening, not what the slide deck says is happening.
- Shadow AI audit. What AI tools are people actually using? Where is data flowing? What's sanctioned, what's unsanctioned, and what's the risk exposure?
- Process mapping. Which processes are candidates for AI deployment? Where are the decision points? What's the current error rate, throughput, and cost per unit?
- Data readiness. Is the data infrastructure ready for production AI? Not "do you have data," but can it be accessed, governed, and served to a production system at the reliability level required? (For a specific process, this is the records check in a fixed-fee Process Audit.)
- Team assessment. Does the organisation have the skills to sustain AI systems after I leave? Where are the gaps?
The diagnostic ends with a clear, honest document. Where you are, what's possible, what I'd prioritise. If the answer is "this isn't ready yet," I'll say so. When the goal is agents running one process, this arc is the fixed-fee Process Audit.
Build and deploy
This is where most advisory engagements fail, because most advisors stop at the recommendation. I don't.
- Decision delegation architecture. Precisely which decisions the AI system makes autonomously, which require human review, and where the escalation boundaries sit. Governance built into the system, not bolted on after.
- Tight-scope deployment. One process. One set of KPIs. Full governance from day one. Shadow mode first, then 10% of live volume, then scale as the numbers justify it. The goal is a production system delivering measurable results within weeks, not a pilot that "shows promise" for months. This arc is the Process Build.
- Kill criteria. Before deployment, we define when we'd stop. If the system doesn't hit its KPIs within the agreed timeframe, we kill it and redirect the investment. No sunk-cost persistence.
- Measurement from day one. Defined KPIs tracked from go-live. Not vanity metrics. Cost per case, resolution rate, time-to-close, revenue impact. Numbers that appear on a P&L.
Sustain and scale
A production system is only valuable if it stays in production and the organisation can evolve it without depending on me.
- Knowledge transfer. The team understands the system architecture, the governance framework, and the monitoring approach. They can maintain and extend it.
- Scaling roadmap. With one system in production and measured results, the 90-day action plan identifies the next two or three processes, prioritised by P&L impact.
- Governance evolution. The framework grows with the AI deployment. New systems, new risk categories, new regulatory requirements, all incorporated systematically.
- Agent operations. Always-on agents need looking after: accuracy, exception rates and cost per item monitored, models upgraded, rules refined, and a monthly report of what the agents handled and returned. Your team can own this, or I can through Agent Operations.
Decision delegation architecture
This is the core intellectual framework behind every AI deployment I build. It answers the question most organisations get wrong: what should the AI decide, and what should a human decide?
Most organisations draw this line based on comfort, not analysis. They keep humans in the loop for everything because it feels safer, which means the AI system adds latency without reducing cost, and the productivity gains never materialise.
The decision delegation architecture maps every decision in a process and classifies it into one of three tiers:
Fully automated
The AI decides and acts. Error rate is within acceptable bounds, consequences of errors are manageable, and the volume justifies automation.
AI-recommended, human-approved
The AI proposes, a human confirms. For decisions where the error cost is high but the AI's recommendation quality is strong enough to save significant analysis time.
Human-only
The AI provides context but the human decides. For decisions requiring judgement, empathy, or contextual knowledge the system can't access.
The boundaries between these tiers are defined by data: error rates, cost of errors, volume, and regulatory requirements. Not by instinct. And they evolve as the system improves and the organisation builds confidence.
The six factors that decide success
The three arcs are how an engagement runs. But there is a layer beneath all of it, more foundational than any process, methodology, or SDLC, that decides how far the work can take you. After enough projects I am convinced that technology alone rarely decides the outcome. It is one of six factors, and the other five sit a couple of levels above execution.
People
The calibre of your people, their skills, values, and attitudes, sets the ceiling on what you can achieve. Get the best you can, and get the most from the ones you already have.
Leadership
The force that lets people perform at their best, or quietly stops them. It sets direction, builds the culture, and makes the hard calls. It is the one factor that can turn a sinking business around.
Culture
Real and tangible, not soft. The shared values and norms that tell everyone how to cooperate, take risks, and share ideas. Slow to build, easy to damage, worth protecting fiercely.
Problem-solving
How you make consequential decisions under real uncertainty, and tell the fast, reversible ones from the slow, irreversible ones. It shapes every other choice you make.
Creativity
The human spark behind a genuinely new idea. As AI generates and remixes options endlessly, the scarce skill shifts from producing ideas to discerning which ones matter and framing the right problem.
Technology
What you can actually build and run: the capabilities, skills and hands-on experience in your team, and the tools and stack they work with. The right stack is the one your people wield well, not the most fashionable one. Get it right and it multiplies the other five.
These are not separate levers. They work in concert: strengthen one and the others gain, weaken one and you weaken all. There are no magic bullets, and process fixes only ever treat the symptoms. If that sounds daunting, start with baby steps: improve the factor that looks least daunting, and let the gains compound.
Systems diagnosis. Finding the leverage point
Some problems survive every fix. You hire, and delivery does not speed up. You change vendor, and the new one disappoints in the same way. You launch a new strategy, and six months later nothing is different. When that happens, the problem is not the fix. It is the structure that keeps regenerating the problem.
For those situations I use systems dynamics, the discipline Jay Forrester founded at MIT and Donella Meadows made practical. It maps what accumulates in an organisation (capability, trust and knowledge, not just budget and headcount), the feedback loops that build or drain it, and the recurring traps those loops form. Then it asks where to intervene. Meadows ranked the places to intervene in a system from shallow to deep. Budgets, headcount and targets sit at the shallow end: easy to change, and easily absorbed without any change in behaviour. Information flows, rules and goals sit at the deep end, and that is where a small change moves the whole system.
Three traps I meet most often in business:
Shifting the Burden. An AI pilot never reaches production because a vendor or a tool is standing in for a capability the organisation never built. Each quick fix works just well enough to remove the pressure to build the real thing, and the dependence grows. The way out is to keep the short-term help while deliberately building the skills, data and ownership it was substituting for. It is also why a failed pilot is usually recoverable.
Drift to Low Performance. Delivery standards erode a little each quarter, because the target is quietly reset to whatever was last achieved. Nobody decides to lower the bar. It just moves. The way out is to anchor the standard to your best performance or an external benchmark, not your most recent one.
Seeking the Wrong Goal. AI adoption is measured by activity: licences issued, prompts sent, use cases launched, share of code written by AI. The organisation dutifully optimises the metric and the P&L does not move. The way out is to make the goal the outcome you actually want, cost per case, resolution rate, time to close, and measure that.
Recognising the trap matters more than analysing any single incident, because it rules out whole classes of fixes that look sensible and cannot work. The full method is set out at bluenhs.org/methodology, and each trap, with its signature and its way out, at bluenhs.org/traps.
Building in the agentic era
The way software gets built has changed faster in the last year than in the previous ten. By mid-2026, agentic coding tools, Claude Code, OpenAI's Codex, Cursor, GitHub's coding agent, are mainstream. Weekly AI use among engineers is now close to universal, many teams hand real work to autonomous agents, and most run several tools at once. I build with these every day. But the hype obscures what actually matters, so here is the honest read I bring to client work.
The bottleneck moved, from typing to deciding and verifying. Generation is cheap now. The scarce, valuable work is defining intent, setting boundaries, reviewing, and proving the system did what you wanted, not just what you literally asked for. The engineer's job is shifting from author to orchestrator and reviewer.
Writing the code
Defining intent, setting boundaries, reviewing output
Did it do what I said?
Did it do what I actually wanted?
Human effort in story points
Spec complexity, with agents as parallel workstreams
Sprints measured in weeks
Cycles in hours, on governed rails
The new lifecycle models are variations on one theme. AI-DLC, spec-driven development, and "agentic delivery" all front-load structured intent and wrap non-deterministic agents in governance. The useful part, writing a clear specification before you let an agent run, is real, and I use it. The overreach, treating the spec as the only artefact a human ever touches, is unproven and looks a lot like waterfall in a new coat. I stay on the proven side of that line.
The heavy process becomes the bottleneck. When working software can appear in minutes, two-week sprints, effort-based estimation, and a calendar full of ceremonies are slower than the engineering they are meant to coordinate. So I strip back to the adaptive core of agile and run delivery a particular way: the people who make the decisions in the same room every day, sharing context and deciding on the spot, so the team behaves like one fast, cross-functional organism rather than a relay of handoffs. Delivery is daily. The longest planning horizon is a week. We course-correct every day, on the foundations the section above demands, not instead of them.
Speed exposes weakness. The most credible evidence, Google's DORA research, is blunt: AI lifts delivery throughput but damages stability unless you already have strong testing, version control, and platform quality. AI amplifies what is already there. A team on weak foundations simply ships its mistakes faster. This is why the control layer, scoped permissions, evaluations, audit trail, and rollback, comes first. It is the decision delegation architecture above, applied to coding agents. And agents need bounded ownership for the same reason a stream-aligned team does: point one across fuzzy boundaries and it will blur them further.
Smaller and faster, with one honest caveat. Work that needed a specialist team in 2023 can often be done by a small, AI-augmented team in 2026, and that leverage is real. But the caveat, from Gartner, matters: most organisations cutting headcount on the strength of AI are not yet seeing the return. "Agentic era" is too often cover for a layoff. Smaller and faster only pays when the foundations are in place.
And that is the thread back to everything above. The faster the mechanical work is automated, the more the outcome is decided by the human factors: judgement, the right problem, the right people, and the leadership to point them well. The tools will keep changing every few months. The layer underneath does not, and that is the layer I help clients get right.
What this is not
- It's not a template. Two clients with the same industry and similar size will get different approaches, because their data maturity, team capability, and strategic priorities are different.
- It's not a maturity model. I'm not going to assess you against a 5-level framework and sell you a roadmap to level 5. I'm going to build something that works and measure whether it delivers.
- It's not detached consulting. It's implementation. I work alongside your team, in your systems, with your data. The deliverable is a working system, not a recommendation to build one.
If you want to see how this would apply to your situation, let's talk. A 30-minute conversation is usually enough to tell whether there's a fit and what the first 90 days would look like.