Tuning a bot

Making a bot takes about a minute: a name, a provider, a model. Making one you'd actually trust with a recurring job takes a few more decisions, and they're the ones nobody explains. Here is every dial, in the order it matters — and the layer underneath all of them, the gateway, which is what stops a bot that has misunderstood its job.

Three layers, not one screen

A bot's behaviour comes from three places, and knowing which is which saves you an hour of editing the wrong one:

• The bot — its brain, its instructions, its numbers. Yours to set per bot.
• What you attach to it — channels, schedules, files, credentials, a device. This is reach, not behaviour.
• The gateway — workspace-wide ceilings and a kill switch. It never makes a bot do more; it only ever stops one doing more.

Tune from the top down. Most “the bot is being weird” problems are layer one, and most “the bot isn't running at all” problems are layer three.

The brain: provider and model

A bot is pinned to one credential and one model, and the model list follows the provider. The choice that catches people out isn't which model — it's where the model runs. A local machine provider spends a subscription you already pay for and never bills your credits, but its turns only happen while that computer is awake and the companion is listening.

Personality is the standing instruction

The Personality panel is read at the start of every conversation, whichever way the bot was woken — chat, Slack, a 7am schedule. That makes it the place for rules that must hold every time, and a bad place for anything you'd only say once.

What earns its place there:

• Who it works for, and the one job it has.
• Tone and length. “Three bullets, urgent first” is a rule; “be helpful” is not.
• The hard nos. Never send without my approval belongs here, not in the message you happen to be typing when it matters.

What doesn't: facts. Anything the bot could look up — a price list, a house style, last quarter's numbers — is better as a file it reads when it needs it than as text it re-reads on every single turn, at cost, forever.

The three numbers under Advanced

“Max steps” is the one worth understanding rather than adjusting. Each step is one tool call — read a file, search, browse, send. A bot that hits the ceiling has usually gone round in a circle, and raising the number just buys the circle more laps. Read what it did first; nine times in ten the fix is a sentence in the personality, not a bigger budget.

There is also a limit you can't set: a single run gets about fifteen minutes of wall clock. Steps and minutes are different currencies — a browser journey is minutes, not seconds, so five of them can exhaust the clock while barely touching the step budget.

Check-ins: the bot that wakes itself

Off by default, and worth turning on for exactly one kind of bot: the one waiting for something. It wakes on your interval, works through a checklist you write, and — this is the part that makes it liveable — says nothing at all when there's nothing to say. No message, no activity-feed entry. It runs on a cheaper model than the bot's own where one exists, because “is there anything to do?” doesn't need a frontier model to answer.

Set the interval to the frequency you'd actually want to be interrupted at. Sixty is hourly; three hundred and sixty is four times a day and is the right answer more often than people expect.

What you attach

The rail down the side of a bot is all reach. Every one of these is a decision about what the bot can touch, and each is worth making narrowly:

• Channels — Slack, Telegram, Discord, iMessage. Where it can be spoken to.
• Schedule — cron entries that start it without you, each with its own delivery.
• Vault — the connected accounts it may act through: read email, send email, read and send messages, browse a site as you.
• Files — a workspace directory that persists between runs.
• Device — an isolated runtime it can execute code in and serve a URL from.
• Webhooks and watchers — so something happening elsewhere can wake it.

The tuning advice here is the same as the advice for the numbers: narrow beats clever. Three bots that each do one thing are easier to instruct, easier to grant permissions to, and much easier to debug than one bot with everything attached — because when something odd happens, you already know which one did it.

The gateway: the layer under every bot

Every screen so far configured one bot. The Gateway is the workspace, and every run passes through it. Three things live there.

The status bar is a heartbeat, not a power switch

It reports one thing: whether a bot has checked in in the last minute or two. Bots without check-ins never stamp it, so on most workspaces it reads Stopped permanently and everything works fine — chats, schedules, webhooks and watchers don't consult it. Read it as “a bot checked in just now”, use the activity feed for whether the workspace is busy, and don't read a stopped bar as a stopped workspace. There's a How it works link beside it that says the same thing, so nobody has to come here to find out.

The global loop limit clamps every bot

The gateway's loop limit and the bot's own “max steps” aren't alternatives — the lower one wins. Set the workspace to 10 and a bot configured for 50 runs 10. Which is the ordering you want: a bot can be made stricter than its workspace, never looser. If you administer bots somebody else configures, this is the setting you care about.

The kill switch stops everything, everywhere

It's one button and it reaches further than it looks. Engaged, scheduled tasks aren't dispatched, check-ins are skipped, email polling and event watchers stand down, the nightly review doesn't run, and 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, and both events land in the activity feed, so “who stopped the bots at 4pm” has an answer.

A tuning order that works

1. Write the personality first, and keep it about behaviour.
2. Set the timezone. Every schedule you write afterwards depends on it.
3. Attach the minimum — one channel, one credential — and use it that way for a day.
4. Read a transcript before touching a number. The steps a run took tell you more than the number it stopped at.
5. Only then add the schedule, and only then the check-ins.

A bot configured in that order tends to need one edit a month. One configured by turning every dial up front tends to need one a day — and you won't know which dial did it.