AI-Native Services

AI-Native Service Architecture

The square, the barbell, the flywheel and the membrane — how to sell a fixed commitment around a generative machine, and make each engagement pay for the next.

Freeze what the customer buys. Leave the method generative. Prove the promise at hard edges. Compound between engagements — without pooling client truth.

Every service you have ever sold had a shape. Nobody drew it.

Ask someone to sketch the shape of a consulting engagement and you will get something with many edges and many curves. It bulges where a source system turned out to be undocumented. It stretches sideways where a stakeholder changed their mind. It grows a lump where somebody had to investigate an edge case for three days. It is an amorphous shape — many edges, many curves — and it is difficult to explain, which is precisely why so much of a professional-services firm's payroll is spent explaining it.

        ______
     __/      \____
 ___/              \__
/                     \____
       project

Time-and-materials contracting is not a billing convention. It is a decision about who owns that shape. It says, roughly: we don't know exactly what reality will require, so you buy access to our people while we discover it. A messy source means more days. A change in requirements means more days. A misunderstanding means more days. Behind those days sit project managers, resource plans, burn rates, timesheets, change requests, and arguments about whether a newly discovered piece of reality was ever in scope.

The customer effectively owns a significant portion of the supplier's production variance.

Everyone has been paying for that arrangement, and there is data on how well it works. PMI's 2018 Pulse of the Profession found that 52 per cent of projects completed in the previous twelve months experienced scope creep or uncontrolled changes to scope — up from 43 per cent five years earlier¹. The trend went the wrong way during exactly the period the industry was getting better at project management.

The obvious response — quote a fixed price and stop arguing — has its own long, documented casualty list. Mature contracting practice is blunt about it. In lump-sum turnkey construction, the contractor takes the cost and performance risk, "although in practice, owners may still face additional costs through change orders and significant disputes can arise… In truth, there is no such thing as an absolute fixed price contract."² Contractors respond by pricing in "significant contingencies", and where those contingencies prove insufficient they are "naturally incentivized to seek opportunities to reopen the fixed price."²

So the industry has two answers and both are bad. Bravado: quote fixed and eat the variance. Padding: quote fixed at triple and price yourself out of the deal while still carrying tail risk. Neither is an architecture. Both are the same shapeless project with a different number on the front.

Why no contract can enumerate the middle

There is a reason this failure is stubborn, and it predates AI by forty years. The incomplete-contracts literature — Grossman, Hart and Moore, whose work earned Hart and Bengt Holmström the 2016 Nobel — starts from the observation that "contracts cannot specify what is to be done in every possible contingency. At the time of contracting, future contingencies may not even be describable."³

Hart frames the resulting trade-off precisely: "The benefit of a rigid contract is that it fixes expectations, avoiding arguments. But it may not perform well when there is uncertainty. A flexible contract can adjust to the state of nature, but there is also room for arguments."⁴

Read that again, because the whole architecture is a refusal of the choice it offers. Rigid or flexible is only a dilemma if the contract is one undifferentiated thing. It stops being a dilemma the moment you notice that expectations and uncertainty do not live in the same place. Expectations live at the boundary — what is promised, what is delivered, what counts as done. Uncertainty lives in the middle — how many documents, how messy, how many attempts, which approach. Put rigidity where expectations live and flexibility where uncertainty lives, and you have a topology instead of a compromise.

That was never economically available before, because the middle was made of expensive human hours. Absorbing an extra thirty hours of thinking work meant absorbing thirty billable hours. It is available now because the price of cognition collapsed: querying a model at GPT-3.5-level performance on MMLU fell from $20.00 per million tokens in November 2022 to $0.07 by October 2024 — a more than 280-fold reduction in roughly eighteen months⁵. That is the whole premise, and it earns exactly one paragraph here.

The architecture: four structures, one system

Square around the engagement. Barbell inside the square. Flywheel between the squares. Membrane around the learning.

Those four are not four metaphors for the same thing, and they are not four best practices you can adopt in whatever order suits your quarter. They are four views of one service at different scales, and each one exists because a specific thing collapses without it.

Four different failures means four different structures. This is the deletion test, and it is the honest way to check whether a composition claim is real: take each piece out on paper and say what specifically breaks. If a piece can be removed without breaking the other three, it was decoration.

The perimeter is productised. The interior is generative.

What the square actually contains

The outside is deliberately rigid: promise · price or unit · time boundary · authoritative inputs · terminal states · exclusions · acceptance tests · authority. The inside is deliberately fluid: search · decomposition · generation · retries · parallelisation · tool choice · code generation · research · testing · regeneration · internal replanning. Then the exit boundary becomes rigid again: evidence · acceptance · human disposition · delivered state.

Tight promise. Loose production. Hard acceptance. It is the commercial sibling of the delivery rule we already run on — tight intent, loose method, hard verification — and the family resemblance is not an accident. It is the same insight applied one layer up.

Fixed price is a consequence, not the essence

This is the point at which most readers hear "fixed-price consulting" and either get excited or get frightened. Both reactions miss it. The invariant is not the fee shape; it is a stable unit of commitment. That could be a fixed-price decision product, a per-project activation, a verified decision, an annual continuity subscription, an assessed estate, an enrolled fleet, a protected period, a guaranteed response commitment or a capacity tier. What it increasingly must not be is "however many hours our internal process happens to consume."

Fixed price matters because it is unusually strong evidence that a supplier has made its own complexity legible enough to take responsibility for it. That makes it a signal, not a religion.

Change requests become boundary mutations

Once the perimeter is real, the most useful thing it does is reclassify surprise. In conventional delivery, almost any newly discovered complexity can become a change request. Under this topology, ordinary production complexity must not.

If I promise to analyse your estate and one part turns out to need twenty agent-hours rather than two, that is my problem; the square absorbs it. If an integration needs three regeneration attempts rather than one, my problem. If the first architecture fails its test and the system generates another, my problem. Those are interior variations.

A commercial event occurs only when something crosses the perimeter: the buyer changes the promised outcome; the input estate crosses the agreed volume band; a new source class appears; the required authority changes; a physical constraint changes; a regulatory obligation lands; the deadline moves. Those are boundary mutations, and they reopen the commercial conversation with evidence rather than with a grievance. (The detailed contract test for boundary changes — typed reserves, exhaustion rules, the mutation matrix — is a separate piece of work; the point here is only that the two categories are different in kind.)

Topology is not cadence

One distinction has to be made explicitly or the whole thing gets misfiled. "Waterfall per increment" — specify, generate, independently verify inside each slice; deploy, observe, learn between slices — describes a production cadence. The square describes a commercial topology. They coexist happily. They are not the same layer, and conflating them wrecks both.

A firm that hears "fixed outside" and freezes its production cadence into a twelve-month requirements phase has misread the architecture completely. A firm that hears "short increments" and concludes that its commercial commitment must therefore be open-ended has misread it in the other direction. The interior can iterate as fast as it likes. What it cannot do is renegotiate the promise every time it learns something.

The part of Agile that survives is its deepest epistemic insight: users still don't completely know what they want until they see something. The part that depreciates is the labour-management layer — sprint capacity, story points, velocity, estimation, hand-offs — machinery whose economic premise was that human implementation capacity is the scarce resource you must ration. When generation is cheap, a large wrong system appears as fast as a large right one, and the binding work moves upstream to framing and downstream to verification. That is a cadence consequence. The commercial consequence is different and sits above it.

The barbell: put the expensive attention at the ends

The square explains what is fixed. The barbell explains why that is safe.

Heavy thought before implementation. Cheap implementation in the middle. Heavy verification after. On the left plate: intent, promises, non-goals, alternatives, assumptions and failure cases, acceptance tests, recorded rejections. On the right plate: independent lenses, deterministic checks, adversarial review, evidence coverage, intent regression. In between: latitude.

The customer buys precision of intent and precision of outcome. They do not buy precision of internal procedure.

Traditional statements of work do almost the reverse. They protect the supplier by describing activities — conduct five workshops, interview twelve stakeholders, run analysis, hold weekly status meetings, prepare report. Those are descriptions of the middle: the exact part the buyer should not be buying. AI-native contracting can be comparatively thin there, and thick at the ends:

Two objections arrive immediately, and both deserve a straight answer.

"Our risk committee will never accept latitude in the middle." The barbell is more governed than supervised automation, not less. Supervised automation puts a thin, tired human layer across every unit of output, which is expensive and — as the evidence keeps showing — not especially reliable. The barbell concentrates authority where consequences concentrate. Where a use is genuinely high-risk, this stops being a design preference: EU AI Act Article 14 requires high-risk systems to be designed so that natural persons can effectively oversee them, interpret their output, remain aware of automation bias, and intervene or halt operation — with separate verification by at least two natural persons for certain uses⁶. That is a barbell written into statute.

"But AI is fast, so acceptance can be light." No. In METR's randomised controlled trial, experienced open-source developers working on their own repositories took 19 per cent longer with early-2025 AI tools than without — while forecasting a 24 per cent speed-up beforehand and believing they had been sped up 20 per cent afterwards⁷. It is one setting, 246 tasks, and a snapshot of a fast-moving capability; METR say so themselves. But the gap between felt and measured is the entire reason the right-hand plate exists. If your acceptance evidence is a demo and a good feeling, you have built a machine for generating confident wrongness at scale.

The outcome is not the test

One small distinction does a lot of work here. The outcome is what was sold. The test is the instrument by which you can legitimately say the outcome occurred. If you sell a verified current-state architecture, the architecture is the outcome; the evidence coverage, the reconciliation checks and the human dispositions are the tests that prove it. Collapse the two and "outcome-based" quietly reverts to vague consulting language, because nothing can fail.

The sequence, then, is: promise → falsifier → latitude → evidence → acceptance. And the acceptance test has to be able to fail. If completion resolves to stakeholder satisfaction, the discipline of the whole square evaporates at the last mile.

The flywheel: engagement two is the only proof

Everything so far describes one engagement. The commercial argument only becomes interesting across two.

Organisations have always tried to learn from delivery. Communities of practice, post-implementation reviews, centres of excellence, knowledge bases, lunch-and-learns. It is not true that organisational learning didn't exist. It is true that the joins were economically broken. Somebody had to notice a lesson was reusable, articulate it, abstract it out of client-specific language, document it, classify it, distribute it, persuade a large group to read it, have one of them remember it at exactly the right future moment, and apply it correctly. Every link in that chain was human labour, which is why so much knowledge management became archaeology.

AI changes essentially every link — and the last one structurally. Nobody has to remember to go and read it. The next run loads the substrate.

So the wiki, the eval set, the acceptance harness, the exception taxonomy and the pricing rules stop being the company library and become part of the cost curve of the product. That is a different claim from "we captured some learnings", and it comes with a brutal condition attached:

Suppose engagement one takes two senior people eight weeks and barely breaks even. That is an excellent investment if it leaves behind a working delivery vessel, a set of eval cases, newly typed exception classes, reusable deterministic tools, sharper pricing-band logic, reusable acceptance tests and a better qualification gate. It is a low-margin consulting job if the two seniors simply worked incredibly hard, solved everything by hand, made the client happy and told everyone what they learned over drinks.

Which means engagement two is the only proof. Transfer means ordinary capable staff lead materially more of the second engagement because the first one improved shared infrastructure — not because the same heroes worked late again. If escalation returns at the same density, if exception classes are still tribal, if pricing rules still bend whenever a principal is in the room, you ran a successful project and did not install a practice. And one successful engagement never evidences compounding. It evidences delivery. Say so plainly, and name what the second engagement would have to show: lower recurring novelty, falling scarce-expert density, typed rather than tribal exceptions, and reusable artefacts an ordinary consultant actually loads.

A normal consultancy monetises accumulated expertise repeatedly as labour. An AI-native consultancy converts each paid engagement into infrastructure that reduces the amount of expertise that must be re-spent on the next one.

There is a cultural consequence worth naming. Traditional professional services rewards knowledge concentration: if you are the only person who knows the trick, your utilisation, indispensability and internal status all rise. Under this architecture the highest-status act changes from I solved the hard case to I solved the hard case once and made sure nobody needs me for that class again. That is a different profession, and pretending it will happen by exhortation is how the last twenty years of knowledge management went.

The membrane: three territories and one gate

"We learn from every engagement" is one clause away from "we pool everybody's data", and buyers know it. So the boundary has to be architectural, not reassuring.

There are three territories, and they are not the same:

1. Client truth. Their data, systems, people, decisions, evidence, context. Stays client-bound according to the engagement and the contract.
2. Engagement learning. What happened in this particular delivery — exceptions, failures, decisions, traces, project evidence. Much of this should also remain inside the engagement boundary.
3. Promotable capability. An abstracted pattern that no longer depends on the client's confidential state: when this condition occurs, use this test; this source class needs this adapter; this pricing band underestimates disposition load under these conditions; do not make this architectural promise without this evidence.

Only the third category is even a candidate for wider use — and not automatically. The gate is de-identification, abstraction, transferability, contractual clearance and human approval, in that order, with a named owner. Every candidate ends in exactly one disposition: local-only, configurable, internal primitive, supported platform, or reject. "Maybe later" is not a disposition; it is a deferred decision that needs a revisit trigger. And rejections are preserved, not deleted — they teach the boundary.

This is emphatically not model training on client exhaust. The model-provider bargain is: give us your interaction data and we'll subsidise inference because it improves our future model. The service firm's version should be: we may accept lower early margin because the engagement improves our external organisational learning substrate — wiki, evals, acceptance harness, pricing configuration, delivery code, adapters, tests, pattern ledger, prompts, toolchain. You very often do not need to train anything at all. In fact you probably shouldn't: external learning is inspectable, reversible, attributable, boundary-aware, usable by tomorrow's engagement, and portable across model upgrades. It is soft-weight learning at organisational scale.

This is also not a novel ethical position; it is where professional conduct already sits. Practitioner guidance on ABA Formal Opinion 512 and equivalent state rules treats generative AI as non-lawyer assistance under supervision obligations, and advises that client confidential information only be entered into platforms that contractually commit to zero data retention and zero training on customer inputs⁸. Standard vendor terms now include deletion of customer data, prompts, outputs and derived training data, plus certification of deletion and audit rights⁹. The membrane is what that looks like when you build it into the service instead of bolting it onto the MSA.

Done twice

Put the four structures together and the definition of "done" gets tougher than the industry's current one.

An engagement is not operationally closed until it has answered two questions. Did we keep the customer's promise? And: what, if anything, should the organisation never have to learn again? The first question is what the client bought. The second is what the firm bought. A service architecture that only closes the first one is a delivery method. Closing both is what makes it a business model.

Where the architecture must shrink the promise — or decline

If this reads as "AI makes fixed-price projects easy", it has been read wrong, and the correction is important enough to state as a rule.

AI cheaply absorbs cognitive variance. It does not absorb all variance. The square breaks when the residual uncertainty lives in:

• Physical scarcity. Trucks, stock, field technicians, laboratories, buildings and working capital do not scale with tokens.
• Human authority. A regulated principal, clinician, board member or licensed engineer may still have to make the consequential call, at their own pace.
• Open-ended intent. If the customer keeps changing what success means, there is no stable perimeter to draw.
• External dependency. A third-party vendor taking six months to expose an API is not machine-scale cognition.
• Unbounded liability. You cannot safely fixed-price an obligation whose consequence tail you cannot bound simply because the analysis got cheap. Without a contractual limitation, professional liability is unlimited and can exceed the cover behind it¹⁰.
• True exploratory R&D. Sometimes the paid object really is exploration, because nobody can yet define a testable terminal state.

The inversion: standardise the compiler, not the answer

Here is the part that should change what you do on Monday.

Historically, productising a service meant reducing variance in the customer's answer. Standardise the deliverable so you can predict the labour: templates, packages, bronze/silver/gold tiers that mostly amount to the same work with fewer knobs. Mass customisation — Stan Davis's term, developed by Joseph Pine — got partway out of this by standardising modules and letting combinations vary, producing goods and services "to meet individual customers' needs with near mass production efficiency"¹¹. But the answer still came from a catalogue.

You standardised the path to understanding, not the conclusion. You productised the path, not the answer. And because the machinery improves every time it runs, the same square becomes more profitable and more reliable across successive engagements rather than merely repeatable.

Same square. Different thing inside every time.

The demand side is already moving towards this shape of promise, which is why the design question is urgent rather than theoretical. McKinsey's global managing partner describes the firm "migrating pretty quickly away from… a fee-for-service model" towards "much more of an outcomes-based model where we say, 'Look, let's identify a joint business case together and we will underwrite the outcomes of that business case'"¹². In legal services the same gap is visible from the buyer's side: 71 per cent of clients would prefer to pay a flat fee for their entire case, while hourly billing remains the most common model, offered by 71 per cent of firms¹³. Buyers want a stable unit of commitment. Most suppliers still sell time. The architecture is how you close that gap without gambling.

What to do this week

Take one live offer and run the deletion test on paper. Four questions, half a page each:

1. No square. If we removed the bounded promise and sold access to people instead, what changes? If the answer is "nothing much", you were already selling time and calling it an outcome.
2. No barbell. If nobody froze intent up front and nobody owned a consequential acceptance at the end, who would be inspecting what? Count the review hours you would need. That number is what the barbell buys.
3. No flywheel. Name three things engagement two will start with that engagement one did not have. If you cannot name three, the second engagement will cost what the first one cost.
4. No membrane. Write the sentence you would say to the client's general counsel describing what leaves the engagement and in what form. If you cannot write it calmly, do not promote anything yet.

Then fill the perimeter fields for that offer — promise, authoritative inputs, exclusions, commercial band, time boundary, valid acceptance states — and mark the ones you cannot answer. The blanks are the design work. They are also, usually, exactly where last year's margin went.

Rigid at the promise. Fluid in the machine. Rigid at proof. And closed only when both questions are answered.