Letting an AI Agent Touch the Rota — What That Actually Means for a Small Business

Reading is the easy half. An assistant that answers who is on tomorrow is useful and risks almost nothing. The moment it can assign a shift, the conversation changes, and most writing about "AI agents for small business" skips straight past the part that matters.

This is the part that matters.

What a write actually is here

Rostera exposes five tools over MCP. Four of them read: the shifts in a period, one shift in detail, the open shifts, the roster for a period. One of them writes: assign_shift, which creates a shift or gives an existing one to somebody.

The important property of that write is not that it exists. It is where the rules live.

assign_shift does not have its own idea of what a valid shift is. It runs the same double-booking guard the rota screen runs, and refuses a conflict the same way, with the same message. An agent cannot talk its way past a rule the application enforces, because the rule is not in the prompt — it is in the code path both doors share.

This is worth checking in any product before you connect an agent to it. Ask one question: does the agent call the same function the button calls? If it does, the agent inherits every guard the product has. If it does not, the agent is a second implementation of your business rules written by whoever built the integration, and it will drift.

The permission you already had

A key acts as one user and inherits that user's role. If the account you attach it to cannot publish a rota in the browser, an agent holding its key cannot publish a rota either. The write tool additionally names the permission it needs, so a viewer-role key is refused before anything is attempted.

And since this release, the key itself carries a scope. Read only means the four reading tools are the only ones the assistant is even shown; assign_shift is not in its list, and calling it anyway is refused by name.

So there are three separate gates between a prompt and a changed rota: the key's scope, the user's role, and the product's own conflict rules. Not one of them is the model's good judgement.

When a writing agent is genuinely worth it

Be specific, because the honest answer is "sometimes".

It earns its place when the work is high-volume and mechanical: filling a fortnight of recurring shifts from last fortnight's pattern, distributing a batch of open shifts to whoever has availability, moving a whole day after a closure. These are tedious, rule-bound, and easy to verify afterwards by eye.

It does not earn its place when the work is judgement: who to give the good Saturday to, who is quietly overloaded, who has asked for fewer nights and has not put it in writing. A scheduler that optimises hours while ignoring the politics of a small team produces a technically valid rota nobody wants to work.

The reasonable middle is the one most operators land on: let the agent draft, keep publishing as a human action. A draft rota costs nothing to throw away.

Set it up so mistakes are cheap

Four things, in order of how much they help:

Start read-only for a week. Ask it real questions about the real rota and see whether the answers are right. If it cannot reliably tell you who is on Thursday, it has no business assigning Friday.
Give the write key its own user. Not the owner account — a named account like agent, with exactly the permissions the job needs. Then the audit log tells you at a glance which changes came from the assistant and which came from a person.
Keep drafts drafts. Publishing is what makes a rota real to your staff. Leave that as a click.
Know how to undo. Before the first write, find the audit log and read it once. Knowing where the record is before you need it is the difference between an afternoon and a shrug.

What it cannot do here either

The same two catalogue-wide rules apply. No tool deletes anything, and no tool emails your staff. An agent can put a shift on the rota; telling people about it stays yours.

That combination is deliberate: the failure modes of a language model are wrong-but-plausible actions, and the two actions you cannot take back are destroying a record and sending a message. Those stay behind human hands regardless of what key you hold.

The question to answer first

Not can an agent do this? — it can. The question is: when it does the wrong thing, how will you find out, and how long will it take to fix?

If the answer is "the audit log shows it, and undoing a draft shift takes ten seconds", the risk is small and the time saved is real. If the answer is "we would find out when somebody did not turn up", do not connect a write key, and consider whether the process needs a person before it needs an agent.

Next steps

Connect your AI — the three-line recipe and every product that answers it
Rostera — the rota app used above; its full tool list, with the writes marked, is in the API.md inside the download
Connect Claude, ChatGPT or a local model to your invoicing — the read-shaped half of this pair

Written because "AI agent for small business" is usually sold as a capability and almost never as a set of guarantees. The guarantees are the product.