A blogged response to ServiceNow
I dialed into the ServiceNow Global Industry Analyst Summit last Tuesday morning. I'm not going to lie…with a packed schedule of briefings and conferences (it’s that time of year), along with a major deadline looming, I was prepared to multitask.
But my ears are currently tuned in to the word "context," having recently run a survey and published a research report, three (now four) blogs, and five Impact Briefs, along with four sandbox tests, and counting, for research in the works.
Early in the sessions, the CEO of a global technology services company explained what happens when his agents get something wrong. The company runs 1,500 of them, and when things failed, the problem wasn't missing data. "We have the right data, but the data is not good enough. The data needs to translate into context."
I sat up in my chair. Then, with speaker after speaker using the word, I couldn't help but continue to pay attention (and the price in lost sleep to make that deadline).
That afternoon, I sent Jack Smithey a note about my reaction (referencing a meme that’s funnier in the email). Jack wrote back with an ask that set me writing…my definition of “context.”
Problem one: I can't compete with Merriam-Webster, let alone the very smart people at ServiceNow.
Problem two: one of my blogs was literally titled Skip the Definitions.
Problem three: each speaker who brought up context framed it differently.
For that technology services CEO, context was specific to tasks. For Nadir Israel, it was security knowledge. For Amit Zavery, it was the current state of the enterprise. For Jeff Hausman, it was the CMDB and service graph.
As often happens, each of them described “context” accurately, but from where they sit.
No surprise…the data and analytics session came closest to where I ended up. Gaurav Rewari said agents "still need to know what that data means and how the business actually operates." His guest, a VP of Platform Innovation at a global financial services company, took it further (and she barely used the word). The hard part isn't volume, she said; it's meaning. To support a lending decision, an AI has to understand the evidence alongside the applicant's affordability data and the lending policy, then show where that evidence came from and how it used it. A catalog tells you where to go get the information. A knowledge graph gives you a map of how it all connects. And governance tells the agent what it can do with it. The agent needs all three.
Relationships, provenance, permissions…all in service of a correct decision.
“Meaning” is the most widely cited result of context being correctly applied (it's in Merriam-Webster's first definition). But meaning in enterprise data can be undefined or inconsistent.
So I took Jack's question as an exercise. To be specific, this is Herb's definition of what "context" means in enterprise IT.
Context is the information needed to generate the correct outcome from data, made explicit.
Why not meaning? Semantics is meaning. Is semantics context? It's part of it, or it can be the whole thing, depending on the problem.
And what are we really trying to get at? The correct outcome. It applies to humans. It applies to machines. And it can come from a data catalog, metadata, a semantic model, an ontology, a knowledge graph, or the arguably incomplete “context” category itself.
The "made explicit" part is the foundational work we glossed over for decades. In Skip the Definitions, I wrote that if the important relationships and rules exist only in people's heads, dashboard logic, or application code, an agent can't reliably use them. Making them explicit is the difference between knowing something and being able to hand it to a machine.
Because context is a concept, it’s totally valid for each speaker to frame it differently. Each was looking at enterprise data from their own position, and each position requires its own context.
The problem is when people try to define context as a single architecture. You have to when you're selling a product, and everyone draws the biggest box around the thing they build. That's fine. But since there are a wide variety of ways to generate the correct outcome, there are a wide variety of ways to provide context…which brings me back to the original point: start with the problem you're trying to solve.
From there, enterprises will end up with combinations of semantic layers, ontologies, knowledge graphs, and pure "context" layers. The harder the problem and the more complex the data, the more context you need. And no single piece gets primacy. In EMA's September 2026 Data and Analytics Research, organizations that combine context-assembly methods report frequent context failures at 11%, compared with 31% for those relying on a single method.
You can't define context as a single architecture any more than you can draw one org chart for every organization. It works the way organizational intelligence works: discrete pieces held by individual people (and now agents), plus an overall framework that ties them together. It exists in many places at once. It has to.
None of this is new. It's what we've always required of a good employee, made explicit so a machine can read it.
Your humble data analyst has been filling in the undocumented gaps for years. As I wrote in September, AI didn't create the problem; it removed the human who had been compensating for it.
Which brings me back to the "correct" outcome. Correct according to whom?
Two departments can look at the same data and legitimately reach different answers. Someone has to decide which one wins and where it applies. That’s an organizational challenge as much as a technical one, and it will create new job titles.
Context engineer, context governance, context analyst. Whatever we call them, they'll be human.
And the job's not going to get smaller. Making analysis easier increases the amount of analysis we have to govern. For every layer we turn over to the machines, a new layer emerges. The arbitration and certification never go away.
That technology services company already works this way: humans validate what its agents produce, and a manager governs each group of agents.
It probably won’t make Merriam-Webster, but it holds up in enterprise IT…with one caveat: As long as an enterprise is serving humans, context will always need a human to decide what’s correct.