Agentes de IA em produção: o que separa demo de operação real

A demo é a parte fácil

Em 2026, qualquer dev júnior monta uma demo de agente em 30 minutos. Cole um prompt, plugue uma ferramenta, grave o vídeo. Funciona o suficiente pra impressionar quem não opera.

Pôr o mesmo agente em produção — com dado real, integração crítica, regulador respirando no cangote e usuário pago do outro lado — é onde 90% dos projetos morrem. Não por falta de modelo bom. Por falta de operação.

Os 7 cortes

Cada um separa quem demonstrou de quem entregou:

1. Contexto vivo, não prompt estático. Agente em produção lê convenções, decisões passadas, regras de negócio do seu vault — não adivinha a partir de um parágrafo de system prompt.
2. Ferramentas com escopo mínimo. Cada tool tem permissão cirúrgica. Ninguém dá "admin no banco" pra agente — dá "SELECT em tabela X com filtro Y".
3. Observabilidade ponta a ponta. Cada prompt, cada chamada de tool, cada resposta logada com contexto. Quando algo der errado — vai dar — você precisa do replay.
4. Gate humano em ações irreversíveis. Apagar, transferir, publicar, cobrar. Sempre humano. Sempre.
5. Avaliação contínua. Conjunto de prompts-canary rodando diário. Modelo regrediu? Mudou de comportamento? Você sabe antes do cliente.
6. Runbook de incidênte. O que fazer quando o agente alucina e age. Quem desliga, quem comunica, quem reverte. Testado, não teorizado.
7. Responsabilidade humana com nome. Cada entrega de agente passa por revisor sênior que assina. Não por cerimonia — por jurídico.

O custo que ninguém calcula no piloto

No piloto, você conta tokens. Em produção, você conta:

• Tokens × escala real (geralmente 10-100× o piloto)
• Custo de observabilidade (Datadog/Honeycomb por evento)
• Custo de armazenamento de logs (compliance exige retenção longa)
• Custo de re-treino/fine-tune quando o modelo base muda
• Custo de incidente (1 alucinação cara > 6 meses de token)
• Custo de gente sênior revisando e calibrando

Quem não orça esses 6 itens entra no vermelho no mês 3 e culpa o modelo.

Sinais de que seu agente ainda está em modo demo

Cinco bandeiras vermelhas que aparecem antes do incidente sério — e que geralmente são ignoradas até ser tarde demais:

• Ninguém sabe o que acontece se a API do modelo cair no meio de uma ação em andamento.
• O agente já tomou uma decisão que ninguém consegue explicar depois, olhando o log — porque o log não registrou o raciocínio, só o resultado.
• "Vamos adicionar monitoramento depois" já foi dito mais de uma vez sobre o mesmo agente.
• Ninguém testou o que acontece quando o agente recebe input adversarial ou mal formado de propósito.
• O agente tem acesso a mais sistema do que qualquer tarefa dele realmente usa — permissão de sobra "por conveniência".

Duas ou mais dessas presentes ao mesmo tempo é sinal de que o agente está pronto pra impressionar em demonstração, não pra rodar sem supervisão constante.

O que costuma dar errado primeiro, na prática

O primeiro incidente sério raramente é o modelo "alucinando" de forma dramática — é mais chato que isso. É timeout de ferramenta externa que o agente interpreta como sucesso silencioso e segue o fluxo como se nada tivesse acontecido. É retry automático disparando a mesma ação três vezes porque ninguém implementou idempotência na chamada. É contexto que estoura o limite da janela e trunca silenciosamente a instrução mais importante do prompt, sem erro visível em lugar nenhum.

Nenhum desses casos aparece na demo, porque demo roda em condição controlada, com rede estável e dado limpo. Produção não tem essa cortesia — e é exatamente por isso que Agent OS com observabilidade ponta a ponta deixa de ser luxo e vira pré-requisito assim que o agente toca dado ou sistema real.

Quando vale a pena esperar antes de ir pra produção

Contraintuitivo, mas real: às vezes a decisão certa é adiar o lançamento. Se a ação do agente é irreversível e de alto custo (cobrar cliente errado, deletar registro, publicar conteúdo em nome da empresa), e o runbook de incidente ainda não foi testado de verdade — não simulado em reunião, testado com o dedo no botão — o agente não está pronto, não importa quão boa a demo tenha sido.

A pergunta que separa operação madura de aposta é simples: se esse agente errar às 3h de uma sexta-feira, alguém sabe exatamente o que fazer nos primeiros 10 minutos? Se a resposta é "provavelmente", ainda não é hora de produção. Esperar mais uma semana pra testar o runbook de verdade custa muito menos que explicar pro cliente, ou pro regulador, por que ninguém sabia o que fazer quando o agente agiu errado.

Arquitetura mínima pra não falhar

Independente do framework (LangGraph, CrewAI, Letta, custom), a estrutura que funciona em produção tem essas 5 camadas:

1. Orçuestrador determinístico — máquina de estado que decide quando chamar LLM, quando cair em código. LLM não controla fluxo crítico.
2. Agent OS — a camada que gerencia identidade do agente, ferramentas disponíveis, memória, auditoria. Reutilizável entre agentes.
3. Brain — memória de longo prazo: vault de conhecimento + RAG + decisões passadas. Sem isso, agente esquece tudo a cada turn.
4. Tools com política — cada ferramenta tem ACL, rate limit, audit. Não é função Python crua.
5. Sandbox de execução — onde código gerado roda isolado de produção.

Onde a AUMI entra

O método AUMI cobre as 5 camadas acima de fora pra dentro: START coloca a primeira frente em produção com disciplina, SCALE roda várias frentes em paralelo com integração de canal, HYPER dedica orquestrador sênior e SLA 24/7. Pra missoes onde o agente é alvo, AEGIS blinda contra red team de fronteira.

Diagnóstico do seu cenário em 24h úteis: assessment gratuito.