IA aplicada

A arquitetura de cinco camadas que eu desenhei para agentes de reunião

Por Ruan Braz · 8 de julho de 2026 · Leitura de ~10 min

Toda empresa de dez pessoas tem o mesmo vazamento: a decisão é tomada na reunião e morre na reunião. Eu passei os últimos meses desenhando um sistema interno para resolver isso, e a parte difícil não foi a IA. Foi decidir onde cada responsabilidade mora.

O problema não é falta de ata, é falta de rastro

Nós somos dez pessoas, quase todas PJ, quase ninguém exclusivo. Isso significa que a agenda de cada um é fragmentada e que boa parte do contexto de um projeto existe só na cabeça de duas ou três pessoas que estavam na chamada certa. Esse modelo de time é barato e flexível, e cobra o preço em continuidade.

Durante um bom tempo eu tratei isso como problema de disciplina. Escreve a ata. Coloca no Notion. Marca o responsável. Não funcionou, e não funcionou por um motivo que hoje me parece óbvio: ata é um artefato de escrita, e escrever ata é a tarefa mais chata da semana de qualquer pessoa. O que sobrevive é sempre um resumo genérico do tipo "alinhamos o roadmap", que não responde nenhuma pergunta útil três semanas depois.

A pergunta que aparece três semanas depois é sempre "por que decidimos isso?", e ata não guarda nada do que responderia: quem estava na sala, qual era a alternativa descartada, qual restrição fez a balança pender. Então eu parei de tentar melhorar a ata e comecei a desenhar o sistema. Cinco camadas. Vou detalhar cada uma, incluindo o que estou abrindo mão em cada escolha.

Camada 1: o Meeting Agent é um sensor burro, e isso é de propósito

A primeira camada entra na reunião pelo calendário, grava, transcreve com Whisper, faz diarização (separa quem falou o quê) e gera uma timeline com marcações de tempo. Ponto. Ela não resume, não classifica, não sugere, não julga.

Essa foi a decisão mais importante do sistema inteiro, e a que mais gente contesta quando eu explico. A tentação de fazer o agente que grava também resumir é enorme, porque é um pipeline a menos e uma chamada de modelo a menos. Eu escolhi o caminho oposto por três razões.

Primeira: captura é infraestrutura, interpretação é produto. A captura precisa ser chatamente confiável: se o bot não entrou na sala, nada mais existe. Ela tem SLA, tem retry, tem fila. A interpretação é experimental, muda de prompt toda semana, muda de modelo a cada dois meses. Misturar as duas significa que um ajuste de prompt pode derrubar a gravação de uma reunião de diretoria. Isso é inaceitável.

Segunda: eu quero poder reprocessar o passado. Se em outubro eu melhorar a extração de riscos, quero rodar a nova lógica em cima de todas as transcrições dos últimos seis meses e comparar. Só dá para fazer isso se a transcrição crua for um artefato imutável guardado à parte, e não um insumo consumido e descartado no meio do caminho.

Terceira: áudio e texto têm regimes de privacidade diferentes. Áudio bruto é o dado mais sensível que a empresa produz. Ele fica numa camada com política de retenção própria e acesso muito mais restrito do que a transcrição, que por sua vez é mais restrita que os insights derivados. Se o mesmo componente segura tudo, você não tem como aplicar políticas distintas sem gambiarra.

O que eu abro mão: latência e custo. Duas passagens custam mais que uma, e o resultado leva alguns minutos para aparecer em vez de trinta segundos. Aceitei a troca sem muito drama, porque ninguém toma decisão baseada em ata nos primeiros trinta segundos.

A diarização, aliás, é a parte mais frágil de tudo. Em chamada com áudio ruim e duas pessoas falando junto, ela erra. Eu ainda estou pensando em como resolver isso direito. Hoje a saída é confrontar com a lista de participantes do calendário e marcar trechos de baixa confiança em vez de fingir certeza.

Camada 2: o Intelligence Agent extrai estrutura, não parágrafos

A segunda camada recebe quatro coisas: a transcrição, a lista de participantes, o histórico daquele projeto e a memória relevante. E devolve estrutura tipada:

• Decisões: o que foi decidido, qual alternativa foi descartada e qual restrição pesou.
• Riscos: com o trecho da transcrição que originou o risco anexado.
• Tarefas: com responsável e prazo. Se não tiver responsável explícito, o campo fica vazio e vira uma pendência, nunca um chute.
• Perguntas em aberto: o que ficou sem resposta na sala. Na prática, o campo mais valioso de todos.
• KPIs e KRs citados: número mencionado em reunião entra como o primeiro ponto de uma série histórica.

O detalhe que mudou a qualidade da saída foi obrigar o modelo a citar o trecho de origem de cada item. A citação funciona como restrição de geração, e não como enfeite de auditoria. Quando o modelo precisa apontar onde no texto está a evidência, ele inventa muito menos. Item sem trecho de origem é descartado antes de chegar em qualquer pessoa.

"Perguntas em aberto" foi a categoria que eu quase não coloquei e hoje é a que eu mais leio. Reunião boa não termina resolvendo tudo; termina sabendo o que ainda não sabe. Uma pergunta que aparece em três reuniões seguidas sem resposta é o sinal mais confiável de projeto travado que eu conheço.

Camada 3: não existe "o agente da empresa"

Cada pessoa tem o seu próprio agente, nomeado com prefixo entre colchetes: [Produto], [Tráfego], [Conteúdo]. Cada agente tem memória própria, instruções próprias e backlog próprio. Isso é o contrário do que quase toda ferramenta de mercado faz. O padrão é um assistente único que responde igual para todo mundo, e eu acho esse padrão errado o suficiente para defender o motivo até o fim.

Um agente que fala igual para todo mundo é um agente que não conhece ninguém.

A mesma frase dita numa reunião significa coisas diferentes dependendo de quem escuta. "Precisamos melhorar a conversão do Atlas" é, para quem cuida de tráfego, um problema de criativo e canal. Para quem cuida de produto, é onboarding. Para mim, pode ser preço e posicionamento na escada de valor. Um agente genérico devolve as três leituras para todo mundo e ninguém age. Um agente pessoal devolve a leitura que cabe naquele papel, naquele nível de responsabilidade.

Tem uma camada conceitual aqui que vem de estratos cognitivos: o horizonte de tempo de cada papel é diferente. O agente de quem opera semana deveria priorizar o que trava a semana. O agente de quem opera trimestre deveria ignorar quase tudo isso e olhar padrão. Instrução por pessoa é a forma mais barata de codificar isso.

O custo dessa escolha é real: multiplica manutenção por dez. Dez conjuntos de instruções, dez memórias, dez lugares onde a coisa pode ficar desatualizada. Estou lidando com isso mantendo uma base comum de instruções e permitindo só um delta por pessoa. Pode ser que não escale além de vinte pessoas. Vou descobrir.

Camada 4: agentes que negociam o entendimento entre si

Essa é a camada que eu não vi em lugar nenhum e a que mais me interessa. Quando o Intelligence Agent extrai uma tarefa com responsável, ela não é simplesmente entregue. Ela é proposta ao agente pessoal daquele responsável. E esse agente faz uma de três coisas: confirma o entendimento, contesta ("isso depende de uma decisão de preço que não foi tomada"), ou pede desambiguação ("não está claro se é a landing do Atlas ou a do Overpass").

Quando dois agentes leem a mesma tarefa de formas incompatíveis (o agente de quem pediu entendeu "entregar a integração", o agente de quem recebeu entendeu "prototipar a integração"), o sistema não escolhe um vencedor. Ele marca conflito de interpretação e sobe para as duas pessoas com as duas leituras lado a lado.

O ganho aqui é antecipação. Divergência de entendimento sobre escopo é a fonte número um de retrabalho que eu vejo na operação, e ela normalmente só aparece na entrega, três semanas depois, quando alguém diz "mas eu achei que era só o protótipo". Trazer esse atrito para o dia seguinte à reunião, quando corrigir custa uma mensagem, é a coisa mais valiosa que esse sistema faz.

Posso estar errado nessa. Existe um risco claro de o sistema virar uma máquina de gerar discussão sobre semântica, e o time começar a ignorar os alertas por fadiga. Por isso o conflito só é levantado quando as duas leituras divergem em escopo, prazo ou entregável. Divergência de redação não gera alerta nenhum, e cada pessoa pode desligar a contestação do próprio agente. Se em três meses ninguém estiver usando, eu mato a camada.

Camada 5: memória segmentada em quatro níveis

A quinta camada é onde tudo vira consultável. Ela é segmentada em quatro níveis:

1. Pessoal: preferências, compromissos e histórico de um indivíduo.
2. Time: acordos operacionais, rituais, convenções de um grupo.
3. Projeto: decisões, restrições e histórico de uma iniciativa específica.
4. Empresa: estratégia, posicionamento, números-âncora, o que já foi tentado e descartado.

A segmentação existe por escopo de recuperação, e não por organograma. Quando alguém pergunta "por que a gente decidiu cobrar crédito por trilha em vez de deixar ilimitado?", o sistema não deve varrer tudo. Ele busca no nível de projeto e no nível de empresa, e devolve a decisão com data, participantes e motivo, que nesse caso foi uma discussão inteira sobre custo variável de IA dentro de uma assinatura de preço fixo.

Essa é a diferença entre ata e memória. Ata te dá o texto de uma reunião. Memória te dá a resposta atravessando dezoito reuniões, e mostra a linhagem: decidimos X em março, revisamos em maio por causa de Y, e desde então nada mudou.

O problema não resolvido aqui é decaimento. Uma decisão de março de 2025 pode estar completamente obsoleta e continuar sendo recuperada com a mesma confiança de uma de junho de 2026. Hoje eu resolvo com peso por recência e marcação manual de decisão superada, e sei que isso é insuficiente. É o item aberto mais incômodo da arquitetura.

Duas decisões de produto que eu tomei contra a intuição

A primeira: tarefa nunca é criada automaticamente no gestor de tarefas. O sistema gera a proposta, a pessoa revisa e confirma, e só então vira card.

Isso parece jogar fora o principal benefício da automação, e é exatamente por isso que preciso justificar. Toda reunião de uma hora produz entre oito e quinze candidatos a tarefa. Talvez cinco sejam tarefas de verdade. O resto é ideia solta, hipótese, coisa que alguém falou em voz alta e já descartou na frase seguinte. Se tudo isso entra no board automaticamente, em duas semanas o board tem duzentos cards, ninguém confia mais nele, e o time volta para o WhatsApp. Já vi isso acontecer com ferramenta comprada pronta. Um board com ruído é pior que board nenhum, porque destrói a confiança no instrumento, e a confirmação humana custa noventa segundos por pessoa por reunião.

A segunda: admin vê tudo, os demais veem só o próprio. Cada pessoa acessa as reuniões em que esteve, as próprias tarefas e a própria memória. Admin acessa a base inteira.

Eu sei como isso soa. Mas a alternativa de todo mundo ver tudo muda o comportamento na reunião, e muda para pior. As conversas mais valiosas que eu tenho envolvem performance, dinheiro, dúvida sobre estratégia. Se cada pessoa sabe que a transcrição fica navegável para os outros nove, essas conversas simplesmente migram para fora do sistema. Aí eu não tenho nem privacidade nem memória: tenho um arquivo de reuniões inócuas.

O que isso me obriga a fazer é ser explícito: o time sabe que a gravação existe, sabe o que é guardado, por quanto tempo, e sabe que eu tenho acesso. Assimetria declarada é gerenciável. Assimetria descoberta depois destrói confiança de forma irreversível.

O trabalho difícil não é o modelo

Se você olhar para a lista do que esse sistema faz (transcrever, resumir, extrair tarefa, responder pergunta sobre o histórico), cada item isolado é resolvido por um modelo comercial disponível hoje. Nenhuma dessas capacidades é vantagem competitiva.

O trabalho difícil é o resto: decidir quais agentes existem e quem responde pelo quê; modelar memória de um jeito que a informação certa apareça sem arrastar lixo junto; definir permissão com granularidade suficiente para não travar o uso nem vazar o que não deve; e manter auditoria para que qualquer afirmação do sistema possa ser rastreada até o minuto exato da gravação que a originou.

Orquestração, memória, permissão, auditoria. É engenharia de sistemas com um componente probabilístico no meio, e a parte probabilística é a que menos me preocupa. Isso vale, eu acho, para quase todo produto de IA sendo construído agora: a bolha está olhando para o modelo, enquanto o valor se acumula na arquitetura em volta dele.

Esse sistema é infraestrutura interna e, pelo menos por enquanto, não vira produto da Overlens. Ele nasce do mesmo lugar que quase tudo que eu construo: aprender resolvendo um problema real em vez de estudar antes, e depois olhar para trás e entender o que o problema ensinou. Se você quiser ver como eu penso o resto da operação, tem a aposta em conectar áreas em vez de aprofundar uma só, mais coisa em sobre e vídeos no canal.