Approvals and autonomy
An agent that cannot write is limited; an agent that writes without supervision is unaccountable. MAIA Plus resolves the trade-off with autonomy modes and an approval gate that sits between the decision and the effect.
The three modes
Section titled “The three modes”| Mode | Reads | Notes | Other writes | Typical use |
|---|---|---|---|---|
| Assistant | Allowed | Require approval | Require approval | New agent, untrusted ticket types |
| Semi-auto | Allowed | Automatic | Require approval | Most production agents |
| Auto | Allowed | Automatic | Automatic | Narrow, well-tested, write-heavy work |
The mode belongs to the agent (Basic tab) or to the running profile; a workflow step inherits the resolved policy. Changing it changes behaviour immediately for every surface that uses that agent.
Two consequences follow, and they matter more than the table:
- In Auto, nothing pauses. There is no approval card to catch a mistake, so Auto is only defensible for an agent whose writes are narrow, reversible and well tested.
- In Semi-auto, a note is not an approval. Writing a note to a ticket is a write, and it happens without a card. If a note needs review, the agent belongs in Assistant mode or the tool must require approval explicitly.
What triggers an approval
Section titled “What triggers an approval”Escalation triggers
Section titled “Escalation triggers”Beyond the mode, the agent carries an escalation policy: high risk, low confidence, missing required information, outside agent scope, policy blocks action, unsafe action, user asks for a human. Each of these can pause a run even in Auto mode.
Per-tool policy
Section titled “Per-tool policy”Tool-level policy adds a third gate, and it is the one to reach for when the mode is too blunt: any write tool can be pinned to Requires approval regardless of the agent’s mode, and a procedure can demand a read before the write. The policy is per tool, so an agent can be fully autonomous for ticket_read and still be blocked on ticket_add_note.
The lifecycle of one approval
Section titled “The lifecycle of one approval”agent decides → approval requested (run pauses) → a human decides → run resumes or ends- The run stops before the effect. Its status becomes Waiting for input — not failed, not completed.
- The request appears in Administration → Pending approval and in Enterprise Audit → Approvals.
- The row names the action, the run that asked, the requester, when it was requested, when it was decided, who decided, and how long it waited.
- On approval the run continues and performs the write. On rejection it ends without the write, and the audit keeps both facts.
The operation behind a pending approval is not performed until someone decides — the gate is before the effect, not after it. This is a guarantee about that one operation: independent writes made earlier in the same run, or written by another run, are unaffected.
Operating an approval queue
Section titled “Operating an approval queue”- Read the action, not the intent. “Ticket add note” with a 900-character body is a different risk from a one-line acknowledgement.
- Watch the wait time. A rising wait means work is blocked on people, not on the system.
- Never approve blind. The ticket reference and the run id are on the row; open the run before deciding.
- Decide, do not resend. Resending creates a second run that will ask again.
Autonomy is a risk decision, not a tuning knob
Section titled “Autonomy is a risk decision, not a tuning knob”| Question | If the answer is no |
|---|---|
| Do I know exactly which tools this agent can reach? | Stay in Assistant |
| Have I seen this agent handle the boring cases correctly? | Stay in Semi-auto |
| Is every write reversible or attributable to a person? | Stay in Semi-auto |
| Would a wrong write be noticed within minutes? | Stay in Assistant |
The main risk in Auto mode is enabling a write procedure that has not been reviewed. Before an agent writes without confirmation, verify that every exposed operation is intended, that its scope is limited to the portal and record types it needs, and that the resulting change would be visible to the person responsible for the ticket. Enterprise Audit records every write, but it records the change after it has happened — it does not prevent it.
Where approvals show up
Section titled “Where approvals show up”| Surface | What it shows |
|---|---|
| Administration → Pending approval | The live queue to work through |
| Enterprise Audit → Approvals | Every decision with actor and duration |
| Enterprise Audit → Runs | The run paused as Waiting for input |
| Technician Copilot | An approval card inside the conversation |
| Automation | A run that does not finish until someone decides |
Limits and failure modes
Section titled “Limits and failure modes”- Unattended automation + approval gate → the run blocks indefinitely; decide deliberately whether that is acceptable.
- Approval by the requester of the action → self-approval undermines the control; keep the decision with a different person.
- Approval fatigue → requiring confirmation for every action dilutes attention; narrow the write surface with per-tool policy instead of approving everything by habit.
- Mode changed after the fact → past runs are not re-evaluated; the audit keeps what actually happened.