Agents are breaking your policy system

It is 7:40 on a Tuesday. Forty-one submissions landed in the shared inbox overnight, and an agent has already read every one of them, every loss run attached to them, and every quote your team wrote for the same insureds last year. Your underwriters will open about ten before lunch.

That agent is about to be told to do something with what it read. This post is about where it does it.

For thirty years, insurance software has come in two shapes. The first is the core system: the policy admin system, the rating engine, the claims platform. It has guardrails. It checks a limit against the form, refuses to issue without a signed application, and keeps an audit trail an examiner can follow. It was built for one person keying one submission, screen by screen.

The second is the warehouse, and the spreadsheet beside it. It has throughput. The actuary can pull five years of loss ratios by class code on a Thursday afternoon. It has no rules, so nothing in it stops a bad write, and nothing written there reaches the policy you will actually issue.

We made the case against splitting a book across systems in Burn the silos. This is a different gap.

An agent needs the guardrails of the first shape and the throughput of the second, in the same place. The core system gives it rules at the speed of a person. The warehouse gives it speed with no rules. Neither tells it what it is allowed to do.

Every policy admin system was built for people. Agents are breaking it in five specific ways.

Carriers solved this problem before software existed. A carrier that lets an MGA commit its paper does not watch every bind. It writes the authority down: which lines, which territories, what limits, how long a policy may run. Anything outside it goes back up as a referral.

Claims has the same shape. Under the NAIC model act, the claim file goes to the insurer as soon as it becomes known that a claim may exceed the MGA's settlement authority. The handler does not ask before every reserve. They ask when the reserve crosses their line.

An agent needs exactly this arrangement. Deeper context than a person holds: the whole file, the account's history, every prior quote, every email with the broker. Over a narrower slice: one program, one line of business, reserves up to a set amount, and nothing outside the appetite you drew.

The usual answer from software vendors is simpler. A human approves everything. Every draft quote, every reserve change and every email to a broker waits for someone to click yes.

At forty submissions a day, that does not hold. The reviewer reads the first twenty carefully and approves the rest because they look like the first twenty. The approval becomes a formality, and a formality is exactly the control an examiner will ask you to prove was real.

A person belongs in the loop where the agent's authority runs out. That is where their attention is worth something, and it is the only place they should be asked to spend it.

If authority is what an agent needs, a policy system has to hold three things it was never asked to hold before. They are the same three things a good MGA already keeps for its carrier, in a binder folder and an authority letter.

Context: the record holds the whole file

An agent quotes on whatever is in the file, so the file has to be complete. The submission, the loss runs, the quote you lost last year and why, the decline two years ago and the reason for it, the broker's emails and the notes from the call. Each submission leaves context for the next one, and the renewal is where it pays.

Authority: the system enforces the rules, not the prompt

A prompt that tells an agent to refer anything over its limit is a suggestion. A limit the system checks before it writes is a control. The underwriter and the agent work on the same record under the same rules, and when either one reaches the edge of their authority, the work parks for the person above them with the reason attached.

Open access: agent access on every surface

The carrier reviewing your book should be reading what the agent read, and so should your partners and the tools you connect, without the month-end bordereau export. That means the assistant, workflows, the API, an MCP server for outside agents and an SDK for building your own, each held to the same permissions as the screen.

Context and open access each get a post of their own. This one is about authority, because it is the part insurance worked out long before software did.

The strongest objection comes from senior underwriters, and it is fair. Authority letters are written for people who already know the business. Refer anything unusual works because the person reading it knows what unusual looks like on a habitational schedule in coastal Texas. An agent does not, and writing it down precisely enough for software to check is a real piece of work.

Some of it will never fit. A broker you have written with for fifteen years. A risk manager whose word you take. A class you are quietly trying to grow. That is judgment, and it should stay with a person.

The answer is that the referral is the product. A refer-up that arrives with its reason, its score, the rule that fired and what is still missing beats an automatic yes that was wrong. An agent that sends you six well-explained referrals a day and works the other thirty-four inside the lines you drew is doing what a good junior underwriter does.

The writing-down also pays twice. The rules an agent needs are the rules your carrier's auditor asks you to show. Once they live in the system, both of them read the same ones.

Riska is built as one system where the underwriter and the agent work on the same record, under the same rules. The agent gets no back door and no copy of the data. Whether it queries the book in SQL or connects from outside over MCP, it sees only what the person it acts for may see, and the query it ran stays on view.

When someone works with Ask Riska, each agent acts for that person, with their permissions narrowed to the agent's own ceiling. A tool the agent is not permitted is never offered to it, so an agent working for an auditor has no write tools to call. It cannot be talked into a change, because the button is not there. Every write it makes is stamped with the agent and the person it acted for, so the history names both.

Claims carries an authority matrix that the system checks, not the handler's memory. A reserve change is checked as the movement it makes: raising a reserve from 10,000 to 12,000 exercises 2,000 of authority, because the first 10,000 was authorised when it was set. Over authority, nothing posts. The change parks for the role the matrix escalates to and posts only when a second approver signs it off. An approver who is over authority themselves is refused, because approving is exercising the authority, not waiving it. Denying or closing a claim is guarded the same way, and a refusal names the reason.

Appetite applies the same idea at the front door. A knockout never changes the score, so both facts survive on the file: scored 84, and knocked out to refer because of the answer that came back. Where an agent makes a call with a fixed set of answers, it returns a confidence band of act, review or abstain, and the judgment is recorded in the same step as the change it drove.

That is the architecture for agentic underwriting. Authority written into the system, where the underwriter and the agent both have to answer to it.