An AI assistant connected to a company's document repositories can answer a question about how an approval works in about two seconds. The answer will be well structured, appropriately hedged, and drawn from the approval policy, the process document and last year's audit response.
It will also describe a process that has not run that way since the system migration. The documents are accurate about what was designed. The assistant has no access to what happens, so it answers about the design and presents it as the operation.
This is the central problem with enterprise context for AI assistants, and it does not get solved by connecting more sources of the same kind.
What the connected sources actually contain
Most enterprise assistants are connected to three or four categories of source, and the categories share a limitation.
Document repositories hold the designed process. Policies, procedures, training material and audit responses describe how work is supposed to happen, written by the people accountable for its design.
Transactional systems hold the record of events. A case opened on Tuesday, a field updated on Thursday, a status changed on Friday. Those records are reliable about what the system saw.
Communication archives hold discussion. Threads where a problem was raised, escalated and resolved, with most of the context assumed rather than stated.
Analytics and reporting hold aggregates. Volumes, cycle times, completion rates, all computed from the transactional layer and inheriting its boundaries.
Between them, those four categories cover what was designed and what the systems recorded. They leave out the layer in between: how the work is actually performed, including the steps that leave no system record, the reasons behind each step, and the exceptions that the normal path does not cover.
An assistant answering from the first four layers is confident and incomplete in a way that is difficult for the asker to detect, because the answer is well sourced and the gap is invisible.
Which layers of context does a model need?
Four layers, in ascending order of difficulty to obtain and descending order of availability.
| Layer | Contains | Typical availability | What an answer misses without it |
|---|---|---|---|
| Design | Policies, procedures, approved flows | High | Nothing, this layer is usually present |
| Event | System records, timestamps, status changes | High | What happened outside the system |
| Practice | The real sequence, including unrecorded steps | Low | The process as it runs today |
| Reasoning | Why each step exists, thresholds, exceptions | Very low | Whether a step can be changed or removed |
The bottom two layers determine whether an answer is actionable. A question like "can we remove this approval" cannot be answered from design and event data, because design states that the approval exists and event data states that it rarely rejects anything. The reason the approval exists, and what its reviewer catches outside the rejection count, lives in the practice and reasoning layers.
That is also why answer quality does not improve with more connectors. Adding a fifth document repository adds volume to the layer that was already complete.
Context layers
What each layer lets an assistant answer
| Layer | Question it can answer | Question it cannot |
|---|---|---|
| Design | What is the approved process? | Is this what we do? |
| Event | How long did this case take? | Why did it wait? |
| Practice | What actually happens, step by step? | Should this step exist? |
| Reasoning | Why is the process shaped this way? | What will the volume be next quarter? |
Design and Event are usually connected on day one. Practice and Reasoning are the two layers that determine whether an answer survives contact with the people who do the work.
Why this matters for deployment, not just for answer quality
The gap compounds when the assistant is doing more than answering questions.
An assistant asked to draft a process improvement proposal will draft it against the designed process. An agent given authority to act within a workflow will act on the sequence it was told about. A model asked to identify automation candidates will nominate steps that look redundant in the documentation, including the ones that quietly perform a second function nobody wrote down.
Risk frameworks put this in the category of context failure rather than model failure. The NIST AI Risk Management Framework places its Map function ahead of Measure and Manage precisely because a system evaluated against the wrong context produces a confident result about the wrong thing. The OWASP Top 10 for Large Language Model Applications addresses the adjacent risks directly, including excessive agency, where a system is given more authority than its understanding of the environment supports, and sensitive information disclosure, which becomes a live concern the moment operational detail becomes retrievable.
Both point at the same practical requirement. An assistant that will be trusted with operational questions needs the operational layer, and the operational layer needs governance that the document layer never required.
What it takes to make the practice layer available
Three requirements, and each one rules out a common shortcut.
It has to come from the people doing the work. The practice layer cannot be derived from the design layer, and it cannot be inferred from event data. Inference produces plausible reconstructions, and a plausible reconstruction consumed by a model becomes an authoritative answer.
It has to cover the roles, not a sample. A sampled description of a process is incomplete in a way that is invisible once it has been ingested. The assistant answers with equal confidence about the covered and uncovered parts.
It has to be current, and currency has to be visible. Organizations do not hold still. Teams build small internal tools and fix things without telling anyone, priorities shift, steps stop happening. A practice layer captured eighteen months ago and presented without a date is worse than no practice layer, because it is specific enough to be believed.
| Approach to the practice layer | Coverage | Currency | Carries reasoning |
|---|---|---|---|
| Process documentation project | Selected processes | Ages immediately | Partly |
| Event log inference | All recorded activity | Current | No |
| Screen and activity observation | Observed roles | Current | No |
| Sampled expert interviews | A sample | Point in time | Yes, for the sample |
| Continuous interviews at census scale | Every role in scope | Refreshed by cycle | Yes |
The third row is worth separating out. Observation captures what a person does on a screen, which is practice without reasoning. It can show that a step takes eleven minutes and cannot show that the operator does it because an upstream field is unreliable. For an assistant, the reasoning is the part that makes the answer usable.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform, and the practice and reasoning layers are the specific thing it produces.
Discovery Cycles run AI-led interviews with every person in a defined scope rather than a sample, adapted by role, asking what the work actually involves: the real sequence, where it waits, what the person fixed themselves, and why each step is shaped the way it is. That output is the practice and reasoning layer, collected from the people who hold it.
The Process Library holds it as navigable documentation that grows with each cycle, which is what makes currency a property of the system rather than a date on a document. The Context Graph connects processes, findings and the inputs behind them, so a retrieved answer carries its provenance. The Insights Dashboard ranks findings by impact and effort with traceability to the conversation that produced each one, and Workspaces provide separated areas with anonymization and spend limits, which is the governance the operational layer requires and the document layer did not.
Horizon is also available in the ChatGPT Plugin Directory, which puts this layer where the questions are already being asked. An operational question raised inside an assistant people use daily can be answered from a record of how the work actually runs, with the source of the answer attached.
At SURA, a cycle produced 63 insights across 600 employees with five systems integrated, in under seven days against a three-week baseline, and the engagement reported a 186% return on investment. The relevant property for this discussion is the integration count alongside the insight count: system connections supply the event layer, and the insights supply the layer the systems do not hold. Those figures describe one engagement and they are evidence rather than a guarantee.
The question worth putting to any vendor offering enterprise context: which of the four layers does your product supply, and if it supplies practice, where did the description come from and when?
Common mistakes
Adding connectors to fix answer quality. Another document repository adds volume to the layer that was already complete, and the answers stay confident about the designed process.
Treating event data as the operational layer. System records show elapsed time and state changes. The reason for a delay sits outside the system, which is frequently why the delay exists.
Publishing a practice layer without a date. Specific and stale is worse than absent, because an assistant presents it with the same confidence as anything else it retrieves.
Deriving practice from design with a model. The reconstruction is plausible, undetectable downstream, and becomes the authoritative answer for everyone who asks.
Giving an agent authority on a sampled map. Authority should not exceed coverage, and an agent cannot tell which part of its context was sampled.
Connecting the operational layer under document-layer governance. Detailed descriptions of how work runs, attributable to roles, need separation and anonymization controls that a policy repository never needed.
FAQ
What is enterprise context for AI assistants?
It is the set of company-specific information an assistant can retrieve when answering. It spans four layers: the designed process, the system record of events, how the work is actually performed, and the reasoning behind each step. Most deployments connect the first two and answer as though they had all four.
Why does an AI assistant describe a process incorrectly when it has the documents?
Because the documents are accurate about the design. If the process has changed through workarounds, system migrations or steps that quietly stopped happening, none of that is in the documentation. The assistant answers correctly from its sources and describes a process that no longer runs that way.
Can the practice layer be inferred from system logs?
Not reliably. Logs record what the systems saw, which excludes the steps performed outside them and never includes the reason for a step. Inference fills the gap with plausible reconstruction, and once that reconstruction is retrievable it is treated as authoritative by everyone who asks.
What changes when the operational layer is connected?
The class of answerable question changes. With design and event data, an assistant can state the approved process and how long a case took. With practice and reasoning, it can state what actually happens, why a step exists and what a change would affect, which is the kind of answer an operational decision needs.
What governance does the operational layer require?
More than the document layer. Descriptions of how work runs, attributable to roles and sometimes to individuals, are sensitive in a way that a policy document is not. Separated workspaces, anonymization and explicit scope limits are the baseline, and published guidance on sensitive information disclosure in model applications is the right reference point for the review.
The answer is only as good as the layer underneath it
An assistant connected to everything a company has written will answer questions about a process that was designed, and it will do so with the fluency that makes the gap hard to notice. Adding sources of the same kind improves nothing.
The layer that changes the answers describes how the work actually runs and why, and it only exists if somebody asked the people doing it. Until that layer is available and dated, an enterprise assistant is an articulate account of the documentation.
See it. Fix it. Stay ahead.