Custom Workflows

​

Overview

A custom workflow is a reusable, step-structured procedure that you and Dexter run again and again — a scheduling pass, a weekly quality audit, a recurring report, a data-refresh-and-compare cycle. It captures how your operation runs the process: the order of steps, the constraints that matter (and how much), the judgement calls, the scripts that do the deterministic work, and the sign-off gates. Custom workflows persist across conversations, appear in the Workflows section of the Dexter sidebar automatically, and improve run over run through a built-in reflection loop. The first run of a new workflow is rarely perfect — it becomes so as Dexter absorbs your corrections into the workflow’s own files.

​

When a Workflow Is Worth Creating

• You run a recurring operational process — daily, weekly, monthly, per-order — and want it standardized so it runs the same way every time.
• You’ve just finished a complex multi-step task with Dexter that you’ll want to repeat.
• You want a future Dexter session (or a teammate) to execute the process the way you would, without re-explaining the operation from scratch.

One-off analyses don’t need a workflow. Anything you’ll run more than a handful of times probably does.

​

What a Workflow Contains

A workflow lives as a small directory of files that Dexter reads at execution time: The workflow’s name has to be unique — it can’t duplicate a built-in procedure’s name — and its directory is kebab-cased. Dexter handles both when it sets the workflow up. Two structural rules apply to every workflow:

1. Step 1 is always the day-of conditions intake. Before touching any data, Dexter asks what’s different about this run — equipment down, deliveries missing or late, labor short, rush orders. Operational conditions change daily and the data rarely says so; this step is how those changes enter the run.
2. The final step is always reflection. After the deliverable is out, Dexter reads the run’s learnings, proposes concrete improvements to the workflow’s files, and applies them only after you approve.

​

Creating a Workflow with Dexter

Tell Dexter you want to save a process — “make this reusable”, “create a workflow for our weekly quality audit”, “standardize the way we build the daily schedule.” Dexter may also propose creating one on its own after you finish a complex multi-step task it can tell you’ll repeat; either way, nothing is written until you confirm. Dexter draws the process out of you before writing anything. Expect questions about:

• The goal — what the process produces, who consumes it, what “done” looks like
• The steps as you run them today — in order, with inputs and outputs per step
• The data sources each step touches — and which ones you trust
• The constraints — for each one, how much it matters: a hard rule that’s never violated, a soft preference weighted by how much you care, or data that looks like a rule but should be ignored
• The judgement calls — where you decide by feel, with example decisions and the reasoning behind them
• What varies day to day — so the conditions intake asks about the disruptions this process is actually sensitive to

Dexter then lays out the structure, writes the README, auxiliary docs, and scripts, and reads the procedure back so you can confirm the step headings and gate placements before it goes live. The workflow is available immediately in the same conversation and appears in the Workflows section of the Dexter sidebar automatically.

​

Starting from the New Workflow Dialog

You can also start from a template. Click the + next to the Workflows section heading in the Dexter sidebar, or open the + menu in the message composer and choose Workflow, then Create a workflow. The New workflow dialog offers two templates:

• ETL pipeline — ingest files, transform them with deterministic scripts, and produce a dataset every run. You describe the Sources, the Transformation, and the Output, and can add Validation checks (optional). The result is a data pipeline, shown on the Data page’s Pipelines tab.
• Custom workflow — describe any repeatable procedure under What should this workflow do? and Dexter structures it.

Give it a Name, fill in what you know, and optionally pick Source files (optional) from your uploads and Integrations (optional) Dexter should look at. Create workflow sends the request to Dexter, which asks clarifying questions in chat before writing the workflow.

​

Gates: How Dexter Checks In During a Run

A gate is a checkpoint where Dexter shows you an intermediate result and waits for your approval before the next step consumes it. Dexter summarizes what was produced and the choices that shaped it in its reply, in a report, or as the artifact itself in the platform, then asks a short approval question. Approve, or reject with a comment telling Dexter what to change. New workflows carry more gates than mature ones. Every gate is a course-correction point: the feedback rescues the current run and feeds the improvement loop. A gate only comes out when you ask for it; the reflection step may propose removing one once runs are consistently clean, but the decision is yours.

​

Reflection and the Improvement Loop

At the end of every run, Dexter reviews where you corrected it mid-flight, where a script caused friction, where an instruction was ambiguous enough to force a guess, and what information the workflow’s files didn’t carry. It translates that into concrete edits — a new hard constraint, a soft preference regraded, a judgement example added, an ambiguous instruction rewritten — and presents them as a proposal. Over enough runs, this loop is what converges a workflow toward autonomous execution.

​

Running a Workflow

From chat — ask for it by name: “Run the daily production schedule.” Dexter picks up the workflow, walks the steps in order, records learnings as it goes, presents gates at the checkpoints, and closes with the reflection step. Long runs maintain a visible task list so you always know which step is in progress. You can also type / in the message composer to pick a workflow, or choose one from the composer’s + menu under Workflow. The active workflow shows as a chip in the composer; click its × (Remove workflow) to clear it. From the Workflows section — the Workflows section of the Dexter sidebar (the left panel of the Chat page) lists every custom workflow in the factory, each with a status icon (Running, Awaiting input, or Inactive); the sidebar’s search box filters it by name. Click a workflow to open its detail page:

• Run — start a manual run now; it appears under Recent Runs, and you can open it from there once it’s going
• Steps tab — the workflow’s Overview (what it does) and its step headings from the workflow definition
• Files tab — the files that make up the workflow (README, auxiliary docs, scripts), which you can view, copy, or download
• Recurring — a toggle for running the workflow on a schedule (where scheduled jobs are enabled). Turn it on, pick a preset such as Weekdays at 05:00 or build a Custom cron expression, and click Enable schedule. The schedule runs in your browser’s timezone; Edit changes it and turning the toggle off pauses it.
• Recent Runs — each run with its status; open one to see the full conversation it executed in
• Latest Output(s) — the deliverables the most recent run produced

Runs are ordinary Dexter conversations, so every gate, tool call, and output remains reviewable after the fact.

​

Custom vs. Built-In Procedures

ProDex ships built-in procedures for the recurring shapes of work Dexter supports everywhere — building a simulation model, comparing scenario runs, generating a report, BOM explosion and configuration, CAD analysis, and planning runs. Dexter follows those automatically when the task calls for them; they don’t appear in the Workflows section and you can’t edit them. Custom workflows are yours: they encode your operation’s specifics and evolve through the reflection loop. When a built-in procedure almost fits but needs your operation layered on, create a custom workflow that leans on the built-in from its steps.

​

Limits and Caveats

• Scoped to the active factory. A workflow runs against whichever factory you’re in; a process that spans factories needs a workflow per factory.
• Gates are non-optional until you remove them. Dexter won’t skip a gate to save time. If a gate asks for something a run doesn’t produce, flag it in the run so the reflection step can fix the workflow.
• Learnings are per-workflow. What Dexter learns running your daily schedule workflow doesn’t transfer to the weekly audit workflow. Cross-workflow knowledge belongs in the knowledge base.
• The step order is a contract. Steps run strictly in order — no skipping, reordering, or merging. Where a step legitimately branches, the branch is encoded explicitly in the step’s instructions.