O que é o Team Mode do Oh My OpenAgent e como vários agents dividem o trabalho?

Sair de "um agent com subagents" pra um time de agents de verdade não é ajuste fino, é virada de chave

E é exatamente isso que o Team Mode propõe dentro do Oh My OpenAgent: em vez de um agent principal delegando tarefinhas e trazendo tudo de volta pra si, você monta um lead que orquestra membros especializados, cada um rodando em paralelo e se comunicando por ferramentas dedicadas

É recurso novo, ainda quase sem material em português, e vale entender antes de sair ligando em projeto sério, beleza? 🙂

O que é o Oh My OpenAgent e onde o Team Mode se encaixa

O Oh My OpenAgent (OMO) é mantido no repositório code-yeongyu/oh-my-openagent e se descreve como um agent harness para Codex e OpenCode

Harness aqui é aquela camada em volta: se você já usou algum gerenciador que empacota configuração, comandos e integrações por cima de uma ferramenta base, a ideia é bem semelhante

O Team Mode faz parte da edição Ultimate do OMO, a que roda sobre o OpenCode, junto com os agents de disciplina, os hooks de ciclo de vida, os MCPs embutidos e os slash commands

Ele entrou no release v4.0.0 e a própria documentação do projeto declara que o modo é modelado a partir dos Agent Teams do Claude Code, ou seja, não é uma invenção paralela: é a mesma escola de coordenação chegando em outro harness

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Como vários agents dividem o trabalho na prática

A anatomia do time é simples de descrever

Tem um agent lead orquestrando e membros especializados por categoria, que rodam em paralelo

• Tamanho do time: max_members define o teto de membros, numa faixa de 1 a 8
• Quantos rodam juntos: max_parallel_members também vai de 1 a 8, com padrão 4
• Conversa: mailbox compartilhada, com deferred ack
• Trabalho: lista de tarefas compartilhada, com claim protegido por lock de arquivo
• Isolamento: worktrees git opcionais por membro

E como um membro pega uma tarefa? Ele chama o team_task_update mudando o status para claimed, e devolve o resultado por team_send_message

O lock de arquivo existe justamente pra isso: quando dois membros tentam reivindicar a mesma tarefa ao mesmo tempo, os claims concorrentes resolvem de forma segura, sem dois agents duplicando o mesmo serviço

São 12 ferramentas team_* no total, entre elas team_create, team_status, team_list, team_send_message, team_task_create, team_task_update, team_shutdown_request, team_approve_shutdown, team_reject_shutdown e team_delete

Todas ficam gated pela configuração: só aparecem com o modo habilitado

Se a ideia de rodar vários agentes em paralelo no mesmo projeto já te interessava, o Team Mode é essa ideia virando configuração declarada em vez de arranjo caseiro

O que você precisa antes de ligar o Team Mode

Antes do passo a passo, checa a lista

• Edição Ultimate instalada, que é a que roda sobre o OpenCode e inclui o Team Mode
• Instalação por comando único: bunx oh-my-openagent install
• Configuração: hoje o OMO usa um arquivo unificado omo.jsonc, com versão global do usuário em ~/.omo/omo.jsonc e versão por projeto em .omo/omo.jsonc
• git disponível, se você pretende usar worktreePath pra isolar membro
• tmux no PATH e sessão tmux ativa, se quiser a visualização lado a lado

Um detalhe que economiza dor de cabeça: os arquivos antigos (oh-my-openagent.json e oh-my-opencode.json, incluindo as variantes .jsonc) são importados uma única vez pela engine de migração e não são mais lidos em runtime

Traduzindo: editar o legado depois da migração não muda nada, e você fica achando que a configuração não pega

Como habilitar e operar o Team Mode passo a passo

O modo vem OFF por padrão, então nada aparece até você ligar explicitamente

1. Abra o arquivo de configuração do OMO, o omo.jsonc (global em ~/.omo ou por projeto em .omo)

O erro comum deste passo: mexer no arquivo legado, que só migra uma vez e depois não é mais lido

2. Adicione a chave que habilita o modo:

{
  "team_mode": {
    "enabled": true
  }
}

O erro comum deste passo: procurar as ferramentas team_* antes de habilitar, elas são liberadas só com team_mode.enabled ligado

3. Reinicie o OpenCode, senão as ferramentas team_* não aparecem mesmo com a chave certa no arquivo

O erro comum deste passo: salvar e continuar na mesma sessão, achando que a config foi ignorada

4. Ajuste o tamanho e o paralelismo do time com max_members (1 a 8) e max_parallel_members (1 a 8, padrão 4)

O erro comum deste passo: subir os dois pro teto de cara, sem saber se a tarefa realmente se divide

5. Isole um membro em worktree próprio, informando o caminho na entrada dele:

"worktreePath": "../wt-scout"

O campo aceita caminho relativo ou absoluto e exige git

O erro comum deste passo: informar nome de branch puro, que é rejeitado

6. Ligue a visualização lado a lado, se quiser acompanhar cada membro:

"tmux_visualization": true

Cada membro ganha um painel dedicado, anexado à sessão pelo opencode attach

O erro comum deste passo: ativar fora de uma sessão tmux, ou sem o tmux no PATH

7. Encerre o time pelo fluxo negociado: team_shutdown_request primeiro, depois team_approve_shutdown ou team_reject_shutdown, e team_delete pra limpeza de estado, mailbox, tasklist, worktrees e painéis

O erro comum deste passo: matar o time no braço e deixar worktree e painel órfãos pra trás

Quando vale colocar mais de um agent no mesmo trabalho

Agora o ponto que interessa de verdade

Time de agent não é upgrade automático: é troca de um custo por outro

Você troca "um agent pensando devagar em tudo" por "vários agents pensando junto, com custo de coordenação em cima"

Os mecanismos dizem bastante sobre onde a divisão se paga

Membros são especializados por categoria, o claim é por tarefa e o isolamento é por worktree

Ou seja: o desenho premia trabalho que já vem picotado

Repara numa coisa: a mailbox tem deferred ack e o paralelismo é limitado de propósito

Isso é sinal de que o projeto assume que coordenação custa

Antecipando o erro clássico: colocar 8 membros pra editar o mesmo módulo não acelera nada, só multiplica a conversa

A lógica de team mode em repositório compartilhado segue a mesma linha: divisão só compensa quando o trabalho já era divisível

Problemas conhecidos do Team Mode e como não cair neles

Recurso novo tem atrito, e é honesto falar dele

**Sintoma: as ferramentas team_* não aparecem**

Causa provável: o modo é gated por team_mode.enabled e exige restart do host depois de habilitar

Existe ainda a issue #3893 no repositório, relatando que o team_mode não consegue ser habilitado em instalação nova

Prevenção: confira a chave, reinicie, e se persistir vale checar se a issue já foi resolvida em release posterior antes de perder a tarde

Sintoma: os painéis do tmux não são criados e nada é avisado

Causa provável: a issue #3963 relata que o tmux_visualization pula a criação de painéis em silêncio no modo TUI padrão

Prevenção: rode dentro de uma sessão tmux com o tmux no PATH, e não use a ausência de painel como termômetro de que o time não subiu

Sintoma: execução que estoura tempo ou volume de mensagens

Causa: time de agent conversa, e conversa custa

Prevenção: o Team Mode tem limites configuráveis além do número de membros, como max_messages_per_run, max_wall_clock_minutes, max_member_turns, message_payload_max_bytes, recipient_unread_max_bytes, mailbox_poll_interval_ms e base_dir

Defina esses tetos ANTES de soltar o time num projeto grande, não depois 😀

O que o Team Mode muda para quem já usa agents de código

O que mais chama atenção aqui não é a feature isolada, é o movimento

Multi-agent está saindo do território da gambiarra caseira (script chamando script, terminal aberto em três abas) e virando configuração declarada, com chave de habilitação, tetos, mailbox e fluxo de encerramento

O paralelo é explícito: a documentação do projeto diz que o Team Mode é modelado nos Agent Teams do Claude Code

Quando duas ferramentas diferentes convergem pro mesmo desenho (lead + membros + canal de mensagem + tarefas com claim), isso costuma indicar que o padrão pegou

Pra quem trabalha com vibe coding, a leitura prática é essa: a habilidade que passa a valer não é só escrever prompt bom, é decidir COMO recortar o trabalho

Se você não sabe dividir a tarefa, o time não vai dividir por você

Vale testar o Team Mode agora?

Depende do que você espera

Se a expectativa é ganho garantido de velocidade, segura: não existe número oficial publicado comparando o Team Mode com rodar um agent só, nem em tempo nem em custo

Agora, se a expectativa é entender cedo um padrão que já apareceu em mais de uma ferramenta, aí sim vale

A configuração é simples e reversível: uma chave liga, um restart aplica, e o team_delete limpa estado, mailbox, tasklist, worktrees e painéis quando você quiser voltar atrás

Meu sugestão de próximo passo é a mais chata e a mais útil: liga num projeto de teste, com poucos membros, numa tarefa que você JÁ sabe que é separável

Daí observa se a coordenação compensou, ou se o lead passou o tempo todo organizando fila

É recurso novo, com issues abertas no repositório, então trate como experimento e não como padrão de produção ainda

até o próximo post!