Context Engineering for Enterprise AI Agents: Where Process Context Actually Comes From 

Context engineering is currently understood as a document problem: retrieval, memory, chunking, tool definitions. For enterprise process agents that framing fails, because the context an agent needs is not in any document. It is in what people actually do, and the unit of that context is the name given to each step of work. 

Most process discovery tools name steps after the application that was open. “Update Excel spreadsheet.” An agent handed that name knows nothing it can act on. Getting to a usable name requires five levels of abstraction, and most of the market stops at level two. 

This article sets out those five levels, explains why the gap between level two and level four is where automation business cases quietly die, and gives you eight questions to ask any vendor who claims their platform is agent-ready. 

AI’s blindspot in business process understanding

Two weeks ago I asked ChatGPT how the main process intelligence vendors decide what to call a process step. Not a marketing question. A technical one. How does a tool turn Excel > click cell > copy > Salesforce > paste > save into something a human being would recognise as a piece of work? 

The answer it gave me was confident, detailed and scored every vendor out of ten. It described semantic clustering, hierarchical abstraction, multimodal understanding. It read like a genuine technical comparison. 

Then I went and checked the sources. 

Almost none of it was there. One vendor’s entire claim to sophisticated activity naming turned out to be a single sentence in a single blog post. Another said nothing about naming at all. Its public vocabulary is metaphor: work is “excavated,” tasks are “cataloged.” The two largest platforms in the category document something less impressive still. One has analysts write the naming rules by hand, conditions like “application equals winword.” The other clusters screenshots but needs a human to identify the task first. 

So the model had not found an answer. It had assembled a plausible one out of whatever technical vocabulary happened to be lying around, and graded vendors on how much of it they had published. 

I found that funnier than I should have. But it points at something real, and it is the reason I wanted to write this down. 

Context engineering has an enterprise-shaped hole in it 

The term “context engineering” has had a good year. Search interest for context engineering is running at roughly 5,400 queries a month in the US, and almost all the content answering those queries is written for AI developers. It covers retrieval strategy, memory architecture, chunking, tool schemas, how much you can fit in a window before quality degrades. 

All of it assumes the context already exists somewhere and the job is fetching it well. 

For an agent that answers questions about your documentation, that assumption holds. For an agent that is supposed to do a piece of operational work, it collapses. The context that agent needs is not in a document. Your process documentation describes the process somebody designed in 2019. It does not describe the four workarounds your team in Manila invented because the system times out on Tuesdays. 

Most context engineering is document engineering wearing a newer name. That is fine for the problems it was built for. It is the wrong tool for operations. 

The context for a process agent has to be observed, because the only place it exists is in what people actually did. 

The unit of process context is a name 

Here is the part I think gets skipped. 

Once you observe work, you have an enormous pile of interaction data. Clicks, keystrokes, application switches, field entries. A single knowledge worker generates tens of thousands of these a day. None of them mean anything individually. 

To make that pile usable you have to group the events into steps and then call each step something. That name is the atomic unit of process context. Everything downstream depends on it: the process map, the variant analysis, the cost model, the automation business case and, eventually, the brief you hand an agent. 

Get the name wrong and everything built on top of it is wrong in the same way, only harder to see. 

And naming is hard in a way that clustering is not. Clustering is a maths problem. Naming is a semantics problem. It requires knowing what the work was for, which is information that is nowhere in the click stream. 

Five levels of process context 

I find it useful to think about naming as a ladder. Each rung requires strictly more context than the one below it. 

Read the right-hand column rather than the left. The levels are not degrees of polish. They are different products. 

A level two name tells you an application was open for eleven minutes. A level four name tells you what those eleven minutes were worth. You cannot build a business case on the first one, and no amount of asking a language model to rephrase it will get you to the second, because the missing information was never captured. 

That last point is worth sitting with. A lot of what is currently sold as AI-powered process naming is a language model rewriting a level two name into something that sounds like a level three name. The English improves. The information content does not change at all. 

Most of the market sits at level two, with the better tools reaching level three. I have not found public evidence of anyone consistently operating at four and five, including us, which is partly why I am writing this. 

The two places level two quietly fails 

The business case. Your CoE runs a discovery exercise. It comes back with 340 activities, ranked by time consumed. Near the top: “Update Excel spreadsheet,” 12,000 hours a year across the shared services centre. 

That number is real and completely unusable. Twelve thousand hours of what? Some of it is invoice reconciliation you could automate tomorrow. Some of it is scenario modelling that requires judgement you would be mad to automate. The activity name has averaged a high-value task and a low-value one into a single line item, and no one can tell them apart without going back and asking people, which is the interview-based approach you bought the tool to escape. 

The agent brief. Same problem, higher stakes. You hand an agent a process model where the steps are named after applications. It knows a field was populated. It does not know the field held a customer credit limit, that the limit belonged to a specific account, that the step followed a contract review, or that three of the last hundred instances hit an exception a human resolved by phoning the account manager. 

The agent is confident and wrong, which in operations is the expensive combination. Then everyone concludes the model was not good enough. The model was fine. The briefing was empty. 

There is a third failure that is subtler and, in my experience, more common than either: naming artefacts masquerading as process variants. If the same underlying activity is named inconsistently across teams, your process map fragments. You look at it and see forty variants of an invoice process across five countries. You launch a standardisation programme. Some of those variants are real and worth fixing. Some of them are one process being called four different things, and you have just committed budget to harmonising a naming inconsistency. 

I have watched that happen. It is not a hypothetical. 

What actually gets you to level four 

Three inputs, and the second one is the one people miss. 

The business object 

Every step of real work acts on something: an invoice, a claim, a customer account, a shipment. If the naming layer knows which object the step touched, the name stops describing the interface and starts describing the work. 

Inheritance across application boundaries 

This is the interesting problem. The business identifier is rarely visible on every screen. An operator sees the customer ID in the CRM, switches to a spreadsheet where no ID appears anywhere, does four minutes of work, then switches back. A naming layer that treats each step in isolation loses the thread at that boundary and the spreadsheet work becomes orphaned effort attributed to nothing. 

The fix is to carry the identifier forward from the preceding step, so the work object survives the application switch. It sounds small. It is the difference between a process model that holds together end to end and one that falls apart at every system boundary, which is exactly where the expensive manual work tends to live. 

Your vocabulary, not a generic one 

A claim is not called the same thing at a South African insurer and a German logistics business. If the naming layer does not use the organisation’s own terminology, every name needs translating before anyone trusts it. 

The bit nobody is solving: consistency 

Suppose you have all three inputs. You still have one problem left, and I think it is the real one. 

If names are generated per instance, the same underlying activity produces different names each time. “Validate customer credit limit.” “Check credit limit for customer.” “Customer credit check.” All three are accurate. All three are fluent. And they will sit in your process model as three separate activities, which means your cost figure for that activity is wrong by roughly two thirds and nobody will notice. 

Fluent English is not the same thing as a canonical name. 

What you want is a naming layer that resolves the same activity to the same name every time, everywhere, with a confidence score attached so you can see which names the system is unsure about and review those specifically. Semantic accuracy and canonical consistency, together. Not one or the other. 

I cannot find any vendor in this category claiming that, including in our own public material, and I think it is the most defensible thing anyone in process intelligence could build. 

Eight questions to take into your next process intelligence vendor demo 

Ask these in the demo, not in the RFP. RFP answers are written by marketing. Demo answers are given by engineers. 

1. Show me a step name your platform generated last week for a real customer, not a slide. Which level on the ladder is it? 

2. Where did that name come from: application metadata, a rule an analyst wrote, or something the system inferred? 

3. If it inferred it, what did it use? Show me the inputs. 

4. A user works in the CRM with a visible customer ID, switches to Excel where no ID appears, works for four minutes, switches back. What happens to those four minutes? 

5. The same activity happens in Manila and in Kraków. Do both instances get the identical name? Show me. 

6. Can I see a confidence score per name, and can I filter for the low-confidence ones? 

7. Can we override a name, and does the override propagate to every instance of that activity? 

8. Export the business context you would hand an AI agent for one process. Not the process map. The actual object. 

Question eight is the one that separates platforms quickly. Several will show you a process map instead, which is the answer. 

Where we sit, honestly 

KYP.ai captures desktop work as structured event data across Windows, macOS, Citrix, VDI and legacy environments, and we do it continuously rather than in recorded sessions. That gives us the raw material for levels four and five: sequential relationships between steps, business identifiers, and the surrounding process rather than a single isolated action. Our positioning has argued for years that agents need ground truth from observed human work rather than proxies like event logs or documentation, and this naming problem is the most concrete version of that argument I have found. 

But I want to be straight about something, because the alternative is writing a page of marketing. 

We have not published this. Not properly. The mechanism described above is closer to what our platform does than anything else I have read in the category, and until now a prospective customer had no way of knowing that from our website. That is our failure, not a competitor’s success. It is why this article exists. 

The customers who have pushed us hardest on naming quality are the ones running the largest estates. SPS found 874 hours a month in their CX operation across 8,500 employees in 20 countries. Allied Global built a 3.0x ROI case and recovered 10,000 to 15,000 hours annually, with payback inside five months. Neither of those numbers is possible on level two names, because at level two you cannot tell which hours are worth recovering. 

You can read more about how we approach automated process discovery and how it differs from traditional task mining, or start with our overview of what process intelligence actually is. 

What I would take away 

Context engineering for enterprise agents is not a retrieval problem. It is an observation problem followed by a naming problem, and the naming problem is where the value is created or lost. 

Five things worth holding onto: 

• The atomic unit of process context is the name of a step, and everything downstream inherits its quality 

• Levels one to three describe what happened at the interface. Levels four and five describe what the work was for. Only the second kind supports a business case or an agent brief 

• A language model rewriting a bad name into better English adds no information 

• Canonical consistency matters as much as semantic accuracy, and almost nobody talks about it 

• If a vendor cannot show you a real generated name and explain where it came from, assume level two 

If you are evaluating platforms for agentic AI readiness, take the eight questions with you. And if you want to see what level four and five names look like on your own processes, book a demo. We will run it on your work, not a sandbox.