The word copilot has done a lot of work in the last three years. It was the right word in 2023, when most people interacting with a language model were sitting in front of a single screen, asking it to draft, summarize, or explain something. The mental model was the airline cockpit. The human is flying. The AI is in the right-hand seat, available, helpful, but not in command.
As most of us in the AI space realize, the mental model is now changing, and the language is changing with it. The word everyone is reaching for is agent. Sometimes coworker. The implication, in either case, is that the system is no longer assisting with a task. It performs the task end-to-end while the human moves on to other tasks.
This is a much bigger leap than the language makes it sound. And the difference between a successful agent deployment and a failed one is rarely about which model is under the hood. It’s about whether the agent has been given what it needs to do the job. Most enterprises, when they sit down to make this list honestly, find they can supply maybe two of the seven things on it.
Let me walk through what those seven things are.
The seven contexts
An agent doing real enterprise work (not a demo, not a single-screen task, but actual end-to-end execution of something a human used to do) needs seven distinct kinds of context. They are not interchangeable. A model can be world-class at reasoning and still produce nonsense if any one of them is missing.
The seven are: process context, system context, policy context, variant context, exception context, memory context, and outcome context. I’ll take each in turn, but the underlying point is this: a copilot can succeed with one or two of these. An agent needs all seven.
1. Process context
The agent has to know what it’s trying to do, where in the work that goal sits, and what comes before and after. This sounds obvious. It’s rarely supplied.
A copilot summarizing a document doesn’t need process context. The document is the world. An agent processing a claim needs to know that this claim is at the adjudication step, not the intake or settlement step; that the previous step was completed by a specific person at a specific time; and that the next step depends on the output of this one. The shape of the work matters. Where you are in it matters more.
Process maps in most enterprises are not built for this. They are built for human comprehension: a one-page Visio diagram that makes the workflow legible to a director who is making a budget decision. The map an agent needs is a different artifact: machine-readable, version-controlled, current as of yesterday, and structured around the question of what is the next valid action from here.
2. System context
The agent has to know how to act in the systems where the work happens. Any given workflow usually touches three to seven applications, none of which were designed with agents in mind. A claims agent might need to read from a policy administration system, write to a claims management system, query a fraud detection system, update a document management system, and send a notification through a customer communication platform. Five systems. Three vendors. Two were last upgraded in 2017.
The system context an agent needs includes: what these systems are, how to authenticate to each, which fields matter, which fields are validated downstream, what counts as a successful write, and what to do when one of them is slow or down. APIs cover some of this. UI automation covers the rest. The gap between the two is where most agent deployments stall.
3. Policy context
This is the layer where regulatory and business rules live, and the layer most likely to be wrong in the documentation.
Every regulated process operates under a stack of policies: federal and state regulations, line-of-business and product-specific policies, exception policies, and the unwritten norms that the operations team has accumulated over years of audits. The written policy is usually a PDF in SharePoint, last updated eighteen months ago. The applied policy is whatever the team actually does, which has drifted in small ways every quarter since the PDF was approved.
An agent that follows the written policy will, in many cases, be technically correct and operationally wrong. The compliance officer will sign off. The customer experience will degrade. The exception queue will grow. The team will quietly start routing cases around the agent.
What an agent actually needs is a policy graph: a representation of the rules as they are currently applied, with the source of each rule, the cases where it applies, the cases where it has been waived, and the chain of authority for changing it. Almost no enterprise has this. Most have a PDF and an institutional memory.
4. Variant context
A process that looks like one process on the map is, in practice, dozens of variants. The “auto claim intake” process is not one process. It’s a high-frequency happy path, a medium-frequency variant for total losses, a low-frequency variant for multi-vehicle incidents, a regulatory variant for certain states, a seasonal variant during catastrophe events, and a long tail of one-offs that occur a few times a year and look nothing like any of the others.
The agent has to know the variants exist. It has to know which variant it’s in. It has to know what differentiates that variant from the ones nearby. And it has to know, for each variant, what its scope of authority is: which ones it should handle, which ones it should hand off, which ones it should refuse.
This is the context most often missing, because variants aren’t visible in the documented process. They’re visible only in the observed one. You can interview a senior claims handler for an hour and not learn about the multi-vehicle variant, because she handles it so reflexively that it doesn’t occur to her to mention it. You can find it in five minutes by looking at a month of work.
5. Exception context
Variants are the cases you’ve seen before. Exceptions are the cases you haven’t.
Every operations team handles exceptions. The handling is almost always informal. Someone notices something unusual, escalates it to a more senior person, who makes a judgment call, often without consulting anyone. The judgment becomes precedent. The precedent becomes practice. The practice never makes it into the formal process documentation, because it isn’t a process — it’s a one-off that happened to become a pattern.
An agent needs to know what counts as an exception (which is itself a learned signal, not a static rule), what to do when it encounters one, and crucially, how to fail gracefully: how to hand off to a human in a way that preserves the work done so far and gives the human enough context to act.
The failure mode here is severe. An agent without an exception context will either escalate everything (in which case it is not really doing the work, just routing it) or escalate nothing (in which case it will eventually make a decision on a case it should not have touched, and the consequences will be expensive). Tuning between these two failure modes is the hardest part of agent deployment, and it depends entirely on the quality of the exception context.
6. Memory context
The agent has to remember.
This sounds simple and isn’t. Memory in an agent is not one thing. There is short-term memory within a single workflow execution: the variables it has gathered, the decisions it has made, and the partial outputs it carries forward. There is medium-term memory across executions of the same workflow: what tends to happen when a customer matches this profile, what worked last time on a similar case. There is long-term memory across the enterprise: what the policy used to be, what changed, why it changed, and who decided.
Different memory types live in different substrates. Short-term lives in the runtime. Medium-term lives in a vector store or a case database. Long-term lives in the policy graph and the process record. An agent that confuses these (that treats short-term assertions as long-term truth, or that fails to retrieve a relevant precedent because it was filed under a different label) will make characteristic mistakes that look like reasoning failures but are actually memory failures.
7. Outcome context
Finally, the agent has to know what counts as success.
This is harder than it sounds, because success in most enterprise processes is multi-objective. A claim adjudication is successful if it is fast, correct, compliant, and satisfies the customer. A loan decision is successful if it is profitable, low-risk, fair, and explainable. A customer service interaction is successful if the issue is resolved, the customer is satisfied, the interaction is brief, and no compliance line is crossed.
These objectives trade off. The trade-offs are usually unwritten. A senior claims handler knows, without being told, that the carrier will tolerate a slightly longer cycle time on a sensitive case to get the customer experience right. She has watched her manager make that trade-off a hundred times. The agent has watched no one. Unless someone tells it how to weigh speed, accuracy, customer experience, and compliance (and does so in a way that adapts to context), it will optimize whichever objective is easiest to measure, which is usually the wrong one.
Why do most enterprises supply two of seven
If you sit with the seven and audit your own organization honestly, the pattern that usually emerges is this:
You have system context, more or less. The APIs are documented. Someone in IT can tell you which systems matter for a given process. The integration is painful but possible.
You have policy context as PDFs. Compliant in form, drifted in practice, not machine-readable, not current.
You have a process map, which is not the same as process context. The map describes intent. The agent needs behavior.
You do not have a variant context in any usable form. You have a sense, from the operations team, that there are “lots of variants,” and you trust them to handle them.
You do not have an exception context at all. Exceptions are tribal knowledge.
You have memory context only inside individual systems. There is no enterprise-wide memory of how cases like this one have been handled before.
You have outcome context as KPIs, which are downstream of the decisions the agent needs to make. The KPIs tell you what happened. They do not tell the agent what to do next.
So the working count is: one (system), a partial (policy), and a process map that is not quite what the agent needs. Call it two out of seven. The other five are the gap: variants, exceptions, memory, outcomes, and a faithful process record.
This is what I mean when I say the leap from copilots to coworkers is not about model capability. The model can reason. The agent will fail anyway because five of the seven things it needs to do the work are missing.
What it looks like to close the gap
The honest version of an agentic AI program (the version that will produce results in two years rather than five) starts by closing this gap before deploying anything.
That means observing the work. Not surveying it, not interviewing about it, and observing it continuously across all the systems and all the variants, at a resolution fine enough to preserve the tacit moves. The observation produces a process record. The record is the substrate from which the seven contexts can be built.
From the record, you can derive variant maps with frequencies. You can derive exception patterns by observing what humans do when the work breaks down. You can derive the applied policy by comparing what people did against what the written policy says. You can derive memory by indexing prior work. You can derive outcomes by linking the work to the downstream KPIs that the business actually cares about.
This is not a single tool. It is an architecture. The architecture has, at its center, a faithful representation of work, what some of us have started calling a living system of record for process execution. The phrase is awkward. The idea is simple: a continuously updated record of how work is actually being performed across the enterprise, against which agents can be designed, deployed, and governed.
The enterprises that build this layer will deploy agents that work. The enterprises that don’t will deploy agents that demo well and fail in production, and they will spend the next three years blaming the models.
The models are not the problem. The substrate is.What it looks like to close the gap
Coworkers, not copilots
The word coworker is doing something useful in this conversation. It signals that what we are deploying is not a tool. It is something closer to a colleague: a system that takes on a defined scope of work, operates within a defined set of authorities, and is accountable for outcomes.
Coworkers, in the human sense, are not made by hiring smart people and pointing them at a job. They are made by onboarding: the process by which a smart person is given the context they need actually to do the work in this organization. Onboarding includes the process, systems, policies (written and applied), variants, exceptions, institutional memory, and unwritten standards for what counts as good work.
We have not been onboarding our agents. We have been hiring them off the shelf, handing them a process map and a policy PDF, and being surprised when they underperform.
The organizations that figure out how to onboard their agents (how to give them the seven contexts at the resolution they need) are the ones that will have a workforce that includes humans and machines in a genuine partnership. The rest will have very expensive copilots.
That’s the leap. It isn’t from a smaller model to a bigger one. It’s from a system that needs a human to operate it to a system that’s been given enough context to operate on its own. The model layer is ready. The context layer is the work.