Start · Orientation · Everyone · ~20 min
Insurance runs on unstructured information: submissions, loss runs, policy wording, claims files, and broker correspondence. Large language models can read and structure that material at scale. Start with the one idea below that everything else hangs on, or choose the category that matches your role.
What this technology is, in brief
Large language models (LLMs), the technology behind ChatGPT, Claude, and Gemini, are software systems trained on enormous volumes of text that can read, summarize, draft, extract, classify, and reason over language. Think of them as an extremely fast, extremely well-read junior analyst: broad knowledge, strong language skills, tireless, but one who occasionally states wrong things with complete confidence, and whose work always needs review before it leaves the building.
They are not databases, search engines, or calculators. An LLM does not "look up" answers; it generates them. That is why it can draft a coverage summary in seconds, and also why it can invent a plausible-sounding policy exclusion that doesn't exist. This failure mode is called hallucination, and managing it is the central discipline of using LLMs well.
The one idea everything else hangs on
Context in, quality out. An LLM answers from what it absorbed in training (general knowledge, as of a specific model training cut-off date) and from whatever context it is given while it works. Almost every disappointing answer traces back to not giving the model enough to work with, and almost every improvement comes from getting more of the right material in front of it.
That is the overarching idea of this site, because the ways of giving a general model access to context have multiplied. Not long ago it meant pasting text into a chat box. Now a model can be handed your documents, templates, and data; loaded with reusable Agent Skills that package your procedures and domain knowledge; and connected to tools through the Model Context Protocol (MCP) or a provider's own browsing and search to look things up while it works: read a live web page, pull a filing, query a database, call an internal system, then reason over what it found. The training cutoff stops being a hard boundary on what it can know. It does not stop being your problem: retrieved material is still context, it can still be wrong, out of date, or deliberately hostile, and a claim the model fetched needs the same check as a claim it remembered.
A rule of thumb falls out of this: treat the model like a bright junior colleague on their first day. Capable, fast, well-read, but they don't know your account, your appetite, or your standards until you tell them, and telling them is supplying context. You review their work before it goes anywhere. This one rule resolves most questions about appropriate use.
Context in, quality out
A model answers from three sources, and you decide what goes into two of them. Supplying them is a craft with its own ladder: the same question answered from a pasted document and from a versioned skill are not the same question.
Levels of context engineering
Each level costs more to build and reaches further. Which one a task deserves depends on how often it recurs and how much the answer matters, not on how advanced you want to look.
-
1
Paste it in The submission or the wording, dropped into the conversation. Reach: one question, one person, once.
-
2
Structure it A reusable prompt carrying the format, a worked example, and the standard the output must meet. Reach: the same task, repeatably, across a team.
-
3
Retrieve it RAG over your guidelines and appetite guides, or a connected tool that fetches from outside them, so the answer is drawn from a named source and cites it. Reach: answers that stay current as the guidelines change, and are checkable.
-
4
Package it A versioned skill: the procedure, its scripts, and its checks, loaded only when the task calls for them. Reach: an organizational procedure that can be tested, corrected once, and reused everywhere.
Why the fourth level compounds
Level 4 earns its emphasis: it gives the model effectively persistent, long-term memory about how you want it to behave, a memory that can be continually accumulated and improved over time. The distinction from level 3 is kind, not currency. Retrieval hands the model reference material to read; a skill hands it instructions to follow, with scripts and checks that produce the same output from the same input instead of asking the model to reinterpret a guideline on every run. Skills load only when their task arrives, so their token cost is paid on demand rather than carried in every prompt. And because a skill is a file, every correction becomes the instruction every later run reads: the procedure compounds.
Skills mix reasoning with determinism
A skill packages three kinds of material: prose the model interprets, scripts that run deterministically, and checks that must pass. An agent partitions the work between them: the model supplies judgment where judgment is required, such as reading an unstructured submission, deciding which step applies, or drafting the language, while the scripts carry the parts that must not vary. This is what separates an agent from a coded pipeline. A pipeline encodes every decision in advance and breaks on the first input its author did not foresee; an agent encodes only the steps where variance is unacceptable and lets the model absorb the rest. The mixture is asymmetric: the model's portions stay stochastic, which is why the harness pairs skills with evals and golden datasets. You cannot unit-test judgment, so you measure it.
Two ways to encode a procedure
A deterministic pipeline encodes every step in advance. An agent with a skill encodes only the parts that must not vary, and lets the model absorb the rest.
Deterministic pipeline
Unforeseen input: no rule matches, so the pipeline stops or silently guesses.
Agent with a skill
The model decides when the skill applies and handles everything around it; the deterministic core inside runs unchanged.
Practice · Concepts · Everyone · ~10 min
The terms you'll hear and an honest account of model strengths and weaknesses.
Terminology, one line each
| Term | Plain-English meaning |
|---|---|
| LLM / foundation model | A general-purpose AI model trained on vast text; the "engine" (e.g., GPT, Claude, Gemini) |
| Generative AI | AI that creates content (text, images, code) rather than just scoring or classifying |
| Prompt | The instruction you give the model; prompt quality drives output quality |
| Hallucination | Confident, fluent output that is factually wrong or fabricated |
| Context window | How much material the model can "hold in mind" at once (now: entire claim files or policy forms) |
| RAG | Retrieval-augmented generation: connecting the model to your documents so answers cite your guidelines and forms. The main technique for grounding output in fact |
| Fine-tuning | Additional training on your own data to specialize a model; less common than RAG in practice |
| Agent | A system that uses a model and tools to complete a multi-step job, rather than answer once |
| Agentic | A workflow pattern in which an agent plans, acts, observes results, and continues within defined boundaries |
| Artifacts | Finished outputs an agent produces as standalone files or apps (documents, charts, webpages) rather than disposable chat replies; they can be saved, shared, and revised |
| Tool use | Letting the model call something outside itself while it works: a web search, a database, a script, an internal system |
| MCP | Model Context Protocol: the open standard for connecting a model to those tools and data sources, so the same connector works across products |
| Context engineering | Designing what the system sees: instructions, source material, examples, state, and retrieved evidence |
| Skill | A packaged, versioned procedure the model loads when a task calls for it: the steps, the scripts they run, and the checks that must pass |
| Human-in-the-loop | A named person approves consequential output or reviews exceptions surfaced by the harness |
| Guardrails | Technical and policy controls that constrain what the AI can see, say, and do |
| Token | The unit models read and produce (~¾ of a word); usage is billed per token |
| Machine learning | The broader field; existing pricing models are ML but not generative AI. Governance for both is converging |
How retrieval grounds an answer in your documents
RAG is the main technique for making a model answer from your guidelines rather than from its training. The retrieval step is the whole difference.
Without step 2 the model answers from general training, which is where invented exclusions come from. With it, a wrong answer is traceable to a document you can fix.
What it does well, and where it fails
Five strengths, five failure modes, and which failures are fixable
The failures are not all the same kind, and treating them as one list is why programmes over-invest in the wrong controls. Two can be removed from the step entirely. The other three can be caught far more often than they can be prevented, and that residual is what a named approver is for.
Good at
- Reading and summarizing large volumes of documents
- Drafting, where the model produces the first version and a person produces the final one
- Extracting structured data from unstructured text
- Explaining, translating, and reformatting information
- Writing and reviewing code
Fails at
- They do not reliably do arithmeticUnaided, a model guesses at a calculation with the same confidence it uses for prose. Engineer it out
- They are non-deterministicThe same question can return a slightly different answer, which is what makes reproducibility and audit hard. Engineer it out
- They fabricateFluency is not accuracy, and a wrong answer looks exactly like a right one. Grounded retrieval, forced citations, schema validation, and a checking hook that verifies each claim against its source turn most invented content into a failed check rather than a delivered document. Engineer it down
- They can be manipulatedPrompt injection: instructions hidden in a document the model reads, written to be obeyed rather than summarized. Least-privilege tools and separating instructions from untrusted content limit what a successful injection can reach. Engineer it down
- They reflect training-data biasA direct concern under unfair-discrimination law. Outcomes testing measures it on your own book and makes it reviewable, which is what regulators ask for; it does not remove it. Engineer it down
The tags split on what is left over, not on how much work is involved. Engineer it out means the failure stops existing for that step. Engineer it down means a control catches most instances before a person sees them, and nothing certifies absence, which is why a named person still approves consequential output.
What the engineering actually is
The first two fixes are the same move: stop asking the model to be the part of the process that has a right answer.
- Arithmetic and data manipulation belong in code. Given a tool, the model writes and runs the calculation instead of guessing at it. The number then comes from a script you can rerun and inspect, and the model's job shrinks to deciding what to compute and reading the result.
- Non-determinism is bounded by fixing the procedure, not the wording. Package the task as a versioned skill: the steps, the scripts they call, the schema the output must satisfy, and the checks that must pass before anyone sees it. The steps that must be identical every time are executed deterministically; the model supplies judgment in the places that genuinely need it, and a failing check stops the run rather than producing a quietly different answer.
The other three work differently: you cannot remove them, so you make them detectable and you bound what they can reach. Fabrication is the clearest case. Ground the answer in retrieved passages and require it to cite them; validate the output against a schema so a malformed answer fails rather than ships; run a checking step whose only job is to hold each claim against its source; gate releases on an eval set with known answers so a regression shows up before a reader does. Hooks like these are why a governed pipeline is not the same product as the same model in a chat window, and they change the arithmetic of review: a person checking exceptions is doing a different job from a person re-reading everything.
What they do not do is certify absence. A check catches what it was written to catch, so the residual is real and it is why accountability stays with a named person rather than with the pipeline. Treat the difference between a 5% error rate and a 0.5% one as worth engineering for, and the difference between 0.5% and zero as something to govern instead.
This is what the context ladder above is for. Level 4 is not a more advanced way to chat; it is the point at which a task stops varying, because the parts that must not vary have been moved out of the model and into code that runs the same way twice.
Where things stand right now
Capability, adoption, and regulation are not moving at the same speed, and confusing them is the most common planning error. Frontier models can already do far more than most insurers have absorbed; the binding constraint is organizational rather than technical. Meanwhile the supervisory framework has moved from consultation to expectation, so a programme started today inherits obligations that did not exist two years ago.
The timeline plots all three on one scale, marks where August 2026 falls, and separates documented events from clearly labelled estimates. Read it before the integration phases: it is what makes the sequencing argument legible.
Choose a category
Four routes through the rest of the site. Strategy decides whether and in what order; Practice covers doing the work; Evidence lets you check any of it; About says who wrote it and what to read next.
Strategy
Start with where the technology stands, then the insurance opportunity, investment, sequencing, capability progression, economics, and governance.
Timeline · AI in insurance · Specialty & E&S · integration phases · Capability ladders · Costs & value · Governance
Practice
Write prompts that work, run agents safely, go as deep as the actuarial work requires, and see how agents build this site.
Hands-on use · Agentic work · Technical deep dive · Agents and this website
Evidence
The verbatim source passages behind the load-bearing claims, so any claim on the site is one click from its receipt.
About
Who wrote this site, the limits of that, and curated external reading.