the insurance-automation paradox

This January, while I was in San Francisco, Aaryaman introduced me to Anand, who (as most professionals that were put my way at the time) wanted some advice on AI. I assumed it’d be another stupid conversation with someone trying to work out where they could sprinkle AI into their business.

I’m pleased to say I was pleasantly surprised. About 10 minutes in, we were discussing the idea of AI-ifying and rolling up entire professional-services companies.

The rough idea was simple. Professional services are full of old, profitable firms which still run on a combination of emails, spreadsheets, PDFs and human memory. Buy a few of them, use AI to remove the repetitive work, and suddenly a collection of normal businesses becomes a much more efficient one.

It was also surprisingly close to what I’d already been doing. My last company built bespoke AI systems for enterprises based on exactly what they were struggling with. We’d go into a business, understand its operations, identify where the inefficiencies were, and build the systems needed to fix them.

The roll-up was essentially the same thing, except we’d own the companies ourselves. Instead of building the system, handing it over and walking away, we’d own both the software and the value created by improving the business. As far as ideas for my next company went, it made a suspicious amount of sense.

We initially tried to work out what that would look like in law. The idea became Lex: something between an AI-first law firm, a corporate-intelligence platform and a legal-services roll-up.

I realised that, with a company’s Companies House number, shareholder agreements and other corporate documents, we could query the GOV.UK API and reconstruct roughly 80% of its current legal state. Lex would turn that information into a structured company record, rebuild the cap table from zero and create a searchable knowledge base connecting the documents, people, shares and legal relationships it found.

You could then interrogate the company through a chat interface, run waterfall calculations and ask questions against both its documents and UK legislation. When the system reached something which genuinely needed a lawyer: Lex would package the question, the relevant company information and the supporting documents into a ticket so that the lawyer didn’t have to spend their first few hours figuring out what was going on.

The technology worked, but it increasingly felt like a feature rather than a company. Carta has since added document ingestion to its cap-table builder, allowing investors to upload corporate documents and automatically populate a company’s ownership structure. That was essentially the natural base for the most useful part of Lex. It already owned the cap table and the distribution around it; and neither Anand nor I had a convincing right to win in law.

We then landed on insurance brokerage.

Anand told me insurance was a trillion-dollar industry and, almost immediately, I was excited. Trillion-dollar industries have a wonderful way of doing that. The number is large enough to temporarily substitute for an argument.

But over the last few months, I’ve been on the fence about whether I actually care about insurance, or whether I care about the fact that a very impressive group of people asked me to build an AI company with them. Those are obviously not the same thing.

So I started peeling back the layers.

The Companies House experiment suddenly became useful again. Instead of using the API to reconstruct one startup’s cap table, we could use it to find insurance brokerages across the UK, pull their filed accounts and build a first-principles view of the acquisition market.

That became this insurance-brokerage target screener. It currently contains filed-account information from 580 companies and lets us compare their revenue, growth, margins, headcount and revenue per employee. It also gives each company a rough fit score based on whether it resembles the kind of smaller, profitable brokerage a roll-up might want to acquire.

It isn’t proper acquisition diligence. Filed accounts are incomplete, profit before tax is only being used as a rough proxy for EBITDA, and some of the companies in the dataset are obvious artefacts. More importantly, the screener is at its blindest exactly where the thesis lives. Small companies and micro-entities can omit their profit-and-loss account from the public filing, which means many of the smallest brokers disclose neither revenue nor profit. The screener can find candidates and approximate their scale through things such as headcount and the balance sheet. The actual numbers normally require an NDA.

Nevertheless, it gave us something much more useful than a market-size slide: an initial picture of which firms actually existed and where the acquisition sweet spot might sit.

And the deeper I went, the stranger the problem became. Insurance seems to be one of the most obvious industries for AI to automate. It contains enormous amounts of paperwork, repeated processes, old software and expensive human administration.

Yet it’s also possibly the last industry in which you’d want an AI quietly getting something wrong.

That’s where for the sake of this essay, I'm coining the term “the insurance-automation paradox”.

What the Broker Actually Sells

An insurance broker sits between a business and the insurance companies willing to carry its risks.

Simple enough.

If you own a factory, the broker needs to understand what the factory makes, which machines it uses, what the building contains, who works there, what’s gone wrong before and the dozens of different ways the business could burn down, stop operating or get sued.

The broker takes this messy version of reality and turns it into something an insurer can understand and price. They find possible insurers, compare policies, explain the differences, arrange the cover, manage the paperwork, renew it every year and, when something inevitably goes wrong, help with the claim.

They sell translation, access, judgement and trust alongside the policy itself.

This explains why companies don’t simply fuck off and do everything internally. Insurance is important enough to bankrupt a business when it goes wrong, but too occasional and specialised for most companies to justify maintaining an entire internal team around it. A good broker already understands the market, knows which insurer has an appetite for a strange risk, understands the policy language and has seen what actually happens when somebody makes a claim.

The relationship becomes incredibly sticky off the back of that. FCA research into the wholesale market found that annual switching between brokers was below 10%, while only around 8% of large corporate clients invited rival brokers to pitch each year. Many of the companies surveyed had stayed with the same broker for over a decade.

What I found interesting was that they weren’t physically locked in. Most of them could’ve moved if they wanted to. They stayed because they were satisfied with the service, trusted the broker and didn’t want to spend an enormous amount of time teaching somebody else how their business worked.

It is a very similar dynamic to the one we found with corporate lawyers, and probably most other professional-services providers. Over time, the service provider accumulates so much context around the company that replacing them means reconstructing years of fairly implicit knowledge.

For smaller companies, the logic was largely the same. A broker was the easiest way to reach several insurers, compare different forms of cover and outsource a very specific type of knowledge which the company didn’t want to develop itself.

The broker is generally paid through commission: a percentage of the premium, paid by the insurer. If a customer pays £100,000 for a policy and the commission is 15%, the brokerage receives £15,000. Brokers can also charge explicit fees, particularly on larger or more complicated accounts, but commission is the central economic fact.

That makes the spreadsheet version of this business less clean. If insurance prices fall, the brokerage’s revenue can fall even when it retains every client. If the broker finds the customer cheaper cover at renewal, it may reduce its own income. Improving the customer’s outcome can therefore cannibalise the broker’s revenue unless the account uses fees or another remuneration structure. The FCA also expects commission to reflect the value provided, so it can’t simply be treated as an untouchable annuity.

We’ve now established that trust is obviously incredibly useful. It is also, unfortunately, where the automation problem starts.

The Insurance-Automation Paradox

AI is normally most useful around the middle of a distribution.

Give a system thousands of similar inputs, clear examples of correct outputs and a relatively stable process, and it can become very useful very quickly. This is why the first insurance products to move online were the simple ones. A ordinary car, house or holiday can be placed through a form and a pricing engine because the questions are already known, the answers fit into fairly neat boxes and millions of similar examples already exist.

Those cases need a human broker least.

The businesses which still rely on independent brokers tend to be the ones which don’t fit cleanly inside a five-minute form.

A restaurant, shipping fleet, construction company and cyber-security business don’t share one tidy description of risk. The information needed to insure them is scattered across emails, spreadsheets, old policy schedules, phone calls, claims histories, accounting systems and, unfortunately, somebody’s head.

So, the more valuable the broker becomes, the harder the consequential part of the case is to automate.

There is an important distinction here. A complicated client doesn’t spend every hour producing complicated work. The shipping fleet still creates an enormous amount of ordinary administration: chasing documents, processing mid-term adjustments, preparing renewals and re-keying information between systems. There is a hard core of judgement wrapped in a lot of routine work.

The paradox therefore exists at the level of tasks rather than entire clients. AI will enter insurance fastest where the decisions are standard and the consequences are measurable. The brokers we’d actually be buying survive because the remaining decisions resist that standardisation, even if much of the work surrounding them doesn’t.

This changes what we should initially ask the technology to do.

Replacing the broker is a fairly stupid place to start. Getting 80% of the way through the ordinary work, reliably enough that the broker can spend their time on the dangerous 20%, seems much more useful.

Getting to 80%

Traditional software would try to solve this by forcing every company into the same perfectly structured form.

That works until the company is even slightly weird, which is unfortunately where brokers begin to become useful.

LLMs change the input side of this problem. They can read the ugly email, eighty-page PDF, spreadsheet, call transcript and claims report without requiring every customer to communicate in exactly the same format. We don’t necessarily need to standardise how the information enters the system anymore.

We still need to standardise what the system understands from it.

At some point, it needs to arrive at a shared view of who is being insured, what the company does, which assets exist, what has gone wrong before, what cover is required, what information is missing and where every fact came from.

That part isn’t allowed to be messy.

Most of the picture should already exist across a small number of sources: current and previous policies, customer proposal forms, claims histories, the broker-management system, renewal emails, call notes, accounts and public company records.

Building a perfect digital twin of every company before doing anything useful would be a wonderful way to spend three years creating infrastructure nobody uses. We need to collect the common facts which decide most ordinary cases, identify where the sources disagree and recognise when the system doesn’t know enough.

This also means that “80% correct” can’t mean the model produces a plausible-looking answer four times out of five.

Across historical cases, it needs to extract the important facts correctly and consistently, link those facts back to their original sources and reliably send incomplete, conflicting or genuinely strange cases to a human.

Not every field deserves the same tolerance either. Misspelling a director’s middle name is annoying. Missing the fact that a factory stores flammable chemicals could invalidate the entire policy.

Correct information therefore has a few different layers. It needs to match the original source, still be current, avoid silently conflicting with another source, be complete enough for the decision being made and remain traceable to where it came from.

This is where I think the actual technical infrastructure sits: a shared evidence layer across the broker’s systems where every customer, policy and risk can be understood, questioned and corrected, in some sort of unified format. {sighs in latent space}

Unit Tests for Insurance Policies

The particularly nasty thing about an insurance error is that it can remain invisible for years.

A policy can be bought, renewed several times and filed away without anyone discovering that it is wrong. The mistake only becomes visible after the factory burns down and the insurer points to an exclusion on page eighty-four.

At that point, it’s obviously a little late to edit the policy.

Software engineers have a pretty obvious response to this type of problem: test before deployment.

I think insurance policies should have something resembling unit tests.

Take a proposed policy and simulate hundreds of normal things going wrong. A fire starts in one part of the building. A machine fails and production stops for six weeks. Customer data is stolen through a supplier. An employee causes an accident while using their own car for work.

For each event, the system asks what should be covered, which clause controls the decision, which detail changes the outcome and where a dispute might emerge. It can then change the facts repeatedly until the cover breaks.

It is loosely inspired by companies such as Artificial Societies, which create synthetic groups of people and test how they may react to a decision before it enters the real world. Insurance needs a much more constrained version. We’d be pressure-testing a legal promise against a series of possible events.

Policy-comparison and gap-analysis tools already do versions of this, so I’m not pretending the category appeared in my head. The useful version would make the test explicit: which clause controls each scenario, which detail changes the answer and where the expected cover breaks.

This obviously wouldn’t prove how an insurer, loss adjuster or court would decide a real claim. Coverage disputes often turn on wording construction and precedent, which is precisely the part a simulation can’t settle. It could still expose missing cover, unclear wording and dangerous assumptions before the policy is relied upon. Something closer to a UAT test for the policy than an artificial claims court.

In the beginning, this would probably only work for simple policies with known scenarios and expert-written expected answers. That feels like the right place to start. Begin where failure is measurable, keep a human in control and earn the right to attempt harder cases.

The Black Box Is the Wrong Thing to Watch

There is a temptation to solve the trust problem by watching the AI’s reasoning trace.

If the model explains how it reached an answer, perhaps a broker can read through the logic, decide whether it makes sense and approve the decision.

It has happened in many cases personally where an AI can produce an incredibly persuasive explanation for a completely wrong answer. The reasoning trace may just be another output of the same unreliable system. It isn’t independent evidence that the decision was correct.

The decision needs to be reconstructable.

For every meaningful action, the system should keep the facts it used, the original documents, the policy clauses involved, the information it considered missing, the checks it passed, the alternatives it rejected, its confidence and the human who eventually approved it.

The broker should oversee an evidence trail rather than trusting the model’s account of itself.

This may mean insurance can’t be automated end to end for a very long time. I don’t think that makes the technical opportunity smaller.

A useful system could gather the information, structure it, compare the policies, run the checks and surface the dangerous bits. The human would remain responsible for deciding what to do with them.

That sounds slightly less exciting than an autonomous insurance agent. It is probably much more useful.

The Human Is Both the Cost and the Asset

This creates an awkward problem for the roll-up.

When you buy a small brokerage, a spreadsheet will tell you that staff are one of its largest costs. It becomes very easy to draw a line through a few roles, replace them with software and call the difference margin improvement.

But the client may have stayed for ten years because Sarah answers the phone, understands their factory and knows which underwriter will tolerate its particularly strange collection of risks.

Remove Sarah and you may remove the revenue with her.

The broker is simultaneously the expensive human in the workflow and the reason the workflow has any commercial value. Their relationships contain information which has never made it into Acturis, Open GI or the policy document.

The people you initially want to automate away may be the asset you just paid to acquire.

There is an uncomfortable echo of Lex here. Carta already owned the cap table, added document ingestion and absorbed its most useful feature. Acturis, Open GI and Applied already sit inside the broker’s workflow, hold much of the policy data and are adding AI themselves. They may be the natural home for the software layer we imagine building.

Owning the brokerage is the possible defence. A software vendor sees what brokers enter into its system. An owner can access the knowledge which never made it there, connect information across the company and change the workflow rather than politely asking customers to adopt one. Whether that advantage is large enough to justify buying dozens of regulated businesses is something we’d still have to prove.

Some of the brokerage’s value also sits in agency agreements, delegated authorities and insurer relationships. Those don’t necessarily transfer cleanly simply because you bought the company. An insurer may need to consent, re-paper the arrangement or decide it no longer wants the risk. The asset can therefore walk out through both the front door and the underwriting agreement.

I think the first form of automation should make the broker unusually capable. Give them perfect memory across the account. Show them everything that changed since the last renewal. Draft the submission. Compare the quotes. Surface the exclusion. Find the missing document. Let them spend their time asking the question the system didn’t know to ask.

Eventually, some roles and parts of the process will disappear. Pretending otherwise would be equally dishonest.

Destroying the human relationship before understanding why it works would be a wonderful way to automate away the company’s value. The difficult part is separating the work the customer is actually paying for from the work which exists because the systems are shit.

To Live, Start by Not Dying

This is the part of the business which I find most rationally compelling.

Most startups begin without product-market fit. You’re trying to work out what the product is, who needs it, why they need it and whether they’ll ever pay you for it. Almost everything can change because almost nothing works yet.

That gives you an enormous appetite for risk. You can replace the product, rebuild the architecture, change the customer and throw away six months of work. There isn’t much to protect beyond the cash in the bank and your remaining will to live.

A roll-up begins from a completely different position. You’re buying a company which already works.

The brokerage already has customers, distribution, revenue, employees and a service people trust. Insurance renews every year, and the broker doesn’t normally carry the risk of paying claims. You acquire a viable business from day one.

You also acquire something which you’re capable of fucking up.

That changes the risk appetite completely. The goal isn’t to search for PMF by changing everything until something works. PMF already exists. The job is to understand why the company works, improve it carefully and avoid destroying whatever kept its customers there in the first place.

You can’t deploy an interesting model into the core workflow, discover it quietly dropped a few important policy details and call that a useful learning. The company has customers today. Its mistakes have consequences today. Every technical change arrives with a burden of proof because the existing system, however inefficient it appears, is producing a functioning business.

This makes a roll-up much more risk-averse operationally than a startup built from zero. New systems should begin in shadow mode, run against historical cases, sit beside the current workflow and prove themselves before they’re trusted with anything consequential.

The company can still be technically ambitious. It just has to spend its risk budget differently.

AI is being asked to improve an existing machine with existing demand. That is a far less sexy story than building the next foundational model. It is also a considerably better way of not dying.

The acquisition thesis becomes especially interesting at the smallest end of the market. Large consolidators already know how to buy brokers. We certainly aren’t the first people to discover recurring brokerage commissions.

There may be a point below which the operational mess is no longer worth their time. Moving years of customer and policy data, checking it, handling the compliance work and combining several systems costs money regardless of whether the target is worth £3 million or £300 million.

If software makes those small migrations cheap and repeatable, the technology changes which brokerages are worth buying in the first place.

That is the part which makes this more interesting than a traditional margin-arbitrage play. The technology could open an acquisition market which is currently uneconomical for larger consolidators.

It is also a real technical claim which we haven’t proved yet.

There is also a counterargument sitting in plain sight. Small brokers already have ways to gain scale without selling. Networks and appointed-representative structures can provide insurer access, compliance support and shared services, while buyers such as Jensten and Clear do acquire smaller firms.

Owning the brokerage only becomes more powerful than networking it if ownership allows a deeper change. A network can negotiate capacity and share services. An owner can rebuild the operating system, migrate the data and force the same evidence layer into every acquisition. That is a decent answer, but it is still a claim we’d need to prove.

Migration isn’t the only constraint on how quickly we could do that. Acquiring control of an FCA-authorised broker requires notification and approval before the transaction takes place. Software may compress a data migration. It can’t compress the regulator in the same way. FCA approval is therefore at least a co-bottleneck and may become the actual limit on roll-up velocity.

There is an equally obvious way for the whole thing to go wrong. Roll-ups often borrow money against their supposedly predictable cash flows. Buy too aggressively, pay too much, lose a few important producers or fail to refinance the debt, and a safe-looking business becomes fragile remarkably quickly.

“To live, start by not dying” therefore cuts both ways. Buying profitable firms gives us a working base. Using their cash flows as an excuse to take stupid financial risks can destroy it.

The company only earns the right to move quickly once it can repeatedly buy, receive approval for, migrate and improve one brokerage without damaging the thing it bought.

That, at least, sounds cool enough to investigate further.

Not Every Business Is My Business

The rational case is much clearer to me now. Insurance brokerage is large, fragmented, profitable and held together by exactly the kind of messy information which LLMs are unusually good at reading. The roll-up gives the technology customers, data and revenue from the beginning. The technical layer could make a part of the acquisition market economic which larger buyers currently ignore.

I no longer think insurance is boring. Once you look past the forms and commissions, the broker is doing something fairly fundamental: turning a strange company and all the things which could destroy it into a risk somebody else is willing to carry.

I can also see the ceiling.

The more I’ve looked, the less comfortable I’ve become with the clean version of the pitch. The public data is weakest where we want to buy. Networks already offer small brokers some benefits of scale. The incumbent software companies own the existing workflow. Insurer agreements and FCA approvals resist the speed the model wants. Commission revenue moves with insurance pricing, and efficiency doesn’t automatically escape that cycle.

None of this kills the idea. Together, it makes it harder to pretend the opportunity is sitting there simply because nobody clever has noticed it.

In fact, I was able to make the rational case well enough that I was offered $50 million to found it. It was materially everything I thought I wanted: the money, the backing, the credibility and the chance to build something very large.

I said no.

The answer was simpler than the story I had built around it. I did not want to spend the next decade running an insurance roll-up.

I wanted to build a system which could get better at getting better. So I’m flying to San Francisco to figure it out.

That may turn out to be a worse business than insurance. It is at least the problem I want to wake up and work on.