London specialty insurance market: From traditional ways of working to an agentic operating model

One example of agentic AI in insurance is Tenhaw's six months with a London specialty insurer, where it meant changing how the delivery teams worked and proving it on one build first. A year of stalled PDF work became a working proof of concept in two weeks, on Azure with Claude: documents in, structured and enriched data out, business intelligence on a dashboard the business already used. An eight-week special project then took the agentic way of working to Product, Engineering and QA, with outcome-based tickets, AI-assisted development workflows and AI-generated tests. On one front-end epic, an outcome ticket built with Claude in the agentic workflow shipped 54 front-end changes, against 1 for a normal ticket built the standard way, in a similar cycle time.

In three steps: take ownership of whatever is blocking delivery, prove the agentic method on one real build with one of your own engineers pairing throughout, then take it to Product, Engineering and QA inside the tool stack you already have. That was the sequence at a London specialty insurer. Month one was an AI readiness assessment that unblocked development and testing. Month two brought a two-week working proof of concept, run using The Tenhaw Way and the agentic engineering method. An eight-week special project then moved the wider team's AI conversation from theory into practice. Nothing went into an operating guide until Tenhaw had run it with the client's team.

Momentum across the whole programme: delivery, governance, data quality, the backlog, release readiness, beta planning and product evolution. Tenhaw arrived at a London specialty insurer to support a stalling programme and became its embedded lead across all of them, one senior person bringing a new way of working. Tenhaw calls the role Embedded Agentic Lead, though most buyers arrive looking for a fractional head of AI or an interim AI programme director who will sit inside the programme. It stayed hands-on for all six months: the two-week proof of concept was pair-programmed with a client engineer, and the eight-week special project ran from concept to handover.

Six problems at once: unclear governance, data quality blocking build and test, a backlog nobody trusted, slipping release readiness, a security gate with no coordination owner, and delivery tooling split across Azure DevOps and GitHub. It was a multi-workstream programme in traditional delivery, stalling in the gaps between product, engineering and platform. Leadership also wanted AI in insurance operations to be more than licences. The immediate need was momentum, and the underlying need was a different way of building. Tenhaw arrived to support the programme, took ownership of the blockers through an AI readiness assessment in month one, and by the end of that month the path into agentic ways of working was clear.

Because the proof of concept was one build, and the aim was a new way of working that the wider team could run. The build was the middle of three phases. Phase one, an AI readiness assessment, filled month one and took ownership of the blockers. Phase two rebuilt a year of stalled PDF work as a working proof of concept in two weeks, the first visible proof of the new operating model, with one of the client's engineers running the method end to end. Phase three, an eight-week special project, took that way of working to Product, Engineering and QA. Tenhaw was hands-on throughout, and spent the last two months proving every step of the operating guides before handover.

The outcome ticket shipped 54 front-end changes and the story shipped 1, in a similar cycle time. Both sat on the same front-end epic at a London specialty insurer. The outcome ticket was written as an outcome and built with Claude in the agentic workflow. The normal ticket was written as a prescriptive story and built using the standard approach. So the two differed in how the work was written and in how it was built. Outcome-based tickets were one of the practices Tenhaw introduced during the eight-week special project, which took the agentic way of working to Product, Engineering and QA.

Both supplied evidence: mutation testing as quality evidence, and the What's Changed review pack as automated review documentation for AI-written code. Tenhaw brought them in during the eight-week special project at a London specialty insurer, when it pushed testing higher up the delivery lifecycle alongside AI-generated tests, structured test plans and evidence-based delivery. Testing and review were two of the five steps the agentic operating guides covered, with design, engineering and deployment, and each step was proven hands-on on live work before it went into a guide. Testing and security processes inside the workflow were part of what Tenhaw left behind.

Only AI tools the client had approved, on zero-retention or enterprise model agreements. The engagement used Claude, Codex and Azure. Claude was the model for the two-week proof of concept on Azure and for the agentic workflow that built the outcome ticket on a front-end epic, and a separate data-quality proof of concept ran on Azure OpenAI. Tenhaw worked on client infrastructure, under client identity and least privilege. Security sat inside the build rather than after it, with a security review roughly every fifth prompt, and the eight-week special project put security, deployment and standards skills inside the delivery workflow.

That agentic ways of working could be implemented for the client within its existing tool stack, by changing the ways of working. The project followed the two-week proof of concept and set out to move the wider team's AI conversation from theory into practice. It introduced five practices: outcome-based tickets instead of prescriptive stories; AI-assisted development workflows; engineering skills and reusable prompts; security, deployment and standards skills inside the delivery workflow; and automated What's Changed review documentation. Tenhaw also explored GitHub-based delivery tooling, enterprise AI connectors and market-intelligence experiments with the client's approved AI tools. The project ran from concept to handover.

Every step from design to deployment. The agentic operating guides covered design, engineering, testing, review and deployment, and each step was proven hands-on with the insurer's team on live work before it went into a guide. The output was not a slide pack. Product, Engineering and QA each had a role-based pack, alongside reusable engineering skills, testing and security processes inside the workflow, and governance and adoption material the team could keep using after Tenhaw left. Every experiment also became reusable knowledge, including lessons learned, testing strategies, product and delivery frameworks, and handover packs with agentic operating model learnings per domain. The guides were written to spread the operating model without Tenhaw in the room.

By running every step with the client's own people before Tenhaw left. It began in the two-week proof of concept, where one of the client's engineers paired throughout and ran the agentic method end to end. Asked at the end of that build how confident they were that they could follow the process and deliver the next outcome without Tenhaw, they said 70%. The eight-week special project then ran from concept to handover, and every step of the operating guides was run with the client's team on live work before it was written down. Once the client was confident it could continue without Tenhaw, the team was left ready to roll out across Product, Engineering and QA.

Yes. Both describe one six-month Embedded Agentic Lead engagement with the same London specialty insurer, which is not named. The six-month write-up covers the whole engagement, from traditional delivery to an agentic operating model: the month-one readiness assessment, the two-week working proof of concept and the eight-week special project that took the new way of working to Product, Engineering and QA. The other write-up is the close-up on months one and two: the audit month, then the two-week working proof of concept in full, with requirements turned into structured markdown before any code, the pipeline stage by stage, confidence-routed review, and the 70% confidence the paired engineer reported at the end of the fortnight.