Agent-First ITSM
A design pattern for ITSM that inverts the traditional flow: an AI agent gathers context, attempts resolution, and only escalates ready-to-resolve work to humans. The ticket becomes the record of what happened, not the mechanism by which work moves.
What It Is
Traditional ITSM treats the ticket as the unit of work: users file tickets, humans triage, route, clarify, and resolve. Forms and rules exist to translate user intent into a structured shape the system can process. Most human effort goes into managing the queue, not into the underlying problem.
Agent-first ITSM moves the agent to the front:
Traditional: User → Form → Ticket → Human triage → Human resolution
Agent-first: User → Agent → (resolution attempted) → ticket only if escalated
The ticket still exists — for audit, for hand-off, for cases the agent couldn’t resolve — but it’s an artifact, not the engine.
How It Works
Agent-first systems share a common architecture:
- Chat-native intake — Slack, Teams, or similar — so users ask in natural language without forms.
- Context gathering — the agent enriches the request with identity, device, history, organization, and policy data, often via a context graph spanning IdP/HRIS/MDM/ITSM.
- Resolution attempt — the agent reasons over a knowledge base, access policies, and pre-authored playbooks; takes scoped actions through integrations; asks clarifying questions when needed.
- Selective escalation — when the agent can’t resolve, the request lands in a triage-ready inbox with category, priority, and context already attached.
- Learning loop — patterns that recur become new playbooks; ad-hoc fixes get codified.
Why It Matters
The business case ^[inferred]:
- Volume reduction, not redirection. Workflow builders and chatbots often “deflect” tickets without resolving them; agent-first claims to remove work entirely from the human queue.
- Reframes IT as leverage. Headcount no longer scales linearly with ticket volume; capacity moves to system-level work.
- Inverts form-first ITSM. Schemas and structured fields get filled by AI from natural language, eliminating the user’s “translate my problem into your taxonomy” tax.
When to Use
Agent-first works best for:
- High-volume, repetitive request shapes — password resets, app access, onboarding/offboarding, status checks.
- Stacks with rich context graphs — IdP, HRIS, MDM, existing ITSM all connected.
- Chat-native workplaces — Slack/Teams already a primary surface.
Mismatches:
- Truly novel incidents that need human judgement (security investigations, complex outages).
- Highly-regulated work where every action requires explicit human approval.
- Companies without integrations to enrich context.
Trade-offs
- Requires scoped, audited agent execution — agents that take action raise the compliance bar (SOC 2 Type II, RBAC, scoped writes). See Console’s argument that this is now table stakes.
- Initial playbook investment — agents need explicit policy and workflow definitions to act safely.
- Risk of over-automation — automating broken processes hardens them; system-level redesign should precede automation in some cases.
Notable Practitioners
- Console — coined the framing publicly with their “Inbox designed to stay empty” positioning; chat-led / no-code style.
- Serval — code-led variant (“vibe coding for IT”); TypeScript-as-contract makes the agent’s actions auditable as Git diffs.
- Atomicwork — multimodal variant; the agent (Atom) takes input via chat, voice, and vision (screen sharing), with public list pricing and an Enterprise Knowledge Graph for context.
- STLabs — graph-led variant (pre-launch); positions Axiom context graph as the substrate the agent reasons over, with engineering self-service as a deliberate flank.
- Treeline — service-led variant; AI augments or resolves routine IT work behind a managed-service wrapper while human technicians remain in the loop.
- Moveworks, Aisera — earlier AI-IT entrants; Console argues these stop at deflection rather than execution.