Engenharia de qualidade e 80% do deploy de agentes de IA
50+ padroes de detecção de lixo, scoring de conteúdo de 0.0 a 1.0 e tres reescritas de um daemon jurídico.
Estamos construindo sistemas autônomos de IA que operam funções de negócio completas. Não copilots. Não chatbots. Sistemas que executam backlogs de pesquisa de 37 tarefas, tomam decisões de roteamento e operam com orçamentos de $20/dia sem um humano vigiando. A parte que mais demora não e construir esses sistemas. E fazer com que parem de produzir lixo.
A engenharia de qualidade de agentes de IA consome aproximadamente 80% do nosso tempo de deploy. A logica do agente, o design de prompts, o encanamento de integracoes — tudo isso e os 20% faceis. O restante do calendário vai para construir sistemas que detectem quando um agente produziu algo inutil e impecam que seja tratado como trabalho real.
Veja como isso se parece na prática.
As tres reescritas
Nosso daemon de pesquisa jurídica e um sistema de 10 agentes rodando como aplicacao Flask em um VPS da DigitalOcean. Gerencia um backlog de tarefas de pesquisa jurídica para um venture de legal tech equatoriano. 10 agentes, 4 configuracoes de equipe, ciclos de sprint autônomos, teto de orçamento de $20/dia. Estamos na terceira versão maior da camada de qualidade. Cada reescrita aconteceu porque descobrimos uma nova categoria de falha que a versão anterior não capturava.
Versão 1: Sem gates de qualidade. Apontamos 10 agentes para um backlog de pesquisa e deixamos rodar. O output era tecnicamente fluente e substantivamente inutil. Os agentes produziam analises juridicas de 2.000 palavras com terminologia correta organizada em padroes sem sentido. Um agente escreveu uma “analise de mercado” detalhada que na verdade era uma reformulacao de suas proprias instruções, preenchida com observacoes genéricas sobre o setor de legal tech. Não conseguiamos distinguir isso de trabalho real escaneando o output rapidamente. Lia-se bem. Não dizia nada.
Versão 2: Validacao basica de output. Adicionamos verificacoes para as falhas obvias: respostas vazias, recusas explicitas (“Como IA, não posso…”), texto placeholder. Isso capturou os 20% piores do lixo mas introduziu um novo problema. Começamos a chamar de “lixo sofisticado”: outputs que passavam verificacoes superficiais mas não continham informação real. Um agente produzia uma analise competitiva bem formatada com cabecalhos, bullet points e números percentuais, onde cada percentual era inventado e cada nome de empresa era real mas as afirmacoes sobre elas eram fabricadas.
Versão 3: Controle de qualidade de tres camadas. Isso e o que roda em produção agora. Captura o lixo sofisticado que a versão 2 deixava passar.
Cada reescrita adicionou aproximadamente uma semana de tempo de desenvolvimento. O esforco total de engenharia de qualidade neste único sistema excede o tempo gasto na logica dos agentes, na camada de integração e na infraestrutura de deploy combinados.
50+ padroes de detecção de lixo
A primeira camada do nosso sistema de qualidade e detecção de lixo baseada em padroes. Mantemos uma lista de 50+ padroes de strings que indicam que o agente falhou em produzir output util. Cada padrão foi adicionado após uma falha especifica em produção. Nenhum foi previsto antecipadamente.
Os padroes caem em seis categorias.
Meta-comentario. O agente descreve o que faria em vez de fazer. Padroes incluem: “let me search,” “I will now proceed,” “below is the plan for executing,” “I’ll attempt to,” “I need to search.” São particularmente comuns quando agentes rodam em modo somente-sintese (sem acesso a ferramentas ao vivo) e não foram instruidos com firmeza suficiente para trabalhar a partir do contexto em vez de solicitar acoes externas.
Resultados de busca vazios. O agente reporta não encontrar nada e apresenta esse relatório como seu entregavel. Padroes: “no results found,” “could not find,” “unable to find,” “search returned no,” “no data available,” “returned 0 results.” Vemos isso quando agentes recebem instrucao de pesquisar um topico mas a janela de contexto não contem material relevante.
Recusas e limites de capacidade. O agente se recusa a fazer o trabalho. Padroes: “as an AI,” “as a language model,” “I cannot access,” “outside my capabilities,” “I’m unable to.” Essas são as falhas mais obvias mas ainda representam aproximadamente 10% dos outputs bloqueados.
Confusao de ferramentas e funções. O agente tenta invocar ferramentas que não existem em seu contexto de execução atual. Padroes: “function call,” “tool_call,” “function_call,” “```tool_code.” Isso acontece quando executamos agentes com tools=[] (modo somente-sintese) e os dados de treinamento do agente sobrescrevem suas instruções.
Planejamento sem acao. O agente produz um plano para trabalho futuro em vez de output real. Padroes: “the next step would be,” “the following steps should,” “we would need to,” “this would involve.” Esta e a categoria mais comum. Agentes caem por padrão em planejamento quando estão incertos.
Reclamacoes de permissao. O agente explica que não tem permissoes para completar a tarefa. Padroes: “I need write permissions,” “what I would accomplish,” “what I would deliver,” “given the constraints,” “if I had access.” Vemos esses quando agentes encontram uma tarefa que interpretam como exigindo acesso a sistema de arquivos ou API que não possuem.
A função de detecção e direta: qualquer output menor que 50 caracteres e automaticamente lixo. Para todo o resto, converter o texto para minusculas e verificar coincidencias de substrings contra a lista de padroes. Se qualquer padrão coincidir, o output e rejeitado.
def _is_garbage_output(text: str) -> bool:
if not text or len(text.strip()) < 50:
return True
lower = text.lower()
return any(p in lower for p in GARBAGE_PATTERNS)Isso captura aproximadamente 30% dos outputs ruins. Os 70% restantes das falhas de qualidade são lixo sofisticado que requer o sistema de scoring.
Scoring de conteúdo: 0.0 a 1.0
Cada output que passa a camada de detecção de lixo recebe uma nota em escala de 0.0 a 1.0. Qualquer coisa abaixo de 0.4 e rejeitada. O algoritmo de scoring e deliberadamente simples porque precisamos que seja previsivel e debugavel.
Nota base: 0.3. Qualquer conteúdo que existe e tem mais de 30 palavras começa em 0.3. Abaixo de 30 palavras, a nota e 0.1 independente do conteúdo.
Bonus por contagem de palavras: ate +0.2. Conteúdo com 100+ palavras recebe +0.1. Conteúdo com 300+ palavras recebe mais +0.1. Isso recompensa output substantivo sem exigir um comprimento específico.
Marcadores de substancia: ate +0.3. Verificamos seis tipos de conteúdo concreto: valores em dolar ($[\d,.]+), percentuais (\d+%), URLs (https?://), datas (\d{4}[-/]\d{2}), formatação de tabela (|...|), e cabecalhos estruturados (^#{1,3}\s). Cada marcador encontrado soma 0.05, com teto em 0.3. Isso recompensa outputs que contem informação especifica e verificavel em vez de prosa abstrata.
Penalidade por planejamento: -0.15. Se o output contem 3 ou mais frases de planejamento (“we should,” “the plan is,” “recommend that we,” “steps to take,” “action items include”), recebe penalidade. Um output cheio de recomendacoes sobre o que fazer a seguir e menos valioso que um output que faz o trabalho.
A função de scoring retorna tanto a nota numerica quanto uma string de razao legivel por humanos. Quando um output e rejeitado, o log mostra exatamente por que: “too short (28 words)” ou “planning-heavy (4 phrases)” ou “baseline” (significando que passou o limiar de 0.4 apenas por contagem de palavras e marcadores de substancia).
O limiar de 0.4 foi calibrado empiricamente. Pontuamos 200 outputs historicos manualmente, marcando cada um como “util” ou “lixo.” 0.4 produziu a melhor separacao. Abaixo de 0.35, estavamos rejeitando alguns outputs curtos mas uteis. Acima de 0.45, estavamos aceitando algum lixo sofisticado.
No nosso motor de produção de conteúdo, estamos testando um sistema de scoring mais agressivo para artigos de blog. Esse verifica especificidade (números, valores em dolar, datas), compliance de anti-padroes de IA (vocabulario proibido, punchlines com em-dash, justaposicao desnecessaria), otimizacao de keywords, consistencia de voz e acionabilidade. Artigos recebem nota em um composto ponderado e são rejeitados abaixo de 0.7. Tivemos artigos que falharam apenas na verificação de compliance anti-IA, o que dispara uma passada de revisao com instruções explicitas sobre o que corrigir.
O teto de tentativas
Ambas as camadas alimentam um mecanismo de tentativas. Quando um output falha na qualidade (seja detecção de lixo ou scoring abaixo de 0.4), a tarefa volta ao status “pending” e e tentada novamente no próximo ciclo de sprint. Mas limitamos as tentativas a 3. Após 3 outputs lixo para a mesma tarefa, a tarefa fica permanentemente bloqueada e marcada para revisao humana.
Este e o mecanismo de protecao de orçamento. Sem o teto de tentativas, o sistema gastaria chamadas de API ilimitadas em tarefas que fundamentalmente não consegue completar. Vimos tarefas falharem 3 vezes porque a janela de contexto não tinha o material fonte necessário, porque a descricao da tarefa era ambigua, ou porque a tarefa exigia dados em tempo real que o sistema não conseguia acessar em modo somente-sintese.
Das 37 tarefas no nosso backlog de pesquisa jurídica, 33 foram concluídas com sucesso. As 4 que bloquearam estavam todas na categoria de financiamento, aguardando timelines de grants externos. Nenhuma das 4 foi bloqueada por falhas de gate de qualidade. Mas vimos outros deploys onde 15-20% das tarefas atingem o teto de tentativas. O percentual depende de quao bem as tarefas do backlog correspondem as capacidades reais do agente.
Separacao de papeis
O segundo sistema de qualidade que operamos em produção e estrutural: o agente que escreve nunca pode ser o agente que revisa.
Aprendemos isso dos nossos research systems. Operamos 6 agentes em tres areas de pesquisa (economia latino-americana, governança de IA, IA e crypto) com 16 skills personalizados e um pipeline de controle de qualidade de 4 gates. Os gates rodam em sequencia estrita: verificação de fontes, checagem de voz, revisao adversarial, aprovação de publicação. Cada gate e de responsabilidade de um agente diferente.
O research-analyst escreve rascunhos. O source-reviewer verifica cada citacao por precisao, relevancia, frescor dos dados e compliance de formato. O quality-controller executa revisoes adversariais, auditorias de voz e toma a decisão final de publicação. Esses tres papeis são implantados como instancias de agente separadas com system prompts separados, memória separada e acesso a ferramentas separado.
Quando implantamos o research system pela primeira vez, o mesmo agente escrevia analises e as revisava. O agente aprovava seu proprio trabalho toda vez. As revisoes eram um paragrafo de elogios seguido de “aprovado para publicação.” Pegamos isso depois que um artigo mal referenciado passou pelo pipeline com citações fabricadas que o agente escritor descreveu como “verificadas” na sua propria revisao.
A separacao e aplicada no nivel do pipeline. As instruções do source-reviewer dizem explicitamente: “Você revisa fontes. Você não escreve rascunhos.” As instruções do quality-controller comecam com: “Você nunca produz conteúdo de pesquisa original. Você testa, quebra e decide se publica.” Quando um rascunho precisa de reescrita, o quality-controller o devolve ao research-analyst com instruções especificas. O quality-controller identifica problemas. Não os corrige.
Isso espelha como departamentos de pesquisa que funcionam bem operam. A pessoa que escreve o relatório não assina seu proprio fact-checking. A diferença e que com agentes de IA, a tentacao de colapsar esses papeis e mais forte porque e “a mesma tecnologia.” A tecnologia não importa. A estrutura de incentivos importa. Um revisor que produziu o trabalho original tem toda razao para aprova-lo.
O pipeline de qualidade de 4 gates
Para nossos research systems, o pipeline de qualidade tem quatro gates sequenciais. Uma falha de gate para o pipeline. O conteúdo não pode pular gates nem passa-los fora de ordem.
Gate 1: Verificação de fontes. Cada citacao usa formato de hyperlink inline. Cada URL e buscada e confirmada ativa. Cada estatistica e rastreada ate uma fonte de Nivel 1-3 (legislação primaria, pesquisa peer-reviewed ou relatorios institucionais). Não restam tags de [CITATION-NEEDED] ou [NEEDS-VERIFICATION]. O agente source-reviewer executa esse gate usando WebFetch para verificar cada URL e WebSearch para buscar dados mais recentes.
Gate 2: Checagem de voz. Nota de autenticidade de 4 ou mais em cinco dimensoes: variacao de comprimento de paragrafo, variacao de comprimento de frase, uniformidade de template, especificidade e tomada de posicao. Zero vocabulario proibido. Zero tells estruturais de IA. Mantemos uma lista de anti-padroes: punchlines com em-dash, justaposicao desnecessaria “não X, mas Y”, triades com terceiro item escalatorio, paragrafos abstratos sem detalhe concreto, hedging genérico (“vale a pena notar,” “curiosamente”), linguagem sensorial falsa (“solução robusta,” “plataforma seamless”), e callbacks forcados. A checagem de voz executa scans programaticos (Grep contra a lista proibida) e avaliacao baseada em LLM para os padroes mais sutis.
Gate 3: Revisao adversarial. O quality-controller executa uma passada de red team em cinco dimensoes: precisao factual, coerencia logica, vies de selecao, scope creep e contraargumentos steelman. Para cada afirmação maior, o agente escreve o contraargumento mais forte que consegue encontrar, respaldado por fontes reais (não objecoes hipoteticas). Depois executa um pre-mortem: “Se esta pesquisa estiver errada em 2 anos, as razoes mais provaveis são…” Cada desafio deve ser abordado no texto ou documentado na secao de limitacoes.
Gate 4: Publicação. Os gates 1-3 passam. O formato corresponde ao template de output. Os metadados estão completos. A entrada de catalogo esta preparada. Tags de relevancia cross-equipe são adicionadas para que as descobertas sejam encontraveis por outras areas de pesquisa.
O sistema de 4 gates adiciona 2-3x o tempo por documento comparado com um fluxo de escrever-e-publicar. Consideramos isso o custo de não publicar lixo. Nossa pesquisa cobre topicos relevantes para política publica onde uma citacao fabricada pode desacreditar meses de trabalho.
Lista de anti-padroes vs. instruções positivas
Uma descoberta contraintuitiva de construir esses sistemas: instruções negativas funcionam melhor que positivas.
Dizer a um agente “escreva naturalmente” produz output genérico. Dizer a um agente “não use punchlines com em-dash, não use justaposicao desnecessaria, não use triades com terceiro item escalatorio, não use frases de hedging genérico incluindo ‘vale a pena notar’ e ‘curiosamente’” produz escrita mensuravelmente melhor. O agente precisa de exemplos concretos do que evitar.
O mesmo se aplica a detecção de lixo. Dizer a um agente “produza output substantivo” não previne respostas em modo planejamento. Listar 50 padroes específicos que constituem lixo sim. Cada padrão na nossa lista existe porque um agente produziu exatamente essa falha em produção.
Mantemos uma lista de “palavras proibidas” para nosso motor de conteúdo com 19 entradas: “leveraging synergies,” “disrupting,” “delve,” “utilize,” “game-changer,” “paradigm shift,” “move the needle,” “cutting-edge,” “state-of-the-art,” “revolutionary,” entre outras. Também mantemos padroes regex para anti-padroes de IA: punchlines com em-dash seguidos de revelacoes dramaticas, triades com terceiro item escalatorio, frases de hedging genérico. Artigos que correspondem a qualquer padrão são marcados para revisao.
O overhead de manter essas listas e modesto. Adicionamos 2-3 padroes novos por semana ao descobrir novos modos de falha. O ROI e alto porque cada padrão previne uma classe de falha em vez de uma única instancia.
O que isso custa
A camada de engenharia de qualidade adiciona aproximadamente 35-40% ao custo de API de um deploy. Para o daemon jurídico rodando a $20/dia maximo, as verificacoes de qualidade (detecção de lixo + scoring de conteúdo + ciclos de tentativa) representam aproximadamente $7-8 desse orçamento. Os agentes quality-controller e source-reviewer no nosso research system consomem aproximadamente 30% do total de tokens.
Consideramos isso um bom tradeoff. A alternativa e publicar lixo, que custa mais em retrabalho, reputacao e confiança do cliente do que o gasto de API em prevencao.
O custo humano e mais significativo. A engenharia de qualidade e 80% do calendário de desenvolvimento para um novo deploy. Para o daemon jurídico, isso significou 3 reescritas completas da camada de qualidade nas primeiras 2 semanas de operação. Para o research system, significou 7 dias de um sprint de construcao de 10 dias dedicados a documentos de padroes, gates de qualidade, separacao de agentes e testes. Para o motor de conteúdo, significou construir um sistema de scoring com 5 dimensoes ponderadas e um pipeline de revisao antes de escrever um único artigo.
Se sua consultoria de IA mostra um demo e chama de deploy, procure outra consultoria. O demo e os primeiros 20%. A engenharia de qualidade que torna seguro operar sem supervisao e os outros 80%.
A Synaptic transforma empresas em organizações AI-native. Começamos onde o demo termina. synaptic.so