Autonomous service desk — architecture blueprint

"Make it as completely autonomous as possible" and "the only human interaction should be to approve or arbitrate" are the same design goal stated twice, and the second half is load-bearing, not decorative. Every domain agent below can read, plan, and propose without limit. None of them can commit a change to a production system without a plan that already passed through the gate. That isn't a hedge against the agents being wrong often — it's a recognition that on infrastructure this broad (routers, firewalls, AD, hypervisors, call control), a single wrong autonomous write can be a multi-day, multi-team incident, and no amount of test coverage make that risk small enough to remove the checkpoint entirely.

This isn't a new idea introduced for this design — it's the same rule this project's own AGENT.md already runs under: "anything irreversible, legally gray, or strange → write it down and wait." The architecture below is that same principle, scaled from one autonomous agent on one box up to a team of them managing a real enterprise environment.

Every agent and the human gate write append-only events to a shared audit log (omitted above for clarity — see "Guardrails," below). The orchestrator never holds direct credentials to target systems itself; only the narrow domain agent for that system class does, and only for that class.

Requests never arrive as a chat message to an agent — they arrive as a ServiceNow record: an Incident (something's broken), a Request (someone needs something provisioned or reset), or a Change (a planned modification). That's deliberate, not incidental: ServiceNow already has the audit trail, the CMDB inventory of what exists, and — most usefully for this design — a native Approval record type. The human approval/arbitration gate isn't a bespoke dashboard bolted on the side; it's the orchestrator creating a real ServiceNow approval on the ticket and waiting on it, the same mechanism a human change-advisory-board reviewer already uses today. One system a human has to watch, not a second inbox competing for their attention.

The orchestrator plans and routes; it never touches a target system directly. Each domain agent holds credentials scoped to exactly one system class — ideally short-lived, checked out from a vault just-in-time for the approved action and revoked immediately after, not a standing broad account. That separation means a compromised or misbehaving orchestrator can propose anything but execute nothing on its own, and a single domain agent's blast radius is capped at its own system class.

"Default tier" is a starting point per action type, not a fixed property of the agent — a Firewall agent's read-only log query is Tier 0; the same agent's permanent rule change is Tier 3. See the risk-tier matrix below for how tier is actually decided.

Tier is decided per action, computed from the plan's blast radius (how many systems/users it touches), reversibility (is there a clean rollback), and whether it's read-only. This is the actual gate the diamond in the lifecycle diagram checks.

A fixed deny-list sits above all four tiers and applies regardless of who approves: disabling MFA, deleting backups, mass account deletion, and firmware wipes are never agent-executable, full stop — not because no legitimate reason ever exists, but because the cost of a single bad autonomous call in that set is high enough that it should always be a human's hands on the keyboard, not an agent's, approval or not.

Both route through the same gate, but they're answering different questions. Approval is a single decision on one proposed action: approve, reject, or send back with an edit. Arbitration fires when there isn't a single proposal to approve yet — two domain agents recommend conflicting fixes for the same incident, or the policy engine flags a plan the orchestrator scored as low-risk but a rule disagrees with. Rather than building a second escalation path for that case, arbitration is handled as a Tier 3 approval request that includes every competing plan side by side, so the human sees the actual disagreement instead of a single agent's confident-sounding answer.

"As completely autonomous as possible" is a destination, not a starting configuration — a system this broad earns wider autonomy one phase at a time, against evidence from the phase before it, not by being deployed at full trust on day one.

• Least privilege, per domain: no agent holds a standing domain-admin, enable-15, or root credential across its whole system class — only what a specific approved action needs, ideally checked out just-in-time from a vault and revoked right after.
• Mandatory dry-run for Tier ≥2: the plan runs in simulation (a config diff, a "what would change" preview) before it's allowed to touch a real system, and the dry-run output is what the human actually approves — not a text description of intent.
• Immutable audit log: every plan, approval, arbitration decision, action, and verification result is appended, never edited, and queryable independently of any one agent's memory.
• Required rollback plan: no mutating action ships without a paired undo step defined up front; if the undo can't be defined, the action isn't Tier 1 or 2, it's Tier 3 at best.
• Circuit breakers: hard caps on actions-per-hour and blast-radius-per-action, independent of any single agent's own risk scoring, so a bug in one agent's judgment can't cascade at machine speed.
• Hard deny-list: a small set of actions (see the risk-tier section) that no tier and no approval can unlock.

This page is an architecture blueprint, written the way a design doc should be written before anyone touches production: the shape of the system, the trust boundaries, and the checkpoints, worked out on paper first. It is deliberately not a running deployment. This box has no ServiceNow tenant, no Cisco/AD/VMware credentials, and no reachable enterprise network to manage — and even if it did, standing up live write-access to someone's routers, directory, and hypervisors isn't a decision an autonomous agent should make for itself. That's a real person's infrastructure, a real person's job to grant that access deliberately, scoped narrowly, with their own change-control process wrapped around it — which is exactly what the human approval/arbitration gate above is designed to plug into, not replace.