Home/Verified AI Operations/Commanded Autonomy
Extension, not replacement
Give AI room to work. Keep authority with your team.
Autonomy is a dial, and moving it changes when a human's authorization is recorded. The operation still records the privilege lease, the model boundary, the target's confirmation and the sealed record. The chain carries the outcome and the command, and we will not ship a setting where the command has no accountable name.
The dial
Four settings. The same controls stay underneath all of them.
Autonomy is often presented as a trade between safe and fast. Here the dial changes when a human's authorization is recorded, while the operation still carries scoped access, target verification and a sealed record. Read the top row for what moves; read the green band for what stays.
The four settings
Where you start, and how teams actually move.
Set per customer, per runbook class, and per target group — not once, globally, for everything you manage. A new client can sit at setting one while a client you have run for three years sits at setting three for password resets and setting two for everything else.
-
Propose only
Seraph investigates, works out what is wrong, and writes the plan as a sequence you can read. Nothing runs until a technician runs it, step by step. This is where a new customer starts, and where a new runbook lives while your team decides whether it deserves certification.
-
Approve each operation
Seraph asks once, on the board, with everything a technician needs to judge it: who asked, the typed outcome, the certified runbook, the target, the lease it wants, and the undo it has already declared. One click and it works the operation end to end. This is the default and most teams stay here for most work.
-
Standing authorization for one certified runbook class
Your team pre-authorizes a specific class of certified runbook — say service recovery — for a named group of targets, at named times. Seraph runs those without asking. Everything outside that class, that group, or that window still comes to the board. The authorization is a deliberate act by a named person, and it is revocable in one click.
-
Autonomous within policy
Seraph works inside a policy your team wrote: which outcomes, which targets, which windows, which privilege ceilings, and what it must do when it reaches the edge. At the edge it stops and asks — it does not widen its own scope, extend its own lease, or decide that this once it is fine. The policy itself was approved by a person, and that person's name is on every operation the policy produced.
Taking the wheel
One click, mid-operation. A fresh lease, under your own name.
This is the moment most AI operations products handle badly: the human intervenes, and the trail either forks into a second ticket or — worse — the human's work is recorded as the AI's, on the AI's privilege. Here is what happens instead.
Your technician is an actor, not an override
Taking the wheel is a first-class move in the operation model, not an escape hatch bolted on the side. It has its own authorization, its own lease, and its own rows in the record.
Which is why it does not break anything: there is no “manual mode” where the governance stops applying because a person is typing.
Handing it back works the same way
Marcus can hand the operation back to Seraph to finish, and the handover in that direction is recorded identically: his lease ends, a new one is minted for the AI, and the operation carries on.
Both directions are ordinary events in one record, which is the only way a mixed human-and-AI shift can be audited at all.
What “commanded” means in the record
Not “an approval happened somewhere”. The receipt names the person, the moment, what they were shown when they decided, and which setting the operation was running under.
The line we will not cross
We will not ship a mode where nobody's name is on the work.
This is worth being blunt about, because it is a product decision that costs us a demo feature other vendors are happy to show.
- No “fully autonomous” mode where operations run without tracing to a person, a class authorization, or an approved policy.
- No AI self-authorization. The model cannot approve its own plan, widen its own scope, or extend its own lease.
- No silent escalation. If a runbook cannot reach its outcome inside the privilege it was given, it stops and asks. It does not ask for more on its own behalf.
- No governance-free manual mode. A human working by hand is still leased, still scoped, and still recorded.
- Autonomy is bounded by policy. At settings three and four, certified operations may run without continuous attention; the operation still records its authorization, access and target result.
- The name is cheap to record and expensive to fake. Attaching an authorization to an operation costs nothing at run time; reconstructing one afterwards is impossible, which is exactly the property you want.
- Revocation is one click. A standing authorization or a policy can be withdrawn immediately, and operations already running finish under the authorization they started with — recorded as such.
- You can prove the setting. The receipt names which autonomy setting produced the operation, so a client asking “was a person involved?” gets an answer from the record rather than from your memory.
What we are not claiming: that autonomy removes judgement. Setting three and four suit narrow, well-understood, certified work — the tickets your team is tired of. They are not a claim that an AI should be trusted with anything you would not sign your own name to, and the product is built so that you always are signing it.
What teams ask before they turn the dial up.
Is autonomy set globally, or per client?
Per customer, per runbook class, and per target group. A new client can sit at propose only for everything while a long-standing client sits at standing authorization for service recovery and approve each for everything else. There is no single switch that changes the behaviour of your whole estate, because that switch is how accidents happen. How client scoping works →
If the AI is working and I take over, does anything get lost?
No. You inherit the operation with its plan, its target, its declared undo, and everything already recorded — you do not inherit its privilege. A fresh lease is minted under your identity, and both leases appear in the same receipt. No second ticket, no second record, no gap. How leases are minted →
What stops the AI from quietly asking for more privilege?
It cannot ask. The lease is requested by the platform against the policy that authorized the operation, and the scope is derived from the operation — not proposed by the model. If the certified runbook cannot reach its outcome inside that scope, the operation stops and a person is asked. Escalation is a human decision by construction, not by restraint.
Can I see what it is doing before it finishes?
Yes — live, on the board, with the current step, the lease remaining, and the take-the-wheel affordance one click away. Watching is not a special mode; it is the ordinary state of an operation in flight. The delivery board →
How is this different from an RMM's approval workflow?
An approval workflow records that someone clicked approve, in a system separate from the one that later says the work succeeded. Here the authorization, the privilege, the job, and the machine's own confirmation are fields of the same object, chained together. That is the difference between an approval and a command you can prove. Compared with autonomous RMM →
Bring your hardest objection
Take the wheel from our AI, mid-operation, on the call.
We will start an operation, hand it to you halfway, and then open the record so you can see both leases and one receipt.