London specialty insurance market: Roughly a year of stalled work, rebuilt as a working proof of concept in two weeks

Because the client has not consented to being named, and Tenhaw treats consent as binding. The engagement is with a business in the London specialty insurance market, and that is as specific as the page gets. The architecture in detail, the model and platform choices, the prompt and review approach and the working history of the fortnight all sit under client confidentiality alongside the name. That restraint is the point. If you engage Tenhaw, you should expect the same treatment of your name and your estate.

Yes, provided you read it the way the case study frames it. The two-week proof of concept was greenfield. It began from a blank repository on Azure and replaced work that had stalled, so there was no running system with existing behaviour to preserve. The roughly twelve months is this client's own prior effort circling the same capability, getting information out of PDFs and turning it into business intelligence, without a working result. Same business goal, reached in a fortnight, under conditions that favoured speed. And the claim is a working proof of concept, not a production system.

It is the client engineer's own confidence, in their own words, that they could run the process without Tenhaw. The entire two-week build was pair-programmed with one of the client's engineers, because a proof of concept nobody internal can reproduce is a demonstration rather than a capability. At the end of the fortnight Tenhaw asked that engineer how confident they were that they could follow the process and deliver the next outcome unaided, and the answer was 70%. It is deliberately the softest number on the page and the one Tenhaw cares about most, because it marks the difference between buying a proof of concept and starting to acquire a capability.

No, and the case study says so plainly. The two-week build is a working proof of concept inside the client's regulated estate: PDFs in, structured and enriched data out, business intelligence on a dashboard the business already uses. Month three of the engagement stands up an adjacent agent-led engineering team to productionise it against the organisation's security standards, on a four-to-six week target. When production lands, the result will be published on the page, dated. A proof of concept is labelled as one here until production is real.

Month one was an audit, and it went a long way past a readout. Tenhaw took on whatever was actually blocking delivery. That meant unblocking the data quality issues holding up development and testing, 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 it 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. By the end of the month Tenhaw understood the estate from the inside, and that is what set up the month-two build.

At Tenhaw's published pricing this maps to an Agentic Build Team at £70k–£85k per month, three people under partner oversight. A business that wanted the programme oversight without the build would be looking at Programme and Delivery Management at £18k–£35k per month. Both come off a published rate card. Partner £1,560 a day, senior practitioner £1,250, associate £950, excluding VAT, at twenty billable days a month. Stating the equivalence on a confidential case study is deliberate, because the pricing is not confidential. You can price the same shape of engagement for your own estate before a single call.

The requirements were engineered first. Every requirement, including PDFs, diagrams and images, was converted to structured markdown, AI built a knowledge map across the whole corpus, and a gap-and-contradiction pass surfaced ambiguities the business had not realised were ambiguous. Those went back to the subject-matter experts and got resolved in conversation, before they could turn into rework later. 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. That sequence is what Tenhaw calls its AI-engineering-first method, run here inside a regulated estate.

Three things go into a confidence score on each record. Where the enrichment came from, how certain the model itself reports it is, and what an independent search-based check makes of the value produced. The score drives routing and is never simply displayed. 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 record does not generate work. The case study is explicit that this is a routing rule, not an assurance framework, and it has not been through a regulator or an audit.

The client does, by design. Extraction to markdown, narrowing to key fields, normalisation, enrichment against third-party APIs and semantic grouping are all plumbing. The business logic layer sits on top of them and runs the client's own rules over each enriched record. The case study calls that layer theirs, not ours, and it is the layer that changes most often, so it should not belong to a supplier. Output then lands in an internal dashboard the business already uses. Built to leave applies to the architecture, not just the contract.

On this engagement, yes, at proof-of-concept level. Alongside the main document pipeline, a separate AI data-quality proof of concept on Azure OpenAI showed that entity-resolution output could be validated and scored automatically, with human review prioritised rather than queued. The practical difference is who waits. The scoring decides which matches need human eyes first, so people are not working down a queue of every matched record. This was demonstrated on a live engagement in the London specialty insurance market, and like the main build it is a proof of concept, not a production deployment.

Monthly, and each month has to end in something measurable. Month one of this specialty insurance AI implementation was an audit that behaved like ownership, taking on whatever was actually blocking delivery and producing the operating-model outputs on MVP focus, data foundations and AI strategy. Month two was the build. A working proof of concept in a fortnight, PDFs in and business intelligence out on a dashboard the business already uses. 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. One senior person has been accountable since month one.

Something the business can build against. This client's leadership wanted a London specialty insurance AI strategy that amounted to more than a set of tool licences, so month one produced the structured outputs defining MVP focus, data foundations and AI strategy, alongside the workshops shaping product vision and data strategy. Month two then tested it by building. A working proof of concept in two weeks, PDFs in, structured and enriched data out, business intelligence on a dashboard the business already uses. The order is the point. The people who wrote the strategy had to deliver against it a month later. That is a harder test than a slide review.

Roughly every fifth prompt, a security review ran across the whole system, inside the build rather than after it. The fortnight started from a blank repository on Azure inside the client's regulated estate, with high-level prompts against the whole requirement set. Reviewing at that rhythm keeps each review small enough to act on while the code is still cheap to change. Security was already a live programme concern when we arrived, with a gate approaching and no coordination owner, and month one picked that up. The cadence is a build practice. Sign-off comes with productionisation against the organisation's security standards.

The delivery tooling was split across both, so no single place showed the state of the work. Month one led the migration to a GitHub-based delivery model with agent-assisted workflows. That puts the delivery record next to the code the agents are working in, so nobody has to keep a separate system in step by hand. The same month also covered the data issues holding up development and testing, plus disaster-recovery failover planning and release governance. Read it as the right call for this estate. It is not a general instruction to leave Azure DevOps behind.