Skip to main content
A Document Lens is agentic document processing: teach it once what to pull out of one kind of document — invoices, applications, drawings — and every document comes back as structured data your stack can query. You show it a few representative documents, review the layout and fields it finds, approve them once, and then it just runs. The approved configuration becomes a frozen, versioned contract. Two callers naming the same lens and the same document get the same answer, and next quarter reads like this quarter.
Document Lens is currently in beta. It lives inside a Room — open the Lens surface from the room’s surface switcher, next to Chat, Playbooks, and Memory.

​
Why a lens

Reads complex documents

Dense tables, handwriting, stamps, and any language — it looks at the page, not just the text layer underneath.

Costs a fraction to run

Agreed once — ten thousand documents become ten thousand bounded model calls, not ten thousand open-ended conversations.

Built for your stack

One API call, one token, and a table of results at an address that does not move.
And on the hard ones — scanned, annotated, badly photographed, inconsistent, not all in one language:
  • It checks its own work. Say the line items must add up; every reading is tested first.
  • It says when it is unsure. When the page disagrees with itself you get told, not a quiet guess.
  • It reads any language. Dates and numerals are normalised, whatever script they arrive in.
  • Versioned, not silently changed. Edit the schema and the version bumps. Old readings still hold.

​
Building a lens

1

Show it a few documents

Click Build a lens on the Lens surface. Pick the lens purpose — Extract fields, Classify documents, or Extract images — describe what these documents are, and point it at the data source holding a few representative examples (two or three of the messy ones). You can optionally list the fields to read up front, and choose whether this lens will read a few documents at a time or a corpus, repeatedly.
2

Approve the fields

The lens reads your samples and proposes the layout it found and the fields worth extracting. In the lens workbench, review the proposal on the Contract tab — field names, types, which are required, and the checks that must hold. Fix what it got wrong, then approve the configuration as the contract every reading uses.
3

Point the pile at it

It reads the rest, and everything that arrives after them, without being asked again. Use the Evaluate tab to read documents and inspect results, and the Runs tab to follow batch runs.
You approve a lens once, then it just runs. Changing the schema afterwards bumps the contract’s version rather than silently changing it — readings made under the old version still hold.

​
Reading modes

A lens serves its readings in one of two modes, chosen on the lens’s configuration pane:
  • Auto — approve a schema for your documents, then read them all the same way. This is the default and right for most lenses.
  • Playbook — bind a Playbook that serves the lens, for readings that need a custom multi-stage process behind the same contract.
A lens shows its readiness at a glance — Not built, Needs approval, Needs a parse, Not serving, or Ready. A lens still being agreed is listed but cannot be called yet.

​
Two ways to run one agreement

You pick the serving per call, not per lens — read the hard one properly while somebody waits, and read the other ten thousand overnight, off the same agreement, at the same version, producing the same fields.

​
What a reading returns

Every reading answers with the same structure:
If missing_required names anything, the lens could not read this document — report that rather than treating a partial reading as a complete one. The fields that did come back look exactly like a good answer.

​
Calling a lens from your stack

You agree the fields in the product, in about the time it takes to check them by hand once. After that it is an API your code owns, reachable over MCP: A few facts that make integration easy:
  • One bearer token authorises the upload, the run, and the read.
  • Readings land in one table at an address that does not change.
  • Fields come back as JSON, so a schema change bumps a version instead of breaking your reader.
  • Failures are rows too — you can query which of last night’s documents did not come back.
A lens serves one document at a time. For a corpus, run the lens’s batch workflow and read the table it writes — a tool call per document over a large pile is slow, expensive, and not what the batch serving is for.

​
Where a lens sits

A lens turns documents into columns; what happens to those columns is the rest of the platform. Accumulate what your lenses read into a Virtual Memory you can query, keep the extracted tables current with a scheduled Workflow, and give your own agents extract_document as a tool they can simply call.

Virtual Memory

Accumulate what your lenses read into a graph or a space you can query.

Workflows

The batch serving behind a lens, keeping the extracted tables current.

Document Digitization

The parsing actions available on the workflow canvas.

Playbooks

Bind a playbook to serve a lens with a custom process.

Agents

Give agents lenses as tools they can call.

MCP Overview

Call lenses from your own applications.