Target operating model for an AI-native organisation

What changes in structure, roles and decision rights once agents do a share of the work.

A target operating model for an AI-native organisation specifies everything a standard TOM does (structure, roles, governance, ways of working) for an organisation in which AI agents perform a meaningful share of the work: which decisions move to agents and which stay human, who is accountable when an agent gets something wrong, how work is priced, gated and verified, and which teams run AI-augmented versus AI-native. Tenhaw publishes the ways-of-working core of its own model in full as The Tenhaw Way and runs it on every engagement, so this guide starts from a working model rather than a framework slide.

Theme
Whole programmes
Read time
6 minutes
Questions answered
7 in full
Updated
Evidence basisDelivered, with the limit stated
Usually engaged as
Agentic Design Team. 2–4 months, £35k–£55k / month.
see the engagement →
Evidence basis

We have done this, and here is exactly how far that goes.

The ways-of-working half of this is delivered and published: The Tenhaw Way is the operating model behind every Tenhaw engagement, including its AI-native delivery mode, and the seventeen how-to guides underneath it are free to adopt. The operating-model discipline has run at 500-team scope: a target operating model co-designed, piloted and proved at HSBC, with global rollout due in 2026 and not yet rolled out, and that work was not an AI programme. The delivered evidence is a product and delivery operating model rather than an enterprise-wide one, and what we cannot show you yet is one organisation taken end to end from a traditional operating model to an AI-native one at scale; on our current insurance engagement we contributed to the operating-model workshops and produced their structured outputs, alongside a working proof of concept, and that is the honest state of the evidence.

On this page

The demand signal

The 2025 DORA report on AI-assisted software development concluded that AI's primary role is as an amplifier, magnifying an organisation's existing strengths and weaknesses, and that the greatest returns on AI investment come not from the tools themselves but from a strategic focus on the underlying organisational system. That is a research finding pointing directly at the organisational system, which is what an operating model specifies. It also matches the buying vocabulary. The phrase organisations use for this work is target operating model: the deliverable transformation practices have sold for decades, now carrying a question none of the old decks answer, which is what changes when a share of the work is done by agents.

Why it stalls

4 failure modes we keep meeting

The pilot worked and the organisation did not change

Scaling an agent from one workflow to fifty is almost never blocked by model capability. It is blocked because scaling requires redefining roles, moving decision rights and rewriting governance across functions the pilot team has no authority over, so every rollout becomes a fresh negotiation. A target operating model is what makes the fifty-first rollout cheap: roles, governance, reporting and value metrics defined once rather than renegotiated team by team, a discipline proved at HSBC on a delivery programme rather than an AI one.

The operating model still assumes a person does all the building

Boards are full, ceremonies run on time, and the business still cannot answer what the quarter produced. The effort is not the problem. The operating model underneath was designed for a world where a person did all of the building, before a model could do research, scaffold code, write tests and critique designs on demand. Bolting agents onto that structure produces licences in daily use and a lifecycle that has not changed.

Decision rights are nowhere written down

An organisation deploying agents without an explicit boundary between what agents decide and what humans decide has still made the decision, implicitly, per team, in the prompt. Nobody can answer who is accountable when an agent gets something wrong, which is the first question a risk function or a regulator asks, and 'the agent decided' is not a defence either of them accepts.

The target model arrives as a document

The classic TOM engagement produces a comprehensive model, an implementation roadmap and change materials, and departs before implementation. Designed apart from the technical architecture, the model asks for things the platform cannot support, and a target model the platform cannot support is a document rather than a design. The other half of the failure is adoption: nobody owns whether people actually work the new way, and a model nobody works is a slide.

How we approach it

7 moves, in order

  1. 01

    Start from a published model, not a blank page

    The Tenhaw Way is published in full: four values enforced as operating decisions, a work breakdown where nothing exists that does not trace to a priced business outcome, two delivery modes, hard approval gates and seven rituals on a fixed cadence. Designing your target operating model starts by adapting a model that is written down and argued for, which is faster to adopt and cheaper to disagree with than a framework invented on your budget.

  2. 02

    Price every outcome in currency

    If value is not priced, technology is a cost centre. Every outcome carries a currency target, every epic carries its planned share, and when the epics do not cover the target the gap is visible before the quarter starts rather than after it ends. This is the discipline that lets an AI programme answer what the quarter produced, and it comes first because every later decision in the model hangs off it.

  3. 03

    Make AI-augmented versus AI-native a structural decision

    The central organisational choice is per team. AI-augmented, where developers build and AI assists, keeps the full four-level breakdown of outcomes, epics, stories and chapters. AI-native, where the model does the building and the developer directs and verifies it, stops at the epic: an outcome ticket written whole, carrying the outcome, its currency share, the key user journeys and the test requirements, because splitting it below that loses more than it gains. The mode is a standing choice per team rather than a per-ticket preference, the two require different habits, and most organisations we work with run both across different teams. Our view is that augmented is the stepping stone and AI-native is where most product teams end up.

  4. 04

    Draw the human-agent boundary by consequence and reversibility

    Agents take decisions that are high-volume, observable and cheaply reversible. Humans retain decisions that are consequential, contested or hard to undo. The boundary is written down explicitly per role, the escalation path across it is part of the governance framework, and accountability for agent decisions maps onto real people with real authority before a single agent is deployed. This is the section of the model your risk function co-authors rather than reviews afterwards.

  5. 05

    Keep the gates, the timebox and the cadence

    An AI-native organisation still runs on delivery discipline. Epics cannot leave ready-for-dev without product and engineering approval; the roadmap is exactly one quarter and opens with tech debt and bug budget epics so neither can hide; retrospectives, health checks and outcome validation run on a fixed cadence, each owned by a named role. And done means the test requirements pass and the named user journeys are demonstrated working, because a model reporting that it has finished is not evidence that it has.

  6. 06

    Design the architecture alongside the model

    The operating-model lead and the agentic architect work as one pair, deliberately, because an architecture designed without knowing which decisions move to agents optimises for the wrong things, and a model the platform cannot support never leaves the slide. The output is one design: the model, the platform it runs on, and the sequenced build plan to reach both.

  7. 07

    Move teams across deliberately, and measure adoption as behaviour

    Moving a team from AI-augmented to AI-native is deliberate work on how it writes, reviews and verifies, not a switch anyone flips. Adoption is owned explicitly, measured monthly as behaviour rather than as licences activated, and reported alongside what reached production. On our live insurance engagement the client engineer who paired through a two-week build finished it 70% confident of running the process unaided, and that number, honestly asked for, is the adoption measure a transformation should be judged on.

Humans retain decisions that are consequential, contested or hard to undo.
Ask a technical questionanswers from all 13 guides
Ask anything technical about target operating model for an AI-native organisation and I will answer from this guide, and tell you first whether this is work we have delivered or an approach we would be taking.

Prefer to talk it through? Ask us on a discovery call →

Questions this guide answers

What is a target operating model for an AI-native organisation?

Everything a standard target operating model specifies (structure, roles, governance, ways of working), designed for an organisation in which AI agents perform a meaningful share of the work. Concretely it adds four things: an explicit boundary between what agents decide and what humans decide, drawn by consequence and reversibility; accountability for agent decisions mapped onto named humans before deployment; a per-team delivery mode choice between AI-augmented and AI-native; and a definition of done in which passing test requirements and demonstrated user journeys count and a model's own report of being finished does not.

How is this different from a Big Four target operating model?

The deliverable is the same category of thing: structure, roles, decision rights, governance and a sequenced plan to move to them. Three differences. It is designed around agents doing a share of the work rather than retrofitted to that fact. The technical architecture is designed alongside it by the same pair, because a target model the platform cannot support is a document rather than a design. And the ways of working underneath it are published in full rather than proprietary, so you can read the whole thing before paying anyone.

Do we restructure before deploying agents, or after?

Neither, in that order: pilot first, design before you scale. A pilot needs no restructure, and restructuring around a capability you have not proved is how transformations produce org charts instead of outcomes. What fails is scaling on the pilot's structure: fifty teams with fifty definitions of done and no shared decision rights, where every rollout is a fresh negotiation. The design work belongs between the proof and the rollout, which is exactly the point where most programmes skip it.

What actually changes for a team in an AI-native operating model?

The ticket, mostly. In an AI-augmented team a developer builds and AI assists, so work still breaks down into stories and chapters. In an AI-native team the unit of work is an outcome ticket written at epic level: the outcome, its share of the currency target, the key user journeys and the test requirements, handed over whole to a model or to a developer who runs it into one and iterates until the outcome is met. The gates and the cadence stay for both modes; what changes is that done becomes the tests passing and the journeys demonstrated rather than a human having authored the code.

Who is accountable when an agent gets something wrong?

A named human, and the operating model has to say which one before the agent is deployed. The model specifies what agents own, what humans own, how agent decisions are audited and the escalation path across the boundary, with accountability mapped onto real people with real authority. 'The agent decided' is not a defence a regulator accepts, and an operating model that cannot produce the accountable name on request is not finished.

What about the people side: roles, spans and layers, workforce transition?

The model defines roles by the decisions they own, maps accountability for agent decisions onto named people, and one of its outputs is the specification for the Head of AI you eventually hire. At HSBC the target operating model we co-designed standardised roles, governance and reporting, was piloted with select teams, and is due for rollout to 500 teams in 2026. What we do not hold is HR execution: workforce consultation, redeployment and the employment decisions that follow a redesign stay with you and your people function, and a supplier who claims to own those is claiming accountabilities that are yours.

How long does target operating model design take, and what does it cost?

As a Tenhaw engagement, two to four months at £35,000 to £55,000 a month for a pair: an operating-model lead holding the interim Head of AI seat and an agentic architect, ending on the target operating model, the architecture, the governance framework and a sequenced build plan your own teams can execute. Doing it yourself is free: The Tenhaw Way and the how-to guides underneath it are published in full, and adopting them without hiring us is a fine outcome.

engage via

Talk to us about target operating model for an AI-native organisation.

A 30-minute call with James Rooney. We'll tell you honestly which parts of this we have done before and which we would be doing for the first time, and you'll leave with a rough scope either way.

most start with a fixed-price Agent-Readiness Audit · £30k–£90k · 6–8 weeks

// pick a slot · cal.com/tenhaw/professional-servicesLIVE CALENDAR

Calendar not loading? Open it on cal.com or email hello@tenhaw.com.