The AI Agent Will Eat Your Agency Management System

The AI Agent Will Eat Your Agency Management System

By PS Advisory Team

The AMS Was Never the True System of Record

Here's the thing that makes the AMS position even more fragile than it appears: the AMS isn't actually the system of record for the most important data in the insurance transaction — the policy itself.

The true system of record for policy data is the carrier. The carrier is the one who underwrote the risk, bound the coverage, and issued the policy. Their policy administration system is where the official record lives. The AMS holds a copy — a useful, aggregated, convenient copy — but a copy nonetheless. Commission data originates with the carrier. Policy terms originate with the carrier. Endorsements and cancellations originate with the carrier. The AMS is an intermediary that assembles information from dozens of carrier systems into a single interface for the agent.

This distinction has been easy to ignore for decades because the AMS was the most practical way to access that aggregated view. But it matters enormously once AI agents enter the picture.

Why This Makes the AMS Uniquely Vulnerable

Zain Hoda recently wrote a provocative piece arguing that AI agents will collapse the "system of record" moat in enterprise software. His thesis is simple: the data in most enterprise systems is small, agents need access to do their jobs, and once an agent has a copy of the data, the original system becomes little more than a write endpoint that nobody opens.

The insurance AMS is an even more extreme case of this vulnerability, because it isn't even the authoritative source. It's an aggregation layer. And aggregation layers are exactly what AI agents are built to replace.

Think about what happens when an AI agent needs policy information for a renewal review. Today, the agent would typically pull that data from the AMS, because the AMS has it all in one place. But what if the AMS restricts API access? What if rate limits make it impractical? What if the vendor decides to wall off the data?

The agent doesn't stop working. It goes to the source.

Carrier portals have APIs. Download and data exchange standards like ACORD already exist to move policy data between carriers and agencies. If the AMS blocks access, a sufficiently capable agent simply pulls the data directly from the carriers who actually own it — the true systems of record. The AMS didn't protect its position. It made itself irrelevant by forcing the agent to build a direct relationship with the authoritative source.

The Data Is Smaller Than You Think — And the Math Proves It

Here's something most insurance professionals don't realize: the actual structured data flowing through an agency is tiny. Not just small. Tiny enough that today's AI models can hold a meaningful chunk of it in a single conversation.

Let's do the math.

A typical policy record — insured name, address, policy number, effective and expiration dates, coverages, limits, premiums, carrier, producer — runs about 500 to 1,000 bytes of structured text. A small independent agency with 3,000 policies has roughly 3 MB of core policy data. Add in contacts, commission records, activity notes, and recent correspondence, and you're looking at maybe 15 to 30 MB total. A mid-size agency with 15,000 policies might have 100 MB. Even a large agency with 50,000 or more policies rarely exceeds a gigabyte of structured data. Your entire book of business, the thing your agency's valuation is built on, could fit on a thumb drive.

Now consider what just became available this week.

Anthropic released Claude Opus 4.6 on February 5, 2026 — with a 1 million token context window. One million tokens translates to roughly 750,000 words, or about 3 to 4 MB of structured text data. That's not a theoretical capability on a roadmap. It's a production model you can use through an API today.

On retrieval benchmarks, Opus 4.6 scored 76% on the hardest variant of the MRCR v2 test — finding eight hidden pieces of information buried across one million tokens of text. Its predecessor scored 18.5% on the same test. This isn't just a bigger buffer. It's a qualitative leap in an AI's ability to hold large amounts of data and actually find and use the specific information it needs within that data.

Here's what that means for an insurance agency: a single Opus 4.6 context window can hold roughly 10 to 25% of a small agency's entire structured AMS data. If you're selective — loading just active policies, current-year commissions, recent activity notes, and key contacts — an AI agent could hold most of what a CSR needs for their daily work in a single session. For a mid-size agency, you'd need multiple passes or a caching layer, but the point is that we're already in the same order of magnitude. The context window and the database are converging.

And context windows are getting larger every release cycle. The AMS data isn't growing at anywhere near the same rate.

This didn't matter when the only way to get an aggregated view of your book was through Applied's interface or Vertafore's UI. The data was spread across dozens of carrier systems, and the AMS was the only practical way to see it all in one place. The application and the aggregation were fused together, and that fusion was the moat.

AI agents break this assumption completely. An agent can aggregate data from twenty carrier systems as easily as it can pull from one AMS. It can hold a significant portion of that data in working memory. And it can retrieve specific information from that data with better accuracy than most humans navigating a clunky search interface. The aggregation layer that justified the AMS's central position is now a commodity capability — one that's getting cheaper and more capable every quarter.

Blocking Access Is a Losing Strategy

Some AMS vendors will try to fight this. They'll restrict API access. They'll implement rate limits. They'll keep data locked behind proprietary formats and closed ecosystems. Applied's historical approach to data access is a case study in this thinking.

This is a losing strategy, and here's why.

If you restrict an agent's access too aggressively, the agent becomes useless for the workflows that depend on AMS data. But unlike a traditional system of record, the AMS doesn't have the fallback position of being the authoritative source. The data exists elsewhere — at the carriers. The AMS is choosing to make itself harder to work with than the original sources, which is a remarkable strategic decision when your entire value proposition is that you're easier to work with than going to each carrier individually.

A sufficiently capable agent, facing AMS access restrictions, does the math. It can either fight the rate limits and proprietary formats of the aggregation layer, or it can go directly to the twenty carrier systems that actually hold the authoritative data. Today, going direct is harder. In twelve months, with better carrier APIs and smarter agents, the calculus flips. And once agencies realize their AI agent can pull data directly from carriers without the AMS as middleman, the switching cost conversation changes fundamentally.

The AMS vendors face a stark choice: open your systems and ensure you provide the best possible infrastructure for agents to access the data they need, or watch as agents simply bypass you entirely and go straight to the source.

This Is Already Happening

The pattern is already emerging across the insurance value chain.

At the agency level, forward-thinking agencies are building AI assistants that sit on top of their operational data. The assistant handles certificate requests, answers coverage questions, preps renewal summaries. The CSR who used to spend 40% of their day navigating Applied Epic's interface now spends that time talking to an agent that has all the same data but actually understands what they're asking.

At the carrier level, underwriting workbenches powered by AI are pulling submission data, loss history, and supplemental information into a unified context. The underwriter doesn't need to toggle between seven systems anymore. The agent has already assembled everything. And critically, carriers are beginning to open their systems to agent-based access — because carriers benefit from making their data accessible to the AI tools that agencies are adopting.

At the MGA level, AI agents are beginning to handle quote intake, appetite matching, and preliminary underwriting. They pull from multiple carrier appointments, multiple rating platforms, multiple data sources. No single aggregation layer is the center anymore. The agent is.

What Actually Matters Now

If you're an AMS vendor, the honest question is: what's your product when an agent can aggregate carrier data directly?

Some answers still hold:

Workflow automation that's genuinely hard to replicate. If your system has deep, insurance-specific workflows — ACORD form generation, download processing, carrier connectivity — that's real value. But it's value as infrastructure, not as a user-facing platform. And you'd better make sure your infrastructure serves agents as well as it serves humans.

The write-back layer. Agencies still need to push data to carriers, not just pull from them. Submission workflows, endorsement requests, policy change processing — the bidirectional data flow is harder to replace than the read layer. If your AMS is excellent at getting data to carriers efficiently, that's defensible. For now.

Regulatory compliance and audit trails. Insurance is regulated. Someone needs to maintain records of who accessed what, when policies were bound, how customer data was handled. Governance matters, but it's a feature, not a platform.

What's not defensible is "we aggregate your carrier data into one place." That's not a moat anymore. It's exactly what agents do natively.

The Insurance Industry's Unique Vulnerability

Insurance is arguably more vulnerable to this shift than most industries, for several reasons.

First, the AMS was never the authoritative source to begin with. Unlike Salesforce, which genuinely is where customer relationship data originates, the AMS has always been a copy of data that lives elsewhere. That makes it much easier to bypass.

Second, the interfaces are notoriously bad. Insurance software has survived for decades with UIs that would be considered unacceptable in any other industry. This was tolerable when there was no alternative. When the alternative is talking to an AI agent that actually understands insurance terminology and can navigate five carrier systems in the time it takes a human to log into one, the old interfaces become indefensible.

Third, the industry already has data portability standards. ACORD exists precisely because insurance data needs to move between parties. Submissions go from agents to carriers. Policies go from carriers to agents. Claims data flows between adjusters, carriers, and insureds. AI agents simply make that portability frictionless — and they don't need the AMS as a waypoint.

Fourth, carriers are increasingly motivated to enable direct agent access. If a carrier can make it easy for an AI agent to pull policy data, submit endorsements, and process renewals directly, they strengthen their relationship with the agency and reduce their dependence on AMS vendors as intermediaries. The carrier incentives are aligned with the agent's architecture.

What Should You Do About It?

If you're an agency principal: Start thinking about your AMS as one data source among many, not as the center of your operation. The agencies that thrive in the next five years will be the ones whose people interact with AI agents that can pull from any system — AMS, carrier portals, rating engines, document stores — without being dependent on any single one.

If you're a carrier CIO: This is your opportunity. Open your systems. Make your APIs agent-friendly. The more accessible your policy data is to AI agents, the less agencies need their AMS as a middleman for your data. You strengthen your direct relationship with the distribution channel.

If you're an AMS vendor: The existential question is whether you become the best infrastructure layer for AI agents or get bypassed entirely. The vendors who open their systems — who make it faster and easier for an agent to get data through the AMS than by going directly to carriers — will survive and potentially thrive. You have the aggregation advantage today. Use it by being the most agent-friendly platform in the ecosystem. The vendors who try to protect their position by restricting data access will discover that the data was never theirs to restrict. It came from the carriers, and agents can go get it from the carriers.

If you're building in insurtech: The opportunity isn't building another aggregation layer. It's building the intelligence layer that makes every data source — AMS, carrier, MGA, rating engine — equally accessible. The agent doesn't care where the data lives. Build for that world.

The Bottom Line

For twenty years, "we aggregate your carrier data into one convenient place" was enough to sustain a business in insurance technology. The aggregation was genuinely valuable because the alternative was logging into dozens of carrier portals individually. AI agents are the ultimate aggregation layer. They can pull from any source, synthesize across systems, and present a unified view — which is exactly what the AMS did, but faster, smarter, and without requiring a human to navigate a clunky interface. The AMS vendors have a narrow window to reposition. Open your systems. Become the best infrastructure for agents to access the data they need. Be so good at serving AI agents that going directly to carriers is slower and less reliable than going through you.Or don't. And watch the agents go around you to the true systems of record — the carriers — who are increasingly happy to let them in.

The choice is open up or get bypassed. There is no third option.


Andrew Bartels is the founder and CEO of PS Advisory, a Salesforce consulting firm specializing exclusively in the insurance industry since 2013. PS Advisory builds AI-powered insurance solutions using Salesforce Financial Services Cloud, Data Cloud, and Agentforce.