Part 3 of 3How 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 — and in four places it narrows what the earlier parts claim, which is the point of reading it. It is written to be forwarded.

The way in

Four ways your data gets in

Four sources today, all ending in the same place. A source nobody has connected yet — a management system, a spreadsheet, another agency's export — is one piece of translation away, and nothing further down the line has to change to accommodate it. A network whose members all run the same management system does that translation once, after which every member is connected by the same route.

A direct feed from your own systems

Your systems send policy and customer records straight in, for any client or lead, with no supplier to sign up with and nobody to ask first. Every record says which of your systems it came from, and saying so is required rather than optional. Every request is checked, capped per agency, and safe to repeat — sending the same record twice does not create a second copy. Where your agency has the AI switched on, what it made of the record comes back in the same reply.

Carrier data pulls, with the consumer’s permission

Policies, claims, vehicles, drivers and documents arrive as each pull finishes. The pull is made by Canopy Connect with the consumer’s permission — this platform does not hold connections of its own to carriers. It needs both an agency that runs Canopy Connect and a client who consents, so it covers part of a book rather than all of it, and reaches no leads.

A browser add-on

Producers send a submission across from the Canopy dashboard they are already working in, with no export and no file to hand over.

Email

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. Five are unconditional. One applies once you have given it somewhere to deliver results: restricting to known addresses, and signed delivery of results, which only applies once you have given it 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 whoever runs the platform.
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	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 rating platform, a CRM or anything else holding policy or prospect records, it can send them to the platform directly — for any client or lead, with no third-party supplier and no consumer consent step. You get an answer immediately that the record was accepted, and where the agency has AI enabled the analysis comes back on that same response.

What travels with every request

X-Client-Secretsk_live_REDACTED
The secret key. Issued once when the credentials are created, and never kept in readable form on the server.
X-Client-ID44444444-4444-4444-8444-444444444444
Which agency this is.
X-Request-ID55555555-5555-4555-8555-555555555555
A unique label for this request, so it can be traced later.
X-Request-Timestamp2026-08-17T12:00:00.000Z
When it was sent. Anything older than five minutes is turned away.
Idempotency-Key66666666-6666-4666-8666-666666666666
Reuse this label and you get the first answer back rather than a second copy of the record.

What you sendIllustrative example

"source_system": "ams",

"pull_id": "11111111-1111-4111-8111-111111111111",

"first_name": "Clark",

"last_name": "Kent",

"email": "clark.kent@example.com",

"insurance_provider_name": "Daily Planet Mutual",

"team_id": "22222222-2222-4222-8222-222222222222",

What comes backIllustrative example

"success": true,

"submission_id": "77777777-7777-4777-8777-777777777777",

"consumer_id": "88888888-8888-4888-8888-888888888888",

"pull_id": "11111111-1111-4111-8111-111111111111",

"timestamp": "2026-08-17T12:00:01.234Z",

"message": "Policy data received and processing started"

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

Replaying years of records uses the same route as everyday traffic, with the same checks applied to each one, so a historical load is not a special case with risks of its own.

Mailboxes can be loaded with their history

A connected mailbox can be filled in backwards rather than starting from the day it was linked.

Analysis happens as the record lands

When a record arrives at an agency with AI switched on, the analysis runs as part of accepting it, so what comes back already reflects the new data rather than catching up later.

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.

These deliveries carry the signature described in the controls above. The one thing your side has to do is check that signature before acting on a message — anything that fails the check did not come from the platform and should be thrown away rather than processed.

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

The model vendor’s own toolkit appears in exactly two files in the entire codebase, both behind an internal interface, and an automated check fails the test suite if it spreads anywhere else. Model calls run through a small set of purpose-built gateways rather than being scattered through features.

What it costs is measured

Model calls record what they used and what they cost, and those figures can be queried per agency. Putting a dashboard on top of them is one of the more obvious first things to build.

Which model serves which tier of work is fixed in configuration rather than picked at run time. A planning step can escalate a hard request to a higher tier, but it cannot change what that tier is allowed to do. That containment is the part worth checking: an inventory script walks the codebase on every build and fails it if the vendor toolkit appears outside the two files it is allowed in. Swapping suppliers is therefore bounded work rather than an archaeology project.

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

Before any analysis runs, the platform gathers everything it can reach about the customer in question, rather than working from whatever happened to be typed into the question.

It works out what it read

For every analysis the platform computes which sources were consulted and how fresh each was. A reviewer can open that on a result today; surfacing it fully in the interface is unfinished, and is exactly the kind of thing a new owner finishes first.

Missing and out-of-date sources are named

If something could not be reached or is out of date, the result says so rather than quietly leaving it out — the difference between an answer you can check and one you have to take on faith.

Code decides the facts, the AI writes the answer

Which sources get read, how a person is matched across records, how fresh that data is, and the shape of the output are all settled by code. The AI writes the analysis on top of them.

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.

That matters most if your organisation has already picked a direction. If your own AI strategy points at a model service running inside your own cloud account rather than at the one used here, that seam is exactly where it would be substituted — work against a defined interface, sized in weeks, rather than a rebuild.

Which company supplies the models is confined to one small part of the code. Anthropic runs it today, and moving to another supplier later is a contained job rather than a rebuild.

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 model calls go on your own account with the provider, at their prices, with nothing routed through me, and the deployment configuration transfers with the code.

Azure Container Apps

Runs the applications and every scheduled job, scaling on demand. No servers to patch and no virtual machines to babysit.

Azure Cosmos DB for MongoDB

A managed database service, holding one separate database per agency.

Azure Key Vault with Managed Identity

Every password, key and token lives in Key Vault and nowhere else. The application proves who it is to Azure using a managed identity, so there is no master password sitting in a config file for someone to find.

Azure Blob Storage

Documents, declarations pages and anything the platform generates.

Azure Cache for Redis

Queues, short-lived state, and the check that stops a repeated request being processed twice.

Azure AI Search

Search across the agency’s own documents, matching on both exact wording and meaning.

Azure Container Registry

Every release is built, tested and published to the registry by an automated pipeline. Nothing reaches production by hand.

No secret is ever stored in the code. Every key and password is held in Azure Key Vault and loaded when the application starts, using a managed identity so that Azure itself vouches for the application rather than a password doing it. There is no bootstrap credential in the repository to find.

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, and the difference matters when your team audits this.

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. The mapping from agency to database is looked up rather than calculated, so no code path can guess its way into the wrong one.

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. I would rather tell you that now than have you find it.

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.

What the screen beside this shows is the administrative half of that: members are set up and run one at a time, each with its own credentials, its own data connection and its own switches, and bringing on another is an action a person takes in the product. The database boundary underneath it is not something a screen can show you — it is a scoped accessor in the code your team inherits, and it is the first thing worth reading when they take this over.

An admin-only agency management screen listing three member agencies with their names and distinct short codes, each row carrying its own credentials, its own data connection status, its own settings switches set differently from the others, a status and the date it was created, beside an action to add another agency — Member agencies are set up and run one at a time: three here, each with its own short code, its own Canopy Connect credentials and connection, and its own settings — the switches are set differently from row to row. Adding another is an action on this screen rather than a software release.

Its own keys and its own feed

Each member gets its own keys, its own ceiling on how much it can send, and its own address for results, so one member’s connection cannot disturb another’s.

Add a member without a software release

Bringing on a member agency is setup, not a release. Its database, its collections and its starting boards are created for it, and its branding and users are configured after that.

Records and compliance per member

The record of AI activity and the compliance status belong to the member agency, so each one can answer for its own automated decisions.

Each member keeps its own rules

Carrier appetite guides, procedures, and the prompts the AI follows belong to the member agency. Members do not inherit one another’s.

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.

If de-identified model calls matter to you, this is contained work rather than new capability: the scrubber and its token map already exist and are wired into chat. Making the map unconditional, and extending it to the analysis path, is the shape of that change.

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 I made for you.

An AI activity log listing 127 activities for the week — chat answers, client analyses and email insights — each row naming the tools the action used, how sensitive it was rated, a safe status and a timestamp, with filters for time range, type, status and risk and a download report action — Every AI action the agency ran, 127 of them this week: what kind of work it was, which of its tools it used, how sensitive that made it, whether it came back clean, and when. Filter it, or take the whole thing away as a report.

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

A structured assessment per AI use, which you can export.

Keeping records

A record of what is retained and for how long, which your team extends into whatever your state actually requires.

Regulatory requirements

A tracked list of requirements with status and deadlines, and a rules catalog to check against. Wiring every rule to live data is where a new owner picks it up.

The compliance records area of the AI center, listing eight categories — fairness checks, AI data exposure, a compliance checklist, an AI transparency statement, AI tool reviews, AI technology partners, regulatory reports and an AI tool inventory — each with a one-line description and each collapsed — The eight things you are expected to be able to produce, kept in one place and built as your staff use the AI: fairness checks, where your data goes, the safety checklist, the statement for your own website, reviews of the tools, who the technology comes from, the reports a state insurance department may ask for, and a list of every AI feature you run.

This is the part almost nobody builds until a regulator asks, and then it is a scramble. The surfaces, the exports and the record are here and they transfer with everything else; wiring them to your own state’s rules is where you pick it up.

See it running, then have your people read the code

That is the whole evaluation. Watch it work on real insurance data, then let whoever you trust technically go through what they would be inheriting.

Book a walkthrough