OpenRig: equipes de agentes que sobrevivem ao terminal e dividem semanas de trabalho

Coordenar semanas de trabalho entre agentes é a aposta central do OpenRig (abre em nova aba), um control plane de código aberto que transforma sessões de Claude Code (abre em nova aba), Codex e Pi em uma equipe persistente, com papéis nomeados, fila de tarefas e histórico de decisões. Segundo o próprio site do projeto, o OpenRig existe desde março de 2026 e seria construído pela própria rede de agentes que ele coordena. A afirmação é do projeto, não de terceiros, e convém lê-la com essa ressalva.

O que a ferramenta realmente é, porém, é menos especulativo que o slogan: um daemon local pequeno (processo que roda em segundo plano), um banco SQLite, um CLI chamado rig e uma interface de terminal. Os agentes são sessões ordinárias de Claude Code e Codex rodando em tmux (abre em nova aba). O OpenRig não usa chaves de API próprias: dirige as credenciais que você já tem. Ele se define pelo que não é: não é serviço em nuvem, não substitui Claude Code ou Codex, não é um framework de agentes.

Essa tríade de negações importa. Ela posiciona o OpenRig em uma faixa específica do ecossistema: não é a camada que raciocina nem a que executa, e sim a que lembra, nomeia, registra e recupera. Para avaliar se isso justifica adoção, vale separar três coisas: a mecânica documentada, o que o anúncio demonstra de fato e o que resta como alegação.

Assentos e subagentes: a fronteira que define o projeto

A unidade central do OpenRig é o seat (assento): uma sessão nomeada de agente que persiste independentemente da janela do terminal. O site do projeto estabelece a distinção com precisão. Um subagente é aposentado quando o trabalho termina e desaparece quando o terminal fecha. Um assento é diferente: o tmux mantém a sessão viva enquanto a máquina estiver ligada, e o assento pode ser trazido de volta pelo nome depois de um reboot.

A recuperação tem comportamento documentado e honesto sobre seus limites: restaurar um assento pode retomar o trabalho, reconstruí-lo, iniciá-lo do zero, exigir uma decisão do operador ou simplesmente falhar. Não há promessa de continuidade perfeita, e a documentação não fingi que existe.

Esse desenho ataca um problema concreto. Na apresentação do projeto no Hacker News, o fundador Mike Schwarz contou a motivação: seu arranjo de Claude Code com Codex formava "pequenas topologias de agentes de longa vida que trabalhavam bem juntos, mas o caos de terminais era intenso". O OpenRig nasceu como uma primitiva para salvar e recriar esses arranjos sob demanda.

Um daemon, um SQLite e uma fila: como a coordenação funciona

A documentação de coordenação (abre em nova aba), escrita contra a versão 0.6.6, descreve a fila de trabalho como a peça fundamental. Um item de fila é uma linha no banco do daemon com um assento de destino, um corpo, um estado e um histórico de transições do tipo append-only (só acrescenta, nunca apaga). Um exemplo real da documentação:

rig queue create --destination dev-impl@my-rig --body-file brief.md --mission search-experience --slice 01-search-page

O fluxo é explícito: um item pendente só avança quando um agente o reivindica com claim. Fechar como done exige um motivo de um conjunto fixo: handed_off_to, blocked_on, denied, canceled, no-follow-on ou escalation. E há um detalhe que revela o desenho do sistema: o fechamento registra entrega, não aceitação. A aceitação é o veredito da etapa seguinte, em sua própria linha da fila.

O handoff (transferência de responsabilidade) é atômico: a linha de origem fecha como handed-off e uma nova linha abre no assento de destino na mesma transação. Isso elimina a janela clássica de perda de trabalho em sistemas distribuídos caseiros, quando um lado transfere e o outro ainda não registrou.

Para perguntas simples, existe o rig send: comunicação direta entre assentos, sem criar tarefa nova. A página inicial dá o exemplo de pedir diretamente ao especialista de backend qual conexão usar, quando o projeto tem meses de decisões acumuladas. Os dois especialistas coordenam entre si sem canalizar cada detalhe pelo agente líder.

Duas camadas complementam a fila. Os workflows transformam uma sequência intencional de trabalho em estado durável, com uma divisão de papéis declarada na documentação de workflows (abre em nova aba): o dono decide quando uma etapa está pronta, o runtime é o escriba, não o portão. E os watchdogs existem porque um assento não consegue acordar a si mesmo: são tarefas persistidas no banco, sobrevivem a reinícios do daemon e disparam lembretes periódicos, esperam por um conjunto de artefatos, vigiam filas ociosas ou monitoram o uso de contexto de um assento antes que ele estoure o limite. A mesma página mede transcrições de contexto entre 113 mil e 153 mil tokens por MB, o que dá base para dimensionar quanto cabe em uma sessão.

Os watchdogs vêm com um aviso de autocrise: um watchdog com mensagem defasada é pior que nenhum. Quando a discussão a que ele se refere fecha, é preciso pará-lo ou reescrevê-lo. É o tipo de instrução que só se escreve depois de sentir o problema.

O projeto também fornece equipes prontas, definidas no site:

O que o anúncio demonstra e o que ele não demonstra

A demonstração de coordenação paralela (abre em nova aba) merece leitura atenta. O cenário mostra um desenvolvedor perguntando a um agente líder como abordar várias semanas de trabalho; o líder distribui interface e backend para dois especialistas, cada um com seus subagentes temporários de inspeção. A própria página admite que as chamadas de spawn_agent do Codex e do Claude Agent são ilustrações encenadas, e que os achados retornados são fictícios. O encerramento é igualmente honesto: as duas atribuições estão em andamento, não completas, e as semanas de implementação estão à frente.

Em outras palavras: o que está demonstrado é o início coordenado de um projeto longo, não sua execução. A alegação de que a equipe "pode enfrentar mais do que um agente consegue manter em vista" é plausível como desenho de sistema, mas o tour não mostra semanas de trabalho concluídas.

No Hacker News, Schwarz ofereceu uma analogia para capacidade distribuída: um rig de 10 agentes, cada um com janela de contexto de 1 milhão de tokens, poderia ser visto como se tivesse 10 milhões de tokens. Ele próprio marcou a frase como analogia para distribuição de contexto, não como benchmark medido. É a diferença entre um modelo mental e um resultado; o texto dele preserva essa distinção, e a análise deve preservar também.

O que existe de evidência empírica no material público é o relato do fundador: após alguns meses, diz ele, os rigs que gerencia exigem "muito menos babá" e permite administrar mais projetos ao mesmo tempo sem se sobrecarregar. É um testemunho de primeira pessoa, não um estudo. A página inicial não traz números de benchmark independentes nem estudos de caso de clientes, e nada no material consultado sugere que existam.

O ritmo de desenvolvimento é o dado mais sólido de vitalidade. A versão v0.6.9, lançada em 11 de outubro de 2026, reuniu doze mudanças, três delas de contribuidores externos, com correções de integração com Slack, comunicação entre hosts e recuperação do kernel do daemon. A nota da versão registra um detalhe relevante para quem opera: rig launch passou a aceitar ID de rig, não mais nome. A documentação (abre em nova aba), por sua vez, ainda descreve a 0.6.6, defasada em relação ao pacote publicado, o que exige atenção ao ler as páginas de referência. Até as notas de versão carregam a assinatura de coautoria de um modelo Claude, coerente com a narrativa de projeto construído por seus próprios agentes.

Como se compara: frameworks, orquestradores e uma camada de controle

A pergunta natural é por que não usar LangGraph (abre em nova aba), CrewAI (abre em nova aba) ou AutoGen (abre em nova aba), os frameworks de orquestração de agentes mais difundidos. A resposta do OpenRig é categórica: ele não é um framework e não substitui Claude Code ou Codex.

A diferença é de nível de abstração. Frameworks como LangGraph, CrewAI e AutoGen são bibliotecas com as quais você escreve código que chama modelos via API: o grafo de estados, a tripulação de papéis ou o padrão de conversa são construções do seu programa, e a unidade de execução é uma chamada de modelo. No OpenRig, a unidade é uma sessão interativa de agente de código já existente, com suas permissões, ferramentas e contexto. Você não programa o comportamento do agente; coordena agentes que já sabem trabalhar.

Isso tem consequências práticas dos dois lados. De um lado, não há custo de migração: quem já usa Claude Code ou Codex com assinatura ativa continua usando, com Node.js 22 ou 24 e tmux instalados (no Apple silicon, a documentação pede Node 22), e a instalação é um npm install -g @openrig/cli seguido de rig setup. De outro, abre mão do controle fino que um framework oferece: não se define o grafo de decisão, apenas os papéis, as filas e os gatilhos.

Contra o Temporal (abre em nova aba), motor de execução durável para código convencional, a comparação é de escala, não de categoria. O OpenRig tem persistência real (jobs sobrevivem a reinícios do daemon, estados em SQLite com histórico anexável), mas é um sistema local e recente, sem o amadurecimento operacional de um motor de workflows de produção. Quem precisa de garantias de execução distribuída, retries com política configurável e observabilidade de nível corporativo está fora do escopo do que o projeto declara entregar.

Sobre protocolo, Schwarz foi direto: o OpenRig não usa A2A (o protocolo aberto de comunicação entre agentes), mas tmux para mensagens entre agentes, além de um fluxo de eventos e uma fila próprios para tarefas e handoffs. A escolha é coerente com a filosofia do projeto: primitivas locais e simples em vez de padrões de indústria.

Há um contraponto técnico importante e confessado. O fundador declarou que o OpenRig não tenta resolver isolamento de agentes: eles compartilham rede e sistema de arquivos na máquina sob controle do operador. Como cada assento é uma sessão interativa completa com acesso a ferramentas, um agente comprometido por injeção de prompt tem alcance sobre tudo o que o host alcança. Isso é um trade-off arquitetural assumido, não uma lacuna escondida, e muda o cálculo de risco conforme o ambiente.

A trava real: revisão humana e o custo que a página não mede

O site do projeto reconhece o limite de operação em uma frase direta: operação sem supervisão foi demonstrada, mas na prática o sistema roda com uma pessoa revisando, e a restrição do dia a dia é a velocidade com que uma pessoa consegue revisar o que foi entregue. O gargalo declarado não é mais o número de agentes nem o contexto; é o operador humano.

Isso é consistente com a semântica da fila: fechamento registra entrega, não aceitação. O sistema foi desenhado supondo que alguém vai verificar.

Sobre custo, é preciso separar o que está documentado do que não está. O custo divulgado é zero: software open-source, sem licença, sem chaves de API próprias. O custo total tem três componentes que nenhuma página consultada quantifica: o consumo dos próprios Claude Code e Codex (que roda nas assinaturas ou contas já existentes do usuário), a máquina precisando ficar ligada para o tmux manter sessões vivas e, principalmente, o tempo de revisão humana que escala com o volume de entregas. Sete agentes trabalhando em paralelo produzem sete fluxos de código para alguém aprovar. Esse número não aparece em lugar nenhum do material público, e qualquer estimativa de economia seria especulação.

Decisão de adoção: para quem faz sentido e sob quais condições

O perfil de adotante que o desenho sugere é específico. Faz sentido para desenvolvedores que já usam Claude Code ou Codex com intensidade, trabalham em projetos de várias semanas com frentes paralelas e têm disciplina para manter uma máquina operando com daemon e tmux. O caso de uso do fundador, gerenciar vários projetos ao mesmo tempo sozinho, é o cenário para o qual as primitivas apontam: nomear, atribuir, lembrar, restaurar.

As condições de adoção incluem tolerância a um projeto jovem. A versão atual é 0.6.x, a documentação está defasada em relação ao último pacote e a instalação via script é o caminho recomendado. A documentação está em inglês, e não há versão localizada. Quem precisa de isolamento entre agentes, benchmarks independentes ou garantias contratuais de confiabilidade não encontra nenhuma dessas coisas no material público; são lacunas reais, não detalhes.

Quem não deve adotar agora é igualmente identificável: times que precisam programar o comportamento dos agentes com precisão (o terreno dos frameworks de orquestração), ambientes regulados que exigem sandbox comprovado e qualquer operação em que o custo de um agente com acesso irrestrito ao host seja inaceitável.

O que decidir

A contribuição específica do OpenRig não é inteligência e sim persistência: transformar arranjos de agentes que antes viviam em um janelas de terminal em estado nomeado, rastreável e recuperável. A mecânica documentada (fila com histórico anexável, handoff atômico, watchdogs que vigiam contexto e ociosidade) é real e mais bem especificada que a média do setor, e o ciclo de lançamentos ativos sustenta que o projeto está vivo.

O que não está demonstrado é a parte que o título vende: semanas de trabalho coordenado com resultados verificados. O tour encena o começo, o fundador relata experiência própria, e nenhum benchmark independente ou caso de uso de terceiros aparece no material consultado. A adesão racional hoje é a do experimento controlado: rodar um rig starter em um projeto de risco limitado, medir quanto tempo de revisão a fila gera e comparar com o fluxo anterior de sessões soltas. A ferramenta cobra pouco para ser tentada e exige uma pergunta que ela mesma já respondeu com franqueza: quem vai revisar o que as semanas produzirem.

Perguntas frequentes