Roughly a year of stalled work, rebuilt as a working proof of concept in two weeks
Roughly a year of stalled work on getting information out of PDFs. Month one removed the delivery blockers and passed a security gate. Month two rebuilt the capability as a working proof of concept in a fortnight, pair-programmed with one of the client's own engineers.
- prior build effort rebuilt as a working proof of concept
- 12 months → 2 weeks
- the client engineer's own confidence they could run the process unaided afterwards
- 70%
- AI-engineering proof of concept delivered, from a month-1 start
- Month 2
If you are a UK insurer, what transfers and what does not
- Provenance-scored extraction transfers.Every enrichment carries the source it came from, so the lineage question a data or actuarial owner will ask has an answer that was recorded at the time rather than reconstructed afterwards.Read the full paragraph
- Confidence-routed human review transfers.Routing review by confidence and consequence is describable to a second line as a control, which a review queue worked in arrival order is not.Read the full paragraph
- The two-week build pace is n=1.One greenfield build, one client, one paired engineer. It is the fastest thing on this site and the least repeatable, and you should not plan against it.Read the full paragraph
- Nothing here has been through a coverholder audit.It is a proof of concept inside one firm, and no assurance function has yet looked at it. What that leaves unevidenced is set out in full below.Read the full paragraph
- No regulatory opinion was given.Compliance was outside our scope and we advised on none of the regimes named on this page. Each is set out below beside what we did and did not do against it.Read the full paragraph
A working proof of concept in two weeks: PDFs in, business intelligence out on Azure, covering ground that had previously taken this business roughly twelve months. We pair-programmed the entire fortnight with one of the client's own engineers, who ended it saying they were 70% confident they could run the process without us. Month one was the audit that pulled us across the whole programme; month two was this build.
- Client
- London specialty insurance market, unnamed at their request
- Duration
- 3 months, ongoing
- Sector
- Financial services, London specialty insurance market, United Kingdom
- Engagement shape
- Embedded Agentic Lead. Most buyers arrive looking for a fractional head of AI or an interim AI programme director.
- Rung on the ladder
- Embedded Agentic Lead
What we walked into
A specialty insurance business was running a complex multi-workstream programme with delivery stalling in the gaps between product, engineering and platform. Data quality issues were blocking development and testing, a security gate was approaching with no coordination owner, delivery tooling was split across Azure DevOps boards and GitHub, and the leadership team wanted an AI strategy that amounted to more than a set of tool licences. The immediate need was momentum; the underlying need was a different way of building.
The work itself
Run against The Tenhaw Way, which is published in full and free to adopt without engaging us.
Month one was an audit, and it took us across far more of the programme than a readout exercise would have. We took ownership of whatever was actually blocking delivery: unblocking the data issues holding up development and testing, coordinating an external penetration test end to end including secure access provisioning and vendor management, supporting disaster-recovery failover planning and release governance, and leading the migration from Azure DevOps boards to a GitHub-based delivery model with agent-assisted workflows. In parallel we contributed to the workshops shaping product vision, data strategy and the AI operating model, and produced the structured outputs defining MVP focus, data foundations and AI strategy. The value of doing it that way is that by the end of the month we understood the estate from the inside rather than from a survey.
Month two went after the capability the business had been circling for roughly a year: getting information out of PDFs and turning it into business intelligence. We ran our AI-engineering-first method. Every requirement (PDFs, diagrams, images) became structured markdown, AI built a knowledge map across the corpus, and a gap-and-contradiction pass surfaced ambiguities the business had not realised were ambiguous, before a line of code was written. Those went back to the subject-matter experts and were resolved in conversation rather than in rework.
Only then did the build start, from a blank repository on Azure, with high-level prompts against the whole requirement set and a security review roughly every fifth prompt. This was greenfield. It replaced work that had stalled rather than changing a running system with existing behaviour to preserve, and the two-week figure should be read in that context. The pipeline itself is set out stage by stage below.
The entire fortnight was pair-programmed with one of the client’s own engineers, because a proof of concept nobody internal can reproduce is a demonstration rather than a capability.
The pipeline, stage by stage
- 01
Extract to markdown
Every source document is converted to markdown before anything else happens, so what the model actually read stays inspectable by a human rather than disappearing into an embedding. - 02
Narrow to the key fields
The markdown is reduced to the fields the business needs, rather than carrying whole documents forward and paying for them at every later step. - 03
Normalise
Fields are normalised into consistent shapes and units, so downstream logic compares like with like instead of guessing. - 04
Enrich against third-party APIs
Records are enriched from external sources, and each enrichment carries the provenance of the source it came from. - 05
Add semantic context and thematic grouping
Related records are grouped and given the context a person would otherwise add by hand when reading them side by side. - 06
Apply business logic
The client's own rules run over the enriched record. This is the layer that is theirs, not ours, and it is the layer that changes most often. - 07
Land in the dashboard
Output lands in an internal dashboard the business already uses, rather than in a tool that only exists while we are there.
- Source provenance
- How much the source of a given enrichment is worth trusting.
- Model certainty
- What the model itself reports about the extraction or the match.
- Search cross-check
- An independent search-based check against the value that was produced.
Those three produce a confidence score on the record, and the score is an input to routing rather than a display value. Review is routed by confidence and consequence together, so a low-confidence field on a high-consequence record reaches a human first and a high-confidence field on a low-consequence one does not generate work. That is a routing rule, not an assurance framework, and it has not been through a regulator or an audit.
70% after two weeks is the difference between having bought a proof of concept and having started to acquire a capability.
What came out of it
- prior build effort rebuilt as a working proof of concept
- 12 months → 2 weeks
- the client engineer's own confidence they could run the process unaided afterwards
- 70%
- AI-engineering proof of concept delivered, from a month-1 start
- Month 2
In two weeks the proof of concept was working: PDFs in, structured and enriched data out, business intelligence on a dashboard the business could use, covering ground that had previously taken roughly twelve months. A separate AI data-quality proof of concept on Azure OpenAI demonstrated that entity-resolution output could be validated and scored automatically, with human review prioritised rather than queued.
The number we care about most is the softest one. At the end of the fortnight we asked the client engineer who had paired on the whole build how confident they were that they could follow the process and deliver the next outcome without us. They said 70%, and 70% after two weeks is the difference between having bought a proof of concept and having started to acquire a capability.
From month one, the external penetration test passed with no major findings and only minor UI observations. We coordinated that test rather than performing it, and its scope was the pre-existing product, not the later AI-built proof of concept.
The two-week build is a proof of concept, not a production deployment. Month three stands up an adjacent agent-led engineering team to productionise it against the organisation’s security standards, on a four-to-six week target.
What we cannot publish, and what we will show you on a call
The architecture in detail, the model and platform choices, the prompt and review approach, and the working history of the fortnight sit under client confidentiality, alongside the client's name. We will walk a technical audience through the architecture and how it was built on a call under an NDA, including the parts that did not work first time, and you should expect the same treatment of your name and your estate if you engage us.
What did not change
Four things this engagement left exactly where it found them. If you are citing the numbers above, cite these with them.
- 01
Nothing moved into production.
The two-week build is a working proof of concept, built inside a regulated insurer's estate rather than on synthetic data. Month three is productionising it against the organisation's security standards.
- 02
No regulatory or audit position changed.
We were not engaged on compliance and we did not advise on Solvency II, Consumer Duty, operational resilience or DORA. No delegated authority audit, no internal model validation and no Lloyd's review has looked at any of this. The confidence routing is a routing rule, not an assurance framework, and it has not been through a regulator or an audit.
- 03
The external penetration test says nothing about this build.
It ran in month one, we coordinated it rather than performed it, and it assessed the pre-existing product. It passed with no major findings and only minor UI observations, and none of that is evidence about the pipeline described above.
- 04
One engineer's confidence is the only measure of handover we have.
The 70% is what the client engineer who pair-programmed the fortnight said when we asked them, after two weeks. It is self-reported, it is one person, and no one else's ability to run the process has been measured, so the wider team's is untested rather than proven.
What a security review of this build would find today
No client security review has looked at this build yet. This is what our published supplier position and this page's account would put in front of one, including the parts that would come back as gaps.
In place
- A security review ran roughly every fifth prompt of the build rather than once at the end
- Extraction lands in inspectable markdown before it is narrowed and normalised, so a reviewer can see what the model actually read rather than being handed an embedding
- Every enrichment carries the provenance of the source it came from, and the confidence score built from provenance, model certainty and a search cross-check routes review by consequence as well as by confidence
- Under our published policy, no client data, code or documentation goes into any AI tool the client has not named and approved in writing, and where an approved enterprise AI tenancy exists we work inside it rather than bringing our own
- Under the same policy, model providers are used on zero-retention or enterprise agreements, so client content is not retained by them or used for training
- Our default is to work on client infrastructure under client controls: their identity provider, their access controls, and least-privilege access time-boxed to the engagement with a documented offboarding step
- BS7858-standard screening before any client access, and no substitution of the people on the engagement without written agreement, are contractual commitments in the engagement agreement
- No client production data is retained after an engagement ends, with retention and deletion terms set in the Data Processing Agreement
- Professional indemnity at £1m and cyber at £25k, either of which can be increased for a specific engagement where a supplier standard requires it
Not yet in place
- No penetration test has been run against this build. The one on this engagement assessed the pre-existing product, in month one
- No independent assurance of the routing rule. It is a control in the making, not a validated one, and no second line has signed it off
- Cyber Essentials Plus is in progress rather than held, ISO 27001 is targeted for 2027, and ISO/IEC 42001 is under assessment
- Productionising the build against the organisation's own security standards is month three's work, and it has not happened yet
The full supplier position, including the cover levels, the DPA and the sub-processor annex, is on the security page.
The obligations this work sits underneath
What each regime asks of an AI programme in this sector, and what we did and did not do against it.
The regime an AI programme inside a UK insurer inherits
A specialty insurer writing in the London market is supervised by the FCA, and where it is a designated firm, by the PRA as well. An AI programme inside one inherits obligations that have nothing to do with model accuracy.
Solvency II expects a documented system of governance with clear ownership of any process feeding risk or capital decisions, which means an extraction pipeline touching submissions or exposure data needs a named owner and a written control rather than a notebook. The FCA's Consumer Duty requires firms to evidence the outcomes customers actually get, so where an automated step influences one, it has to be explainable months later by someone who was not in the room. Operational resilience rules ask which important business services the new system sits inside and what happens when it is unavailable, a question almost nobody asks of a proof of concept until it has quietly become load-bearing. For firms with EU entities, DORA extends the same thinking to third parties, which now means model providers and the APIs an enrichment step calls.
None of that is satisfied by an evaluation harness.
What our method produces towards that, and what it does not
We were not engaged on regulatory compliance. We did not advise on Solvency II, Consumer Duty, operational resilience or DORA, and nothing here is a regulatory opinion.
The way we build produces some of the evidence those regimes ask for as a by-product rather than as a later exercise. Extraction lands in inspectable markdown before it is narrowed and normalised, so a human can see what the model actually read. Every enrichment carries a confidence score derived from the provenance of its source alongside model certainty and a search-based cross-check. Human review is routed by confidence and consequence, which is the beginning of a defensible control. Security review runs roughly every fifth prompt of the build.
If you need a regulatory opinion, you need a regulatory specialist, and we will say so on the first call. If you need the programme built so that a regulatory specialist can evidence it afterwards, that is the work described on this page.
What this engagement does not claim
The same caveats the case studies hub carries, narrowed to this engagement so nothing here is a surprise to your analyst.
- 01
The client is confidential, and stays that way.
This organisation has not consented to being named, so nothing on this page identifies it: no product names, no people, no detail that would narrow it to one firm in the market. Before you sign, we will ask them for a reference call, and if they decline we will tell you so. You should expect the same treatment of your name if you engage us.
- 02
Nothing agentic is in production yet.
The specialty insurance build is a working proof of concept, and month three stands up an agent-led engineering team to productionise it against the client's security standards. The HSBC Voice Insights platform was a proof of concept, and its 1.5M hours a year is a projection rather than a measured saving.
- 03
The 70% is one engineer's own estimate.
It is what the client engineer who pair-programmed the build said when we asked how confident they were of running the process without us: self-reported, after two weeks, not a benchmark. We report it because handover is the measure we care about most.
What transfers is the whole shape of the engagement: one senior person accountable from month one, a monthly cadence with something real at the end of each month, and a handover built into the build rather than bolted onto the end of it. What does not transfer yet is production. This is a working proof of concept built inside the client's regulated estate, month three is productionising it against the client's security standards, and the result will be published here, dated, when it lands.
Agent-Readiness Audit
Where agents add value, where they don't, and what to do first. Fixed price · £30k–£90k · 6–8 weeks.
What that engagement coversOther engagements
Sector first, because that is the next question. All twelve are on the hub, grouped into the two we would call AI work and the ten we would not.
Standing up the delivery engine behind a £40bn hydrogen business case
£40bn, business case underpinned
Landing the Discovery+ launch on a CEO-set deadline
6, development teams coordinated
Turning erratic global delivery into something the business could plan around
3, regions: UK, USA, Singapore
What this engagement is called before anyone finds us
The words buyers arrive with, and what they have in common.
What buyers call this before they find us
Three different searches land on this engagement and all three describe the same thing. Some call it a fractional head of AI, because what they need is one senior person accountable for the AI programme without a permanent executive hire. Some call it an interim AI programme director, because a programme already exists and nobody owns the agentic part of it. Some go looking for an agentic AI consultancy or an AI implementation partner, because the advisory work has been done twice already and produced slides.
The distinguishing test is worth applying to anyone you shortlist, us included: ask what they will personally have shipped by the end of month two. Here the answer was a pipeline that takes PDFs in and puts business intelligence out on Azure, built from a blank repository, in two weeks.
Want the same thing, in your organisation?
A 30-minute call with James Rooney. We will tell you which parts of this we have done before and which we would be doing for the first time, and you will leave with a rough scope either way.
Most organisations start with a fixed-price Agent-Readiness Audit · £30k–£90k · 6–8 weeks