Routines and webhooks

Routines

A routine runs once, at a repeating interval, or on selected weekdays. Each run starts a fresh execution using the selected bot's model, permissions, tools, and computer configuration.

Each run's thread is titled with the routine's name and the date and time it started, for example Daily briefing · Oct 3, 9:00 AM. Run receipts distinguish queued, active, waiting, completed, missed, failed, and cancelled work. Brainwrite must be running when a local routine becomes due.

If a routine's instructions or attached files name a path that cannot exist on the computer that runs it, for example a path on your laptop in a routine that runs on My Cloud, the routine list shows a warning under it. Change the path to one on that computer, or attach the file to the routine.

Keep reports in one thread

In a routine's editor, use Post results to to choose an existing thread, or leave it on The bot's main thread: the conversation you last wrote in, which is also the one conversation you see with threads hidden. You can move a results thread into a folder, such as Reports, just like any other thread.

Each run gets its own execution context, while dated reports collect in the chosen thread. Background execution threads stay out of the normal sidebar and mobile thread pickers. Use Open run on a report for its conversation and any approvals, then Back to results to return. Run logs keeps the execution history, including failures and waiting runs.

A bot schedules, changes, pauses, resumes, and deletes its own routines from chat without asking, and each change shows as one line with Undo (see Changes a bot makes). A routine for another bot asks first unless the conversation has Full access.

Without a chosen thread, each run reports into the bot's main thread as it is when the run starts, wherever the routine was made, so results follow you to the conversation you are in. Changing the destination affects future runs, not the report links for older runs. If you delete a results thread, its hidden execution threads become visible so you can still inspect their work and respond to approvals.

Remember the last run

Each run starts fresh by default. For work that builds on last time, such as a QA pass, monitoring or follow-ups, turn on Remember the last run under the routine's instructions. Each run then starts with the previous run's report (up to 2,000 characters), so the bot knows what it found before. It is available for repeating routines that one bot runs; team goals don't carry it yet. You can also ask the bot in chat to turn it on.

Run when the app starts

If your computer is often off when a routine is due, open the routine's Advanced options and turn on Also run when Brainwrite starts. The routine then runs once each time Brainwrite opens, as well as on its schedule. Its run logs show these runs as On startup. A routine that Brainwrite is already catching up on at startup runs once, not twice, and an occurrence missed by more than 12 hours is covered by the startup run instead of being reported as missed. Switching to another workspace and back, or Brainwrite recovering from a crash, doesn't count as opening the app again. Pausing a routine stops its startup runs too. It's available for repeating routines, and you can also ask the bot in chat to turn it on.

Clear a folder's unread dots

Right-click a folder or open its … menu, then choose Mark folder as read. This clears unread dots without opening each thread. It does not answer approvals, dismiss questions, or stop any running work.

Webhook triggers

Webhooks start the same queued task executor from an external HTTP request. They are independent from schedules and use a dedicated receiver on 127.0.0.1:8800 by default.

The receiver exposes only health and secret hook routes. It does not expose the broader Brainwrite API.

Bearer authentication is preferred because it keeps the secret out of URLs and most access logs. A capability URL is available for senders that cannot set headers.

A bot that sets up its own webhook

When a bot creates a webhook automation from chat, it gets the private address in the result, and it can ask for it again later, so it can paste the address into the other app's setup itself instead of asking you to use Copy address. Only the bot the automation belongs to gets it, or a Chief of Staff that can reach that bot (bots with a different audience on a shared workspace cannot), and only in a conversation you drive: never in a run that a webhook or app event started, and never in a My Cloud conversation a guest drives. The address stays in that tool result; chat transcripts, step details and logs show it masked, and the Automations page keeps the secret hidden until you press Show. Copy address copies the same address the bot has, so copying never breaks a setup; Replace address makes a new one and the old one stops working.

Reaching a local webhook

On My Cloud there is nothing to set up: webhooks use the workspace's own address. The Webhooks panel shows https:// plus the workspace's hostname followed by /hooks/ and the endpoint, and only those hook paths are passed to the receiver. The same is true of a hosted workspace.

On the desktop app the receiver listens only on this computer. To accept events from the public internet, proxy only the webhook receiver through a narrowly configured relay or tunnel. Do not expose the main harness port.