The AI workflow builder
that pauses for humans.

An AI workflow builder lets you wire multi-step automations visually — but Aerostack's nodes are AI-native, not bolt-ons. The 30 node types include an autonomous agent loop, LLM reasoning, MCP tool calls, guardrails on model output, confidence-based routing, identity verification, and human-approval gates as first-class primitives. n8n and Zapier were built for deterministic SaaS plumbing and treat AI as one more HTTP step; an agentic workflow on Aerostack makes the LLM the decision-maker — it picks the branch, calls tools from any MCP server in your workspace, and pauses for a human when a step crosses a policy line. Everything runs on Cloudflare's edge, so a workflow that calls three tools and an LLM still returns in well under a second. If your automation is purely deterministic — no reasoning, no branching on model output — you don't need a workflow at all; ship a single edge function instead.

A human handoff node pauses a running workflow and routes an approval request to a designated person before any sensitive step executes — a refund, an outbound message, a write to a system of record. The workflow holds its state on the edge and resumes exactly where it left off once the reviewer approves or rejects, with the decision logged. You approve from the dashboard or from the OpenClaw mobile app, so an agent can run unattended and still never take an irreversible action without a human in the loop. This is the same approval primitive that governs tool access in an Aerostack workspace — workflows, bots, and direct agent calls all share it.

Aerostack ships 30 node types covering the full agentic loop: Trigger, LLM Call, Agent Loop, MCP Tool, Call Function, Action (HTTP / set variable), Send Message, Send Proactive, Schedule Message, Delegate to Bot, Logic (if/else), Loop, Parallel, Code Block, Error Handler, Sub-Workflow, Auth Gate, Confidence Router, Guardrail, Structured Output, Knowledge Retrieval, Wait / Delay, LLM Router, Memory Store, Vision Analyze, Document Parse, Image Generate, Data Transform, and Function Call. The standouts: the Agent Loop runs an autonomous reason-act-observe cycle and is what makes a workflow genuinely agentic; the Guardrail enforces policy on LLM output before it reaches a user; the Confidence Router branches on how sure the model is; the Sub-Workflow lets you reuse a flow as a building block; the Auth Gate verifies identity before a protected step; and the MCP Tool node calls any tool from any server in your workspace. You compose them on a visual canvas — no YAML, no glue code — and the same graph runs identically in draft and production. New node types ship regularly as the agentic-workflow patterns mature.

Yes — this is the core of agentic workflow automation on Aerostack. The MCP tool node connects to any MCP server installed in your workspace (Stripe, GitHub, Notion, your own, or anything from the marketplace) and executes a tool call mid-workflow, feeding the structured result into the next node. Because a workspace already composes many MCP servers behind one authenticated URL, a single workflow can read from your CRM, write to your database, and post to Slack without you wiring three separate integrations. The LLM node can also pick which tool to call at runtime, which is what separates an agentic workflow from a fixed pipeline.

Workflows execute on Cloudflare Workers at the edge: no servers to provision, automatic global scaling, and near-zero cold start, so steps begin in milliseconds from the nearest location to your user. There's nothing to deploy or keep warm — publish a workflow and it's live worldwide. Execution is metered against your plan's AI token allowance (the free tier includes 500K tokens a month), and you can bring your own model key to drop the platform markup to zero. State is persisted between steps on the edge, which is what lets a human-approval handoff pause a run for minutes or hours and resume cleanly.

Yes. Every workflow has a draft and a published version, so you can edit safely without touching what's live, then publish when ready and roll back if needed. Reusable logic goes into subflows — a sub-workflow you build once and call from many parent workflows, so a shared approval or enrichment routine stays in one place instead of being copy-pasted. This is what keeps larger automations maintainable: a 25-node flow becomes a handful of named subflows you can test and reason about independently.

Workflows are the engine underneath both. An Aerostack bot is a workflow with a messaging front end — the same auth gates, human handoffs, and MCP tool calls, delivered across WhatsApp, Telegram, Discord, and Slack, with bot-to-bot delegation between them. And the workflow builder sits inside the broader agent-automation layer: an AI agent, given the Aerostack MCP URL, can generate, test, and publish a workflow for you from a single conversation. So the visual builder is for when you want to design the logic by hand; agent automation is for when you want an agent to build it.

When the task is fully deterministic. If there's no reasoning step and no branching on model output — a fixed transform, a scheduled sync, a webhook that always does the same thing — a single edge function is simpler, cheaper, and faster than a workflow graph, and Aerostack functions give you the same edge runtime with database, cache, and AI bindings built in. Reach for an agentic workflow when you genuinely need an LLM to decide the path, call tools dynamically, or pause for human approval. Roughly: if you can draw the logic as a flat checklist with no 'it depends', it's a function, not a workflow.

Yes. Every workflow has a built-in analytics view: total runs, success rate, average and maximum duration, total tokens consumed in and out, and the dollar cost of those tokens. A per-node breakdown shows runs, average and max duration, error count, and token cost for each step, so you can pinpoint exactly which node is slow or expensive rather than guessing. You can scope all of it to a 24-hour, 7-day, or 30-day window and see the run-status breakdown of completed, paused, and errored runs. This is the observability that tools like n8n are known for, available without wiring up any external monitoring.

Yes. The workflow marketplace is a community library you can browse by category — customer support, sales, automation, research, data, devops, and general — with featured workflows surfaced at the top. Preview any workflow to see its node graph, then clone it into one of your bots in a click and customize from there, which is the fastest way to start instead of building from a blank canvas. You can also publish and share your own workflows with the community. Cloning and publishing are free; this is about sharing reusable automations, not selling them.

The Parallel node fans out to multiple branches simultaneously and waits for all (or the first) to complete before merging results and continuing downstream. This is the difference between checking three inventory warehouses sequentially — 3× the latency — and checking all three at once and acting on the first available result. In ai agent workflows it matters most when an LLM step needs data from several independent sources at once: you fan out to parallel MCP tool calls, collect the structured results, and feed the merged payload into the next LLM node. Multi-trigger convergence is related but distinct: multiple inbound trigger sources (a bot message, an API call, a webhook) can all converge into the same workflow graph, so you maintain one piece of logic instead of duplicating it across trigger types.

A sub-workflow is a workflow you build once and call from many parent workflows using the Sub-Workflow node. It is the equivalent of a function in code — encapsulate shared logic (an approval sequence, an identity-verification round trip, a data-enrichment step) into a named subflow, test it independently, and reuse it everywhere without copy-pasting nodes. This is what keeps large ai workflow automation projects maintainable: a 30-node flow becomes four or five named subflows that you can reason about in isolation. Every subflow has its own draft/published versioning, so updates to a shared subflow propagate to all callers when you publish — no tracking down duplicates. Reach for subflows as soon as you see yourself building the same five-node sequence in two different workflows.