Uma das maiores armadilhas em projetos de agentes de IA é construir algo que parece inteligente, mas que ninguém consegue explicar quando falha.
No começo, o agente responde bem. Usa ferramenta. Consulta contexto. Gera resumo. Impressiona na demo. O problema aparece depois, quando alguém pergunta:
Por que ele respondeu isso?
Qual ferramenta ele chamou?
Qual contexto foi usado?
Quanto tempo demorou?
Qual modelo estava ativo?
Onde o fluxo quebrou?
O erro veio do prompt, da busca, da ferramenta ou do modelo?
A memória influenciou a resposta?
O custo está crescendo onde?
Se o time não consegue responder, não existe aplicação de IA madura. Existe uma caixa-preta com interface bonita.
É por isso que a integração entre LangChain, LangGraph e Microsoft Foundry ficou tão importante depois da consolidação do novo Foundry. A Microsoft passou a organizar uma trilha clara para usar o pacote langchain-azure-ai como ponto de entrada para aplicações LangChain e LangGraph com capacidades do Foundry, incluindo modelos, agentes, ferramentas, memória, vector stores, retrievers, chat histories, tracing e integração com Azure Monitor. (learn.microsoft.com)
Para mim, esse é um tema central da fase atual da IA corporativa: não basta criar agente. É preciso observar, rastrear, medir e governar agente.
O problema do agente invisível
Um agente invisível é aquele que executa uma tarefa, mas não deixa trilha suficiente.
Ele recebe uma entrada.
Chama um modelo.
Talvez use uma ferramenta.
Talvez recupere contexto.
Talvez consulte uma memória.
Talvez tome uma decisão intermediária.
Entrega uma resposta.
E ninguém sabe exatamente o que aconteceu no meio.
Isso pode ser aceitável em laboratório. Em produção, é perigoso.
Quando um agente ajuda alguém a escrever um texto, o risco pode ser baixo. Quando ele participa de suporte, vendas, jurídico, financeiro, atendimento, operação ou decisão executiva, a falta de visibilidade vira problema real.
Software tradicional já exige logs, métricas e rastreabilidade. Com IA, isso é ainda mais crítico, porque parte do comportamento é probabilístico.
Se você não observa, você não melhora.
Se não rastreia, não audita.
Se não mede, não governa.
Se não entende a falha, repete a falha.
Por que LangChain e LangGraph entram nessa conversa
LangChain e LangGraph se tornaram populares porque ajudam desenvolvedores a construir fluxos, agentes, chains, ferramentas, memória e orquestração com mais flexibilidade.
LangChain é muito útil para compor chamadas, ferramentas, modelos e retrievers.
LangGraph é especialmente interessante quando o fluxo precisa de estado, grafo, múltiplas etapas ou comportamento mais controlado.
O ponto é que frameworks flexíveis resolvem uma dor, mas criam outra: quanto mais liberdade, mais responsabilidade de observabilidade.
A Microsoft reconhece esse movimento ao disponibilizar o langchain-azure-ai como pacote de integração para conectar aplicações LangChain e LangGraph às capacidades do Foundry. A documentação apresenta blocos como Foundry Agent Service, Content Safety middleware, chat models, embeddings, vector stores, retrievers, chat history stores, tools, callbacks e tracing. (learn.microsoft.com)
Isso mostra uma direção clara: o Foundry não quer apenas hospedar agentes. Ele quer se conectar ao ecossistema real que os desenvolvedores já usam.
A pergunta certa não é “LangChain ou Foundry?”
Existe uma discussão comum no mercado: usar framework open source ou usar plataforma gerenciada?
Eu acho essa pergunta mal formulada.
A pergunta melhor é: qual parte da arquitetura precisa de flexibilidade e qual parte precisa de plataforma?
Você pode usar LangChain ou LangGraph para compor fluxos, testar padrões, criar agentes e controlar lógica. E pode usar Microsoft Foundry para modelos, identidade, endpoints, memória, ferramentas, observabilidade, RBAC e operação.
A documentação mostra esse caminho ao permitir que classes do langchain-azure-ai se conectem por meio de um Foundry project endpoint, reutilizando o endpoint do projeto e autenticando com Microsoft Entra ID e Azure RBAC. (learn.microsoft.com)
Ou seja: não precisa ser uma briga. Pode ser uma composição.
LangChain e LangGraph dão flexibilidade.
Microsoft Foundry dá base corporativa.
Azure Monitor e Application Insights dão observabilidade.
Entra ID e RBAC dão controle de acesso.
A arquitetura boa combina essas peças.
O que muda com project endpoint e Entra ID
Um ponto que parece pequeno, mas é muito importante: a integração com Foundry project endpoint.
A documentação mostra que várias classes do langchain-azure-ai podem usar o endpoint do projeto Foundry, configurado por AZURE_AI_PROJECT_ENDPOINT, e que, nesse padrão, a autenticação usa Microsoft Entra ID e RBAC no projeto. (learn.microsoft.com)
Isso é muito melhor do que espalhar chaves por toda aplicação.
Em laboratório, chave de API é rápida. Em produção, identidade é melhor.
Quando você usa Entra ID e RBAC, consegue alinhar a aplicação com práticas corporativas: menor privilégio, identidade gerenciada, permissões por projeto, governança e auditoria.
Minha regra seria:
API key para teste rápido.
Entra ID para aplicação séria.
Managed Identity para workload em Azure.
RBAC por função e por escopo.
Segredo compartilhado só quando realmente necessário.
Esse tipo de decisão não é detalhe. É fundamento de arquitetura.
Um desenho base de arquitetura
Eu desenharia uma aplicação LangGraph com Foundry assim:
Usuário / Aplicação
↓
Camada de experiência
↓
LangGraph workflow
↓
Nós especializados:
- classificador de intenção
- nó de recuperação
- nó de ferramenta
- nó de decisão
- nó de resposta
↓
Microsoft Foundry
- modelos
- ferramentas
- memória
- políticas
- endpoints
↓
Azure Monitor / Application Insights
- traces
- spans
- latência
- erros
- chamadas de modelo
- chamadas de ferramentaO ponto central é: o grafo executa a lógica, mas a operação precisa ser visível.
Cada nó importante deve emitir informação suficiente para entender o que aconteceu. Cada chamada de modelo deve poder ser rastreada. Cada tool call deve ter status, latência e resultado. Cada erro deve ser investigável.
Observabilidade não é opcional
A documentação de tracing do Foundry é direta: quando agentes se comportam de forma inesperada em produção, tracing permite identificar rapidamente a causa raiz. Ele captura telemetria detalhada, incluindo chamadas de LLM, tool invocations e fluxos de decisão do agente, permitindo depurar problemas, monitorar latência e entender comportamento entre requisições. (learn.microsoft.com)
Esse é exatamente o ponto.
Sem tracing, você vê apenas a resposta final.
Com tracing, você começa a enxergar o caminho.
E, em agentes, o caminho importa tanto quanto a resposta.
Um agente pode dar uma resposta correta pelo motivo errado. Pode usar uma fonte errada e, por sorte, acertar. Pode chamar ferramenta desnecessária. Pode ignorar contexto. Pode ter latência alta em uma etapa invisível. Pode falhar em silêncio e cair em fallback ruim.
Sem observabilidade, você só descobre quando o usuário reclama.
OpenTelemetry como ponte
Um aspecto importante é que o Foundry usa integração com OpenTelemetry para frameworks como LangChain e LangGraph. A documentação mostra que o pacote langchain-azure-ai pode emitir spans compatíveis com OpenTelemetry, que aparecem na área de Observability > Traces do portal Foundry e também se conectam ao Application Insights. (learn.microsoft.com)
Isso é relevante porque OpenTelemetry já é um padrão conhecido de observabilidade.
Em vez de criar um modelo completamente isolado para IA, a plataforma começa a aproximar observabilidade de agentes da observabilidade moderna de aplicações.
Para mim, esse é o caminho certo. IA precisa entrar no mesmo nível de disciplina operacional que o resto do software.
O que eu rastrearia em um agente
Em uma aplicação com LangGraph e Foundry, eu rastrearia pelo menos:
request_id
user_id ou app_id
session_id
workflow_name
node_name
model_name
tool_name
retriever_name
input_type
output_type
latency_ms
status
error_message
token_usage
memory_used
documents_retrieved
confidence_score quando aplicável
human_escalation
timestampNão significa armazenar tudo em texto puro. Pelo contrário: é preciso cuidado com dados sensíveis. Mas os metadados precisam existir.
A documentação também alerta que tracing pode capturar informações sensíveis, como entradas do usuário, saídas do modelo e argumentos ou resultados de ferramentas. Por isso recomenda habilitar gravação de conteúdo durante desenvolvimento e debugging, mas desabilitar em produção quando necessário para proteger dados sensíveis. (learn.microsoft.com)
Esse ponto é crítico.
Observabilidade demais, sem política, pode virar risco de privacidade.
Observabilidade de menos vira cegueira operacional.
A arquitetura precisa equilibrar os dois.
Foundry Memory: memória não é histórico infinito
Outro tema importante da documentação é o uso de Foundry Memory com LangChain e LangGraph. A ideia é usar langchain-azure-ai e Foundry Memory para adicionar memória de longo prazo às aplicações, mantendo o histórico curto no runtime e usando Foundry Memory como armazenamento de contexto durável no nível do usuário. (learn.microsoft.com)
Esse ponto é importante porque muita gente confunde memória com histórico infinito de chat.
Memória boa não é guardar tudo.
Memória boa é guardar o que importa.
Se você coloca todo histórico no contexto, aumenta custo, ruído e risco. Se não guarda nada, perde continuidade. O caminho certo é separar memória de curto prazo e memória de longo prazo.
A própria documentação separa o papel da memória de longo prazo, como preferências estáveis do usuário e resumos de conversas anteriores, enquanto o estado curto da conversa fica no runtime do LangChain ou LangGraph. (learn.microsoft.com)
Essa separação é arquitetura pura.
Que tipo de memória faz sentido?
Eu separaria memória em três categorias.
1. Memória de sessão
É o contexto da conversa atual. Serve para manter coerência durante aquele atendimento ou fluxo.
2. Memória de perfil
São fatos mais estáveis sobre o usuário: preferências, idioma, cargo, tipo de uso, configurações e padrões relevantes.
3. Memória de resumo
São resumos de interações passadas que podem ajudar em uma nova conversa, sem carregar todo o histórico bruto.
O erro é misturar tudo.
Se eu guardo informação demais, o agente fica contaminado por contexto antigo. Se guardo informação sensível sem controle, crio risco. Se não defino escopo, a memória pode aparecer onde não deveria.
Memória exige governança
Memória em agentes é poderosa, mas perigosa.
Um agente que lembra preferências pode melhorar experiência. Um agente que lembra informação sensível sem necessidade pode violar privacidade. Um agente que usa memória errada pode personalizar mal. Um agente que recupera contexto antigo pode tomar decisão baseada em dado desatualizado.
Então, antes de usar memória, eu definiria:
O que pode ser memorizado?
O que nunca deve ser memorizado?
Por quanto tempo?
Quem pode acessar?
Como apagar?
Como atualizar?
Como separar usuários, sessões e recursos?
Como auditar recuperação de memória?
Como evitar uso indevido?
A documentação do Foundry Memory trabalha com o conceito de escopos para particionar informação, usando identificadores como user ID, session ID e resource ID. Isso é importante porque memória sem escopo vira vazamento contextual. (learn.microsoft.com)
Para produção, eu trataria escopo como item obrigatório.
Exemplo conceitual: assistente técnico com memória
Imagine um assistente interno para arquitetos e desenvolvedores.
Ele ajuda a responder dúvidas sobre Azure, Foundry, arquitetura e padrões internos. Sem memória, toda conversa começa do zero. Com memória, ele pode lembrar que um usuário trabalha mais com Python, que prefere exemplos em Azure CLI ou que está desenvolvendo um projeto com Foundry Agent Service.
Mas a memória precisa ser limitada.
Eu permitiria memorizar:
Preferência de linguagem: Python
Preferência de profundidade: técnica avançada
Projeto atual: agente interno de suporte
Formato preferido: exemplos objetivosEu não permitiria memorizar:
Segredos
Tokens
Credenciais
Dados pessoais sensíveis
Informação de cliente
Dados financeiros
Informação jurídica
Dados de saúdeA diferença entre personalização e risco está nesse limite.
LangGraph: quando o fluxo precisa de estado
LangGraph faz sentido quando a aplicação precisa de fluxo com estado, múltiplos nós, decisão condicional e controle mais claro do caminho.
Um chatbot simples talvez não precise de LangGraph.
Um agente com múltiplas etapas pode precisar.
Um processo que consulta ferramenta, decide caminho, valida risco e escala para humano provavelmente se beneficia de grafo.
Eu usaria LangGraph quando precisasse desenhar explicitamente:
nó de entrada;
nó de classificação;
nó de recuperação;
nó de ferramenta;
nó de avaliação;
nó de resposta;
nó de escalonamento humano;
nó de fallback.
Isso dá mais controle que um fluxo livre.
Mas controle só vale se você observa o que está acontecendo. Por isso, LangGraph sem tracing continua sendo uma caixa-preta, apenas com mais estrutura interna.
Um desenho de fluxo LangGraph com Foundry
Um exemplo conceitual de fluxo:
START
↓
ClassifyIntent
↓
RetrieveContext
↓
CheckRisk
↓
[Low Risk] → GenerateAnswer
[Medium Risk] → GenerateAnswerWithDisclaimer
[High Risk] → HumanEscalation
↓
TraceResult
↓
ENDEsse tipo de grafo evita que tudo vá para o mesmo caminho.
A pergunta simples recebe resposta simples.
A pergunta com risco recebe aviso.
A pergunta crítica vai para humano.
Tudo fica rastreável.
Isso é muito melhor do que criar um prompt gigante pedindo para o modelo decidir tudo sozinho.
O papel do Azure Monitor e Application Insights
O Foundry se conecta ao Azure Monitor e Application Insights para observabilidade. A documentação de tracing exige um projeto Foundry com tracing conectado ao Azure Monitor Application Insights e permissões adequadas para ingestão e visualização de traces. (learn.microsoft.com)
Isso é importante porque coloca IA dentro do ecossistema operacional do Azure.
O time que já monitora aplicações pode começar a acompanhar agentes. Pode olhar latência, erros, chamadas, traces e padrões de comportamento.
Em um ambiente mais maduro, eu criaria dashboards para:
latência por workflow;
erro por ferramenta;
custo por modelo;
uso por agente;
taxa de fallback;
escalonamentos humanos;
tempo de execução;
falhas de retrieval;
nós mais lentos;
requisições com risco.
Sem dashboard, o time só reage a reclamação.
O que eu colocaria em um dashboard de agentes
Para um dashboard inicial, eu usaria:
Total de execuções
Execuções com erro
Latência média
P95 de latência
Tool calls por execução
Falhas por ferramenta
Modelo mais usado
Custo estimado por agente
Taxa de fallback
Taxa de escalonamento humano
Traces com conteúdo bloqueado
Principais intenções
Principais fontes recuperadasIsso já começa a transformar agente em produto observável.
Depois, conforme maturidade, adicionaria avaliações de qualidade e métricas de satisfação.
O erro de monitorar só infraestrutura
Outro erro comum é monitorar só infraestrutura.
CPU, memória, requisição e erro HTTP importam. Mas em aplicações de IA isso é insuficiente.
Você precisa monitorar comportamento.
O agente usou a fonte certa?
Chamou a ferramenta certa?
Respondeu dentro do escopo?
Inventou informação?
Pediu humano quando deveria?
Usou memória relevante?
Caiu em prompt injection?
Custou mais que o esperado?
Essas métricas são específicas de IA. Não aparecem automaticamente em um monitoramento tradicional.
A observabilidade moderna de IA precisa unir infraestrutura, aplicação e comportamento do modelo.
Segurança e privacidade em traces
Tracing é fundamental, mas precisa de política.
Se você grava tudo, pode acabar armazenando dados sensíveis em Application Insights ou logs. Se não grava nada, perde capacidade de debugging.
Eu faria assim:
Ambiente de desenvolvimento
Permitir conteúdo mais detalhado para debugging, com dados fictícios ou mascarados.
Homologação
Registrar conteúdo controlado, com amostras e cuidado com PII.
Produção
Preferir metadados, IDs, status, latência, ferramentas, modelos e erros. Gravar conteúdo apenas quando houver justificativa, mascaramento e política clara.
Essa separação conversa com a recomendação da Microsoft de controlar gravação de conteúdo e evitar armazenar segredos, credenciais ou tokens em prompts e argumentos de ferramentas. (learn.microsoft.com)
A regra é simples: log deve ajudar a operar, não criar novo risco.
Como isso ajuda em incidentes
Imagine que um agente respondeu incorretamente sobre uma política interna.
Sem trace, você só tem a resposta final.
Com trace, você pode investigar:
Qual modelo foi usado.
Qual prompt estava ativo.
Qual memória foi recuperada.
Quais documentos foram consultados.
Qual ferramenta foi chamada.
Qual nó do grafo tomou a decisão.
Quanto tempo cada etapa levou.
Se houve fallback.
Se alguma fonte estava desatualizada.
Isso muda tudo.
O incidente deixa de ser discussão subjetiva e vira análise técnica.
Como isso ajuda em melhoria contínua
Observabilidade não serve só para erro. Serve para evolução.
Você pode descobrir que:
um nó do grafo é lento;
uma ferramenta falha demais;
um modelo caro está sendo usado em tarefa simples;
o retrieval traz documentos ruins;
a memória está pouco útil;
o fallback está alto;
usuários fazem perguntas que o sistema não cobre;
um agente especialista não está agregando valor.
Com esses dados, você melhora o sistema.
IA não deveria ser publicada e esquecida. Deveria ser iterada como produto.
Um exemplo aplicado ao varejo
Imagine um agente para vendedores em loja.
Ele ajuda a responder perguntas sobre produto, campanha, garantia, objeções e condições comerciais.
Sem observabilidade, você não sabe se ele está ajudando ou criando risco.
Com observabilidade, você consegue ver:
quais produtos geram mais dúvidas;
quais campanhas confundem vendedores;
quais respostas são mais usadas;
quando o agente consulta fonte errada;
quais perguntas exigem humano;
quais lojas usam mais;
qual latência no ponto de venda;
onde o conteúdo precisa melhorar.
Esse tipo de insight vai além da tecnologia. Ele melhora operação.
E é exatamente esse tipo de conexão entre tecnologia e negócio que torna agentes realmente úteis.
Um método simples para começar
Eu começaria com quatro passos.
1. Padronizar endpoint e autenticação
Usar Foundry project endpoint, Entra ID e RBAC sempre que possível. Evitar espalhar chave.
2. Criar fluxo observável
Mesmo que simples, cada etapa relevante precisa ser rastreável.
3. Separar memória curta e longa
Histórico de sessão no runtime. Memória durável apenas para fatos realmente úteis e permitidos.
4. Conectar tracing ao Azure Monitor
Sem isso, o time não consegue operar.
Depois disso, eu evoluiria para dashboards, avaliação, alertas e governança mais avançada.
Checklist para uma aplicação LangGraph com Foundry
Antes de chamar uma aplicação de pronta para produção, eu verificaria:
Usa project endpoint quando possível
Usa Entra ID / RBAC em vez de segredo compartilhado
Tem separação de ambientes
Tem grafo documentado
Tem nós com responsabilidade clara
Tem fallback
Tem human-in-the-loop para risco alto
Tem tracing habilitado
Tem Application Insights conectado
Tem política de gravação de conteúdo
Tem controle de dados sensíveis
Tem memória com escopo definido
Tem avaliação de qualidade
Tem dashboard básico
Tem dono técnico e dono de negócioSem isso, o agente ainda está em estágio de laboratório.
Minha leitura sobre abril de 2026
Abril de 2026 é um bom momento para falar desse tema porque, depois da GA do Microsoft Foundry em março, a conversa naturalmente sai de “novo portal” e entra em “como construir aplicações de IA de forma madura”.
A documentação do Foundry passou a mostrar claramente uma trilha para LangChain e LangGraph com langchain-azure-ai, incluindo integração com modelos, agentes, ferramentas, memória, vector stores, retrievers, chat histories e callbacks/tracing. Também há documentação específica para tracing de frameworks de agentes com OpenTelemetry, LangChain, LangGraph e integração com Application Insights. (learn.microsoft.com)
Para mim, isso confirma uma tese: a próxima fase da IA não é apenas criar mais agentes. É criar agentes observáveis, governáveis e integrados à operação real da empresa.
Conclusão
LangChain e LangGraph continuam sendo ferramentas muito fortes para construir aplicações e agentes com flexibilidade.
Microsoft Foundry entra como a camada que ajuda a transformar essa flexibilidade em algo mais governável: endpoints de projeto, autenticação com Entra ID, integração com modelos, ferramentas, memória e observabilidade com Azure Monitor.
O ponto principal é simples: agente invisível não deveria ir para produção.
Se você não consegue rastrear o que aconteceu, não consegue confiar.
Se não consegue medir, não consegue melhorar.
Se não consegue auditar, não consegue governar.
Se não consegue explicar, não consegue escalar.
A maturidade em IA corporativa não está apenas em criar agentes mais capazes. Está em criar agentes que possam ser observados, corrigidos, avaliados e operados.
No fim, um agente de IA é software.
E software sério deixa rastro.
A diferença é que, com IA, esse rastro precisa mostrar não apenas se o sistema rodou, mas como ele pensou, que ferramentas usou, que contexto recuperou e por que chegou à resposta final.
Essa é a nova camada de engenharia que o Microsoft Foundry começa a organizar.
E, para mim, esse é o verdadeiro salto: sair do agente que impressiona na demo e chegar no agente que aguenta produção.
Seja o primeiro a comentar