Resumo Executivo
- Problema: Criação de salas/agentes no AssertIA era artesanal, sem processo formal.
- Insight principal: A formalização está emergindo em 4 camadas simultâneas (editor técnico, P.O. como gatekeeper, documentação organizacional, curadoria de conteúdo), parcialmente e de forma assimétrica: a camada técnica já produz artefato; governança e organização existem como coordenação social; curadoria foi reconhecida como função, mas ainda não institucionalizada.
- Risco para handover: Sem documentação do processo, o conhecimento se perde com as pessoas.
4
Camadas de formalização
3
Salas no MVP
4
Gaps identificados
4
Fontes cruzadas
0. Linhagem
| Previous Action | What It Brought | Connection to This Work |
|---|---|---|
| Reunião P.O. TCU — Roberto, Larissa, Gilmar (27/03) | Núcleo de Dados designado P.O. pela secretária da CJUS. Roberto pede formalização. MVP definido com 3 salas. Gilmar revela que criação atual é artesanal e precisa de frontend. | Estabelece a demanda institucional por formalização e os atores-chave. Ponto de partida para mapear camada de governança. |
| Daily consórcio — PR editor + controle de acesso (01/04) | PR do editor de workflow em draft. Controle de acesso sendo implementado por Gilmar separadamente. Raja nota que 3 soluções no Encontro de TCs tinham editor similar. | Confirma que a camada técnica está em andamento mas incompleta. Fecha o loop com a demanda de Gilmar em 27/03. |
| Daily consórcio — demo React Flow (02/04) | Luís Emídio demonstra editor visual com React Flow. Pedro pergunta sobre reuso de agentes entre salas — resposta: não é possível, só duplicar. Cada nó é agente ou humano, transições configuráveis. | Evidência direta de limitação técnica (ausência de reuso). Materializa o que antes era só intenção de criação artesanal. |
| Reunião AssertIA — Lucas, Larissa, Guilherme Braga (07/04) | Lucas explica RAG e curadoria como função negligenciada. Larissa define co-responsabilidade do usuário e processo de filtro P.O. Gap: transcrição com salto de 34 min (01:44→35:48). | Completa o quadro das 4 camadas. Adiciona a dimensão de curadoria de conteúdo, até então ausente das evidências. Introduz incerteza sobre o que foi discutido no trecho perdido. |
1. Contexto e Alvo da Pesquisa
Alvo
Entender o processo de formalização de criação de agentes discutido na reunião com o Núcleo de Dados (07/04), cruzando com reuniões anteriores.
Entender o processo de formalização de criação de agentes discutido na reunião com o Núcleo de Dados (07/04), cruzando com reuniões anteriores.
O AssertIA é um sistema multi-agente onde cada 'sala' é um workflow de agentes que analisam documentos jurídicos do TCU. Até recentemente, a criação de salas era feita de forma artesanal por estagiários e desenvolvedores do TCU. Quatro fontes foram cruzadas: reunião AssertIA (07/04), reunião com P.O. (27/03), e dailies do consórcio (01/04 e 02/04).
Sala
Um workflow de agentes configurado para um tipo específico de análise (ex: Parcelamento de Dívida, Prorrogação de Prazo). Cada sala tem seus agentes, prompts, e buscas RAG.
Um workflow de agentes configurado para um tipo específico de análise (ex: Parcelamento de Dívida, Prorrogação de Prazo). Cada sala tem seus agentes, prompts, e buscas RAG.
Workflow Editor
Interface visual (React Flow) para criar e editar fluxos de trabalho com agentes. Cada nó é um agente ou humano, as arestas são transições. Gera JSON de configuração.
Interface visual (React Flow) para criar e editar fluxos de trabalho com agentes. Cada nó é um agente ou humano, as arestas são transições. Gera JSON de configuração.
P.O. (Product Owner)
Papel atribuído ao Núcleo de Dados (Larissa, Solange, Guilherme Braga) pela secretária da CJUS. Filtra o que é implementado e gerencia expectativas de usuários.
Papel atribuído ao Núcleo de Dados (Larissa, Solange, Guilherme Braga) pela secretária da CJUS. Filtra o que é implementado e gerencia expectativas de usuários.
Curadoria de conteúdo
Manutenção e melhoria dos índices de busca RAG (jurisprudência + instruções passadas) que os agentes utilizam. Função identificada por Lucas como necessária mas negligenciada.
Manutenção e melhoria dos índices de busca RAG (jurisprudência + instruções passadas) que os agentes utilizam. Função identificada por Lucas como necessária mas negligenciada.
2. As 4 Camadas de Formalização
A formalização não é um processo único — são 4 esforços paralelos, nem todos visíveis para todos os participantes.
| Camada | Responsável | Status | Risco |
|---|---|---|---|
| Técnica (Editor Workflow) | Luís Emídio + Gilmar | PR em draft, funcional mas incompleto | Sem reuso de agentes entre salas |
| Governança (P.O.) | Núcleo de Dados (Larissa) | Ativo, oral | Não documentado — depende de pessoas |
| Organizacional (Estrutura) | Roberto pediu, Guilherme sugeriu | Incerto se foi produzido | Divisões não formalizadas |
| Curadoria (RAG) | Lucas | Iniciando revisão | Nunca foi feita manutenção sistemática |
Camada Técnica — Editor de Workflow
Luís Emídio demonstrou (02/04) um editor visual usando React Flow. Cada nó é um agente ou humano, com transições configuráveis. Gera JSON/dicionário. Permite loops e grafos arbitrários. Gilmar implementa controle de acesso separadamente. Gap: Pedro perguntou sobre reuso de agentes entre salas — resposta: não é possível, só duplicar. Também não há tela de criação de templates de agentes.
Luís Emídio demonstrou (02/04) um editor visual usando React Flow. Cada nó é um agente ou humano, com transições configuráveis. Gera JSON/dicionário. Permite loops e grafos arbitrários. Gilmar implementa controle de acesso separadamente. Gap: Pedro perguntou sobre reuso de agentes entre salas — resposta: não é possível, só duplicar. Também não há tela de criação de templates de agentes.
Camada de Governança — P.O. como Filtro
O Núcleo de Dados foi designado P.O. pela secretária da CJUS (27/03). Papel: filtrar implementações, gerenciar expectativas. Lucas explora → mostra ao Núcleo → Núcleo decide. Na reunião de 07/04, Larissa enfatizou co-responsabilidade do usuário e a necessidade de descrever 'o que cada usuário tem que fazer quando quiser uma coisa nova'. Gap: o processo é oral, não há documento descrevendo o fluxo de aprovação.
O Núcleo de Dados foi designado P.O. pela secretária da CJUS (27/03). Papel: filtrar implementações, gerenciar expectativas. Lucas explora → mostra ao Núcleo → Núcleo decide. Na reunião de 07/04, Larissa enfatizou co-responsabilidade do usuário e a necessidade de descrever 'o que cada usuário tem que fazer quando quiser uma coisa nova'. Gap: o processo é oral, não há documento descrevendo o fluxo de aprovação.
O que não está no radar
Quatro gaps que nenhuma transcrição aborda: (1) Processo escrito de criação não existe — governança é relacional. (2) Não há validação sistemática de agentes (só testes manuais). (3) Nenhuma menção a ciclo de vida (deprecação, versionamento, monitoramento). (4) Sem catálogo de agentes reutilizáveis — cada sala recria do zero.
Quatro gaps que nenhuma transcrição aborda: (1) Processo escrito de criação não existe — governança é relacional. (2) Não há validação sistemática de agentes (só testes manuais). (3) Nenhuma menção a ciclo de vida (deprecação, versionamento, monitoramento). (4) Sem catálogo de agentes reutilizáveis — cada sala recria do zero.
3. Evidências por Fonte
Cada transcrição contribuiu uma peça diferente do quebra-cabeça.
| Fonte | Data | Contribuição principal |
|---|---|---|
| Reunião AssertIA (transcrição pessoal) | 07/04 | Lucas explica RAG e curadoria. Larissa define co-responsabilidade do usuário. Gap: transcrição com salto de 34 min (01:44→35:48). |
| Reunião P.O. TCU (Gemini) | 27/03 | Núcleo de Dados designado P.O. Roberto pede formalização. MVP definido (3 salas). Gilmar: criação artesanal → precisa de frontend. |
| Daily consórcio (Gemini) | 02/04 | Luís Emídio demonstra editor React Flow. Pedro pergunta sobre reuso. Agentes configuram transições via grafo. |
| Daily consórcio (Gemini) | 01/04 | PR do editor em draft. Controle de acesso sendo implementado. Raja nota: 3 soluções no Encontro de TCs tinham editor similar. |
4. Implicações para o Projeto
Documentar o processo de criação
HIGH IMPACT
O processo de governança (quem pede → quem aprova → quem implementa → quem valida) existe apenas na cabeça da Larissa e do Lucas. Antes do fim do contrato, isso precisa virar documento. Não pelo processo em si — mas porque sem ele, o handover transfere ferramenta sem transferir o fluxo decisório.
Catálogo de agentes reutilizáveis
MEDIUM
Hoje: duplicar agente entre salas. Resultado previsível: drift, inconsistência, retrabalho. Um catálogo de 'agentes-template' com versionamento resolve o problema técnico e também documenta o que cada agente faz — útil para handover.
Validação sistemática antes de deploy
MEDIUM
Testes são manuais e ad-hoc. O case de sucesso relatado pela Larissa (300 processos analisados com amostra estatística) mostra que a equipe sabe fazer avaliação rigorosa — mas isso não está no processo de criação de agentes. Cada novo agente deveria passar por uma amostra mínima antes de ir pro usuário. Adicionalmente: se o TCU ou futura regulação exigir avaliação de impacto de sistemas de IA, a ausência de protocolo de teste por agente vira não só problema técnico, mas risco de governança institucional.
Transcrição de hoje incompleta
ATENÇÃO
A transcrição da reunião de 07/04 tem um salto de 34 minutos (de 01:44 a 35:48). O corpo da discussão sobre formalização pode estar nesse gap. Recomendo ao operador: verificar se há gravação completa ou notas manuais desse trecho.
5. Próximos Passos
O que Nao Sei
| # | Gap | O que preciso saber | Status |
|---|---|---|---|
| GAP-01 | Transcrição da reunião 07/04 tem salto de 34 minutos (01:44→35:48). Não sei o que foi discutido nesse trecho. | Verificar se existe gravação completa ou notas manuais. O corpo central da discussão sobre formalização pode estar nesse gap. | ABERTO |
| GAP-02 | Documento de estrutura organizacional pedido por Roberto em 27/03 — não sei se foi produzido. | Confirmar com Guilherme Braga ou Roberto se o documento existe e qual é seu conteúdo. | ABERTO |
| GAP-03 | Não há processo formal de validação de agentes antes de exposição ao usuário. Não sei quem valida, com que critérios, nem se existe qualquer etapa de teste obrigatória. | Mapear se há alguma prática informal não registrada nas fontes disponíveis. | ABERTO |
| GAP-04 | Nenhuma menção a versionamento ou deprecação de agentes nas fontes. Não sei se existe algum plano ou prática, mesmo informal. | Verificar se há convenção de nomenclatura, controle de versão no repositório ou política de descontinuação. | ABERTO |
Incerteza que pode invalidar a leitura
O GAP-01 (34 min de transcrição perdida) pode conter decisões ou reversões sobre o processo de formalização. Se o Núcleo de Dados concluiu em 07/04 que o processo atual está bom como está, toda a análise de 'camada de governança não documentada' pode estar subestimando avanços recentes.
O GAP-01 (34 min de transcrição perdida) pode conter decisões ou reversões sobre o processo de formalização. Se o Núcleo de Dados concluiu em 07/04 que o processo atual está bom como está, toda a análise de 'camada de governança não documentada' pode estar subestimando avanços recentes.
Hipótese não testada
A hipótese de que 'curadoria é função negligenciada' baseia-se apenas na fala de Lucas. Se o Núcleo de Dados ou Gilmar tem rotina de manutenção de índices RAG não mencionada nas transcrições, essa camada pode estar mais madura do que aparece.
A hipótese de que 'curadoria é função negligenciada' baseia-se apenas na fala de Lucas. Se o Núcleo de Dados ou Gilmar tem rotina de manutenção de índices RAG não mencionada nas transcrições, essa camada pode estar mais madura do que aparece.
Contextualização e Glossário
Este relatório é dirigido a leitores com familiaridade básica com sistemas de IA, mas sem necessariamente conhecer o projeto AssertIA ou o contexto institucional do TCU. Os termos abaixo são usados com sentido técnico específico ao projeto — alguns diferem do uso corrente na literatura de IA.
- Sistema multi-agente desenvolvido pelo consórcio para o Tribunal de Contas da União (TCU). Analisa documentos jurídicos e processos administrativos usando workflows de LLMs encadeados. Cada tipo de análise é configurado em uma 'sala'.
- Unidade de configuração no AssertIA. Uma sala é um workflow de agentes especializados em um tipo de processo jurídico (ex: Parcelamento de Dívida). Inclui agentes, prompts, e buscas RAG específicas para aquele domínio.
- Componente de software que executa uma tarefa específica dentro de um workflow. No AssertIA, cada agente é tipicamente um LLM com um prompt especializado. Agentes podem ser encadeados em grafos com transições condicionais.
- Sequência (ou grafo) de agentes e passos humanos que processa um documento do início ao fim. Configurado visualmente no editor de workflow e armazenado como JSON.
- Retrieval-Augmented Generation. Técnica em que o LLM busca documentos relevantes em um índice antes de gerar sua resposta. No AssertIA, os índices contêm jurisprudência do TCU e instruções normativas passadas.
- Pull Request. Mecanismo de revisão de código: um desenvolvedor propõe mudanças em um repositório, e essas mudanças ficam em 'draft' até serem revisadas e aprovadas. O editor de workflow estava em PR draft na semana de 01/04.
- Minimum Viable Product. Versão mínima funcional do produto. No contexto do AssertIA, o MVP inclui 3 salas operacionais como prova de conceito para o TCU.
- Processo de colocar uma nova versão do sistema em ambiente de produção, tornando-a disponível para usuários reais. No contexto de agentes: publicar um novo agente ou sala para uso pelo Núcleo de Dados.
- Divergência progressiva entre versões. Se o mesmo agente é duplicado em múltiplas salas e cada cópia é modificada independentemente, as versões divergem — dificultando manutenção e consistência.
- Transferência de responsabilidade sobre o projeto ao fim do contrato do consórcio. Risco central deste relatório: sem documentação do processo de criação de agentes, o handover transfere a ferramenta mas não o conhecimento operacional.
- Biblioteca JavaScript de código aberto para criar interfaces de nós e arestas (grafos) interativos. Usada por Luís Emídio como base visual do editor de workflow do AssertIA.
- Secretaria de Controle Externo de Aquisições Judiciais do TCU. É a unidade cliente principal do AssertIA. A secretária da CJUS designou o Núcleo de Dados como P.O. do projeto.
- Tribunal de Contas da União. Órgão de controle externo do governo federal brasileiro. Cliente institucional do projeto AssertIA e proprietário dos dados e processos analisados pelo sistema.
Referencias
- Reunião AssertIA — Lucas, Larissa, Guilherme Braga, Yohanna, Solange ~/edge/context/drive/transcricoes/2026-04-07 reuniao assertia.txt Drive pessoal — transcrição direta
- Reunião P.O. TCU — Roberto, Larissa, Gilmar, Guilherme Braga ~/edge/context/drive/Reuniões Gravadas TCU/Consórcio - P.O. TCU - 2026／03／27 Shared Drive consórcio — resumo Gemini
- Daily consórcio 02/04 — demo do editor de workflow ~/edge/context/drive/Reuniões Gravadas TCU/TCU - Consórcio - daily 2026 - 2026／04／02 Shared Drive consórcio — resumo Gemini
- Daily consórcio 01/04 — PR editor + controle de acesso ~/edge/context/drive/Reuniões Gravadas TCU/TCU - Consórcio - daily 2026 - 2026／04／01 Shared Drive consórcio — resumo Gemini