Nielsen Norman Group study maps how power users organize the context that feeds AI agents

Anyone who has ever automated a task with an AI agent knows: the prompt is the easy part. The real work is deciding what the agent needs to know, where to store that information, and when to update it. A study published on October 9, 2026 by the Nielsen Norman Group, authored by Tanner Kohler, went into the field with advanced Claude users across different industries and found an uncomfortable pattern: everyone builds this system alone, from scratch, and thinks their neighbor is doing it better.

The central finding applies to anyone building AI products, not just day-to-day Claude users: an agent's quality depends less on the prompt and more on the context library behind it. It's the piece that separates an assistant that understands the project from one that makes up an answer every new session.

What a context library actually is

In NN/g's definition, a context library is the set of institutional and process knowledge, in markdown files or external systems, that the agent can consult and also edit. It's not just a folder of .md files: connections via MCP or API bring Notion bases, Slack histories, or meeting transcripts into the same ecosystem.

The study organizes this content into three roles, which apply both to a personal assistant and to an agent plugged into a production pipeline:

• Global: stable information that shapes the agent's behavior in any interaction (code standards, team policies, tone of voice).
• Local: information restricted to a specific project or task (a client's rules, a sprint's scope).
• Environment: raw, uncurated streams, such as emails and transcripts, that the agent sifts through without anyone having filtered them beforehand.

Mixing these three roles without criteria is the root of almost every problem reported by participants.

Context doesn't maintain itself

The study's simplest lesson is also the most neglected: a context file written once and never revisited becomes a liability, not an asset. One participant had a daily task-summary automation that kept losing usefulness as their way of working changed. Claude had broad access to email, messages, and meeting transcripts, but the automation's instructions were too rigid to pick up on the change on their own.

The most common behavior wasn't fixing the context, it was simply starting to ignore the useless parts of the automation, without telling the system about it. In product terms, that's the equivalent of a user who stops clicking a broken button instead of reporting the bug: the problem stays invisible until someone goes looking for it.

Another participant called the fragility of external integrations "system decay": their Todoist connection expired frequently, cutting off Claude's access to the task list until they reconnected manually. They even considered building an agent whose only job was to keep the other connections alive, which practically cancels out the time savings that motivated adopting AI in the first place.

Letting the agent edit its own context

A finding of direct interest to anyone who codes: almost no one in the study edited context files manually, even with the markdown open on screen. Asking Claude to make the change was faster than navigating a file the agent itself had written, and it kept style and structure consistent across the whole library.

Participants also requested bulk changes: if a project gained a new constraint, they'd ask Claude to propagate it across all related files, without knowing exactly which files existed or where they lived. And here's the point that deserves engineering skepticism: they rarely checked what the agent had actually changed. Judgment was based on the quality of the next output, not on reviewing the diff.

This pattern works for personal productivity. For context feeding an agent in production, applying business rules or generating code for clients, it's the kind of practice that would call for, at minimum, git versioning and peer review before trusting it. The study itself notes that some participants considered GitHub to version-control the library, but none actually adopted it.

Folder structure as a control mechanism, not just organization

The third lesson is about the ability to find things (findability, in information architecture vocabulary), and it has a direct technical consequence: poor structure isn't just uncomfortable, it determines what the agent loads or fails to load into the context window.

One participant discovered, during the research session, a global context file that governed much of what Claude could or couldn't do, without knowing it existed: the agent itself had probably created the file on its own, or the participant simply forgot. The practice recommended by AI labs' own documentation, and adopted by the participant with the study's most elaborate library (more than 2,700 context files), is to place an "index" file in each folder explaining what it contains and when to use that content. In Claude's ecosystem, that file is called CLAUDE.md.

The most rigorous participant had a single rule to control what the agent could see from wherever the session started:

It must move up or down before it can move sideways.

Study participant from the Nielsen Norman Group, quoted by Tanner Kohler

In practice: a session opened inside open-projects/ is blind to the rest of the library. To reach something in Teaching/, the agent needs to go up to Health/, then to Workspace/, read the top-level CLAUDE.md, and only then go down into the right folder, never loading the content of the folders it passed through along the way. It's basically a directory-based scoping system, similar to a namespace or a monorepo import rule, just applied to the agent's memory instead of to code.

When context leaks between projects

Models accept context windows of millions of tokens today, but the study is direct on a point worth underlining: giving access to tangential context doesn't improve the agent's performance, the same way flooding a coworker with information doesn't improve their work. This is worse with environment context, because the user tends to grant access to far more than the agent actually needs.

Two examples from the study show the practical cost of this:

• One participant watched Claude mix up who had done which task, them or their business partner, because the environment sources (emails and client calls) didn't clearly distinguish between the two people.
• Another saw their podcast's visual guidelines leak into a reading-tracker app they were building in parallel, because the context was marked as global when it should have been local.

NN/g's recommendation, which stands as an architecture principle for anyone integrating AI into a real product, is to scope locally by default and only promote something to global context when there's a concrete reason for it to apply in any session.

The practical lesson

The study closes with an observation that only sounds obvious after you've read it: AI platforms still don't help users curate these libraries, so the entire burden falls on the user. This applies equally to the UX professional organizing research and to the engineering team structuring context for an agent in a production pipeline.

Some of the study's practices translate directly for those working with AI in code:

1. Treat the index file (CLAUDE.md or equivalent) as part of the architecture, not as optional documentation.
2. Audit global and local context periodically against recent environment sources, instead of letting a file written once stand forever.
3. Scope as local by default; only promote to global with a justification.
4. Keep files short. The study found no magic number, but most participants kept each file to a few hundred lines.
5. If the context feeds something running in production, don't treat automatic editing by the agent as sufficient: versioning and review remain the responsibility of whoever builds the system, not the agent.

None of these practices are new technology. They are, in essence, the same information architecture and configuration management principles that existed before generative AI, now applied to a type of file that the agent itself helps write.