← Writing
5 min read

When both sides of the API are agents

A broker gets a submission. To shop it, they key the same information into four different carrier portals, each with its own login, its own fields, its own quirks about how you write a date. Same data, four times, by hand. Then they wait, collect the quotes, and re-key the winner into their own system. Most of insurance back-office work is this: moving structured information between parties who can't, or won't, agree on a wire format.

We have tried to fix this before, and the history is worth knowing before you get excited about agents fixing it. Independent agencies spent decades chasing something called SEMCI, single-entry multi-carrier interface. Type the risk once, quote it everywhere. The standard to do it has existed since the 1980s, ACORD's AL3, and there's a 2004 trade-press article with the wonderful title "Desperately Seeking SEMCI." The schema was there for forty years. It still didn't happen. Not because the format was hard. Because carriers had no particular reason to make themselves easy to compare side by side. The friction wasn't a bug. For the party that owned the quote, it was the product.

So I'm suspicious of anyone who says agents make integration free and therefore the walls come down. The walls were never really about integration cost. Keep that in your pocket. It changes what's actually new here.

Two rows. Today: a broker re-keys the same submission into Carrier A, B, and C portals by hand. When both sides are agents: a broker's agent and a carrier's agent exchange capabilities and a schema in a single signed handshake, with no portal in between.
The portal was a place to re-type things. When both ends are agents, the schema is the thing.

What's new is that both ends are becoming machines that can negotiate. When the broker's side is an agent and the carrier's side is an agent, onboarding stops being "go create an account and learn our form." It becomes capability negotiation. Google's Agent2Agent protocol makes this concrete with something called an Agent Card: a machine-readable manifest of what an agent can do and how to ask it. That's the same idea as an ACORD field dictionary, except the counterparty reads it in a second instead of a quarter. The onboarding call becomes a handshake.

And the contract changes shape too. Google's follow-on payments protocol leans on signed "mandates," intent and cart and payment, expressed as verifiable credentials, so a settled cart is an executable, cryptographically signed artifact rather than a PDF a human squints at. A contract becomes a schema. In insurance terms, a bound quote stops being an email attachment and becomes a signed object both agents already agree on the shape of.

The part that actually moves

Ben Thompson wrote the demand-side version of this in a piece on software survival: per-seat SaaS starts to wobble when the "seats" are agents doing the work, because you priced by human identity and the humans are thinning out. That's the money question, who pays and how. I care about the wire question underneath it. When the cost of one system talking to another falls toward zero, the moat stops being "we already have the integration" and starts being "we have the customer." Integration was a wall. Agents are a ladder anyone can carry.

Which is exactly why SEMCI is the right ghost to keep in the room. The blocker there was incentive, and agents don't dissolve incentive. A carrier that didn't want to be easy to compare in 2004 still doesn't want it. What agents change is the cost of routing around that reluctance. When your agent can read any carrier's Agent Card and drive their flow, the carrier's refusal to build the nice integration stops protecting them. The leverage slides to whoever holds the relationship with the person who actually needs coverage.

I can hear three objections, and they're good ones.

The first: this is ACORD with an LLM sticker on it, and we've had machine-readable insurance schemas for forty years without brokers disappearing. Right, and I said as much. The difference isn't a new schema. It's that the schema no longer needs the counterparty's cooperation to be useful, because an agent can consume a clumsy portal as if it were a clean API. The economics shift even when the incentives don't.

The second: trust and liability don't schematize. When a broker's agent binds coverage the client never wanted, a JSON blob does not go in front of the regulator. Someone's errors-and-omissions policy does. True, and it's the part that stays human. The accountable envelope, who is responsible when it goes wrong, doesn't automate. The plumbing between accountable parties is what automates. Those are different layers and it's worth not confusing them.

The third: you don't want a stochastic, hallucination-prone agent negotiating a binding contract. Also true, and it's the strongest reason the schema layer matters rather than the reason it doesn't. The standards that reshaped back offices worked because they were rigid. FIX did it for equities trading in the nineties, SWIFT for interbank messaging before that. A bound rate is a bound rate, no interpretation. The agent gets to reason, sloppily and creatively, right up to the wire. The wire format is deterministic and signed. The agent proposes. The schema disposes.

The back office was always a protocol problem wearing a headcount costume. We staffed it with people because the parties couldn't agree on a format and someone had to sit in the gap and retype. That gap is what's closing. When both sides are agents, the portal was never the product. The relationship was, and it's the only thing that doesn't reduce to a schema.

Comments