The Employee Context Graph Behind an AI Service Desk

Every ITSM vendor now says "AI-powered." The phrase tells you nothing about what happens the moment an agent tries to act on your data instead of just answering a question about it.

Most vendors run comparable models. What separates them is what the model is allowed to see before it responds and what it's allowed to touch after, a problem that surfaces the moment a request needs more than context for AI agents to hand back a canned reply.

This is what we mean by an employee context graph. It's the structured record an AI agent reads before a request even arrives, and the boundaries that decide what it's allowed to do next. Here's what that looks like inside Siit, end to end.

TL;DR

• Every ITSM vendor claims to be AI-powered; what separates them is whether the agent has real context and whether its actions stay governed.
• An employee context graph is the structured record an AI agent reads before a request arrives, and the rules that decide what it's allowed to do next.
• Governed context gets more useful over time: customers running this for years - Swile, Unit, Mirakl, and Qonto - show it firsthand.
• An employee context graph is the practical difference between AI-native ITSM and a model bolted onto a legacy ticketing queue.
• Siit builds that employee context graph before every request, with its own MCP server, live at mcp.siit.io/mcp, as public proof the governance claim is real.

What Happens Before an AI Agent Answers a Request?

Picture a request landing in Slack: "I need Salesforce access for the new AE starting Monday." A model with no context asks three clarifying questions before it can act. A model with an employee context graph already has the answer sitting in front of it, pulled from records that existed before the request did:

• Who's asking, and what team they manage
• The new hire's role and start date
• The company's approval policy for that specific app
• Who signs off before access is granted

Siit's AI agent evaluates the request against that pre-built profile, routes an approval card to the manager's DM, provisions the access in Okta once approved, and confirms in the same Slack thread. No portal, no separate ticket to check on, no follow-up message asking for a status update. That's the difference between an AI feature bolted onto a ticketing queue and an agent that acts inside a graph of who, what, and under what conditions.

What Is an Employee Context Graph Built From?

Strip the layers most "context engineering" writing uses down to the two that matter here: context and graph. The others (prompt, harness, loop) are background detail, useful for an AI-engineering audience but not for explaining what an AI service desk does.

Siit's Unified Data Model is what makes the context layer possible. It collapses HRIS, MDM, and IAM into the one record the agent reads, so there's nothing left to reconcile before it acts.

The graph layer is what keeps that access accountable. Every action an agent takes against that context runs inside role-based permissions, routes sensitive steps to a human approval first, and lands in an audit trail. Context without governance is a bigger attack surface with a friendlier interface. Siit builds the two together on purpose.

What Does Siit's MCP Server Let a Connected Agent Do?

Siit's own MCP server is the clearest public evidence for this. It's a live connector endpoint at mcp.siit.io/mcp, meant to be added inside an MCP-compatible client like Claude or Cursor. It gives those connected clients read and write access to a defined set of objects, described in Siit's own documentation as "requests, people, your CMDB, your service catalog, and your knowledge base." Nothing broader than that, and nothing implied.

The scope isn't left to trust. Siit's documentation states plainly that "every action runs on your authenticated account and follows your Siit roles and permissions, so it never goes beyond what your role allows," and that the resulting activity is "auditable by design." An agent connected through it can't see or do more than the person operating it could already see or do inside Siit. The employee context graph is what it reads from, and the permissions on that graph are what bound it.

What Governed Context Looks Like After Years of Use

Governed context gets more useful the longer it's in place, since every resolved request adds to the record the next one draws from. In Swile's scaling story, IT Director Louis-Marie Fusco puts three years of that in one line: "It's the orchestration layer of our entire IT operation." Swile's AI agent now triages 100% of the company's IT tickets and runs 160 automated workflows, up from 75. Account creation, once a 40-minute manual task, now takes 5.

Unit's lean IT story adds the governance side under real audit pressure. A two-person IT team supports over 200 employees across three countries under strict SOC 2 requirements, with risk-based approval built in: automatic for basic apps, manager-plus-owner for standard ones, and the COO added for sensitive ones. Adi Avraham, Unit's Head of IT, sums up what changed: "Siit evolved from an IT service desk into our company-wide operations hub." Helpdesk labor fell 60%, and the team avoided hiring one to two additional people.

Mirakl and Qonto show the same pattern on narrower problems: Mirakl's provisioning story took a seven-person team from 120 manual actions a month to zero in a week, and Qonto's results with Siit show a 28% ticket deflection and SLAs cut in half, once a VPN issue that used to generate 20 to 30 requests a week finally had somewhere structured to route through.

AI-Native ITSM Means More Than a Model Attached to a Queue

A structured employee context graph is the practical difference between AI-native ITSM and AI bolted onto a legacy ticketing system. Agentic ITSM names the same requirement in the language IT buyers search for: an agent that can complete a process on its own, without routing every step back through a human first.

Every incumbent ticketing tool can attach a model to its existing queue and call the result agentic. The context that model reasons from decides whether the result is a chatbot with API access or one of the trustworthy internal agents that can complete a process end to end without a human re-checking every step.

Where the Boundary Actually Sits

Some actions still route to a human, and that's by design. Siit's AI agent, when it's routing requests across departments, sends sensitive steps, like the ones tied to compensation, legal, or high-privilege access, to a human approval before they execute. What matters is whether the system enforces that boundary on its own. A passive assistant would leave the judgment call to whoever's asking.

Every resolution, human-approved or fully automated, writes to the same requests resolved end-to-end timeline. An admin can answer "what did the agent do, and who approved it" for any request in the system, including the ones that never needed escalation.

The Context Graph Is the Engineering Claim

The AI-powered claim every ITSM vendor makes is only as real as what the agent behind it can see and what it's allowed to do with that access. An employee context graph is how Siit makes both of those verifiable. It's built on context-aware resolution, with a record the agent can act from before it responds.

Swile, Mirakl, and Qonto all got there the same way: a record the agent could trust, and rules it couldn't cross. Unit's team says it best: "Where the SaaS app has SSO and SCIM provisioning, we can automate the whole process. The employee requests access, it goes through the approval chain, and they get notified when it's done. Completely automated," says Adi Avraham, Head of IT. Every one of those actions lands in the audit trail Unit's SOC 2 auditors now check automatically.

Want to see what your own employee context graph would look like inside Siit? Book a demo.