Ambient agents
Most AI agents wait for someone to type a prompt. An ambient agent doesn't. It's always on, and events wake it: an email lands, a customer replies, a deadline gets close. It works on its own computer in the cloud, with a real browser and a handle in Slack, like a teammate who never logs off.
That changes the first question of every integration: do they have a public API? In insurance, the answer is almost always no. Carriers, wholesalers and premium-finance lenders run the industry on websites built for a person with a mouse, and while a few publish APIs that we still use, most don't. Almost everything after a quote, from binding and payments to cancellations and documents, sits behind a login.
So we stopped making APIs a bottleneck and built an agentic insurance harness: the tools, context and checks our agents need to work with a carrier, whether it publishes an API or only has a website portal. Where there's no API, we use computer-use agents that sign in and take actions the way a broker would. Since September 2026, an ambient agent has helped bring more than 200 small businesses current with their premium-finance lender, covering over half a million dollars in annual premium, and the lender has cancelled none of them. Underneath it: agents that explore a portal and write its types, an abstraction layer beyond APIs, and our own copy of every portal.
Agent exploration
The most difficult part of a portal isn't the clicking but knowing what its data means. A portal you click through is already an API client. Most portals we work with are single-page apps whose pages call private JSON endpoints, some of them GraphQL. Older ones post a form behind every server-rendered page. None of it is documented for brokers, but it's the same set of calls every click makes. Turning those calls into an API takes three stages.
Explore. A portal with no API still has to fetch the data for every page it renders. So a coding agent signs in through a real browser, like a broker would, and walks through the portal: find a policy, open its documents, check what's due. A recorder keeps the first response to each of those calls, plus the cookies the login left behind. When it gets stuck, it writes down where, and what would unblock it.
Learn. Recording a portal's calls gets you data, not meaning. To keep a copy we can trust, we have to know when something actually changed. So the agent reads all our records on the portal twice and compares them. If a policy looks different the second time, did the policy change, or did the portal just hand back a new download link? From those comparisons the agent learns which attributes we can anchor on: one that identifies each record on every read, and one that tells us when it changed. Anything that shifts on every read, like that download link, is noise we ignore.
Codify. What the agent learned only matters once code can rely on it. Every portal we read gets an API doc: its calls, what each returns, the attributes we anchor on and the noise we ignore. Then come the types, strict where it matters and loose enough that a field the portal adds tomorrow breaks nothing. A portal we act on also gets a small adapter, so our quoting engine can start a quote through our API without knowing which portal sits behind it. It's tested on recorded responses, never the live portal.
The abstraction layer beyond APIs
Our agents never ask whether a carrier has an API. They call ours, starting from what we already know about the business: our context layer. Behind each call, the harness picks the way in: the carrier's published API where there is one, and where there isn't, its portal, worked step by step or clicked through in a real browser, the way a broker would.
Most portals answer the same six actions: start a quote, apply answers, read its state, take an action, fetch documents, cancel. Everything specific to one portal, like what it can do and how its statuses map to ours, lives in a manifest. Adding a portal means writing that manifest and a thin adapter, never changing the core.
The API never trusts its memory of a portal. On a portal it clicks through, before each answer it checks what the live page will accept, it reads back every write, and it only takes an action when the page actually offers the button. When a request is missing something, it doesn't fail. It waits, with the fix spelled out, so we can fill in the answer and carry on.
Mirroring
Acting on a portal is one job. Knowing what's in it shouldn't need a login at all.
Once a browser has signed in, which is the one thing only a browser should do, the harness keeps its own copy of each portal as its context, one table per portal and kind of record. This week, more than a dozen portals landed data.
Under the hood:
- Context engineering. Each record lands as the portal sent it, with its history beside it, so an agent can see how a policy went from applied to bound without logging in.
- Ontology. The kinds of record we copy from each portal, and how they connect: applications, quotes, policies, cancellations and their notices, renewals, premium audits, and invoices and payment ledgers where a portal shows them.
- Canonical model. Our own model of accounts, policies and money is built on top of the copy, and reconcilers flag where the two disagree.
The portal stays the system of record for its own facts. Our docs put it plainly: downstream normalization must not become the only copy of partner truth. Every row records when it was first seen, last changed and last seen, so anyone can tell how fresh a fact is.
We plan from the mirror and act on the live page. People and agents query the copy instead of logging in, which saves logins, the scarce resource, for actions.
Premium rescue
Insurance has been hard to crack. It's an old, layered industry where every party runs a portal with no public API, and one integration per portal was more code than a broker could write and keep up. Exploration, types and an abstraction layer beyond APIs change that math.
- 200+ small businesses brought current with their lender
- 0 cancelled by the lender
- $500K+ in annual premium
Say a roofing contractor financed its annual premium, and the owner never set up an account with the lender, so they never saw a bill. That's the most common way these go wrong on our book. After one missed installment, the notice of intent to cancel arrives. Saving the policy takes three websites, none with a public API: the portal where it was placed, the lender's portal, and our own payment tools.
Like most of our work, rescues started by hand: people on our team worked these notices one at a time, against a cure date that doesn't move. Then we built them tools, and the tools helped. But our book grew faster than our team: by October we were binding more than four times as many policies a month as in January. Even with good tools, people can't keep up with that volume. That's why we think a brokerage has to be AI-run. So we wrote the workflow down as skills and gave them to an ambient agent in our harness, and we built the first version in about a day. The harness gives the agent what a rescue needs: our copy of each portal as its context, and the tools to act on the live page. When a notice arrives, the agent works the rescue through to the lender's confirmation, and a person on our team signs off before any money moves. If anything doesn't match, it stops and hands the job back.
Meet Grok Bot, the platform powering our ambient agents
Grok Bot is the harness our ambient agents run in. It runs our insurance back office and helps 6,000+ small to medium-sized businesses across America get the insurance they need to keep operating. Each bot gets what a new teammate would: skills that explain a portal and a workflow, and a trigger that wakes it. It doesn't need an integration to start. It needs the website, the skills and a reason to wake up.
The biggest bottleneck in insurance has always been that almost all of its work is unstructured: PDFs, emails, scanned forms and notes that a person has to read before anything happens. Ambient agents in Grok Bot read that work as it arrives and turn it into something they can act on. That's how our back office is becoming a team of agents that wake up when the work arrives, with our licensed agents watching over them.
If you'd like to work on ambient agents at Harper, we're hiring.
