Agentes de IA: do protótipo à produção

Qualquer pessoa consegue montar a demo de um agente de IA numa tarde. Some um modelo de linguagem, algumas ferramentas e um loop, e em minutos você tem algo que parece mágica: ele lê um e-mail, consulta uma base, responde, age. O problema é que a demo e o produto são animais diferentes. O que impressiona numa apresentação controlada costuma desmoronar diante de usuários reais, dados bagunçados e o custo de errar em escala.

O whitepaper Introduction to Agents, publicado pela Google em novembro de 2025, deixa esse contraste explícito. Ele define um agente como “modelos de linguagem em um loop, com ferramentas, para cumprir um objetivo” e, de forma mais reveladora, como “um sistema dedicado à arte da curadoria da janela de contexto”. A definição é simples; a engenharia para chegar à produção, não. Este artigo destrincha o que separa o protótipo do sistema confiável.

Um agente é um sistema dedicado à arte da curadoria da janela de contexto.Google · Introduction to Agents

O que é um agente de IA, afinal?

Um agente de IA é um software que usa um modelo de linguagem para decidir, passo a passo, quais ações tomar, chamando ferramentas, lendo resultados e seguindo até cumprir um objetivo. A Google descreve sua anatomia em quatro partes que vale memorizar, porque cada uma vira um ponto de falha em produção:

• O Modelo é o cérebro: raciocina, planeja e decide a próxima ação.
• As Ferramentas são as mãos: dão ao modelo acesso ao mundo (APIs, bancos, buscas, ações).
• A Orquestração é o sistema nervoso: o loop que coordena planejamento, memória e raciocínio entre uma decisão e a seguinte.
• A Implantação (deployment) é o corpo: a infraestrutura que coloca tudo isso de pé, com escala, segurança e monitoramento.

A demo costuma exibir só o cérebro e as mãos. A produção vive ou morre pelo sistema nervoso e pelo corpo, e é justamente aí que a maioria dos projetos tropeça.

De prompt engineering para context engineering

A grande virada de mentalidade, segundo a Google, é abandonar a ideia de “engenharia de prompt” e abraçar a “engenharia de contexto”. Não basta caprichar numa instrução: o que define a qualidade de um agente é a curadoria do que entra na janela de atenção (limitada) do modelo a cada passo. Instruções, fatos relevantes, ferramentas disponíveis e histórico da conversa competem por esse espaço escasso, e escolher bem é metade do trabalho.

É aqui que a memória entra como peça de engenharia, não como detalhe. A Google distingue dois tipos: a memória de curto prazo, que mantém o fio da conversa atual dentro da janela de contexto; e a de longo prazo, que persiste conhecimento entre sessões, na prática um sistema de RAG sobre um banco vetorial, consultado sob demanda quando o agente precisa lembrar de algo que já não cabe na janela.

Como medir se um agente está funcionando?

Você não pode melhorar o que não mede, e medir agentes é mais difícil do que medir software comum, porque a saída não é certa nem errada, é melhor ou pior. A Google chama essa disciplina de “Agent Ops”, a evolução natural de DevOps e MLOps. A receita é metrificar o comportamento real do agente, não só sua disponibilidade:

• Conclusão de objetivo: o agente de fato resolveu a tarefa do usuário, do início ao fim?
• Satisfação: a resposta foi útil e adequada, na percepção de quem perguntou?
• Latência e custo: quanto tempo e quantos tokens cada interação consumiu?
• Avaliação por “LM como juiz”: um modelo avalia as respostas do agente contra um conjunto de casos de referência (golden dataset).
• Rastreamento (tracing) de cada passo: registrar toda decisão, chamada de ferramenta e resultado intermediário, para conseguir depurar quando algo dá errado.

Com essas métricas em mãos, a decisão de lançar ou não uma versão deixa de ser uma sensação e vira um Go/No-Go orientado por dados. E há um hábito que a Google trata como inegociável: cada bug que aparece em produção deve ser convertido em um teste permanente, somado ao golden dataset, para que aquela falha nunca mais volte despercebida.

O que torna um agente seguro?

Dar a um modelo de linguagem o poder de agir muda a natureza do risco. A Google aponta duas ameaças principais: as “ações descontroladas” (rogue actions), quando o agente faz algo nocivo ou não intencionado, e a “exposição de dados sensíveis”, quando ele vaza informação que deveria proteger. Diferentemente de um chatbot que só fala, um agente que executa pode causar dano real, e por isso a segurança faz parte do design desde o início.

A resposta recomendada é defesa em profundidade, combinando duas camadas que se complementam:

• Guardrails determinísticos: regras rígidas, em código, que limitam o que o agente pode fazer, independentemente do que o modelo “decidir”.
• Defesas baseadas em raciocínio: o próprio modelo (ou um modelo supervisor) avaliando se uma ação é apropriada antes de executá-la.
• Identidade e menor privilégio: tratar o agente como uma nova classe de “principal”, com identidade própria e permissões mínimas, como se concede a um funcionário ou serviço.

Como a Charla aplica isso em produção

Na Charla, esses princípios são como a plataforma é construída. Todo assistente roda sobre um mesmo loop agêntico unificado, com recuperação agêntica: em vez de injetar passivamente trechos de uma base no prompt (RAG clássico), o agente chama ferramentas como kb_search e wiki_search sob demanda, quando de fato precisa da informação. É a “engenharia de contexto” da Google posta em prática: o agente cura o próprio contexto, passo a passo.

A camada de confiança aparece em decisões concretas de produto. As respostas são transmitidas por SSE (streaming), sem expor a cadeia de raciocínio bruta ao usuário. Cada chamada de ferramenta e cada ação privilegiada é gravada em um log de auditoria imutável (append-only). Cada assistente (cada “Charla”) é isolado, com sua própria base de conhecimento, lista de acesso e prompt. A recuperação é filtrada por assistente antes do ranqueamento, refletindo exatamente o princípio de identidade e menor privilégio.

O custo e a supervisão humana também são tratados como requisitos de primeira ordem: orçamentos de crédito por assistente limitam o gasto, e uma postura de propor-e-aprovar mantém uma pessoa no circuito para mudanças de conhecimento e configuração. São as preocupações de produção do whitepaper (confiabilidade, observabilidade, segurança, custo, supervisão) aparecendo em uma plataforma real, sem promessas mágicas.

De pedreiro a diretor

A conclusão da Google resume a mudança de papel de quem constrói esses sistemas: o desenvolvedor deixa de ser um “pedreiro”, assentando cada tijolo de lógica à mão, e passa a ser um “diretor”, definindo objetivos, dando ferramentas, estabelecendo limites e julgando resultados. Construir a demo continuará fácil. O trabalho de verdade, e a vantagem competitiva, está em tudo o que vem depois dela: avaliar, observar, proteger, controlar o custo e manter o humano no comando. É exatamente nesse terreno que um agente deixa de ser um truque e vira um produto.