When Dex Hands Off: Drawing the L3 Line Between AI and Your Best Engineers

The objection that comes up most often in IT leadership conversations is not "can it do the work." It is "where does it stop." An autonomous system that resolves L1 through L3 sounds like a system that eventually starts making calls your senior engineers should be making, and an IT director who has spent five years building a strong team is right to push on that before anything touches their tenant.

So here is the boundary, stated plainly. Dex resolves L1 through L3 autonomously, and hands off to a human when a request is novel, requires business judgment rather than technical judgment, has no policy permitting it, or carries a blast radius that a person should own. That line is not a limitation we apologize for. It is the design, it is enforced in code rather than in a prompt, and it is the reason the autonomy is deployable at all. This post covers exactly where the line falls, the four conditions that trigger a handoff, what a good handoff contains, and how to move the line yourself.

Most vendors draw the line one or two tiers too low

The default assumption in the market is that AI handles Tier 1 and humans handle everything above it. That framing is comfortable, and it is also why so many "AI for IT" deployments produce a disappointing number six months in.

Tier 1 is the highest-volume slice of the queue, but it is not where your engineers' time actually goes. Password resets and license assignments are quick. What consumes a senior technician's week is the middle: a mailbox that stopped receiving external mail after a transport rule change, a Conditional Access policy interacting badly with a device compliance state in Intune, a SharePoint permission inheritance chain nobody has mapped since the last migration, an Entra ID group whose dynamic membership rule silently stopped matching. Each of those takes investigation. None of them takes architectural judgment. They are Tier 2 and Tier 3 work by every standard taxonomy, and they are exactly the work an autonomous engineer should be doing.

Drawing the line at Tier 1 means the automation harvests the cheap tickets and leaves the expensive ones. The queue shrinks in count and barely moves in hours. That is the deflection trap described in the three questions that separate agentic IT from chatbot copilots: containment improves while the workload stays put.

Where the line actually falls

Dex investigates, plans, and executes across L1 through L3. The tier a request lands in does not determine whether Dex handles it. The nature of the request does.

At Tier 1, Dex resolves the routine, policy-bounded surface: password resets, account unlocks, MFA recovery, group and license access, software provisioning, basic device issues. At Tier 2 and Tier 3, it does the multi-step work: tracing a failure across Exchange Online and Entra ID, correcting a misconfigured policy, reconciling permissions after a migration, building an integration to a SaaS platform mid-conversation when the request needs one. Dex runs up to 40 reasoning steps on a single task and does not stop at the first error, which is what allows it to work cases that a script-bound tool abandons on the first unexpected API response.

What crosses to a human is the residual: the genuinely novel, the genuinely ambiguous, the unpermitted, and the high-consequence. In practice that is a small fraction of inbound volume, which is what the 90%-plus end-to-end resolution rate describes. The remaining share is not the work Dex failed at. It is the work that should have been on a senior engineer's desk in the first place.

The four conditions that trigger a handoff

Novel, not just hard

Difficulty is not a handoff trigger. Novelty is. A hard problem with precedent in the environment is something Dex can investigate, because its persistent memory retains API behaviors, environment quirks, and prior solutions from earlier sessions. A problem with no precedent anywhere, where the correct approach has to be invented rather than derived, is a different category. That is design work, and design work goes to a person.

Business judgment, not technical judgment

"Which group grants access to this site" is a technical question with a discoverable answer. "Should this contractor have standing access to the finance SharePoint site through the end of the quarter" is a business question wearing technical clothing. The second one has no correct answer inside the tenant. It depends on risk tolerance, on a relationship, on something the requester's manager knows and the system does not. Dex escalates these rather than guessing, because a confident guess on a judgment call is the exact failure mode IT leaders are right to fear.

No policy, no action

This one is structural rather than discretionary. Every action Dex takes must match an explicit, structured policy, enforced in code at the execution layer across six layers from global scope down to runtime. When no policy permits an action, Dex cannot take it, regardless of how sensible it would be or how persuasively a user asks. The request stops and surfaces to a human. That is not the model deciding to be careful; it is a check the model cannot reach, which is what makes prompt injection a non-event rather than an incident. The security and governance model covers the enforcement layer in detail.

Blast radius wide enough to warrant a human

Some changes are correct and still should not happen unsupervised, because being wrong about them is expensive. Tenant-wide configuration, bulk operations on many accounts at once, anything touching authentication posture. Dex Pro handles this with a human in the loop by design: it shows the planned action before executing, with an "Approve Always" option once an admin trusts a given pattern. Dex Go is scoped harder still, able to act only on the requesting user's own account and never on someone else's. The blast-radius boundary is where your team chooses how much rope to give, per action class, in policy.

A handoff is a finished investigation, not a forwarded ticket

The escalation itself is where most automation quietly destroys value. A tool that escalates by dropping the user's original sentence into a queue has done worse than nothing: it has added latency and a layer of false confidence, and your engineer still starts from zero.

When Dex hands off, the case arrives with the work already done. What was requested. What was checked, in which systems, and what came back. Which hypotheses were eliminated and on what evidence. The action Dex was preparing to take. The specific reason it stopped, whether that was a missing policy, an ambiguous business decision, or an environment state that did not match any known pattern. Every step is in the audit trail, in both the M365 logs and Dex's own activity log.

The difference in engineer experience is the whole point. The escalation is not "user cannot access SharePoint, please help." It is "user cannot access the finance site; group membership is correct, license is valid, permission inheritance was broken by a change at 02:14 UTC; the fix requires re-granting at the parent site, which no policy currently permits for this scope; approve or amend policy." One of those is a ticket. The other is a decision that takes ninety seconds.

Why the boundary is what your best engineers want

The concern under the skepticism is rarely technical. It is that autonomous IT quietly deskills a team, or takes the interesting work, or eventually makes a judgment call a human should have owned and gets it badly wrong in front of the CIO.

The boundary above does the opposite. It routes every routine and semi-routine case away from your senior people and routes every novel, ambiguous, or high-consequence case toward them with the investigation already complete. That is a straight upgrade to the composition of their week: less triage, less context-switching, more of the architecture and security work that has been deferred for two years because the queue never went quiet.

Cliff DuPuy, Director of IT at Grand Traverse County, put the effect in concrete terms: "Dex helped us unlock $67K in value in a single day." That was not a productivity percentage. It was work the team finally got to do once the queue stopped owning their attention.

Autonomy you cannot bound is not autonomy. It is exposure. The line is what makes the rest of it safe to turn on.

How to draw your own line

The boundary described here is the default, not a fixed constraint, and the useful exercise before any deployment is deciding where you want it.

Start by listing the action classes in your environment and sorting them into three buckets: autonomous, autonomous-with-notification, and approval-required. Most teams find the first bucket is far larger than expected, and the approval-required bucket small and specific, usually authentication posture and anything tenant-wide. Then write the policies, because once the routine work is handled the constraint is no longer engineer hours; it is how precisely your policies express what is allowed.

Two things make that tractable. Dex Pro uses the admin's own delegated OAuth token rather than a broad shared API key, so its reach is bounded by permissions the admin already has. And Dex never retains M365 data, reading only what a task requires and discarding it after. Escalated cases go to your ITSM as the system of record, whether that is SysAid, ServiceNow, or Jira, so the hard tickets stay tracked while the routine ones stop being created at all.

For the investigate-plan-execute sequence in more detail, including how Dex decides what to check before it acts, see how Dex works end to end.

The question worth asking a vendor is not whether their system can be trusted with your environment. It is whether they can tell you, precisely and in advance, what it will refuse to do. If the answer is a paragraph about how carefully the model was trained, there is no line. If the answer is a policy file, there is.