What Your AI Employee Is Allowed to Touch: Skills, Queues and the Line Between Reading and Writing
When a small firm hires its first robot employee, the surprise is rarely the intelligence. It is the limits. A robot in the Firmspace Robot Office is not a general-purpose assistant with access to the whole account. It is a colleague with a role, a defined roster of tools and one queue of its own. Most of the design work went into drawing those limits clearly, because in a real business the expensive mistake is usually not a task that failed. It is a task that quietly did something nobody asked for.
The unit of permission is a skill, and a skill is simply a named set of tools. Nothing else grants access. A robot that lacks the finance skill does not get finance tools with a warning attached — it does not get them at all. The catalog in the code lists sixteen skills: crm, quotes, invoices, finance, stock, purchasing, production, tasks, mail, documents, blog, hr, data, blogwrite, monitor and web. Every one of them is a plain list of tool names, so you can read exactly what a capability contains before you hand it over. That is the whole permission model, and its smallness is the point.
The catalog of roles is where those bundles become a job. Lena works sales: she reviews open deals, calls find_stale_contacts to surface customers nobody has written to for a while, prepares quotes and leaves follow-up tasks. Max does accounting — creates invoices, records expenses, marks an invoice paid once the payment is confirmed. Nora handles receivables, preparing polite and factual reminders; her instructions state plainly that she never threatens and never gives legal advice. Clara does controlling and is told to answer with numbers read from her tools, never guessed. The same pattern repeats across warehouse, purchasing, production, office, marketing and service.
Two capabilities are deliberately withheld from companies. The blogwrite skill can draft articles for the landing-page blog but can only save them as drafts — publishing stays with a person. The monitor skill comes with an empty tool list: robots that carry it watch platform data such as errors and site optimisation, take no tasks at all, and cannot change anything. Both belong to platform roles and cannot be handed out to your own robots.
There is one hard line that no role crosses, no matter how the role was configured or edited. Robot skills contain no delete tools. Removing records is not a behaviour that can be switched on, because the capability is simply absent from every bundle. Issued invoices are protected further still: robots are instructed not to rewrite them, and changing an issued invoice always waits for a human, even in the mode that otherwise acts on its own.
The second line is the one people configure themselves. Every robot runs in one of two modes. In the asking mode, each action that would change data is collected instead of executed, and the task ends in a waiting state. You see the proposed changes as a list and approve them all or only the ones you want; approved actions then run under your own permissions. In the automatic mode, the robot executes its write actions directly and reports afterwards. Reads are never held back in either mode — the robot always looks at the real data first.
The queue is per robot, not per firm. One robot works on one task at a time and the rest wait in its own line; different robots work in parallel. That is a deliberate shape, because a robot working in the sales pipeline and a robot working in the warehouse do not compete for the same records, while two tasks for the same robot genuinely can conflict — and two production orders created from the same instruction would be worse than a short wait. If the server restarts while a task is running, that task is not shown as working forever. After a minute it is marked as interrupted, with an honest message asking you to start it again.
Because the limits are written down, a robot can be honest about them. When a task falls outside its skills, the instruction is to say in one sentence which kind of robot should do it instead of improvising. So an accounting robot asked to book a delivery does not silently invent an inventory movement; it points at the warehouse role. That behaviour is more useful than it sounds, because it turns a missing capability into a hiring decision you can make in one step — and the skills list already tells you whether the capability exists at all.
The delegation is the part that feels most like an office. Give a task to Ayris, the office manager, and it reads the roster of your robots together with their skills, splits the work and hands each part to a robot with a self-contained instruction. It answers in a couple of short sentences about who received what, and does not sit and wait for them: the robots report on their own. Small or cross-cutting work the manager keeps and does itself.
Even in the automatic mode there is a short list of actions that never run on their own. Deletions are on it, and so is changing an invoice that has already been issued, together with a few maintenance operations. In those cases the robot stops and asks, however the mode was set. There is a second guard that is easier to miss: if the robot has just read text that came from outside the firm — a customer e-mail, a page on the web — the automatic execution is switched off for the rest of that task and everything it proposes comes back to you for a decision. The reasoning is that untrusted text can contain instructions, and the safe default is to let a person look. A robot reading a supplier's message cannot act on it in the same breath.
Skills and duties are two different layers, and mixing them up is the usual source of disappointment. The template supplies the job description: what this role cares about and how it should phrase its work. You can also write your own instructions for a robot, which replace the template text, and change the name and title along with it. But duties do not widen access — the skills still decide which tools exist, and the tools themselves still run through the owner's own access rights. A robot cannot see further than the person who hired it.