Context engineering: dê aos agentes de IA o contexto certo

Se um agente funciona na demonstração, mas perde o rumo no trabalho real, examine o que chega ao modelo antes de acrescentar mais instruções. A engenharia de contexto, ou context engineering, coloca sob seu controle 5 entradas em cada etapa: instruções, ferramentas, fatos recuperados, memória e histórico. O objetivo é fornecer evidências suficientes para a próxima ação correta, carregando menos material irrelevante.

O que é context engineering, a engenharia de contexto?

Engenharia de contexto é o trabalho de decidir o que um modelo vê ao tomar sua próxima decisão. Isso inclui a instrução que você escreveu, as ferramentas que ele pode escolher, as evidências que essas ferramentas retornam, as memórias carregadas e a conversa que você mantém.

A janela de contexto de um modelo é seu espaço de trabalho para uma requisição. Um token é uma unidade de texto ou de outro conteúdo processada pelo modelo. Um documento salvo em algum lugar do sistema é informação disponível; seu conteúdo só passa a fazer parte do contexto ativo quando a aplicação ou o agente o carrega.

Essa diferença explica uma falha comum em produção. O agente pode ter acesso à política correta e, ainda assim, responder com base em uma conversa antiga, porque a política atual nunca chegou ao modelo no momento da decisão. Da mesma forma, carregar todas as políticas pode introduzir exceções sem relação com a tarefa e versões obsoletas.

Em seu artigo de engenharia de 29 de setembro de 2025, a Anthropic descreve esse trabalho como “selecionar e manter o conjunto ideal de tokens (informações) durante a inferência de um LLM.” A distinção é entre escrever instruções e gerenciar o conjunto mais amplo de informações fornecido durante a execução. Artigo da Anthropic sobre engenharia de contexto.

O artigo da LangChain de 2 de julho de 2025 fala em “preencher a janela de contexto com as informações certas a cada etapa da trajetória de um agente.” Ele organiza o trabalho em escrever, selecionar, comprimir e isolar: salvar o estado útil, buscar material relevante, encurtar o que fica e separar investigações independentes. Artigo da LangChain sobre engenharia de contexto.

Na prática, muda a unidade que você projeta. Um prompt isolado pode permanecer fixo. Já a próxima requisição de um agente muda sempre que ele lê um arquivo, recebe o resultado de uma ferramenta, conclui uma subtarefa ou descobre que uma suposição anterior estava errada. É preciso definir como montar essa requisição ao longo de toda a tarefa.

Documentação verificada em 13 de outubro de 2026: o comportamento das ferramentas descrito abaixo foi conferido na documentação atual da Anthropic e da OpenAI. O exemplo prático ilustra um projeto; não é um benchmark de produção.

Engenharia de contexto e engenharia de prompt: qual é a diferença?

A engenharia de prompt melhora a instrução; a engenharia de contexto melhora toda a requisição ao redor dela. Você continua precisando das duas.

Para um agente de programação, a engenharia de prompt pode trocar “corrija o cadastro” por “descubra por que as novas tentativas de cadastro enviam e-mails de boas-vindas duplicados; proponha uma correção mínima e um teste de regressão”. A engenharia de contexto decide, então, quais arquivos de cadastro, logs de novas tentativas, regras do projeto e descobertas anteriores o agente recebe antes de propor a correção.

Uma instrução muito bem escrita não compensa o carregamento de logs do ambiente errado. Um trecho de log cuidadosamente selecionado não compensa uma instrução que deixa em aberto se o agente deve diagnosticar, editar ou fazer o deploy.

A habilidade central da engenharia de contexto: definir limites

Para cada informação, decida quando ela deve entrar no contexto e quando pode sair. Regras permanentes do projeto, estado temporário da tarefa e evidências brutas precisam de tempos de permanência diferentes.

Uma convenção de código pertence às instruções persistentes. “O ramo de nova tentativa ainda não foi testado” pertence ao registro de continuidade da tarefa atual. A resposta completa de um provedor deve ficar em um arquivo de evidências acessível, com os campos relevantes carregados quando influenciarem a decisão.

É por isso também que a geração aumentada por recuperação, ou RAG, é apenas parte do trabalho. O RAG recupera material de apoio para o modelo. Ainda é preciso escolher as instruções, as ferramentas, o histórico mantido e o conteúdo retornado por essa recuperação.

Engenharia de contexto para agentes de IA: as principais práticas

Comece pela maior fonte de contexto irrelevante na etapa que falhou. Não introduza todos os mecanismos de uma vez. Um agente de depuração sobrecarregado de logs precisa de uma primeira correção diferente da de um assistente que vive esquecendo as restrições do projeto.

Compacte o histórico em torno das decisões, não apenas dos assuntos

O Claude Code, agente de programação da Anthropic, oferece /context para inspecionar o uso do contexto e /compact para encurtar uma conversa. Seu gerenciamento automático limpa resultados antigos de ferramentas e depois resume a conversa, se necessário. A documentação avisa explicitamente que instruções detalhadas de trechos anteriores da conversa podem se perder. Gerenciamento de contexto do Claude Code.

Dê um objetivo à compactação. Na investigação dos e-mails de boas-vindas, use /compact Preserve the current goal, change boundaries, relevant file paths, observed evidence, failed hypotheses, and the next unresolved question. Esse é um comando com orientações específicas para a tarefa, não uma garantia de que todos os detalhes serão preservados.

Antes de continuar, confira se o resumo ainda diferencia o que foi observado, inferido e não verificado. “Novas tentativas de envio de e-mail investigadas” é apenas um rótulo de assunto. “A aceitação pelo provedor está confirmada; o fluxo de confirmação local ainda precisa ser inspecionado” registra um estado que permite agir.

A compactação perde informação. Mantenha as evidências originais acessíveis e as regras permanentes nas instruções do projeto, para que uma etapa posterior consiga recuperar o detalhe de que precisa.

Recupere as evidências no momento em que forem necessárias

Busque a fonte que responde à próxima pergunta e só amplie a busca se o resultado não bastar. O artigo de engenharia da Anthropic descreve essa prática como manter referências leves e usar ferramentas para carregar informações quando necessário. Contexto sob demanda.

No Claude Code, as ferramentas de leitura de arquivos e de shell dão suporte a esse fluxo. Peça que ele localize o handler de novas tentativas, leia esse handler e o código que o chama, e inspecione a sequência de erros correspondente. Quando a ferramenta específica Grep está habilitada, ela pode retornar caminhos de arquivos, trechos correspondentes ou contagens, em vez de arquivos inteiros. Referência de ferramentas do Claude Code.

No seu próprio agente, retorne uma referência à fonte, um trecho relevante e metadados suficientes para estabelecer o escopo: ambiente, identificação do registro, versão ou data de vigência. Uma chamada posterior de ferramenta pode abrir o material ao redor.

A recuperação pode deixar passar evidências relevantes. Defina uma regra para ampliar a busca. Se uma busca restrita não encontrar nada, mude o escopo ou a consulta antes de concluir que o fato não existe. Se o trecho não permitir determinar se uma exceção se aplica, carregue a seção ao redor.

Enxugue os resultados das ferramentas antes de incluí-los na conversa

Retorne o resultado necessário para a próxima decisão, com uma forma de recuperar os detalhes omitidos. Para ferramentas com respostas extensas, a Anthropic recomenda filtragem, paginação, seleção de intervalos e truncamento, acompanhados de orientações úteis quando os resultados forem encurtados. Orientações da Anthropic para projetar ferramentas.

O Claude Code aplica uma versão concreta desse padrão à saída extensa de comandos de shell bem-sucedidos: acima do limite de conteúdo incluído diretamente, ele fornece o caminho de um arquivo salvo e uma prévia, permitindo que o agente pesquise ou leia o arquivo quando necessário. O tratamento documentado para comandos que falham é diferente; portanto, não presuma que todo erro truncado inclui um caminho de arquivo recuperável. Tratamento da saída do shell.

Para o agente que investiga o cadastro, um resultado útil de log contém o evento correspondente, a operação anterior, o erro e a localização da fonte. Requisições bem-sucedidas repetidas podem ficar no arquivo de log. Preserve exatamente o código de erro e a identificação do evento; uma descrição como “algo excedeu o tempo limite” pode apagar a pista que define a correção.

Truncar sem critério pode remover a exceção decisiva. Deixe a omissão visível e forneça uma consulta complementar ou uma referência ao arquivo. Corte o ruído repetido antes de cortar evidências contraditórias.

Use subagentes sem fork para investigar com um contexto limpo

Os subagentes do Claude Code podem realizar uma investigação delimitada em uma janela de contexto separada e devolver um resultado. Um subagente sem fork começa do zero, com sua definição e a tarefa recebida; um fork da conversa herda o histórico do agente principal. Ambos separam o trabalho subsequente, mas só o primeiro oferece um contexto inicial limpo. Subagentes e forks.

Delegue algo como: “Inspecione o fluxo de novas tentativas de envio de e-mail. Não edite arquivos. Retorne os caminhos relevantes, as evidências de entrega duplicada, as explicações alternativas e a próxima verificação.” Inclua as restrições de que o subagente precisa, em vez de pressupor que ele conhece a conversa principal.

Mantenha o retorno enxuto o suficiente para ser útil: descobertas, referências às evidências e incertezas. Um subagente que devolve todo o seu histórico de leitura apenas transfere o excesso de volta para a conversa principal.

Os subagentes fazem suas próprias requisições e também geram consumo. Eles podem repetir trabalho quando a descrição da tarefa omite uma decisão já estabelecida pelo agente principal. Use-os quando a investigação puder ser separada e seus resultados intermediários puderem ser descartados. Mantenha junto o raciocínio cujas partes dependem fortemente umas das outras. Os detalhes de configuração estão no guia de subagentes do Claude Code.

Dê aos arquivos de memória uma função restrita e estável

CLAUDE.md é um arquivo de instruções do projeto, não um lugar para colar toda conversa concluída. O Claude Code também tem memória automática para anotações aprendidas. Sua documentação distingue ambos de configurações impostas pelo sistema: escrever uma proibição em um arquivo de memória não torna uma ação tecnicamente impossível. Memória do Claude Code.

Em uma equipe pequena de produto, mantenha no arquivo permanente as regras específicas do repositório, os comandos reais de build e teste, os limites das alterações e as referências para documentação mais aprofundada. Guarde o estado temporário da investigação em uma nota separada da tarefa. Veja a estrutura do arquivo em memória da equipe com CLAUDE.md.

Há uma limitação sutil: importar um documento longo em CLAUDE.md também carrega seu conteúdo. Mover texto para arquivos importados pode melhorar a organização sem reduzir o contexto ativo. Para instruções necessárias apenas em parte de um repositório, considere as regras com escopo por caminho descritas na documentação. Para fluxos reutilizáveis, as skills do Claude Code normalmente mostram primeiro suas descrições e carregam as instruções completas quando são invocadas. Importações de memória e regras com escopo definido, carregamento de skills.

Arquivos persistentes podem preservar suposições obsoletas com a mesma eficiência com que preservam conhecimento útil. Remova incidentes resolvidos e comandos substituídos. Registre uma fonte ou revisão para fatos que mudam. Para entender melhor a diferença entre sessão, contexto de trabalho e armazenamento durável, leia o guia sobre memória de agentes.

Como aplicar essas práticas no Claude Agent SDK e no Codex

Esses mecanismos estão disponíveis nas ferramentas citadas; a escolha das evidências e dos limites da tarefa continua sendo responsabilidade da aplicação. O gerenciamento automático de contexto não consegue decidir qual informação do negócio seu fluxo esqueceu de buscar.

Claude Agent SDK: leve o ciclo do agente para sua aplicação

O Claude Agent SDK oferece, para aplicações Python e TypeScript, as ferramentas, o ciclo de execução do agente e o gerenciamento de contexto usados pelo Claude Code. Use-o ao incorporar um agente a um produto ou a uma automação que você opera. Visão geral do Agent SDK.

O SDK compacta automaticamente o histórico mais antigo quando a janela se aproxima do limite e emite um evento de sistema compact_boundary. Registre esse evento junto dos resultados das tarefas para identificar falhas que aparecem depois do resumo. Os subagentes sem fork do SDK mantêm o trabalho intermediário em suas próprias conversas e retornam a mensagem final. Ciclo de execução do agente no SDK, subagentes do SDK.

Defina explicitamente o carregamento das instruções do projeto. As opções padrão atuais de query() habilitam as fontes do usuário e do projeto. Se você informar settingSources em TypeScript ou setting_sources em Python, inclua project quando precisar do CLAUDE.md do projeto; um array vazio impede seu carregamento. Quem controla isso são as fontes de configuração, não a escolha da predefinição de prompt de sistema claude_code. Carregamento de instruções no SDK.

Mesmo um ciclo de execução competente precisa de uma política de recuperação específica para seu domínio. Um agente de suporte ainda precisa que você defina quem é o cliente atual, qual política se aplica e quais evidências são necessárias antes de agir.

Codex: separe as instruções do repositório da conversa em andamento

O Codex, da OpenAI, lê as instruções de AGENTS.md antes de trabalhar. Ele combina orientações globais com arquivos do projeto, percorrendo o caminho da raiz do repositório até o diretório de trabalho; as orientações encontradas depois prevalecem, e AGENTS.override.md tem prioridade no diretório em que está. Instruções de projeto do Codex.

Use essa hierarquia para manter as regras gerais de build na raiz e as regras especializadas perto do trabalho correspondente. O Codex CLI também oferece /compact para resumir a conversa visível e /init para criar uma estrutura inicial de arquivo de instruções. Revise essa estrutura à luz do seu repositório antes de tratá-la como referência oficial. Comandos do Codex.

Um arquivo de instruções do repositório não registra automaticamente a tarefa em andamento. Salve separadamente o objetivo atual, as descobertas confirmadas, as pendências e a localização das evidências. Após um reinício ou uma compactação, a próxima requisição deve disponibilizar esse estado da tarefa sem repetir toda a investigação.

Exemplo de engenharia de contexto: como enxugar o contexto de um agente

Reduza o material ao redor da decisão, preservando aquilo de que ela depende. Imagine um agente de programação encarregado de investigar e-mails de boas-vindas duplicados após novas tentativas de cadastro. Os nomes de arquivos e as evidências abaixo ilustram o projeto; não são resultados de um sistema em produção.

Seu pacote inicial sobrecarregado contém todo o manual de engenharia, grandes extrações do repositório, logs de serviços sem relação com o problema, todas as conversas anteriores de depuração e ferramentas para atividades administrativas alheias à tarefa. O trabalho real é mais restrito: encontrar o fluxo de envio duplicado, propor a menor alteração e identificar um teste de regressão. Alterações de esquema estão fora do escopo.

1. 1

   Mantenha a tarefa ativa e as restrições permanentes

   Substitua os pedidos conflitantes do histórico pelo objetivo atual e pelos critérios de aceitação. Mantenha visível a restrição sobre o esquema. Disponibilize as ferramentas do repositório necessárias para esse trabalho e deixe de fora desta execução as definições de ferramentas administrativas sem relação com a tarefa. Mova as convenções estáveis do repositório para o arquivo de instruções de projeto adequado; deixe as observações temporárias na nota da tarefa. Não coloque o manual inteiro em uma importação carregada automaticamente.

2. 2

   Troque os arquivos completos por um mapa de evidências

   Mantenha referências a signup-handler.ts, welcome-job.ts, ao teste de novas tentativas e ao arquivo de log relevante. Esses nomes são ilustrativos. Leia o handler e o worker quando eles responderem à próxima pergunta e inspecione suas dependências quando necessário. O mapa torna as evidências acessíveis; não substitui sua leitura.

3. 3

   Filtre o resultado da ferramenta em torno da falha

   Solicite o evento de cadastro afetado e sua sequência de novas tentativas. Suponha que o registro hipotético mostre a aceitação pelo provedor, seguida da ausência de uma confirmação local e de outra tentativa colocada na fila. Mantenha essa sequência, a identificação do evento e a localização da fonte. Deixe as requisições bem-sucedidas sem relação com o problema no log original. Preserve a incerteza sobre se a segunda tentativa realmente resultou em uma entrega.

4. 4

   Isole uma busca com escopo delimitado

   Dê a um subagente sem fork a tarefa de encontrar onde está implementada a prevenção de envios duplicados. Forneça o escopo da tarefa e os caminhos relevantes. Peça localizações e evidências, incluindo uma declaração explícita caso a busca tenha ficado incompleta. Devolva a descoberta ao agente principal e mantenha as leituras exploratórias do subagente fora da conversa principal.

5. 5

   Compacte a investigação em um registro que permita continuar

   Mantenha o objetivo atual, as evidências conhecidas, as explicações descartadas, a questão em aberto e a próxima ação. Preserve a diferença entre uma nova tentativa na fila e uma entrega duplicada confirmada. Arquive a conversa original para que o agente consiga recuperar um detalhe em vez de adivinhar.

6. 6

   Monte a próxima requisição com o que restou

   Carregue a tarefa, as regras permanentes, o trecho relevante do handler, a sequência filtrada de eventos e a descoberta do subagente. A próxima ação é inspecionar os fluxos de confirmação e de prevenção de duplicidade e propor o teste de regressão. Carregue mais evidências se essa ação exigir; não volte a anexar todo o arquivo por hábito.

A nota resultante da tarefa poderia ser assim:

Objetivo: Explicar os e-mails de boas-vindas duplicados após novas tentativas de cadastro e propor uma correção mínima com um teste de regressão.
Restrição: Manter alterações de esquema fora do escopo.
Evidências: A sequência de logs selecionada mostra aceitação pelo provedor, ausência de uma confirmação local e outra tentativa colocada na fila. Preservar a referência do evento e a localização do log original.
Questão em aberto: Se a nova tentativa colocada na fila resultou em uma entrega e onde se aplica a prevenção de envios duplicados.
Próxima verificação: Inspecionar os fluxos de confirmação e de prevenção de duplicidade no handler e no worker referenciados.

Essa nota hipotética deixa a incerteza visível. Ao elaborar o diagnóstico, o modelo recebe junto dela o trecho que sustenta as evidências.

O resultado é um conjunto menor de conteúdo, sem afirmar uma redução de tokens. A contagem exata de tokens depende da requisição real e do tokenizador. A redução de gastos e a melhora nas taxas de conclusão exigem medição; este exemplo estabelece o que remover e o que preservar.

Modelo de nota para dar continuidade ao trabalho

Use uma nota de tarefa com estes campos, preenchidos com evidências reais da execução:

• Objetivo e condição de conclusão: o pedido atual e o que caracteriza sua conclusão.
• Restrições: limites que a próxima etapa deve respeitar.
• Fatos estabelecidos: cada descoberta acompanhada da localização da fonte e da revisão ou do escopo relevante.
• Incertezas: o que ainda é inferência, está em contradição ou não foi inspecionado.
• Próxima ação: a próxima verificação e onde recuperar as evidências necessárias.

Atualize a nota quando uma descoberta mudar. Acrescentar cada nova ideia sem revisar a anterior recria o problema original em um arquivo menor.

Tamanho do contexto e custo: cada um exige uma medição

Otimize o custo de um resultado aceito, não o tamanho de uma única requisição. Uma conversa principal menor pode vir acompanhada de mais chamadas de subagentes, buscas de informações ou tentativas malsucedidas.

Dois limites documentados para instruções mostram por que as unidades importam. No Codex, o limite padrão combinado dos documentos de projeto é de 32 KiB, ou 32 × 1,024 = 32,768 bytes. Esse é um limite em bytes, não um orçamento de tokens. O Claude Code recomenda manter cada CLAUDE.md abaixo de 200 linhas; trata-se de uma orientação de escrita, não de um limite rígido da janela de contexto. Nenhum desses números prevê economia. Limite de instruções do Codex, Orientações de escrita do Claude Code.

Em um fluxo de produção, registre o custo do agente principal, dos subagentes, da compactação, da recuperação de informações e das novas tentativas. Depois, calcule:

Custo por tarefa aceita = custo total do fluxo em todas as tentativas ÷ tarefas que atendem aos critérios de aceitação.

Para um orçamento mensal, some os custos de uso do modelo aos de ferramentas, recuperação de informações, armazenamento e hospedagem. Não existe um preço mensal único para engenharia de contexto, nem uma economia em dólares que possa ser sustentada sem conhecer sua carga de trabalho e as tarifas aplicáveis do provedor.

O cache complica a comparação. O cache de prompts da OpenAI reutiliza prefixos renderizados idênticos. A compactação pode alterar esse prefixo e reduzir a reutilização do cache, mesmo que a requisição fique mais curta. Mantenha as instruções reutilizáveis estáveis sempre que possível e compare o custo total antes e depois da mudança. Uma taxa menor de acertos no cache, sozinha, não prova que uma otimização falhou. Cache de prompts da OpenAI.

Use o guia de diagnóstico de cache de prompts do GPT-6 para separar problemas causados por mudanças nos prefixos daqueles causados por conteúdo desnecessário. O cache barateia o processamento de entradas repetidas; ele não decide se essas entradas pertencem à tarefa.

Boas práticas de engenharia de contexto: por onde começar?

Aja quando o trace mostrar uma falha de contexto e escolha a menor intervenção que a resolva. Um trace é o registro da sequência de requisições, chamadas de ferramentas e resultados, incluindo o que o modelo viu antes de cada decisão.

Para quem desenvolve, inspecione a etapa imediatamente anterior à ação errada. Se faltam evidências, corrija a recuperação. Se elas estão soterradas em saídas repetidas, filtre o resultado da ferramenta. Se uma discussão anterior se sobrepõe à tarefa atual, corrija o estado da tarefa e o registro de continuidade. Se uma investigação que pode ser separada inunda a conversa principal, isole-a.

Para quem opera, defina o que é um resultado aceito e preserve falhas representativas para avaliação. Compare a qualidade da conclusão, as afirmações sem respaldo, as novas tentativas, a latência e o custo total nas mesmas tarefas. Altere uma política de contexto por vez para que o resultado continue sendo interpretável. Use traces existentes para elaborar casos de avaliação offline.

Para quem compra, pergunte se o produto mostra o contexto e os resultados de ferramentas por trás de uma resposta, preserva as referências às fontes depois de resumir e permite controlar as instruções persistentes. É difícil diagnosticar um recurso de “memória” quando não se consegue ver o que ele carrega.

Adie a adoção de mecanismos adicionais quando um fluxo curto e delimitado já funciona de forma confiável. Talvez você precise de uma instrução mais clara ou de uma mensagem de erro melhor da ferramenta, sem um serviço de memória ou uma rede de subagentes. Se a falha vem de permissões incorretas, de um problema na lógica da aplicação ou da indisponibilidade dos dados de origem, resolva a causa diretamente; a curadoria de contexto, sozinha, não consegue corrigi-la.

O que há de exagero nas promessas da engenharia de contexto?

Uma janela de contexto maior, mais memória e mais agentes são capacidades, não evidências de decisões melhores. A pergunta útil é se esses recursos ajudam este fluxo a levar as informações certas para a próxima etapa.

“Coloque tudo no prompt” evita fazer escolhas, mas introduz material conflitante. “Resuma tudo” faz uma seleção agressiva demais se apagar a exceção que importa. “Deixe um subagente cuidar disso” só ajuda quando a tarefa pode atravessar essa separação sem perder decisões essenciais.

O erro mais caro é confundir uma requisição mais curta com um sistema validado. Um agente que responde a baixo custo com base na política errada continua errado. Uma boa política de contexto deve facilitar a verificação da resposta: a regra que orienta a decisão está visível, as evidências de apoio têm fonte e as incertezas ainda não resolvidas permanecem explícitas.

Dúvidas de quem desenvolve agentes que perdem o rumo

A engenharia de contexto resolve o problema de um agente que funciona na demonstração, mas falha em produção?

Ela pode resolver a falta de evidências, instruções desatualizadas, resultados excessivos de ferramentas e a perda do estado da tarefa. Primeiro, inspecione a requisição que falhou. Uma ferramenta com defeito, uma lógica de aplicação incorreta ou uma tarefa além da capacidade do modelo exige uma correção própria. Avalie a mudança pelos resultados aceitos em tarefas representativas.

Preciso de um banco de dados vetorial ou de um framework multiagente para começar?

Não. Comece com instruções explícitas de projeto, recuperação direcionada de arquivos ou documentos, resultados de ferramentas delimitados e um registro para dar continuidade à tarefa. Acrescente busca semântica quando ela for necessária para encontrar material relevante, ou um subagente quando uma investigação independente se beneficiar de um contexto separado.

Como saber se enxuguei demais o contexto?

Confira se a próxima decisão ainda conta com a regra que a orienta, as evidências de apoio, o escopo aplicável e as exceções importantes. Se o agente precisa adivinhar um fato removido, o contexto ficou enxuto demais. Mantenha uma fonte recuperável e amplie a leitura quando o trecho não resolver a questão.

Para colocar em prática na segunda-feira: pegue uma execução que já falhou e inspecione a requisição anterior à primeira ação errada. Classifique seu conteúdo como instruções permanentes, estado da tarefa ativa, evidências necessárias agora ou material que pode continuar armazenado. Faça a menor alteração correspondente e, depois, compare o resultado e o custo total do fluxo nos mesmos casos de avaliação.

Assine a newsletter para receber guias práticos sobre como criar e operar agentes úteis.