Rutba Assistant has no account of its own, and that is the design

Most business software has added a chat box by now, and most of those chat boxes answer questions about the software: where the export button is, what a field means. Rutba Assistant answers questions about the business. Which customers are furthest behind on paying. What will run out before the next delivery. Who is close to overtime this week. It answers from your own records, and it shows you which records it read.

That is a more useful assistant and a more dangerous one, because the records it reads are the ones a company is most careful about. So the first design decision was not about the model at all. It was about whose authority the assistant uses when it reads — and the answer is that it has none of its own.

Where it lives

There is no separate app to open. The Ask button sits in the top bar of the apps you sign in to, and the panel docks to the side or the bottom so you keep working while it answers. It knows which app you are in, and it reads the same API the screen in front of you reads.

It is deliberately absent from two places: the public storefront and the delivery-tracking page. Neither has a signed-in person for it to act as, and an assistant for your shoppers is a separate product with a separate authority model.

You can ask the whole suite, or address one part of it by name. There is an agent for every app and one for each of the ten areas they fall into — Finance & Accounting, Inventory & Purchasing, People & Payroll, Sales & Customers, Logistics & Fleet, Manufacturing, Marketing & Web, Mail, Chat & Calls, Facilities & Assets, and Documents & Sign. The agents are generated from the suite’s own list of apps, so a new app has its agent the day it ships.

The same three checks the screen meets

When the assistant decides it needs a figure, the call it makes is an ordinary request to the suite’s API, sent with the signed-in person’s own authority and the same app and role the screen would send. It meets the same three checks a browser meets:

1. Is your organization licensed for this? If not, the answer is that the organization would have to buy something.
2. May you do it? If not, the answer is that an administrator would have to give you the role.
3. Does it exist? If not, that is a bug, and it is ours.

There is no private door. There is no way to pass the assistant an elevated role, and a call naming an app you are not working in is refused before the request is even built. The limits you already rely on — who can see salaries, who can see stock valuation, who can see a customer’s credit position — apply to the assistant unchanged, because it goes through them rather than around them.

The assistant gets no private door. That is what makes respecting the limits of a product an architectural fact rather than a sentence in a prompt.

A tool you could not use is never offered

The suite’s API is large — thousands of calls, over a thousand of them read-only. Before a question reaches a model, the list of calls it may use is cut down to the ones your organization holds and your roles allow. A person with three roles is offered the handful of calls those three roles reach, not the whole catalogue.

That is partly usability: an assistant that spends its turns being told no is an assistant nobody uses. It is also the stronger guarantee. A tool the model cannot see is a tool it cannot decide to try. But the filter is not the security boundary, and it is not allowed to become one — every call still meets the three checks above. A filter without the checks would be a breach waiting for a bug; checks without the filter would be an assistant nobody wants. It has both.

Naming an agent works the same way. Asking the Payroll agent keeps a question inside Payroll; what it may use is Payroll’s calls and what you hold, never either on its own. If you hold nothing in Payroll, it says so in those words instead of handing a model nothing to read and letting it answer from general knowledge. We explain why that matters in three different noes, and who each one sends you to.

The panel only reads

From the panel, the assistant reads. That is held by three independent checks rather than one: the index of calls it is built from marks every call by what it does, the filter declares no call that changes anything, and the executor refuses one if it arrives anyway. A regression in any single layer does not reach your data.

The one thing it writes from the panel is a report, when you press Report instead of Ask — a spreadsheet in your own Drive whose figures no model typed (how that works). Anything that changes records happens only as a plan a person approved, step by step, under a grant with an end date.

What is still open

• It is not switched on for anybody. It has been exercised end to end against the running suite — a real person’s sign-in, the three checks, the calls — but it is not released and not for sale.
• How well it answers is measured before release. A set of real business questions is the bar, and the release waits on that number rather than on a date.
• The list of things it may never do is written but not yet in front of every path. Running payroll, posting to the ledger, deleting anything, changing who may do what, changing its own limits, and sending to your customers stay out of its reach whatever anybody approves. Putting that list in front of every route that can change something is a condition of switching it on.
• Credit prices are not published. It will run on prepaid credit your organization holds, one balance rather than a bill per feature.

If you want to see what it looks like in a particular part of a business, the Rutba Assistant at work series takes one area at a time: the questions, the calls it makes to answer them, and where it hands the job back to a person.