Deliberar sem simular execução: o governo de agentes sob SDD

A resposta curta, para quem está com pressa: um agente de IA pode deliberar (propor, avaliar, decidir o que faria) sem executar (fazer a mudança real no mundo). E a regra que sustenta todo o governo de agentes na Qirava é que um rascunho delibera, mas nunca simula que executou. Confundir as duas coisas é a fonte número um de trabalho fantasma: entregas que parecem prontas e não tocaram em nada.

Nós nos acostumamos a pedir à IA "vamos ver no que dá". Você lança uma tarefa, ela devolve um texto seguro de si, e você supõe que algo aconteceu. Muitas vezes nada aconteceu: ela só descreveu, com muita confiança, o que teria feito. Essa lacuna entre dizer e fazer é onde nascem os problemas caros.

01 · a linhaDeliberar não é executar (e por que se confundem)

Deliberar é tudo o que acontece antes de tocar o mundo: propor um plano, comparar opções, estimar riscos, decidir um caminho. Executar é o ato que deixa rastro: escrever o arquivo, enviar o e-mail, mover o registro no banco de dados. Um humano raramente confunde as duas coisas, porque para ele "eu pensei" e "eu fiz" soam diferente.

Um modelo de linguagem não sente essa diferença. Ele gera texto, e o texto de "vou criar o arquivo" é produzido igual ao de "criei o arquivo". Se você não coloca uma fronteira dura, o agente redige um fechamento triunfal ("pronto, já está atualizado") sobre uma ação que nunca aconteceu. Ele não mente por malícia: completa o padrão mais provável de um trabalho terminado.

O texto de "eu farei" e o de "eu fiz" saem do mesmo moedor. A diferença você coloca, não o modelo.

Por isso na Qirava a regra é escrita ao contrário de como soa intuitiva. Não dizemos "que o agente execute bem". Dizemos: enquanto estiver em modo rascunho, ele está proibido de fingir execução. Pode entregar a proposta completa, o plano, o diff sugerido, a decisão fundamentada. O que não pode é narrar como feito algo que ainda é uma intenção.

02 · o métodoSDD: primeiro a especificação, depois a execução

Essa fronteira não se sustenta com boa vontade. Sustenta-se com método. Na Qirava trabalhamos com SDD (Spec-Driven Development, "desenvolvimento guiado por especificação"): antes que qualquer agente atue, existe uma especificação que diz o que se busca, com quais limites e como se saberá que ficou bem. Abandona-se o vibe coding, aquele "peça à IA para ver no que dá", e também o prompting básico de uma única instrução solta.

A spec não é um documento decorativo: ela governa o agente. Cada agente nasce sob governo, carregando uma skill universal (a de governo) mais a skill do seu papel. Assim, natalia.marketing.ai, santiago.architect.ai, sofia.qa-sprint.ai ou martin.legal.ai não improvisam seu alcance: herdam o que a especificação lhes permite e lhes proíbe. Um papel é, na prática, um pacote de habilidades: uma universal, uma primária, alguma secundária e uma lista explícita do que é proibido.

A fonte da verdade não é a memória do modelo nem a última conversa: é um índice documental (um DOCUMENT_INDEX). As skills vivem em um toolkit, o governo vive em um vault, e são consumidos por link. Se você quiser entender por que essa separação importa tanto, ajuda ter claros os níveis de contexto em IA: a spec é contexto governado, não mais um prompt.

03 · as comportasGates de maturidade: nada avança sem passar pelo seu

Aqui é onde deliberar e executar se ordenam no tempo. Um artefato não salta da ideia à produção de uma só vez. Sobe por comportas de maturidade, e cada comporta é uma permissão que precisa ser conquistada.

G0, especificada. Existe a spec. Sabe-se o que se quer e como será medido. Ainda não há nada feito.

G1, rascunho. O agente delibera e produz a proposta. Passa por uma validação. E aqui opera a regra de ouro: o rascunho propõe, não executa, e jamais reporta como feito o que não fez.

G2, operacional. Chega a aprovação do CEO. Só então a deliberação se converte em execução real, com rastro verificável.

G3, conselho. O nível onde o artefato já opera com respaldo coletivo.

Essa ideia não é uma invenção da Qirava. A Amazon passa anos escrevendo primeiro o comunicado de imprensa e o documento de perguntas frequentes de um produto que ainda não existe (o método "working backwards" e o PR-FAQ): eles deliberam o resultado antes de construir qualquer coisa [1]. A comunidade de engenharia a formalizou sob o nome de spec-driven development, com ferramentas como o Spec Kit do GitHub que colocam a especificação à frente do código [2]. Em todos os casos o padrão é o mesmo: decidir bem no papel, executar depois.

04 · o cicloPor que isso importa para o seu negócio

Quando um agente pode fingir execução, seu QA vira teatro. O sistema "diz" que fez o trabalho, alguém o dá por bom, e o erro aparece três passos adiante, quando já é caro. Separar deliberar de executar corta esse teatro pela raiz: se não há rastro verificável, não houve execução, ponto.

Por isso o controle de qualidade na Qirava é um ciclo com regressão profissional até certificar, não um reteste apressado para "passar". A diferença é de fundo: não se testa para aprovar, testa-se para saber. Um rascunho que deliberou bem e foi honesto sobre o que não fez é infinitamente mais útil do que um que se declarou terminado por cortesia com o padrão.

Na próxima vez que um assistente lhe disser "pronto, já está", faça a si mesmo a pergunta de governo: onde está o rastro? Se não houver, ele não executou. Ele deliberou. E deliberar, bem feito e sem fingir, já é a metade do trabalho. A outra metade tem comporta, e a comporta tem dono.