A Saved Bot Isn't a Permission Grant
A bot is a voice, a model, and standing scheduled work — capability comes from somewhere else entirely, and that separation used to be faked.
The word "bot" carries an implicit assumption most people don't examine closely: that a bot is a bounded, sandboxed thing, and that setting one up is roughly the same act as deciding what it's allowed to do. Piskes deliberately keeps those two questions separate, and it's worth understanding the separation before you assume otherwise and get surprised by it later.
What a bot actually is
In the Bots screen, a bot is a voice, a model, a name, a description, and a set of standing scheduled work. What it is not, by design, is a capability grant. Creating or configuring a bot doesn't, on its own, decide what that bot is allowed to touch. Capability comes from somewhere else — the pack a bot is running under — and packs are, deliberately, editable by whoever they're meant to bound, not baked permanently into the identity of any specific bot.
That separation matters because it keeps two genuinely different questions from getting blurred together: "who is this bot, and what does it sound like" versus "what is this bot actually allowed to reach." A lot of AI agent tooling conflates those, so that configuring an agent's persona also, implicitly, configures its access. Piskes keeps them apart on purpose.
The version that used to be faked
There's a genuinely useful trust-building detail in how this used to work, and it's worth telling honestly rather than skipping past it. Bots didn't always have a real bot_id column joining them to their scheduled work — for a while, the connection was inferred by substring-matching a bot's name against schedule text. It worked, mostly, until it didn't: renaming a bot could silently break its own schedule count, because the substring match that used to find its schedules no longer matched the new name. Nobody would have seen an error. The count would have just quietly gone wrong.
That got fixed with a real bot_id column added later, joining bots to their schedules properly instead of pattern-matching on a display name that was never meant to be a stable identifier. It's a small story, but it's the kind of thing worth knowing: the underlying data model for something as basic as "which schedules belong to which bot" wasn't always as solid as it looked from the UI, and it's more solid now because someone found the gap and closed it with a real relationship instead of a string match.
What this means for you
If you're setting up bots and capability packs, don't assume that naming or configuring a bot a certain way narrows what it can do — go set the pack explicitly, because that's the actual control surface. And if you've renamed a bot recently, its schedules should still count correctly now, on a real join rather than a name match that a rename could quietly break.