Workflows

A workflow is a process you draw instead of describe: one trigger, a set of steps (nodes), and the connections (edges) between them, laid out on a canvas. When the trigger fires, the steps run in the order you drew, each one receiving the output of the steps before it.

The studio

The editor has four surfaces:

• Step palette (left) — every step the runtime understands, grouped by category and searchable. Click or drag a step to add it; press Enter to add the first search match. When your graph has no trigger yet, the palette leads with trigger choices.
• Canvas (centre) — the graph itself. Drag nodes to arrange them, connect them to set the order.
• Dock (right) — four tabs: Configure step, Run history, Learning, and Build with Kaer.
• Console (bottom) — the Test panel: validate, simulate, and live-run.

Build your first workflow: a morning brief

Five minutes, four steps. The result: every Monday at 09:00 Kaer searches the web, summarises what it found, and emails you the brief.

1. Create it. Open Workflows and create a new workflow. Name it in the topbar — "Morning brief".
2. Add the trigger. With an empty canvas the palette shows trigger choices. Pick Schedule, then in the Configure tab set the cron expression to 0 9 * * 1 (Mondays at 09:00) and choose your timezone.
3. Add the steps. Search the palette for Web Search and add it; set the query to whatever you want tracked, e.g. latest developments in small modular reactors. Then add an AI Chat step and set its prompt to Summarise these findings as a short morning brief: {{ input }}. Finally add Send Email: bind your mailbox, set the To address and subject, and put {{ input }} in the body.
4. Connect them. Wire the steps in order so the chain reads Schedule → Web Search → AI Chat → Send Email. The graph saves automatically as you work.
5. Test it. Open the console and press Validate structure to catch structural problems, then run a Sandboxed test. Nothing leaves the app in a sandboxed run, so give the Web Search step a fixture (a canned JSON result) when asked — see Testing. Read the trace to check each step's input and output.
6. Publish. Press Push to production. The next Monday at 09:00 your brief arrives by itself.

The order matters: prove the flow in the sandbox first, publish second. A schedule multiplies whatever behaviour a workflow already has, good or bad.

Triggers

Every workflow has exactly one trigger — the palette hides trigger choices once you have one.

Steps and bindings

The palette groups steps into six categories:

• AI agents — AI Chat (system prompt, prompt, temperature 0–2, max tokens), Agent Task (runs a Kaer agent inside a project), Computer Task (drives the computer agent).
• Tools — Web Search, Send Email (from your own mailbox), HTTP Request, Page Reader, MCP Tool, and Memory Get / Memory Set — durable per-workflow memory that persists across runs, which is how workflows learn state over time.
• Connectors — Slack and GitHub Issue, using your connected accounts.
• Logic — Switch (if/else with true/false branches), Delay, Wait Until, Loop / Map, While Loop, Approval, and Sub-workflow (run another workflow's current graph with a hand-off input; cycles and deep nesting are rejected).
• Sources — Data Source, reading from a pinned revision of your data.
• Outputs — Notification and Output Webhook (POST the result somewhere).

Fields that point at your stuff — Project, Mailbox, Workflow — use a styled picker, not a raw dropdown. It shows the label and description of each option, and a Bound value footer with the raw ID underneath. This binding matters: agent and computer task steps require a bound project, and saving the graph fails with project_id must be a bound UUID until you pick one.

Template variables

Step fields resolve {{ }} references at run time:

• {{ input }} — the previous step's output.
• {{ steps.<id>.output }} — the output of any upstream step, by its ID.
• {{ params.<key> }} — a manual trigger's input parameter.

You don't have to type these from memory: text fields have a Reference inserter that lists every value the step can legitimately see, walking the graph upstream, and inserts the right expression.

Editing the canvas

• Autosave. The graph saves as you edit; the save indicator in the topbar tells you when it's dirty and when it landed.
• Rename in the topbar.
• On Failure policy per step, in the inspector: retries (0–5), timeout (5–1800 seconds, default 600), and a continue-on-error toggle so one failing step doesn't kill the run.
• Branches. A Switch step's true/false targets are wired in the inspector; the canvas shows the branch pills ("if true" / "else") on the edges.
• Insert on a connection. Click the + on an edge, pick a step from the palette, and it slots between the two nodes. Escape cancels.
• Node menu. Each node's kebab menu offers duplicate, configure, and delete.
• Tidy re-layouts the graph when it gets messy.

Testing

The console at the bottom of the studio has two modes.

Sandboxed is the default, and nothing leaves the app. Simulated runs make no real mail, network, token, write, or agent calls. Any step that would touch the outside world is stubbed and refuses to run unless you give it a fixture — a canned output, as JSON, keyed by step. When a simulation stops on a missing fixture you get a one-click stub to fill in (like n8n's pin-data). The Trace view shows every step's input, output, and provenance ("fixture (stubbed)" vs computed); the Logs view shows the log lines.

Live runs against your real accounts. It's only available for published workflows with a manual trigger — you can't accidentally live-fire a draft.

Two more tools: Validate structure checks the graph and lists findings in plain language ("Nothing starts this workflow — add a trigger first"); click a finding to jump to the offending step. And Test this step, in a step's inspector, runs just that node.

Common errors

Testing philosophy and security

The sandbox is deliberately fail-closed. Simulation runs in-process: side-effecting steps (mail, HTTP, writes, agent calls) are not partially executed and then cleaned up — they are never executed at all. Without a fixture, the run stops with SIMULATION_FIXTURE_REQUIRED rather than guessing. Values that pass through the trace are redacted and bounded (large payloads are truncated), and the trace itself is capped, so a simulation can never leak or amplify secrets. The honest consequence: a green sandboxed run proves your graph and data flow are right, not that the real accounts will cooperate — that's what the gated Live mode is for.

Publishing and versions

Workflows have two states. The draft is what you edit on the canvas. Push to production validates the graph and snapshots an immutable live version — that's what schedules, mail events, and webhooks actually fire against, and the topbar chip shows it (Live · v3, or Paused · v3). You can keep editing the draft without touching production, and pause or resume the live version at any time.

The Run history tab in the dock lists every execution, and above it the version history: restore any earlier version as a draft, review it, and push it again to roll back.

Build with Kaer

The Build with Kaer tab in the dock is a chat that designs the workflow for you. Describe the outcome — "digest my unread mail every morning at 8 and send it from my mailbox" — and it asks clarifying questions when it needs to, then writes the draft straight onto your canvas.

Under the hood it works in tools, not prose: it can list your workflows, search the step catalog, and save a full declarative spec — a trigger plus steps, each declared with uses (the step type), with (its config), needs (upstream steps), label, retries, and onError. Then it closes the loop itself: it calls validate_workflow and simulate_workflow on the draft, fixes what comes back, and only then hands it over. What you receive is a tested draft — you review it on the canvas and publish when you're happy.

Build with Kaer is a paid feature. On a free plan the panel shows the upgrade path, with manage-billing for existing subscribers.

Templates

The Templates tab is a gallery of 24 ready-made workflows across eight categories: Mail & Inbox, Reporting, Monitoring, AI Agents, Integrations, Engineering, Marketing, and Assistants. Each card shows the trigger type, complexity, rough setup time, and the integrations involved.

• See Preview opens the real graph — nodes, edges, and config — before you commit.
• Use template creates a draft in your account. If the template runs an agent step, it auto-binds your first project (you need at least one project for those templates).
• The bookmark saves a template for later; a Saved tag appears in the filter row so you can see just your shortlist.

Filter by category, trigger type, or complexity; sort; search by name or description. Templates are the fastest way to a working workflow — take one, rebind the accounts, test, publish.

Limits and plans

Workflow count is capped per plan:

Hitting the cap returns a clear error telling you to upgrade or delete an existing workflow. Templates you instantiate and workflows Build with Kaer creates both count toward it.

Learning

The Learning tab in the dock shows what the harness has learned from this workflow's real runs: per-step reliability, classified failure patterns, and evidence-backed repair proposals — bounded patches you can apply with one click, each one audited. The diagnostics policy controls how aggressive the learning is. This only gets useful after the workflow has some real run history; an untouched draft has nothing to learn from yet.

Troubleshooting

The Catalog

The Catalog view (Workflows → Catalog) lists the pre-built workflows: 28 entries across six categories — Frame & Route, Transformation, Generation, Orchestration, Evaluation, and Task Execution. Kind tabs filter the list (All / Standard / Agent), and search narrows it by name or description. Each card shows the name, a kind pill, a one-line summary, the argument count, and the default token cap. Pressing Run → opens a form generated from that entry's argument schema, so you only fill in what the workflow needs.

There are two kinds:

• Standard entries run one focused step — classify, summarize, revise and the like — and return structured output.
• Agent entries are multi-step pipelines that decompose a big job and run it on budgeted sub-agents: deep-research fans work out over several angles, plan-tasks → run-tasks builds and executes a dependency graph, goal loops until a judge passes, and debate, tournament, and red-team run adversarial sub-agents against each other.

Running a catalog entry creates a managed workflow instance that inherits the entry's kind. Each run re-builds the instance's steps from your inputs, which has one consequence worth knowing: manual edits to a catalog instance are overwritten on the next run. To customise the steps, duplicate the instance into a standard workflow and edit that instead.

Every catalog run has a token budget — each entry ships with a sensible default, and overrides are clamped to between 500 and 200,000 tokens. If a run exhausts its budget mid-pipeline it settles with partial results rather than failing, marked with a "results are partial" note. Both the App Agent and the Computer Agent can also discover and run catalog entries directly, with workflow_search and workflow_run.

Good to know

• Do scheduled runs cost credits? Yes — every run is metered the same, whether you triggered it or the schedule did: the LLM usage plus a small workflows surcharge. See Billing and Usage.
• Where is the history? Every run, with full step results, is in Activity, and in the studio's Run history tab for the workflow you have open.
• Templates, catalog, or Build with Kaer — which first? If a template is close, start there. If a catalog entry does the job, running it is cheaper than building a canvas. Otherwise describe it to Build with Kaer, and only hand-build when you want full control.
• When is a workflow the wrong tool? When the work is one-off or still taking shape. Run it as a normal agent turn first, and promote it to a workflow once the steps have stabilised.
• Can someone else follow my workflow? That is half the point — the canvas is the documentation. A colleague can read the nodes left to right and understand the process without reading any prompt text.
• Can an agent step use my own tools? Yes. Custom tools, MCP servers and skills you registered in Customise are available to agent steps like anywhere else — an Agent Task can call your own endpoint, and a skill applies when the step's request matches its conditions.
• Can I trigger a workflow from outside Kaer? Triggers cover webhooks and schedules. To drive the agent itself from a script or a cron job, use a personal API key — see Account API.