Part 1 of 3The offer
For agency owners, principals, and network executives
It already works. And you own every line of it.
agentCanvas is a finished AI platform for insurance agencies, running today on real policy data. Your team can start working in it straight away — there is nothing to build first.
And you receive the whole thing: all of the source code, running on your own systems, yours to change however you like. The finished platform, handed over — instead of the years and the engineering payroll it would take to build one.
I build platforms and hand them over. Running a software company was never the plan — that was settled before the first line of code. More on why it is for sale.
What it is
Start here: this is the product
This is the software your producers and service staff would open every morning — their clients, their renewals, their carrier mail — with AI already doing the reading.

Every open piece of work sits in one list — the client it concerns, who owns it, the carrier, and what is already late. Your staff already know how to read this. Nobody needs training in AI to use it.
The difference from the system you have now is that the AI has already been through every record — so the account that needs a call today is at the top, the reason is written underneath it, and the reply is drafted before anyone opens the file.
Built for one industry
It was built for an independent agency, not adapted to one
This is the difference between software that knows what an endorsement is and software you have to explain it to. Nothing here was generalized for other industries and trimmed down to fit yours.
A column for each line you write — auto, home, umbrella, rental, life, commercial
Carrier mail understood as what it is: a renewal, a cancellation, an endorsement, an audit, a billing notice
Coverage read properly — limits, deductibles, replacement cost, uninsured motorist, open and closed claims
Producers, agents, and service staff treated as different jobs, because they are
Your carrier appetite and your commission plan, applied as written

That briefing is the tell. A general AI tool can summarize a document. It cannot tell you that a household carrying this much premium on a single line has no umbrella over it, that the client is licensed in two states and the exposure follows them, or that the town they live in is one you have already said you want more of. That knowledge is the part that took years.
What you get, and where you take it
Version one is finished. Version two is yours.
This is the point of buying a platform rather than a product. The modules below are finished, and your team can use them as they stand. The layer underneath them is what makes the next one yours to build — with your data, for the way your agency actually works.
Working on day one
Clients scored
Every client you connect, ranked with its reasoning attached
Coverage review
One reading, written twice — for the producer and the client
Carrier mail, sorted
Read and matched to the right client on arrival
The client app
Your clients connect their own carrier, under your name
Chat on your records
Answers from your policies and your own documents
Prompts your staff write
New AI work without a developer
Whatever you build next
Your lines, your rules, your data — built the same way as the six above
The platform underneath — what actually changes hands
- Connections in — permissioned carrier pulls, mailboxes, your own systems
- Everything arrives in one shape
- The whole client assembled before anything runs
- One controlled path for every AI request
- Safety checks, and limits on what it may do
- A record of every AI action
- A separate database for every agency
In version one
Finished, running, yours on day one
- Two working applications: the one your staff use and the one your clients use, with your admin settings inside the first
- Every client you connect scored and ranked, with the reasoning written underneath the account
- A producer briefing and a client-ready coverage review, written from the same reading
- Carrier mail read, classified and matched to the right client on arrival
- Chat with 53 tools built for insurance work, answering from your own documents
- The whole customer picture gathered from 10 sources before any analysis runs
- Scoring weights, carrier appetite, writing style and AI autonomy, all set by your own admins
- Compliance and audit surfaces, and one separate database per agency
What you build on it
Your data, your use cases, your roadmap
- Point it at the parts of your book I have never seen, including commercial lines and any data your systems already hold
- Write prompts for the work only your agency does, and have them run automatically on every new record
- Add the carriers, systems and feeds specific to your markets
- Build your own analysis on top of the same data and the same safety checks
- Change anything at all, because your engineers have the source code
Most of the second list needs no engineer at all. Your admins write the prompts and set the rules inside the product. The rest is open to your developers, because the source code comes with it, and nothing about that depends on me.
The problem, and the alternative
Every agency already owns the information it needs
It is in the declarations pages, the carrier mail and the claim histories, and nobody has the hours to read all of it on every account. The renewal nobody called. The umbrella nobody wrote on a household that plainly needs one. The named insured that does not match the client. These are not knowledge problems — your people know what to look for. They are reading-volume problems, and that is the kind of problem this solves.
Which leaves two ways to get there. Buy the platform that already reads all of it — Part 2 shows one of these findings caught on a real record — or build it. Building it means the work below, and almost none of that work is insurance work.
What comes before a single useful answer
- Connections to permissioned carrier pulls, mailboxes and your own systems — and the work of making all that data look the same
- A way to recognize the same person across policies, email threads, and documents
- One controlled path for every AI request, with retries, streaming, and cost tracking
- A record of every AI action that a regulator would accept
- The insurance knowledge itself — coverages, endorsements, claims, carrier appetite
And what is still yours to finish
- Direct carrier and portal connections — Data arrives through permissioned pulls, your own systems and your mailboxes. Wiring a carrier or a portal directly is credentialing and a commercial agreement, not just code, and none of it is built.
- Removing personal details before analysis — Identifying data is removed on the chat path. On the analysis path it is detected and recorded but not stripped, which Part 3 sets out in full.
- A way to tell whether a change made the AI better or worse — There is no evaluation harness. Every AI action is recorded in a form one could read from, which is the hard half, but the harness itself is yours to build to your own risk appetite.
Part 3 says where each of these stands, in more detail than this page has room for.
What you receive
Everything, including the code
Everything below transfers to you: the working applications, the code behind them, and the material your team needs to run and extend it without me.
Two working applications
The whole AI layer
Every connection already built
The compliance and audit side
The tests that prove it works
The documentation
And it becomes your property
This is a purchase, not a rental. Once it is yours, nothing about running it depends on me still being here.
- You get the source code
- Every line. Your team can read it, change it, and build on it without asking anyone’s permission.
- It runs on your account
- Your cloud, your databases, your storage. Your client data never has to sit with a vendor.
- Your roadmap
- You decide what gets built next and when. No waiting on someone else’s release schedule, no feature requests disappearing into a queue.
- No dependency on me
- Nothing stops working if I walk away. There is nothing to renew and no service you have to keep buying.
How much is already built
The size of what changes hands
These are counts, not estimates — taken from the working code on 23 August 2026. They are here because the honest question about any platform is whether it is a real one.
- 335,000
- lines of code
- 1,425
- source files
- 281
- server routes behind the two applications
- 7,345
- automated tests
- 547
- written documents and guides
The tests and the written material are the two that matter most to whoever inherits this. The tests are how your team will know, in minutes, whether a change they made broke something. The written material is how they will find out why a decision was made without having to ask me.
And what it would take to arrive here from nothing
131 engineer-months of engineering, or 18 to 24 months with a team of six to eight — before any of it is insurance work. Estimated bottom-up across twenty-three modules, each one anchored to code that is in the repository. It is what the work in front of you represents, not what it cost to produce.
Safe to hand a regulator
One system, many agencies, and none of them can see each other
Software like this runs one copy that serves every agency at once. That is normal, and it is what lets one deployment serve every member agency. The question is how the data is kept apart, and there are two ways to do it.
The usual way
The usual approach puts every agency's records in the same tables and trusts the software to filter by agency on every request. It works until one query forgets.
The way this is built
Your client book gets a database of its own. The policies, claims, documents and carrier pulls are not in the same place as another agency's, so for the data that actually matters the separation is physical rather than a filter someone has to remember.
That shape is also why a network fits this cleanly: an aggregator is many agencies at once, and every member's book stays its own.
A separate database for every agency
Personal details are handled deliberately, and the handling is recorded
The AI can only use the tools it was given
AI activity is logged, with content fingerprinted rather than stored
Settings that are not client data — your users, your boards — sit in one shared store separated the ordinary way. That tier is the one worth auditing when your team takes the code over.
The whole platform runs on Microsoft Azure, using its managed services for hosting, storage, search and secrets. Every password and key lives in Azure's own vault rather than in the code.
That is the short version, and it is here because a principal should not have to read an engineering page to know their members are kept apart. Part 3 has the rest.
Why a network would want to own it rather than rent it
What an aggregator sells its members is capability they could not buy alone. Owning this lets you put an AI platform in front of every member agency under your own name, with each member keeping its own rules, its own carrier appetite, its own compliance record and its own book — and without paying per member for it forever, or asking your members to trust their client data to a third party you do not control. Adding a member is an action someone takes in the product, not a release.
How to judge this
Nine questions worth asking, including the ones this answers badly
Anyone evaluating something like this arrives with roughly the same list. Here they are answered together rather than scattered across three pages — and six of the nine come back only partly, or not yet, or that part is yours. Those are the useful ones.
1. Does it fit how we already build
Depends on you, not on usEnd to end on Microsoft Azure — containers, database, secret storage, files, cache and search — and after handover the same setup runs in your own account. The one part that is not Microsoft is the AI supplier, kept to a single seam so it can be changed.
2. What do we actually own
Partly, with limits namedAll of it, outright, with nothing to renew and no part you keep paying for. What has not been done is a formal review of the licences on the open-source pieces underneath — normal diligence, and yours to run before you sign.
3. Is the security model sound
Partly, with limits namedEach agency gets a database of its own rather than a share of one, so a mistake in a query cannot reach another agency’s book. Everything sent in is checked and capped per agency, and every AI action is recorded. One tier is weaker than the rest, and Part 3 names it.
4. How far can we extend it, and who has to do it
AnsweredThree levels. Your staff change the instructions the AI follows, in the product, with no release. Your developers change anything at all, because they have the source. No level requires us.
5. Can we move it later
AnsweredIt runs in your cloud account, not ours, so there is nothing to move out of. The AI supplier sits behind one seam and can be swapped — including for one inside your own account — as contained work rather than a rebuild.
6. Do we get the source, and can we change it
AnsweredEvery line, with the tests that tell your team whether a change broke something and the written material explaining why decisions were made. This is the one answered most completely, and the reason the rest can be answered honestly.
7. What does it depend on that we do not control
Partly, with limits namedTwo, named rather than buried. An AI supplier, substitutable and running on your account. And for permissioned carrier pulls only, a service your agency signs up with separately — which is why that route is one of four. Everything else, including records from your own systems, has no outside dependency.
8. Who runs it once it is ours
This one is yoursYou do, and that is the honest answer rather than a soft one. Releases are automated and nothing reaches production by hand, so the machinery is built — but the people are yours: whoever watches it, whoever answers a producer at four in the afternoon, whoever brings each new agency on. Handover support is defined and finite, not a condition of the software working.
9. What does it cost over its life
Partly, with limits namedWhat you pay us ends at the purchase. The running cost is what your cloud provider and AI supplier charge you directly — nothing routed through us, nothing marked up. What the platform gives you is control: every piece of AI work is costed as it happens and readable per agency, work is sized before it runs with a ceiling it will not cross, and the AI is off for an agency until you switch it on.
And one more, because it is the question this answers worst
How would you tell whether a change made the AI better or worse? There is no test harness here and it should not be claimed. What exists is the harder half: every AI action is already recorded in a form something could read from. Most organisations buying a foundation like this are already choosing a separate service for testing and monitoring models — this is what that would run against, not a replacement for it.
And buying a foundation is one option among several, not always the right one. If a common workflow is all you need and speed matters more than owning it, ready-made software is the better answer. If your rights to your own data are unresolved, or nobody is free to run it, the answer is not yet. This is worth buying when the workflows are yours, the members have to stay separate, and a full build is more than the problem deserves.
How it happens
Four steps, and your people see the code before you sign
No stage asks you to take anything on trust. Your own technical team reviews what they are inheriting while you can still walk away.
- 1
See it working
I walk your team through the running platform against real insurance data, so you know what you are buying before anything is signed.
- 2
Your team looks under the hood
Your technical people get access to review the code, the tests, and the documentation, and to ask whatever they want.
- 3
Handover
The code, the documentation, the deployment setup, and the written procedures all transfer to your accounts.
- 4
Your team takes it from here
I stay available through the transition while your people get comfortable, then it is yours to run. If you want me involved after that, it is a separate arrangement rather than a condition of anything.
The obvious question
Why a finished platform is for sale
Because building it was the point. I am a fractional CTO, and twice before I have been the CTO who built a company's core insurance platform from nothing — at Polly, and at Veruna — and both times the object of the exercise was that their own people ran it afterwards.
The difference here is that nobody commissioned this one. I built it on spec, at my own risk, which is why you get to look at a finished platform before you pay for it instead of funding a team for two years and hoping — and it is why the handover reads the way it does.
The right owner is an agency network whose technical people want the source and intend to keep building on it.
You would be the first to run this. That is why the evaluation starts with your own engineers reading the code and the tests rather than with a reference call — you are checking the thing itself instead of somebody else's opinion of it.