Context Management for Business: The Right AI Context for Every Task

Consider an illustrative spare-parts scenario. A customer asks about a part for a machine delivered years ago. An AI tool writes the reply in half a minute. The salutation, tone and part number are correct, but the promised lead time comes from a price list the supplier replaced long ago. The only error concerns the detail the customer actually cares about.

Such errors rarely originate in the language model. They originate before it, in the question of which trustworthy information the AI saw for this one task at all. That question is context management, and it arises long before any tool is chosen.

What context management means in a company

Context management is the ongoing work of deciding which trustworthy information a person or AI system needs for a specific task: where it comes from, who may use it, how current it is and how the result can be traced back to its source. It does not mean loading every document into a chatbot. Context management starts with one concrete task and then identifies the sources that task needs.

Four signs suggest that the problem lies with context rather than the tool.

• Two experienced colleagues answer the same customer question differently, and each can point to a document.
• An answer holds up until somebody asks which list the figure came from.
• A recurring task depends on one person, because only that person knows which file currently applies.
• Corrections end up in an email or a chat history and never in the source the next answer comes from.

Knowledge management, AI context and context engineering

Four terms are often confused, including in German discussions of the subject. Knowledge management asks how a company captures, maintains and shares its knowledge. Context management asks which dependable information a specific task needs, where that information comes from, who may see it and how current it is. AI context is the package of facts, rules, examples and history available to an AI system for that task. Context engineering is the technical practice of selecting, structuring and delivering the package. This distinction is our reading of the field; we do not claim that the industry has agreed on one definition.

A worked example: answering a customer email

Return to the illustrative spare-part enquiry. A useful answer needs five pieces of information, each stored in a different place.

• The article and its successor, in the ERP.
• The price, from this customer's agreed terms.
• The lead time, from the supplier's current commitment.
• The rule for the amount above which someone counter-signs.
• Three earlier replies that carry the tone.

An experienced employee brings those details together and notices when something does not add up. An AI tool without the same access writes a fluent reply with the wrong date. The difference lies entirely in the context.

Our own work has produced a rule for this. An AI system may complete a draft, but it must not invent a value that someone will later have to stand behind. In XPO Inventory, the inventory solution for exhibition builder NEO Expo, a photo suggests the name, description, color, category and unit. Dimensions and quantity remain manual because those values are critical to the inventory workflow. The same rule applies to the spare-part reply: AI can supply the salutation and structure, while the price and delivery date must come from an authoritative source or be left out.

The six questions that define a context path

For every task AI is meant to take on, we settle six points. The questions use plain language so that an owner can answer them without software vocabulary and ask a provider the same questions in the next meeting.

1. Task: what exactly is to be decided or produced?
2. Source: where does every detail that changes the result come from?
3. Responsibility: who may correct it, and which source wins in a conflict?
4. Permission: who or what may read it, and for what purpose?
5. Freshness: how quickly does it become wrong, and how does anyone notice?
6. Evidence: how will you know in everyday use that the context improved the result?

The spare-part reply rarely fails on the first question. The problem usually appears at the third: the ERP and the supplier's commitment contradict each other, and no one has decided which figure applies.

When one of these questions remains open, the cause is almost always unclear responsibility.

What order alone already achieves

We can now put a number on the value of that groundwork. In May 2026, a UCLA group used LongMemEval-V2 to measure how well different setups recovered information from weeks of activity. Current frontier models with no access to that history scored 14.1 %. A purpose-built memory system that analyses every observation as it is recorded and sorts it into three knowledge stores scored 58.6 %. A standard tool allowed to search the same histories as plainly organized files reached 69.9 %. The best variant reached 74.9 % by adding written working instructions, a table of contents and a few helper scripts to that standard tool.

The written instructions were the most effective single component. Removing that plain document reduced accuracy in the large test from 70.1 % to 64.1 %.

This leads to the second rule we follow. Anything an AI system needs to know about the company belongs in a version-tracked file that people and machines can both read. Rules kept only in a tool's settings create a quiet form of vendor dependency: no one can easily check what applies or see when it changed. Once the workflow and its rules are written down, people and AI systems work from the same information.

These figures come from two artificial test environments in English, without permissions, conflicting sources or data-protection constraints. They show how well a system finds the right passage in existing material. They do not show whether that material is correct or who should be allowed to see it. Moreover, 74.9 % still means that one answer in four is wrong. A well-built AI context therefore helps someone who is able to review the result; it does not replace that person.

What such a file looks like, and when it gets read

What, then, belongs in such a file? For the spare-part reply, we would use one short document per topic: delivery times, price tiers and parts for discontinued product lines. Each document would fit on one screen. They would all follow the same structure so that people and AI systems can find the relevant detail quickly.

• What applies today. One paragraph that answers the question without requiring anyone to read further.
• The details below, including exceptions and the product lines governed by a different rule.
• What remains open. Questions no one has decided yet, marked as open rather than omitted.
• Who is responsible. A name, not a department.
• What changed and when. Give the date and reason in two lines.

The third point is less familiar. A document that names its open questions is more useful to an AI system than one that silently leaves a gap. Faced with the silent version, the system may fill that gap with something plausible, just as it did with the delivery time in the opening example.

That settles only half of the problem, however. You must also decide which files the AI system may see for a given task, since providing everything at once makes its answers worse. We use three tiers. A few short files accompany every task, such as the tone guide and the commitments that always require approval. Task-specific files come next; for this example, those cover the part and the affected product line. Everything else remains in place and is retrieved only when the task requires it.

This separation also makes the fourth question practical. Anyone serving several clients must never expose two clients' files in the same run. The filing system must enforce that boundary because a tool setting may change during an update without anyone noticing.

Whether the same structure still works across several thousand documents remains an open question. It works at the scale of our clients.

When technology joins in

Tooling becomes worth discussing only after the task, sources and responsibilities are clear. We follow the steps below in order and stop as soon as the task works reliably.

1. Remove obsolete and duplicate material and name an authoritative source.
2. Improve search, filing and permissions in the existing system.
3. Connect the task to live data through an export or an interface.
4. Add search across approved documents.
5. Assemble the context for the task automatically and let the AI draft, checked by a person.
6. Permit bounded actions once reading is reliable and logged.

The first two steps require no new software project. They may already be enough to make the task reliable. When several programs, company-specific rules or sensitive data come together, the later steps become useful. We draw the same boundary in using AI in your business.

Where to start

We start with one task that currently depends on an experienced person. You do not need a requirements document; one real case and your own account of the work are enough. In a 90-minute working session, we replay three to ten real cases, including a normal case, an exception and one that went wrong. The normal case alone never reveals where context breaks down. The result is a context map for the task, a decision on authoritative sources and ownership, and a recommendation for the smallest useful intervention.

If AI currently fails on one of your tasks because it lacks context, bring us a real example. Book an intro call.