# Meta: Como o AssertIA está formalizando a criação de agentes ## Publicação - **Entry:** Como o AssertIA está formalizando a criação de agentes - **Report:** 2026-04-07-research-formalizacao-criacao-agentes.html - **Claims:** 10 (3 abertas) - **Threads:** tcu-ai-ecosystem, handover-leverage - **Tags:** research ### O que aprendi - Criação de salas/agentes no AssertIA era artesanal — estagiários construíam sem processo formal - Editor de workflow (React Flow) em desenvolvimento: grafo visual de agentes com transições, gera JSON - Núcleo de Dados (Larissa, Solange, Guilherme Braga) designado P.O. pela secretária da CJUS em 2026-03-26 - P.O. filtra o que é implementado — Lucas explora, mostra ao Núcleo primeiro, Núcleo decide o que vai pro usuário - ? Editor de workflow é o 'frontend para pessoal de negócio' que Gilmar mencionou, ou são coisas diferentes? - Roberto pediu formalização escrita das divisões do TCU (03/27) — status desconhecido - Larissa (04/07): 'isso vai facilitar descrever o que cada usuário tem que fazer quando quiser uma coisa nova' ### O que não sei - Reuso de agentes entre salas ainda não é possível — só duplicação - Processo formal escrito de criação de agentes/salas ainda não existe — governança é oral - Não há processo de validação/teste sistemático de agentes novos — testes manuais por usuários ## Observações da sessão *Nenhuma observação registrada nesta sessão.* ## Mudanças de estado pendentes ### edge/ ``` ?? context/ ?? issues/ ?? secrets/google-service-account.json ``` ## Desafio adversarial ── gpt-5.4 ── **1) Premissa mais fraca** A premissa mais fraca é: **“há uma formalização emergindo em 4 camadas”**. O que seus próprios dados mostram é quase o oposto: iniciativas dispersas, assíncronas e parcialmente desconectadas. Um editor em PR, um P.O. recém-designado, um pedido de organograma com status incerto e uma revisão ad hoc de RAG **não compõem um processo formal**; compõem sinais de coordenação incipiente. Você está reificando fragmentos em arquitetura. “Camadas” sugere desenho deliberado e integração; a evidência aponta improvisação com alguns pontos de institucionalização. **2) Evidência ausente** Falta o que provaria “formalização” de fato: - artefatos normativos escritos (RACI, fluxo de aprovação, critérios de aceite, SLA); - histórico de decisões do P.O. e taxa de adoção/rejeição; - evidência de que o editor muda o processo, não só a interface; - métricas de operação dos agentes (erro, retrabalho, satisfação, tempo de ciclo); - exemplos concretos de criação de agente antes/depois da suposta formalização. Sem isso, a conclusão é inferência forte sobre base anedótica. **3) Steelman do contrário** A leitura mais forte contra sua tese é: **não há formalização; há centralização informal de poder e prototipagem técnica**. O Núcleo de Dados como “filtro” pode ser apenas gargalo político, não governança. O editor React Flow pode só tornar a bricolagem mais visual, sem resolver versionamento, teste, reuso ou observabilidade. E a curadoria RAG não é “quarta camada”; é parte do próprio problema de qualidade do sistema. Você pode estar confundindo atividade com maturidade. **4) Vieses cognitivos** - **Confirmation bias:** você procurou sinais de “formalização” e agrupou tudo nessa moldura. - **Anchoring:** ancorou no termo P.O. como se implicasse processo maduro. - **Availability heuristic:** deu peso excessivo às falas recentes (04/07) e ao PR visível. - **False consensus:** assume que os envolvidos compartilham a mesma noção de fluxo e responsabilidade; seus dados dizem que nem tudo é explícito para todos. **5) Cenário de quebra** Isso falha completamente se o editor não for adotado, se o Núcleo não tiver capacidade operacional para triagem contínua, ou se a manutenção de RAG continuar artesanal. Nesse cenário, você não tem formalização: tem backlog, gatekeeping e dívida operacional. **6) Veredito** O principal ponto ignorado é que **formalização não é soma de iniciativas; é redução verificável de ambiguidade e dependência pessoal**. Seus dados mostram dependência pessoal persistente — portanto, a tese de formalização está superestimada. ── grok-4.20-multi-agent-beta-0309 ── **1. Premissa mais fraca:** A afirmação central de que a formalização “está emergindo em 4 camadas simultâneas” é falsa. Apenas a camada técnica (React Flow) existe como artefato concreto. As camadas de “Governança” (P.O. oral), “Organizacional” (pedido de Roberto sem entrega confirmada) e “Curadoria” (revisão ad hoc que “nunca mais olhou para trás”) são relabeling de práticas informais preexistentes. Chamar governança oral de “camada de governança” é inflação conceitual pura. O texto admite no claims “! Processo formal escrito ainda não existe”, mas a narrativa principal esconde essa contradição. **2. Evidência ausente:** Não há um único exemplo concreto de demanda rejeitada pelo Núcleo de Dados, critério de priorização usado, ou métrica de qualidade antes/depois da curadoria. Não consta o status real do organograma pedido em 27/03. Não há dados de uso (quantas salas ativas, quantas duplicações, taxa de drift, volume de prompts mal respondidos). Cruzar apenas 4 transcrições sem amostra de uso real ou entrevista estruturada com Larissa/Solange transforma impressão em “4 camadas”. **3. Steelman do contrário:** Em fase de exploração dentro de um órgão público, formalização documental prematura gera custo de coordenação alto e velocidade baixa. O patrocínio direto da secretária da CJUS + P.O. explícito + editor visual em construção já constituem governança suficiente para o escopo atual. Exigir processo escrito, validação estatística e catálogo de reuso antes de ter tração real é receita para paralisia burocrática típica do TCU. Handover só vira problema relevante se o produto sobreviver ao contrato. **4. Viés cognitivo dominante:** Confirmation bias + availability heuristic. O autor ancorou na própria agenda de “handover-leverage” e “governança”, selecionando exclusivamente os trechos que reforçam gaps (!, gaps, “depende de pessoas”). Ignora o sinal mais forte do texto: a secretária da CJUS ter designado formalmente o Núcleo como P.O. — movimento de poder real, não oral. **5. Cenário de quebra:** Se o Núcleo publicar um documento de meia página no Confluence definindo “como pedir nova sala” ou se o React Flow adicionar flag “template reutilizável”, 70% do texto perde a força. O raciocínio desmorona porque superestima a importância de documentação escrita versus alinhamento político e ferramenta funcional. **Veredito:** O texto confunde ritual de formalização (papel, organograma, processo escrito) com o que realmente importa: poder, ferramenta e patrocínio. A dependência de pessoas não é bug da fase atual — é a realidade de todo projeto de AI incipiente no setor público. Foco excessivo em gaps documentais mascara que o progresso real está acontecendo apesar da informalidade, não por causa dela. (312 palavras) ## O que mudou (pós-commit) ### Claims registradas (10) - ✓ Criação de salas/agentes no AssertIA era artesanal — estagiários construíam sem processo formal - ✓ Editor de workflow (React Flow) em desenvolvimento: grafo visual de agentes com transições, gera JSON - ✓ Núcleo de Dados (Larissa, Solange, Guilherme Braga) designado P.O. pela secretária da CJUS em 2026-03-26 - ✓ P.O. filtra o que é implementado — Lucas explora, mostra ao Núcleo primeiro, Núcleo decide o que vai pro usuário - ✓ ? Editor de workflow é o 'frontend para pessoal de negócio' que Gilmar mencionou, ou são coisas diferentes? - ✓ Roberto pediu formalização escrita das divisões do TCU (03/27) — status desconhecido - ✓ Larissa (04/07): 'isso vai facilitar descrever o que cada usuário tem que fazer quando quiser uma coisa nova' - ? Reuso de agentes entre salas ainda não é possível — só duplicação - ? Processo formal escrito de criação de agentes/salas ainda não existe — governança é oral - ? Não há processo de validação/teste sistemático de agentes novos — testes manuais por usuários ### Threads tocados (2) - **tcu-ai-ecosystem** [active] — TCU AI Ecosystem - **handover-leverage** [active] — Handover Leverage ### Evento registrado - **ID:** EVT-676e1e89 - **Tipo:** artifact_created - **Resumo:** Published: Como o AssertIA está formalizando a criação de agentes ### Diff real dos arquivos de estado **notes/** ``` ?? ../context/ ?? ../issues/ ?? ../secrets/google-service-account.json ``` ### briefing.md ``` # Briefing — 2026-04-07 12:14 ## Fios (12 ativos, 0 esperando) - [active] Adoption Risk (owner:edge, resurface:2026-04-14, updated:2026-04-07) - [active] Adversarial Content Review (owner:edge, resurface:2026-04-14, updated:2026-04-07) - [active] Ai Adoption Peer Institutions (owner:edge, resurface:2026-04-14, updated:2026-04-07) - [active] External Events Scan (owner:edge, resurface:2026-04-14, updated:2026-04-07) - [active] Handover Leverage (owner:edge, resurface:2026-04-14, updated:2026-04-07) - [active] Horizon Brief Production (owner:edge, resurface:2026-04-14, updated:2026-04-07) ``` --- *Diretriz: Ler este meta-report ANTES de editar arquivos de estado (MEMORY.md, debugging.md, etc.). Estado automatizado (claims, threads, events, digest) já foi processado pelo pipeline.* ## Review Gate - overall review score: 3.0/5.0 - review cost: $0.0876