O humano no loop não e rede de seguranca. E uma decisão de arquitetura.

O agente prepara. O humano aprova. O agente executa.

Esse loop de tres passos parece simples. Na prática, a maioria das equipes erra de uma de duas formas. Ou removem o humano completamente e descobrem que o agente enviou um contrato alucinado para um cliente, ou inserem o humano em cada passo e descobrem que ninguém le a 47a notificacao do dia no Slack. Ambos os modos de falha produzem o mesmo resultado: a supervisao humana não esta funcionando.

Estamos construindo sistemas de agentes nas seis unidades de negócio da Odisea neste momento. 90+ papeis de agentes, 10 sistemas distintos, tarefas reais com consequencias reais. Por volta da terceira semana operando nosso daemon de pesquisa jurídica, percebemos que humano-no-loop não e uma feature que se adiciona no final. E uma decisão estrutural que determina se o sistema inteiro funciona ou gera ruido caro.

Este e o framework que estamos usando.

Tres Níveis de Autoridade

Cada acao de agente nos nossos sistemas cai em um de tres níveis. A atribuicao de nivel acontece em tempo de design, não em tempo de execução. O agente não decide quanta supervisao precisa. O arquiteto decide.

T1: Autônomo. O agente executa e registra. Nenhum humano ve o output antes de surtir efeito. O agente registra o que fez, e alguem pode revisar o log depois se quiser. A maioria dos agentes passa a maior parte do tempo aqui.

Exemplos dos nossos sistemas em produção: um agente de pesquisa extraindo dados de mercado de fontes publicas. Um engenheiro de corpus indexando documentos juridicos. Um job de consolidação de memória fundindo as descobertas da semana em arquivos por categoria. Um agente de métricas calculando gasto diário contra tetos de orçamento.

Os criterios para classificacao T1: a acao e reversivel, o raio de impacto se limita a estado interno, e o custo de um erro se mede em compute desperdicado em vez de relacionamentos danificados ou dinheiro perdido.

T2: Notificar. O agente executa e informa. A acao acontece imediatamente, mas um humano recebe uma notificacao estruturada mostrando o que aconteceu e por que. O humano pode intervir após o fato se algo parecer errado.

Exemplos: um agente de outreach enviando um email de primeiro contato para um prospect a partir de um template pre-aprovado. Um agente de vendas atualizando um estagio do pipeline de CRM. Um agente de conteúdo publicando um rascunho em uma fila de revisao interna. Um agente de monitoramento sinalizando que um limiar de orçamento foi excedido.

Os criterios para T2: a acao tem visibilidade externa ou afeta um fluxo de trabalho compartilhado, mas o custo de uma única execução ruim e baixo e corrigivel em horas.

T3: Esperar. O agente redige e aguarda aprovação humana explicita antes de qualquer coisa acontecer. Este e o único nivel onde o agente esta bloqueado por uma decisão humana.

Exemplos: enviar uma proposta para um cliente. Contratar um servico pago. Publicar conteúdo no site da empresa. Modificar um schema de banco de dados de produção. Responder um email de um prospect que fez uma pergunta que o agente nunca encontrou antes.

Os criterios para T3: a acao e irreversivel ou de alto impacto, o raio de impacto se estende a stakeholders externos, ou o custo de um erro se mede em confiança em vez de tempo.

Por que tres níveis em vez de dois

O instinto da maioria das equipes e binario: ou o agente age sozinho, ou um humano aprova cada acao. O problema com a classificacao binaria e que forca a escolher entre duas opcoes ruins para uma grande categoria de acoes que ficam no meio.

Pegue atualizacoes de CRM. Se você as classifica como T1 (totalmente autônomo), tem um agente que silenciosamente move um deal de “Qualificado” para “Proposta Enviada” sem ninguém saber ate o relatório do pipeline parecer errado. Se classifica como T3 (aprovação humana necessária), tem uma fila de aprovação que trava com 30 mudancas de estagio de pipeline por dia, cada uma trivial, cada uma treinando o humano a clicar “Aprovar” sem ler.

T2 resolve isso. O agente move o estagio do deal imediatamente (porque velocidade importa em operacoes de vendas) e posta um resumo no canal de vendas. Se o movimento estava errado, alguem pega em horas. A acao e visivel sem estar bloqueada.

O modelo de tres níveis também torna a conversa de design concreta. Em vez de debater se um agente “deveria ter supervisao humana” (uma pergunta sem resposta util nesse nivel de abstracao), a equipe pergunta: “Essa acao e reversivel? Qual o raio de impacto? Qual o custo de uma execução errada?” Essas perguntas tem respostas especificas que mapeiam diretamente para T1, T2 ou T3.

O fluxo de aprovação da Penelope

Penelope e nosso agente de produção de podcasts. Monitora email, pesquisa convidados potenciais, redige respostas e gerencia agenda via Notion. O sistema lida com dezenas de interacoes por dia em múltiplas threads de email.

O fluxo de resposta de email dela e uma implementação limpa de T3. Quando Penelope redige um email, posta o rascunho em um canal do Slack com tres botoes: Aprovar, Rejeitar, Editar. O humano le o rascunho, toma uma decisão, e o agente ou envia, descarta ou aguarda uma versão editada.

Isso funciona por uma razao especifica: a solicitacao de aprovação contem exatamente o contexto suficiente para uma decisão e nada mais. A mensagem no Slack mostra o destinatario, o assunto e o texto completo do rascunho. O humano não precisa entender como Penelope encontrou esse email, que queries de busca executou, que rascunhos alternativos considerou ou qual era seu score de confiança. Precisa responder uma pergunta: “Esse email deve sair como esta?”

Também estamos testando um mecanismo de timeout. Se uma solicitacao de aprovação fica no Slack por mais de 4 horas, o sistema a marca como obsoleta e envia um lembrete. Após 24 horas, passa para estado “expirado” e o agente reavalia se a resposta ainda e relevante. O timeout existe porque uma solicitacao de aprovação esquecida e pior do que nenhuma solicitacao. Cria uma falsa sensacao de seguranca: o humano acha que o agente esta esperando, o agente acha que o humano esta revisando, e o email nunca e enviado.

O verificador de aprovacoes roda a cada 15 minutos. E um dos 6 jobs agendados do sistema, e existe porque aprendemos que fluxos de aprovação sem enforcement de timeout viram filas de mensagens mortas.

A falha dos 200 mensagens

Nosso daemon de pesquisa jurídica roda 10 agentes especializados executando sprints de pesquisa contra um backlog de 37 tarefas. No inicio do desenvolvimento, testamos uma versão onde o orquestrador postava o output de cada agente em um canal do Slack antes de passa-lo ao próximo agente no pipeline.

O raciocínio era solido: humanos deveriam revisar outputs intermediarios para pegar problemas de qualidade cedo. Na prática, o canal de revisao acumulou 200+ mensagens em dois dias. Cada mensagem era um output de pesquisa de 500-2.000 palavras. Ninguém lia. O canal virou um muro de texto que as pessoas silenciaram no primeiro dia.

O que aconteceu depois era previsivel. O sistema produziu tres outputs com estatisticas fabricadas que chegaram a um documento de resumo. A “supervisao” humana estava rodando ha 48 horas e não pegou nada, porque os humanos pararam de olhar depois da hora 4.

Substituimos a revisao por output por um sistema de scoring de qualidade: 50+ padroes de detecção de lixo, scoring automatizado de conteúdo em escala 0-1, e um teto de 3 tentativas que bloqueia tarefas em vez de regenerar indefinidamente. A revisao humana passou de “ler cada output” para “revisar tarefas bloqueadas e relatorios semanais de qualidade.” A superficie de revisao caiu de 200+ mensagens por dia para 3-5 itens por semana. Os humanos realmente leem esses 3-5 itens.

A lição: a supervisao humana se degrada em proporcao direta ao seu volume. Cada solicitacao de revisao que não requer genuinamente julgamento humano torna mais difícil para o humano se envolver com as que requerem. A fadiga de alertas não e apenas um problema de monitoramento. E o modo de falha central dos sistemas de humano-no-loop mal projetados.

Projetando pontos de escalação

A pergunta não e “um humano deveria estar envolvido?” A pergunta e “em que ponto específico do fluxo de trabalho o julgamento humano adiciona informação que o agente não tem?”

Para as respostas de email da Penelope, esse ponto e claro: o agente não consegue avaliar completamente se um tom ou fraseado específico vai funcionar com uma pessoa especifica. A calibracao social humana e genuinamente superior aqui.

Para os outputs de pesquisa do daemon jurídico, a resposta e diferente. Um revisor humano adiciona pouco valor lendo uma analise de dimensionamento de mercado que o agente produziu a partir de dados publicos. O agente e mais rápido e mais completo em sintese. Onde o humano adiciona valor e nos criterios de qualidade: decidir se os padroes de detecção de lixo estão capturando as coisas certas, revisar os limiares de scoring, e avaliar tarefas bloqueadas onde o agente explicitamente falhou.

Estamos desenvolvendo um principio a partir disso: a escalação deveria acontecer no ponto de maxima alavancagem humana, não no ponto de maximo conforto humano. A maioria das pessoas se sente mais confortavel revisando cada output. Mas esse conforto vem ao custo da qualidade real da supervisao.

Veja como isso mapeia nos nossos sistemas:

Sistema	Acoes T1	Acoes T2	Acoes T3
Legal Daemon	Sintese de pesquisa, consolidação de memória, tracking de orçamento	Resumos de sprint, alertas de qualidade, notificacoes de tarefas bloqueadas	Decisões GO/NO-GO de kill criteria
Penelope	Monitoramento de email, pesquisa de convidados, parsing de calendário	Atualizacoes de estagio de pipeline, confirmacoes de agenda	Respostas de email, convites para reuniões
Sales Pipeline	Enriquecimento de dados de prospects, coleta de inteligência competitiva	Atualizacoes de pipeline, criacao de action items	Rascunhos de propostas, discussoes de preços
Research Systems	Coleta de fontes, indexacao de citações	Rascunhos de analises, relatorios de verificação de fontes	Aprovação de publicação

Observe o padrão. T1 e tudo que toca estado interno. T2 e tudo que toca fluxos de trabalho compartilhados. T3 e tudo que toca relacionamentos externos ou compromissos irreversiveis. A classificacao se deriva do raio de impacto, e permanece consistente entre sistemas mesmo quando o domínio muda completamente.

A separacao Ulises/Penelope

Operamos dois agentes conectados ao Slack: Penelope (agente pessoal, voltada para fora) e Ulises (operacoes internas, gestao de pipeline, inteligência entre unidades). Compartilham o mesmo workspace do Slack mas tem frameworks de autoridade completamente separados.

Penelope opera majoritariamente em T2 e T3. Suas acoes frequentemente envolvem comunicacao externa, entao quase tudo que faz e notificado ou aprovado. Ulises opera majoritariamente em T1 e T2. Suas acoes são internas: atualizar trackers de pipeline, postar resumos de pesquisa, rotear informação entre unidades de negócio. Raramente precisa de aprovação humana porque seu raio de impacto esta contido dentro da organizacao.

Essa separacao existe porque os níveis de autoridade devem refletir o escopo de impacto do agente, não sua sofisticacao técnica. Ulises e possivelmente o sistema mais complexo. Coordena entre 6 unidades de negócio, gerencia um CRM no Notion com 92+ prospects e executa fluxos de inteligência competitiva. Mas suas acoes não alcancam fora da organizacao, entao opera com mais autonomia que Penelope, cujas acoes individuais são mais simples mas aterrissam na caixa de entrada de outra pessoa.

Misturar os dois em um único agente com um único framework de autoridade forcaria uma escolha: ou Ulises ganha autonomia demais para o exterior, ou Penelope fica lenta com requisitos de aprovação em operacoes internas que não os justificam.

Detalhes de implementação

Alguns específicos sobre como o framework de autoridade funciona na prática.

A classificacao acontece na definição do agente, não no código. Cada agente tem um arquivo markdown especificando seu papel, ferramentas e nivel de autoridade por tipo de acao. Quando integramos um novo cliente, o mapeamento de autoridade e uma das primeiras decisões de design. Vai para o ARCHITECTURE.md do cliente antes de qualquer código ser escrito.

Acoes T3 exigem payloads de aprovação estruturados. O agente não pergunta apenas “posso fazer isso?” Apresenta: a acao proposta, o raciocínio, o contexto relevante e as alternativas especificas que considerou. Isso da ao humano informação suficiente para tomar uma decisão real em vez de bater o olho e decidir “parece bom.”

Cada nivel de autoridade tem logging. Acoes T1 são registradas silenciosamente. Acoes T2 são registradas e notificadas. Acoes T3 são registradas, notificadas e bloqueiam. Mas os tres produzem trilhas de auditoria. Se algo da errado em T1, o log existe. Se uma notificacao T2 foi ignorada, a linha do tempo e reconstruivel. O logging e a rede de seguranca. O nivel de autoridade e a restricao operacional.

As atribuicoes de nivel podem mudar. Quando um agente executou uma acao T3 especifica com sucesso 20+ vezes com taxa de aprovação de 100%, isso e evidência de que a acao deveria ser reclassificada para T2. Quando uma acao T1 produz um erro que causa impacto externo, e reclassificada para T2 ou T3. O framework e projetado para evoluir conforme o sistema acumula histórico operacional.

O problema do checkbox

A razao pela qual a maioria dos deploys de agentes de IA trata a supervisao humana como um checkbox e que os compradores exigem isso. Equipes de procurement, departamentos de compliance e comites de risco querem ouvir “um humano revisa cada output.” Essa frase aparece em RFPs. Aparece em avaliacoes de fornecedores. Aparece em apresentacoes de diretoria sobre governança de IA.

O problema e que “um humano revisa cada output” descreve um sistema que não funciona. A 5 outputs por dia, talvez. A 50, improvavel. A 200, o humano esta carimbando automaticamente ou ignorando. A supervisao existe no papel e falha na prática.

Níveis de autoridade projetados produzem resultados melhores. Menos pontos de revisao, cada um posicionado onde o julgamento humano genuinamente muda o resultado. Agentes que operam mais rápido porque não esperam aprovacoes em acoes que não precisam. Humanos que se envolvem com solicitacoes de aprovação porque recebem 3 por dia em vez de 30.

Estamos testando isso em cada sistema que construimos. Os resultados iniciais confirmam a tese central: supervisao concentrada em pontos de decisão de alto impacto supera supervisao distribuida em todos os pontos de decisão. A primeira produz revisao genuina. A segunda produz uma ficcao confortavel.

O agente prepara. O humano aprova no momento exato. O agente executa. Acertar esse passo do meio e a decisão de arquitetura que determina se o sistema realmente funciona.

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