Engenharia de contexto para agentes de IA

O agente pode ter acesso a tudo e ainda trabalhar mal

Empresas conectam agentes de IA ao CRM, e-mail, documentos, planilhas, calendário e sistemas internos esperando respostas melhores. O acesso aumenta, mas a qualidade nem sempre acompanha.

O agente recebe o histórico inteiro de um cliente quando precisava apenas do compromisso mais recente. Consulta três versões de uma política sem saber qual está vigente. Encontra uma conversa informal e a trata como decisão aprovada. Carrega instruções demais, perde a prioridade da tarefa e devolve uma resposta fluente que exige conferência completa.

Esse problema costuma ser atribuído ao modelo. Muitas vezes, a falha está na montagem do contexto.

Engenharia de contexto é a disciplina de selecionar, estruturar e entregar ao agente as informações, regras, ferramentas e estados necessários para executar uma tarefa específica. Ela determina o que entra na execução, em que formato, com qual prioridade, sob quais permissões e com que evidência.

Para uma empresa, isso representa uma mudança importante. Conectar dados abre uma porta. Preparar contexto decide se o agente encontrará um caminho operacional ou apenas uma sala cheia de arquivos.

O que é engenharia de contexto

Durante cada execução, um agente trabalha com um conjunto limitado de elementos. Esse conjunto pode incluir:

objetivo atual;
identidade do usuário e do agente;
instruções permanentes;
procedimento aplicável;
estado da tarefa;
registros do sistema transacional;
documentos recuperados;
histórico relevante;
ferramentas disponíveis;
permissões e bloqueios;
formato esperado da saída;
critérios de conclusão.

A engenharia de contexto organiza esse pacote para que o agente consiga agir com precisão suficiente e dentro das regras da empresa.

Ela vai além de escrever um prompt. O prompt é uma parte do pacote. Dados do caso, memória, políticas, resultados de ferramentas e estado mudam a cada execução. A arquitetura precisa combinar camadas permanentes e variáveis sem transformar a janela de contexto em depósito.

Também existe diferença entre engenharia de contexto e base de conhecimento para agentes de IA. A base organiza fontes que podem ser consultadas. A engenharia de contexto decide quais fontes, trechos, registros e regras devem chegar ao agente naquela tarefa.

Contexto bom começa pela unidade de trabalho

A pergunta “quais dados podemos conectar?” costuma produzir projetos amplos e pouco úteis. Comece definindo a unidade que o agente deve processar.

Pode ser:

uma oportunidade comercial;
um chamado de atendimento;
uma nota fiscal;
uma reunião;
uma proposta;
um contrato;
um pedido;
uma cobrança;
uma pendência de projeto.

A unidade cria uma fronteira. Um agente que prepara follow-up comercial precisa entender uma oportunidade específica, seu contato, estágio, histórico recente, objeção, compromisso e próxima ação. Ele raramente precisa receber toda a carteira do vendedor.

Depois da unidade, defina a decisão ou entrega esperada. Preparar uma recomendação exige contexto diferente de enviar uma mensagem. Classificar um documento exige menos acesso do que corrigir um cadastro. Quanto maior a consequência, maior o cuidado com fonte, atualização e aprovação.

Esse recorte reduz custo e ruído. Também facilita teste, porque a empresa consegue comparar entradas semelhantes e observar se a saída melhora.

As seis camadas de um pacote de contexto operacional

Uma arquitetura prática pode separar o contexto em seis camadas. A divisão ajuda a encontrar a origem de erros e evita que tudo vire um texto longo e indivisível.

1. Objetivo e contrato da tarefa

O agente precisa saber o que deve entregar, para quem e com qual critério de conclusão.

“Analise este cliente” deixa espaço demais. “Prepare um briefing para a reunião de renovação, com situação atual, compromissos, riscos, pendências e decisões necessárias” define uma saída revisável.

O contrato também informa o que fica fora do escopo. Se o agente deve preparar o briefing, ele não precisa alterar o CRM nem enviar mensagem.

2. Estado atual do caso

O estado vem dos sistemas que registram a operação. CRM, ERP, ferramenta de projetos, sistema financeiro e agenda costumam responder melhor a fatos estruturados:

qual é o estágio;
quem é o responsável;
qual é o valor;
que prazo está vigente;
qual item continua pendente;
que evento aconteceu por último.

Enviar uma transcrição longa para descobrir um status que já existe em um campo aumenta incerteza. Sempre que possível, o agente deve consultar o dado na fonte que possui autoridade sobre ele.

3. Conhecimento aplicável

Políticas, procedimentos, catálogo, condições comerciais, manuais e documentação ajudam o agente a interpretar o caso.

A recuperação precisa considerar metadados. Produto, unidade, cliente, país, data de vigência, versão e nível de acesso podem mudar qual documento vale. Similaridade textual sem filtros pode trazer um trecho muito parecido e operacionalmente incorreto.

4. Memória relevante

A memória de agentes de IA sustenta continuidade. Ela pode recuperar uma objeção anterior, um compromisso, uma preferência ou uma decisão já tomada.

O critério deve ser utilidade para a tarefa atual. Uma conversa antiga pode explicar o relacionamento, mas também carregar hipóteses vencidas. Memórias precisam de identidade, data, fonte e escopo. Fatos e inferências devem permanecer distinguíveis.

5. Procedimento, ferramentas e limites

O agente precisa saber como executar o trabalho. Uma skill de agente de IA pode definir sequência, fontes, critérios, ferramentas, formato da saída e situações de escalonamento.

As ferramentas também compõem o contexto. Nome, finalidade, parâmetros e restrições precisam ser claros. Duas ferramentas com funções sobrepostas aumentam a chance de uso incorreto.

Permissões devem ser aplicadas tecnicamente. Uma instrução dizendo “não envie” ajuda, mas a credencial do agente deveria impedir envio quando a tarefa permite apenas leitura e preparação.

6. Evidência e saída

O resultado precisa conservar ligação com o que o sustentou. A saída pode incluir fontes consultadas, campos usados, lacunas encontradas, versão da política e ações propostas.

Isso reduz o trabalho de revisão. O responsável consegue verificar pontos sensíveis sem reconstruir toda a busca feita pelo agente.

Uma saída bem desenhada também informa o estado final: concluído, pendente de dado, bloqueado, aguardando aprovação ou escalado. “Pronto” é pouco quando o trabalho possui várias consequências possíveis.

Mais contexto pode reduzir a qualidade

Janelas maiores permitem processar mais material. Esse avanço técnico não elimina a necessidade de seleção.

Excesso de contexto cria problemas previsíveis:

instruções importantes competem com detalhes secundários;
versões antigas reaparecem ao lado das atuais;
o custo por execução cresce;
a resposta fica mais lenta;
dados sensíveis circulam sem necessidade;
o agente usa uma evidência plausível, mas inadequada;
a equipe perde capacidade de entender por que algo foi incluído.

A meta não deveria ser preencher a janela. A meta é montar o menor pacote que permita concluir a tarefa com qualidade e tratar exceções de forma segura.

Isso exige prioridade explícita. Regras de segurança e limites de ação precisam prevalecer sobre preferências de estilo. O estado transacional vigente deve superar um resumo antigo. Uma decisão aprovada deve ser distinguida de uma sugestão feita em reunião.

Contexto estático e contexto dinâmico

Parte do pacote muda pouco. Identidade do agente, objetivo da função, política de acesso e formato de saída podem permanecer estáveis por várias execuções.

Outra parte muda a cada caso:

usuário que iniciou a tarefa;
cliente ou processo envolvido;
estágio atual;
documentos vigentes;
últimas interações;
ferramentas disponíveis naquele ambiente;
pendências e prazos;
nível de risco;
aprovações já concedidas.

Misturar tudo em uma instrução permanente produz manutenção difícil. O contexto dinâmico deve ser montado no momento da execução a partir das fontes corretas.

Considere um agente que prepara análise de uma cobrança. A política de cobrança pode ser estática e versionada. O valor, pagamento, contestação e histórico do cliente são dinâmicos. A regra de escalonamento pode ser estática. A existência de uma disputa aberta muda a rota daquela execução.

Separar essas camadas permite atualizar uma política sem reescrever todo o agente e corrigir um cadastro sem alterar o procedimento.

Um exemplo no processo comercial

Imagine uma oportunidade que ficou sem próxima ação. O agente recebe a tarefa de preparar uma recomendação para o vendedor.

Um pacote de contexto útil pode conter:

identificador da oportunidade e responsável;
estágio, valor e data da última movimentação no CRM;
resumo da última reunião com link para a fonte;
objeção registrada e compromisso de retorno;
proposta vigente, se houver;
política comercial aplicável;
procedimento de follow-up;
permissão apenas para leitura e preparação;
formato de saída com diagnóstico, próxima ação, mensagem sugerida e lacunas;
regra de escalonamento para condição especial, conflito de valor ou pedido explícito de não contato.

O agente não precisa receber todos os e-mails do cliente desde o primeiro contato. Pode buscar uma mensagem específica se encontrar divergência. Essa recuperação progressiva preserva foco e permite aprofundar quando o caso exige.

A saída registra os fatos usados, separa interpretação de evidência e entrega uma recomendação para aprovação. Esse desenho combina contexto com o fluxo de follow-up comercial com IA sem transformar o agente em remetente autônomo desde o primeiro dia.

Como testar a qualidade do contexto

Avaliar apenas a resposta final esconde parte do problema. A empresa também precisa testar se o pacote entregue era adequado.

Monte casos que incluam:

registro completo e consistente;
documento vencido ao lado da versão atual;
duas fontes com informações conflitantes;
memória de outro cliente que nunca pode aparecer;
dado obrigatório ausente;
usuário sem permissão para uma fonte;
mudança de estágio feita depois do último resumo;
exceção que exige aprovação;
ferramenta indisponível;
solicitação fora do escopo.

Observe quatro dimensões.

Relevância

O agente recebeu os elementos necessários e evitou material sem relação com a tarefa?

Autoridade

As fontes corretas prevaleceram quando havia conflito? Documento vigente, sistema transacional e decisão aprovada foram identificados?

Segurança

O pacote respeitou usuário, cliente, função e finalidade? Informações sensíveis ficaram fora quando não eram necessárias?

Resultado operacional

A seleção reduziu tempo de revisão, retrabalho e erro? O agente conseguiu concluir mais casos com evidência suficiente?

O guia sobre como avaliar agentes de IA ajuda a transformar esses cenários em testes de regressão. Mudanças no recuperador, na memória, na instrução ou nas ferramentas devem enfrentar casos estáveis antes de entrar em produção.

Sinais de que a empresa precisa rever a engenharia de contexto

Alguns sintomas aparecem com frequência:

usuários precisam repetir informações já registradas;
respostas citam políticas antigas;
o agente mistura clientes ou projetos;
cada execução envia o histórico completo;
a revisão humana precisa refazer toda a pesquisa;
custos crescem sem melhora de qualidade;
fontes são conectadas sem dono ou prioridade;
o agente recebe ferramentas que nunca deveria usar naquela tarefa;
resultados variam porque cada pessoa monta o contexto de um jeito;
ninguém consegue explicar quais dados sustentaram a recomendação.

Esses sinais indicam uma arquitetura de entrada frágil. Trocar o modelo pode alterar o comportamento, mas dificilmente corrige sozinho fonte, autoridade, identidade e escopo.

Checklist para desenhar o primeiro pacote

Qual unidade de trabalho será processada?
Que entrega encerra a tarefa?
Qual sistema confirma o estado atual?
Que conhecimento é aplicável ao caso?
Que memória precisa voltar e por quanto tempo?
Quais informações devem ficar de fora?
Que procedimento orienta a execução?
Quais ferramentas são necessárias?
Que permissões o agente recebe?
Que eventos exigem bloqueio ou aprovação?
Como fatos e inferências serão separados?
Que evidência acompanhará a saída?
Como casos conflitantes serão testados?
Qual indicador mostra ganho operacional?

Engenharia de contexto transforma acesso em capacidade

Agentes empresariais dependem de contexto para interpretar, decidir e usar ferramentas. A qualidade desse contexto vem da seleção e da arquitetura ao redor da execução.

Quando a empresa define unidade de trabalho, fonte de autoridade, memória relevante, procedimento, limite e evidência, o agente recebe condições melhores para produzir algo útil. A operação também ganha legibilidade: fica mais claro onde o dado nasce, por que foi usado e quem responde pela próxima decisão.

Essa disciplina evita duas despesas silenciosas. A primeira é pagar para processar informação que não ajuda. A segunda é mobilizar pessoas para conferir uma resposta que perdeu a fonte, a versão ou o objetivo no meio do caminho.

Antes de ampliar a janela, conectar outra pasta ou adicionar mais uma integração, revise o pacote de contexto de uma tarefa real. Descubra o que o agente precisa saber, o que precisa ignorar e onde deve parar. É nessa arquitetura que acesso começa a virar capacidade operacional.