Target operating model for an AI-native organisation

It describes how your organisation works when AI agents perform a meaningful share of the work: its structure, roles, decision rights, governance and ways of working. It makes clear what an agent may do, what a person must approve, who is accountable and how the result will be checked.

For a product team, that includes choosing how developers use AI, defining approval gates and agreeing the evidence needed before a change ships. The Tenhaw Way publishes the product and delivery core of our model in full, free for you to adopt with your team.

Compare the proposed team, scope, evidence and implementation responsibilities. Big Four services vary by firm and engagement, so the useful comparison is with the proposal you are considering.

Tenhaw's Agentic Design Team is two senior practitioners: an operating-model lead and an agentic architect. They design the roles, decision rights, governance and technical architecture together with your people, and produce a sequenced build plan. The service covers design; implementation needs its own delivery plan and resources. You can read and try the published ways of working, The Tenhaw Way, before deciding whether to engage us.

Test a useful workflow before committing to a broad restructure. Establish the permissions, approval responsibilities and safeguards needed for that pilot, then use what your team learns to design the wider changes before scaling.

A pilot might show that an agent can prepare a reliable first draft, while reviewers still need better access to supporting records. That points to a specific change in work and responsibilities. Map those changes with the people involved, check what the architecture can support and decide which roles or reporting lines, if any, need to change.

The team changes how it specifies, builds and verifies work. In AI-augmented mode, developers write code with AI assistance and work from stories, adding chapters only when a story needs smaller pieces during the build.

In AI-native mode, the developer directs a model from a complete outcome ticket at epic level. It carries the outcome, its planned currency contribution, key user journeys and test requirements. The developer verifies the change through passing tests, demonstrated journeys and human review.

Product and engineering approvals remain in both modes. The mode is a standing choice for the team, made with the people doing the work. Completing the build provides release evidence; outcome validation checks the business value afterwards.

Name an accountable person with the authority to oversee the agent's work before deployment. The operating model should record the decisions that person owns, what the agent may do, which actions need human approval and where questions or incidents go.

Work through a difficult case with your operations, engineering and risk colleagues. If the agent proposes an incorrect change, who can spot it, stop it and put it right? Give those people the access, records and time they need to carry that responsibility, and test the escalation path alongside the workflow.

Start with the work people do and the decisions they need to make. Explore how AI changes that work with the affected teams, including the exceptions they handle and the expertise they want to develop. Use those findings to design roles, responsibilities and any changes to management spans or layers.

Tenhaw's design work includes accountability for agent decisions and a specification for the Head of AI role you may recruit into. Your organisation and people function retain ownership of workforce consultation, redeployment and employment decisions. Bring them into the design early so those responsibilities and the support people need are part of the plan.

Tenhaw's Agentic Design Team typically runs for two to four months at £35,000–£55,000 per month, excluding VAT. The pair comprises an operating-model lead holding the interim Head of AI seat and an agentic architect, with partner oversight. Retainers are cancellable on 30 days' written notice either way.

The outputs are a target operating model, technical architecture, governance framework and a sequenced build plan that your teams, Tenhaw or another supplier can execute. Building the systems is a separate scope. You can also adopt The Tenhaw Way and its how-to guides for free, with your own people taking the work forward.

Implementation becomes difficult when the design asks for capabilities the platform cannot support, leaves delivery responsibilities unclear or gives the people affected little chance to shape how it will work. AI introduces further questions about permissions, human approvals and how agent actions will be checked.

Develop the operating model and architecture together, then try the proposed ways of working with representative teams. Their feedback should change the design before a wider rollout. Give each next step an owner, capacity and a way to assess progress, so the handover provides a practical basis for implementation.

AI can help with a task, but unclear priorities or decision rights still need people to resolve them. Faster drafting, for example, may add to an approval queue if nobody has the authority or time to review the output.

Trace one piece of work with the people who handle it. Find where it waits, what gets reworked and which decisions are difficult to make. Then test whether AI, a change in responsibilities or a simpler workflow improves the result. A baseline gives you and your team a way to see what helped.

Explore the change with the team through a real, bounded build. Practise writing a complete outcome ticket, directing the model, reviewing its changes and verifying the named user journeys. Use what happens to decide whether AI-native delivery suits that team's work and what support it needs.

If the team adopts the mode, make it a standing way of working, with clear responsibilities for writing, review and verification. Review the team's experience alongside observed performance and the help people still need.

In our specialty insurance proof of concept, one client engineer paired throughout the two-week build and reported 70% confidence in running the process unaided. That was one person's self-assessment at the end of the build; independent delivery and sustained adoption still need to be observed.

It can evolve the operating model you already have. Start by identifying which decisions, responsibilities and workflows change when agents take on part of the work, and keep the arrangements that continue to serve your organisation well.

Bring the changes into one coherent model, including any transition arrangements. Different teams can use AI-augmented or AI-native delivery within it, with each holding a standing choice of mode. Shared governance should make ownership and dependencies clear while allowing those differences in how teams build.

It can include changes to reporting lines, but the design also covers decisions, responsibilities, governance and daily work. Sometimes clearer ownership or a better handoff will address the problem without a new organisation chart.

For example, if an agent prepares a customer response, the model should say who checks the evidence, who can approve sending it and who handles an exception. Walk through that process with the people who will use and support it. Their experience helps you decide which structural changes would improve the work.

Include the people who do the work, the people who support it and those with authority to approve changes. That usually brings together product, engineering or architecture, operations, risk and security, with finance helping define value and the people function owning workforce consultation and transition. An executive sponsor needs the authority to resolve decisions across those groups.

Give affected teams a real role in designing and testing the workflow, with named ownership for adoption. Tenhaw contributes an operating-model lead and an agentic architect. James Rooney provides partner oversight on every engagement and leads audits personally.

Follow one workflow from request to completed result and examine both. Poor output quality, unreliable integrations or missing data point to technical work. Repeated waits for a decision, unclear ownership or approvals that nobody can give point to operating-model work. The two can interact, so check the evidence with the people handling the exceptions.

At Globelynx, delivery lead times fell by 60% within six months during work on planning, coordination, supplier arrangements and operational insight. The figure was measured with the client from its delivery data. It is our measurement of our own work, has not been independently audited and does not isolate the effect of any one change. It provides an example to investigate, not a forecast for your organisation.

You can define responsibilities and a way to review decisions while the technology develops. Clear accountability, approval requirements, escalation paths and value measures give teams a stable basis for testing new capabilities.

Treat the work delegated to agents as something to revisit with evidence. A task being frequent or easy to reverse is a useful starting point, but you still need to test reliability, permissions, monitoring and recovery. Your teams and risk colleagues can agree when the evidence supports changing that boundary, without committing the whole organisation to one vendor's current features.

Both delivery modes retain product and engineering approval before an epic leaves Ready for Dev, and human review of the change. AI-augmented teams also need a product-approved story attached; AI-native teams put the user journeys and test requirements on the outcome ticket itself.

The quarterly roadmap includes Tech Debt and Bug Budget epics with allocated capacity. Retrospectives, health checks and outcome validation keep their published cadence. AI can help prepare work for those decisions, while the people responsible check the evidence. Passing tests and demonstrating journeys establish that the work functions; validating value after release establishes what it achieved.

Look at how people carry out the work and ask what they find useful or difficult. Can the team write a usable ticket, apply the approval gates, review an agent's changes and handle an exception? Does feedback lead to changes people can see? Review that evidence alongside releases, quality and the support the team still needs.

Keep adoption and business value visible as separate questions. Outcome work carries currency targets and planned contributions from delivery epics; maintenance epics carry capacity budgets. Monthly outcome validation compares live results with the baseline and measurement plan, recording value realised, not realised or still too early to assess. A team can be using the method while a longer-term benefit is still being measured.