From All-Hands to AI - The Same Context Problem

The hard problem is not storing more knowledge. It is selecting, compressing, and activating the right context when a decision has to be made.

An LLM context window is not much like a company’s institutional memory. It is closer to the amount of institutional knowledge that can be brought into one decision in usable form.

That is the comparison worth keeping. Organizations have never lacked files, dashboards, meetings, or intelligent people. They struggle when the fact, exception, or prior decision that matters does not arrive in time.

I encountered this in a reporting system built from a heavily customized CRM environment. We were deciding how to validate a new replication process, and the obvious approach was to compare row counts and confirm that every current record had arrived. What was easy to miss was an older system behavior: some records that still appeared active could remain linked to parent records that had been deleted or retired upstream.

We discovered the dependency by tracing records that passed the basic load checks but failed later when they were joined into the reporting model. The problem was not that the organization lacked the knowledge. Someone familiar with the source system could explain the exception once we found it. The problem was that the exception had not been brought into the validation decision.

Three jobs, not one

Context work has three separate jobs.

• Selection: deciding which facts, constraints, and prior decisions matter now.
• Compression: reducing those facts into a form someone can use without reopening every raw record.
• Activation: getting that usable context to the person or system making the decision.

An organization can do any one of these well and still fail at the other two. It can preserve excellent records that nobody finds. It can collect everyone in a room and still drown the decision in noise. It can produce a fine summary that arrives after the work has already moved on.

Why we used to over-select

For a long time, teams bought context with attention. Long meetings, escalation chains, status reviews, war rooms, and hallway conversations all reduced the chance that one important fact would stay with the one person who knew it.

Y2K is a useful illustration. Organizations had to inventory systems, surface dependencies, test assumptions, and give exceptions a path to the people who could act on them. The work was expensive because the context problem was expensive. Nobody believed a larger archive alone would make the deadline safe.

Lean, Agile, and XP changed the tradeoff. Their best practices shortened feedback loops and moved useful information closer to the work. They did not solve the context problem once and for all. They made selection and correction less costly.

Presence does not guarantee access

The right people can be in a meeting and still miss the right context. Someone may remember the dependency but not recognize that it applies. The decision may live in a ticket, a chat thread, or a whiteboard photograph that no one thought to retrieve. A person can be present, attentive, and still lack the one fact that changes the call.

I have seen this happen in technical discussions where everyone needed to decide which data source should anchor a change. The people in the room understood the system, and several knew that a familiar downstream table had been created for reporting convenience rather than as the authoritative source. But that earlier design decision was not visible in the meeting, and the table’s name made it look more central than it was.

The distinction surfaced only after someone traced the data lineage back through the code and documentation. No one had been inattentive. The relevant knowledge simply had not been retrieved at the moment the decision was being made. A visible source-of-truth map, linked directly from the table documentation, would have changed the conversation before the team began designing around the wrong boundary.

That is why getting the right people in the room is necessary but incomplete. The work is making the right context visible, credible, and usable at the moment it matters.

What GenAI exposes

GenAI did not create this problem. It makes the gap harder to ignore.

An organization may have Teams messages, SharePoint folders, DevOps records, email, drafts, notes, and old procedures. Those are records of work. They are not automatically decision-ready context. Some are stale. Some contradict one another. Some preserve political language, half-finished ideas, or an exception without the reason it existed.

A model can retrieve material from that collection, but retrieval does not establish relevance, authority, or fitness for the present decision. The surrounding human system still has to decide what is current, what is trusted, what should be compressed into guidance, and what must remain available for deeper review.

This is an opportunity for system builders. The useful work is not simply adding another place to search. It is designing records, handoffs, interfaces, and review practices that help people and tools use what the organization already knows.

A better question

The next time a team says it needs more context, ask three questions:

• What should be selected for this decision?
• What can be compressed without losing the exception that matters?
• How will that context become active before the decision is made?

All-hands meetings were one answer. War rooms were another. Agile practices were another. GenAI can be part of the answer too. None of them help much unless they improve the selection, compression, and activation of context that actually matters.