For a couple of months I used one phrase, “the case backend”, to describe three things that have nothing in common: where the agent reads evidence, where it writes its verdict, and where it talks to a human. They are separate axes with separate constraints, and one of them is decided by the customer’s licence rather than by any choice I get to make.
The three things
Untangled, they are:
| Axis | Question | What decides it |
|---|---|---|
| Telemetry estate | Where does the evidence come from? | The customer’s Microsoft licensing — not a design choice |
| System of record | Where does the verdict get written? | Follows from the estate; the incident lives where the alert fired |
| Human channel | Where does the conversation happen? | A real choice, and the one I got wrong twice |
Conflating the first and the third is the error, and it is easy to make because in a Microsoft shop all three are Microsoft products and they blur together in conversation. They should not. One is a licensing fact, one is a consequence, and only one is a design decision.
Track one: the telemetry estate, and the licence wall
This is the part I understated, and it is the most consequential thing in the chapter.
Sentinel is a SIEM. It runs on an Azure subscription and it contains whatever its connectors have been configured to bring in. You can stand it up on a bare Azure tenant with no Microsoft 365 licensing at all, and what you get is control-plane and directory material: Azure activity, sign-in and audit logs from the directory, service principal activity. Real telemetry, genuinely useful, and almost entirely about the cloud control plane.
Defender XDR is a different estate. Endpoint process and device events, mail flow and message events, identity signal from the endpoints themselves. That is where most of an actual intrusion becomes visible, and none of it is reachable from Sentinel sitting on a bare subscription. It is gated behind Microsoft 365 licensing — Business Premium at the small end, E3 or E5 with the appropriate add-ons above that.
Which is why building against both was not an abstraction exercise. Two estates, two query surfaces, two schema vocabularies, two sets of table names that mean similar things and behave differently — and a real parity problem, because a finding that is trivially available in one is structurally unavailable in the other.
This connects directly to the ceiling that coverage puts on confidence. My own lab tenant runs Sentinel with no Defender XDR, and that single licensing fact is the whole explanation for why two of seven evidence groups have never produced a finding, and why there are no endpoint or mail tables in the corpus chapter. I did not choose a thin tenant. I chose a licence tier, months earlier, without understanding that I was choosing the ceiling on every verdict the system would ever produce there.
Track two: the system of record
Less interesting, because it is mostly a consequence rather than a decision. The investigation attaches to the incident that triggered it, and that incident lives in whichever platform raised it — a Sentinel incident for Sentinel-sourced alerts, a Defender incident for Defender-sourced ones. Comments carry the reasoning, entities carry structured context, and case history gives the agent memory across investigations.
One genuine engineering rule came out of this. Reads choose between the management API and the query language based on freshness: the management API reflects the current state of an incident immediately, while the query interface lags but is far better for anything historical or aggregated. Picking per read, rather than standardising on one, removed a class of bug where the agent acted on a stale view of a case it had just written to.
Track three: the human channel, and two wrong answers
Here there was a real choice, and I made it badly twice before getting it right.
Jira came first, because it is what everyone already uses. Rich formatting, workflow states, comments as a conversation. It died on a single sentence from a prospect with data-sovereignty requirements: the ticket system is an exfiltration path. Every log excerpt quoted as evidence, every entity name, leaving the customer’s tenant for a third-party cloud under my account. The product’s central claim was being quietly falsified on every investigation, by the component I had chosen in week one for convenience and never revisited.
SharePoint Lists came next and fixed the sovereignty problem by staying inside the tenant. It was still wrong, for two reasons. It is a data store being used as a conversation medium, so the hard part was never storing the record — it was reliably detecting that a human had replied. The first attempt parsed replies with regular expressions and failed in every way you would expect; the fix was a convention, an explicit marker the reply is written after, plus a merge-patch write that did one predictable thing. Both times the simpler version replaced something cleverer and was shorter.
The second reason is fatal on its own: nobody looks at a SharePoint list. Putting an investigation somewhere technically correct and behaviourally invisible is not delivery.
Teams, and why it is the answer
Teams won, and it is not a compromise — it is better than both on every axis that matters.
It stays inside the customer’s tenant, so the sovereignty property holds. It is where the people already are, so an investigation verdict arrives in the place they are looking rather than a system they have to remember to check. Adaptive Cards give a verdict real structure — headings, evidence, an action — instead of a wall of text in a list cell. Replies are just replies, which removes the entire class of problem that made the SharePoint reply capture fragile. Reports upload as files into a channel the customer already owns.
And it is genuinely nicer to use, which is not a soft consideration when the buyer is a small provider whose team will see this every day. The comparison with a SharePoint list is not close.
What made the moving around survivable
An interface, defined early, with the agent core knowing nothing about where any of this lived: open a case, append a comment, ask a question, record a verdict, search history. Several implementations behind one contract.
I would like to claim foresight. It was closer to luck — the interface existed because the original design had to support two case systems simultaneously for commercial reasons, not architectural ones. That accidental seam is the only reason changing these pieces cost days instead of weeks.
The lesson
Name your axes before you build against them. “Backend” was doing three jobs in my head, and the cost was not just vocabulary: it let me treat a licensing constraint as if it were an engineering choice for longer than it should have.
The specific version, for anyone building on the Microsoft stack: work out what the customer’s licence actually exposes before you design anything that depends on evidence being there. Sentinel on a bare subscription and a full Defender estate are not two configurations of the same system. They are different amounts of visible truth, decided by a procurement decision you had no part in.