StellarBase
Docs StellarBase Platform Workflows
StellarBase Platform

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 scheduleThe task is interactive / conversational
Output feeds another system (CSV, DB, email)Output is read by a human
You need exactly the same processing each timeThe user shapes the request each time
You need to parallelize over many itemsSingle one-off question
An auditor needs the trace of how the answer was producedCasual 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

TriggerUse case
Schedule (cron)Nightly oversight, weekly reports, monthly billing
New documentProcess every new file in a folder
WebhookExternal system POSTs to trigger
Manual / on-demandUser clicks “Run” in the UI
Workflow chainAnother workflow finishes
Email arrivalNew 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