Runs when you click Play
Running ops automations at
What do you want to build?
Get started with some examples
Automate a recurring task Build a weekly digest Track follow-ups
Read recent #sales messages and drop anything already handled
If → Triage questionsIf → Summarise run
Pick the messages that are real knowledge questions worth answering
If → Research and draftIf → Summarise run
Answer each question from Brainfish knowledge and draft a Slack reply
If → Deliver drafts
brainfish docs/search
Close out a run that found nothing to answer
DM the reviewer each draft and log it for the audit trail
Go from a sentence to a running workflow in five minutes
Most of what a workflow gets quoted at is plumbing: field mappings, API calls, retries. Ballet does all of it, and you check what it built before it runs.
- 01
Describe it
Say what you want to happen, which systems it touches, and the rules it has to follow.
- 02
Review the build
Read every step in plain words before it runs. A model reads the ticket; fixed rules move the money.
- 03
Connect the systems
The integration is written as part of the build — your internal billing service as readily as Salesforce.
- 04
Run it end to end
Every step runs the same way each time, and checks its own assumptions as it goes.
- 05
Keep the controls
Choose which steps wait for a person. The gate lives in the workflow, so nothing can route around it.
Open any run and read what happened
Every step, how long it took, who held the gate, and the check that spotted a schema change before anyone filed a ticket about it.
PlayRunsCode
Total runs48
Successful runs47
Per run4 credits
Total consumption502 credits
| Status | Run ID | Triggered by | Duration |
|---|---|---|---|
| Completed | c41f9e02… | webhook:salesforce | 9.0s |
| Completed | 5e8d2b71… | webhook:salesforce | 14s |
| Completed | 9a07f6c3… | slack:jess.f | 11s |
| Failed | 2d6b8e14… | webhook:salesforce | 31s |
| Completed | e7c3a9d5… | webhook:salesforce | 8.4s |
Completedc41f9e02-7a3b-4d1e…
Steps (5)
- deal-closed102ms
- get-call1410ms
- draft6812ms
- approvewaited 12m
- post611ms
Output
{
"account": "Ironhouse Gym",
"owner": "Priya Shah",
"amount": 48000,
"posted": true
}Reach the system nobody has documented
Every step is real code Ballet wrote and can refactor or debug on request. That's why the hard workflows are possible: anything you can reach with an API, a database, or an MCP server, a step can do.
read-new-messages.ts
package.json { } Format
const { channelId, lookbackHours } = input_data as Input;
// --- read the channel, and keep only the real questions ---
const since = Date.now() - lookbackHours * 3_600_000;
const history = await slack.tool("conversations_history", {
channel: channelId,
oldest: since / 1000,
});
// --- skip anything a past run already answered ---
const handled = await tables.handled.find({ channelId });
const seen = new Set(handled.map((row) => row.ts));
const questions = history.messages.filter((m) =>
!m.bot_id && !seen.has(m.ts) && m.text.trim().endsWith("?")
);
// --- note them, so the next run skips them too ---
await tables.handled.insert(questions);
return questions.map((m) => ({
ts: m.ts,
user: m.user,
text: m.text,
}));Logs
Ask it to change something
Generate a step from a description, refactor the one you're looking at, or hand it a bug.
Reach anything
APIs, databases, MCP servers, off-the-shelf connectors, and the internal service with no docs.
Simulate before you ship
Run one step against sample input and read its output and logs without touching the rest.
Leave a workflow running for a week
Ballet spins up a database the moment a playbook needs one, so it can run for days, pick up where it left off, and leave behind a record the next playbook reads. Nothing to provision, no schema to design.
| id | T sessionId | T question | T reason | # confidence | T citations | T status |
|---|---|---|---|---|---|---|
| test-session-escalate-1789158039441 | test-session-esc… | My invoice from L… | no_knowledge | 0 | Empty | open |
| test-session-escalate-2-178915819 | test-session-esc… | My invoice from L… | out_of_scope | 0.15 | Managing subscri… | open |
| no-session-1789159820748 | Empty | How do I reset m… | No matching KB a… | Null | Null | open |
| sess_test-1789159851801 | sess_test | How do I reset m… | No matching KB a… | Null | Null | open |
| no-session-1789160117228 | Empty | How do I reset m… | No matching KB a… | Null | Null | open |
Data Structure + Row Filters Columns 1–5 of 5
Long-running work survives
A workflow that runs for days keeps its state in a table rather than in one process's memory.
Shared between playbooks
What the escalation playbook recorded is what the weekly summary reads. No export step in between.
A record you can query
Every run leaves rows behind, so the history is something you can filter rather than reconstruct.
Hand the finished playbook to everyone else
A workflow gets approved once. After that it's available in the browser and in Slack, and nobody running it needs to open the workflow.
Platform
Build and run the workflow
Where a workflow gets written, reviewed, and watched once it's live.
You're here
Chrome extension
Run playbooks beside the tab you're in
A side panel next to your CRM or helpdesk. Ask for something, or type / and pick a playbook.
Chrome extension →
Claude connector
Build and run playbooks inside Claude
Connect Ballet in Claude and ask it to run a playbook, read what happened, or build a new one.
Claude connector →
Slack agent
Tag Ballet where the work already happens
Mention Ballet on a message, or send it a DM. The result posts back in the thread.
Slack agent →You can read it before it runs
Every step says what it reads, what it changes and when it waits for a person, and you put a gate in front of the steps that warrant one. The code is there for anyone who asks to see it. Every run is logged and replayable. Ballet is covered by Brainfish's SOC 2 Type II and ISO 27001 compliance.
What would you hand to Ballet?
Pick one workflow your team still does by hand. We'll build it and show you it running on your systems.