O Pipeline da OQVA (Work In Progress)
É assim que usamos agentes de IA para construir ventures. Não está pronto. Partes quebram, partes mudam, partes são substituídas toda semana. Estamos publicando assim mesmo porque o pipeline não é o que nos define.
O Problema
Todo mundo que trabalha com IA já tem um pipeline. Só não chama assim.
Você abre um chat, faz um prompt para um agente, pega o resultado. Copia o resultado para outra ferramenta. Faz outro prompt para outro agente com novo contexto. Pega outro resultado. Cola em algum lugar. Revisa. Ajusta. Faz prompt de novo. Talvez você tenha três terminais abertos com Claude Code, cada um trabalhando em uma parte diferente, e você é o roteador — copiando contexto entre eles, decidindo o que roda primeiro, mantendo o controle do que está pronto e do que não está.
Isso é um pipeline. Só que é manual, vive na sua cabeça, e nada é registrado.
Dois problemas com isso.
Não escala. Se um projeto precisa de dez tasks em paralelo, você não vai abrir dez terminais e ficar cuidando de dez agentes. Vai fazer duas ou três por vez e virar o gargalo. Os agentes não são lentos. Você é.
Não tem memória. Quando termina, não existe registro do que aconteceu. Por que essa decisão foi tomada? O que o agente gerou na primeira tentativa? O que o revisor apontou? O que mudou entre a versão um e a versão quatro? Sumiu. Espalhado em janelas de chat que você já fechou.
Queríamos duas coisas: estruturar o pipeline manual para que os agentes trabalhem sem a gente sentado na frente, e manter o contexto completo de cada decisão, cada review, cada linha de código alterada e por quê.
É isso que estamos construindo.
A Stack
Tudo é self-hosted. Não por ideologia — por controle. Precisamos customizar cada camada, trocar modelos quando algo melhor aparece, e não depender de mudanças de preço ou limites de API de ninguém para manter o pipeline rodando.
- Plane — Gerenciamento de projetos. Cada projeto, cada task, cada transição de estado vive aqui. Usamos Pages para documentos longos (pesquisas, guias de marca, design systems) e Work Items para tasks rastreáveis. Estados customizados funcionam como etapas do pipeline — quando um work item muda de estado, coisas acontecem.
- n8n — Orquestração. O Plane envia webhooks a cada atualização. O n8n filtra o ruído e dispara workflows nas transições de estado que importam. Ele decide o que roda e quando.
- Redis — Fila simples. O n8n coloca jobs no Redis. Workers puxam do Redis. Só isso. Sem framework de jobs sofisticado.
- Docker — Cada worker é um container. Isolado, reproduzível, descartável. Escala colocando mais containers em mais máquinas.
- Mac Minis + VPS — A camada física. Todas as máquinas escutam a mesma fila do Redis. Um job não se importa se roda num Mac Mini embaixo de uma mesa ou num VPS em Frankfurt.
- Claude Code + Modelos Locais + Gemini — Os agentes dentro dos containers. Claude Code para tasks de código. Gemini para pesquisa e trabalho de marca. Modelos locais como Kimi para tasks específicas onde queremos velocidade ou privacidade. O modelo é uma flag — troca sem mexer no pipeline.
Projetos, tasks, transições de estado. Pages para documentos longos, Work Items para tasks rastreáveis. Cada ação registrada.
Webhooks do Plane → workflows nas transições de estado. Decide o que roda e quando.
Fila simples. n8n coloca jobs; workers puxam. Sem framework de jobs sofisticado.
Cada worker é um container. Isolado, reproduzível, descartável. Escala adicionando containers.
Camada física. Todos escutam a mesma fila do Redis. O job não se importa onde roda.
Claude Code, Gemini, modelos locais. O modelo é uma flag — troca sem mexer no pipeline.
Como tudo passa pelo Plane, cada ação fica registrada. Cada output de agente é uma Page vinculada. Cada review é um comentário. Cada transição de estado é logada. Daqui a seis meses, podemos abrir qualquer work item e ver o histórico completo — o que foi gerado, o que foi rejeitado, o que foi alterado, e qual foi o raciocínio em cada etapa. O contexto não desaparece quando você fecha uma aba. Ele vive no work item.
O Pipeline Interno
É assim que um novo venture sai de uma ideia e chega em algo que será construído.
Cada venture começa como um único work item no Plane. Esse work item viaja por um pipeline de estados. Cada estado ou dispara um worker de IA, ou exige uma revisão humana, ou ambos.
Estados do pipeline de ventures:
- New Idea → Paper Validation → Go / No Go → Conscious Contrast → Brand Verification → Design System & Copy → Design System & Copy Verification → Content And Traffic Loop → Validation Review → Design Creation → Design Creation Verification → Build or Recycle
Como funciona
Quando um work item entra em um estado de trigger — digamos, "Conscious Contrast" — o Plane dispara um webhook. O n8n intercepta, processa o payload, e coloca um job no Redis com todo o contexto que o worker precisa: a premissa, a análise de mercado, qualquer Page vinculada de etapas anteriores.
Um worker pega o job. Dentro do container, o agente de IA executa a task — nesse caso, gerar um guia de coerência de marca usando nosso Conscious Contrast Framework. O output é escrito de volta no Plane como uma Page vinculada ao work item.
Depois o work item avança para um estado de verificação. Um humano lê o output. Se está bom, avança. Se não está, adiciona comentários — no Plane ou diretamente no documento — e move de volta. O worker pega novamente com o novo contexto e itera.
Cada etapa adiciona Pages vinculadas ao work item: pesquisa de mercado, análise de CAC, diretrizes de marca, tom de voz, direção de copy. Quando um venture chega em "Build or Recycle," o work item tem um portfólio completo de documentos anexados — todos gerados por agentes, todos revisados por humanos, todos rastreáveis.
"Recycle" significa que achamos que os outputs precisam de mais uma passagem por parte do pipeline. Não é falha. É iteração.
É um processo de quatro mãos mais robôs. Humanos — nós e os founders — estão no loop em cada etapa de verificação.
O Pipeline de Código
Quando um venture chega em "Build," precisamos entregar software. Mesma infraestrutura, pipeline diferente.
Aqui o projeto no Plane é o produto em si. Cada work item é uma task de código. Usamos TaskMaster AI para decompor o escopo completo do projeto em tasks com dependências, para podermos paralelizar o trabalho entre múltiplos agentes.
Estados do pipeline de código:
- Backlog → Ready for Dev → In Progress / Blocked / Needs Input → In Review → Review Approved → Merge → Done
Como funciona
Quando uma task muda para "Ready for Dev," o n8n coloca um job no Redis. Um container worker pega. Dentro do container: acesso ao GitHub e Claude Code. O payload do job no Redis contém tudo que o agente precisa — a descrição da task, critérios de aceite, referência do repositório, convenções de branch, e contexto das tasks dependentes.
O agente clona o repositório, cria uma branch, escreve o código, e faz push.
A task avança para "In Review." Um worker diferente pega — rodando um modelo diferente do que escreveu o código. Isso é intencional. Se o mesmo modelo codifica e revisa, ele tende a achar seu próprio output aceitável. Um modelo diferente pega coisas diferentes.
Se o revisor encontra problemas, a task volta para desenvolvimento com os comentários do review. O agente de dev pega de novo, endereça o feedback, faz push novamente. Esse loop continua até o agente revisor aprovar.
Quando os agentes aprovam, um humano faz a revisão final. Se passa, avança para "Merge." Se não, adicionamos comentários no GitHub ou Plane e mandamos de volta.
Dependências e paralelismo
O Plane rastreia relacionamentos entre tasks. Se a Task B depende da Task A, a Task B fica em "Blocked" até a Task A chegar em "Merge." Uma vez desbloqueada, fica automaticamente disponível para um worker.
Tasks sem dependências rodam em paralelo. Múltiplos containers, múltiplos agentes, múltiplas tasks — tudo ao mesmo tempo. Se o TaskMaster quebra um projeto em quarenta tasks e dez delas não têm dependência entre si, dez agentes pegam simultaneamente.
Ninguém abre dez terminais. Ninguém copia contexto entre janelas. O pipeline resolve.
O gargalo nunca é "esperando um desenvolvedor." É o grafo de dependências.
Os Workers
Um worker é um container Docker com um trabalho simples: puxar uma task do Redis, executar, devolver o resultado.
O que tem dentro de um worker de código
- GitHub CLI (autenticado)
- Claude Code (ou qualquer modelo configurado)
- O contexto do job vindo do Redis (descrição da task, repositório, branch, dependências, restrições)
Só isso. O container não sabe nada sobre o Plane. Não sabe nada sobre o n8n. Não sabe nada sobre outros workers. Ele recebe um job, faz o job, reporta de volta. Todo o resto é orquestração.
Cada container é descartável. Se algo quebra, mata e sobe um novo. Sem estado para preservar. Sem ambiente para debugar.
Podemos escalar horizontalmente adicionando máquinas. Cada novo Mac Mini ou VPS entra na mesma fila do Redis. Um worker em São Paulo e um worker em Frankfurt puxam do mesmo pool. O pipeline não se importa onde o trabalho acontece.
O Que É Manual (Por Enquanto)
Não estamos fingindo que isso é totalmente autônomo. Isso é o que ainda precisa de um humano:
Um humano lê o output da IA e decide se avança. Estamos descobrindo quais checkpoints podemos confiar para automatizar.
Uma IA pode analisar um mercado. Não pode decidir se devemos apostar nele.
Cada venture envolve uma pessoa real com uma visão real. O pipeline apoia a conversa; não a substitui.
O review automatizado pega bastante coisa. O review humano existe porque já vimos agentes aprovarem código que funciona tecnicamente mas não pertence estruturalmente.
Cada checkpoint manual é uma pergunta: "temos confiança suficiente para remover isso?" Alguns dias automatizamos um. Outros dias algo quebra e adicionamos um de volta.
O pipeline muda toda semana.
Por Que Self-Hosted
Três razões.
Modificamos o Plane para nossos estados de pipeline e integramos o TaskMaster AI. Não dá para fazer isso com um SaaS que você não controla.
Hoje Claude Code e Gemini; amanhã outra coisa. O modelo é uma flag no job config. Trocar não mexe no pipeline.
Containers em Mac Minis que já temos são mais baratos que chamadas de API em volume. Dezenas de agentes em paralelo em múltiplos ventures — a conta importa.
Work In Progress
Este pipeline não está pronto. Toda semana encontramos algo que pode ser mais rápido, algo que quebrou, algo que um novo modelo resolve melhor do que o que estávamos usando.
Se você é um founder técnico e quer ver como isso funciona na prática, ou se tem interesse em construir algo junto: entre em contato.
Pontos principais
- O pipeline estrutura o trabalho dos agentes e mantém o contexto completo no Plane; cada decisão e output é rastreável.
- Stack self-hosted (Plane, n8n, Redis, Docker) dá controle sobre customização, modelos e custo em escala.
- O pipeline interno leva ventures da ideia ao build através de estados de trigger e verificação humana; o pipeline de código paraleliza tasks com workers que respeitam dependências.
- Workers são containers stateless; escala adicionando máquinas na mesma fila do Redis.
- Humanos ficam no loop nas etapas de verificação, Go/No Go, e conversa com cofounders; o pipeline evolui toda semana.