Pro Brainers customize their workspaces in code. Spawn automations that read your brain, call any LLM, write to boards, and fire integrations — sandboxed, with cost caps, and human-in-the-loop for risky writes.
Automations are triggered periodically or on new brain memories. They can read and write to boards, trigger LLM calls with full brain context, and call integrations directly. Sandboxed by default, with cost caps and an audit log on every call.
// docs · automations→Inside an automation you have four handles — brain, boards, llm, integrations — wired into the same MCP your team uses. Compose them however the work demands. Cost is metered per call and per run; exceed your cap and the run stops cleanly.
Cron is a fine trigger. But sometimes you want an automation to fire when reality changes: a new email from a customer, a calendar event tomorrow, a PR opened on this repo. Memory triggers subscribe to your brain itself.
// docs · triggers→Memory triggers are filters over your brain: a page kind plus zero or more frontmatter constraints. When a new page lands that matches, your automation runs once per match, with the page already passed in as input. Combine triggers freely — cron + memory + webhook in one program.
Every board is a typed dataset your team edits, your automations write to, and your dashboards visualize. Mini-sites turn that data into real web apps — dashboards, kanban, public forms, internal admin panels — published to a URL or embedded anywhere. One workspace, one database, one frontend.
// docs · boards→Every board carries a queryable memory shared by everyone on it — comments, attached docs, edit history, the decisions you made together. The hiring board knows every candidate conversation; the deal board knows every email touch; the project board knows every meeting decision. Common knowledge, ambient context.
Boards live in one place: your brain. Automations call append_board_rows, update_board_row, get_board, delete_board_row over MCP. The same row you write from code is the row your team sees in the UI a millisecond later.
A mini-site is a thin runtime that reads and writes the board it's attached to. Drop in a dashboard (kanban, charts, KPIs), a public form (collect rows from outside), an internal admin panel (full CRUD), or all three. Authenticated calls hit the same MCP your automations use, so the same access scopes apply.
Kanban, cards, table, charts — pinned views over the same rows your team edits. Permissions cascade from the board, so private stays private.
Drop a form on your marketing site, in a Slack channel, anywhere. Submissions land in your board as typed rows — ready for an automation to triage.
Publish a new draft, see it diffed against the live version, revert in one click. Mini-sites version like code — because they are code.
Two action shapes. fetch_from_integration pulls fresh data from Gmail, Drive, Calendar, Slack, GitHub, Stripe, and 195 more — and auto-persists it as pages. act_on_integration does writes: send an email, create a calendar invite, open a PR. Risky writes go through a two-phase draft → confirm → send flow. Every integration runs in a safe sandbox with only the scopes its manifest declares.
Reads (fetch_from_integration) run inline — the result is persisted as a page and the automation continues. Writes (act_on_integration) mint a draft with a preview and a TTL; nothing leaves your brain until a human (or another automation with explicit confirm scope) approves it. Drafts are addressable across MCP, web, and Telegram.
Automations, boards, integrations, and apps — running on your brain, with your keys.