Author the Runbook

Write your App's Runbook in plain English. Describe the workflow the way you would explain it to a new analyst on their first day. The platform compiles your Runbook into a structured workflow, and your analysts review the output.

You are not coding. You are encoding what your team already knows how to do.

Audience: builders

Open the Runbook tab

Inside an App, the Runbook tab carries two sub-tabs.

• Edit. The markdown editor where you write the Runbook.
• Review and Publish. A side-by-side compare between your latest saved draft and the currently-published version. Publish lives here.

The subtitle on the page says it plainly: "Edit the runbook, then review the generated workflow before you publish it live."

Start from the template

A new App ships with a starter Runbook.md that gives you the structure the workflow compiler expects:

• Purpose. What this App owns and the outcome it is responsible for.
• Triggers. The events, schedules, or manual actions that wake it up.
• Inputs. The files, Data Collections, MCP tools, and external systems it can rely on.
• Procedure. The operating steps the App should follow from start to finish.
• Guardrails. The approvals, safety checks, and escalation rules it must respect.

Keep the headings. The compiler reads them. You can add more sections, but losing one means the compiler may miss structure it could otherwise use.

Save, build, review, publish

The Runbook follows a loop. Each step has a clear feedback signal.

• Save. The editor saves on a debounce. Saving queues a fresh build ("Rebuild queued from the latest saved runbook.").
• Build. The platform compiles your markdown into a structured workflow. A status indicator shows ready when the build succeeds. If the build fails, it shows the error so you can act on it.
• Review. Open Review and Publish. Compare your draft to the currently-published workflow. Switch between the plain-language view and the detail view to see different lenses on the same change.
• Publish. When the build is ready and you like what you see, click Publish. The confirm dialog shows the impact summary, including what changes for in-flight work items, before the change goes live.

Discard or rebuild a draft

Two actions sit alongside Save on the Edit tab.

• Discard. Reverts the editor to the last saved value. Only your local unsaved changes go away; the server-side draft stays.
• Rebuild draft. Queues a fresh compile from the latest saved Runbook. Use this when a build failed transiently or when you want to retry the build without editing.

Reference Project context by name

Your Runbook can name the files, Data Collections, Integrations, and MCP servers attached to the App. The agent finds them by name at run time.

Make the names in your Runbook match what is bound in Context. If the Slack Integration is named "AP team", write "Slack: AP team" in the Runbook, not "the Slack channel". Specific names beat generic descriptions every time.

Patterns that scale

Most production Runbooks settle into one of a few shapes:

• Extract, validate, decide, post. For document-driven workflows: read the source, validate against the contract, decide on the action, post the result.
• Triage and route. For inbound work: classify the incoming item, decide whether to handle automatically or escalate, route to the right reviewer.
• Refresh and reconcile. For periodic work: pull the latest data, compare against the prior state, flag the deltas that need human review.

Pick the shape that fits your work, then write the Runbook against it.