Prova de Deploy

O que aprendemos operando 35 agentes de IA em produção

10 sistemas, 90+ papeis de agentes, 13.570 linhas de Python. O que funciona, o que quebra e o que fariamos diferente.

No ano passado, a Odisea — o laboratório de tecnologia por tras da Synaptic — parou de aconselhar clientes sobre IA e comecou a usa-la para operar sua propria organizacao. Não como prova de conceito. Não como hackathon de fim de semana. Como a infraestrutura operacional real de uma organizacao multi-unidade que abrange produção de podcasts, pesquisa jurídica, operacoes de vendas, parcerias institucionais e pesquisa acadêmica em seis países.

Doze meses depois, temos 90+ papeis de agentes definidos em 10 sistemas distintos, 13.570 linhas de Python em produção e cicatrizes suficientes para saber o que funciona, o que falha e o que a indústria de consultoria entende errado sobre automação empresarial.

Isso e o que aprendemos.

A Configuracao

A Odisea opera seis unidades de negócio: uma rede de podcasts (La Odisea), uma prática de tecnologia jurídica, uma operação de vendas DeFi (Pan.Tech), um laboratório de infraestrutura aberta (ODIL), uma divisao de pesquisa cobrindo governança de IA e economia latino-americana, e a propria Synaptic. Cada unidade tem seu proprio pipeline, seus proprios stakeholders e seu proprio ritmo operacional.

Em vez de contratar uma equipe de operacoes tradicional, construimos sistemas de agentes de IA para cada unidade. Não chatbots. Não copilots. Sistemas autônomos que executam fluxos de trabalho de múltiplas etapas, tomam decisões de roteamento, reportam resultados e escalam apenas quando atingem os limites de sua autoridade.

Isso e o que esta rodando em produção agora:

Legal Tech Daemon: 10 agentes especializados gerenciando um backlog de 37 tarefas de pesquisa jurídica para direito equatoriano. Os agentes incluem um engenheiro de corpus, arquiteto de produto, especialista em compliance, pesquisador de mercado e especialista de domínio. O sistema executa ciclos de sprint autônomos com gates de qualidade, scoring de conteúdo e um teto orcamentario de $20/dia. 33 de 37 tarefas concluídas sem intervenção humana.

Penelope: Um agente pessoal de IA gerenciando a produção de podcasts. Monitora email, redige respostas com aprovação humana via Slack, pesquisa convidados, gerencia agenda via calendário e rastreia o pipeline pelo Notion. 14 ferramentas, polling a cada 5 minutos.

Pan.Tech Sales Pipeline: 7 agentes especialistas gerenciando 92+ prospects em um CRM no Notion, lidando com inteligência competitiva, acompanhamento de reuniões e action items para um produto de API DeFi.

Research Systems: 6 agentes em tres areas de pesquisa (Dinamismo Latino-Americano, Governança de IA, IA & Crypto) com 16 skills personalizados e controle de qualidade de 4 gates: verificação de fontes, checagem de voz, revisao adversarial, aprovação de publicação.

Ventures / Founder Factory: O sistema mais complexo. Forneca uma ideia de negócio e ele gera uma estrutura completa de empresa com ~35 agentes em 10 departamentos, memória de 4 camadas, provisionamento de infraestrutura para 9 plataformas (Cloudflare, DigitalOcean, GitHub, Vercel, HubSpot, PostHog, Resend, Crisp) e um daemon de operação autônomo. A propria Synaptic foi gerada por essa fabrica.

Lição 1: O difícil não e construir o agente

Construir um único agente de IA e trivial. Qualquer desenvolvedor competente consegue conectar um LLM a um conjunto de chamadas de API em um fim de semana. O difícil e tudo que acontece depois do demo.

Controle de qualidade. Gestao de custos. Recuperacao de erros. Persistencia de contexto entre sessoes. Coordenacao entre agentes que compartilham um fluxo de trabalho mas tem objetivos diferentes. Degradacao controlada quando uma API upstream cai. Escalação humana que não vire gargalo.

Nosso Legal Daemon passou por tres reescritas maiores antes de parar de produzir lixo. A primeira versão não tinha gates de qualidade. Os agentes geravam analises juridicas de 2.000 palavras com conteúdo que soava convincente mas era absurdo: terminologia jurídica correta organizada em padroes sem sentido. Construimos 50+ padroes de detecção de lixo (verificando definicoes circulares, conclusoes sem sustentacao e linguagem de placeholder que soa autoritativa) e um sistema de scoring de conteúdo que rejeita qualquer coisa abaixo de um limiar de qualidade de 0.4. Adicionamos um teto de 3 tentativas por tarefa, após o qual a tarefa e marcada como bloqueada em vez de regenerar lixo indefinidamente.

A lição: desenvolvimento de agentes e 20% construcao e 80% engenharia de qualidade. Se sua consultoria de IA mostra um demo e chama de deploy, procure outra consultoria.

Lição 2: Coordenacao multi-agente e um problema de design organizacional

Quando implantamos os Research Systems, inicialmente o mesmo agente escrevia analises e as revisava. O resultado era previsivel: o agente aprovava seu proprio trabalho automaticamente. Bastou uma publicação vergonhosa de um artigo mal referenciado para instituirmos uma regra rigida: o agente que escreve nunca pode ser o agente que revisa.

Isso não e uma restricao técnica. E um principio de design organizacional que se aplica a software. Terminamos com um pipeline de tres estagios (o research-analyst redige, o source-reviewer verifica citações, o quality-controller executa revisao adversarial) que espelha como um departamento de pesquisa bem gerido opera. Os agentes tem separacao de responsabilidades não porque o framework exige, mas porque handoffs descuidados produzem trabalho descuidado independente de o trabalhador ser humano ou artificial.

A Ventures factory leva isso adiante. Cada empresa gerada recebe 10 departamentos com ativacao por fases. Durante validacao, apenas Estrategia, Vendas e Marketing estão ativos. Produto e Engenharia entram na fase de construcao. Customer Success e Operacoes ativam no lancamento. Finanças e Talentos na escala. Não projetamos isso por elegancia técnica. Projetamos porque ativar todos os 35 agentes desde o primeiro dia cria um pesadelo de coordenacao onde agentes geram trabalho para departamentos que ainda não tem razao de existir.

A lição: as melhores arquiteturas multi-agente se inspiram na teoria organizacional, não em papers de sistemas distribuidos. A Lei de Conway se aplica a agentes de IA tanto quanto a equipes de engenharia.

Lição 3: Controles de orçamento não são opcionais

Nosso Legal Daemon tem um teto fixo de $20 por dia em custos de API de LLM. A Ventures factory rastreia o uso de tokens por departamento e pausa sprints quando o orçamento diário e excedido. Cada sistema que implantamos tem visibilidade de custos integrada na camada de relatorios.

Isso parece obvio. Não e prática padrão no mundo de consultoria de IA.

Por que importa: a diferença entre um sistema de IA util e um passivo financeiro frequentemente e um único loop descontrolado. Um agente que encontra uma tarefa ambigua e tenta indefinidamente pode queimar centenas de dolares em custos de API em horas. Um sistema multi-agente onde agentes se acionam mutuamente sem amortecimento pode criar cascatas de custo exponenciais.

Aprendemos isso da forma cara quando uma versão inicial do nosso pipeline de pesquisa entrou em um ciclo onde o agente analista continuava revisando seu output com base no feedback do agente revisor, cada revisao disparando uma nova revisao, cada revisao gerando novas sugestoes de revisao. Doze iteracoes depois, o output era pior que o rascunho original e tinhamos gasto 40x o orçamento de compute esperado.

Agora cada agente tem: um numero maximo de tentativas (geralmente 3), um limite de orçamento por sprint e um circuit breaker que marca a tarefa como bloqueada em vez de continuar gastando dinheiro. A Ventures factory vai alem com uma alocacao de orçamento por departamento que consolida em um teto diário no nivel da empresa.

Lição 4: A memória e o diferencial competitivo

O componente mais subestimado em todo nosso stack e o sistema de memória. A Ventures factory usa uma arquitetura de 4 camadas: memória episódica (SQLite para registrar o que aconteceu), memória semântica (arquivos markdown para capturar o que sabemos), memória procedural (playbooks para codificar como fazemos as coisas) e memória estratégica (lições aprendidas mais um diário de decisões para preservar por que fizemos as escolhas que fizemos).

Antes de construir isso, cada sprint de agente começava do zero. Os agentes reinvestigavam topicos que ja tinham analisado. Cometiam os mesmos erros de sprints anteriores. Propunham estrategias que ja tinham sido tentadas e rejeitadas.

Depois de implementar memória persistente, a qualidade do output dos agentes melhorou de forma mensurável. Não porque os agentes ficaram mais inteligentes, mas porque pararam de desperdicar ciclos redescobrindo o que ja tinham aprendido. Os research systems agora mantem um indice compartilhado de descobertas e um catalogo de trabalhos publicados. Quando um research-analyst inicia uma nova analise, primeiro consulta o que a organizacao ja sabe sobre o topico.

Para nosso deploy do OpenClaw, usamos QMD (um sistema de retrieval que combina busca por keywords BM25 com embeddings vetoriais e reranking) que auto-indexa o workspace a cada 5 minutos. O resultado e um agente que acumula conhecimento institucional da mesma forma que um funcionario veterano, exceto que nunca esquece e consegue recuperar contexto relevante em milissegundos.

Isso tem implicacoes diretas para consultoria: quando implantamos sistemas de agentes para clientes, o valor se acumula ao longo do tempo. Um sistema implantado ha 6 meses e significativamente melhor que o mesmo sistema no primeiro dia, porque acumulou contexto sobre o negócio do cliente que um novo funcionario levaria semanas para absorver.

Lição 5: A camada de integração consome a maior parte do calendário

Se me pedissem para estimar a distribuicao de tempo para um deploy tipico de agentes, seria assim:

  • Entender o fluxo de trabalho existente do cliente: 25%
  • Construir integracoes com as ferramentas (Slack, email, CRM, Google Workspace, Notion, APIs customizadas): 40%
  • Logica de agentes e engenharia de prompts: 15%
  • Gates de qualidade, monitoramento e tratamento de erros: 15%
  • Testes e handoff: 5%

Quarenta por cento do trabalho e encanamento. Não porque integração seja inerentemente difícil, mas porque ferramentas de negócio reais tem peculiaridades, rate limits, fluxos de autenticacao e comportamentos não documentados que so se descobrem em produção.

Nossa integração com o Notion, por exemplo, tem dois caminhos de autenticacao separados porque um deles falha intermitentemente com erros de “Invalid refresh token”. Nossa integração com o Slack roteia por duas identidades de bot diferentes (Penelope para uso pessoal, Ulises para operacoes) porque misturar as duas cria confusao sobre quem esta dizendo o que. A integração com o Google Workspace exigiu uma configuracao completa de servidor MCP (Model Context Protocol) com fluxos OAuth separados para cada servico.

Nada disso e trabalho glamoroso. E onde a maioria dos projetos de “transformação com IA” realmente empaca. A consultoria mostra um demo bonito de um agente respondendo perguntas de um dataset de teste, e depois o projeto morre em um pantano de problemas de autenticacao de API e incompatibilidades de formato de dados.

Lição 6: Humanos no loop precisam de pontos de contato projetados

Penelope, nosso agente de produção de podcasts, tem um sistema de human-in-the-loop que funciona assim: quando o agente redige uma resposta de email, posta o rascunho no Slack com tres botoes (Aprovar, Rejeitar, Editar). O humano revisa o rascunho e toma uma decisão. O agente so envia o email após aprovação explicita.

Isso funciona porque a interacao e projetada em torno de uma decisão especifica em um momento específico. O humano não precisa supervisionar a pesquisa ou o raciocínio do agente. So precisa responder uma pergunta: “Esse email esta pronto para enviar?”

Compare isso com sistemas de agentes que expoem cada passo intermediario para revisao humana. Tentamos isso com o Legal Daemon no inicio. O orquestrador postava o output de cada agente em um canal do Slack para revisao antes de passa-lo ao próximo agente. Em dois dias, o canal de revisao tinha 200+ mensagens não lidas e ninguém lia. A supervisao humana virou carimbo automatico.

A lição: supervisao humana funciona quando esta concentrada em pontos de decisão de alto impacto e e invisivel em todo o resto. Cada solicitacao de aprovação que não e genuinamente importante dilui as que são.

Lição 7: Comece com um agente, não com dez

A Ventures factory pode gerar 35 agentes em 10 departamentos. Quando realmente implantamos para um negócio, Começamos com um. Um único agente fazendo uma tarefa bem definida dentro de um departamento.

Nossa estrutura de piloto reflete isso: um engagement Starter ($5K, 2 semanas) implanta um agente com uma integração. Um engagement Growth ($10K, 4 semanas) expande para 3-5 agentes cobrindo um fluxo de trabalho de ponta a ponta. Enterprise ($15K, 6 semanas) abrange 2-3 departamentos.

Isso não e uma tatica de vendas. E uma lição da nossa propria experiencia. Quando tentamos implantar múltiplos sistemas simultaneamente, a superficie de debugging cresceu exponencialmente. Quando um agente falhava, era difícil determinar se o problema estava na logica do agente, na integração, nos dados upstream ou em uma falha em cascata de outro agente.

Comecar com um agente, leva-lo a qualidade de produção e depois expandir e mais rápido do que implantar tudo de uma vez e passar semanas debugando interacoes entre sistemas meio construidos.

O que isso significa para as empresas

O mercado de consultoria de IA esta projetado para atingir $24,6 bilhões globalmente este ano, com o mercado de IA na América Latina crescendo a 22% ao ano em direcao a uma projecao de $34,6 bilhões ate 2034. O mercado de agentes especificamente (sistemas que atuam de forma autônoma, não apenas respondem a prompts) deve crescer de $7,84 bilhões para $52,6 bilhões ate 2030.

A maior parte do que e vendido como “transformação com IA” ainda são apresentacoes e provas de conceito. As Big Four cobram $500K+ por engagements que levam 6-18 meses. As plataformas de agentes de IA vendem ferramentas self-serve que exigem que o cliente construa tudo sozinho. Os engenheiros freelance de IA entregam código sem infraestrutura operacional.

O que falta e o meio-termo: firmas que realmente implantam sistemas autônomos, a preços de mid-market, com a maturidade operacional para mante-los funcionando.

Foi isso que construimos para nos mesmos. Cada sistema neste artigo e código de produção rodando em infraestrutura real, processando dados reais, produzindo resultados de negócio reais. O Legal Daemon completou 33 de 37 tarefas de pesquisa atribuidas. O sales pipeline gerencia 92+ prospects ativos. Os research systems produzem analises prontas para publicação com controle de qualidade de quatro gates.

Não construimos esses sistemas para impressionar ninguém. Construimos porque precisavamos deles. E o fato de que funcionam, com toda a engenharia de qualidade bagunzada e pouco glamorosa que “funcionar” requer, e o argumento mais forte que podemos fazer sobre como a automação com IA realmente se parece quando se passa do demo.


A Synaptic transforma empresas em organizações AI-native. Começamos onde o demo termina. synaptic.so