Docs

Everything you need to run your first agent team.

Getting started

• Sign up at /login — email and password, or GitHub/Google OAuth when enabled.
• Pick a model. The included starter model needs no key. For anything serious, add a provider key at /settings (OpenRouter, Anthropic, Google, Groq, and other OpenAI-compatible hosts are supported). Keys are encrypted at rest and never shown again.
• Create an agent on the Agents page — describe what you want, or drag nodes and edges by hand. Every agent lands on the same live canvas.
• Run it — manually, on a cron schedule, or from a webhook. Watch each hop stream in real time.

Core concepts

Graphs, nodes, edges

A graph is a team of agents. Each node is an agent with a role (supervisor, worker, router, reviewer), a model, a system prompt, and a tool set. Edges decide who runs next: explicit edges fire on conditions, auto edges let the model pick the next specialist by name, and consensus edges fan out to several agents at once and join on an aggregator.

Runs and live editing

A run executes the graph hop by hop — one BullMQ job per hop. Chat turns and runs started from the canvas are live: each hop re-resolves against the graph as it is right then, so a drag changes the next hop of the run you are watching. Saving that route is a separate choice; until you do, later runs are unaffected. pinned mode, the default for schedules and webhooks, snapshots the graph at launch so that run is reproducible.

Approvals

Any node can carry an approval gate: the run parks at /approvals with the pending payload visible, and continues only when a human approves. Use it before anything irreversible — publishing, sending, paying.

Tools

• MCP servers — connect any MCP endpoint; the allowlist and per-server allowedTools keep the model inside exactly the tools you grant. Credentials come from /settings, never from node config.
• File access — read_file/list_directory confined to a per-node root.
• Sub-agents — a node can SPAWN runtime-defined specialists that fan out and rejoin.
• HTTP endpoints — call allowlisted REST APIs (e.g. the GitHub API) as tools.
• UX probe — ux_probe renders a site in a real browser (light, dark, reduced motion, phone width) and returns accessibility and layout findings as text, one line per problem. The agent names a site the operator configured, never a URL, and the probe shows up in the run like any other step.
• Memory — agents can propose durable memories a human applies or rejects.

Triggers

Cron schedules and webhook triggers live on the graph. Schedules auto-disable after repeated no-entry skips instead of silently burning budget; webhooks get a per-trigger token URL for external systems to fire.

API access

Everything the app does goes through the same REST API you can call directly. Create a personal API key at Settings → API keys — it's shown once at creation, then only its hash is stored. Send it as the X-Api-Key header; a key authenticates as you, so it can do exactly what your account can — a member's key keeps that member's access.

• Launch a run — POST /runs with { graphId, input }; poll GET /runs/:id for status and output. API-launched runs start pinned, so they snapshot the graph like a scheduled firing.
• Publish a graph as an MCP tool — a graph's owner sets its MCP slug in the graph's settings, and POST /mcp/serve/:slug then speaks MCP JSON-RPC: tools/call launches a pinned run. Opt the slug into public access to serve unauthenticated callers.

Where to go next

• Try the live demo — a scripted model drives the real engine; steer it mid-run.
• Templates — ready-made agent setups including the self-improvement loop.
• Pricing — the Solo/Team split and how hosted-key metering works.
• Migrate from Flowise or from Agent Builder — import what you have rather than redrawing it.
• Changelog — what shipped recently.
• Status — live service health.