Context Libraries: How AI Power Users Manage Context Engineering - NN/G

Introducing NN/G Membership | Access all self-paced courses for $249 per year | Join by Jan. 26, 2027 |
Find the training option that fits your learning style.
October 9, 2026 2026-10-09
AI agents have made curating context as important as writing prompts. The agent can do the typing, but deciding what context to keep, where to put it, and when to update it is left entirely to the user — and even the experts are struggling. This is true for UX professionals as much as for the Claude power users from various industries in our recent study. Our participants spent more effort engineering context libraries than crafting prompts (most of which they casually dictated). Yet each had improvised a bespoke process, files went stale or missing, and many suspected that someone else was surely doing it better.
A context library is a collection of institutional and procedural knowledge, contained within markdown files or external software, that AI agents may reference and edit.
A context library does not live solely within markdown files, though this was certainly the prevailing file type used to store context by our participants. MCP and API connections expand the library to include external sources such as Notion databases, Slack histories, or Granola transcripts. Some context in the library is actively updated and maintained; some is merely referenced. The context within the library generally plays one of three roles (which we discuss in greater detail in another article):
AI agents are designed to work with context libraries, but the AI systems themselves do little to help users learn how to curate and manage them. Users in our study had learned how to use context mainly from X and Reddit posts and from their own experimentation.
Figuring out how to build a context library should not require extensive reading of Anthropic’s developer-oriented support pages.
Our study highlighted several helpful lessons for ensuring that a context library delivers value over time. These lessons come from issues encountered by our study participants, all of whom were expert users working with Claude daily and who had built extensive context libraries. Users in nontechnical domains or with lower AI literacy will likely encounter the same problems, amplified: they will have fewer workarounds and less ability to notice when the library is failing them.
Build context that guides AI to achieve your goals, while making your context infrastructure future-proof in this live online course.
A context file was often written once but used for months, and much of what participants had written no longer matched how they worked. Some had created pieces of context for their library but never returned to them to ensure they still added value; others kept running scheduled routines they had gradually stopped trusting, or that depended on brittle connections to external sources that kept failing.
Context libraries must evolve to remain useful, but unlike humans, they can’t adapt on their own. A colleague senses when instructions have gone stale — say, when everyone else has quit using an old template — and moves on. AI isn’t yet sensitive to these signals. More ambient context, such as MCP connections to recent meeting transcripts in Granola, might seem to fill the gap, but it didn’t for our participants.
For example, one participant’s daily automation for summarizing tasks became less useful as his working style slowly evolved. Yet, even though Claude had sweeping access to his email, messages, and meeting transcripts, the automation’s instructions were too insulated to adapt. The participant had started ignoring the useless parts of the automation without providing any explicit feedback to the system.
To keep your library up to date:
Much of the context our study participants relied on was retrieved from external databases such as Notion or HubSpot via MCP or API connections. Maintaining these connections frustrated several participants; one called it “system decay.” His Todoist connection kept expiring, cutting Claude off from his to-do list until he reconnected it by hand. He had even considered building a separate agent just to keep connections alive. While this issue might seem a minor inconvenience, it undercuts the main reason these users adopted agents in the first place: to save time.
Almost nobody in our study typed directly into their context files. Even with the markdown file open in front of them, they would usually ask Claude to make the change. This wasn’t laziness. Asking Claude was faster than navigating a file it had written in the first place and working out exactly what to say — and it kept style and structure consistent across the library. It allowed participants to specify their intent and let the AI handle execution. Some updates were requested manually; others were triggered automatically by workflows or other context files.
Participants also commonly asked Claude to make sweeping changes across many library files at once. For example, if a project picked up a new constraint, they might ask Claude to work it into every file related to that project. They didn’t always know exactly which files needed changes or where they lived, and they rarely checked what Claude had changed. Instead, they trusted it to understand their intent and judged its work by the quality of the subsequent outputs. If the output was consistently poor, they simply asked Claude to make another round of updates wherever needed.
Because participants let Claude create and maintain most of their files, the library’s structure seemed to happen to them rather than exist as something they designed. Yet where files live and how folders are organized determines whether both the user and the agent can find the right context and what the agent loads.
Many of our study participants struggled to find context in their own libraries during our sessions. They would tell us how important a particular manifesto or boundaries document was, then come up empty