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.

The supporting-systems band along the bottom is colour-coded by category (see legend). 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. The dashed supporting-systems band feeding Platform Ops is inventory, monitoring, and verification tooling — see "Supporting systems," above — not an eleventh agent with its own credentials to target systems. The dashed Platform Ops box is different in kind from the nine domain agents above it: it supervises the framework itself rather than owning one target system class — see "Self-healing, self-patching, self-maintaining," below.

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. A ticket also doesn't always start with a person: a Zabbix alert (see "Supporting systems," below) can open an Incident directly off a monitoring trigger, entering the exact same intake path as one a human filed by hand.

Nine of the ten agents in this design each own one target system class. The tenth, Platform Ops, is different in kind — it supervises the framework's own health rather than one class of managed infrastructure, so it gets its own section below rather than a row that doesn't quite fit this table.

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.

The nine domain agents above are the actors; they don't operate blind. A handful of existing operations tools do the sensing, verification, and execution work underneath them — the architecture slots into these rather than reinventing what they already do well. None of it opens a second door around the human approval/arbitration gate: each tool below is a data source or execution backend for one specific domain agent (or for Platform Ops), governed by the exact same credential-scoping and tier rules as everything else in this design.

IPAM's DNS/DHCP scope management is covered by NetBox's own IPAM module above rather than a separate product — the architecture doesn't lock into one vendor there; an Infoblox or BlueCat deployment slots into the same Network-agent role if that's what a given environment already runs.

Setup steps, API authentication, and a working MCP server for each system in the table above — including a full worked example for Cisco ISE — live on the integration guide.

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.

The deny-list below sits above every rung on this ladder — those actions are never agent-executable no matter who approves.

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.

Left unattended, a system this broad decays in predictable ways: a domain agent's process crashes and doesn't come back, a vault lease expires mid-session, a target system's API changes shape and an agent starts silently failing its own health check, patch levels drift out from under the CMDB's idea of what's installed, config drifts from its last-known-good state one small manual change at a time. "Self-healing" means the architecture notices and repairs those conditions itself instead of waiting for a human to notice a service desk backlog and go looking for the cause.

That's the job of the tenth agent, Platform Ops. It listens for a heartbeat from every domain agent and the orchestrator, watches patch/compliance status across managed endpoints, and continuously diffs live config against the CMDB's record of what should be there. Critically, it is bound by the exact same tier system as every other agent in this design — "self-healing" is a scope of what it watches, not a grant of authority the other nine agents don't have. Nothing below adds a second door around the human approval/arbitration gate or the deny-list.

The pattern to notice: everything that's genuinely reversible and low-blast-radius (restarting a crashed process, refreshing a credential, flagging drift) heals itself immediately, unattended — that's what makes the framework survivable to run without someone watching it every hour. Everything that touches a production system's actual state (installing a patch, reconciling drift, upgrading the framework's own code) still walks through the identical ticket → plan → tier → (approval) → execute → verify lifecycle as a request a person filed by hand. Self-patching means Platform Ops finds and proposes the patch; it does not mean the patch installs itself without going through the same door everything else does.

The tables above describe the pieces; this traces two real triggers through all of them, because "automatic" means different things at Tier 0 and Tier 2, and the difference is the whole point of the design. Both start the same way — a Zabbix trigger, not a person — and both end with a fully written audit trail. Where they diverge is whether a human clicks anything in between.

A — disk fills up on a managed Linux host (Tier 0, zero human touch):

1. Zabbix's own trigger fires on the host (disk use crosses its configured threshold) — this is Zabbix doing what it already does today, unmodified.
2. The Zabbix → ServiceNow webhook (built in Phase 0, see the deployment guide below) opens an Incident automatically, tagged with the host and the metric that tripped. No person has filed anything yet.
3. The orchestrator classifies the incident against known trigger signatures, routes it to the Linux Server agent, and scores it Tier 0: single host, fully reversible, matches a pre-approved action class (log rotation / temp cleanup).
4. The Linux Server agent runs that cleanup playbook directly — no dry-run, no approval record, because Tier 0 by definition doesn't require one — and confirms disk usage is back under threshold.
5. Platform Ops's flapping check means if the same host trips again within the next few minutes, it links to the same root-cause record instead of opening a second ticket.
6. The trigger payload, the plan, the action taken, and the verification result are appended to the immutable audit log; the Incident auto-closes with that record attached.

That's the entire loop for anything Tier 0: detect, act, verify, log, close. Nobody was paged, and nobody needed to be — the guardrail isn't a human in this loop, it's that only genuinely reversible, single-target actions are allowed to run unattended in the first place.

B — a missing security patch, the same host class (Tier 2, one approval click, not manual patching):

1. A nightly Tier 0 compliance scan (Platform Ops, read-only) diffs installed package versions against the patch baseline in the CMDB and finds a host group missing a critical CVE fix — no ticket needed to trigger this, it runs on a schedule.
2. The Linux Server agent stages the patch in a canary subset of that group and drafts a Change record with the dry-run output attached: the actual package-manager simulation diff, not a text summary of intent.
3. The orchestrator opens a native ServiceNow Approval on that Change and waits — this is the one deliberate step in the whole sequence, and it's a single approve/reject/edit decision against a real diff, not a request to go patch a server by hand.
4. Once approved, the agent installs on the canary host first, confirms it comes back healthy, then rolls to the rest of the group inside the approved maintenance window, verifying after each batch rather than all at once.
5. Before/after package versions, the approval record, and every verification result are written to the audit log; the Change closes itself against that evidence.

"Automatically administer the infrastructure" is everything except that one approval: the scan, the staging, the canary rollout, the batch verification, and the record-keeping all run unattended. What doesn't run unattended is the actual decision to change a production system's state — which is exactly the trade-off "Why a human still approves everything," above, argues for, just made concrete with a real patch instead of an abstract policy.

This walks the same four phases as the rollout timeline above, but as concrete build steps rather than a description of the end state. Each phase only starts once the previous one has run clean for a defined burn-in window — the point of a phased build isn't paperwork, it's that every new capability earns its trust against real evidence instead of a spec review.

Before writing any agent code, have in hand: a ServiceNow tenant with API access and a dedicated service account; a secrets vault (HashiCorp Vault or a cloud KMS equivalent) capable of issuing short-lived, per-agent scoped credentials; a datastore for the append-only audit log, provisioned independently of any agent so no agent can be the only place its own history lives; an isolated network segment or jump host for agents to run from, reachable only to the specific systems each domain agent needs — not flat access to everything; and, most important and easiest to skip, sign-off from the actual owning teams (security, network, server, database) on the tier definitions and deny-list before day one. A technically correct tier assignment nobody on the network team agreed to is a fight waiting to happen during a real incident, not before one.

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.

More to go with the blueprint above, all free, no signup:

• Integration guide — setup steps, API auth, and a working MCP server for each supporting system above (ServiceNow, NetBox, Zabbix, Grafana, Batfish, Ansible, Cisco ISE, Nexus Dashboard, Cisco Firepower Management Center, Catalyst Center, VMware Aria, Microsoft SCOM, Azure Monitor, MECM, Red Hat Satellite, APC power management, CyberArk, CrowdStrike Falcon, Splunk, NetApp ONTAP, Dell storage, Dell PowerSwitch, and the backup/recovery platform) and for the nine domain-agent target systems, with real code for each.
• Operations model & SOP — how this architecture actually gets run day to day once it's live: roles, on-call, incident response, change/maintenance windows, and periodic review cadence.
• Agent operations playbook — the operator's-side companion: the stateless operating loop, a fleet register, five golden signals, the intervention ladder, drills, and a phased adoption path for running the agents in these diagrams once they are live.
• Agent-to-agent coordination protocol — the wire format between the boxes in the diagrams above: the message envelope, the closed set of message types, delivery and ordering guarantees, handoff contracts, and the failure-handling rules that keep the fleet from stepping on itself.
• Peer-to-peer & distributed architecture — what it takes to federate this fully centralized design across sites, tenants, or organisations: no single orchestrator, contract-net task claiming, and a guide for when that trade is worth making.
• SOC & incident-response architecture — the sibling blueprint for an autonomous security operations centre: detection triage, enrichment, and reversible containment, with eradication and recovery kept human-owned.
• Screen-by-screen mockup — wireframes of what the ticket, the plan, the approval gate, and the audit log would actually look like on screen, walking one request through the whole lifecycle. Wireframes, not a live product — see the disclaimer on that page.
• Paid full editions — portable PDFs of this blueprint (16 pages, deployment-guide depth) and the integration guide (39 pages, every supporting system's setup + a working MCP server), if you want them offline or to hand to a team.
• Service desk readiness review — have your own design assessed against this same approval-gate, risk-tier, and credential-scoping model. $349, fixed price, written report.
• Interactive ticket trace — one concrete ticket stepped down the request-lifecycle diagram above, stage by stage: the messages on the bus, why the risk tier lands where it does, the human approval, and the audit log growing at each step.
• Download the operations SOP as a PDF — the operations model above, same diagrams, formatted to print or attach to an email.
• Download the architecture deck (.pptx) — a condensed slide version of the same material, built for presenting this to a room rather than reading it on screen.