Agentic AI Is Scaling. The Model Behind It Isn’t. Meet Small Language Models for Insurance

Three years ago, the AI conversation in insurance was about generative models: draft policy wording faster, summarize a claim file, answer a broker’s question. Useful, but narrow. One prompt, one answer, and a human doing everything around it. Then came agents: systems that take an instruction, break it into steps, call tools, and finish the job with less supervision. Now the industry is talking about agentic AI, networks of agents that plan, delegate, and hand work to each other from first notice of loss through to settlement.

What gets glossed over in that progression is how little has changed underneath. Almost all of it still sits on the same foundation: a very large, general-purpose language model. Bigger context windows, more tool calls, more agent-to-agent handoffs. Each of those adds tokens per transaction, which adds cost. Each also adds one more place for a model to be confidently wrong.

That model was never trained to read a Texas CR-3 crash report, to tell a claims-made trigger from an occurrence trigger in a D&O form, or to know why a repair estimate at 68% of actual cash value should route differently from one at 72%. It improvises that expertise at inference time, one expensive call after another. For a chatbot demo, that’s fine. For a system deciding whether a claim goes to the special investigations unit or gets paid in three days, “usually right” isn’t the standard. And the industry is starting to feel the distance between what agentic AI promises and what it costs and risks to run at insurance volume.

That gap is where Small Language Models (SLMs) enter the conversation.

Small stopped meaning weak

The economics are already becoming a concern. NVIDIA’s 2025 research also found that many agent tasks are narrow and repetitive, making smaller models a practical fit for much of the work.

An SLM isn’t a smaller, weaker version of a big model. It’s a different design choice. Instead of trying to handle everything, it is fine-tuned for a specific domain and set of tasks: policy wordings, FNOL narratives, claims guidelines, underwriting submissions and the decision patterns already used by adjusters and underwriters.

A Predibase study of 310 fine-tuned 7-billion-parameter Mistral variants found that the tuned models outperformed GPT-4. The point isn’t that smaller models are universally better. It’s that a model trained for one job doesn’t need to be a generalist to perform that job well.

For insurers, the benefits extend beyond cost. A domain-specific model can be evaluated against defined tasks, versioned, and deployed within the organization’s data and security requirements.

What an Insurance SLM knows that a General LLM doesn’t

The difference isn’t simply model size. It’s what the model knows about the work.

Where the work actually changes

None of this matters if it doesn’t show up in the workflows insurers already run. It does, and the pattern is consistent: the SLM handles the high-volume, well-defined step, while the human keeps the judgement call.

Underwriting. An SLM can extract structured risk data from a broker submission in seconds, potentially reducing a manual review that can take 15–20 minutes in some workflows. It can also flag potential out-of-appetite risks and draft a referral summary against the insurer’s own guidelines, allowing underwriters to focus on the risks that need a decision.

Claims. This is where volume can make the economics more visible. A completeness check that might require an adjuster to cross-reference multiple documents can happen at intake. This may help reduce avoidable pendencies and shorten time-to-first-decision. At scale, a potential 10–30x difference in serving costs between larger and smaller models could materially affect the economics of AI-assisted triage.

Servicing. An SLM can turn a multi-year policy and claims history into a concise briefing an agent can review in around two minutes, compared with a manual file review that may take around 15 minutes. The result could be less time spent searching through records and more time focused on the customer conversation.

Contact center. An SLM can answer well-defined coverage questions using the insurer’s actual policy wording and may support sub-second responses for tightly scoped queries. For live interactions, lower latency could help create a more responsive experience.

How to evaluate an SLM against a standard LLM

Vendor claims should be tested against what the model does technically and what that translates to commercially. Neither scorecard is sufficient alone.

Technical parameters

The pattern to look for in extraction accuracy isn’t a single headline number. It’s consistency field by field, especially on the fields general models systematically fumble.

Note: The figures below come from Hexaware’s internal evaluation of a general model against its insurance-tuned SLM on claims documents and are illustrative of that pattern rather than a universal benchmark.

Notice which fields the general model struggles with most: claim number and carrier. Those aren’t hard for a human. They’re hard for a model that has never seen how your forms lay them out.

Business parameters

The honest architecture is a mix

It would be convenient to end with “replace your LLM with an SLM.” That would also be wrong.

The right design is usually layered. A domain-tuned SLM handles the high-volume, well-defined work: extraction, completeness checks, classification, triage. A retrieval layer keeps it grounded in the latest policy wording and state regulation without retraining every time a form changes. A larger general-purpose model stays available for the genuinely open-ended cases, the long-tail reasoning the SLM was never trained for, and the moments where a human wants a second opinion in plain language.

SLM-only, SLM plus retrieval, and SLM plus a general model are all legitimate configurations. Which one fits depends on the workflow, not on picking a technology and forcing every process through it. The mistake most carriers are making today isn’t choosing the wrong model. It’s choosing one model for everything.

Where Hexaware fits

Hexaware has built an Insurance SLM spanning both Life and P&C, deployed across distribution, underwriting, claims, servicing, and finance. It’s offered as a ready-to-deploy foundation that’s then fine-tuned, on an insurer’s own data, which typically compresses the path to production from the year-plus a from-scratch build usually takes to a matter of weeks.

For insurers, MGAs, and brokers who’d rather build natively inside their own environment, Hexaware’s Create Your Own SLM program enables organizations to develop a domain-specific model using their own data, within their own infrastructure. The approach is tailored to the organization’s priorities, level of customization, and value-chain needs. Hexaware’s insurance team can help identify the right approach for your roadmap.

The question worth asking

The next phase of AI in insurance isn’t about adding another AI-powered chatbot to the claims portal. It’s about choosing models that fit the work.

The question for insurers, MGAs, and brokers isn’t whether a domain-specific model beats a general-purpose one. It’s which parts of the workflow need broad, general-purpose reasoning, and which are better served by a model built specifically for the work.

Ready to explore where an Insurance SLM could fit in your workflows? Talk to our insurance experts or request a demo to see it in action. Contact now.