Learn the role and settings of each node and you can automate most repetitive document work. Connect them visually in the agent builder to shape your own pipeline.
Parse
Converts any document format into text β the starting point of every agent.
Classify
Sorts documents into your document types, and can split them with Split mode.
Extract
Pulls the fields defined in your schema, as structured data.
Instruct
Takes the results and summarizes, transforms, validates, or decides.
Parse
Parse is the starting point of every pipeline. It converts PDFs, images, Office documents, HWP files β any format β into machine-readable text (HTML and Markdown).
When do you use it?
- In every agent β every file goes through Parse, and the downstream nodes take its output as their input.
- Scanned documents and images are read with OCR; text documents are converted with their structure analyzed.
- It is especially useful when you need the content of tables, charts, and equations with their structure intact.
Main settings
The basic settings only contain the model, which is configured automatically for your document β leave it as is. The options below appear once you open Advanced settings.
| Setting | Options | How to choose |
|---|---|---|
| Mode | Auto / Basic / Advanced | Auto: picks the best mode per page Β· Basic: clean, well-structured documents Β· Advanced: complex layouts with many visual elements |
| OCR | Images only / Always | If scans and photos are mixed in, or recognition quality is disappointing, choose Always |
| Language | Auto / English / Korean / Japanese / Chinese | If the document language is fixed, naming it is more accurate |
| Nightly | Checkbox | Only if you want to try the latest experimental build first. New features land here first, but stability isn't guaranteed and it can change without notice |
Other advanced options
| Setting | When to turn it on |
|---|---|
| Chart recognition | Documents where the numbers inside charts matter (performance decks and the like). Converts charts into tables. Enabled automatically in Advanced mode |
| Merge multi-page tables | When a table continues across pages (financial reports, settlement sheets) β merges them into one table |
| Coordinates | Returns the coordinates of each element. Use it when you need to trace or audit where a value came from |
| Output format | HTML (check layout) / Markdown (feed into prompts) / Text (plain review) |
| Image extraction | Only when you also need the pictures and charts inside the document as images |
| DPI | PDF conversion resolution β 150 (default) / 200 / 300. Raise it for documents with small type |
Checking the result
Parse results are shown in Preview Β· HTML Β· Text Β· Markdown Β· JSON tabs. Watermarks are removed automatically.
If recognition quality disappoints, try these in order β β switch OCR to Always β β‘ switch Mode to Advanced β β’ raise DPI to 300 β β£ replace the file with a sharper original.
"Parse is the agentβs input normalizer β whatever the document format, it becomes text the downstream nodes can read."
Classify
Classify sorts a mixed pile of documents into document types you define yourself. It is the branching point that lets you apply a different schema and different handling per type.
When do you use it?
- When several kinds of documents arrive mixed together β receipts, contracts, invoices.
- When the same kind of document needs a different schema per vendor.
- When one PDF contains several documents that have to be handled separately (splitting).
You can skip Classify if all your documents are already one type and share a single schema.
Defining document types
Add the names of the types you want, and write a description for each. The description is the prompt the model classifies with, so the clearer and more specific it is, the more accurate the result.
| Field | Example |
|---|---|
| Type name | Domestic receipt, Overseas receipt, Tax invoice |
| Description | A receipt showing a Korean business name and an amount in KRW β spell out whatever is easy to confuse |
- Auto-generate (Beta) β Generates document types from your uploaded documents. Select the cases and click Auto-generate. It may take a while.
- Reuse a setup β Document types built in one agent can be reused in another. Save them with Export as JSON, then Import JSON in the other agent and the types, descriptions, and Split settings come across intact. Treat a well-tuned classification setup as a team standard.
Always add an "Other" type. Without an escape hatch for documents that belong nowhere, the model will force them into an existing type and cause misclassification. If you classify FedEx and UPS invoices, add an Other type for anything that is neither.
Hierarchical classification
Document types don't have to be a flat list. You can define up to three levels to organize a large number of types systematically.
- Click Add sub-level on a type row to add types beneath it (three levels maximum).
- For example: Invoice (level 1) β Courier invoice (level 2) β UPS shipping invoice (level 3).
- The description at every level is used as a classification prompt, so put broad criteria at the top and specific distinctions further down.
- After a run, the classification tree in the results shows which branch each document landed in.
- Design rules β leaf type names must be unique across the whole tree, and every intermediate level needs at least one child. If you only have a handful of document types, one flat level is plenty.
Fixing classification errors
- Edit only the description of the type that's wrong. Leave the ones that work alone.
- Descriptions are natural language, so refine them iteratively. You can state conditions too, e.g. "FedEx invoices over $10,000".
- You can also combine two levels of criteria inside a single Classify node β splitting into UPS shipping invoices and UPS non-shipping invoices gets you finer granularity without adding another node.
Split β Classify's second mode
Classify runs in two modes: the default mode, which only classifies, and Split mode, which first divides a case (one file or a bundle) into individual documents and then classifies each one. Both take the whole case as input; the difference is the unit of processing.
| Mode | What it does | Suited for |
|---|---|---|
| Classify only | Treats the whole case as one document and assigns it a single type | One document per case |
| Split, then classify | Divides one file or file group into several documents, then classifies each | Several documents mixed into one file or group |
Split criteria
| Criterion | Behavior | Suited for |
|---|---|---|
Auto-detect documents Recommended | Treats the input as one stream and cuts wherever a new document starts | Most cases β start here |
| Split by file | Separates a combined file along its original file boundaries | Scanned bundles where separate files were merged |
| Split by page | Classifies each page while keeping page order | Bulk scans of one-page receipts or forms |
| Split by page, then group by type | Classifies each page, then groups pages of the same type together | Pages of the same document arriving out of order |
| Custom | Define your own split rule β cut at pages containing a given word, or every N pages | When you have a clear marker like a company name or date |
When splitting by an identifier, test thoroughly. If you split on invoice number, check the results to make sure the model isn't looking at a similar field such as a tracking number instead.
"Classify is the junction that routes a mixed pile of documents into type-specific lanes β so every node after it can behave differently per type."
Extract
Extract pulls specified fields β names, amounts, dates β out of a document as structured data. The heart of it is schema design: defining what to pull and how.
When do you use it?
- When you need specific fields from a document as structured output such as a table or JSON.
- When the same fields must be extracted consistently from documents that repeat the same layout.
Building a schema
A schema is a list of the fields to extract. Each field has four properties.
| Property | What it is | Example |
|---|---|---|
| Name | The field identifier (up to 100 bytes) | vendor_name, total_amount |
| Description | The prompt you give the model (up to 1,000 bytes) β the single biggest lever on accuracy | The vendor name at the top of the document |
| Type | The data type of the value | String / Number / Boolean, and so on |
| List | Check this when the same structure repeats | Line items, work history |
For repeating row groups β several fields forming one set, like line items β use Add table to define a group table.
Reuse your schemas. Save a finished schema with Export fields as a JSON file, and one Import fields from JSON in another agent brings the same names, descriptions, and types across. Treat a carefully tuned schema as a team standard.
Writing good descriptions (mini-prompting)
The description field is a prompt sent to the model. Use it for these five things.
| Purpose | Example |
|---|---|
| Locate | The vendor name, usually at the top left of the document |
| Include / exclude | Exclude corporate suffixes such as LLC or Inc |
| Format | A dollar amount including decimals down to the cent |
| Disambiguate | Use only the amounts in the line-item detail, not the summary table |
| Normalize | Format dates as YYYY-MM-DD |
Don't skip the table description. Group tables have a top-level description too. Something like "the line items from the detailed billing section, not the summary table" is what lets the model find the right group of data.
Mapping schemas to document types
If there is a Classify node upstream, connect each document type to the schema that should apply to it. For example: domestic receipts β the Korean-field schema, overseas receipts β the English-field schema. You can also leave a type (such as "Other") unmapped so it is skipped.
Don't casually change the schema structure of a production agent. If extraction results feed a database, adding or removing fields or changing types can break the data pipeline. In production, improve accuracy mainly by editing descriptions, and coordinate structural changes with whoever owns the database.
"Extract lives or dies on schema design β the more precise the field names and descriptions, the more reliably the AI finds the right value."
Instruct
Instruct is the node you give natural-language instructions to. It takes the previous node's output and does post-processing: summarizing, transforming, validating, deciding.
When do you use it?
| Purpose | Example |
|---|---|
| Normalizing data | $1,000 β 1000; standardize dates to 2026-01-05 |
| Comparing against a baseline | Compare extracted contract terms with your standard terms and flag deviations |
| Summarizing | Condense a document or a set of extracted fields into a structured brief |
| Validating | Cross-check business rules β e.g. "line item amounts must sum to the invoice total" |
| Deciding / branching | Pick one of a fixed set of decisions such as approve or reject |
Choosing a type
- Generate only β Returns a free-form text response following your prompt. Right for summaries, translations, and transformations where no fixed decision value is needed.
- Generate and decide β Makes a judgment and picks one of the options you defined in advance (for example, approve or reject). Downstream nodes can branch on the decision value.
Writing the prompt
In the prompt box, type @ to reference an extracted field from an upstream Extract node, and # to reference
the decision value of another Instruct node.
Three ingredients of a good prompt β β state the criteria as numbers and conditions
("please review" β β "reject if the total exceeds 10,000 KRW" β), β‘ reference upstream results with @field_name,
β’ spell out the output format you want.
Where to place it
- After Extract β normalize, validate, and judge the extracted fields (the most common placement).
- After Classify β summarize or route by document type without extracting anything.
- Standalone (after Parse) β a general-purpose LLM prompt over the whole document.
Rather than handing a whole document to a general-purpose LLM, letting Extract handle document understanding and Instruct handle post-processing means the transformation and judgment happen on clean, verified data β which produces markedly more reliable results.
"Instruct is the agentβs decision engine β pull upstream results in with @ and normalize, validate, and make the final call."
Not every workflow needs every node β see Use cases for how the four nodes are assembled into real work.