Three different noes, and who each one sends you to

Most software says no in one sentence. “Something went wrong.” “You do not have permission.” A support desk that receives those spends its day guessing, and the guess is usually wrong in the expensive direction: somebody is given a role they did not need, because the real problem was that the organization had never bought the product.

An assistant is the worst possible place to blur that, because it answers in prose. A model handed a status code will happily paraphrase it into something friendly and useless. So in Rutba Assistant the refusals are sorted before a model ever sees them, and each one keeps its own sentence.

Three checks, three different sentences

Every call the assistant makes meets the same three checks a screen meets (the first post in this series explains why it has no way round them). Each check refuses differently, and each refusal points at a different person:

Internally these are three different failure kinds, not three flavours of one. The rules that decide whether a longer piece of work carries on read them as three different stop reasons too — alongside the ones that are nobody’s fault, like a call timing out or a service being briefly unavailable.

Refused in the words of the rule

The model is told to report a refusal in the words it was given rather than rephrase it. And one refusal happens before a request is built at all: if the model asks for a call belonging to an app you are not working in, the assistant refuses it itself. The check further along would have caught it; the point is that a refusal we can explain in a sentence beats one a model has to interpret from a status code.

An agent with nothing you can reach says so

Named agents introduce a failure the suite-wide assistant does not have. Ask the Payroll agent a payroll question while holding no Payroll role, and the list of calls it may use is empty. Hand a model an empty toolbox and a payroll question, and it will answer anyway — from its general knowledge, with a confident salary figure, no source, and no refusal.

So an agent that has nothing you can reach never gets as far as the model. It returns a refusal naming the reason — and because the filter in front of it counts why each call was excluded, it can say which reason: your organization is not licensed for Payroll, or you do not hold a Payroll role. Those are the first two rows of the table above, and they send you to two different people.

A confident salary figure with no source is the one answer worse than none.

Out of credit is a stop, not a failure

The assistant will run on prepaid credit held by your organization. When it runs out, the assistant stops and says that it has run out and where to top up. A plan that stops for credit says in its notification that nothing was left half-done, and once the balance is topped up it can be resumed from the step where it stopped.

The balance screen follows the same rule from the other side. A deployment that does not meter says it does not meter, rather than showing a balance of zero — because “zero” and “we are not counting” send an administrator to two different places too.

The same sentences when a plan stops

Work that outlasts a single answer runs as a plan a person approved, and when one stops, the notification names the remedy rather than saying it failed. Rights changed after approval: ask an administrator, then resume. A route it needed does not exist: that one is a bug report. It is waiting for a decision: it is waiting for you rather than guessing. A notification that does not say what to do is one people learn to ignore.