# Agents are breaking your policy system (https://riska.io/blog/agents-are-breaking-your-policy-system)

_2026-10-15 · Riska Underwriting Team · business-ecosystem_

For thirty years insurance software has come in two shapes. Neither was built for an agent that reads every submission, acts on whatever is in the file, and needs authority over a narrow slice of the book. Insurance already has the answer in delegated authority: written limits and referral rules, enforced by the system instead of by a reviewer's attention, so the agent works inside the lines and a person sees only what falls outside them.

## Key takeaways

- An underwriting agent reads the whole submission queue, not the ten files a person opens before lunch, so a policy system built around one person keying one submission becomes the bottleneck.
- An agent acts on whatever is in the file. A decline reason that lives in someone's inbox does not exist for it.
- Agents need deeper context than a person, over a narrower slice of the book. Insurance already has a name for that arrangement: delegated authority.
- Having a person approve everything an agent drafts does not hold at forty submissions a day. Approval turns into habit, and habit is how the exception gets through.
- In Riska an agent acts with the permissions of the person it works for, narrowed to its own ceiling, and a claims reserve over authority parks for the role above instead of posting.

## Insurance software has come in two shapes

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](/blog/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.

### Five ways an agent strains a policy system built for people

Each row is something an underwriting agent does on its first morning, and the reason a system designed around one person at one screen gives way under it.

| Strain | What an agent does | Why a system built for people breaks |
| --- | --- | --- |
| Scale | Reads the whole submission queue, every loss run and every prior quote on the account before anyone else is in | Screens and record locks assume a person opening one file at a time. A nightly export fills the gap, and it is already stale when the agent reads it |
| Context | Quotes on whatever is in the file | If the reason you declined the account two years ago sits in an underwriter's inbox, it is not in the file, and the agent quotes a risk you already turned down |
| Interface | Needs the rules without the screen | A referral rule that only exists as a greyed-out button does not exist for an agent. Neither does a check that only runs when someone clicks Save |
| Language | Works best in the conventions it was trained on: SQL for a question across the book, and the industry's own nouns for what is in it: program, product, exposure, coverage, endorsement | A proprietary query language, or a deductible kept in a field called Custom 17, has to be explained to the agent in a prompt, and the prompt drifts from the system |
| Permissions | Needs deeper context than a person, over a narrower slice of the book | Access was designed for people. An agent signed in as a user can touch everything that user can, and nothing says where its own authority stops |

> **DEFINITION: Delegated authority**
> Delegated authority is the arrangement under which an insurer lets another firm write business on its behalf. At Lloyd's that firm is a [coverholder](https://www.lloyds.com/market-resources/delegated-authorities/compliance-and-operations/about-coverholders), also called an MGA, authorised to enter into insurance contracts for a syndicate under a binding authority agreement that defines the underwriting and administrative functions it may perform.

In the United States, the NAIC's [Managing General Agents Act](https://content.naic.org/sites/default/files/model-law-225.pdf) requires the contract between an insurer and its MGA to carry underwriting guidelines, including the types of risks which may be written, maximum limits of liability, territorial limitations and the maximum policy period.

## Agents need the same authority as people, over a narrower slice

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.

### The rubber-stamp cycle

What happens when every action an agent takes needs a person to say yes.

1. **Agent drafts** forty quotes and reserve changes before nine
2. **Human skims** the queue is long and most drafts look right
3. **Approved by habit** the click itself becomes the only control
4. **Exception slips** an out-of-appetite risk gets quoted and nobody notices
5. **Review tightens** every draft waits longer, so people skim harder

_Returns to Agent drafts._

_The cycle stops only when the system knows where the agent's authority ends, so the reviewer no longer has to._

## The architecture for agentic underwriting

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](/platform/developers), an MCP server for outside agents and an SDK for building your own, each held to the same permissions as the screen.

[Context](/blog/underwriting-agent-context-compounds) and [open access](/blog/what-is-a-bordereau) each get a post of their own. This one is about authority, because it is the part insurance worked out long before software did.

## Writing authority down is work, and some judgment will not fit a rule

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.

## One system for underwriters and agents

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](/platform/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](/platform/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](/platform/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.

## Questions we get asked

### Can an AI agent bind coverage?

An agent should only be able to do what the person it works for may do, narrowed to the agent's own limits. Whether that includes binding is a delegated authority decision, the same one a carrier makes for an MGA, and it belongs in the system as limits and referral rules rather than in a prompt.

### Why do AI agents need different software than underwriters?

Agents do the same work under different strains. They read every record rather than a handful, act on whatever is in the file, need rules they can read without a screen, and need deeper context over a narrower slice of the book than any one person holds. Software built around one person at one screen handles none of those well.

### Isn't this just human-in-the-loop with extra steps?

It moves the human to where they add something. Approving every agent action turns into approval by habit at forty submissions a day. Instead, a person sees the work that falls outside the agent's authority, with the reason it fell outside.

### What does a carrier auditor see when an agent acted?

In Riska, every change an agent makes is stamped with the agent and the person it acted for, and the history keeps the values before and after. A claims reserve that went over authority does not post until a second approver decides the parked request, so the approval is on the record too.

### What is delegated authority in insurance?

Delegated authority is the arrangement under which an insurer lets another firm, usually an MGA or a Lloyd's coverholder, write business on its behalf. The contract sets what may be written, such as the types of risk, the maximum limits, the territories and the policy period, and anything outside it is referred back to the insurer.