What is agentic IT? A working definition for IT leaders

Agentic IT is software that does the IT work — investigates the request, plans the change, executes it under policy, and leaves an audit trail. Not a copilot. Not a chatbot. Not a smarter ticket router. An agentic IT system handles a task end-to-end the way a junior engineer would, except faster, and with safety controls that live in code instead of in someone's head.

The category is new enough that most products using the word "agentic" don't fit the definition. This post is the working one — for IT leaders trying to separate the real thing from the marketing.

The three jobs of an agentic IT system

Strip away the branding and an agentic IT system has to do three specific things. Other categories do parts of this; an agent does all of it.

Investigate. Before it does anything, the system gathers the context required to do the work well. Who is the user, what permissions do they have under your identity provider, what device are they on, what does the underlying system actually allow right now, has the user previously had access to this resource? This is the part most "AI for IT" tools skip. They start at the response, not the situation. An agent has to start at the situation.

A concrete example: an employee messages, "I can't get into the Finance SharePoint." Investigation means looking up the user in Entra ID, confirming their department, checking whether the SharePoint site exists, reading the access policy that governs Finance-tagged resources, and checking whether the user had access previously. Five separate lookups before the agent decides what to do. None of them surface to the employee.

Plan. With context in hand, the system decides what to do — and crucially, what not to do. The plan is conditional: if the user is in Finance, grant access; if they're in a peer department, route to the resource owner for approval; if their account has any open security flags, refuse and explain why. A real plan also includes a rollback step. "Try to grant access" without "and undo if approval isn't received" isn't a plan, it's a wish.

Execute. Then it does the work. Not "creates a ticket for someone else to do the work" — does the work itself, against the real system, with the real consequences. Resets the password. Grants the group access. Provisions the license. Opens a ticket only if the work can't or shouldn't be automated.

Investigate, plan, execute. Under explicit policy. With a full record of what happened. That's the loop.

What agentic IT is not

The word "agentic" has been claimed by a lot of products that aren't doing any of the three jobs above. Worth being precise about what it doesn't mean.

Not a copilot. A copilot suggests — drafts a response, recommends an action, summarizes a ticket. The human still does the work. Copilots make humans faster; agents make humans unnecessary for the specific task. Different category, different value, often confused. Microsoft Copilot for IT, the various ServiceNow assistants, every "ask me about your tickets" sidebar — those are copilots. They're useful. They're not agentic IT.

Not a chatbot. A chatbot has a conversation. It might answer questions from a knowledge base. It cannot reset a password, change a group membership, or modify a Conditional Access policy. If your "AI agent" doesn't have credentials and a permissions model, it's a chat interface in front of a search engine.

Not an ITSM. ITSM tools — ServiceNow, Jira Service Management, SysAid, Halo — track and route IT work. They're systems of record for tickets. An agentic IT system eliminates the ticket. Both belong in a healthy IT org: the agent handles 90% of work before it becomes a ticket; the ITSM handles the remaining 10% that need human judgment, plus the historical record of everything. We're not a ServiceNow replacement; we make most of what ServiceNow does invisible.

Not a "lightweight" AI agent. There's a flavor of "AI agent" that's basically a chatbot with two API calls — knowledge base lookup, then maybe a ticket creation. That's the Tier 1 chatbot the analysts have been writing about for two years. An agentic IT system handles L2 and L3 work — multi-step, cross-system, policy-gated execution. Different problem space, different architecture, different evaluation criteria.

Why "agentic": what governance looks like when software takes action

Autonomy is the easy part. Anyone can write a script that performs an action. The hard part — and the part that determines whether an agentic IT system is safe to run inside a real enterprise — is governance. Without it, an agent is a security incident waiting to happen.

The right model has three properties.

Policy lives in code, not in the prompt. Every action the system can take must match an explicit, structured policy. Not "the model has been told not to grant admin access" — that's a guardrail in a prompt, which is bypassable by prompt injection or model drift. The policy lives in code, before the action executes. No policy match, no action. Dex enforces this with a six-layer model — global organization, tenant, target rules, department, action type, runtime — every layer checked in code, not in instructions to a model.

Permissions are delegated, not borrowed. When the agent does work for an end user, it acts as the user — within the user's actual permission scope, bounded by what the user could do themselves. When it does work for an admin, it uses the admin's OAuth token. There is no shared service account with broad access to everything. This eliminates the "AI broke into production" failure mode that most AI-for-IT products have by design.

The audit trail is the deliverable. Every action the system takes is logged — in the underlying system's audit log (Microsoft 365, Okta, etc.) and in the agent's own activity log — with the policy that authorized it, the user it acted on behalf of, and the reasoning trace that led to the decision. Auditors love this. Compliance teams love this. It's the inverse of a black box.

The shorthand for this is governed autonomy: the agent acts, but only within explicit, code-level boundaries. That's the only model that survives enterprise scrutiny. Without it, the "agentic IT" label is just a faster way to introduce a new security incident.

For the security depth on how Dex implements this, see our security overview and architecture deep dive.

What changes inside an IT org when you adopt agentic IT

Once a meaningful percentage of routine IT work disappears, the IT organization changes shape. This is the part vendor pitches don't usually cover, because it's the part that affects budgets and roles, not just queues.

Tier 1 stops being a function. When 90% of L1 work is handled before it becomes a ticket, you don't staff Tier 1 the same way. The metric "ticket volume" stops being meaningful — you're measuring the work that didn't happen. Some teams collapse L1 entirely; others keep a small group focused on the cases that genuinely need human judgment.

Engineers do engineering. The work that ate L2's day — password resets, provisioning, license assignments, group access — moves to the agent. What's left for engineers is the work an agent can't do: architecture, integrations, root-cause investigations on novel issues, security and compliance work that requires human accountability. The team gets smaller as a fraction of overall headcount, but the people who remain are doing higher-leverage work.

IT becomes proactive. When the queue is empty, the team has time to fix the things that cause tickets in the first place. The shift from reactive to proactive isn't a slogan; it happens automatically once the volume drops.

A concrete example. Cliff DuPuy, Director of IT at Grand Traverse County (an MSP), told us that Dex helped them unlock $67,000 in value in a single day — work that would otherwise have required new headcount, deferred indefinitely, or both. That's not a productivity-improvement story. That's a "we could do the thing we couldn't do before" story. Those are the outcomes an agentic IT system actually produces.

How to evaluate an agentic IT tool (a buyer checklist)

Eight specific questions to ask any vendor claiming to be "agentic." If they can't answer cleanly, they're a chatbot with marketing.

1. Does it execute, or does it suggest? Ask for a live demo of the agent taking a real action — changing a setting, granting access, resetting a password — against a real Microsoft 365 environment. If the vendor pivots to "here's a recommendation it generated," they're a copilot, not an agent.

2. Where does policy live — in the prompt or in code? A prompt-level guardrail is bypassable. A code-level policy fails closed by default. Ask: "Walk me through the code path that enforces a deny." If they can't, the guardrails are decoration.

3. What's the permissions model? The two patterns are (a) a shared service account with broad access and (b) delegated permissions where the agent acts as the requesting user. The first is a security disaster waiting to happen. Only the second scales to enterprise.

4. Does it remember anything between sessions? A stateless agent re-learns every quirk of your environment every time. An agent with memory gets faster and more accurate as it sees more of your org. Ask what it remembers and what it doesn't.

5. Can it build a new integration mid-conversation? Most agents are limited to a fixed integration list. Real autonomy means the agent can read an API doc, write the integration code, store credentials, and use it inside the same task. Ask to see this live.

6. What does the audit trail look like? You want every action taken, the policy that authorized it, the user it acted on behalf of, and the reasoning trace. If they show you a transcript of the chat, that's not an audit trail.

7. How is data isolated? Per-org isolated databases with dedicated encryption keys are the table stakes. Shared databases with a logical tenant_id column are not. Ask the question; the answer tells you whether they were built for enterprise or are still selling to startups.

8. What does failure look like? Every system fails sometimes. An agent that fails by going silent, guessing, or hallucinating a successful action is dangerous. An agent that fails by stopping, escalating to a human, and producing a clear log of what it tried is safe. Ask for the failure-mode demo, not just the success demo.

Where Dex fits

Dex is the agentic IT engineer for Microsoft 365. Two products, one engine.

Dex Go is the user-facing agent. Employees talk to it in Microsoft Teams or Slack to resolve IT issues and requests — password resets, group access, software provisioning, device troubleshooting — and Dex Go performs the work itself, under your policy, with full audit. Most requests close without a ticket ever being filed.

Dex Pro is the admin-side counterpart. It runs the routine engineering work that fills the queue from the other side — discovery, configuration, audit, the long tail of admin tasks that fill an IT engineer's day. Same engine, different scope, same governance.

Both run on the policy + permissions + audit model described above. Both are SOC 2 Type 2, ISO 27001 / 27017 / 27018, GDPR-compliant, and HIPAA-aligned, with per-org isolated databases and zero data retention on Microsoft 365 content.

We're built by the team behind SysAid — the ITSM that 3,000+ organizations have run their IT operations on for two decades. SysAid is how we know what ITSM is for; Dex is what we built for the work ITSM isn't.

If you want to evaluate Dex against the eight questions above, book a working session and we'll walk through them live against your environment.