A million-token context window does not solve your context problem.
The decision you need may be trapped in another model, buried in a teammate’s session, or missing from the summary you kept. Even when the information is available, a larger window can’t tell you which source to trust. The billing system tells you whether a customer is paying. The call transcript tells you why they almost left. And if the original work was never saved, no context window can bring it back.
The context window is only the last mile. Many things have to happen before information gets there.
We’ve started calling the practice of solving that problem contextmaxxing.
Contextmaxxing is deliberately accumulating, retrieving, and reusing the context you have already created so every person and agent can start from the current state instead of reconstructing it from zero.
The name is intentionally a little ridiculous. Here's why it actually makes sense.
The wrong thing to maximize
The obvious interpretation of contextmaxxing is stuffing as much information as possible into a model. Bigger prompt, bigger window, more tokens, better answer.
In practice, dumping more information into a context window often makes the answer worse. An agent gets five versions of the same plan and cannot tell which one won. A six-month-old diagnosis looks as current as yesterday’s fix. A speculative idea - or an agent’s suggestion - gets mistaken for the final decision. The relevant paragraph is technically present, but buried under 200,000 tokens of things that do not matter.
Instead of maximizing context volume, you should maximize context continuity: preserve the work that matters and make the right parts available when they become useful again.
So start here: What is the most valuable record of how your work actually happens?
Choose the record that matters
There is no universal answer.
For a sales team, the CRM may contain the current state of an account, while call transcripts and emails contain the reason the relationship changed.
For an engineering team, the codebase contains what is true now. Issues and pull requests contain some history. Agent traces may contain the failed approaches, commands, corrections, and architectural reasoning that explain how the code got there.
For a researcher, the published paper is the output, but notebooks, experiment runs, and research conversations may contain the path that makes the result reproducible.
For an individual, the valuable record might be spread across AI conversations, voice notes, documents, and messages. The answer depends on where they actually think and work.
This distinction matters because different sources answer different kinds of questions. If I want to know whether a customer is paying, I should check the billing system. If I want to know why they almost churned, the answer might live in a call transcript. If I want to know what we already tried to fix the problem, it may be in an agent session.
These sources are not interchangeable. One records current state. Another records reasoning. Another records execution. A useful context system has to preserve those differences rather than flattening everything into one undifferentiated pile of text.
The first step in contextmaxxing is therefore not connecting every source you can find. It is identifying the sources that carry the highest-fidelity record of your work.
In an AI-native company, the trace becomes primary
At Nessie, a disproportionate amount of our valuable work happens inside AI sessions. We discuss product strategy with Claude. We investigate user behavior in Codex. We build and debug through coding agents. We move between models depending on the task.
The resulting trace is not just a chat log. It contains the question, the attempted paths, the evidence pulled in, the tools used, the corrections we made, and the output that eventually survived. It often contains more of the real work than the document or code change produced at the end.
This reverses the traditional relationship between an artifact and its history.
Most companies keep the final document and discard the conversations that shaped it. They keep the merged code and lose the wrong turns, the failed commands, and the reason one architecture won over another. The artifact is treated as the source of truth; the process that produced it is treated as exhaust.
For AI-native work, the trace is increasingly the primary record of the process. The final artifact is a useful, compressed view of it.
That does not mean every trace is important, or that a trace should override an authoritative system. A brainstorming conversation does not tell you what the team ultimately decided. An old coding session does not override the current codebase. The point is narrower: when work happens through AI, the trace preserves something companies used to lose: the path behind the result.
Without the trace, a future agent can see what survived but not why. It has to make the same mistakes, ask the same questions, and rediscover the same constraints.
Three ways context systems go wrong
1. They preserve information without asking what it is for
The easiest information to save is not always the information you will need later. A final document captures the conclusion but may omit the reasoning. A conversation preserves the reasoning but may no longer reflect what the team ultimately decided. A database tells you what is true now, but rarely explains why it changed.
There is no universally correct source. The right one depends on the question you are trying to answer.
2. They compress before the future question is known
Summaries are useful. They are also decisions about what to throw away.
The problem is that the summarizer does not know which future question will make an omitted detail important. A project summary may preserve the final architecture and discard the rejected option. Three months later, a new constraint appears and the rejected option is exactly what the team needs to revisit. A meeting summary records the decision but omits the objection that explains why implementation later stalled.
Compiled knowledge should exist, but the full-fidelity source should remain underneath it. Distillation is a view, not a replacement.
Otherwise every layer of summarization compounds the judgment of the previous layer. Eventually the system gives a clean, confident answer whose evidence disappeared several compressions ago.
3. They confuse retrieval with dumping
Once companies have gathered the data, the temptation is to put all of it into the model. Long context windows make this look increasingly reasonable.
But retrieval is an act of judgment. The agent needs the few sources that answer the present question, not every source that contains the same words. It needs to know which record is current, which is historical, which is speculation, and which system is authoritative for the claim being made.
A larger context window gives you more room. It does not decide what deserves to occupy that room.
The contextmaxxing loop
The practice is a loop:
Choose → preserve → make legible → retrieve → continue → compound
Choose
Identify where the important work and current truth actually live. Do not assume the answer is the same for every person, function, or company.
Preserve
Keep the full-fidelity record available. Store the original trace, transcript, document, or event before turning it into a cleaner artifact. You can always compress a source later. You cannot recover what was discarded.
Make legible
Organize each source so an agent can understand what kind of evidence it is and when it should matter.
Concretely, an agent should not treat a billing record, a sales call, and a brainstorming session as three equally authoritative passages about a customer. The billing record answers what is true now. The call explains why the customer feels a certain way. The brainstorm contains possibilities, not facts.
The same applies to engineering. The current codebase says what exists. A recent agent trace may explain why it was built that way. An old design document may be useful history without being the current plan.
Making context legible does not require turning your company into a perfectly tagged database. It means preserving enough shape around the source that an agent can judge how to use it instead of merely matching words.
Retrieve
Bring in the smallest set of sources that can answer the current question well. Prefer current and authoritative records for current-state claims; use traces and conversations for reasoning, history, and continuity. Keep the path back to the source.
Continue
The next agent, model, teammate, or future version of you should be able to pick up the work without a manual briefing. A conversation started in Claude should be continuable in Codex. A teammate should be able to inspect the reasoning behind a decision instead of receiving only its conclusion.
Compound
Once work can be continued, it can improve. Repeated failures become visible. Good workflows become reusable. Corrections survive the session in which they were made. A company can learn from its own record instead of paying to regenerate the same understanding over and over.
The context window is the execution surface
The industry spends a lot of time debating context-window size because it is easy to measure. But the window is temporary. It belongs to one model, during one run, for one task.
Your context system is everything that decides what survives beyond that run:
- which sources are worth preserving
- which source answers which kind of question
- how a future agent finds the relevant evidence
- how work moves across tools and people
- how the result becomes input to the next attempt
At Nessie, we started with AI conversations and agent traces because that is where our own work increasingly lives. We built a way to preserve those traces across tools and make them available to whichever person or agent needs them next.
Another company may start somewhere else. The important data might live in customer calls, experiment logs, a codebase, or an operational database. Contextmaxxing is not the claim that everyone needs the same sources. It is the discipline of knowing which sources matter to you and making sure their value does not end when the original interaction does.
A larger context window lets an agent see more for a moment.
Contextmaxxing makes your work usable again.
-Anna