How it is built
For whoever you ask to check this
The rest of this site is written for the person who authorizes the purchase. This page is written for the person they forward it to, so it goes into contracts, controls and infrastructure. Where something is unfinished or narrower than it sounds, it says so. Nothing here changes what the other pages claim, so it is safe to skip and send on.
The way in
Four ways your data gets in
Four sources today, all ending in the same place. A source nobody has connected yet — another carrier, a management system, a spreadsheet — is one piece of translation away, and nothing further down the line has to change to accommodate it.
A direct feed from your own systems
Your systems send policy and customer records straight in. Every request is checked, capped per agency, and safe to repeat — sending the same record twice does not create a second copy.
Carrier data pulls
Pulls from the carrier arrive as they finish — policies, claims, vehicles, drivers, and documents.
A browser add-on
Producers capture what is on a carrier portal screen where they already work, with no export and no file to hand over.
Outlook and Gmail mailboxes connect directly. Threads, attachments, and carrier notices land as records in their own right, not as loose mail.
Everything arrives in the same shape
However data reaches the platform, it is turned into one common format before anything reads it: where it came from, which agency it belongs to, the customer, their policies, their documents. Connecting a new source later means writing one piece of translation, not a second system.
Keeping the connection safe
Nobody can push data in pretending to be you
Six controls sit on the connection between your systems and the platform. Four are unconditional. Two are opt-in and marked as such: restricting to known addresses, and signed delivery of results, which only applies once you have given us somewhere to deliver them.
| The control | What it means |
|---|---|
| Every request is signed in | A secret key and an agency identifier travel with every request. The key is shown once when it is created and then kept only as a one-way scramble, so nobody can read it back out — including us. |
| Old requests are refused | Each request carries the time it was sent, and anything more than five minutes old is refused. That narrows the window in which a captured request is any use to someone. |
| Sending twice is safe | If the same record arrives a second time, the platform returns the first answer instead of loading it again. Retrying after a network problem cannot create duplicates. |
| Known addresses only, if you want it | An agency can list the network addresses its data is allowed to come from, and require that anything else be turned away. |
| A ceiling per agency | How much each agency can send is capped separately, so one agency cannot slow down another. |
| Signed replies back to you | When results are sent to your systems, each message carries a signature computed from a secret only the two sides know. Your side checks it before trusting anything in the message. |
A direct feed
Your own systems can send records straight in
If your agency already runs a management system, a portal, or anything else holding policy records, it can send them to the platform directly. You get an answer immediately that the record was accepted, and the analysis follows a short time later.
What travels with every request
X-Client-Secretsk_live_REDACTEDThe secret key. Issued once when the credentials are created, and never kept in readable form on our side.
X-Client-ID44444444-4444-4444-8444-444444444444Which agency this is.
X-Request-ID55555555-5555-4555-8555-555555555555A unique label for this request, so it can be traced later.
X-Request-Timestamp2026-08-17T12:00:00.000ZWhen it was sent. Anything older than five minutes is turned away.
Idempotency-Key66666666-6666-4666-8666-666666666666Reuse this label and you get the first answer back rather than a second copy of the record.
Loading your history
A large book goes in the same way a single record does
Loading years of existing business is not a special one-off exercise with its own risks. It uses exactly the same route as the traffic that follows it, which is why it can be done at whatever pace suits you.
Your history loads the same way live traffic does
Mailboxes can be loaded with their history
Analysis happens as the record lands
Results back out
Finished analysis is sent to your systems, not left for you to fetch
Each agency says where results should be delivered and which ones it wants. Nothing on your side has to sit there asking whether the answer is ready yet.
Customer-facing analysis finished
The analysis written for the customer is ready for a submission you sent in.
Producer-facing analysis finished
The analysis written for your producer is ready for a submission you sent in.
One route in
Every AI request goes through the same place
Not one clever integration per feature, which is how most of these systems end up. Model access runs through a small set of purpose-built gateways, and the vendor's own toolkit is confined to two files behind an internal interface, with an automated check that fails the build if it spreads.
The AI vendor is confined to two files
What it costs is measured
What the AI is given
It sees the whole client, not just the question
Ask a general AI tool about a client and it knows only what you typed. Before this platform answers anything, it gathers what it can reach about that client from the 10 places below. Nobody on your team picks which ones to include: every source that applies to the record is asked, and any that does not apply or cannot be reached is reported as such rather than silently skipped.
Every message, kept in its conversation.
The open conversation
The thread in front of the user right now.
Carrier records
Policy data pulled from the carrier.
Earlier analysis of carrier data
What the AI already worked out from those records.
Records you sent in
Data your own systems fed to the platform.
Findings
Gaps and risks already identified on the account.
History
What has happened to this customer, in order.
Your own guidance
Your procedures, carrier appetite guides, and internal rules.
Calendar
Meetings and scheduling.
Customer and policy details
Customer, account, policy, and carrier records.
That assembly runs the same way for analysis, whether it was triggered by the morning list or by an overnight job. Chat works differently on purpose: there each tool fetches what it needs as the conversation goes, and the assembler reports what was available rather than pre-loading it. A source that cannot be reached, or that does not apply to the record in hand, is named rather than quietly dropped.
Checking its work
Every answer shows what it was based on
The usual objection to AI in an agency is that nobody can tell where an answer came from. The platform computes, for every analysis, which sources were consulted and how fresh each was. A reviewer can open that today; presenting it properly in the interface is unfinished, and is named here rather than glossed over.
The AI is handed the whole picture
It works out what it read
Missing and out-of-date sources are named
Code decides the facts, the AI writes the answer
Coverage and freshness: what the analysis read, and what it could not.
Capture pending
Not locked in
You are not tied to any one AI company
A fair question about buying anything built on AI: what happens when the company supplying the models raises its price, changes its terms, or is overtaken by someone better?
The answer here is that the choice of supplier is kept in one small part of the code rather than spread through it. Changing suppliers is a contained job for your team, and it does not touch the insurance work, the safety checks, or anything your staff see.
Where it runs
Built on Microsoft Azure, end to end
Nothing homemade and nothing exotic. 7 managed Azure services, running in production today. After a handover the same setup runs in your own Azure account, on your bill, under your control, and the deployment configuration transfers with the code.
Azure Container Apps
Azure Cosmos DB for MongoDB
Azure Key Vault with Managed Identity
Azure Blob Storage
Azure Cache for Redis
Azure AI Search
Azure Container Registry
Keeping agencies apart
Two tiers of separation, and it is worth knowing which is which
The client book is separated physically. Platform metadata is separated by scope in a shared store. Both are deliberate.
Client data — pulls, policies, claims, documents, vehicles — resolves to a database per agency, reached through a scoped accessor. A defect in a query cannot return another agency's book, because that book is not in the database the connection is bound to. That is the tier where a mistake would be a breach, and it is the tier that does not depend on a filter.
Platform metadata — users, boards, settings, connections, audit entries — lives in one shared store and is scoped by agency on each query, which is the conventional model. It is enforced by convention and review rather than by the connection, so it is the tier worth auditing when your team takes the code over.
Each agency gets its own database, not a shared table with a filter on it.
Capture pending
Networks and aggregators
Each member gets a whole database, not a share of one
If you serve member agencies, this is the question they will ask you first.
The separation described above is what a network needs, because a network is asked this question by the members themselves — often by two members who compete with each other in the same towns. The answer a network can give is that the separation does not depend on the network operating the platform carefully. It holds because each member's book is somewhere the others cannot address.
Its own keys and its own feed
Add a member without a software release
Records and compliance per member
Each member keeps its own rules
Personal data
Where identifying data is removed, and where it is not
The models are run by an outside company, so it matters exactly what leaves. This is the honest version rather than the flattering one.
Chat: the message is always scrubbed
What a user types is tokenised before it leaves: identifiers are swapped for placeholders and mapped back in the reply, so the model works the problem without holding the person. Records the tools read back are tokenised using that same map, which means it applies when the question itself contained identifying details and not otherwise.
Analysis: detected and recorded, not removed
When the platform analyses a client record it sends that record. Personal data in it is detected and written into the audit entry for the call, so you can account for exactly what went where, but it is not stripped out. Coverage analysis on a de-identified record would not be worth reading.
Treat this as one control among several rather than a blanket promise. The ones doing the heavy lifting for client data are the per-agency database, the limit on what tools the AI may reach, and the logged fingerprint of every analysis. Whoever reviews this should weigh the model provider's own data terms alongside them.
Limits on the AI
It is fenced in before it starts
What the AI is allowed to do at all is decided in advance, in the software, and it cannot widen those limits itself.
Tool access is the control that is enforced hardest. When chat tries to use a tool, the request is checked against the list it is permitted before anything executes, so the model cannot reach a capability it was not handed.
The supervision layer around analysis is the more configurable half: it validates and records runs and can be tightened per agency, and it is switched off by default. Extending it to sit in front of every model call is a well-shaped piece of work for whoever takes this over, and the seams for it already exist.
The record
Nobody has to reconstruct what happened
Built for the day a regulator or an internal auditor asks how a particular decision came about.
Each analysis records the model that ran it, the tools it used, the tokens and the cost, and a one-way fingerprint of what went in and what came back. That is written as it happens rather than pieced together later.
Note what is deliberately not kept: the wording itself. Storing a fingerprint proves later whether a given input or output is the one that was used, without parking client details in a log. If your obligations require retaining the full text, that is a change to make on your own terms after handover rather than a default we made for you.
Every AI action, recorded with the model that ran it, what it used, and what it cost.
Capture pending
The compliance center
Somewhere to actually run the compliance work
Impact assessments, a tracked requirement set and retention records live inside the product rather than in a spreadsheet kept off to the side. This is also the least finished area of the platform, and the one where a buyer with a specific regulator in mind will want to build most.
Impact assessments
Keeping records
Regulatory requirements
Every requirement you are tracking, its status, and what is due next.
Capture pending
An impact assessment per use of AI — the document a regulator asks for by name.
Capture pending
Bias tests, run and recorded, with results you can hand over.
Capture pending
What is kept, for how long, and what has already been archived.
Capture pending
This is the part almost nobody builds until a regulator asks, and then it is a scramble. It is already here, and it transfers to you with everything else.