Reference files

Most real processes depend on a document. A price list, a policy PDF, an email template, a mapping spreadsheet that says which product code belongs to which team. You attach those to the workflow, and they become part of what the workflow IS rather than settings sitting beside it.

In the console they live under Knowledge, in the workflow's Apps panel. Drop a file in, or browse for it. Every file there is downloadable again later.

What you can upload

Any file up to 10 MB. The console suggests csv and pdf because those are the common ones, but nothing is rejected on type.

Names have to be unique within a workflow, because every file lands in one flat directory when a run starts. A few names are reserved for what the platform writes there itself, and a file cannot claim one of those.

Text extraction happens once, at upload

When you upload a file, the platform tries to pull readable text out of it right away:

• Text and markdown files pass straight through.
• PDFs go through a text extractor, page by page.
• Anything else carries no extracted text.

Extraction never blocks an upload. A scanned PDF with no text layer, an encrypted one, a binary format nobody can read: all of them still upload, still store, and still show up in the workflow's directory. They just have no text for an agent to read, so they are only useful to a step that opens the file itself.

How a file reaches a run

Two different paths, depending on what is doing the work.

An agent gets the extracted text folded into its instructions as a ## Knowledge section, one heading per file. That block is capped at 40,000 characters across all files together. When your corpus is larger, the block is cut at the limit and carries a visible truncation marker, so the agent knows it is reading a partial view rather than silently working from half a document.

A code step gets the file bytes written into its workspace before the step runs, so its code can open a template or parse a price list the way a person would. The workspace is rebuilt from the stored bytes on every execution.

Agentic runs get both: the text in the instructions, and the actual files in the sandbox next to a read-only copy of SOP.md.

Changing a file changes the workflow

Adding, replacing or deleting a reference file mints a new version of the workflow directory. That is on purpose. Replace the price list a step parses and the step is now wrong about the world, so the change belongs in the version history beside the code it affects.

Two consequences worth knowing:

• Re-uploading identical bytes does nothing. Same file, same digest, same directory, no new version.
• On a codified workflow you get asked a question first. A swapped reference might be this month's version of last month's file, or it might be a different kind of document entirely, and those look identical from outside. See editing and revising.

A run that is already going keeps the files it started with. Swap a file while a run is paused on an approval and the run resumes on the version it pinned, not on what you just uploaded.

Files a run wrote

Runs can produce files as well as read them. Those show up in the same panel under Outputs, described as files this workflow wrote.

An output file is quarantined. No later run sees it, and it is not part of any version, until you press Keep. That is what stops one run from quietly steering the next through a file it left behind. When you do keep one, its text is extracted at that moment and it joins the workflow's reference files like any upload.