Workflows Come to the Cloud: Running Multi-Agent Pipelines from the Browser

I've been building AI tools for three years now. Here's what I keep running into: most real work isn't a conversation – it's a contract.

You have the input (an article, a diff, a pile of CSV data). You know what the output should be (social drafts, a review verdict, a readable report). What you want in between isn't chat. It's a pipeline: specialists doing their parts, handing off to each other, with an auditor gating the result before it reaches you.

That's the core idea behind workflows in Octomind – our session-first, multi-provider AI agent runtime. And as of this week, those workflows now run in the cloud panel, not just the CLI.

Same pipelines. Same tap library. New surface.

If you've been running octomind workflow from your terminal, nothing changed – you just got a second way to do the same thing. If you haven't tried workflows yet, here's what I built and why I built it this way.

A workflow is a team with a contract

Every workflow in Octomind is a declared pipeline of steps. Each step is a full agent run with its own role. Steps can be sequential, parallel, conditional – or loops, which is where it gets interesting.

Take the promote workflow. You feed it an article. It turns that article into platform-native social drafts. Here's what actually happens:

  1. A researcher grounds the article in its source material
  2. A writer drafts per platform (Twitter, LinkedIn, whatever)
  3. An auditor checks each draft against quality gates
  4. If the audit fails, the draft loops back for re-editing
  5. The pipeline halts rather than shipping something the auditor rejected

Or review – it takes your unstaged diff and produces an independently verified verdict. Or report – it turns raw data into a decision-ready document where every number is computed, never invented.

There are fourteen of these in the public tap today. They're the same whether you run them from a terminal or a browser.

# CLI still works exactly the same
cat article.md | octomind workflow promote

Enter fullscreen mode Exit fullscreen mode

The full input goes in at the start – the whole brief, up to 256 KB of it – and the finished result comes out at the end. No steering mid-flight, no drip-feeding context. That's not a limitation; it's the point. You're not chatting with a team, you're commissioning one.

From library to running pipeline

In the cloud panel, the Library tab shows the catalog. Pick a workflow and the new-run screen asks for exactly two things: which machine, and your input.

The Dry run button is the part I'd point at first. It validates the workflow on the machine itself and renders the resolved pipeline – every step, every role, the loop caps – without spawning anything or reading your input.

It's free. It takes a couple of seconds. And it means a broken pipeline fails before a single token burns.

Starting a real run performs the same validation again on its own, so the button is a preview, not a chore. But I use it anyway. There's something useful about seeing the full pipeline shape before you commit to running it.

Then the run page becomes the thing worth watching: the whole chain renders immediately from the validated plan, and steps light up as the stream comes in. A checkmark when a step completes. A spinner on the one running. A pass counter on loops as the auditor sends drafts back.

You can close the tab and come back. The run belongs to the machine, not to your browser.

Artifacts: when output is a file, not text

Under the result there's a detail we're calling artifacts. Workflow deliverables are often files – promote writes drafts, report renders a document – and the final message names the paths.

The panel picks those mentions out and turns each one into a download chip, with inline previews for images and text. Nothing is fetched until you click – the mention is just a string until you ask for the file.

This is also the security posture: text can name a path, but only you can fetch one. Sessions got the same mechanic: when an agent in a chat says it saved something, the file is right there to grab.

Everything the run printed is kept, verbatim. The collapsible full log holds the validated plan, the machine-readable event stream, and the human progress view – downloadable, nothing summarized away. Step outputs get their own friendly view too, so you can read what each specialist handed to the next.

Honest one-shots: why there's no retry button

Here's a design decision I want to be explicit about: a workflow run has five states – queued, running, done, failed, canceled – and the last three are final.

There is no resume. No retry-in-place. No "continue from step 3".

The CLI has no such mode, and we didn't fake one in the UI. Partial re-execution of a pipeline whose earlier steps fed later ones is a good way to get confidently wrong output. If step 2 consumed step 1's output and step 5 consumed step 4's output, you can't just rerun step 3 without invalidating everything downstream.

So a failed run tells you plainly what went wrong – the actual stderr tail, not a shrug – keeps every completed step's output visible (that spend was real, and the work is often still useful), and offers exactly one recovery: Run again, which pre-fills a fresh run with the same workflow and input.

Your runs list is history you can trust: what ran, what it cost, what came out.

I'd rather give you a clean slate than a half-broken retry mechanism that produces garbage output.

What it costs: nothing new

There's no workflow fee and no new meter. A run's model calls flow through your account's hub key exactly like a session's – plan caps and credits decide, per published prices – and the machine bills per second while it works, like always.

The run page shows the aggregated cost the pipeline reported, so you can see what a promote actually costs you end to end. On the open models, it's typically cents.

Dry runs are free. And workflows are on every plan, free tier included – the free tier's one-at-a-time model calls just serialize the steps, which makes runs slower, not smaller.

Same contract as the CLI

If you already run workflows from the terminal, nothing changed and everything got a second surface. The panel drives the same octomind workflow binary on your machine, with the same tap resolution and the same machine-readable output contract the CLI exposes via --format jsonl:

# Machine-readable output
cat article.md | octomind workflow promote --format jsonl

Enter fullscreen mode Exit fullscreen mode

One event per completed step. One aggregated cost at the end. A pipeline you tested locally behaves identically in the cloud, because it is identical.

That's also the direction this is headed. Today the library is the public tap. The plan is for every account to get its own tap – personal workflows, edited in the panel with the same dry-run validation, distributed to your machines through the exact mechanism tap content already uses.

One distribution system, not two.

Why pipelines beat chat for production work

I want to zoom out for a second. Why build this at all?

Chat is great for exploratory work. You don't know what you're looking for. You want to poke around, ask follow-ups, change direction mid-conversation. A session – a conversation where you steer turn by turn – is exactly right for that.

But production work is different. You have a contract. Input in, output out. You want repeatability. You want auditability. You want to know that if you run the same thing tomorrow, you get the same result.

Workflows give you that. They're not better than sessions – they're different. And for a whole class of problems, they're the right tool.

Here's what I mean:

  • Chat: "Help me figure out what's wrong with this code"

  • Workflow: "Review this diff and tell me if it's safe to merge"

  • Chat: "What should I post about this article?"

  • Workflow: "Turn this article into Twitter, LinkedIn, and Mastodon drafts"

  • Chat: "Help me analyze this data"

  • Workflow: "Turn this CSV into a decision-ready report with computed metrics"

The chat version is open-ended. The workflow version has a contract. Both are useful. I use both. But they're not the same thing.

The technical bit: how the pipeline actually runs

Under the hood, a workflow run is a state machine. Each step is an agent invocation with its own context, role, and constraints. The pipeline orchestrates these invocations, passing outputs between steps, handling loops, and aggregating costs.

The event stream is the key. Every step completion emits an event. The panel subscribes to that stream and renders it live. That's how you see steps light up, how loop counters increment, how the final cost gets computed.

Here's what a simplified event stream looks like:

{"event": "step_start", "step": "research", "role": "researcher"}
{"event": "step_complete", "step": "research", "output": "...", "cost": 0.002}
{"event": "step_start", "step": "write", "role": "writer"}
{"event": "step_complete", "step": "write", "output": "...", "cost": 0.004}
{"event": "step_start", "step": "audit", "role": "auditor"}
{"event": "audit_failed", "step": "audit", "reason": "..."}
{"event": "loop_iteration", "step": "write", "iteration": 2}
{"event": "step_complete", "step": "audit", "passed": true, "cost": 0.001}
{"event": "workflow_complete", "total_cost": 0.015, "artifacts": ["drafts/twitter.md", "drafts/linkedin.md"]}

Enter fullscreen mode Exit fullscreen mode

The CLI and the panel both consume this same stream. That's why they behave identically – they're two different UIs over the same underlying contract.

What's next

If you haven't tried the cloud yet, it's open to everyone – no card, no invite. Create a machine, open Workflows, feed promote a blog post you like, and watch a team you didn't have five minutes ago argue itself into shippable drafts.

And if you're already running workflows from the CLI: nothing broke. Your taps still work. Your machines still work. You just got a browser option now.

The repo is at github.com/muvon/octomind. Apache-2.0, like everything we build. Pull it, run it, tell me what breaks.

This is the original article: Workflows Come to the Cloud