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 the AI-native version 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. The ways-of-working core of Tenhaw's own model is published in full as The Tenhaw Way, free to adopt without hiring anyone.

The deliverable is the same category of thing: structure, roles, decision rights, governance and a sequenced plan to move to them. Tenhaw fields a two-person Agentic Design Team, an operating-model lead and an agentic architect, both senior and both working inside the client's teams rather than briefing them. Three differences follow. It is designed around agents doing a share of the work rather than retrofitted to that fact. The architecture is designed alongside it by that same pair, because a target model the platform cannot support is a document rather than a design. And the ways of working underneath it, The Tenhaw Way, are published in full rather than proprietary, so you can read the whole thing before paying anyone.

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. Tenhaw proved that on a London specialty insurance engagement, where a proof of concept moved PDFs into business intelligence on Azure in two weeks, ground the business had circled for roughly a year, without a reporting line moving. 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.

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.

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.

Roles get defined by the decisions they own, accountability for agent decisions maps onto named people, and one output is the specification for the Head of AI you eventually hire. The target operating model Tenhaw's founder co-designed at HSBC standardised exactly that, roles, governance and reporting, was piloted with select teams, and is due for rollout to 500 teams in 2026. What Tenhaw does 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.

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 Tenhaw is a fine outcome.

Two failures do most of the damage, and neither is the quality of the thinking. The first is a model designed apart from the technical architecture, specifying ways of working the platform cannot support. The second is work that ends at handover: a comprehensive model, a roadmap and change materials, delivered before anyone has worked a day the new way. An AI-native design adds a third, a boundary between what agents decide and what humans decide that nobody wrote down, so every team sets its own in the prompt. Tenhaw designs the model and the platform as one piece of work; the target model it co-designed for 500 teams at HSBC was piloted before rollout, which is due in 2026 rather than done.

No, it amplifies it. 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 from a strategic focus on the underlying organisational system rather than from the tools themselves. The operating model is that system. Bolting agents onto a structure designed for a world where a person did all the building produces licences in daily use and a lifecycle that has not changed, which is why the redesign work on decision rights, delivery modes, gates and cadence has to happen for the investment to pay.

Treat it as a change of habits rather than a licence rollout. The habits transfer by pairing on a real build: on a live Tenhaw insurance engagement the client engineer who paired through a two-week build finished it 70% confident of running the process unaided, which is the number a transition should be judged on. The delivery mode is a standing choice per team rather than a per-ticket preference, so the move starts by deciding that one team now works AI-native and changing what a ticket looks like: an outcome ticket written whole, with the developer directing and verifying rather than authoring. Adoption then gets a named owner and is measured monthly as behaviour rather than as licences activated.

One model, not two. An AI target operating model specifies the same things a standard one does (structure, roles, decision rights, governance and ways of working) for an organisation where agents perform a meaningful share of the work, so it replaces the model you have rather than running beside it. Whether a given team works AI-augmented or AI-native is a standing choice inside that single model, and most organisations Tenhaw works with run both across different teams. A separate model for the AI teams recreates the problem the exercise exists to solve, which is every rollout being renegotiated team by team.

No, and a redesign that stops at the org chart is the version that changes nothing. Structure is one component. The ones that decide whether anything actually moves are decision rights and ways of working, which is why roles get defined by the decisions they own rather than by where they sit in a hierarchy. In an AI-native design that includes the boundary between what agents decide and what humans decide, written down per role, with accountability for agent decisions mapped onto real people with real authority before deployment. Redraw the boxes without any of that and you get new reporting lines and the same throughput.

Fewer people than a classic transformation, and more senior. The essential three are an executive with the authority to change how product and engineering actually work, since decision rights nobody senior enforces are only suggestions; your risk function, co-authoring the boundary between what agents decide and what humans decide rather than reviewing it after it is drawn; and a named owner for adoption, measured monthly on whether people work the new way. Your people function sits alongside them, because workforce consultation and redeployment stay with you. From Tenhaw's side it is a pair, an operating-model lead and an agentic architect working as one, with James Rooney leading every engagement personally.

Three symptoms point at the model rather than the tooling. The pilot worked, everyone agreed it worked, and nothing about how the organisation runs changed afterwards. Boards are full and ceremonies run on time, and the business still cannot say what the quarter produced. Licences are in daily use and the delivery lifecycle is identical to the one you had before anyone bought them. None of those is fixed by a newer model or another tool, because what blocks you is roles, decision rights and governance nobody has redefined. Tenhaw's delivery-transformation work at Globelynx cut lead time by 60% inside six months, and that came from changing how the work ran rather than from buying anything new.

The parts that matter are not tied to any particular model release. Decision rights, accountability, approval gates, cadence and how value is priced outlive vendors, and the human-agent boundary is drawn by consequence and reversibility rather than by what this quarter's model happens to be good at: high-volume, observable, cheaply reversible decisions move to agents, and consequential or contested ones stay with named people. A good design also says which decisions can move as capability improves, so the boundary shifts by decision rather than by another redesign. What does date quickly is a model written around one vendor's current product features.

No. The gates matter more once a model can produce a plausible-looking result in minutes, because plausible is exactly what a thin review waves through. Concretely, an epic cannot leave ready-for-dev without both product and engineering approving it, the roadmap stays exactly one quarter and opens with tech debt and bug budget epics so neither can hide, and retrospectives, health checks and outcome validation keep a fixed cadence with a named role owning each. What gets lighter is authorship, not governance. The speed comes from the model doing the building, and the discipline around it is what makes that speed safe to accept.

By what people do and what ships, not by seats activated. Adoption carries a named owner, and the monthly report is behaviour set against what actually reached production, which is a harder number to flatter than a licence count. Underneath it the model checks itself: every outcome carries a currency target and every epic its planned share, so a quarter whose epics do not cover the target is visible before it starts rather than after it ends. Outcome validation then asks, on a fixed cadence, whether shipped work delivered the value it promised. The failure it catches is tools in daily use and a lifecycle nobody changed. Tenhaw's own rule is that a month delivering no measurable value is a failed month.