The AI-native target operating model, answered in full.

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.

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.

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.

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.

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.

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.