“Adding manpower to a late software project makes it later.” — Fred Brooks, The Mythical Man-Month, 1975
A maioria das empresas que experimenta agentes de IA chega ao mesmo ponto de ruptura: o agente funciona no demo, falha em produção.
Não é um problema de modelo. É um problema de arquitetura.
Agentes isolados não escalam. Agentes orquestrados, sim.
A diferença entre um sistema de IA que entrega resultados consistentes e um que produz outputs imprevisíveis não está na escolha do LLM. Está em como as responsabilidades são divididas, sequenciadas e validadas entre agentes especializados. É a diferença entre um freelancer sobrecarregado tentando fazer tudo e uma equipe de engenharia com papéis claros, handoffs definidos e critérios de aceite auditáveis.
O pipeline B.L.A.S.T. foi construído exatamente para resolver esse problema. Cinco fases. Cinco agentes especializados. Um contrato de execução determinístico do Sprint Goal ao deploy em produção.
O Problema que Ninguém Fala: Agentes Sem Fronteiras
Quando um único agente recebe o prompt “implemente essa feature”, ele tenta fazer tudo: entender o requisito, projetar a arquitetura, escrever o código, validar a lógica e fazer o deploy. O resultado é previsível: alucinações em decisões arquiteturais, código que ignora o que já existe no repositório, e zero rastreabilidade sobre o que foi decidido e por quê.
Esse é o modelo que a maioria das equipes ainda usa. E é fundamentalmente quebrado.
O problema não é a capacidade do modelo. É a ausência de separação de responsabilidades. Em engenharia de software, nenhuma equipe saudável pede para o mesmo desenvolvedor fazer discovery, arquitetura, implementação e QA no mesmo ciclo, sem comunicação entre as etapas. Com agentes de IA, essa intuição básica é ignorada com frequência.
O que acontece sem um pipeline estruturado
- Scope creep silencioso: o agente “adivinha” requisitos não especificados e os implementa
- Duplicação de código: sem acesso ao inventário existente, o agente recria o que já existe
- Decisões irreversíveis: mudanças arquiteturais são tomadas na fase de implementação, sem registro
- Falha em cascata: um erro na interpretação do requisito contamina todas as fases seguintes
- Sem auditoria: não há como saber o que foi decidido, quando e por qual razão
A solução não é um agente mais inteligente. É uma arquitetura que torna a inteligência previsível.
B.L.A.S.T.: Cinco Fases, Cinco Contratos
O B.L.A.S.T. não é um agente mais capaz. É um protocolo de orquestração que divide o ciclo de desenvolvimento em cinco fases sequenciais, cada uma executada por um agente com escopo estritamente delimitado, ferramentas específicas e critérios de saída auditáveis.
A lógica é simples: nenhum agente avança sem antes entregar um artefato verificável ao próximo.
| Fase | Agente | Input | Output | Modo |
|---|---|---|---|---|
| Blueprint | Blueprint Agent | Sprint Goal | PRD (prd-sprint-*.md) | Interativo |
| Link | Link Agent | PRD | Link Context (JSON) | Headless |
| Architect | Architect Agent | PRD + Link Context | Plano DAG (plan-sprint-*.json) | Headless |
| Stylize | Stylizer Agent | Plano DAG | Código em produção | Headless |
| Trigger | Trigger Agent | Status das tasks | Deploy + Doutrina atualizada | Headless |
Quatro dos cinco agentes operam em modo headless, sem interface de chat, sem interação com o usuário. Apenas o Blueprint Agent conversa com o CTO, e apenas para extrair o que o sistema precisa antes de entrar em modo de execução autônoma.
Esse design não é acidental. Cada ponto de interação humana é um ponto de latência. O pipeline B.L.A.S.T. minimiza esses pontos ao máximo, concentrando toda a coleta de requisitos em uma única fase estruturada antes de liberar os agentes para executar.
Fase por Fase: O que Cada Agente Faz (e o que é Proibido Fazer)
A força do B.L.A.S.T. não está apenas no que cada agente faz. Está no que cada agente é explicitamente proibido de fazer.
Blueprint: O Arquiteto de Requisitos
O Blueprint Agent conduz uma entrevista estruturada com o CTO, extraindo cinco dimensões do Sprint Goal: Definition of Done, superfície de contato (API, UI, CLI), modelo de dados, integrações externas e non-goals explícitos.
A regra mais importante dessa fase: o agente não avança sem confirmar cada resposta do usuário. Não há suposições. Não há interpretações livres. O output é um PRD salvo no R2 Storage, a Única Fonte da Verdade (SSoT) para todo o restante do pipeline.
Link: O Inspetor de Contexto
O Link Agent opera em silêncio absoluto. Ele lê o PRD, cruza com o inventário de código existente (code-map.md), verifica as variáveis de ambiente já configuradas e identifica segredos externos pendentes.
O que ele não faz: não interage com o usuário, não testa conexões dinamicamente, não bloqueia a sprint por causa de bindings nativos da Cloudflare. Sua única saída é um JSON transiente com status, missing_secrets e architect_notes passado diretamente ao próximo agente.
Architect: O Engenheiro Sênior
O Architect Agent transforma PRD e Link Context em um plano de execução serializado: um grafo de dependências (DAG) com tarefas atômicas, especialistas designados, workspaces isolados e critérios de aceite testáveis.
Sua regra de ouro é o Princípio de Escopo Mínimo: uma sprint típica deve ter entre 1 e 3 tarefas. Se o plano tem mais de 3 tarefas para um Sprint Goal simples, o agente está decompondo demais.
O Architect não escreve código. Ele projeta a planta baixa e define quem executa o quê.
Stylize: O Executor Isolado
O Stylizer Agent é recriado a cada tarefa com contexto zerado. Ele lê o plano, identifica a primeira tarefa com dependências concluídas, restaura contexto via system-rules.md e findings.md, e implementa exatamente o que foi especificado — nada mais.
YAGNI estrito: sem funcionalidades preventivas, sem “isso pode ser útil no futuro”. Se a tarefa diz “criar um endpoint GET /mcp”, o agente cria um endpoint GET /mcp.
Ao final de cada ciclo, o Stylizer atualiza o plano com o novo status da tarefa e registra descobertas no findings.md via append_findings, nunca sobrescrevendo, sempre acrescentando.
Trigger: O Guardião da Doutrina
O Trigger Agent é o último a executar e o mais estratégico em termos de longo prazo. Ele audita o código produzido (apenas em busca de segredos vazados, não de qualidade de código), promove o branch para main, faz o deploy para Cloudflare e, crucialmente, atualiza a Doutrina do sistema.
Doutrina é o conjunto de artefatos que torna cada sprint mais rápida e mais segura que a anterior: code-map.md (inventário de componentes), findings.md (lições aprendidas), changelog.md (histórico técnico) e SOPs (padrões arquiteturais reutilizáveis).
A sprint não termina no deploy. Termina quando o sistema aprendeu com ela.
O Princípio Que Une Tudo: Doutrina como Memória Institucional
Existe uma diferença fundamental entre um sistema de agentes que executa tarefas e um sistema de agentes que aprende com cada execução.
A maioria dos pipelines de IA opera no modo amnésico: cada sprint começa do zero, sem memória do que foi construído, do que falhou, do que foi decidido. O resultado é previsível. Os mesmos erros se repetem. As mesmas decisões são tomadas de novo. O custo por sprint não cai com o tempo.
O B.L.A.S.T. foi projetado para o oposto.
O conceito de Doutrina é o que diferencia o pipeline de qualquer outra abordagem de orquestração. Doutrina não é documentação. É o conjunto de artefatos ativos que os agentes leem obrigatoriamente antes de cada ciclo:
system-rules.md: stack global, variáveis de ambiente, convenções de códigocode-map.md: inventário completo de componentes, serviços e utilitários existentesfindings.md: decisões arquiteturais, desvios, bugs resolvidos e padrões validadosSOPs/: padrões reutilizáveis extraídos de sprints anteriores
Quando o Architect Agent lê o code-map.md antes de criar um plano, ele sabe que o pacote @witek/email já existe e não precisa ser recriado. Quando o Stylizer lê o findings.md, ele sabe que processar CSVs pesados via Cloudflare Queues é o padrão validado, não uma escolha a ser reinventada.
Cada sprint bem executada torna o sistema mais rápido e mais confiável na próxima. Não por mágica. Por acumulação estruturada de contexto.
Isso é o que separa Agentic Engineering de automação de tarefas. Automação executa. Engenharia aprende.
Por Que Isso Importa Agora
A pergunta que todo CTO deveria estar fazendo não é “qual modelo de IA devo usar?”. É “como estruturo meu sistema de agentes para que ele seja auditável, incremental e confiável em produção?”.
A resposta exige uma mudança de paradigma.
O modelo antigo: um agente generalista que tenta fazer tudo, com contexto ilimitado e responsabilidade difusa.
O modelo B.L.A.S.T.: agentes especializados com escopo cirúrgico, contratos de handoff explícitos e memória institucional acumulada.
A diferença não é filosófica. É operacional. Sistemas construídos sobre o modelo antigo têm custo por entrega que não cai com o tempo, porque cada sprint recomeça do zero. Sistemas construídos sobre o B.L.A.S.T. têm custo por entrega que cai progressivamente, porque cada sprint alimenta a Doutrina que acelera a próxima.
O que isso significa na prática
- Rastreabilidade total: cada decisão arquitetural tem um artefato (PRD, plano DAG, findings) que documenta o porquê
- Escopo controlado: o Blueprint Agent força o CTO a definir non-goals antes de qualquer linha de código ser escrita
- Custo previsível: o Architect Agent limita sprints a 1-3 tarefas, tornando o custo de tokens estimável
- Deploy confiável: o Trigger Agent é o único ponto de promoção para produção, com auditoria de segurança obrigatória
Orquestração de agentes não é sobre delegar tarefas para a IA. É sobre construir um sistema que entrega software com a mesma previsibilidade de uma equipe de engenharia sênior, mas na velocidade que só agentes autônomos conseguem atingir.
O B.L.A.S.T. não é o futuro da engenharia de software. É o presente para quem já entendeu que agentes sem arquitetura são apenas automação cara.
Prós e contras: Pipeline B.L.A.S.T. vs Agente Único
| Pipeline B.L.A.S.T. | Agente Único | |
|---|---|---|
| Rastreabilidade | Artefato verificável por fase | Output final sem auditoria |
| Escopo | Delimitado pelo Blueprint Agent | Scope creep silencioso |
| Custo por sprint | Previsível (1-3 tarefas) | Variável, difícil de estimar |
| Memória | Doutrina acumulativa entre sprints | Recomeça do zero |
| Complexidade | Mais setup inicial | Simples de começar |
Fontes
[1] Fred Brooks, “The Mythical Man-Month: Essays on Software Engineering,” Addison-Wesley, 1975.
[2] Google Cloud DORA Team, “Accelerate: State of DevOps Report,” 2023. Disponível em: dora.dev.
[3] Anthropic, “Building Effective Agents,” 2024.