How many M365 tenants can one MSP engineer manage?

Under a traditional support model, a support engineer typically covers around five mid-size Microsoft 365 tenants before ticket volume forces the next hire, because routine L1-L3 work scales linearly with client count. With an autonomous IT engineer resolving L1 through L3 across every tenant, a single senior engineer can supervise 40 or more tenants, because they are handling exceptions and governance rather than the routine queue itself.

How do MSPs scale without hiring more technicians?

The only way to scale an MSP without a headcount curve that tracks client growth is to break the link between ticket volume and labor. Agentic IT does this by investigating, planning, and executing routine M365 work autonomously across all tenants at once, so adding a client adds compute cost rather than a proportional share of an engineer's salary. Human engineers move from clearing the queue to defining policy and handling the genuinely hard cases.

Does autonomous IT work across multiple tenants at the same time?

Yes. Dex Pro operates per tenant using the admin's own delegated permissions, with per-org isolated databases and encryption keys, so one console supervises many Microsoft 365 tenants without co-mingling client data. Each tenant carries its own policy set, so the same autonomous engineer enforces different rules for different clients simultaneously.

Is autonomous IT only for Tier 1 MSP tickets?

No. Dex autonomously resolves L1 through L3 - routine password, MFA, and access work as well as deeper Tier 2 and Tier 3 troubleshooting, configuration, and engineering-adjacent tasks that used to require a senior technician. Only genuine architectural and judgment cases escalate to a human, and they arrive with full context attached.

What is the ROI of agentic IT for an MSP?

The ROI comes from decoupling revenue growth from headcount growth. In a traditional MSP, gross margin per client is capped by the labor needed to support it; adding clients adds cost at nearly the same rate as revenue. When an autonomous engineer absorbs the routine L1-L3 load across every tenant, the marginal cost of the next client drops toward the cost of compute, so each new tenant lands closer to full margin. Grand Traverse County, an MSP running Dex, described unlocking $67,000 in value in a single day once its team stopped owning the queue.

The MSP Tenant Math: What Changes When One Engineer Runs 40 M365 Tenants

Every managed service provider is priced against the same hidden constraint: the number of Microsoft 365 tenants one engineer can actually run. Grow past it and you hire. Hire and your margin per client compresses, because senior M365 engineers are expensive and slow to find. This post works through the economics of that constraint, why the technician-per-tenant model has a ceiling no pricing trick can lift, and what changes when an autonomous IT engineer resolves L1 through L3 across dozens of tenants at once. It is the math behind Dex for MSPs, which we reveal on July 8.

The curve every MSP is fighting

An MSP's cost base is labor, and MSP labor scales with tickets, and tickets scale with clients. That chain is the whole problem.

In a traditional support model, a support engineer covers roughly five mid-size M365 tenants before the routine queue - password resets, MFA recovery, license and group access, mailbox and SharePoint permissions, device and configuration issues - forces the next hire. The exact ratio varies with tenant size and SLA, but the shape does not: support cost rises in a nearly straight line with tenant count. Ten tenants need two engineers. Forty tenants need eight. Eighty need sixteen.

That linear curve is why MSP margins are structurally thin. Revenue per seat is roughly fixed by a competitive market. Cost per seat is set by how many engineers you need to keep the queue clear. Every time you cross a staffing threshold, you take a margin hit until the new hire is fully utilized - and then you approach the next threshold and do it again. Growth feels like running to stay in place.

The usual responses do not change the slope of the line. Offshoring lowers the cost per engineer but keeps the headcount-per-tenant ratio. Better ticketing tools route the work faster but a human still does it. Self-service portals deflect the simplest cases and leave the rest. Each helps at the margin. None of them breaks the link between client count and labor. We wrote about the mechanics of this ceiling in detail in how MSPs scale IT support without a linear headcount curve.

What one autonomous engineer changes

To break the curve you have to break the thing that makes it a curve: the assumption that resolving a ticket requires a person.

Dex is an autonomous IT engineer for Microsoft 365. It does not route work or suggest answers - it investigates the tenant, plans the change, and executes it under explicit policy, then closes the loop with a full audit trail. Critically, it does this across L1 through L3: not just the password-and-access layer, but the deeper Tier 2 and Tier 3 troubleshooting, configuration, and engineering-adjacent work that used to define a senior technician's day. Only genuine architectural or judgment cases escalate to a human, and they arrive with context attached.

For an MSP, the decisive detail is that this runs per tenant, in parallel, from one place. Dex Pro operates through the admin's own delegated permissions, with per-org isolated databases and encryption keys, so a single console supervises many tenants without co-mingling client data. Each tenant carries its own policy set. The same autonomous engineer enforces one client's Conditional Access rules and another client's provisioning workflow at the same moment, because the guardrails live in a deterministic policy engine, not in a person's memory. No policy, no action - that boundary is enforced at the code level, per tenant.

So the engineer's job changes shape. Instead of clearing forty tenants' worth of queue, one senior engineer defines the policies, reviews the exceptions, and handles the small residue of genuinely hard cases. The routine load - the part that used to set the headcount ratio - is absorbed by the autonomous engineer running everywhere at once.

$Line chart comparing traditional MSP support cost rising linearly with tenant count against agentic IT cost staying flat, with the crossover point labeled.$

The tenant math, worked out

Here is the model with concrete numbers. Use your own ratios for your actual case; the structure is what transfers.

Traditional model. Take an MSP running 40 M365 tenants at roughly one support engineer per five tenants. That is 8 engineers. At a loaded cost of $90,000 per support engineer:

40 tenants  ÷  5 per engineer  =  8 engineers
 8 engineers  ×  $90,000        =  $720,000 / year in support labor

Support labor works out to about $18,000 per tenant per year - and, importantly, that per-tenant number does not fall as you add clients. Tenant 41 costs roughly what tenant 4 cost. The line keeps climbing.

Agentic model. Now let the autonomous engineer resolve 90% of the L1-L3 load across all 40 tenants. The residue - exceptions, policy authoring, the genuinely hard cases - is supervised by one senior engineer at a loaded cost of $130,000, plus the platform cost of running Dex across the fleet:

1 senior engineer  ×  $130,000  =  $130,000 / year
       + platform cost (scales with usage, not headcount)

The senior engineer's capacity is no longer set by ticket volume, because they are not working the tickets - they are governing an autonomous engineer that is. One person can stand behind 40 tenants, and the same person can stand behind 60 without a proportional new hire, because the marginal tenant adds compute, not salary.

The comparison that matters is not the absolute figures - plug in your own - it is the two shapes. Traditional support cost is a rising line: every batch of five tenants adds an engineer. Agentic support cost is nearly flat: the base covers a wide range of tenant counts before you add anyone. Those two shapes are what the chart above draws.

Why the crossover comes early

The interesting number in a linear-versus-flat comparison is the crossover: the tenant count above which the flat model is simply cheaper. For MSPs, it arrives sooner than most owners expect.

The reason is the per-tenant labor cost. At $18,000 per tenant per year, a traditional MSP spends the equivalent of a single senior engineer's loaded cost roughly every seven or eight tenants. An autonomous engineer that covers dozens of tenants for one senior engineer's supervision therefore passes the break-even point in the single digits of tenants and then keeps pulling away. Past the crossover, every additional client the traditional MSP wins costs it a growing slice of an engineer; every additional client the agentic MSP wins lands closer to full margin.

That is the strategic point behind the math. In the traditional model, growth and margin are in tension - you win the client and give back the margin to the hire you need to serve them. In the agentic model, growth and margin move together, because the cost of the next tenant has been decoupled from the cost of the next engineer. An MSP that breaks the curve can bid on work its technician-per-tenant competitors structurally cannot price.

What doesn't change (and shouldn't)

Breaking the labor curve does not mean removing the humans or the controls. Two things stay firmly in place.

Governance stays strict. Every action Dex takes has to match an explicit, per-tenant policy, enforced deterministically rather than by a prompt that a clever input could talk around. Dex never bypasses MFA and never grants itself admin roles. Every change is logged in both the Microsoft 365 audit trail and Dex's own activity log, per tenant - which is exactly the evidence an MSP needs when a client asks who changed what. Dex Pro is human-in-the-loop by design: it shows its planned actions before executing, with bulk approval for repetitive operations.

Your ticketing system stays too. Dex is not an ITSM and does not replace one. It resolves the work before it becomes a ticket and uses your ITSM - SysAid, ServiceNow, Jira, Halo - as the system of record for what remains. The autonomous engineer clears the queue; the ITSM still tells the client what was done. The two are complementary, and an MSP keeps its reporting and SLA machinery intact.

What changes is only the part that was always meant to be leverage: the routine, policy-bounded work that consumed engineers' days without needing their judgment.

What to do with this

If you run or operate an MSP, three moves follow from the math.

Measure your real per-tenant labor cost. Take your support headcount, load it fully, and divide by tenants. That single number - not your per-seat price - is the ceiling on how many clients you can profitably add under the current model. It is also the number the agentic model attacks directly.
Ask any automation vendor for end-to-end resolution across L1-L3, not deflection. A tool that deflects the easy cases to a portal leaves the labor curve intact, because the residue still needs engineers. The number that changes MSP economics is the share of routine work resolved end-to-end, under policy, with an audit trail - across all three tiers, not just Tier 1.
Model the crossover for your fleet. Run your own tenant count against the flat-versus-linear comparison above. If you are past the crossover - and most MSPs above a handful of tenants are - the technician-per-tenant model is quietly costing you the margin on every client you win.

Grand Traverse County, an MSP running Dex, put the recovered-capacity effect plainly: "Dex helped us unlock $67,000 in value in a single day." That was not a cost-cutting number. It was work the team finally had time to do once the queue stopped owning their attention.

The technician-per-tenant model is not inefficient because MSP engineers are slow. It is inefficient because the routine work never needed an engineer in the first place. Remove that assumption and the curve stops being a curve. That is the reveal on July 8 - and it is where Dex for MSPs starts.