Uma ferramenta que promete coordenar semanas de trabalho entre agentes de IA costuma vir acompanhada de nuvem, assinatura mensal e promessas grandes. O OpenRig (abre em nova aba) segue o caminho inverso. Segundo a documentação oficial, é um software de código aberto que roda inteiramente no computador de quem o usa: sem serviço hospedado, sem plano pago, sem camada externa. A equipe que ele organiza é formada por agentes de programação como o Claude Code e o Codex, que passam a se comunicar, dividir tarefas e manter o trabalho andando enquanto o humano fornece direções gerais e feedback.
O projeto existe e está em movimento. No repositório oficial no GitHub (abre em nova aba), o código sob licença Apache 2.0 acumula 3.735 commits, o mais recente em 11 de outubro de 2026, e a versão corrente é a 0.6.9. O site afirma que o OpenRig é construído, desde março de 2026, pela própria rede de agentes que ele cria. O detalhe soa circular, e é essa mesmo a proposta: a ferramenta organiza equipes de agentes, e equipes de agentes participam do seu desenvolvimento.
O que exatamente é o OpenRig
A metáfora do próprio projeto ajuda a entender o lugar da ferramenta. Um "harness" (algo como arreio, em tradução livre) é o programa que envolve um modelo de IA e o transforma em agente capaz de ler arquivos, escrever código e executar comandos. O Claude Code e o Codex são exemplos. A frase resumida do site diz que a harness envolve o modelo, e a rig envolve as harnesses. Ou seja, o OpenRig fica uma camada acima, coordenando vários desses agentes como um único sistema. A equipe é definida num arquivo YAML, um formato de texto usado para configuração, e colocada para funcionar com um comando.

O que essa camada acrescenta é estrutura. Cada agente ocupa um "assento" com nome próprio, terminal próprio e responsabilidade própria. As tarefas ficam registradas numa fila compartilhada, as mensagens trafegam entre os membros e o contexto do projeto permanece disponível para todos. A equipe também é persistente: sobrevive ao fechamento das janelas e pode ser restaurada depois. O site vai além e sugere começar com cinco agentes, escalando para cinquenta ou cem conforme o trabalho cresce, com equipes que gerenciam outras equipes. São números apresentados pelo desenvolvedor, não resultados medidos por terceiros.
Como funciona uma divisão de trabalho
A página de demonstração (abre em nova aba) mostra o fluxo pretendido com uma cena de três terminais. Um agente líder, identificado como dev-lead@factory, recebe do programador humano o pedido de implementar um conjunto grande de funcionalidades ao longo de semanas. O líder divide o trabalho: a interface vai para dev-ui@factory, o comportamento do servidor vai para dev-app@factory. Cada tarefa vira um item rastreado, e cada especialista lê e reivindica a sua, o que garante um responsável nomeado para cada parte.
Dentro de cada tarefa, o especialista pode delegar investigações pequenas a subagentes temporários, que aparecem no terminal do agente pai. Eles examinam código existente e cobertura de testes e devolvem constatações, mas não se tornam membros da equipe. É uma extensão do que esses agentes de programação já fazem sozinhos, agora com limites definidos.
O ponto mais interessante da cena é o terceiro passo. Em vez de canalizar tudo pelo líder, dev-ui pergunta diretamente a dev-app qual conexão com o servidor usar. A resposta incorpora a investigação do backend: reutilizar o cliente compartilhado e o suporte a reconexão que já existe. Os especialistas coordenam entre si, e o líder fica com a função de acompanhar o progresso e reunir os resultados para revisão.
Há uma ressalva importante, e ela está na própria demonstração. A página adverte que as chamadas exibidas são encenações ilustrativas e que as respostas devolvidas pelos agentes são fictícias. A cena termina com as duas tarefas em andamento, não concluídas: as semanas de implementação estão à frente, e a troca mostra apenas como a equipe as inicia.
A fila que sustenta o trabalho longo
O que dá sustentação a essa promessa de semanas é um mecanismo burocrático de propósito. A documentação de coordenação (abre em nova aba), referente à versão 0.6.6, descreve a fila como linhas num banco de dados local. Cada item é uma unidade de trabalho com assento de destino, conteúdo, estado e um histórico de transições que só cresce, nunca é apagado.
A mecânica é detalhada. Uma tarefa pendente passa a "em progresso" quando o agente a reivindica. Para fechá-la, o agente precisa escolher um motivo de uma lista fixa: transferida, bloqueada, negada, cancelada, sem continuação ou escalada para um humano. A documentação separa entrega de aceitação: fechar um item registra que o trabalho foi entregue, e a fase seguinte do processo julga se aceita, num item próprio. A passagem de bastão entre dois agentes é uma única transação, em que a tarefa de origem se fecha e outra se abre no destino.
Os fluxos de trabalho seguem a mesma lógica prudente. A página de fluxos (abre em nova aba) mostra um agente consultando a posição atual de um projeto e lendo duas coisas: o roteiro escrito por um humano (construir, depois uma checagem combinada independente, depois um teste com pessoas) e um arquivo de evidências, que registra o que já passou em cada etapa. O agente interpreta o roteiro, examina as evidências e decide o próximo passo, avançando o fluxo com um comando explícito. Ler e avançar são ações separadas. A estrutura organiza o processo longo, mas o julgamento continua sendo do agente, com o humano no circuito nos pontos previstos.
O que muda em relação ao que já existe
As perguntas frequentes do projeto comparam a ferramenta com três alternativas que o público de programadores já conhece. As diferenças abaixo são afirmações da própria documentação, não de avaliações independentes.
Janelas de terminal comunso comando de inicialização restaura sessões, contexto, papéis e o grafo da equipeCrewAI e AutoGendefinem em código como agentes conversam; o OpenRig cuida da infraestrutura em que eles rodamAgent teams do Claude Codesão experimentais, desligados por padrão e pertencem a uma sessão; o rig mantém equipe permanenteA comparação com o docker-compose (ferramenta que descreve e sobe vários contêineres de software a partir de um arquivo de configuração) é a mais esclarecedora. O OpenRig não define o comportamento dos agentes nem escreve a lógica da conversa entre eles; isso fica com o Claude Code e o Codex. O que ele governa é a base sobre a qual tudo acontece: quem existe, quem tem qual tarefa, quem responde a quem e o que já foi entregue.
O que está demonstrado e o que é afirmação
Do lado comprovável estão a existência e o ritmo do projeto. O repositório público é ativo, a licença é aberta, a instalação é documentada em um comando e a documentação afirma que cada instrução foi extraída do texto de ajuda do próprio programa, o que reduz o risco de comandos descritos que não existem. O histórico de commits cobre o período de março a outubro de 2026 sem interrupções aparentes.
Do lado da afirmação fica quase tudo sobre o resultado. Que equipes de agentes coordenam projetos de semanas ou meses com menos supervisão, que trabalham durante a noite e avisam quando precisam de decisão, que escalam para dezenas ou centenas de assentos: tudo isso é a descrição do próprio desenvolvedor. O material divulgado não traz benchmark independente, estudo externo nem caso real documentado por terceiros. A demonstração mais detalhada, como visto, é encenada.
Os limites
As restrições documentadas são específicas, o que ajuda a avaliar a ferramenta com sobriedade.
- Memória de julgamento. A FAQ reconhece que salvar fatos que um agente aprendeu é relativamente fácil, mas salvar o raciocínio por trás das suas decisões é muito mais difícil de automatizar e segue em desenvolvimento. Para projetos de semanas, é exatamente esse tipo de memória que mais faria diferença.
- Requisitos técnicos. O sistema exige Node.js 22 ou 24 e o tmux, um gerenciador de janelas de terminal, e funciona em macOS ou Linux. No Windows, só há suporte via WSL2 (camada que executa Linux dentro do Windows), e os testes automatizados ainda não rodam nesse ambiente.
- Custo indireto. Não há chave de API separada: os agentes rodam como sessões normais de Claude Code ou Codex, consumindo a assinatura que o usuário já tiver. A FAQ não estabelece limite de agentes, mas diz que a capacidade depende da máquina e das assinaturas. Preços não aparecem no material.
- Tudo local. O daemon, o programa que mantém o estado da equipe, é um servidor HTTP local com banco SQLite, e a FAQ afirma que nada é enviado para fora. Não existe versão na nuvem, nem planos de criar uma. Isso preserva privacidade, mas significa que a máquina precisa ficar ligada e a infraestrutura é responsabilidade de quem usa.
Perguntas frequentes
O OpenRig é gratuito?
O software é, sim: código aberto sob licença Apache 2.0, sem plano pago e sem versão na nuvem. Os agentes, porém, rodam como sessões normais de Claude Code ou Codex, o que exige as assinaturas correspondentes desses serviços.
Funciona no Windows?
Não de forma nativa. No Windows, o caminho é usar o WSL2, e a documentação admite que os testes automatizados ainda não funcionam nesse ambiente. O suporte pleno é para macOS e Linux.
Preciso saber programar para usar?
A ferramenta coordena agentes de programação trabalhando em código, então o público natural é quem desenvolve software. Configurar a equipe exige editar um arquivo YAML e usar comandos de terminal, tarefas acessíveis para quem já programa.
Quantos agentes uma equipe pode ter?
A documentação não impõe limite pela ferramenta. A FAQ atribui a capacidade real à máquina usada e às assinaturas de Claude Code ou Codex que sustentam as sessões dos agentes.
Fontes
- What is OpenRig · openrig.dev
- Coordinate work that takes weeks — OpenRig · openrig.dev
- Coordination: assigning tasks to agents — OpenRig · openrig.dev
- Know what comes next — OpenRig · openrig.dev
- FAQ - OpenRig · openrig.dev · 30/04/2026
- GitHub - mvschwarz/openrig · github.com · 10/10/2026

