Projeto de Hackathon

Agentes propõem, o código decide.

18 de julho de 2026 · 6 min de leitura

Construímos um sistema de IA que escreve propostas comerciais, e o proibimos de fazer a matemática.

Essa única decisão de design, mais do que qualquer escolha de modelo ou truque de prompt, é o que fez o Proposal Architect funcionar. Esta é a história da arquitetura que construímos para o Google for Startups AI Agents Challenge 2026, e da regra que a moldou: os agentes propõem, o código decide.

Por que propostas são um bom problema para agentes

Uma proposta comercial não é uma tarefa só. É uma cadeia de competências muito diferentes: ler um briefing bagunçado, mapear requisitos, desenhar uma arquitetura, decompor o trabalho, estimar esforço, precificar e escrever tudo isso numa forma que um cliente consiga de fato avaliar. Peça a um único prompt para fazer tudo e você recebe algo que parece uma proposta e não sobrevive a nenhum escrutínio.

Pipelines multiagente existem exatamente para problemas com esse formato. Cada competência vira um agente especializado com um contrato estreito; o pipeline carrega estado de um para o outro; e as partes que nunca podem ser criativas (a aritmética) saem do modelo por completo.

O pipeline em seis movimentos

O fluxo se lê da esquerda para a direita: um briefing bruto entra; agentes o ancoram no conhecimento da empresa (tabelas de preços, projetos anteriores); um agente arquiteto desenha a solução e sua estrutura de trabalho; um passo determinístico calcula custo e ROI em código; um crítico adversarial contesta o rascunho; e um compositor monta a proposta final, na tela e em PDF com a marca.

O núcleo determinístico

Modelos de linguagem são convincentes em aritmética e não confiáveis nela, que é a pior combinação possível para precificação. Por isso o passo de preço do Proposal Architect não é um agente. É Python puro: o modelo propõe entradas estruturadas (papéis, esforço, premissas), e compute_price e compute_value fazem a conta.

A fronteira é defendida, não apenas declarada. Números de autoria do modelo são validados antes de entrar no cálculo: valores não finitos e quantidades negativas são rejeitados de imediato, então uma entrada alucinada não consegue envenenar o preço nem o ROI. As mesmas entradas produzem sempre os mesmos números, o que significa que um sócio pode auditar qualquer valor do documento até as suas entradas.

Essa é a regra geral com que construímos: o modelo propõe, o código decide. Onde um número carrega consequência de negócio (um preço, um score, uma cota), ele é calculado deterministicamente, e o trabalho do modelo termina em sugerir entradas.

O crítico que contesta

Primeiros rascunhos são confiantes e errados de formas sutis. A resposta do pipeline é um agente crítico adversarial cujo único trabalho é atacar o rascunho: afirmações sem sustentação, seções fracas, inconsistências entre a arquitetura e a estimativa. Seções reprovadas voltam para outra passada, dentro de um loop limitado, para que a pressão de qualidade seja estrutural em vez de depender de alguém relendo com atenção às 23h.

O que essa arquitetura compra

Três propriedades caem do design em vez de serem coladas depois: rastreabilidade (cada requisito do briefing mapeia para uma seção da resposta, com status), auditabilidade (cada número se reproduz a partir das entradas) e consistência (a estrutura do documento é imposta pelo pipeline, não pelo humor do dia).

A parte honesta

O Proposal Architect nasceu como um sistema de hackathon: o conhecimento em que ele se ancora é sintético por design, e ele não é (ainda) um deployment de cliente. O que o build validou foi a arquitetura: a fronteira determinística, o loop de crítica e o padrão de ancoragem sobreviveram a execuções reais, revisão adversarial e uma onda de hardening de segurança.

Essa arquitetura é o ponto. É a mesma regra que aplicamos a tudo que entregamos na Techmorphosys: inteligência onde ajuda, determinismo onde importa.