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.

The working list with ten open items ranked by score, each with an owner, overdue flags, the carrier and where it arrived from, and one client open beside it showing findings, next actions and a drafted email
The list your producers open to: every open piece of work ranked, with its owner, what is overdue, the carrier, and where it arrived from — and the client you pick open beside it, with what the AI found, the four things worth doing next, and a reply already written.

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

The key findings the AI drew from one client record: that only a boat policy is on file and no auto, home, renters or umbrella coverage is present; that a $500,000 combined single limit is solid but leaves the client exposed above it without an umbrella policy; that two operators hold licences in different states and the carrier should confirm both are rated; and that medical payments and on-water towing are common boat endorsements not visible in the data
The same reading, in the industry’s own vocabulary: a solid liability limit with nothing above it, two operators licensed in different states, and boat endorsements that are common and are not on this policy. This is what a general-purpose AI tool has no idea to look for.

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
Everything in the top row was built on everything in the bottom row — and so is whatever you build after you own it. The six are worth having. The layer under them is what you are buying.

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 connectionsData 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 analysisIdentifying 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 worseThere 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 platform your staff work in every day, a customer-facing app your clients use, and the public website.

The whole AI layer

Everything that reads your data and produces answers, including the insurance-specific tools it uses and the safety checks around them. Not a wrapper around someone else’s chatbot.

Every connection already built

Carrier data, email, documents, and a way for your own systems to send information straight in.

The compliance and audit side

Records of what the AI did, assessments, and retention tracking — the parts most people forget to build until a regulator asks.

The tests that prove it works

Thousands of automated checks your team can run whenever they change something, so they know straight away if anything broke.

The documentation

How it is built, how to run it, how to deploy it, and the reasoning behind the decisions — written down, not locked in someone’s head.

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

Your client book — the policies, claims, documents and carrier pulls — sits in a database of its own rather than in shared tables. Every request that touches it is tied to one agency before it runs.

Personal details are handled deliberately, and the handling is recorded

In chat, identifying details are taken out of what a user types and out of the records it reads back, before anything goes to the AI model. When the platform analyzes a client record it works on that record, and it writes down exactly what personal data was involved in every call.

The AI can only use the tools it was given

Every time chat reaches for a tool, the platform checks it against the list that request is permitted before anything runs. Analysis goes through a separate supervision layer that can be tightened per agency.

AI activity is logged, with content fingerprinted rather than stored

Analysis records the model, the tools used, the tokens and the cost, plus a one-way fingerprint of what went in and what came back. That settles later whether anything changed, without keeping client wording in the log.

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. 1. Does it fit how we already build

    Depends on you, not on us

    End 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. 2. What do we actually own

    Partly, with limits named

    All 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. 3. Is the security model sound

    Partly, with limits named

    Each 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. 4. How far can we extend it, and who has to do it

    Answered

    Three 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. 5. Can we move it later

    Answered

    It 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. 6. Do we get the source, and can we change it

    Answered

    Every 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. 7. What does it depend on that we do not control

    Partly, with limits named

    Two, 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. 8. Who runs it once it is ours

    This one is yours

    You 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. 9. What does it cost over its life

    Partly, with limits named

    What 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. 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. 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. 3

    Handover

    The code, the documentation, the deployment setup, and the written procedures all transfer to your accounts.

  4. 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.

Chris Marcus · Fractional CTO & AI Architect