The problem
A company of about 600 people ran internal IT through a shared Slack channel and a ticketing queue. Two recurring costs: the same "how do I get on the VPN" questions answered over and over, and access requests that bounced between the requester, their manager, and the system owner for hours before anything was provisioned.
The design principle
The agent routes approvals; it does not hold them. It can answer from the knowledge base freely, but any change to access is drafted by the agent and granted only after the correct human approves it in Slack. And the agent's control plane is never reachable from the public internet.
Architecture
The system is self-hosted in the client's cloud.
- An OpenClaw gateway daemon runs the agent on Slack, where the IT team already works. The gateway is reached only over Tailscale — there is no public endpoint, no inbound port.
- MCP servers for the identity provider, the MDM, the ticketing system, and the internal wiki. Read access is broad; write access is a short, explicit list — create a ticket, provision a named entitlement, enrol a device.
- A heartbeat drives SLA nudges — a stalled approval gets a reminder, then an escalation.
- Model-agnostic, with Claude as the default; a cheaper model handles classification.
Answering from the knowledge base
Routine questions — VPN setup, MFA reset, software requests, "is this email a phish" — are answered inline in the thread with a link to the wiki source. About 55% of interactions resolved this way with no ticket created. If retrieval is weak, the agent opens a ticket and routes it rather than guessing.
Access requests and approval routing
When someone asks for access, the agent works out the specific entitlement and the correct approver from the IdP and an ownership map, then posts a structured request into Slack: who, what, why, for how long. It provisions only after the approver clicks approve in the thread. Median time to access went from about seven hours to about forty minutes. There were zero automatic grants — the agent has no code path to provision without an approval event.
Guardrails
Least-privilege service credentials scoped to the exact write operations the agent needs. Every action — answer, ticket, request, grant — lands in an append-only audit log with the Slack thread linked. A kill switch disables all write tools and leaves the agent in answer-only mode; an operator can hit it from a command in Slack without a deploy. The gateway's isolation (Tailscale only, no public route) is part of the security review, not an afterthought.
What it costs to run
Compute in the client's account plus model usage — on the order of a few hundred dollars a month at this size. It absorbed roughly a full-time-equivalent of first-line IT work and took the friction out of access requests.
How we rolled it out
Knowledge-base answering went first, and we measured ticket deflection for a month. Then access requests ran in "draft the ticket, don't route" mode so the team could check the agent was identifying the right entitlement and approver. Then live approval routing, for a small set of low-blast-radius entitlements first, expanded as the audit log stayed clean.
This is the kind of system we build
If your IT channel is answering the same questions and chasing the same approvals, this pattern fits. Book a call, or see Tools & Integrations (MCP).
Publishing note: a representative composite of internal-IT agent work, not a single named client. Headcount, deflection, and timing figures are illustrative of the range we see.