Extracting insurance documents well is not a generic problem. A loss run has valuation dates and reserves that must reconcile; an ACORD form has a fixed grid and a form number that means something; a financial statement has scale traps ($ vs. $000s) that flip a number by three orders of magnitude. A generic extractor doesn’t know any of this. You can pour it all into one giant prompt — but that prompt becomes an unmaintainable wall of caveats, applied to every document whether relevant or not, impossible to test or version.
InsightXtract takes the opposite approach. Domain expertise is broken into skills — small, self-contained playbooks, one per document family — and the agent loads only the ones a given document needs. Each skill carries not just guidance but invariants: rules the agent can mechanically check.
What a skill is
A skill is a spec, not code — a named playbook for one document family that bundles: the signals that identify it, the reasoning guidance for reading it, worked examples, and the invariants that must hold. Here’s the shape, using the loss-run skill:
Multi-year claim experience: per-claim rows with date of loss, paid, reserved, incurred, valuation date.
If per-claim figures don’t reconcile to the printed total within ±$1 rounding, keep the printed values and add a does_not_reconcile note — never “fix” a number to force the math.
incurred_reconciles: sum(claims.paid) + sum(claims.reserve) == total_incurred
That reconcile-don’t-fix rule is exactly the discipline an experienced loss-run reviewer applies — now written down once, versioned, and enforced on every loss run the platform sees. The financial-statement skill similarly encodes the scale-ambiguity rule (lower confidence and flag when $ vs. $000s is unclear). Expertise that used to live in people’s heads becomes an explicit, testable asset.
Progressive disclosure: only what’s relevant
The agent doesn’t carry every skill at once. Early in the reasoning loop, a routing step matches the document to its family and loads just those skills — so a loss run gets the loss-run playbook, an ACORD gets the form playbook, and neither is burdened with the other’s caveats. This keeps the working prompt small and focused, which is both cheaper and more accurate than one monolithic set of instructions.
reconcile invariants] RT -->|ACORD| S2[load acord_form skill
grid + form-number rules] RT -->|financials| S3[load financial_statement skill
scale-ambiguity rule] S1 & S2 & S3 --> EX[extract with the
right playbook applied]
| Skill | Encodes |
|---|---|
| loss_run | Reserves & incurred reconcile; valuation date; multi-year experience. |
| acord_form | Fixed grid layout, form-number semantics, what the form implies. |
| financial_statement | Scale traps ($ vs. $000s), totals foot, printed-value fidelity. |
| insurance_binder | Coverage & limit conventions, effective/expiration handling. |
Why skills beat one big prompt
- Maintainable. Adding expertise for a new document family is adding a skill, not editing a fragile mega-prompt every other document also depends on.
- Testable & versioned. Each skill is a discrete artifact with its own invariants, so you can validate and version domain behavior independently.
- Focused and cheaper. Loading only relevant skills keeps the prompt small — better accuracy, lower cost, than carrying every caveat on every document.
- Auditable domain logic. The rule that a loss run must reconcile isn’t buried in a prompt — it’s a named invariant you can point to.
Machine-checkable, not just advisory
The difference between a skill and a prompt tip is the invariant. “Loss runs should foot” is advice; sum(paid) + sum(reserve) == total_incurred is a check the engine runs, that triggers a re-extract or a flag when it fails. Skills turn tribal knowledge into rules the system enforces.
Where they came from — and where they’re going
Skills are how domain teams contribute to accuracy without touching the engine. As reviewers correct extractions and patterns emerge (“this carrier’s loss runs always put reserves in the last column”), that knowledge can be captured as a skill or an invariant — making every future document of that family a little more accurate. It’s the mechanism behind self-improving agents: expertise, encoded once, applied at scale.
Read next →
See the invariants in action: self-checking extraction, the loop that loads them: the reasoning loop, and how corrections become new skills: self-improving agents.