Workflows
Deterministic pipelines that orchestrate agents, tools, and data into repeatable processes. Same inputs produce the same outputs, every time. Visual editor or agent-built — your choice.
🛠 In active development — Q3 2026. The model and node types described here reflect what we're building. Visual editor, agent-built definitions, and external triggers become available throughout Q3 2026.
What a workflow is
A workflow is a directed graph of nodes. Each node does one thing: fetch data, transform it, call an agent, route based on a condition, write output. Edges define the data flow.
Workflows are deterministic — given the same input, the same workflow produces the same output structure (modulo the LLM’s natural variance). This is what separates a workflow from “let an agent figure it out”. Workflows are auditable, repeatable, and parallelizable.
When to use a workflow vs. just an agent
| Use a workflow when… | Use just an agent when… |
|---|---|
| The task runs on a schedule | The task is interactive / conversational |
| Output feeds another system (CSV, DB, email) | Output is read by a human |
| You need exactly the same processing each time | The user shapes the request each time |
| You need to parallelize over many items | Single one-off question |
| An auditor needs the trace of how the answer was produced | Casual exploration |
Node types
Source nodes
Where data comes from. New documents in a watched folder, rows from a database query, webhook payloads, scheduled tick.
Processing nodes
Pure transformations. StellarOCR on a document, language detection, anonymization, schema validation, type coercion.
Agent nodes
Invoke a configured agent with the upstream data. The agent’s output (structured per its schema) flows downstream.
Model nodes
Call a specific model directly — your custom classifier, an external API, a local LLM. Cheaper than full agent invocation when you don’t need reasoning.
Routing nodes
Conditional branching. “If risk_level == HIGH, route to compliance approval; else route to standard output.”
Approval nodes
Human-in-the-loop gates. Workflow pauses; designated reviewer approves / modifies / rejects; workflow resumes (or terminates).
Output nodes
Where data goes. CSV file, database row, email, Slack notification, webhook to an external system.
Building a workflow
Visual editor
Drag nodes onto the canvas, connect with arrows, configure each node’s parameters. Live validation prevents invalid graphs (cycles, type mismatches, missing required fields). Test with sample inputs before going live.
Agent-built
Describe the workflow in plain language to an orchestrator agent: “For each new contract uploaded to the M&A folder, run StellarOCR, detect the contract type, route to the appropriate reviewer agent, and produce a risk register row.” The agent generates the workflow graph; you review and adjust.
Triggers
| Trigger | Use case |
|---|---|
| Schedule (cron) | Nightly oversight, weekly reports, monthly billing |
| New document | Process every new file in a folder |
| Webhook | External system POSTs to trigger |
| Manual / on-demand | User clicks “Run” in the UI |
| Workflow chain | Another workflow finishes |
| Email arrival | New message matching a filter |
Determinism & reruns
Every run is recorded with its inputs, intermediate outputs, and final result. You can rerun any past run with the same inputs and verify the output is consistent. If you change the workflow definition, the version is bumped — old runs reference the old version, new runs use the new.
Reruns are useful for:
- Bug verification (did our fix produce different output?)
- What-if analysis (would the new prompt have flagged this case?)
- Backfill (run the new workflow against historical data)
Parallelism
Workflows that process many items (1,000 contracts, 4,000 patient reports) parallelize automatically. The platform decides the concurrency based on rate limits and your tier. You see total progress and individual item status.
Error handling
Per-node retry policies (default: 3 retries with exponential backoff). Persistent failures route to a dead-letter queue with the failure reason. The workflow continues with other items — one bad input doesn’t halt the run.
For workflows where partial completion isn’t acceptable (financial close, audit reports), configure “all-or-nothing” semantics: any failure rolls back all outputs.
Observability
For each run:
- Start time, end time, duration
- Per-node duration (find slow steps)
- Token usage (LLM cost attribution)
- Error count, retry count
- Output preview
Trends across runs (weekly run took 1h yesterday, 3h today — what changed?) help you tune.
Sharing & permissions
Workflows are Base-scoped. Within a Base, you control who can:
- View the workflow definition
- Trigger on-demand runs
- Edit the workflow
- Approve human-in-the-loop gates
Examples from the case studies
- Legal: contract ingest → anonymize → classify type → route to specialist agent → annotate Word + risk register row
- Finance: policy ingest → anonymize → extract structure → route by line → portfolio comparison row
- Medicine: EHR pull → PHI anonymize → case summary → guideline + literature → tumor board packet
- Manufacturing: SCADA telemetry → CMMS context → anomaly model → equipment specialist agent → work order
- Government: beneficiary report → anonymize PII → classify programme → ESF+ / Procurement / Anomaly agents → compliance register
Related
- Agents — building blocks of workflow logic
- Chat — invoking workflows conversationally
- Collaboration — approval flows
