Core concepts — the two heroes

In one line. An Agent does the work; a Collection holds the work. Everything else on the platform exists to configure, connect, supervise, or display those two. You’ll be able to. Read any screen in Studio and know which of the four pillars you are looking at — and why it exists.

Agent — the worker

An agent is a configured AI worker. Its definition is a handful of decisions, each one a tab in the agent editor:

Decision	Tab	What it means
Who is it?	Persona	Plain-language instructions: role, task, output expectations. You describe the worker; you don’t program it.
What does it think with?	Model	An LLM you registered, or Auto to let the platform route.
What may it read?	Knowledge	The collections attached as its grounding. This attachment is the access boundary — an agent cannot see what you don’t attach.
What can it do?	Capabilities	Tools, skills, and MCP servers. Every capability widens what the agent can act on — grant them deliberately.
What must it obey?	Guard rails	The rules and refusals layered onto every run.

You build one in A3 · Your first agent, test it in a live playground, and only then point it at real work. Agents come in varieties — answering, extracting, deciding, generating — covered in A4, and they compose into pipelines and teams when one worker isn’t enough.

Collection — the work

A collection is a typed home for records. The type decides its behavior:

• Processing collections hold work in flight — each document moves through a lifecycle toward a decision.
• Knowledge collections hold reference content — documents become readable knowledge the moment they land; there is no lifecycle. This is the grounding for Agentic Search.
• Structured collections hold rows — records with fields rather than pages.

Three things live on a collection and do most of the platform’s heavy lifting:

1. Schema — the fields you want out of every record (vendor, amount, due_date…). The schema is what agents extract into, what tables display, and what dashboards count. On this platform, the label set is the schema.
2. Taxonomy & tags — how records are classified and sliced.
3. Lifecycle — the stages a record moves through (New → Extracted → In review → Settled) and the automations that move it. Confidence gates live here: high-confidence work skips ahead; uncertain work routes to humans.

Details in D1 · Collections & schema and D3 · Taxonomy, lifecycle, tags & events.

The two surfaces

The platform has two faces, and knowing which one you’re on orients you instantly:

• Studio is where builders work: collections, agents, pipelines, experiences, governance. If you can configure it, it’s in Studio.
• The consumer surface is what your users get: the document workspace, cited chat, dashboards, the inbox. They never see Studio, and they never need to.

The four pillars, one sentence each

• Agents — hire and equip the workforce.
• Data — shape the collections the workforce reads and fills.
• Experience — decide what your users see and touch.
• Governance — decide who can do what, and prove what happened.

One concrete run, end to end

An invoice PDF lands in a Processing collection (ingestion — Data). The extraction agent reads it, fills the schema fields, and reports 0.97 confidence (Agents). The lifecycle automation sees the confidence and the matched PO and moves it straight to Settled; a low-confidence sibling routes to the review queue instead, where a person corrects one field and approves (Governance). The finance team watches both land in the workspace and the settled-per-week dashboard tick up (Experience).

That loop — ingest, think, gate, show — is the platform. Every chapter from here is a deeper look at one part of it.

Where to go next

Build the loop yourself in S3 · Your first 30 minutes, or go straight to the pillar you need in the sidebar.