Your team works well with artificial intelligence. It commissions analysis, asks for drafts, reviews what comes out and corrects what does not fit. And even so, one scene repeats itself: yesterday's session ended at an exact point —three things resolved, one discarded for a specific reason, one half-done— and today's starts blank.
The natural reaction is to try to stop it forgetting: keep the conversation going, drag everything inside it, never close. That is precisely the decision that makes the output worse, and it is worth seeing why before discussing any solution.
The long conversation is not free: the output degrades
A language model answers from everything it has in front of it at that moment: its standing instructions, the documents it has read and the whole conversation up to that point. That set is called the context. And what is measured —not assumed— is that the context is not used evenly, depending on how much of it there is and where each thing sits.
Three published results, worth having to hand when someone proposes “keeping it all in the same thread”:
- What sits in the middle gets lost. Performance is highest when the relevant information occurs at the beginning or the end of the input context, and degrades significantly when the model must access information located in the middle of long contexts (Source: Liu et al., “Lost in the Middle”, Transactions of the ACL, vol. 12, 2024). It is a U-curve: whatever was left halfway through a long conversation is the hardest thing to retrieve.
- The longer it gets, the worse it reasons. In an evaluation designed to demand inference —not the location of a literal phrase—, at 32,000 tokens (the unit in which the model counts text, roughly word fragments) 11 of the 13 models evaluated fall below half of their short-text baseline (Source: Modarressi et al., “NoLiMa”, ICML 2025).
- The degradation does not wait for hard tasks. Across 18 models: “models do not use their context uniformly; instead, their performance grows increasingly unreliable as input length grows”, and it happens even on simple tasks, in non-uniform ways (Source: Hong, Troynikov and Huber, “Context Rot”, Chroma, 2025).
What matters for a decision-maker is not the figure: it is the shape of the failure. The model does not return an error, nor warn that it has stopped taking something into account. It carries on answering in the same confident register, and the fact that was lost halfway through the conversation does not reappear with a caveat — it is simply not in the answer. A degraded result looks a great deal like a good one until someone checks it against the source.
Why it happens, in two sentences
This is not a flaw in one particular tool, nor something the next release fixes. There are two structural causes:
Attention is a budget. Every piece of the text can relate to every other one: for n pieces there are n² possible relationships, so doubling the text does not double the relationships to attend to, it quadruples them. The model's ability to capture those relationships “gets stretched thin” (Source: Anthropic, “Effective context engineering for AI agents”, 2025). And how it was trained: models learned from data in which shorter sequences are far more common than longer ones, and are left with less experience of dependencies that span a whole context ([Source: Anthropic, 2025, same URL]).
From which follows something worth knowing before spending money: buying a model with a larger context window widens the space available, not the attention budget shared out inside it. The limit that matters is not how much fits; it is how much is attended to well.
Managing that has a name: context engineering
If the quality of the answer depends on what the model has in front of it when it answers, then that composition stops being an accident and becomes a decision. That decision, taken deliberately and systematically, is what is called context engineering: the set of strategies for curating and maintaining the optimal set of information while the model works, including everything that lands there without you having written it — documents the system decided to read, connected tools, the full message history ([Source: Anthropic, 2025, same URL]). It is not the same as prompt engineering, which deals with how the question is phrased.
The guiding principle, in the words of those who build these systems, runs against years of being told that AI should be given “as much context as possible”: find the smallest possible set of high-signal tokens that maximise the likelihood of the desired outcome ([Source: Anthropic, 2025, same URL]).
Put in management terms: the quality of an answer is decided before the question. And that is exactly what a person properly trained on this tool learns. They do not write cleverer questions: they decide what the system has in front of it when they ask —which documents, which history, which rules— and keep that set small and clean. It is the difference between an advanced user and an occasional one, and it is not acquired by reading a manual: it is acquired by working alongside someone who already manages their context that way.
The written close: the piece that makes working short possible
This is where the opening scene returns. If the short, clean session is where the model performs best, one has to be able to close. And closing without losing the thread requires something to carry the state of the work from one session to the next. The conversation cannot: it is precisely what has to be let go. A file can.
The mechanism is short to describe. Before finishing, the session writes down three things: what was genuinely closed, what remains open and what the next one starts with. The following day's session begins by reading that, and only that — high-signal information, without the full history behind it.
What is difficult is not the file: it is knowing what deserves to go into it. Two decisions concentrate almost all of the value, and they are the ones no automatism takes:
- Reconcile what was closed against the rest of the list. What was resolved today in one place is usually requested in two more, in other words. If it is not cross-checked there and then, the list goes on demanding for weeks something that is already done — and a list that lies gets abandoned.
- Hunt the loose ends. The criterion agreed verbally, the new document nobody noted where people look, the material already consumed that tomorrow would be re-read as pending. It is the last hour in which that knowledge exists.
There are three more rules that stop the notebook degenerating into a diary, and they come with the system. But the part that cannot be automated is the one above: noticing what is missing. An absence, by definition, is not written down anywhere; only someone with the whole of the work in front of them sees it, and only while it is in front of them.
What the company gains, not just the person
So far the benefit looks individual: better answers for whoever does the work. The one that matters is a step beyond.
When the close is a practice and not a personal virtue, the state of the project leaves someone's head and enters a file the company keeps. Whoever picks the work up after a week away starts by reading instead of reconstructing; a handover or a period of leave stops being a hole; and the person joining does not depend on someone else having time to talk them through the project.
It also changes what remains when a supplier finishes. A system handed over without its history is a mute system: it works until something has to change, and then nobody knows why it was built that way. In our method the record of how it was built is part of what is delivered, for the same reason the department is built with the client's people and not in front of them: the construction is the training, and that record is what sustains it once we are no longer there.
Two pieces that look alike should not be confused, either. The rules the system obeys set the permanent criterion —what holds for every case, and is loaded in every session— and the close sets the state, which changes every day. Together they are what makes a business operable by AI: described in such a way that a system can read it and act on it without a person translating at every step.
Where this comes from
In our training, context engineering is not explained on a slide: it is practised. The person watches the context fill up as they work, learns to read when it is time to close, writes their own close on their real work and runs it before finishing the day.
And the system being installed is not a teaching exercise: it is the one that sustains our largest internal project, refined over months of daily use and then reduced to what a team needs. What is transferred is not the file —a file can be copied in a minute—: it is the judgement about what deserves to be written down, which is the part that took months to earn.
The tailwind: the regulation asks for the same artefact
For the systems European law considers high-risk, this stops being good practice. The regulation requires their providers to have a quality management system documented in writing that includes, among its thirteen aspects, “systems and procedures for record-keeping of all relevant documentation and information” (Source: Regulation (EU) 2024/1689, art. 17(1)(k), EUR-Lex, 2024).
If your system is not in that category, the obligation does not reach you. The artefact, however, is the same — and whoever already works this way does not have to build it on the day someone asks for it.
The question to take away
It is not which model you bought. It is what that model has in front of it when your people ask — and who decides that: someone, deliberately, or the inertia of a conversation that has been open for three weeks. The difference between those two situations is not visible in the answer, because both sound equally confident. It is visible when you check them.