Core modernization: why legacy core with bolt-on AI adds risk, and what to do instead

Every AI point solution added to a legacy core adds an integration, a failure point, and another place where context gets dropped. The result is immense technical debt: custom ETL workflows, data lakes to manage, and the integration risk of a multi-vendor patchwork. 

In last week’s webinar, “Frankenstein’s Monster: Why Legacy Core with Bolt-on AI Is Positively Scary,” now available on demand, Federato co-founder and CTO William Steenbergen and Stacy Newsome, SVP of Forward Deployed Engineering, talked with Max Ettelson, Director of Forward Deployed Engineering, about the active, compounding costs of patching a legacy core. They dug into what AI needs from a core, where best-of-breed strategies break down, and how to sequence a successful modernization.

The opening poll asked attendees to describe their core environment. 60% reported running on a homegrown or highly customized core. For those carriers, building AI into the system is their own responsibility, and likely most of their cores were designed before AI was a factor.

In case you missed it, here are the top insights and recommendations from the session.

Bolt-on AI fails when the core can't supply context and tools

William described an AI agent as having three components: the large language model (LLM), context, and tools. Few insurers build their own LLMs, so the model is rarely the differentiator. Context is the data an agent can access when it makes a decision. Tools are the actions it can take, such as rating a risk, generating a policy document, or starting a referral. 

A carrier controls context and tools whether it builds its own platform or selects a vendor. The core determines how well an agent can use both. Carriers have two paths. They can automate steps in the current process, or they can rethink the process around agents. William said the carriers that rethink the process are the ones that win, and that path requires context and tools built for agents.

Federato's own history offers an example. For the first 2–3 years, Federato automated parts of the existing underwriting workflow, including submission triage, and putting portfolio strategy in front of the underwriter at the moment of decision. Underwriters wrote more in-appetite business, about a 10–15% increase. William estimated that much larger gains were achievable if they rebuilt the underwriting process around agents, an estimated 80–90% efficiency gain and 5–6x more in-appetite bound submissions. That rebuild required Federato to own the product definition, so an agent could do the work.

Agentic AI raises the standard for data and APIs

While people compensate for unclear data by asking the expert who owns it, AI agents have only what they are given. An agent in the middle of a quote can’t message an engineer to find a data source. That defeats the purpose of the agent.

Stacy framed it from the decision-maker's side. A bad decision usually follows from missing context. When data is pulled from several sources, context drops at each handoff, and the agent still returns an answer. Someone then has to determine whether the answer is wrong.

API quality shows up quickly. Max described a custom API that returned a 200 response, the standard signal for success, with a list of errors underneath. An agent parsing that response gets confused. William added that agents call APIs far more often than people do. A rating API that a person clicks once may be called 5 or 6 times by an agent comparing options, so the infrastructure under it has to scale.

For carriers with homegrown cores, all of this work falls on them, including API documentation, error handling, performance, and the engineering capacity to improve all three.

AI-native does not require replacing your infrastructure

An attendee asked whether Kubernetes, Kafka, and zero trust identity can carry over to an AI-native foundation. William said yes. Modern, scalable infrastructure works. The deciding factors are how data is stored, how metadata is handled, and what the APIs expose.

The difficulty is that changing the interfaces often means changing the platform, or building a large layer on top of what exists. That can cost more than replacing the system.

William compared the moment to the move from on-prem to cloud. Carriers that skipped that move are behind today. He sees the shift to AI-native as equal in size or larger. 

The question to ask is whether a carrier can compete with AI-native carriers and MGAs 5 years from now with a bolt-on approach.

Point solutions split the context that decisions depend on

In the early years of Federato, carriers wanted to keep their document ingestion tools and send the extracted data into Federato. William said the integration produced no value. An underwriter needs to understand the risk, run a rater, and generate a quote. An ingestion tool that doesn’t know which fields the rater requires can’t extract the right data.

The approach that worked treats extraction as a tool inside an agent loop. The agent knows what it needs, extracts it, receives an error from the rater that names a missing field, and extracts again. Connecting extraction to that context changes the quality of the results.

Stacy offered a test for deciding what belongs together: does the capability shape the decision, or serve it? A data feed serves a decision. Appetite, risk selection, and triage shape it, and they need to live together. Splitting them, she said, is "like looking through a keyhole versus seeing the entire room."

Best-of-breed works when the point solution is stateless and AI-native

William gave a framework for the cases where a point solution makes sense. The solution should be stateless, meaning it stores no data of its own, so nothing needs to stay synchronized across systems. It should also be AI-native, meaning it exposes a performant API with strong error handling that can handle agent traffic.

Federato has implementations where the rating engine runs outside the platform. The team does not prefer that setup, but it works when both conditions hold.

Integrations add cost in lost context, failure points, and governance

Stacy named three burdens that come with each added integration or customization.

The first is context, which drops at every connection. 

The second is failure points. The carrier owns the space between each integration, and support often depends on the one person who knows how the pieces fit. Stacy has been on high-impact outage calls where several vendors were involved and nobody could be reached to troubleshoot. 

The third is process and governance. A change in one system has to be made and tested in several, and project managers and operations staff working on separate components lose context as they stitch the outcome together.

William added data from Federato's implementations. Integrating Federato's underwriting workbench with a customer's policy administration system took longer than replacing the entire old core. The number of integrations is the largest variable in Federato's capacity planning. A point solution looks like a smaller surface area, but it often takes longer.

Stacy summarized the principle: simplicity drives stability, accuracy, and reliability, and it lowers total cost of ownership.

Count the full cost of staying, not the amount already spent

Carriers often say they have spent millions on their platform and cannot walk away. Stacy reframed the decision around what it costs to keep the system and what risk the carrier takes by staying.

The cost of staying goes beyond licensing, hosting, and maintenance. It includes integration upkeep, engineering support, reconciliation and reporting workarounds, dependence on the few people who know the system, and whether the platform supports where the carrier wants to be in 3–5 years.

The value of moving includes faster quotes, better hit ratios, faster product launches, less customization, and better risk selection over time. In insurance, Stacy said, the return comes from better decisions and faster growth. IT savings are part of it.

She described a financial services customer running a $100 million legacy platform. The platform met current needs, but blocked future growth. The conversation started with IT spend and moved to three business goals: move fast instead of only running fine, build a foundation ready for AI, and reduce maintenance costs.

Start modernization with your largest line of business

Many carriers plan to migrate line by line or product by product. William agrees with that sequencing, but said that the common choice, to start with the smallest line, is a mistake.

The first line is always the hardest. The teams are building a working relationship and learning together, whatever the size of the line. If the first line is also the smallest, and only improves 2% of the business, the executive sponsor has little impact to show when asking leadership to fund the rest of the migration, where most of the value sits.

Starting with the largest line puts the work where the opportunity cost is highest. It produces a visible result and makes the case for the rest of the migration. 

Stacy added that the best starting point is where the pain is: submissions piling up, frustrated underwriters, and a business leader who owns the outcome and can show a before-and-after.

Implementation speed depends on decisions as much as technology

Timelines are almost never driven by technical complexity on a modern platform with build-time AI, such as AI-assisted coding, automated data mapping, and workflow building. Requirements change, people resist change, and decisions stall.

The most effective step William has seen is to reduce the number of people who make decisions. Some Federato implementations went live in a couple of weeks because one person had full authority over the workflow. That person was a strong product thinker and a champion for change. The slowest implementations involved consultants, 20 people on every call, and decisions by consensus.

Stacy added that discovery on the first line of business decides success. Three underwriters will often make the same decision three different ways, so the team has to keep asking what outcome it wants. She also shared a lesson from early in her tenure at Federato. The team said yes to every request from a carrier, including every connection and customization, and timelines dragged. The carrier CEO later asked her to tell the team to stop saying yes to everything, since 80–90% of what the carrier really needs works out of the box.

The solution is to ask why before agreeing to a customization. Implementations run best with defined outcomes, a joint success plan, and governance that moves decisions up quickly. Federato uses a forward-deployed engineering model so the team that has seen dozens of core migrations stays in-house.

Advice for carriers ready to modernize  

When asked for the one piece of advice they’d give a carrier that wants to modernize but worries about risk, William and Stacy offered the following:

• William: Think about data context first. If data storage and context are well organized, everything else follows.
• Stacy: Keep a small group focused on the outcome, since it is easy for a modernization to drift.

Watch the webinar on demand for the complete insights.