AI Business Engineering: A Working Definition

The work I do does not have a name yet.

I sit in the C-suite of an SME mid-market business — usually $5M to $50M revenue, usually founder-run or family-owned, usually 10 to 20 years old, usually with everything aged together. Strategy. Leadership. Operations. The working software. All need a reset at the same time. I run the reset end to end, alongside the leadership team. Operator in the room, not consultant in the deck. I write the thinking, I build the tooling, and I hold the operating tempo with the leadership team for as long as the engagement runs.

When I tell people what I do, the labels miss. AI consultant is wrong — I do not explain AI for a living. Transformation advisor is wrong — I do not write the strategy and outsource the build. Fractional CTO is too narrow — strategy and leadership are half the work. Operating partner is closer but assumes a fund. Founder-builder describes my history, not what I do for clients.

So I started using a working term: AI Business Engineering. Here's what I mean by it.

A working definition, in three claims

Claim one — it is engineering the business, not the AI

Most of what gets called AI engineering in 2026 is engineering AI models, AI products, AI features. That work is real but it is downstream. The bottleneck for an SME mid-market business is not which model to fine-tune. The bottleneck is upstream: what is the business actually trying to do, and is the leadership team aligned enough to ship it?

AI Business Engineering is the discipline of using AI to compress the upstream work. The output is sharper positions, deeper alignment, and execution that is hyper-focused on outcomes the team can name on a single page. The AI is the iteration accelerant. The business is the artifact under construction. If I had to put it in a sentence: I use AI to engineer business clarity, then let clarity drive everything else.

Claim two — it is a discipline, not a toolkit

A toolkit is a stack. Claude here, Cursor there, a Notion database, a Zapier workflow. A toolkit is replaceable. Next quarter's model changes the stack. A discipline is the operating principles that hold no matter which model is in fashion.

The principles I run on are not new. They come from the framework I wrote into Resolute over more than a decade — the Resolute Leadership Curve, the six stages of growth, the twelve questions, the Transformation Iceberg. What is new is the tempo. The frameworks did not need rewriting for the AI era. They needed an operator willing to run a clarity loop weekly instead of quarterly — and AI to take the synthesis cost low enough to make that cadence sane.

Stuart Leo

The frameworks did not need rewriting for the AI era. They needed an operator willing to run a clarity loop weekly instead of quarterly — and AI to take the synthesis cost low enough to make that cadence sane.

Claim three — it sits in the operator seat, not the CTO seat

AI Business Engineering belongs to the person at the head of the table — the founder, the CEO, the operating partner — not the head of engineering. The CTO seat is critical and adjacent. It is not where this work lives.

This work lives wherever positioning, leadership, operating model, and the working software all touch the same decision. That is the C-suite. In an SME of 50 to 500 people, that table is small enough to fit one operator who can hold all four threads at once. That is the role I run.

Why Resolute is the substrate

Frameworks fail in the AI era for two reasons. Too brittle — designed for a tempo synthesis can no longer support. Or too vague — designed to hold any business loosely, holding none precisely.

Resolute is neither. It was written for SME mid-market operators specifically, and it was written as a sensemaking tool — not as a process. From the book itself: the Leadership Curve provides elevated perspective to understand organizational position and determine the best path forward. That is the function I lean on most. The curve gives me a stage hypothesis for the business in front of me. The six stages of growth name what each stage's real bottleneck is. The Transformation Iceberg names the depth at which a change actually has to land — behaviour, skill, belief, value, character — so that the work does not stay shallow. The twelve questions give me a structure I can run a clarity loop against — seven of leadership for tomorrow, five of management for today.

What the book does not say — because it predates the wave — is what changes when AI is in the loop. That is what this series does. The frameworks hold. The loops compress.

Why the discipline is unfilled

The market today has three lanes that look adjacent to AI Business Engineering, and none of them sit where the work actually is.

The AI explainer lane — Ethan Mollick, Azeem Azhar, Allie Miller. Excellent at explaining the wave. They do not run engagements and they do not ship the AI inside companies. They are upstream of the work.

The transformation advisor lane — Aaron Dignan, Frédéric Laloux, Gabe Cutler. Excellent at designing organisations and leadership systems. They outsource the technical layer because that is not their craft.

The builder-operator lane — Tobi Lütke, Simon Willison, Andrew Chen. Excellent at shipping AI at hyperscale. They are not in the SME C-suite engagement zone — the altitude is wrong.

The triangle in the middle is empty. It is empty because the requirements compose multiplicatively. The work needs an operator who has earned the right to sit in the SME C-suite, who has the engineering chops to ship the working software, and who has run leadership and strategy long enough to have a framework worth running. Most operators have one of those. A few have two. The intersection is rare.

Saying AI Business Engineering out loud is a way of staking that intersection. It is also a way of recognising the work that is already happening inside companies, by operators like me, that the existing labels keep missing.

What it looks like in practice

A working example. A services firm I worked with had one revenue channel under compression — government funding — and a leadership team aligned on the existing model, not the next one. A traditional engagement would diagnose for six weeks, write a strategy deck, hand it over, and bill quarterly through the implementation. That is not the work I did with them.

The leadership team kept its quarterly rhythm. What changed was the work between the quarterlies. The CEO and I ran a weekly clarity loop — every week, a working session focused on whichever position the next quarterly needed to land. Before each loop, I used AI to compress the prep. Synthesising market data, modelling EBITDA scenarios under three different revenue architectures, drafting the position paper for the CEO to react to. This was as the AI wave was building — early enough that the tooling was rough, already inside the loop. By the time the leadership team met, the position was three or four cycles tighter than it would have been. Six weeks in, the CEO took a new revenue architecture to the team — three diversified commercial streams. Eighteen months later, revenue had doubled. EBITDA up more than 10%.

The AI did not make the decision. The CEO and the leadership team made the decision. What AI did was take the synthesis cost low enough that the CEO could think weekly. Week over week, that clarity compounded. The quarterly meetings produced different decisions because of it.

That is what AI Business Engineering looks like in the work. Not a feature. Not a deck. A different operating tempo, applied to the upstream clarity that everything else depends on.

What this series does next

Eight pieces. Next: The Clarity Loop: Speed of Thought Beats Speed of Code — the mechanism. After that: The Resolute Leadership Curve, Re-Read for the AI Era — the framework end to end. From there: a single-stage deep dive on the most common SME stuck-point (Calibrate), the operating tempo argument, a counter-positioning piece on what alignment actually means, a piece on the leadership character that holds when the tooling changes weekly, and the closing argument on what outcome-based execution means when you mean it.

The series doubles as the spine for Commander in Brief. Audio is the primary cut — the article is the durable, search-indexed version. The frameworks come from Resolute. The lens is mine. The work is what I do for a living.

---

If a piece of this maps to a problem you are sitting with, the work itself happens in conversation. Start a conversation. For the longer ladder — engagement model, receipts, the books — the rest of the site is the map.