Estudo da Nielsen Norman Group mapeia como power users organizam o contexto que alimenta agentes de IA

Quem já automatizou alguma tarefa com um agente de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → sabe: o prompt é a parte fácil. O trabalho real está em decidir o que o agente precisa saber, onde guardar essa informação e quando atualizá-la. Um estudo publicado em 9 de outubro de 2026 pela Nielsen Norman Group, assinado por Tanner Kohler, foi a campo com usuários avançados do Claude de setores variados e encontrou um padrão incômodo: todo mundo monta esse sistema sozinho, do zero, e acha que o vizinho está fazendo melhor.

O achado central vale para quem constrói produtos com IA, não só para quem usa Claude no dia a dia: a qualidade de um agente depende menos do prompt e mais da biblioteca de contexto por trás dele. É a peça que separa um assistente que entende o projeto de um que inventa resposta a cada sessão nova.

O que é, de fato, uma biblioteca de contexto

Na definição da NN/g, uma biblioteca de contexto é o conjunto de conhecimento institucional e processual, em arquivos markdown ou em sistemas externos, que o agente pode consultar e também editar. Não é só pasta de .md: conexões via MCP ou API trazem bases do Notion, históricos de Slack ou transcrições de reuniões para dentro do mesmo ecossistema.

O estudo organiza esse conteúdo em três papéis, que valem tanto para um assistente pessoal quanto para um agente plugado num pipeline de produção:

• Global: informação estável, que molda o comportamento do agente em qualquer interação (padrões de código, políticas da equipe, tom de voz).
• Local: informação restrita a um projeto ou tarefa específica (as regras de um cliente, o escopo de uma sprint).
• Ambiente: fluxos brutos e não curados, como e-mails e transcrições, que o agente vasculha sem que ninguém tenha filtrado antes.

Misturar esses três papéis sem critério é a raiz de quase todo problema relatado pelos participantes.

Contexto não se mantém sozinho

A lição mais simples do estudo também é a mais negligenciada: arquivo de contexto escrito uma vez e nunca revisto vira passivo, não ativo. Um dos participantes tinha uma automação diária de resumo de tarefas que foi perdendo utilidade conforme seu jeito de trabalhar mudava. O Claude tinha acesso amplo a e-mail, mensagens e transcrições de reunião, mas as instruções da automação eram rígidas demais para captar a mudança sozinhas.

O comportamento mais comum não foi corrigir o contexto, foi simplesmente passar a ignorar as partes inúteis da automação, sem avisar o sistema disso. Isso é o equivalente, em termos de produto, a um usuário que para de clicar num botão quebrado em vez de reportar o bug: o problema fica invisível até alguém ir procurar.

Outro participante batizou a fragilidade das integrações externas de "decadência do sistema": sua conexão com o Todoist expirava com frequência, cortando o acesso do Claude à lista de tarefas até ele reconectar manualmente. Chegou a cogitar montar um agente só para manter as outras conexões vivas, o que praticamente anula o ganho de tempo que motivou adotar IA em primeiro lugar.

Deixar o agente editar o próprio contexto

Um achado que interessa direto a quem programa: quase ninguém no estudo editava os arquivos de contexto manualmente, mesmo com o markdown aberto na tela. Pedir para o Claude fazer a mudança era mais rápido do que navegar um arquivo que o próprio agente tinha escrito, e mantinha estilo e estrutura consistentes em toda a biblioteca.

Participantes também pediam alterações em massa: se um projeto ganhava uma restrição nova, eles pediam para o Claude propagar isso em todos os arquivos relacionados, sem saber exatamente quais arquivos existiam ou onde ficavam. E aqui está o ponto que merece ceticismo de engenharia: raramente conferiam o que o agente tinha mudado. O julgamento era pela qualidade da saída seguinte, não pela revisão do diff.

Esse padrão funciona para produtividade pessoal. Para contexto que alimenta um agente em produção, aplicando regras de negócio ou gerando código para clientes, é o tipo de prática que pediria, no mínimo, versionamento em git e revisão por pares antes de confiar. O próprio estudo registra que alguns participantes cogitaram GitHub para controlar versões da biblioteca, mas nenhum chegou a adotar.

Estrutura de pastas como mecanismo de controle, não só organização

A terceira lição é sobre capacidade de achar as coisas (findability, no vocabulário de arquitetura da informação) e ela tem uma consequência técnica direta: estrutura ruim não é só desconfortável, ela determina o que o agente carrega ou deixa de carregar na janela de contexto.

Um participante descobriu, durante a sessão de pesquisa, um arquivo de contexto global que governava boa parte do que o Claude podia ou não fazer, sem saber que ele existia: o próprio agente provavelmente tinha criado o arquivo sozinho, ou o participante simplesmente esqueceu. A prática recomendada pela própria documentação das AI labs, e adotada pelo participante com a biblioteca mais elaborada do estudo (mais de 2.700 arquivos de contexto), é colocar um arquivo de "índice" em cada pasta explicando o que ela contém e quando usar aquele conteúdo. No ecossistema do Claude, esse arquivo se chama CLAUDE.md.

O participante mais rigoroso tinha uma regra única para controlar o que o agente enxergava a partir de onde a sessão começava:

Precisa subir ou descer antes de poder se mover para os lados.

It must move up or down before it can move sideways.Participante do estudo da Nielsen Norman Group, citado por Tanner Kohler

Na prática: uma sessão aberta dentro de open-projects/ fica cega para o resto da biblioteca. Para alcançar algo em Teaching/, o agente precisa subir até Health/, depois até Workspace/, ler o CLAUDE.md do topo e só então descer até a pasta certa, sem jamais carregar o conteúdo das pastas pelas quais passou de raspão. É basicamente um sistema de escopo por diretório, parecido com namespace ou com regra de import em monorepo, só que aplicado à memória do agente em vez de ao código.

Quando o contexto vaza entre projetos

Modelos aceitam janelas de contexto de milhões de tokens hoje, mas o estudo é direto num ponto que vale a pena grifar: dar acesso a contexto tangencial não melhora a performance do agente, do mesmo jeito que inundar um colega de informação não melhora o trabalho dele. Isso é mais grave com contexto ambiente, porque o usuário costuma liberar acesso a muito mais do que o agente de fato precisa.

Dois exemplos do estudo mostram o custo prático disso:

• Um participante via o Claude confundir quem tinha feito qual tarefa, ele ou o sócio, porque as fontes ambiente (e-mails e ligações com clientes) não distinguiam claramente as duas pessoas.
• Outro viu as diretrizes visuais do seu podcast vazarem para dentro de um app de controle de leitura que ele construía em paralelo, porque o contexto estava marcado como global quando deveria ser local.

A recomendação da NN/g, e que vale como princípio de arquitetura para quem integra IA em produto real, é escopar localmente por padrão e só promover algo a contexto global quando houver motivo concreto para isso valer em qualquer sessão.

O que fica de lição prática

O estudo fecha com uma constatação que soa óbvia só depois de lida: as plataformas de IA ainda não ajudam o usuário a curar essas bibliotecas, então o trabalho cai inteiro sobre quem usa. Isso vale tanto para o profissional de UX organizando pesquisa quanto para o time de engenharia que estrutura contexto para um agente em pipeline de produção.

Algumas práticas do estudo se traduzem direto para quem trabalha com IA em código:

1. Trate arquivo de índice (CLAUDE.md ou equivalente) como parte da arquitetura, não como documentação opcional.
2. Audite contexto global e local periodicamente comparando com fontes ambiente recentes, em vez de deixar arquivo escrito uma vez valer para sempre.
3. Escope por padrão como local; só promova a global com justificativa.
4. Mantenha arquivos curtos. O estudo não achou um número mágico, mas a maioria dos participantes mantinha cada arquivo com poucas centenas de linhas.
5. Se o contexto alimenta algo que roda em produção, não trate edição automática pelo agente como suficiente: versionamento e revisão continuam sendo responsabilidade de quem constrói o sistema, não do agente.

Nenhuma dessas práticas é tecnologia nova. São, em essência, os mesmos princípios de arquitetura da informação e de gestão de configuração que já existiam antes da IA generativa, agora aplicados a um tipo de arquivo que o próprio agente ajuda a escrever.

Fonte: Nielsen Norman Group