Systems · Kivara
Design partnerPut AI agents to work without putting your licence at risk.
One wrong sentence from an assistant in a licensed conversation is not a support ticket. It is a complaint with your licence number on it. Kivara is the design-partner system for that exact edge: a governed front door in front of the CRM you already run, where the assistant answers only from text a person approved and the regulated act stays with the person licensed to perform it. Medicare and insurance agencies first, virtual care next, lending later. Specified and reviewed across three model families, not built. We build it with the first customer.
Design-partner conversations start the same way as every other one: we measure your operation before we propose anything.
The problem
The hard part is not what the agent can do. It is what it is allowed to say.
Your team already knows the feeling. A question that takes eight seconds to answer, sitting next to a rule about who is permitted to answer it. Most of the work in a regulated business is not the regulated part at all — it is intake, follow-up, reminders, paperwork, the fourth attempt to reach somebody before a deadline. It is still done by hand because it sits close enough to the regulated part that nobody wants to be the one who automated it.
The generic agent platforms answer this by telling you to be careful. The agent gets a login, a pleasant tone and no idea which sentence ends a career. The rules are a paragraph in a prompt, which is to say they are a suggestion made to a system that is optimised to be helpful.
In your industry, the rule table already exists. Somebody else wrote it.
The argument
The regulator already wrote your risk-tier table.
In health, insurance and lending, the rules already sort every action into four bins: what software may do on its own, what it may do if the output is checked by a person, what a person must approve, and what only a licensed person may do. Nobody in your compliance department calls that a risk-tier table. That is exactly what it is.
A generic agent platform leaves you to discover those bins the hard way, with a regulator reading the transcript. Kivara is designed the other way round: the table is filled in per module before anything is built, and the runtime underneath is the thing that enforces it, not the prompt. Where each line falls in your business is confirmed with your compliance counsel, and because the specifics change every plan year the table is a versioned object — changing it is itself a governed action with a reviewer and a preview of what it affects.
| The bin the rules put it in | Typical actions | Tier | What the design does |
|---|---|---|---|
| Software may do it alone | Look up, log, summarise, prepare the paperwork | T0 | The assistant reads the record and prepares the work. Nothing leaves the building and nothing is committed. |
| Software may do it if the output is checked | Answer a consumer’s question in writing | T1 | Answers would be selected from text a person approved, not generated. No approved answer means no answer: the conversation goes to a person. |
| A person must approve it | Reach out to a consumer; change what their record says | T2–T3 | Outreach is gated on a consent record and the gate is designed to fail closed. The agent prepares; a named person sends. |
| Only a licensed person may do it | Advise, recommend, quote, submit | T4 | The system would prepare the brief and the paperwork. The licensed person performs the regulated act. An agent never submits. |
| Changing the rules is itself an action | Edit the rule table, widen what may be said | T5 | The rule table is a versioned object. Changing it is reviewed, recorded, and previewed for what it would affect before it takes effect. |
- The bin the rules put it in
- Software may do it alone
- Typical actions
- Look up, log, summarise, prepare the paperwork
- Tier
- T0
- What the design does
- The assistant reads the record and prepares the work. Nothing leaves the building and nothing is committed.
- The bin the rules put it in
- Software may do it if the output is checked
- Typical actions
- Answer a consumer’s question in writing
- Tier
- T1
- What the design does
- Answers would be selected from text a person approved, not generated. No approved answer means no answer: the conversation goes to a person.
- The bin the rules put it in
- A person must approve it
- Typical actions
- Reach out to a consumer; change what their record says
- Tier
- T2–T3
- What the design does
- Outreach is gated on a consent record and the gate is designed to fail closed. The agent prepares; a named person sends.
- The bin the rules put it in
- Only a licensed person may do it
- Typical actions
- Advise, recommend, quote, submit
- Tier
- T4
- What the design does
- The system would prepare the brief and the paperwork. The licensed person performs the regulated act. An agent never submits.
- The bin the rules put it in
- Changing the rules is itself an action
- Typical actions
- Edit the rule table, widen what may be said
- Tier
- T5
- What the design does
- The rule table is a versioned object. Changing it is reviewed, recorded, and previewed for what it would affect before it takes effect.
This is how the design is organised. It is not a statement of what any particular rule requires today, and it is not legal advice. Regulatory specifics change every plan year; your compliance counsel and the programme documents govern, never this page.
Three modules
Start at the front door, where enquiries go cold.
Each module is a design: the rule table, the interfaces and the workflows are written and reviewed. None of them is running for a customer today, and the order below is the order we would build them in.
Enroll-Ready
Design partnerInsurance and Medicare agencies
The front door: the enquiry, the consent, the conversation and the handoff to the licensed person.
The design covers
- Lead intake and an assistant that answers only from approved text
- A consent ledger with a send gate designed to fail closed
- Approve-to-send for licensed staff, and prepared call briefs
- Handoff to the carrier-approved enrollment path, where the person enrols themselves
Front Door
Design partnerClinics and virtual care
The administrative half of care: getting people in, reminded, followed up and escalated to a clinician.
The design covers
- Intake, scheduling and reminders
- Follow-up on the people who fall through
- Escalation to a clinician, with clinical judgement left where it belongs
Clear-to-Close
Design partnerLenders
Document intake and conditions tracking, queued behind the first two and design-partner only.
The design covers
- Document intake and classification
- Conditions tracking against the file
- Later than the other two, deliberately
On the roadmap behind these, and equally unbuilt: agent and agency portals, a contracting tracker, commission reconciliation, document classification and care-gap outreach.
What it inherits
Two guarantees the module does not have to invent.
Kivara is a tenant of the operating system, so the parts an auditor asks about first are not built into the vertical. They are underneath it.
No agent approves itself, and a spoken “yes” is not a signature
Approval is an act performed by a named person in a surface built for approving. A model repeating a customer’s agreement back to itself does not satisfy it, and neither does an agent with a convincing argument. Today those approvals run in an operator-grade cockpit; the inbox a business user would live in is being packaged.
Every decision is written down, including the refusals
An auditor asks two questions: what did it do, and what was it stopped from doing. Each action writes an event for every way it can end — completed, failed, denied, or waiting on a person — with one correlation id threading the run together. The customer-facing export of that evidence is designed and not yet built.
- 10:02:11T0consent.checkexecuted
consent record found · scoped to this contact
- 10:02:12T1answer.selectexecuted
approved text only · source and version recorded
- 10:02:40T2record.updateexecuted
reversible · before and after stored
- 10:03:04T3outreach.sendrefused
no consent on file · the gate fails closed
- 10:03:09T1call.brief.prepareexecuted
brief prepared for a licensed person
- 10:05:55T4enrollment.submitrefused
an agent never submits · a licensed person does
Honest status
Design partnerNothing in Kivara is live.
We would rather write that sentence than have you find it out in week three. Here is the whole of it.
What exists today
- A complete specification for Enroll-Ready, reviewed across three model families.
- The rule table written out, with the gates that would have to pass before launch.
- A synthetic test bench. No live workbench, and no customer.
- The operating system underneath it, which is real and is running.
What does not exist
- Any Kivara module running for a customer, in any market.
- Portals, contracting tracking, commission reconciliation, document classification.
- Front Door and Clear-to-Close beyond the design.
- Every regulated gate the programme documents list is unsigned.
Straight answers
What a compliance officer asks first.
Bring the rule table. We will build around it.
Start with the measurement. You get an honest count of what your team does by hand and how much of it an agent could take, with the actions that would still need a licensed person listed separately. Then we decide together whether a design-partner build is worth anybody’s year.
Five multiple-choice questions. A person replies within one business hour.
Kivara is one of four systems. See the others and their real status.