Pipeline Triad Pattern: Um Pipeline de Agentes de IA no Lugar de uma Equipe de Desenvolvimento
Descubra o Pipeline Triad Pattern, uma abordagem inovadora que substitui equipes de desenvolvimento tradicionais por um pipeline de agentes de IA. Este padrão promete acelerar o ciclo de vida de desenvolvimento de software (SDLC) em tarefas empresariais típicas, mantendo a segurança e o controle humano em pontos estratégicos.
MundiX News·15 de abril de 2026·15 min de leitura·👁 4 views
Pipeline Triad Pattern: Um Pipeline de Agentes de IA no Lugar de uma Equipe de Desenvolvimento
TL;DR
O Pipeline Triad Pattern não é um único agente de IA, mas um pipeline de tríades: Criador, Crítico e Árbitro. Cada tríade cobre seu próprio estágio do SDLC, com a intervenção humana ocorrendo apenas em 4 pontos de controle. Este padrão funciona melhor em tarefas empresariais típicas com regras formalizadas. Não é um substituto para CI/CD, mas sim uma camada de delegação baseada em agentes sobre a automação regular. As principais limitações são alucinações, qualidade dos prompts, processos organizacionais e a segurança do próprio pipeline.
Escopo:
Não é adequado para descoberta ou MVP. O padrão é projetado para produtos com arquitetura clara, padrões estabelecidos e regras de negócios documentadas. Quanto mais limpa a entrada, mais eficiente o pipeline.
O desenvolvimento empresarial ainda é estruturado como um pipeline de pessoas. Um analista leva uma semana para escrever as especificações. Um desenvolvedor leva mais duas semanas para codificar. Um revisor encontra bugs e os retorna. Um testador cobre os cenários. Um especialista em segurança escaneia. A equipe de operações implanta na produção. Entre cada etapa, há espera, troca de contexto, licenças médicas, férias e reuniões. Uma tarefa típica em um banco leva de 2 a 3 meses para chegar à produção.
Eu vi isso por dentro em projetos bancários. E agora vejo que, em 2026, o mesmo caminho – das especificações à implantação – para uma classe de tarefas empresariais típicas com lógica formalizada pode ser percorrido em horas. Não por um único agente mágico, mas por um pipeline de tríades de agentes, onde cada etapa é protegida por validação tripla, e um humano controla o processo em quatro pontos estratégicos.
Eu chamei isso de Pipeline Triad Pattern.
Na minha artigo anterior, descrevi o Jarvis Pattern – um manifesto de minimalismo de agente pessoal. A fórmula:
LLM (cérebro) + SO (mãos) + memória de arquivo (mapa de conhecimento) = especialista completo.
Meu agente umax cobre tarefas DevSecOps em modelos de nível médio. Um único agente em vários circuitos de engenharia pode cobrir o trabalho de um especialista.
Pipeline Triad é o próximo passo. Se Jarvis é o Jarvis de um Tony Stark específico, então Pipeline Triad é um pipeline desses Jarviss. Cada um é especializado, cada um conhece seu papel e, juntos, cobrem todo o SDLC – da análise à implantação.
O mercado oferece diferentes abordagens para essa tarefa. Devin e SWE-agent seguem o caminho de um único agente-desenvolvedor. Cursor e Copilot Workspace aprimoram o humano na IDE. CrewAI e LangGraph fornecem frameworks para orquestração de sistemas multiagentes. Pipeline Triad não é uma ferramenta nem um framework, mas um padrão de organização de processo. A diferença é fundamental: um framework ficará obsoleto em um ano, um padrão permanecerá. Ele pode ser implementado sobre qualquer uma das ferramentas listadas.
Fundamento: Sobre o que estamos construindo
No final de 2025, Antonio Gulli, Distinguished Engineer do escritório do CTO do Google, lançou o livro “Agentic Design Patterns” (Springer, 424 páginas) – a primeira sistematização séria de padrões de design de agentes de IA. 21 padrões, cada um com código e casos de uso. O principal contribuidor foi Marco Fago, que fez o código, diagramas e revisão do texto.
Paralelamente, Anthropic (“Building Effective Agents”), Lilian Weng da OpenAI (“LLM Powered Autonomous Agents”) e a própria OpenAI lançaram “A Practical Guide to Building Agents”. Todos os trabalhos chegam à mesma conclusão: os padrões básicos se cristalizaram. Os frameworks são telas diferentes, mas os padrões são os mesmos. Uma lista completa de fontes está no final do artigo.
Não vou recontar 424 páginas. Para Pipeline Triad, seis padrões são críticos:
Prompt Chaining (divisão em etapas menores – um LLM em uma pequena tarefa geralmente funciona melhor),
Routing (lógica condicional – o agente decide para onde mover a tarefa),
Parallelization (execução paralela – isso oferece um ganho em tarefas paralelizáveis, mas pode piorar o resultado em tarefas de raciocínio sequenciais; a multiagência não é gratuita),
Tool Use (chamada de ferramentas reais – curl, git, scanners de segurança),
Memory Management (memória de curto e longo prazo – os mesmos arquivos markdown do Jarvis Pattern) e
Reflection – autocrítica.
Vamos nos concentrar em Reflection com mais detalhes.
Por que uma tríade, não um único agente?
LLMs são ruins em encontrar erros em sua própria resposta. Huang et al. (ICLR 2024) mostraram: sem feedback externo, LLMs em tarefas de raciocínio geralmente não se autocorrigem bem e às vezes até se degradam. Isso não é absoluto – o modelo pode detectar um erro de digitação óbvio, mas muitas vezes não vê erros sistemáticos na lógica. Anthropic em “Building Effective Agents” tira uma conclusão prática disso: um gera, outro avalia e o processo se repete até que o resultado atinja a qualidade desejada.
Gulli formaliza isso como Producer-Critic. Um agente gera, o segundo critica. Funciona, mas não o suficiente. O crítico também pode cometer erros: ser muito rigoroso, perder um problema crítico, ficar obcecado com detalhes.
Portanto, estou adicionando um terceiro papel – Árbitro. Um juiz independente que verifica tanto o Criador quanto o Crítico.
O princípio maker-checker-approver é conhecido há muito tempo – é um padrão em processos bancários. A novidade do Pipeline Triad é a aplicação sistemática desse princípio a todo o ciclo de desenvolvimento, onde cada tríade é especializada para seu próprio estágio e trabalha com uma memória compartilhada.
A analogia é simples: um desenvolvedor escreve código, um revisor encontra problemas, um líder técnico toma uma decisão. Três papéis, três pontos de vista, minimização de erros. Apenas em vez de três pessoas que concordam por uma semana, – três agentes em minutos.
Ciclo interno da tríade: Criador -> Crítico -> Árbitro.
"Isso é apenas CI/CD?" – não
Uma diferença importante.
Jenkins, GitLab CI, TeamCity – isso é automação. Um script executa um linter, executa testes, constrói um build. Se um teste falhar, o pipeline fica vermelho. Tudo é determinístico: entrada idêntica = saída idêntica.
Pipeline Triad não é automação. É delegação.
O Crítico não apenas executa um linter. Ele analisa a lógica: “Não há verificação de direitos de acesso aqui, e de acordo com os regulamentos, apenas a função ACCOUNT_MANAGER pode chamar esta operação”. O Árbitro não apenas verifica uma lista de verificação. Ele toma uma decisão: “O comentário do Crítico é válido, estou retornando para revisão” ou “O Crítico está reclamando do estilo, mas o código está correto, estou passando”.
CI/CD executa instruções. A tríade interpreta o contexto e toma decisões dentro das regras estabelecidas. Um script não pode encontrar um cenário de negócios perdido ou notar que uma solução arquitetônica contradiz os padrões da empresa. Um agente pode, em alguns casos.
Ao mesmo tempo, Pipeline Triad não substitui CI/CD, mas o inclui: nas etapas 11 e 13, um pipeline automático regular funciona. Os agentes preparam, o CI/CD entrega.
Human-in-the-Loop: Controle sem Ilusões
Gulli destaca dois modos.
Human-in-the-Loop – um humano verifica, aprova, corrige.
Human-on-the-Loop – um humano define a estratégia, o agente executa de forma autônoma dentro da estrutura especificada.
Pipeline Triad usa ambos. A etapa 0 e os Human Gates são in-the-loop. As etapas do agente entre os gates são on-the-loop: um humano definiu as regras, descreveu as habilidades dos agentes e os critérios de qualidade, a tríade funciona sozinha.
Gulli escreve honestamente sobre as limitações: os humanos não escalam, a eficiência depende da qualificação do verificador, os dados confidenciais precisam ser anonimizados. É por isso que existem quatro Human Gates no Pipeline Triad, não quatorze – um humano está presente apenas onde o custo do erro é máximo.
Quadro: 14 etapas da ideia à produção
Por que sprints quando há um fluxo?
Sprints otimizam o trabalho das pessoas. Iteraçōes de duas semanas, retrospectivas, velocity – tudo porque as pessoas se cansam, ficam doentes, mudam de contexto. Agile é uma grande metodologia. Para pessoas.
Os agentes não se cansam. Não ficam doentes. Eles não mudam de contexto, porque cada um tem seu próprio contexto na memória. Quando os executores são agentes, a coordenação é simplificada.
Kanban é sobre o fluxo de tarefas, não sobre iterações. Uma tarefa é definida – uma tarefa é iniciada. A próxima não espera o final do sprint. Para um pipeline de agentes, este é um modelo natural. Agile não morre – é simplificado para um fluxo contínuo.
Modelo completo
Pipeline Triad: 14 etapas da ideia à produção
Criação de tarefa – Humano. Você formula uma tarefa e a coloca no quadro. A qualidade da declaração determina a qualidade de todo o pipeline. Garbage in - garbage out ainda se aplica.
Análise – Tríade. O Criador lê os requisitos, a base de conhecimento, os padrões da empresa. Escreve as especificações técnicas. O Crítico procura buracos: cenários perdidos, conflitos com a arquitetura, ambiguidades. O Árbitro decide se as especificações estão prontas ou não.
Validação de requisitos – Human Gate #1. O gate mais barato. Pegar um erro nos requisitos leva horas. Pegar no código leva dias. Pegar na produção leva meses e dinheiro.
Desenvolvimento – Tríade. O Criador escreve o código. O Crítico com o prompt “você é um Senior Developer rigoroso” procura bugs, vulnerabilidades, violações de estilo. O Árbitro toma uma decisão.
Revisão de código – Tríade. Revisão de código: arquitetura, desempenho, capacidade de manutenção. Se FAIL - retornar à etapa 3.
Teste – Tríade. O Criador gera e executa testes. O Crítico analisa a cobertura, procura cenários perdidos. Um agente pode executar significativamente mais técnicas em paralelo e mais rápido do que uma pessoa normalmente faz: boundary testing, mutation testing, property-based, fuzz testing.
Regressão – Tríade. Um conjunto completo de testes de todo o sistema. O Criador executa, o Crítico analisa as falhas, o Árbitro toma uma decisão.
Segurança – Tríade. Escaneamento de código e dependências em busca de vulnerabilidades: SAST, DAST, verificação de bibliotecas de terceiros em busca de vulnerabilidades conhecidas. Vulnerabilidades críticas - bloqueador, retornar ao desenvolvimento.
Aprovação de prontidão – Human Gate #2. A pessoa responsável analisa o resultado de todas as etapas: código, testes, segurança. Dá o sinal verde.
Preparação de artefatos – Tríade. Documentação de lançamento: plano de teste, protocolos de aceitação, documentação do usuário, notas de lançamento, notificação das partes interessadas. O Crítico verifica a integridade. O Árbitro confirma.
Aprovação de implantação – Human Gate #3. A equipe de operações confirma a prontidão da infraestrutura e a disponibilidade de um plano de rollback.
Implantação no staging – Automático. CI/CD implanta no ambiente de teste.
Confirmação de produção – Human Gate #4. Verificação no staging: cenários básicos funcionam, as métricas estão normais. Isso é obrigatório em fintech. O custo de um erro na produção é medido em dinheiro e reputação.
Implantação em produção – Automático. Implantação no ambiente de produção.
Modelo operacional do pipeline
Pipeline Triad não é apenas um conjunto de papéis, mas um contrato de execução. Cada etapa é obrigada a produzir um artefato formalizado, critérios de aceitação, um log de comentários do Crítico e uma decisão do Árbitro. A próxima etapa não começa a funcionar até receber um pacote de entrada válido. Isso transforma o pipeline de um conjunto de prompts em um processo de engenharia reproduzível.
O que isso significa na prática. Cada etapa emite:
Artefato – o que exatamente sai da etapa. A etapa 1 emite especificações técnicas no formato: requisitos, contrato de API, regras de negócios, edge cases. A etapa 3 emite um diff e uma descrição das mudanças. A etapa 5 emite um relatório de cobertura e uma lista de testes com falha. O formato do artefato é descrito na habilidade do agente – o mesmo markdown do Jarvis Pattern.
Critérios PASS/FAIL – o que é considerado uma passagem bem-sucedida. Para análise: todos os cenários são cobertos, não há ambiguidades, não há conflitos com a arquitetura. Para segurança: não há vulnerabilidades críticas/altas. Para teste: a cobertura não é inferior ao limite, não há testes com falha. Os limites são definidos pela configuração da etapa.
Trace – quem propôs o quê, quem rejeitou o quê e por quê. O Criador propôs X. O Crítico encontrou o problema Y com justificativa. O Árbitro tomou a decisão Z com um motivo. Tudo é escrito no log da etapa. Isso não é lixo de serviço, mas uma trilha de auditoria.
Decisão do Árbitro – PASS, FAIL ou PARTIAL. PASS – o artefato passa. FAIL – retornar com uma indicação do motivo. PARTIAL – o artefato passa com comentários que precisam ser levados em consideração na próxima etapa.
Onde isso é escrito. No caso mais simples – uma estrutura de arquivos na memória do agente, como no Jarvis Pattern. Para produção – armazenamento externo: Git para artefatos, sistema de log para trace, painel para o estado do quadro.
Limites de aplicabilidade
O padrão funciona melhor onde as regras de negócios já estão descritas, os padrões são conhecidos e o resultado pode ser verificado por artefatos e testes. É menos adequado para tarefas de pesquisa, domínios fracamente formalizados e grandes mudanças entre equipes, onde o principal problema não é a execução, mas a incerteza e a coordenação.
Adequado para:
change requests e bugfixes, CRUD/API-endpoints, integrações, mudanças de infraestrutura, tarefas empresariais típicas com regulamentos.
Não adequado para:
arquitetura greenfield sem padrões maduros, P&D com especificações pouco claras, grandes refatorações entre equipes, domínios onde parte do conhecimento vive na cabeça, não em documentos.
Exemplo: uma tarefa passa pelo pipeline
Para aqueles que trabalham com backend bancário – uma execução específica. Tarefa: adicionar um REST endpoint /api/v2/accounts/{id}/freeze para congelar a conta de um cliente. Uma tarefa empresarial típica de dificuldade média: você precisa levar em consideração as regras de negócios, a segurança e a integração com o sistema existente.
Etapa 0. O arquiteto coloca no quadro: endpoint, regras de negócios, link para os regulamentos de congelamento.
Etapa 1. Análise. O Criador lê os regulamentos, olha a documentação dos endpoints existentes, escreve as especificações: método HTTP, formato de solicitação/resposta, validações de negócios, códigos de erro, requisitos de log. Crítico: “O comportamento não é descrito em caso de congelamento parcial – e se houver pagamentos automáticos agendados na conta?” O Árbitro confirma o comentário, retorna. Segunda passagem – o Criador adiciona um cenário. O Crítico está satisfeito. O Árbitro passa.
Etapa 2. Human Gate. Arquiteto: o cenário com pagamentos automáticos é levado em consideração, tudo está no lugar, eu passo. 15 minutos.
Etapa 3. Desenvolvimento. O Criador escreve um controlador, um serviço, uma camada de trabalho com o banco de dados, uma migração. Crítico: “Não há verificação de direitos de acesso. Quem pode chamar freeze? A autorização de função é necessária.” Ciclo. O Criador adiciona. Crítico: OK. O Árbitro passa.
Etapa 4. Revisão de código. A tríade verifica a nomenclatura, o tratamento de erros, a segurança de threads, a idempotência.
Etapa 5. Teste. O Criador faz testes unitários, de integração e negativos. Crítico: “Não há teste de corrida – duas chamadas paralelas de freeze para uma conta.” Ciclo.
Etapas 6-7. A regressão passa. O scanner de segurança está limpo.
Etapa 8. Human Gate. O arquiteto verifica o resultado: código, testes, relatório de segurança. Tudo está limpo. 20 minutos.
Etapas 9-13. Documentação, aprovação de operação, staging, verificação, produção.
Como resultado, o tempo humano: definição (10 minutos) + verificação de requisitos (15 minutos) + aprovação (20 minutos) + aprovação de implantação e verificação de staging (15 minutos) = aproximadamente 1 hora.
Em uma empresa clássica, a mesma tarefa geralmente leva de 2 a 3 semanas: análise, desenvolvimento, espera pela revisão, teste, segurança, documentação. Aqui – cerca de uma hora de tempo humano mais o trabalho da máquina do pipeline.
Aviso: esses números se referem a tarefas onde a lógica de negócios já está descrita nos regulamentos e não requer longas aprovações. Se você precisar obter a aprovação de um advogado, um oficial de compliance e três analistas de diferentes departamentos, o Pipeline Triad não teletransportará os processos organizacionais. Acelera o trabalho técnico.
Economia: quanto custa um pipeline
Você precisa contar em dois modelos – via API e via assinatura.
Cálculo via API
Uma passagem da tríade – são três chamadas de LLM: Criador, Crítico, Árbitro. Cada chamada – aproximadamente 10-20K de entrada e 2-5K de saída. Com 2-4 passagens da tríade por etapa e 7 etapas de agente, obtemos 42-84 chamadas por tarefa.
Cálculo aproximado: aproximadamente 1-2M de tokens de entrada e 200-400K de tokens de saída. Em termos monetários, para um modelo de nível médio, isso dá uma ordem de $6-12 por execução completa de uma tarefa.
Esta é uma estimativa. O consumo real depende da complexidade da tarefa, do tamanho do contexto e do número de retornos para revisão. Para tarefas simples, pode ser $3-5, para tarefas com um grande contexto e muitas iterações – $15-20.
Cálculo via assinatura
A assinatura é quase sempre mais barata do que a API, porque é subsidiada pelo provedor. Mas não há aritmética precisa lá: os limites flutuam, as tarefas variam em dificuldade e a intensidade do trabalho depende de uma janela específica, modelo e carga.
Na prática, isso significa uma coisa: uma assinatura é conveniente para pilotos, um estande pessoal e um número limitado de quadros. Para um fluxo de produção estável, você terá que contar via API e definir limites.
Comparação
Uma equipe empresarial típica para um produto – são analistas, desenvolvedores, testadores, DevOps, especialista em segurança, líder técnico, PM. Mesmo uma semana de trabalho de tal equipe – é uma ordem de magnitude diferente. Uma tarefa que antes levava metade da equipe duas semanas, aqui potencialmente passa pelo pipeline durante o almoço.
Métricas de qualidade
Economia sem KPIs de qualidade – é velocidade para lugar nenhum. Quatro métricas sem as quais o padrão não pode ser considerado pronto para produção:
Lead time – da definição da tarefa ao staging/prod. Para uma tarefa CRUD típica, o valor alvo é horas, não dias.
Rework rate – a porcentagem de retornos entre as etapas. Se 80% das tarefas retornarem do desenvolvimento para a análise, o problema está na definição ou na habilidade da tríade de análise.
Defect escape rate – bugs que passaram pelo pipeline e foram descobertos na produção. A principal métrica de qualidade.
Human touch time per task – quanto tempo real uma pessoa gastou em uma tarefa: definição, validação, aprovações.
Cost per task é rastreado como uma métrica financeira, mas não é um KPI de qualidade. Um resultado ruim barato é pior do que um resultado bom caro.
Onde isso quebra
LLM alucina a lógica de negócios. Um agente pode inventar uma regra que não está nos regulamentos. A tríade reduz o risco, mas não o elimina completamente.
Custo de um erro nas primeiras etapas. Se a tríade na análise tomou uma decisão arquitetônica errada e o Human Gate perdeu, todas as etapas subsequentes farão perfeitamente, mas não o que é necessário.
Dependência da qualidade dos prompts. A habilidade de cada agente – o que ele faz, o que ele olha, quais são os critérios – é um trabalho delicado. Um Crítico mal descrito irá perder tudo ou rejeitar tudo.
Os processos organizacionais não desaparecem. O pipeline acelera o trabalho técnico. Reuniões, aprovações e política permanecem.
Custo em escala. $6-12 por tarefa via API – não é caro. Mas 20 quadros com 50 tarefas por semana – isso já é um dinheiro perceptível em tokens. Ainda mais barato do que a folha de pagamento, mas isso terá que ser orçado.
Segurança do pipeline
O bloco “segurança” na etapa 7 é sobre o produto. Mas quem protege o próprio pipeline? Se um agente tem acesso ao repositório, CI/CD e segredos, esta é uma superfície de ataque separada.
Isolamento de agentes por direitos. O Criador escreve o código, mas não faz merge no main. O Crítico lê o código, mas não o altera. O Árbitro toma uma decisão, mas não toca nos arquivos. O menor privilégio é obrigatório.
Escopo de leitura/escrita por repositórios. O agente de análise lê os regulamentos e padrões, mas não tem acesso ao código-fonte. O agente de desenvolvimento trabalha em um branch de recurso, não no main.
Proibição de acesso direto à produção. Mesmo o agente de implantação não entrega diretamente. Ele inicia o pipeline CI/CD, que executa o trabalho real. Os segredos vivem no CI/CD, não na memória do agente.
Log de auditoria de todas as ações. Cada chamada de ferramenta, cada leitura de arquivo, cada comando – são registrados. Isso não é para paranoia, mas para postmortem.
Policy engine sobre o uso de ferramentas. Antes de chamar uma ferramenta, o policy engine verifica se um agente com essa função tem o direito de usar essa ferramenta neste contexto. Isso não é uma restrição de prompt, mas uma imposição no nível do orquestrador.
Classificação de dados. Nem todos os dados podem ser fornecidos ao modelo. PII, credenciais, segredos comerciais devem ser filtrados antes de entrar no contexto do agente.
Sem isso, qualquer especialista em segurança dirá: “Bonito, mas você apenas transferiu o risco da cadeia de suprimentos para dentro do orquestrador LLM”. E estará certo.
Rollback e incidentes
O caminho para a implantação é descrito. Não há caminho de volta. E este é um buraco.
Quem inicia o rollback. No modelo Pipeline Triad – apenas um humano. Se houver degradação das métricas após o lançamento, a equipe de operações inicia o rollback.
O agente faz isso. Não. Mas a tríade pode participar do postmortem: analisar o trace, procurar qual etapa perdeu o problema e preparar um fix-forward.
O que acontece em caso de degradação. O monitoramento detecta uma anomalia. A equipe de operações recebe um alerta. Se a solução for rollback, o CI/CD reverte para a versão anterior. O pipeline é colocado em espera durante este tempo.
Postmortem. A tríade analisa o relatório de incidente, diff, trace, métricas antes e depois. O resultado é uma atualização das habilidades da etapa responsável. Assim, o ciclo de melhoria do pipeline é concluído.
Orquestração de tarefas
Ao escalar para uma única base de código, várias tarefas são executadas e os conflitos surgem imediatamente.
Conflito de contextos – enquanto a tarefa A passou pela análise, a tarefa B já mudou o código. O contexto da tarefa A está desatualizado.
Corrida pela memória compartilhada – os agentes leem e escrevem em uma base de conhecimento comum. A versionamento ou o bloqueio otimista são necessários.
Conflito de migrações – duas tarefas adicionam colunas à mesma tabela.
Conflito de branch de lançamento – um branch é mesclado primeiro, o segundo deve ser rebaseado.
Obsolescência do artefato – um artefato da etapa 3 pode se tornar inválido no momento da etapa 8, se outras mudanças já tiverem avançado.
A solução é uma camada de orquestração sobre o quadro. Não um super-agente separado, mas um conjunto de regras: bloqueio de arquivos ou módulos durante uma tarefa ativa, rebase e revalidação em caso de conflito, gráfico de dependência entre as tarefas. Isso não é rocket science, mas sem isso a escala empresarial não funciona.
"E mostre um quadro de trabalho"
Uma pergunta justa. Pipeline Triad no momento da publicação – é um padrão, verificado em etapas separadas no meu estande. O agente umax do Jarvis Pattern cobre as etapas DevSecOps do pipeline: segurança, CI/CD, infraestrutura. A tríade Criador-Crítico-Árbitro é executada na análise e revisão de código.
Um pipeline completo de 14 etapas com um quadro de trabalho – é o próximo passo.
Estou publicando isso como um padrão, não como um produto acabado, porque a arquitetura do processo é mais importante do que a implementação específica. O Jarvis Pattern também começou como um manifesto e depois rapidamente se transformou em um sistema de trabalho. A lógica aqui é a mesma.
Escala: de um quadro para uma empresa
Uma tríade por etapa – é o mínimo. Para uma grande empresa, parece assim:
10 Criadores trabalham em paralelo em 10 tarefas
10 Críticos verificam em paralelo
10 Árbitros tomam decisões em paralelo
Um quadro = um produto ou serviço. 20 produtos = 20 quadros. 24/7. Sem pausas. Pela manhã, artefatos prontos já estão no quadro, aguardando aprovação no Human Gate.
A paralelização funciona para tarefas independentes. Tarefas com dependências requerem orquestração: SLAs entre as tarefas, priorização por meio de um humano, estratégias de merge. Este é um tópico separado que está além do escopo deste artigo.
O principal trabalho ao escalar – não é código, mas uma descrição das habilidades: o que cada agente faz, o que ele olha, onde ele escreve, onde ele commita. Os mesmos arquivos markdown do Jarvis Pattern, apenas para cada função na tríade.
Equipe mínima
É nisso que o estado se transforma com o Pipeline Triad:
Arquiteto/líder técnico (1 pessoa). Define as tarefas, valida os requisitos, aprova a prontidão. Esta é uma pessoa que vê o quadro geral, entende o contexto de negócios e pode avaliar rapidamente se a tríade entendeu corretamente a tarefa.
Operações/exploração (1 pessoa). Aprova a implantação, verifica o staging, é responsável pela infraestrutura, rollback e monitoramento na produção.
Analista de negócios (opcional, para domínios complexos). Se o produto funciona em uma regulamentação pesada, você precisa de uma pessoa que verifique a lógica de negócios nas etapas 2 e 8.
Total: 2-3 pessoas.
Não porque os outros não sejam necessários. Seu trabalho é realizado pelo pipeline. Mas essas 2-3 pessoas devem ser fortes. Um júnior não puxará o papel do único arquiteto em um pipeline de 7 etapas de agente. Aqui você precisa de um Senior+ que veja o sistema como um todo e possa avaliar em 15 minutos se os agentes trabalharam corretamente. Pipeline Triad não reduz os requisitos para as pessoas. Reduz radicalmente seu número.
O que é necessário para uma implementação de nível de produção
Lista de verificação. Sem nenhum dos itens, este é um protótipo, não produção.
Catálogo de habilidades – habilidades descritas para cada função na tríade em cada etapa.
Policy engine – direitos de acesso de agentes a ferramentas, repositórios, segredos.
Esquema de artefato – formato do artefato em cada etapa.
Eval harness – um conjunto de tarefas de referência com respostas conhecidas.
Log de auditoria – trace completo de todas as ações dos agentes.
Política de rollback – quem inicia o rollback, como ele é executado, o que o pipeline faz durante este tempo.
Cost guardrails – limites de tokens por tarefa, por quadro, por dia.
Sem isso, o circuito do agente permanecerá um estande de demonstração.
Quando o gargalo não está mais no desenvolvimento, mas nas pessoas
Há outro efeito que não é óbvio até que você o veja ao vivo. Quando o circuito técnico acelera drasticamente, a organização não consegue se adaptar à nova velocidade.
O problema não é mais que a análise, o código, os testes e a implantação estão indo muito devagar. O problema é outro: as pessoas não conseguem formular tarefas, priorizar o backlog, validar o resultado e reconstruir o roadmap para o novo ritmo. Encontrar especialistas que entendam como trabalhar com tal circuito também não é fácil. Você pode ensinar, mas a adaptação organizacional ainda é mais lenta do que o próprio pipeline.
Na prática, isso parece incomum: em poucas semanas, um volume de trabalho é fechado, o que antes se estendia por meses. Em algum momento, o gargalo se desloca da engenharia para o gerenciamento de produtos e mudanças. O pipeline não está preso ao código. Ele está preso à capacidade das pessoas de ter tempo para inventar, selecionar e confirmar as próximas tarefas.
No limite, isso dá um efeito estranho para uma empresa clássica: o backlog do produto acaba.
Sem cartão para começar · Planos a partir de R$49/mês
Pipeline Triad Pattern: Um Pipeline de Agentes de IA no Lugar de uma Equipe de Desenvolvimento
TL;DR
O Pipeline Triad Pattern não é um único agente de IA, mas um pipeline de tríades: Criador, Crítico e Árbitro. Cada tríade cobre seu próprio estágio do SDLC, com a intervenção humana ocorrendo apenas em 4 pontos de controle. Este padrão funciona melhor em tarefas empresariais típicas com regras formalizadas. Não é um substituto para CI/CD, mas sim uma camada de delegação baseada em agentes sobre a automação regular. As principais limitações são alucinações, qualidade dos prompts, processos organizacionais e a segurança do próprio pipeline.
Escopo:
Não é adequado para descoberta ou MVP. O padrão é projetado para produtos com arquitetura clara, padrões estabelecidos e regras de negócios documentadas. Quanto mais limpa a entrada, mais eficiente o pipeline.
O desenvolvimento empresarial ainda é estruturado como um pipeline de pessoas. Um analista leva uma semana para escrever as especificações. Um desenvolvedor leva mais duas semanas para codificar. Um revisor encontra bugs e os retorna. Um testador cobre os cenários. Um especialista em segurança escaneia. A equipe de operações implanta na produção. Entre cada etapa, há espera, troca de contexto, licenças médicas, férias e reuniões. Uma tarefa típica em um banco leva de 2 a 3 meses para chegar à produção.
Eu vi isso por dentro em projetos bancários. E agora vejo que, em 2026, o mesmo caminho – das especificações à implantação – para uma classe de tarefas empresariais típicas com lógica formalizada pode ser percorrido em horas. Não por um único agente mágico, mas por um pipeline de tríades de agentes, onde cada etapa é protegida por validação tripla, e um humano controla o processo em quatro pontos estratégicos.
Eu chamei isso de Pipeline Triad Pattern.
Na minha artigo anterior, descrevi o Jarvis Pattern – um manifesto de minimalismo de agente pessoal. A fórmula:
LLM (cérebro) + SO (mãos) + memória de arquivo (mapa de conhecimento) = especialista completo.
Meu agente umax cobre tarefas DevSecOps em modelos de nível médio. Um único agente em vários circuitos de engenharia pode cobrir o trabalho de um especialista.
Pipeline Triad é o próximo passo. Se Jarvis é o Jarvis de um Tony Stark específico, então Pipeline Triad é um pipeline desses Jarviss. Cada um é especializado, cada um conhece seu papel e, juntos, cobrem todo o SDLC – da análise à implantação.
O mercado oferece diferentes abordagens para essa tarefa. Devin e SWE-agent seguem o caminho de um único agente-desenvolvedor. Cursor e Copilot Workspace aprimoram o humano na IDE. CrewAI e LangGraph fornecem frameworks para orquestração de sistemas multiagentes. Pipeline Triad não é uma ferramenta nem um framework, mas um padrão de organização de processo. A diferença é fundamental: um framework ficará obsoleto em um ano, um padrão permanecerá. Ele pode ser implementado sobre qualquer uma das ferramentas listadas.
Fundamento: Sobre o que estamos construindo
No final de 2025, Antonio Gulli, Distinguished Engineer do escritório do CTO do Google, lançou o livro “Agentic Design Patterns” (Springer, 424 páginas) – a primeira sistematização séria de padrões de design de agentes de IA. 21 padrões, cada um com código e casos de uso. O principal contribuidor foi Marco Fago, que fez o código, diagramas e revisão do texto.
Paralelamente, Anthropic (“Building Effective Agents”), Lilian Weng da OpenAI (“LLM Powered Autonomous Agents”) e a própria OpenAI lançaram “A Practical Guide to Building Agents”. Todos os trabalhos chegam à mesma conclusão: os padrões básicos se cristalizaram. Os frameworks são telas diferentes, mas os padrões são os mesmos. Uma lista completa de fontes está no final do artigo.
Não vou recontar 424 páginas. Para Pipeline Triad, seis padrões são críticos:
Prompt Chaining (divisão em etapas menores – um LLM em uma pequena tarefa geralmente funciona melhor),
Routing (lógica condicional – o agente decide para onde mover a tarefa),
Parallelization (execução paralela – isso oferece um ganho em tarefas paralelizáveis, mas pode piorar o resultado em tarefas de raciocínio sequenciais; a multiagência não é gratuita),
Tool Use (chamada de ferramentas reais – curl, git, scanners de segurança),
Memory Management (memória de curto e longo prazo – os mesmos arquivos markdown do Jarvis Pattern) e
Reflection – autocrítica.
Vamos nos concentrar em Reflection com mais detalhes.
Por que uma tríade, não um único agente?
LLMs são ruins em encontrar erros em sua própria resposta. Huang et al. (ICLR 2024) mostraram: sem feedback externo, LLMs em tarefas de raciocínio geralmente não se autocorrigem bem e às vezes até se degradam. Isso não é absoluto – o modelo pode detectar um erro de digitação óbvio, mas muitas vezes não vê erros sistemáticos na lógica. Anthropic em “Building Effective Agents” tira uma conclusão prática disso: um gera, outro avalia e o processo se repete até que o resultado atinja a qualidade desejada.
Gulli formaliza isso como Producer-Critic. Um agente gera, o segundo critica. Funciona, mas não o suficiente. O crítico também pode cometer erros: ser muito rigoroso, perder um problema crítico, ficar obcecado com detalhes.
Portanto, estou adicionando um terceiro papel – Árbitro. Um juiz independente que verifica tanto o Criador quanto o Crítico.
O princípio maker-checker-approver é conhecido há muito tempo – é um padrão em processos bancários. A novidade do Pipeline Triad é a aplicação sistemática desse princípio a todo o ciclo de desenvolvimento, onde cada tríade é especializada para seu próprio estágio e trabalha com uma memória compartilhada.
A analogia é simples: um desenvolvedor escreve código, um revisor encontra problemas, um líder técnico toma uma decisão. Três papéis, três pontos de vista, minimização de erros. Apenas em vez de três pessoas que concordam por uma semana, – três agentes em minutos.
Ciclo interno da tríade: Criador -> Crítico -> Árbitro.
"Isso é apenas CI/CD?" – não
Uma diferença importante.
Jenkins, GitLab CI, TeamCity – isso é automação. Um script executa um linter, executa testes, constrói um build. Se um teste falhar, o pipeline fica vermelho. Tudo é determinístico: entrada idêntica = saída idêntica.
Pipeline Triad não é automação. É delegação.
O Crítico não apenas executa um linter. Ele analisa a lógica: “Não há verificação de direitos de acesso aqui, e de acordo com os regulamentos, apenas a função ACCOUNT_MANAGER pode chamar esta operação”. O Árbitro não apenas verifica uma lista de verificação. Ele toma uma decisão: “O comentário do Crítico é válido, estou retornando para revisão” ou “O Crítico está reclamando do estilo, mas o código está correto, estou passando”.
CI/CD executa instruções. A tríade interpreta o contexto e toma decisões dentro das regras estabelecidas. Um script não pode encontrar um cenário de negócios perdido ou notar que uma solução arquitetônica contradiz os padrões da empresa. Um agente pode, em alguns casos.
Ao mesmo tempo, Pipeline Triad não substitui CI/CD, mas o inclui: nas etapas 11 e 13, um pipeline automático regular funciona. Os agentes preparam, o CI/CD entrega.
Human-in-the-Loop: Controle sem Ilusões
Gulli destaca dois modos.
Human-in-the-Loop – um humano verifica, aprova, corrige.
Human-on-the-Loop – um humano define a estratégia, o agente executa de forma autônoma dentro da estrutura especificada.
Pipeline Triad usa ambos. A etapa 0 e os Human Gates são in-the-loop. As etapas do agente entre os gates são on-the-loop: um humano definiu as regras, descreveu as habilidades dos agentes e os critérios de qualidade, a tríade funciona sozinha.
Gulli escreve honestamente sobre as limitações: os humanos não escalam, a eficiência depende da qualificação do verificador, os dados confidenciais precisam ser anonimizados. É por isso que existem quatro Human Gates no Pipeline Triad, não quatorze – um humano está presente apenas onde o custo do erro é máximo.
Quadro: 14 etapas da ideia à produção
Por que sprints quando há um fluxo?
Sprints otimizam o trabalho das pessoas. Iteraçōes de duas semanas, retrospectivas, velocity – tudo porque as pessoas se cansam, ficam doentes, mudam de contexto. Agile é uma grande metodologia. Para pessoas.
Os agentes não se cansam. Não ficam doentes. Eles não mudam de contexto, porque cada um tem seu próprio contexto na memória. Quando os executores são agentes, a coordenação é simplificada.
Kanban é sobre o fluxo de tarefas, não sobre iterações. Uma tarefa é definida – uma tarefa é iniciada. A próxima não espera o final do sprint. Para um pipeline de agentes, este é um modelo natural. Agile não morre – é simplificado para um fluxo contínuo.
Modelo completo
Pipeline Triad: 14 etapas da ideia à produção
Criação de tarefa – Humano. Você formula uma tarefa e a coloca no quadro. A qualidade da declaração determina a qualidade de todo o pipeline. Garbage in - garbage out ainda se aplica.
Análise – Tríade. O Criador lê os requisitos, a base de conhecimento, os padrões da empresa. Escreve as especificações técnicas. O Crítico procura buracos: cenários perdidos, conflitos com a arquitetura, ambiguidades. O Árbitro decide se as especificações estão prontas ou não.
Validação de requisitos – Human Gate #1. O gate mais barato. Pegar um erro nos requisitos leva horas. Pegar no código leva dias. Pegar na produção leva meses e dinheiro.
Desenvolvimento – Tríade. O Criador escreve o código. O Crítico com o prompt “você é um Senior Developer rigoroso” procura bugs, vulnerabilidades, violações de estilo. O Árbitro toma uma decisão.
Revisão de código – Tríade. Revisão de código: arquitetura, desempenho, capacidade de manutenção. Se FAIL - retornar à etapa 3.
Teste – Tríade. O Criador gera e executa testes. O Crítico analisa a cobertura, procura cenários perdidos. Um agente pode executar significativamente mais técnicas em paralelo e mais rápido do que uma pessoa normalmente faz: boundary testing, mutation testing, property-based, fuzz testing.
Regressão – Tríade. Um conjunto completo de testes de todo o sistema. O Criador executa, o Crítico analisa as falhas, o Árbitro toma uma decisão.
Segurança – Tríade. Escaneamento de código e dependências em busca de vulnerabilidades: SAST, DAST, verificação de bibliotecas de terceiros em busca de vulnerabilidades conhecidas. Vulnerabilidades críticas - bloqueador, retornar ao desenvolvimento.
Aprovação de prontidão – Human Gate #2. A pessoa responsável analisa o resultado de todas as etapas: código, testes, segurança. Dá o sinal verde.
Preparação de artefatos – Tríade. Documentação de lançamento: plano de teste, protocolos de aceitação, documentação do usuário, notas de lançamento, notificação das partes interessadas. O Crítico verifica a integridade. O Árbitro confirma.
Aprovação de implantação – Human Gate #3. A equipe de operações confirma a prontidão da infraestrutura e a disponibilidade de um plano de rollback.
Implantação no staging – Automático. CI/CD implanta no ambiente de teste.
Confirmação de produção – Human Gate #4. Verificação no staging: cenários básicos funcionam, as métricas estão normais. Isso é obrigatório em fintech. O custo de um erro na produção é medido em dinheiro e reputação.
Implantação em produção – Automático. Implantação no ambiente de produção.
Modelo operacional do pipeline
Pipeline Triad não é apenas um conjunto de papéis, mas um contrato de execução. Cada etapa é obrigada a produzir um artefato formalizado, critérios de aceitação, um log de comentários do Crítico e uma decisão do Árbitro. A próxima etapa não começa a funcionar até receber um pacote de entrada válido. Isso transforma o pipeline de um conjunto de prompts em um processo de engenharia reproduzível.
O que isso significa na prática. Cada etapa emite:
Artefato – o que exatamente sai da etapa. A etapa 1 emite especificações técnicas no formato: requisitos, contrato de API, regras de negócios, edge cases. A etapa 3 emite um diff e uma descrição das mudanças. A etapa 5 emite um relatório de cobertura e uma lista de testes com falha. O formato do artefato é descrito na habilidade do agente – o mesmo markdown do Jarvis Pattern.
Critérios PASS/FAIL – o que é considerado uma passagem bem-sucedida. Para análise: todos os cenários são cobertos, não há ambiguidades, não há conflitos com a arquitetura. Para segurança: não há vulnerabilidades críticas/altas. Para teste: a cobertura não é inferior ao limite, não há testes com falha. Os limites são definidos pela configuração da etapa.
Trace – quem propôs o quê, quem rejeitou o quê e por quê. O Criador propôs X. O Crítico encontrou o problema Y com justificativa. O Árbitro tomou a decisão Z com um motivo. Tudo é escrito no log da etapa. Isso não é lixo de serviço, mas uma trilha de auditoria.
Decisão do Árbitro – PASS, FAIL ou PARTIAL. PASS – o artefato passa. FAIL – retornar com uma indicação do motivo. PARTIAL – o artefato passa com comentários que precisam ser levados em consideração na próxima etapa.
Onde isso é escrito. No caso mais simples – uma estrutura de arquivos na memória do agente, como no Jarvis Pattern. Para produção – armazenamento externo: Git para artefatos, sistema de log para trace, painel para o estado do quadro.
Limites de aplicabilidade
O padrão funciona melhor onde as regras de negócios já estão descritas, os padrões são conhecidos e o resultado pode ser verificado por artefatos e testes. É menos adequado para tarefas de pesquisa, domínios fracamente formalizados e grandes mudanças entre equipes, onde o principal problema não é a execução, mas a incerteza e a coordenação.
Adequado para:
change requests e bugfixes, CRUD/API-endpoints, integrações, mudanças de infraestrutura, tarefas empresariais típicas com regulamentos.
Não adequado para:
arquitetura greenfield sem padrões maduros, P&D com especificações pouco claras, grandes refatorações entre equipes, domínios onde parte do conhecimento vive na cabeça, não em documentos.
Exemplo: uma tarefa passa pelo pipeline
Para aqueles que trabalham com backend bancário – uma execução específica. Tarefa: adicionar um REST endpoint /api/v2/accounts/{id}/freeze para congelar a conta de um cliente. Uma tarefa empresarial típica de dificuldade média: você precisa levar em consideração as regras de negócios, a segurança e a integração com o sistema existente.
Etapa 0. O arquiteto coloca no quadro: endpoint, regras de negócios, link para os regulamentos de congelamento.
Etapa 1. Análise. O Criador lê os regulamentos, olha a documentação dos endpoints existentes, escreve as especificações: método HTTP, formato de solicitação/resposta, validações de negócios, códigos de erro, requisitos de log. Crítico: “O comportamento não é descrito em caso de congelamento parcial – e se houver pagamentos automáticos agendados na conta?” O Árbitro confirma o comentário, retorna. Segunda passagem – o Criador adiciona um cenário. O Crítico está satisfeito. O Árbitro passa.
Etapa 2. Human Gate. Arquiteto: o cenário com pagamentos automáticos é levado em consideração, tudo está no lugar, eu passo. 15 minutos.
Etapa 3. Desenvolvimento. O Criador escreve um controlador, um serviço, uma camada de trabalho com o banco de dados, uma migração. Crítico: “Não há verificação de direitos de acesso. Quem pode chamar freeze? A autorização de função é necessária.” Ciclo. O Criador adiciona. Crítico: OK. O Árbitro passa.
Etapa 4. Revisão de código. A tríade verifica a nomenclatura, o tratamento de erros, a segurança de threads, a idempotência.
Etapa 5. Teste. O Criador faz testes unitários, de integração e negativos. Crítico: “Não há teste de corrida – duas chamadas paralelas de freeze para uma conta.” Ciclo.
Etapas 6-7. A regressão passa. O scanner de segurança está limpo.
Etapa 8. Human Gate. O arquiteto verifica o resultado: código, testes, relatório de segurança. Tudo está limpo. 20 minutos.
Etapas 9-13. Documentação, aprovação de operação, staging, verificação, produção.
Como resultado, o tempo humano: definição (10 minutos) + verificação de requisitos (15 minutos) + aprovação (20 minutos) + aprovação de implantação e verificação de staging (15 minutos) = aproximadamente 1 hora.
Em uma empresa clássica, a mesma tarefa geralmente leva de 2 a 3 semanas: análise, desenvolvimento, espera pela revisão, teste, segurança, documentação. Aqui – cerca de uma hora de tempo humano mais o trabalho da máquina do pipeline.
Aviso: esses números se referem a tarefas onde a lógica de negócios já está descrita nos regulamentos e não requer longas aprovações. Se você precisar obter a aprovação de um advogado, um oficial de compliance e três analistas de diferentes departamentos, o Pipeline Triad não teletransportará os processos organizacionais. Acelera o trabalho técnico.
Economia: quanto custa um pipeline
Você precisa contar em dois modelos – via API e via assinatura.
Cálculo via API
Uma passagem da tríade – são três chamadas de LLM: Criador, Crítico, Árbitro. Cada chamada – aproximadamente 10-20K de entrada e 2-5K de saída. Com 2-4 passagens da tríade por etapa e 7 etapas de agente, obtemos 42-84 chamadas por tarefa.
Cálculo aproximado: aproximadamente 1-2M de tokens de entrada e 200-400K de tokens de saída. Em termos monetários, para um modelo de nível médio, isso dá uma ordem de $6-12 por execução completa de uma tarefa.
Esta é uma estimativa. O consumo real depende da complexidade da tarefa, do tamanho do contexto e do número de retornos para revisão. Para tarefas simples, pode ser $3-5, para tarefas com um grande contexto e muitas iterações – $15-20.
Cálculo via assinatura
A assinatura é quase sempre mais barata do que a API, porque é subsidiada pelo provedor. Mas não há aritmética precisa lá: os limites flutuam, as tarefas variam em dificuldade e a intensidade do trabalho depende de uma janela específica, modelo e carga.
Na prática, isso significa uma coisa: uma assinatura é conveniente para pilotos, um estande pessoal e um número limitado de quadros. Para um fluxo de produção estável, você terá que contar via API e definir limites.
Comparação
Uma equipe empresarial típica para um produto – são analistas, desenvolvedores, testadores, DevOps, especialista em segurança, líder técnico, PM. Mesmo uma semana de trabalho de tal equipe – é uma ordem de magnitude diferente. Uma tarefa que antes levava metade da equipe duas semanas, aqui potencialmente passa pelo pipeline durante o almoço.
Métricas de qualidade
Economia sem KPIs de qualidade – é velocidade para lugar nenhum. Quatro métricas sem as quais o padrão não pode ser considerado pronto para produção:
Lead time – da definição da tarefa ao staging/prod. Para uma tarefa CRUD típica, o valor alvo é horas, não dias.
Rework rate – a porcentagem de retornos entre as etapas. Se 80% das tarefas retornarem do desenvolvimento para a análise, o problema está na definição ou na habilidade da tríade de análise.
Defect escape rate – bugs que passaram pelo pipeline e foram descobertos na produção. A principal métrica de qualidade.
Human touch time per task – quanto tempo real uma pessoa gastou em uma tarefa: definição, validação, aprovações.
Cost per task é rastreado como uma métrica financeira, mas não é um KPI de qualidade. Um resultado ruim barato é pior do que um resultado bom caro.
Onde isso quebra
LLM alucina a lógica de negócios. Um agente pode inventar uma regra que não está nos regulamentos. A tríade reduz o risco, mas não o elimina completamente.
Custo de um erro nas primeiras etapas. Se a tríade na análise tomou uma decisão arquitetônica errada e o Human Gate perdeu, todas as etapas subsequentes farão perfeitamente, mas não o que é necessário.
Dependência da qualidade dos prompts. A habilidade de cada agente – o que ele faz, o que ele olha, quais são os critérios – é um trabalho delicado. Um Crítico mal descrito irá perder tudo ou rejeitar tudo.
Os processos organizacionais não desaparecem. O pipeline acelera o trabalho técnico. Reuniões, aprovações e política permanecem.
Custo em escala. $6-12 por tarefa via API – não é caro. Mas 20 quadros com 50 tarefas por semana – isso já é um dinheiro perceptível em tokens. Ainda mais barato do que a folha de pagamento, mas isso terá que ser orçado.
Segurança do pipeline
O bloco “segurança” na etapa 7 é sobre o produto. Mas quem protege o próprio pipeline? Se um agente tem acesso ao repositório, CI/CD e segredos, esta é uma superfície de ataque separada.
Isolamento de agentes por direitos. O Criador escreve o código, mas não faz merge no main. O Crítico lê o código, mas não o altera. O Árbitro toma uma decisão, mas não toca nos arquivos. O menor privilégio é obrigatório.
Escopo de leitura/escrita por repositórios. O agente de análise lê os regulamentos e padrões, mas não tem acesso ao código-fonte. O agente de desenvolvimento trabalha em um branch de recurso, não no main.
Proibição de acesso direto à produção. Mesmo o agente de implantação não entrega diretamente. Ele inicia o pipeline CI/CD, que executa o trabalho real. Os segredos vivem no CI/CD, não na memória do agente.
Log de auditoria de todas as ações. Cada chamada de ferramenta, cada leitura de arquivo, cada comando – são registrados. Isso não é para paranoia, mas para postmortem.
Policy engine sobre o uso de ferramentas. Antes de chamar uma ferramenta, o policy engine verifica se um agente com essa função tem o direito de usar essa ferramenta neste contexto. Isso não é uma restrição de prompt, mas uma imposição no nível do orquestrador.
Classificação de dados. Nem todos os dados podem ser fornecidos ao modelo. PII, credenciais, segredos comerciais devem ser filtrados antes de entrar no contexto do agente.
Sem isso, qualquer especialista em segurança dirá: “Bonito, mas você apenas transferiu o risco da cadeia de suprimentos para dentro do orquestrador LLM”. E estará certo.
Rollback e incidentes
O caminho para a implantação é descrito. Não há caminho de volta. E este é um buraco.
Quem inicia o rollback. No modelo Pipeline Triad – apenas um humano. Se houver degradação das métricas após o lançamento, a equipe de operações inicia o rollback.
O agente faz isso. Não. Mas a tríade pode participar do postmortem: analisar o trace, procurar qual etapa perdeu o problema e preparar um fix-forward.
O que acontece em caso de degradação. O monitoramento detecta uma anomalia. A equipe de operações recebe um alerta. Se a solução for rollback, o CI/CD reverte para a versão anterior. O pipeline é colocado em espera durante este tempo.
Postmortem. A tríade analisa o relatório de incidente, diff, trace, métricas antes e depois. O resultado é uma atualização das habilidades da etapa responsável. Assim, o ciclo de melhoria do pipeline é concluído.
Orquestração de tarefas
Ao escalar para uma única base de código, várias tarefas são executadas e os conflitos surgem imediatamente.
Conflito de contextos – enquanto a tarefa A passou pela análise, a tarefa B já mudou o código. O contexto da tarefa A está desatualizado.
Corrida pela memória compartilhada – os agentes leem e escrevem em uma base de conhecimento comum. A versionamento ou o bloqueio otimista são necessários.
Conflito de migrações – duas tarefas adicionam colunas à mesma tabela.
Conflito de branch de lançamento – um branch é mesclado primeiro, o segundo deve ser rebaseado.
Obsolescência do artefato – um artefato da etapa 3 pode se tornar inválido no momento da etapa 8, se outras mudanças já tiverem avançado.
A solução é uma camada de orquestração sobre o quadro. Não um super-agente separado, mas um conjunto de regras: bloqueio de arquivos ou módulos durante uma tarefa ativa, rebase e revalidação em caso de conflito, gráfico de dependência entre as tarefas. Isso não é rocket science, mas sem isso a escala empresarial não funciona.
"E mostre um quadro de trabalho"
Uma pergunta justa. Pipeline Triad no momento da publicação – é um padrão, verificado em etapas separadas no meu estande. O agente umax do Jarvis Pattern cobre as etapas DevSecOps do pipeline: segurança, CI/CD, infraestrutura. A tríade Criador-Crítico-Árbitro é executada na análise e revisão de código.
Um pipeline completo de 14 etapas com um quadro de trabalho – é o próximo passo.
Estou publicando isso como um padrão, não como um produto acabado, porque a arquitetura do processo é mais importante do que a implementação específica. O Jarvis Pattern também começou como um manifesto e depois rapidamente se transformou em um sistema de trabalho. A lógica aqui é a mesma.
Escala: de um quadro para uma empresa
Uma tríade por etapa – é o mínimo. Para uma grande empresa, parece assim:
10 Criadores trabalham em paralelo em 10 tarefas
10 Críticos verificam em paralelo
10 Árbitros tomam decisões em paralelo
Um quadro = um produto ou serviço. 20 produtos = 20 quadros. 24/7. Sem pausas. Pela manhã, artefatos prontos já estão no quadro, aguardando aprovação no Human Gate.
A paralelização funciona para tarefas independentes. Tarefas com dependências requerem orquestração: SLAs entre as tarefas, priorização por meio de um humano, estratégias de merge. Este é um tópico separado que está além do escopo deste artigo.
O principal trabalho ao escalar – não é código, mas uma descrição das habilidades: o que cada agente faz, o que ele olha, onde ele escreve, onde ele commita. Os mesmos arquivos markdown do Jarvis Pattern, apenas para cada função na tríade.
Equipe mínima
É nisso que o estado se transforma com o Pipeline Triad:
Arquiteto/líder técnico (1 pessoa). Define as tarefas, valida os requisitos, aprova a prontidão. Esta é uma pessoa que vê o quadro geral, entende o contexto de negócios e pode avaliar rapidamente se a tríade entendeu corretamente a tarefa.
Operações/exploração (1 pessoa). Aprova a implantação, verifica o staging, é responsável pela infraestrutura, rollback e monitoramento na produção.
Analista de negócios (opcional, para domínios complexos). Se o produto funciona em uma regulamentação pesada, você precisa de uma pessoa que verifique a lógica de negócios nas etapas 2 e 8.
Total: 2-3 pessoas.
Não porque os outros não sejam necessários. Seu trabalho é realizado pelo pipeline. Mas essas 2-3 pessoas devem ser fortes. Um júnior não puxará o papel do único arquiteto em um pipeline de 7 etapas de agente. Aqui você precisa de um Senior+ que veja o sistema como um todo e possa avaliar em 15 minutos se os agentes trabalharam corretamente. Pipeline Triad não reduz os requisitos para as pessoas. Reduz radicalmente seu número.
O que é necessário para uma implementação de nível de produção
Lista de verificação. Sem nenhum dos itens, este é um protótipo, não produção.
Catálogo de habilidades – habilidades descritas para cada função na tríade em cada etapa.
Policy engine – direitos de acesso de agentes a ferramentas, repositórios, segredos.
Esquema de artefato – formato do artefato em cada etapa.
Eval harness – um conjunto de tarefas de referência com respostas conhecidas.
Log de auditoria – trace completo de todas as ações dos agentes.
Política de rollback – quem inicia o rollback, como ele é executado, o que o pipeline faz durante este tempo.
Cost guardrails – limites de tokens por tarefa, por quadro, por dia.
Sem isso, o circuito do agente permanecerá um estande de demonstração.
Quando o gargalo não está mais no desenvolvimento, mas nas pessoas
Há outro efeito que não é óbvio até que você o veja ao vivo. Quando o circuito técnico acelera drasticamente, a organização não consegue se adaptar à nova velocidade.
O problema não é mais que a análise, o código, os testes e a implantação estão indo muito devagar. O problema é outro: as pessoas não conseguem formular tarefas, priorizar o backlog, validar o resultado e reconstruir o roadmap para o novo ritmo. Encontrar especialistas que entendam como trabalhar com tal circuito também não é fácil. Você pode ensinar, mas a adaptação organizacional ainda é mais lenta do que o próprio pipeline.
Na prática, isso parece incomum: em poucas semanas, um volume de trabalho é fechado, o que antes se estendia por meses. Em algum momento, o gargalo se desloca da engenharia para o gerenciamento de produtos e mudanças. O pipeline não está preso ao código. Ele está preso à capacidade das pessoas de ter tempo para inventar, selecionar e confirmar as próximas tarefas.
No limite, isso dá um efeito estranho para uma empresa clássica: o backlog do produto acaba.
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
