What it does, and why each part exists

Several inputs, one graph

A Discord message, a nightly schedule and a webhook can all feed the same workflow. Each event runs only the part of the graph its own input reaches — so the schedule's digest branch does not re-run because somebody posted in chat.

Why it matters

The alternative is three near-identical workflows that drift apart, or one workflow that does three times the work on every event and bills you for it.

How it works

Every input is a named source. On an event AWO computes the forward-reachable subgraph from that source and runs exactly that — the same rule the run inspector shows you afterwards.

Who it is for

Anyone whose job has more than one trigger: a support channel that also needs a daily summary, a monitor that also accepts manual re-checks.

Batching, so a busy channel stays affordable

An input can hold events and deliver them together — by count, by time, or whichever comes first. Fifty messages become one run with fifty messages in it, not fifty runs.

Why it matters

A model call is the unit of cost. On a channel doing 300 messages an hour, a five-minute batch window is the difference between 7,200 calls a day and 96.

How it works

Two ceilings: maxEvents and maxWaitSeconds. The batch delivers when either is hit, so a quiet channel still reports on time instead of holding events indefinitely.

Who it is for

Anyone pointing an AI step at a chat channel, a webhook firehose, or anything else that arrives in bursts.

Try the calculator with your own numbers →

Branches, merges and guarded loops

One AI step's answer can decide which of three branches runs. Branches can come back together and read what actually arrived. A fix-and-retry loop can run until it passes.

Why it matters

Real work is not a straight line. A list of steps forces you to express "if this then that" as separate workflows, or not at all.

How it works

Conditions gate an edge; a merge node reports how many branches reached it and which. Cycles are allowed but always bounded — attempts, wall-clock time and spend — so a loop cannot run away with your bill.

Who it is for

Anyone whose process has an "unless", a "try again", or two things that have to finish before a third starts.

A run you can actually read

Every step keeps what it was given, what it produced, how long it took, and why it ran — including the steps that did not run and the reason they were skipped.

Why it matters

The hard question in any automation is not "did it fail" but "why did this step do that". A tool that shows only outputs makes you guess.

How it works

Every node records its inputs, outputs, duration and the edge that admitted it. A skipped step says which branch it belonged to, so absence is explained rather than silent.

Who it is for

Whoever has to work out at 9am why last night's run did nothing.

Open a finished run →

Errors written for a person

"The Discord message could not be sent because it has no message text. Open this step and fill in message text" — rather than a stack trace naming a function you cannot see.

Why it matters

Most automation tools report the condition the code checked. That is true and useless: it tells you what failed, not what to do.

How it works

Every failure names the step, what was wrong, and the next action. Where a value is missing, it says where a value could come from.

Who it is for

Everyone, and especially anyone who is not the person who built the workflow.

Caught before the model is called

AWO validates while you are still configuring: missing fields, references to steps that do not exist, an action wired to nothing, settings left over from a different action type.

Why it matters

A mistake found at edit time costs nothing. The same mistake found at run time costs a model call, a wait, and a confusing failure.

How it works

The workflow schema is the single source of truth, and the Studio checks against it continuously. Press Validate for the full report before you ever press Test run.

Who it is for

Anyone building their first workflow, and anyone editing one they wrote months ago.

Any model, including one on your own machine

Set a model for the workflow, or per step. Local Ollama, OpenAI, Anthropic, or your own endpoint. AWO ships no model and no keys.

Why it matters

Model choice is a cost and privacy decision, and it belongs to you. A hosted tool that only speaks to its own model makes both decisions for you.

How it works

A step can override the workflow's model — a cheap one for classification, a strong one for the summary that gets published.

Who it is for

Anyone with data that must not leave the building, and anyone watching the bill.

Off by default

Shell commands, filesystem access, git writes and code-writing agents each need a separate, explicit opt-in. A workflow file cannot enable them on its own.

Why it matters

A workflow you were sent should never be able to grant itself the ability to run commands on your machine.

How it works

Permission lives in your local setup, not in the document. Code-writing agents run in a sandbox and open a pull request rather than pushing.

Who it is for

Anyone running this on a work machine.

Read the full security page →

Project Autopilot, for software engineering work

A goal and a repository become a plan of phases you approve, then a pull request per phase — researched, built, reviewed and tested by composable cycles running on this same engine.

Why it matters

Pointing an agent at a repository usually produces one enormous diff and a claim that it is finished. A plan you edited and a PR per phase are both reviewable; a thousand-line diff is not.

How it works

The plan is a dependency graph, walked by the engine: next ready phase, run its cycles, gate on your tests, open a PR, repeat. Completion is a predicate over saved state, not a model saying "done".

Who it is for

Anyone with a backlog of well-defined work and a test suite worth trusting. Requires Pro, and a coding agent you connect yourself.

The full Autopilot page →