Bots & the Gateway
A bot is a worker you configure once and then leave running — a provider, a model, standing instructions, and whatever you attach to it. The gateway is the layer underneath all of them: the workspace's ceilings, its browser, its schedule keeper, and the one switch that stops every bot at once.
What a bot is made of
Everything on a bot's page is one of four things — who it is, what it thinks with, how it behaves, and what it can reach.
| Part | Where | What it decides |
|---|---|---|
| Identity | Settings | Name and description. The name is what channels and the activity feed call it. |
| Brain | Settings | Which provider credential and which model each turn runs on. |
| Personality | Personality | Standing instructions, read at the start of every conversation. |
| Attachments | Channels, Schedule, Vault, Files, Device, Webhooks, Watchers, Skills | Where it can be spoken to, what wakes it, and what it can reach when it runs. |
Choosing the brain
A bot is pinned to one credential and one model. The model list follows the provider you pick, so add the credential first under API Keys — see AI Providers.
Scheduled work needs an always-on provider
Point a bot at a local machine provider and its turns only run while that computer is awake and the companion is listening. That is fine for a bot you talk to; it is not fine for one that fires at 3am. Scheduled tasks, webhooks and check-ins on a local provider simply don't happen while the lid is shut — and nothing is billed to your credits either.
Personality: what it should sound like
The Personality panel is plain English, not a prompt format. It is read at the start of every conversation, so it is the right place for standing rules — the ones that should hold whether the bot was opened in chat, woken by a schedule or messaged in Slack:
- Who it is working for and what it is for.
- Tone — how long an answer should be, and how formal.
- Hard rules. Never send anything without my approval belongs here, not in the message you happen to be typing.
- Output shape — bullets, a table, urgent items first.
Keep it about behaviour. Facts belong in the bot's files or knowledge, which it can read when it needs them, rather than in instructions it re-reads on every single turn.
Tuning: the numbers under Limits & tuning
Under Settings → Everything else → Limits & tuning are the three knobs worth touching, and the defaults are deliberate.
| Setting | Default | What it does |
|---|---|---|
| Max steps per turn | 25 | How many tool calls the bot may chain before it has to answer. A bot that misreads a task stops with a reason rather than grinding. Raise it for genuine multi-step research; lower it for a bot that should answer, not investigate. |
| Creativity (temperature) | 0.7 | 0 is deterministic, 1 balanced, 2 wild. Anything that files, sorts or extracts wants a low number. |
| Timezone | UTC | The clock the bot reads. It writes its cron schedules and dates its daily notes in this zone, so a bot on the wrong zone runs its “9am” report at the wrong 9am. |
There is a fourth limit you cannot set and should know about: a single run has a wall-clock deadline of about fifteen minutes. It exists because slow tools — a browser journey is minutes, not seconds — can burn a step budget without ever hitting it.
Check-ins
Settings → Everything else → Check-ins lets a bot wake on its own, review what it was doing, and message you only if something needs you. It is off by default, because each check-in is a real API call. When it is on:
- The interval is yours — 60 for hourly, 360 for four times a day. Due-ness is evaluated every half hour, so a six-hour check-in costs four runs a day, not forty-eight.
- A check-in that finds nothing to do is silent: no message, no activity-feed entry. A heartbeat that says “nothing to report” forty times a day is one you turn off.
- It runs on a cheaper model than the bot's own where one exists, because “is there anything to do?” does not need a frontier model to answer.
- What to check is the checklist it follows. Left blank, it uses the one in the
bot's
HEARTBEAT.md.
The gateway
Everything above is per bot. The Gateway screen is per workspace, and every bot run passes through it. It is the answer to “how do I stop all of this at once”, and to “what stops a bot that has misunderstood its job”.
Running, Stopped, and the heartbeat
The bar at the top of Bots and Gateway is a heartbeat, not a power state, and it tracks exactly one thing: when a bot last checked in. A check-in stamps the workspace, and the stamp goes stale after about three heartbeat intervals — 90 seconds on the default of 30. Which has one consequence worth stating plainly:
- Stopped is the normal reading. No bot has check-ins on? It reads Stopped forever. Check-ins are on but half an hour apart? It reads Running for a minute and a half after each one, and Stopped in between.
- Nothing depends on it. Chats, scheduled tasks, webhooks and watchers all run the same whether the bar says Running or Stopped. It is a light, not a switch — and the switch that does stop things is the red one beside it.
So read it as “a bot checked in just now”, and reach for the activity feed rather than the bar when you want to know whether the workspace is doing anything.
The kill switch
One button, checked in more places than it looks. While it is engaged:
- Scheduled tasks are not dispatched.
- Check-ins are skipped.
- Email polling and event watchers stand down.
- The nightly review does not run.
- Every AI request is refused, so a bot already mid-run stops at its next step rather than finishing the job.
It stays engaged until someone disengages it — there is no timer. Both events are written to the activity feed — engaging as a critical entry, disengaging as an ordinary one — so “who stopped the bots at 4pm” is answerable.
It halts, it does not undo
The switch stops the next step. It cannot recall an email that has already been sent or a message already delivered to a channel. Use it as a brake, and keep dangerous capabilities off bots that should not have them in the first place.
Ceilings
The gateway's global loop limit clamps every bot's own “max steps per turn” — the lower of the two wins. Set the workspace ceiling to 10 and a bot configured for 50 runs 10. That is the ordering to remember: a bot can be made stricter than the workspace, never looser.
| Gateway setting | Default | What it does today |
|---|---|---|
| Heartbeat interval | 30s | How fresh a bot's last check-in has to be for the status bar to read Running. Three intervals of silence and it reads Stopped, which is the usual state. |
| Global loop limit | 25 | Clamps every bot's max steps per turn. Enforced on every run. |
| Max concurrent sessions | 10 | Recorded as the workspace's intended ceiling. It is not yet enforced in the run path — treat it as the number you have agreed with yourself, not a guarantee. |
| Rate limit (req/min) | 60 | Same: stored on the workspace, not yet applied to outgoing requests. Provider-side limits still apply. |
| Cache hit rate alert | 50% | Writes a warning to the activity feed when prompt-cache hits fall below the threshold — the early sign that something is rewriting a prompt that used to be stable. |
Web browsing
How a bot reads pages is a workspace decision, not a per-bot one. With a Cloudflare Browser Rendering token configured, pages are rendered there; without one, they are read with Playwright, which ships with the app. Clicking, filling forms and logging in always run on Playwright — Cloudflare's API can only render a page — so a workspace without Playwright can read the web but not walk through it.
Nightly review
Optional, and off by default. When it is on, each active bot wakes once a night at the configured time — in its own timezone, not the server's — reviews the day's sessions and notes, and updates its long-term and working memory. Turn it on for bots that accumulate context worth keeping; leave it off for ones that answer questions and forget.
When a bot stops
| What you see | What happened |
|---|---|
| “Kill switch engaged” | Someone hit the switch. Disengage it from the gateway bar; the activity feed says who and when. |
| “Iteration limit reached” | The run used its steps. Either the task needs more than the ceiling allows, or the instruction sent it in a circle — read the transcript before raising the number. |
| “Run deadline reached” | Fifteen minutes of wall clock, usually slow tools rather than many of them. |
| “Paused — out of credits” | Managed-provider credit ran out mid-run. Top up and the bot picks up; see Endpoint Tokens. |
| Nothing at all, at the scheduled time | Usually a local-machine provider on a sleeping computer, a paused bot, or the kill switch. The gateway bar reading Stopped is never the cause — it only reports check-ins. |
Next steps
- AI Providers — add the credential a bot's brain points at.
- Local machine — run a bot on a subscription you already pay for, and what that costs you in availability.
- Training Your AI — knowledge a bot can read instead of instructions it re-reads every turn.