Unified Context: What an AI Service Desk Needs to Know Before It Acts

Unified context is what an AI service desk knows about an employee before acting on a request: who they are, what they have, what applies, and what was done before. Siit, the AI service desk for internal IT and HR requests, builds it from HRIS, identity provider, MDM and knowledge base data, reconciled and permission-scoped before the request arrives.

An access request lands in Slack at 9:04. Resolving it takes four minutes. Finding out whether it should be resolved takes forty: who this person is, who their manager is now, what they already have, whether the same request was approved for the same role last quarter. The process is fine. The problem is everything the process assumes someone already knows.

That gap is what IT and HR teams run into when they add an AI agent. The agent can follow the process. It cannot walk over to a colleague to ask which manager is current, or remember what was decided in March. Everything it does not know, it either asks the employee for or gets wrong. Gartner's ITSM Data Governance Playbook for Agentic AI (August 2026) puts it in analyst language: "While ITSM is one of the most likely domains to experience success with AI, data quality issues plague heads of I&O during implementation."

This guide defines unified context, the knowledge an AI service desk needs before it acts, and shows how to build it, govern it and keep it current.

Why do AI agents fail in internal IT and HR support without context?

Ask an agent a question it can answer from a document, and it does well. Ask it to act for a specific person inside a specific company, and the failures are predictable. It approves a request for someone who left last month. It routes an approval to a manager who changed teams. It locks the laptop of the previous owner. It treats a VPN question as one person's problem in the middle of an outage. In each case the model did its job. It did not know who was asking, what they had, what applied, or what had been done before.

The evidence matches the anecdotes. In February 2025, Gartner predicted that "through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data." TheAgentCompany, a Carnegie Mellon benchmark that gives agents real tasks inside a simulated company, HR and admin work included, found in 2025 that "the most competitive agent can complete 30% of tasks autonomously."

The reflex is to give the agent more: every document, the whole history, a bigger window. That makes things worse. Research on long inputs shows that models lose accuracy as the context grows, a pattern Anthropic's engineering team calls context rot. Their conclusion applies directly to a service desk: the goal is "the smallest possible set of high-signal tokens," which in practice means the handful of facts an experienced admin checks before touching a request. Those facts exist. They live in four or five systems that do not agree with each other.

What is unified context?

Unified context is the reconciled record of an employee and their situation that an AI service desk reads before it answers or acts. It answers four questions.

• Who is asking? Role, team, department, office and legal entity, manager, employment status (employee, external, alumni), start and end dates. The HRIS is the system of record.
• What do they have? Apps, groups and entitlements from the identity provider. Devices and their state from the MDM. Licenses and equipment from the asset catalog.
• What applies? The service they are asking about and how the company defines it, the policies and approval rules, the relevant knowledge, and what is going on right now: an incident, a change freeze, an onboarding wave.
• What was done before? Their past requests and how they ended, the approvals and exceptions, and the dated changes on their record: role changes, access granted or removed, resets.

Two words carry the definition.

Unified means reconciled, not collected. Connecting systems is the easy part. The hard part is that they disagree. The HRIS moved an employee to Finance on the 1st, the identity provider still lists her in the Product groups, and the MDM shows her old laptop assigned to someone else. Each system is consistent on its own. A unified record settles the conflict by naming, for every field, the system that is right. Which one that is depends on the company: the manager may come from the HRIS in one organisation and from the identity provider in another. Siit lets admins make that choice for each People field, on the schema described in its unified data model. The result is one employee record that IT, HR and any other team on the desk read through their own lens, instead of several copies that drift apart.

Context means scoped to the request and to whoever is reading. An agent handling a laptop request has no business seeing compensation, and should not be able to retrieve it. The same record shows different fields to IT, to HR, and to the agent working for each of them.

‍

The four questions are answered before the agent proposes a plan. An admin approves it, the actions run, and the resolution becomes part of the answer to the fourth question for the next request.

What does an AI service desk need to know before it acts?

The table is the practical version of the four questions. Use it to audit what your service desk can see today, and what it still has to ask the employee for.

‍

Context breaks at predictable moments, and a mover is the hardest case. The HRIS record changes on day one, but the groups, the device and the approval chain still describe the old job. Gartner found in 2023 that 47% of digital workers "struggle to find information or data needed to effectively perform their jobs." For an admin handling a mover, the information exists. It is spread across systems that no longer agree.

Reorganizations do the same thing in bulk: any approval rule tied to a person rather than to a role routes to the wrong place the next morning. Contractors often have no HRIS record at all, so the identity provider becomes the only source, and an agent without a reconciled record either blocks them or treats them as employees. Teams in several countries add a policy dimension: a works council rule here, a data residency constraint there, and the agent has to apply the one that covers this employee, not the global default.

Every one of these turns into an escalation, and escalations are where service desk cost lives. MetricNet's 2023 benchmarks put the average cost of a service desk contact handled by an analyst at $20.61 and a desktop support request at $114.96.

What is the difference between an agent that answers and one that acts?

An agent that answers works from knowledge. How do I expense a trip, what is the parental leave policy, which VPN client do we use. Retrieval over a decent knowledge base gets many teams this far, and the cost of an incomplete answer is a follow-up question.

An agent that acts changes a system. It adds someone to a group, provisions an app, locks a device, closes an account. Before it does, it needs all four questions answered: whether this person is entitled, what they already have, which approval rule applies, and whether the same request was handled before. Benchmarks that test agents on rule-bound tasks show how demanding that is. The 2024 τ-bench study found that even state-of-the-art tool-calling agents "succeed on <50% of the tasks" when they have to follow domain rules while talking to a user. Those numbers are for agents acting alone, with no record to check and nobody to approve. The answer is a different design, not a better model: give the agent the four answers and keep a human on the plan.

This is where context stops being a data quality topic and becomes the condition for resolution. An agent with the four answers can resolve. One without them can only suggest, and the request lands back in an admin's queue with the investigation still to do.

Inside Siit, Assist reads the request and the context around it, including similar past requests and how they were resolved, and proposes a resolution plan. Nothing runs until an admin approves the plan. The actions then go through Siit's connections to the identity provider, the MDM and the other systems, limited to the scopes approved when each was connected: groups, access, device actions.. Assist works with the Siit permissions of the person using it, so it proposes nothing that admin could not do, and runs nothing that admin has not approved. Reconciled data, a bounded scope and a human on the plan are what make an agent safe to trust with access and devices.

How does a service desk get smarter with every resolution?

The fourth question is the one most service desks cannot answer. Past requests exist, but as closed items, not as context. The exception granted in March, the reason it was granted, the approver who said yes: that lives in a chat thread and in someone's head. Foundation Capital calls this material decision traces: "the exceptions, overrides, precedents, and cross-system context that currently live in Slack threads, deal desk conversations, escalation calls, and people's heads."

For a service desk, memory does not need to be a theory. It needs to be a timeline. Siit keeps one on every person, app and device: role changes, access granted and removed, resets, and the requests themselves, each dated. When a request comes in, the agent reads that timeline and the similar requests before it. Was this app approved for this role last month? Did the same VPN symptom turn out to be a known issue? Is this the third password reset in three months, and should someone look at why?

Each resolution then becomes a reference for the next one, and the same memory works for the team as a whole: an admin can ask Assist to read the last six months of requests and propose the articles or processes that would remove them. The service desk gets smarter with every resolution, and what it learns belongs to the team, not to whoever handled the case.

Who decides what the agent can see and do?

A record rich enough to resolve a request is rich enough to cause harm if nothing bounds the agent. Four rules do most of the work, and they are the rules security teams already apply to people.

• Least privilege. The agent gets the minimum access its task needs, which is how NIST defines the principle for any entity. In Siit, Assist inherits the permissions of the person using it. It cannot see or do more.
• Field-level permissions. Roles decide who sees which field of the record. HR can be given compensation data imported from the HRIS while IT is not, on the same employee. The GDPR's data minimisation principle asks for exactly that: data "limited to what is necessary."
• Approval before action. The admin approves the plan before anything runs. For actions that could put an employee at a disadvantage, such as suspending an account, this is also what keeps the decision from being "based solely on automated processing" in the sense of GDPR Article 22.
• A log of everything. Every action is attributed to a person and recorded, including actions taken through Siit's MCP server, where "every action is scoped to your own Siit permissions" and auditable.

Two more points come up in most evaluations. Employees should know when they are talking to an AI agent; the EU AI Act's transparency rule has required it since 2 August 2026. And routine IT and HR requests are not among the Act's high-risk uses, a category reserved for recruitment, decisions on the terms or termination of employment, and performance monitoring, with obligations now due in December 2027. The legal detail, prompt injection and OWASP's guidance for AI agents are covered in a separate article.

Hosting, certifications and data handling are on Siit's security page.

Governance also gives the service desk its shape: which team handles which service, who approves what, which SLA applies. Context is shared across the company. Execution is local to each team.

How is unified context different from a CMDB, a knowledge base or RAG?

Each of these holds part of the answer and is often mistaken for the whole.
‍

A CMDB describes things; unified context describes a person in relation to things. A knowledge base tells the agent how; it does not tell it who. Retrieval finds text; acting needs state. And the Model Context Protocol is the transport: if the people, devices and apps behind it are not reconciled, an MCP server exposes the contradictions faster. Siit's MCP server lets any compatible client read and write across requests, people, the CMDB, the service catalog and the knowledge base, on the same unified context an admin sees in Slack or Teams. The full comparison, with enterprise search, data warehouses and identity governance, is in a companion article.

How do you get there?

Five steps, whether you build or buy.

1. Connect the systems of record. HRIS, identity provider, MDM, knowledge base, and the channel where requests arrive.
2. Reconcile them into one employee record. Name the system of truth for each field, so conflicts resolve the same way every time.
3. Scope the record by role, field by field. Let the agent inherit the permissions of the person using it.
4. Decide which actions need approval, and who gives it.
5. Keep the history readable. Past requests and resolutions as context, not as archive.

If you are evaluating a platform, put the four questions to it, then a fifth: is every action attributed to a person and logged? A platform built on unified context answers all five. One that queries each system when it needs to answers them one request at a time.

Siit's customers show the outcome. Mirakl went from 120 manual IT actions a month to zero. Unit runs IT for 200 employees with two people. Qonto deflected 28% of its IT requests.

Unified context is what makes an AI service desk worth trusting

The vocabulary will keep moving: context engines, context graphs, memory. The question underneath does not. Before an agent acts for an employee, does it know who they are, what they have, what applies and what was done before? And is that knowledge reconciled, scoped and governed?

The job of a service desk is still to resolve, and the forty minutes of checking is what disappears: the agent arrives with the four answers, and the admin spends the four minutes deciding. Unified context is what lets it resolve without asking the employee what the company already knows, without guessing at a rule that lives in someone's head, and without an admin re-checking what the systems already say. Siit is built on it: one context for every request, agents that qualify and resolve end to end with the permissions of the person using them, an admin's approval on the plan, and a service desk that gets smarter with every resolution.

Book a demo to see what unified context looks like for your own employees, or start a free trial.

Go deeper: What is ITSM context, What is contextual AI, Unified employee data, The employee context graph behind an AI service desk, and the Siit MCP server.