The Agentic Workflow pattern

In one line. A multi-step automation that processes work and decides — documents in, decisions out, humans approving only the edge cases. You’ll be able to. Recognize workflow-shaped problems, assemble the seven-part processing loop, and choose the right engine for the middle of it.

What it is

An Agentic Workflow is level 2 of the ladder. Where Search answers questions, a Workflow does the work: it takes each incoming document through extraction, validation and decision, routes the uncertain minority to people, and shows everyone the state of everything.

Choose this shape when the sentence in your head is “we process these every day and it’s manual” — invoices, claims, contracts, applications, tickets — and there is a decision at the end: settle, escalate, approve, route.

The processing loop

Same spine as Search (collection → ingest → agent), plus a lifecycle, a human, and an operations surface:

1. PROCESSING collection (+ lifecycle)
2. SCHEMA            — the fields to fill
3. INGESTION         — upload or connector
4. ENGINE            — agent / team / xflow / mesh, assigned as the collection's processor
        │ each document walks the lifecycle
        ├── 5. HITL INBOX        — exceptions; a human decides
        ├── 6. OUTPUT / EXPORT   — views, datasheet, export template
        └── 7. EXPERIENCE        — lists, inbox, dashboards for the operators

The build order matters less than the design order: schema and lifecycle first. They are the contract everything else fills.

1. Processing collection — Studio ▸ Data Model ▸ Collections ▸ + Collection, category Processing. (D1)
2. Schema — the fields a settled record must have: vendor, amount, po_match… (D1)
3. Lifecycle — the stages a document moves through, and the automations that move it: New → Extracted → In review → Settled. Confidence gates live here — this is where “humans only see the edge cases” is actually wired. (D3)
4. Engine — build the worker and assign it as the collection’s intake/processor. One agent for simple extraction; a team or mesh when steps deserve their own specialists; an XFlow when you need scheduled or branching pipelines.
5. Human-in-the-loop — route low-confidence or flagged documents to the Inbox; reviewers correct, approve, and their corrections become feedback.
6. Output — views and Datasheet for downstream consumption, export templates for other systems.
7. Experience — the workspace is live from day one; add dashboards for throughput, exceptions and aging.

Choosing the engine

Engine	Use when	Chapter
Single agent	One coherent job — extract and flag	A3
Team / mesh	Distinct steps deserve distinct specialists: classify → validate → enrich → approve → summarize, each lighting up live	A11
XFlow	Scheduled runs, fan-out, branching, cross-collection pipelines	A10

The platform’s reference example is the invoice settlement mesh: five decoupled members hand a baton down a durable bus, and the document’s Summary pane fills with the settled fields as each lane goes green. Loan underwriting, claims adjudication and contract review are the same shape wearing different schemas.

Worked builds, easiest first

Build	Teaches
B3 · Invoice settlement	The whole loop, smallest form — do this one first
B4 · Support intake triage	Routing, tags, inbox discipline
B5 · Contract review	Clause extraction, four-eyes review
B6 · SEC filings analyst	Scheduled XFlow pipelines over a public feed
B7 · Loan underwriting	Mesh engine, multi-collection, straight-through-processing gate

Do B3 even if your real target is B7. Every workflow is the same skeleton wearing different clothes, and the skeleton is easiest to see on the small one.

Where to go next

• Start building: B3 · Invoice settlement.
• The gates that keep humans in command: G2 · Human-in-the-loop.
• Outgrowing one workflow: the System pattern.