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 tools each step uses, and where the process waits on someone.

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.

When several components work toward the same thing, they can be grouped into a named skill — "Manager Notification", say — with a line describing how it usually runs, like "runs once, then waits for a reply". A stage with a dozen components becomes three or four named groups you can read at a glance.

The agent sees those groups too, and it takes them as intent rather than instruction. It still decides what to do and when, so a skill described as a daily check won't stop it acting sooner when something needs attention.

Stages¶

A stage groups related work and carries guidance: plain-English instructions for how the work in that stage should go. Guidance is where your business rules live: "chase a missing receipt before approving", "use the rejection email if the request was denied". A stage that waits on somebody is a hand-off.

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), each branch carries a plain-English condition for when it's taken — "the manager approved", "no reply within 48 hours" — and the runner picks one path at runtime from those conditions and the data collected so far. Branches can re-converge later, and hovering a stage on the canvas shows the conditions on its neighboring stages.

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.

Hand-offs¶

Most stages do their work and move on. A hand-off is a stage that waits for a person instead: an approval, a review, a form somebody fills in.

When a run reaches one, Malleable reaches out on the channel that person already uses — email, Slack, Teams — and pauses there. If they need to fill something in, the message carries an authenticated link to the form, so they need no account and no password. If you've named a channel for the stage (below), the form is simply there for them to answer — though it's usually still worth reaching out, since a wait nobody was told about is the common reason a run sits untouched. The stage won't complete on its own until someone responds — unless you give it a deadline (below).

Who gets reached doesn't have to be fixed when you build the workflow. The same stage can notify a different person on each run, from an address or handle the run collected earlier.

A hand-off can also carry a deadline: if no one responds within the delay, the wait is satisfied on its own so the run can move on to the next stage instead of waiting indefinitely. It can send a reminder before that point too, if you asked for one when the hand-off was set up.

Who sees a run¶

People see a run through a channel: a named view, read either on a web link or in a Slack or Microsoft Teams conversation. You name each one — "the Requester", "the Manager" — and say which stages it reads, and how much of each: its messages, how the answer was worked out, the form it puts in front of someone, or the record of what each component did. One channel can follow a run across several stages.

Channels are optional. Without any, everyone who can open a run sees all of it. Once a workflow has one, each stage is seen only by the channels you show it to.

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 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"). It can also require something of the data already collected ("every reviewer approved"). Each such condition is required or best-effort. A best-effort condition can't hold the run up indefinitely: the agent waits while something is still working to produce the data, and if it still isn't there once that finishes, moves on without it, following whatever you told it to do in that case. 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. A required check on collected data can simply fail (nobody approved), so the stage before it needs a second branch to take when it does.

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. Each value can also carry its own description — what it means and what format it should take, checked when the value is stored — written once on the value rather than repeated in stage instructions. 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 can be marked secret: agents never see them, they're injected straight into the action that needs them.