Every government M365 tenant I have ever opened is overpaying for licenses nobody is using. That part is not controversial. What surprises people is that the standard cleanup tools, the “find inactive users and reclaim” scripts, usually make the problem worse. They reclaim the wrong accounts, miss the expensive ones, and quietly create a help desk fire two weeks later when a payroll service account loses its mailbox.
I built an agent that recovered 400+ G3 GCC licenses in a production environment. Roughly $105,000 a year at list pricing, recovered without a single “why did my account stop working” ticket. This is the teardown of why M365 license recovery automation in GCC needs contextual inference, and why a rules engine will never get you there.
What Rules-Based License Recovery Actually Does
The classic reclamation rule is one line of logic: if an account has not had an interactive sign-in in 90 days, flag it for reclaim. Some tools add “and the account is disabled” or “and the mailbox last logon is stale.” That is the whole brain.
It feels safe because it is measurable. Sign-in date is a hard number. The problem is that a sign-in date answers the wrong question. It tells you when a human last typed a password. It does not tell you what the license is doing, who depends on it, or whether pulling it breaks something three systems away.
The Accounts a 90-Day Rule Gets Wrong
Here is what the simple rule reclaims by mistake, every time. Service and integration accounts that authenticate through Graph or app tokens and never show an interactive sign-in, but quietly run half your automation. Mailboxes on litigation hold, where yanking the license is a legal problem, not a cost saving. Accounts for staff on military, medical, or seasonal leave, who come back in month four to find their identity gutted. Shared mailbox owners and delegate chains, where one stale-looking account is load-bearing for five active ones.
And here is what it misses entirely, which is where the real money lives. The account that logs in every single day, looks perfectly active, and is sitting on a full G3 while using exactly one workload. That person does not need a $22 seat. They need an F3, or Exchange-only, or nothing. A 90-day rule will never flag them because by its only metric, they pass. You can be aggressively reclaiming the wrong tail while the expensive middle of your tenant goes untouched.
A sign-in date tells you when someone typed a password. It tells you nothing about what the license is doing.
Contextual Inference: Classify the Account, Not the Login
The agent I built does not ask “did this person log in.” It asks “what is this account, and what is the cheapest correct state for it.” To answer that, it pulls a stack of signals instead of one. Interactive and non-interactive sign-in logs. Per-workload usage from the Graph usage reports, so Exchange, Teams, SharePoint, and OneDrive activity are scored separately rather than rolled into one yes-or-no. License assignment path, direct versus group-based, because that changes how you remediate. Litigation hold and retention status. Mailbox type and delegate relationships. HR or directory status where it is available. MFA registration as a proxy for whether a real human ever owned the account.
Then it reasons over that stack and sorts each account into an action with a written rationale: reclaim, downgrade to a cheaper SKU, convert to a shared mailbox, keep as-is, or send to a human because the signals conflict. The last bucket matters more than the others. A good agent knows what it does not know and escalates instead of guessing. That is the difference between cost recovery and an outage.
The output is not a kill list. It is a defensible recommendation per account, with the evidence attached, that a human approves in bulk. Nobody reclaims 400 licenses on faith.
Why GCC Makes This Harder, Not Easier
If you have only done this in commercial M365, you are about to have a bad week. The off-the-shelf SaaS reclamation products that the commercial world reaches for mostly cannot operate inside the GCC (Government Community Cloud) boundary, and the ones that claim to often want data to leave it. That is a non-starter. So you build inside the boundary, against GCC Graph endpoints, which do not always behave like their commercial twins.
Usage report data in GCC lags, and if your tenant has concealed usernames turned on for privacy, the reports come back de-identified, which breaks any tool that expects to map usage to a UPN. The agent has to account for report latency so it does not flag an account as idle when the data is simply three days stale. None of this is exotic. It is just the unglamorous reality that commercial playbooks die quietly in GCC, and the only thing that survives is a solution built for the constraint from the first line of code.
What 400+ Licenses Looks Like on the Budget
If you are a CIO, the pitch is that your tenant is almost certainly carrying six figures of recoverable spend, and the reason your last cleanup did not find it is that the tool you used was answering the wrong question. If you are a CFO, the number is simpler. Four hundred G3 GCC seats is in the neighborhood of $105,000 a year, recurring, that does not require a budget request to recover. It requires one engineer and the right logic.
The recurring part is what people underweight. This is not a one-time sweep. Built right, the same inference runs on a schedule and keeps the tenant clean as people leave, change roles, and over-license themselves. The savings compound because the drift never gets a chance to.
Who Built This
I am Jacob, a U.S. Navy veteran and the engineer behind Puget Sound AI, a veteran-owned small business (VOSB) that builds M365 and AI automation inside government GCC environments. Not roadmaps, not slideware. The system above is the kind of work I scope, build, and hand off myself, with documentation, so your team owns it after I leave. Solutions are architected to operate within Microsoft’s FedRAMP-authorized GCC boundary and aligned to CMMC and NIST 800-171 control objectives.
If your license bill feels heavier than your headcount justifies, that is usually a measurable problem with a fast payback. Let’s talk.