Choose a starting point
Begin with Foundations to understand the technology and its recent history. Then use Strategy to plan an investment or Practice to try a task.
Foundations
Start with the AI basics below: what LLMs are, how context helps, and where the technology falls short. Then follow the timeline of capability, insurance adoption, and regulation before moving into strategy.
Strategy
Ready to plan? Explore the insurance use cases, then use the phased plan and use-case ranking to choose a pilot, an owner, and a measure of success.
Practice
Trying AI at work? Complete a worked first task, check the answer, then adapt a template. Actuaries and analysts can continue to the technical deep dive.
Evidence
Checking a claim? Read the source passages and corrections, and distinguish reported results from forecasts before using a number in a decision.
About
Assessing this guide? Read about its purpose, the author's background, and its limits, or find external reading.
Foundations · AI basics · Everyone · ~17 min
Submissions, loss runs, policy wording, claims files, and broker correspondence are natural starting points for AI-assisted document work. The aim is a useful draft or structured record that a person can check against the source.
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. Give the model the task, relevant source material, and the standard its answer must meet. Context is one lever you control; model capability, retrieval quality, and verification also matter. Adding more text can make relevant information harder to find, as Anthropic's context-engineering guidance explains.
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.
Terminology, one line each
Definitions before the sections that use them. The three carrying the most weight below are context engineering, skill, and agent.
| Term | Plain-English meaning |
|---|---|
| LLM / foundation model | A general-purpose AI model trained on vast text; the "engine" (e.g., GPT, Claude, Gemini). Left to itself it answers the question in front of it and stops |
| 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 | The same engine given a goal, tools, and a loop: it plans, acts, reads what comes back, and continues until the job is done or a limit stops it. What separates an agent from a general model is that scaffolding, not a stronger engine |
| 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.
Retrieval can miss a relevant clause, and a model can misread or miscite a passage it receives. Compare the answer with the retrieved text before relying on it.
Why the fourth level compounds
A skill packages instructions, scripts, and resources for reuse. The host loads its instructions when relevant; the file persists between runs. That gives a team a procedure it can version and improve, but does not guarantee that the model will select it or follow it correctly. Test each revision before making it the team's default.
Skills mix reasoning with determinism
In a workflow, code determines the sequence; in an agent, the model can choose the next action. Both can combine model calls, scripts, checks, and human review. Anthropic's workflow and agent patterns describe this distinction. A skill makes a procedure reusable; the surrounding system must enforce its permissions and release checks.
Two ways to encode a procedure
Code can fix the route through a task, or a model can choose the next step. Either design needs an explicit path for exceptions.
Deterministic pipeline
Design an exception path: reject an unsupported input or send it for review.
Agent with a skill
Check the model's choices as well as its output. Versioned scripts can make fixed calculations repeatable.
What it does well, and where it fails
Five useful tasks and five failure modes to check
Match the control to the failure. Put calculations in tested code, evaluate model judgments, and keep a named reviewer for consequential output.
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. Use tested code
- They are non-deterministicThe same question can return a slightly different answer, which is what makes reproducibility and audit hard. Test repeated runs
- They fabricateA fluent answer can contain invented facts. Require source passages and compare each claim with them; a valid output format does not establish factual accuracy. 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
These are controls to test, not guarantees. Code can repeat a wrong calculation, and a checker can miss a false claim. Measure errors on representative work before reducing human review.
What the engineering actually is
Separate fixed calculations from model judgment, and verify both:
- Put arithmetic and data manipulation in tested code. Review the formula, inputs, units, and edge cases. Keep the code and data needed to reproduce the result.
- Evaluate variation in model output. A versioned skill fixes the procedure you supply, but model decisions can still vary. Run representative tasks repeatedly, record errors, and enforce failed-check stops in the surrounding system.
For fabrication, compare the answer with its sources. For prompt injection, restrict tool access and enforce approval before consequential actions. For bias, test outcomes across relevant groups. Sample accepted outputs as well as flagged exceptions so you can see what the checks miss.
Agent evaluation guidance describes repeated trials and complementary code, model, and human graders. Use these methods to assess the whole workflow; packaging instructions is only one part of it.
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.
Continue from the foundations
Next, read the timeline to put the concepts in historical context. Then explore insurance use cases and build a strategy, or try the worked exercise. Before using company data, check your approved tools and the rules in Governance.