Your system of record is not your AI agent's context

AI agents are cheap to build now. Context isn't, and the service desk you already run doesn't have it.

A year ago, an agent that could grant a new sales hire a CRM license was a project. Now it's an afternoon's work. Every service management vendor has one, and your own team could build one if it wanted to.

That changes the question. For twenty years the hard part was the automation: the workflow, the integrations, the rules, and the consultants who kept it all working after the org changed underneath it. That part is now cheap. What's expensive is what the agent knows at the moment it acts: who is asking, what they already have, who needs to approve, what changed since yesterday. Nobody disputes that AI needs context.

And every enterprise system of record has drawn the convenient conclusion: we hold the data, so the context is ours, and the agent should be too. The service desk you already run says this as loudly as any of them, so that's the one we want to look at. The claim is partly true. The true part is the less important part.

One person, three identities

Here is a case every service desk has handled, and almost none has handled completely. Emma arrives through a staffing agency. She gets an agency email, a guest account in Slack, a GitHub seat, a shared drive, a loaner laptop. Eight months in she converts to full-time, which means a new HR record, a corporate email, a new identity in Okta and a new laptop. Nobody retires the old accounts. Nothing was wrong with them.

A year later she resigns. HR terminates the record, the identity provider deprovisions the corporate account, a ticket reads "offboard Emma Carter," the analyst works the checklist, the ticket closes.

The agency email still holds the GitHub seat. The guest account is still in three channels. The loaner laptop never came back and is still enrolled. The service desk's copy of Emma is the one record the import produced, keyed on a corporate email that no longer exists, and nothing in it connects those leftovers to the person who just walked out.

Resolving that ticket properly takes three things the analyst never had. That the agency identity, the guest account and the corporate identity are one person. What that person currently holds, across systems that were never in the same catalog. And that "deprovisioned" means each system was checked, not that a ticket reached a closed state. None of it originates in the service desk. The service desk has the ticket, which is a request for those facts.

Does the service desk have the context an AI agent needs?

Not in a form an agent can act on. The service desk will say it does hold those facts: there's a user table, an asset list, a configuration management database, and Emma is in all of them. True. But look at how she got there. A scheduled import. A connector somebody configured two years ago. An administrator typing in a record. Every entry is a copy, as fresh as the last refresh and as complete as the key it was imported on, and that key was the corporate email.

This isn't an AI failure. An agent reading the service desk's copy of Emma would reason correctly over what it was given and still leave the GitHub seat open. The record showed a value. It did not show where the value came from or when anyone last checked, so nothing could tell a current fact from a stale one, or one of Emma's identities from another. Context is the fact plus its source, the time it was observed, and how it connects to the rest of what's known about that person. Take those away and what's left is data, which is what the service desk has.

To be fair about what it holds uniquely: ticket history, change records, the service catalog. That's a good account of past work, and it matters. It isn't an account of what's true about the organization right now, which is what an agent needs before it acts.

Why the claim gets made anyway

If the agent is cheap, it can't carry the price, so context has to. The pitch becomes: the platform is the context layer and the AI is a premium tier on top of it. The implementation project that populates the configuration database gets sold alongside, and again each time the organization changes shape; industry estimates put that work at one to three dollars for every dollar of license.

There's a deeper reason the claim doesn't hold, and it has to do with what these systems were built for. Most enterprise systems of record were designed when the goal was to make a company adhere to a process: log the request, classify it, route it to the right queue, collect the approvals, close it with the right code. A good system was one where nothing happened outside the process. Solving the problem quickly was the analyst's job. The system was there to make sure it was done in order.

There was nothing wrong with building that. But an agent is judged on whether the problem got solved. Ask a system built to enforce procedure for context, and it hands over the artifacts of procedure: tickets, categories, states. No AI tier changes what the thing underneath was built to do.

An agent bolted onto that platform inherits all of it: the same copies, the same import schedule, the same administrators keeping the record honest, and a scoring system that still counts steps. We'll say that once and move on, because the more useful question is what the alternative looks like.

What a context layer for AI agents looks like

The alternative isn't another system of record competing to hold the data. It's a model assembled from the systems that already hold it, kept current by them, and honest about where each fact came from.

This is what STLabs builds with Axiom™. Axiom™ connects to the sources directly: the HR system, the identity provider, device management, the applications themselves. It reconciles a person's identities across them into one, so the agency email, the Slack guest and the corporate account all resolve to Emma, with her devices, applications and access attached. Every fact carries its source, the time it was observed and a confidence. An analyst can open any decision and see what it rested on. When a role changes in HR, the change arrives through the integration and the next request uses it. No schema to design, no record to type in, no import to schedule.

The other half of context is the rules. In a bolted-on agent, approval logic lives inside each workflow, so a new rule means finding and editing every workflow it touches. STLabs applies a policy once, through Policies & Approvals, across the workflows it covers. Add a rule that contractor seats in GitHub expire at ninety days, and every request that rule applies to now waits for the required approval, and nobody opened the workflow that handles it.

With both in place the agent doesn't answer the request, or summarize it, or open a ticket for someone else. It takes the action within policy, verifies it, and records the request, the decision and the outcome together. The service desk sits around that, which is what AI-native service management means in practice.

How to test an AI agent's context on your own systems

A demo can't settle this, because every agent resolves the first request. The claim is about what happens after the organization moves, so that's what to test.

Run Emma's case, or your own version of it. Bring a contractor in, convert them, let the agent handle the offboarding, then go check each system yourself for what it left behind. Change the facts underneath: update a role in the HR system, see how long it takes to show up and whether the next request uses it. Open a fact and look for its source and the time it was observed. Then change a rule, the ninety-day one, say, and submit a request it should catch without touching the workflow. If the request routes around the new rule, you've learned where the rules really live.

The whole time, keep a second tally next to the completed requests: what an administrator had to update, repair or reconfigure to keep the agent right. That number belongs in the price of the platform. Vendors rarely volunteer it.

Add the AI agent alongside your service desk, then consolidate

None of this means ripping out the service desk on day one. STLabs runs alongside it with bidirectional sync, so routing, resolution and change records stay aligned while you evaluate. Onboarding takes days, not months or years. We connect the source systems, Axiom™ builds the model from them, the sync goes on, and approved requests go live in Slack and Teams. There's no implementation project because there's no database to populate and no catalog to configure by hand.

Then let the evidence decide. Once STLabs is fulfilling a workflow reliably, ask what still depends on the old tool. Keep the history you need and plan around the real dependencies. Where the old system is mostly keeping a second copy of work that now happens elsewhere, that copy is upkeep with no return.

The end state is simple enough. Your HR system and identity provider stay the systems of record, because that's what they are. Axiom™ is the context built from them. The agent acts within policy on top of that, and the service desk is where the work gets seen and handed off. The service desk never had to be the context layer. It only had to stop claiming to be.

Frequently asked

Does a CMDB give an AI agent the context it needs?

No. A CMDB is a copy of other systems, refreshed by import or by hand, with no record of where each value came from or when it was last checked. An agent reading it can't tell a current fact from a stale one.

What context does an AI agent need to resolve a request?

Who is asking, what they currently hold across every connected system, who has to approve, and what changed since the last request, with each fact carrying its source and the time it was observed.

Should you add an AI agent to your existing ITSM tool or replace it?

Start alongside it, with two-way sync. Judge the agent on what your team still has to maintain to keep it right, not on the first request it resolves. Consolidate whatever the old tool only duplicates.

What is Axiom™?

Axiom™ is STLabs' live model of your organization, built directly from HR, identity, device and application sources. Every fact carries its source, observation time and confidence. It is the context STLabs agents act on, within policy.