Agentes de IA em produção, não slides
Engenharia de agentes de IA generativa que rodam em produção 24/7 dentro da sua infra — com observability, guardrails e fallback determinístico quando o modelo falha.
O problema que vemos no mercado
A maioria dos projetos de IA generativa que chegam até nós já passou por um ciclo conhecido: alguém da liderança viu uma demo brilhante, contratou uma squad de consultoria, recebeu uma POC bonita em três semanas, e dali em diante nada chegou em produção. O backlog está cheio de provas de conceito; o ROI está vazio.
Quando a gente abre o capô, encontra sempre os mesmos quatro problemas. Primeiro, alucinação não tratada: o modelo inventa nomes de clientes, datas, valores, e ninguém colocou guardrails determinísticos no caminho. Segundo, observability inexistente: não há rastreio de prompt, custo por chamada, latência por etapa nem taxa de fallback — então diagnóstico de regressão é puro chute. Terceiro, custo descontrolado: o sistema chama GPT-4 quando GPT-4o-mini resolveria, ou faz embedding completo a cada request quando devia cachear. Quarto, integração frouxa: o agente conversa lindamente, mas não escreve no ERP, não atualiza o CRM, não consulta o banco de dados real do cliente.
O resultado é previsível. A POC fica em ambiente isolado, a operação continua a mão, e seis meses depois alguém propõe contratar outra consultoria pra refazer. O dinheiro foi gasto, o problema continua.
Como entregamos
Não tratamos agentes de IA como produto mágico. Tratamos como software de missão crítica que tem um componente probabilístico no meio — e que portanto precisa do mesmo rigor de engenharia que um sistema bancário tem: logging, testes, fallback, métricas, rollback.
Cada agente que entregamos é construído com RAG (retrieval-augmented generation) ancorado em uma base de conhecimento real do cliente, indexada em vector DB — Postgres com pgvector quando o volume permite e o cliente já tem Postgres, Pinecone quando a operação justifica o custo gerenciado. O retrieval é o que ancora o agente na realidade do cliente; sem ele, o LLM responde fluentemente sobre coisas que não existem.
Em cima do retrieval, montamos guardrails customizados: regex para PII, validação de saída via JSON schema quando a tarefa exige estrutura, classificadores de intenção que decidem se a query sequer deve passar para o LLM. Quando a IA não tem confiança suficiente, o sistema cai pra um caminho determinístico — uma busca por keyword, uma resposta canned, ou handoff direto pro humano. Isso é o que chamamos de fallback determinístico, e é o que separa um agente confiável de uma roleta russa.
Por fim, observability nativa desde o dia um. Usamos LangSmith quando o cliente tem orçamento e quer dashboards prontos; usamos OpenTelemetry com sinks customizados quando o cliente quer instrumentação interna. O que não negociamos é a existência de traces ponta a ponta: cada prompt, cada chamada de ferramenta, cada token gasto fica registrado e auditável.
Stack que usamos em produção hoje
Modelos: Anthropic Claude (Sonnet e Opus) quando precisamos de raciocínio longo, tool use confiável e contexto extenso; OpenAI GPT-4o e GPT-4o-mini quando o custo por chamada importa mais que profundidade; modelos open-source via vLLM ou Ollama quando o cliente exige inferência on-premise por compliance. A escolha é por tarefa, não por preferência de marca.
Orquestração: LangChain quando a complexidade justifica (multi-agente, ferramentas heterogêneas, branching condicional); código TypeScript direto chamando o SDK quando a tarefa é linear e LangChain só adicionaria abstração desnecessária. Não usamos framework por status. Usamos quando vale.
Vector DBs: Postgres com pgvector é o default — mantém a base junto do resto dos dados do cliente, sem mais um serviço pra operar. Pinecone, Weaviate ou Qdrant entram quando o volume passa de algumas dezenas de milhões de embeddings ou quando o cliente quer latência sub-50ms em retrieval. Deploy em Coolify quando o cliente já está nessa stack; AWS, GCP ou Azure quando o cliente exige cloud específica.
O que vai (e o que não vai) entregar valor
Vamos ser diretos: IA generativa não substitui sistemas determinísticos onde precisão é crítica. Não escreva um motor de cálculo fiscal com LLM. Não use agente conversacional pra aprovar crédito sozinho. Não delegue decisão regulada (saúde, jurídico, financeiro estrito) a uma rede neural sem revisão humana.
Onde IA generativa entrega valor real: triagem e classificação semântica de tickets ou documentos (mover trabalho de etiquetagem manual para algo automático, com humano só nos casos de baixa confiança); redação assistida (gerar primeira versão de respostas, e-mails, descrições — humano edita em vez de escrever do zero); busca semântica em bases grandes de conhecimento interno (achar o documento certo entre dez mil); automação de tickets recorrentes (resolver os 60% de tickets que são variação dos mesmos cinco problemas, escalar o resto).
A regra que usamos pra decidir: se 5% a 15% de ganho de eficiência em volume alto é significativo pra operação e o erro pode ser revisado por humano antes de ter consequência, IA generativa cabe. Se cada saída precisa ser exata e o custo de erro é alto e silencioso, não cabe — pelo menos não sem camadas pesadas de validação.
Propriedade · tudo no seu nome
O agente, os prompts, a base vetorial e a infraestrutura são entregues sob o seu controle total. Você não aluga inteligência — é dono dela. Repositório, infraestrutura como código e documentação ficam no seu nome desde o primeiro dia, sem vendor lock-in.
Próximo passo
O diagnóstico que abrimos é uma conversa de 30 minutos onde mapeamos um fluxo específico da sua operação e respondemos uma pergunta só: agentes de IA cabem aqui, em qual ponto, e qual é o ganho realista? Saímos da conversa com uma resposta clara — sim, não, ou "sim mas com pré-requisitos X e Y antes". Sem proposta de 40 páginas. Sem PowerPoint.
Veja também
Diagnóstico de viabilidade de agentes de IA
Mapeamos onde IA generativa cabe (e onde não cabe) no seu fluxo atual em 1 chamada de 30 min — sem proposta inflada nem POC eterno depois.