Select a system for the full write-up: the problem, what was built, and the measured outcome.
On the "not yet built" label. The claims engine has been designed and validated but not built, and is marked accordingly. No figures elsewhere on this site are drawn from it.
Contact
Describe the process you want to automate.
You will receive a fixed price and a build plan.
There is no charge for the initial call and no obligation. You deal directly with the engineer who builds the system.
A property-investment platform was paying a third-party service to fetch listing data. It worked, in the sense that data arrived — but nobody could see what was happening inside it, and the bill kept climbing.
What we found
Structured logging across every stage made the invisible visible, and it was worse than anyone expected:
Over half the daily work was being silently abandoned. Jobs were timing out mid-run and quietly dropping what they hadn't finished.
One dead link had consumed a month's API budget by re-fetching itself every five minutes, forever, with no retry cap.
An image-analysis agent was firing three AI calls every two minutes, around the clock, against a dataset that barely changed.
What we built
Rather than pay for more capacity, the work was re-architected: a purpose-built scraper using Python, residential proxies and real browser sessions replaced the paid service, and the enrichment step moved from a synchronous request that always timed out to a paced background worker that doesn't.
73%
cut in running costs
44→100%
job completion
99%
fewer paid AI calls
45min
to detect an incident, from days
Correction during the project
The first fix proposed was wrong. The instinct was to raise concurrency — push harder. The client pushed back, and the deeper analysis that followed found the architectural cause instead. The correction is the reason it worked.
Testing cold-email copy the usual way is slow and wasteful: you split traffic evenly, wait weeks for significance, and spend half your sending volume on the variant you already suspect is worse.
What we built
A system that treats every message variant as a competing option and continuously shifts sending toward whichever is earning genuine replies. It never stops adjusting, so there's no moment where someone has to declare a winner.
Signal filtering
It scores engagement by how fast it arrives. Corporate inbox scanners open and click within milliseconds of delivery, which is enough to poison any naive open-rate measurement. Anything arriving at machine speed scores zero, so the system optimises for real human interest rather than inflated numbers.
217%
more positive replies
19%
on a 10,000-lead campaign
14.2%
for a separate business
Each measured against an equal-split baseline. The 217% is our own acquisition campaign; the 19% was a campaign at StaffCircle, where Caius works part-time. Stated plainly so you can weigh them accordingly.
This one has never run on live claims, and no figure elsewhere on this site comes from it. It's here because the method is worth showing — particularly the part where measuring made the project smaller.
The problem
A vehicle-warranty administrator assessed every claim by hand: read the email, work through a 69-clause terms document, check the vehicle's MOT and tax history, price the part, negotiate. Around thirty minutes a claim, with a ceiling of roughly fifteen claims a day per person.
What validation found
The volume was a quarter of the assumption. Everyone believed 10–30 claims a day. Instrumenting the real inbox showed about 2.5. That reshaped the business case downwards, and it was reported that way.
Only one email in five was a new claim — a 5:1 noise ratio nobody had quantified — and single claims arrived spread across several emails.
The client's own documents contradicted each other on servicing allowances and repeat-claim rules. Resolving them into one canonical rule set was the first real deliverable.
The 7× error
Pricing parts from live market data looked simple until a naive median valued a turbocharger at £96 against a real figure of £278. The cheap listings were actuators and scrap cores, not turbochargers. That single result is why a validation layer exists — without it the system would have made an indefensible offer with total confidence.
The design principle
The AI never decides a verdict. Deterministic rules make every decision; the language model only reads inbound email, classifies the fault and drafts the reply. Every figure is injected by script, and any clause the model cites is checked against what the rules actually decided before the email can send.