Work that outlasts a reply runs as a plan a person approved

Some of what people want from an assistant is not an answer. Chase every invoice more than sixty days overdue. Raise purchase requisitions for everything below its reorder point. Produce the same stock report every Monday at seven. Those are jobs, and a job changes things.

An assistant that changes things on the strength of a chat message is the one people are right to be afraid of. So in Rutba Assistant, anything that writes happens one way only: as a plan, which a person approves before it runs.

A plan is a list of requests, not a promise

A plan is not “I will chase the overdue invoices”. It is every step, each with the exact request it will send — which call, which record, which values. You approve the requests, not a summary of them.

What you approved is fixed. Each step’s request is fingerprinted at approval, and a step whose request has changed since is refused rather than run. Each step also carries a key derived from what it does — the plan, the step and that fingerprint — never from when it was sent. And when a change times out and may or may not have landed, the plan does not retry it and hope: it pauses and asks a person, because that is the one case where guessing is worse than stopping.

It stops where it fails

A step runs only when the one before it succeeded. When one fails, the plan stops there and keeps the reason — it does not skip ahead to the steps that would still work, because a plan that skipped a step would be a different plan from the one somebody approved. Fix the cause and resume it, and it carries on from the step that stopped, without repeating the steps that already finished.

Your authority is checked again before every step, not once per plan. A plan approved on Monday may run on Friday, and in between a role can be taken away or a grant can expire. If what it is running under has narrowed, it stops with that as the reason.

Close the tab

A worker carries the plan on without you. You are told once, when it ends: finished, stopped with the reason and what to do about it, or waiting for a decision it will not guess at. Never once per step — a notification for every step of a nine-step chore is how a bell becomes noise. If the worker itself dies mid-step, the step is returned to the queue after a generous grace period; generous on purpose, because a duplicate write is worse than a delay.

Schedules that cannot turn into incidents

A chore can run on a timetable — hourly, daily, weekdays, weekly or monthly. An unattended loop that is billed for every run needs rules a person does not have to remember:

• It never overlaps itself. A report that takes ninety minutes and is scheduled hourly does not start a second copy on top of the first.
• It stops after three runs in a row that did not finish, and says so. A job failing the same way every night is not going to recover on its own, and every attempt costs credit. A person restarts it once the cause is fixed.
• It cannot outlive its grant. A schedule whose grant has expired does not create a plan at all, rather than producing a nightly plan that fails on its first step.
• A missed window is not caught up. If the worker was down for a day, the job runs once when it returns — not once for every window it missed, which would be six identical reports and six charges.

Grants that end

Letting the assistant work while you are away takes an explicit grant: the apps it covers, never more than you hold yourself, and an end date you choose. There is no “until revoked” — a grant without an expiry is refused when it is created. Revoke one early and the next step stops.

Its changes are signed as its own

The audit trail has to answer one question honestly: did a person do this, or the assistant on their behalf? A header saying “the assistant did it” would be a claim anybody holding a valid sign-in could make — the cheapest possible way to make your own change deniable. So the mark is signed, by a secret only the assistant’s service holds, over whose authority was used, the exact request, the time, and the grant it ran under. The suite checks the signature before believing it, and records an unproven mark as no mark at all.

What a plan will never contain

Some changes stay with people whatever anybody approves: running or approving payroll, posting to the general ledger, deleting anything, changing who may do what, changing the assistant’s own limits, grants or balance, and sending anything to your customers. Your organization will be able to add to that list and never take anything off it. Putting it in front of every path that can change a record is one of the conditions for switching the assistant on — the first post in this series lists the others.