The workflow¶

A workflow is one repeatable business process (customer onboarding, expense approval, a manufacturing checklist) captured so it can run again and again, the same way each time.

You don't write it alone. You describe the process, and the architect (the agent you build the workflow with, see Building workflows) models it with you: the way you'd sketch a flowchart on a whiteboard with a coworker, asking questions and redrawing as you go. The result is a diagram on a canvas: stages left to right, the people involved, and the tools each step uses.

That diagram isn't a picture of the software. Once you publish it, it is the software: every run executes the workflow you drew. The rest of this page is what a workflow is made of.

Stages & components¶

A workflow is organized into stages, the phases of your process, in the order they happen. Each stage holds components: the concrete building blocks that do the work. The component reference lists every type; this section explains how they fit together.

Here's a small example, a daily customer-meeting digest (this is the same live diagram you work with in the product):

The cards are stages; the chips inside each are its components; the arrows show the order they run in.

Stages¶

A stage groups related work under one responsible actor and carries guidance: plain-English instructions for how the work in that stage should go. Guidance is where your business rules live: "escalate if the amount exceeds $5,000", "use the rejection email if the request was denied".

Traditional workflow tools make you spell out every condition, branch, and loop. Malleable doesn't, because every run is carried out by the runner agent (the AI that executes the workflow, see Running workflows). It reads your guidance and applies judgment the way a capable coworker would, so plain instructions are enough.

Stages connect to their successors explicitly. A stage with no successor ends the workflow; one successor always advances to the next stage. When a stage has several successors (a fork, like the approve vs. reject split in the diagram above), the runner picks one path at runtime based on the guidance and the data collected so far. Branches can re-converge later.

For work that should run in parallel or in isolation, say one ticket per attendee, workflows use sub-workflows instead of forks.

How the runner uses components¶

Some parts of a workflow are settled when you build it, and some are decided fresh on each run. A component like "send the approval email" does the same thing every time: it sends that email to whoever the run says it goes to. What varies (the name, the amount, the recipient) fills in as the run gathers it.

The runner handles the judgment that can't be settled in advance: which branch to take, what to write in a free-form message, when to ask a clarifying question. When two situations genuinely need different content, like an approval notice versus a rejection notice, those are two separate components, and the runner picks the right one during the run.

Actors & hand-offs¶

Every stage has an actor: the person or role responsible for it (or "system" for background steps with no human involved). When the next stage belongs to a different person, Malleable hands off to them automatically: it generates an authenticated link (no account or password needed), notifies them, and pauses the run until they act.

Sub-workflows¶

A sub-workflow is a workflow run as a step of another one. It's how you break a large process into pieces, each with its own stages, actor, and hand-offs, and how you run work in parallel.

The most common shape is fan-out: run the same sub-workflow once per item, like one review per approver or one audit per project. Each runs independently, so different people can work their part at the same time.

A later stage can wait for the results before it begins ("summarize once all four reviewers have responded"). Since people don't always respond, a sub-workflow can carry a time limit: when it's reached, the run continues with whatever came in.

The Sub-workflow component covers the configuration in detail.

Data flow¶

As a run progresses, it gathers facts: who submitted the request, what amount, which decision was made. Malleable calls this collected data, and it's declared explicitly: each workflow defines what it collects, where each value comes from, and which components consume it. Explicit wiring is what lets the workflow be validated before it runs, instead of failing mid-run on missing data.

A stage can't complete until its required data has actually been gathered, so a run can't quietly skip a step that some later part of the process depends on.

Sensitive values like API tokens and passwords can be marked secret: agents never see them, they're injected straight into the action that needs them.