Every real intake queue has a long tail. Most documents fit a known type — an ACORD, a loss run, an exposure workbook — but a meaningful slice don’t: a broker’s bespoke summary, a one-page addendum, a cover letter with the key term buried in it, a document type you simply haven’t configured yet. Template-based tools have one answer for all of them: unsupported. The document falls out of automation and lands in a human’s lap with zero structure extracted — and the long tail is often 10–20% of the volume.
InsightXtract doesn’t treat “no matching class” as a failure. It treats it as a different mode. An unclassified document is routed through the same agentic extraction engine — just without a rigid spec — using what the system already knows about the project to guide it.
What “context” means
A document isn’t truly context-free just because it lacks a class. The project it arrived in tells the agent a great deal, and freeform extraction feeds that in as hints:
| Context signal | What it tells the agent |
|---|---|
| Project name & description | The domain and purpose — e.g. “Excess Casualty submissions,” so it looks for insured, limits, exposures. |
| Sibling document specs | The fields and tables the configured classes in this project care about — a strong prior for what matters here. |
| Reference data in scope | The glossaries and lookups bound to the project, so even freeform values get standardized. |
So a broker’s one-off summary in an excess-casualty project isn’t read blindly — the agent knows to surface insured name, requested limits, and exposure figures, because those are what this project’s other documents extract.
document class?} C -->|yes| SPEC[extract to the
class spec] C -->|no| FF[freeform extraction
project desc + sibling specs
+ reference data as hints] SPEC --> OUT[structured result
+ confidence + provenance] FF --> OUT
Both paths converge on the same kind of output — structured fields and tables, each with confidence and a source citation — and run through the same reasoning loop, validation, and post-processing. Freeform isn’t a lesser pipeline; it’s the full engine with a softer spec.
From freeform to first-class
Freeform extraction is also a discovery tool. When a new document type keeps showing up in the long tail, its freeform results show you exactly what fields it carries — which is the head start for promoting it to a real document class in the builder. The dead-end becomes a backlog of candidates to formalize, in priority order by how often they appear.
Reassign when you’re ready
If a freeform document turns out to be a known type — or you build a class for it — it can be reassigned to that class and re-extracted to the full spec. Nothing is stuck in a lesser state; freeform is a floor, not a ceiling.
Why it matters
- The long tail automates too. The 10–20% of documents that break template tools still yield structured data — instead of all landing in manual entry.
- No hard dead-ends. “We don’t support that” stops being an answer; the worst case is lower-confidence structure, not zero.
- New types surface themselves. Recurring freeform documents become a prioritized list of classes worth building.
- Consistent output. Freeform results carry the same confidence and provenance as classified ones, so downstream systems treat them uniformly.
Read next →
See how a recurring freeform type becomes a real agent: config-driven agents. And the engine both paths share: the reasoning loop.