TL;DR: Roteamento é decidir qual agente de código assume uma determinada tarefa. Rotee com base nas propriedades da tarefa, não no ranking da semana passada: o que ela altera, quão reversível é, se sobrepõe arquivos que outro agente está mexendo, quanto tempo roda sem supervisão e qual assinatura a cobre. Faça a correspondência com o agente cujo comportamento no seu código-fonte se encaixa. Isso funciona de cabeça com um ou dois agentes. A partir de três, a decisão de roteamento precisa de um lugar compartilhado para morar. Este guia traz as regras e um checklist.
Você tem o Claude Code em um terminal, o Codex em outro, talvez o Gemini CLI em um terceiro. Chega uma tarefa: corrigir um teste instável, adicionar um endpoint, refatorar um módulo importado por outros três arquivos. Qual agente fica com ela? A maioria de nós responde por hábito, ou pela janela que já está em foco. Isso funciona até você não lembrar para qual agente entregou a migração, ou até dois deles editarem o mesmo arquivo.
Escolher o agente "melhor" é uma decisão única que envelhece no dia em que sai um modelo novo. Decidir qual agente fica com esta tarefa é uma decisão que você toma dezenas de vezes por semana, e ela depende muito mais da tarefa do que do ranking. Assim que você passa a ter mais de um agente, o roteamento é onde seu tempo vai embora.
O Sharkly foi construído em torno dessa decisão. O Sharkly é uma plataforma tudo-em-um de comando e gestão de Agentes: você conecta seu próprio Computer, define um Agente uma vez como um papel vinculado a um runtime e atribui uma Tarefa a ele. Ele fica acima dos agentes de código que você já usa, não ao lado deles. Este artigo percorre como rotear bem uma tarefa, primeiro como regras que você aplica na mão, e depois até o ponto em que a decisão de roteamento precisa de um lugar compartilhado para morar.
Roteamento é uma decisão, não uma preferência
Comece com uma definição limpa. Roteamento é fazer a correspondência entre uma tarefa e o agente que deve executá-la. Não é a mesma coisa que escolher seu agente favorito, nem que escolher um modelo. Qual modelo para qual tarefa de código é uma questão separada e mais restrita, que fica uma camada abaixo; aqui estamos decidindo qual agente (Claude Code, Codex, Gemini CLI, OpenCode e os demais) recebe o trabalho.
Uma tarefa carrega propriedades que determinam sua rota antes mesmo de a capacidade entrar em cena:
- O que ela altera. Um ajuste em um único arquivo, uma refatoração transversal, uma funcionalidade do zero, testes, documentação. Cada uma tem um raio de impacto diferente.
- Quão reversível é. Corrigir um erro de digitação e uma migração de banco de dados produzem os dois um diff. Só um deles arruína sua tarde se o agente errar.
- Sobreposição de arquivos. Ela toca arquivos que outro agente está editando agora?
- Horizonte de autonomia. Uma edição rápida e interativa, ou uma longa execução sem supervisão, que precisa planejar, executar e se autoavaliar.
- Teto de custo. Qual assinatura ou orçamento de API deve absorver a tarefa.
Leia uma tarefa à luz dessas cinco propriedades e a rota geralmente se escolhe sozinha. O erro é pular direto para "qual agente é o melhor", uma pergunta que não tem resposta fixa e muda a cada lançamento de um laboratório.
Rotee pelo formato da tarefa antes de rotear pela capacidade
Agentes de código realmente diferem entre si. Um pode planejar bem tarefas longas de várias etapas; outro pode ser mais afiado em edições cirúrgicas ou mais rápido em ciclos curtos. Mas a versão honesta é: eles diferem no seu código-fonte, e a única forma de saber é observá-los trabalhar nele. Benchmarks medem um conjunto fixo de problemas em um momento fixo, o que não é nem o seu repositório nem o mês que vem. Compare agentes no seu próprio código-fonte antes de confiar em um ranking.
Então rotee primeiro pelo formato. Um par de decisões para ancorar isso: use um agente rápido e interativo quando a tarefa é pequena, bem delimitada e você estará acompanhando; recorra ao agente mais autônomo quando a tarefa é grande o bastante para você preferir descrevê-la uma vez e revisar o resultado a ficar babá de cada passo.
| Formato da tarefa | Rotear para | Por quê |
|---|---|---|
| Pequena, bem delimitada, você acompanhando | Seu agente interativo mais rápido | Baixo overhead, ciclo curto |
| Grande, multi-etapas, descrever uma vez | Seu agente autônomo mais confiável | Ele planeja e se autoavalia sem supervisão |
| Toca arquivos que outro agente tem abertos | Qualquer agente, em um worktree isolado | Evita a colisão de merge |
| Alto risco ou irreversível | O agente cuja saída você revisa de perto, com permissões restritas | O raio de impacto, não a velocidade, domina |
| Barata e repetitiva | A que seu orçamento preferir | O teto de custo decide |
Nada disso nomeia um vencedor, porque não existe um. Existe um encaixe entre uma tarefa e o comportamento observado de um agente, e é esse encaixe que você usa para rotear.
As restrições que decidem o roteamento antes da capacidade
Duas restrições se sobrepõem à capacidade em todos os casos, e ambas têm a ver com coordenação, não com habilidade.
A primeira é a sobreposição de arquivos. Cinco agentes editando um repositório parece eficiente até dois tocarem os mesmos arquivos e você ter de resolver um conflito de merge que criou de propósito. A solução é o isolamento: dê a cada tarefa seu próprio checkout para que os agentes não possam colidir. Worktrees de agentes de código, um checkout por tarefa cobre o mecanismo, e rodar vários agentes em um mesmo repositório cobre o que quebra sem isso. Quando duas tarefas tocariam os mesmos arquivos, a rota não é "o agente melhor", e sim "qualquer agente, em um worktree separado".
A segunda é o risco. Uma tarefa que migra dados, altera autenticação ou reescreve um caminho crítico deve ser roteada para onde sua revisão for mais rígida e as permissões do agente forem mais restritas, independentemente de qual agente seja tecnicamente mais forte. Agentes pesquisam, executam, testam e reportam. Pessoas definem a direção, concedem autoridade e aceitam o resultado. Rotear uma tarefa arriscada para o agente mais rápido é otimizar a variável errada.
Onde o roteamento de cabeça deixa de escalar
Com um agente, não existe problema de roteamento. Com dois, você mantém a tabela de cabeça e tudo bem. O problema começa por volta de três agentes e várias tarefas abertas: a decisão de roteamento não tem onde morar, a não ser na sua memória de curto prazo.
Você não consegue lembrar qual agente ficou com a migração. Uma execução concluída some do topo do terminal antes de você lê-la. Você decide a mesma rota três vezes porque não há registro de que já a decidiu uma. Dois agentes editam o mesmo arquivo porque nada avisou a nenhum dos dois que o outro estava lá. Nada disso é falha dos agentes. É o custo de manter uma tabela de roteamento na cabeça enquanto os terminais se multiplicam. Terminais demais são um custo real, e o roteamento é onde ele aparece primeiro.
É aqui que um quadro de tarefas conquista seu lugar, porque ele tira a decisão de roteamento da sua cabeça e a coloca em um registro compartilhado. O Sharkly faz isso com três substantivos. Uma Tarefa é a unidade compartilhada de trabalho. Um Agente é um papel vinculado a um runtime, definido uma vez para que a decisão de roteamento se torne reutilizável em vez de refeita em cada terminal. Você atribui uma Tarefa a um Agente, e a execução, os bloqueios e os resultados voltam para essa Tarefa em vez de sumirem rolando para fora da tela. Você vê qual agente está com o quê sem trocar de janela, e o diff e a saída dos testes esperam sua revisão em um só lugar. Atribuir, acompanhar e revisar o trabalho dos agentes é o que substitui esse jogo de memória.
Você não precisa de nada disso para rodar bem um único agente. Também dá para rodar Claude Code e Codex juntos em um mesmo código-fonte na mão, e para dois agentes isso é razoável. A equação muda quando as decisões de roteamento passam do que você consegue manter na cabeça: vários agentes, várias tarefas, vários repositórios, uma equipe que precisa ver o mesmo quadro.
Um checklist de roteamento para usar hoje mesmo
Antes de entregar uma tarefa a um agente, passe por isto:
- Nomeie o formato da tarefa. Ajuste em um arquivo, refatoração, do zero, testes ou documentação? Isso define o raio de impacto.
- Verifique a reversibilidade. Difícil de desfazer? Rotee para sua revisão mais rígida e suas permissões mais restritas, não para seu agente mais rápido.
- Verifique a sobreposição de arquivos. Outro agente já está nesses arquivos? Se sim, isole esta tarefa em seu próprio worktree primeiro.
- Faça a correspondência com o horizonte de autonomia. Curta e acompanhada, ou longa e sem supervisão? Rotee para o agente cujo comportamento se encaixa no seu repositório.
- Defina o teto de custo. Decida qual assinatura ou orçamento absorve a execução.
- Registre a rota em algum lugar compartilhado. A partir de dois agentes, escreva-a onde você e sua equipe possam vê-la: uma Tarefa, não um terminal que você vai fechar.
- Faça os resultados voltarem para um só lugar. O diff, a saída dos testes e a revisão devem retornar ao registro da tarefa, não se espalhar pelas janelas.
Rotee pela tarefa, não pelo ranking. O melhor agente para uma tarefa é aquele cujo formato se encaixa no trabalho à sua frente, e a decisão de roteamento só se mantém barata se morar em algum lugar que você possa ver.
Se você já roda vários agentes de código, o Sharkly oferece um lugar único para rotear as tarefas deles e ler os resultados. Você pode baixar o Sharkly e conectar os agentes que usa.
FAQ
Roteamento é a mesma coisa que escolher o melhor agente de código? Não. Escolher o melhor agente é um julgamento único que envelhece rápido. Roteamento é decidir qual agente assume cada tarefa, com base em seu formato, risco, sobreposição de arquivos e horizonte de autonomia. Você roteia dezenas de vezes para cada vez que escolhe.
Qual a diferença disso para escolher um modelo? Escolher um modelo acontece uma camada abaixo, dentro do agente. O roteamento decide qual agente fica com a tarefa; a questão do modelo decide o que roda dentro da sessão desse agente. Veja qual modelo para qual tarefa de código para a decisão mais restrita.
Quando eu realmente preciso de uma ferramenta para isso? Quando as decisões de roteamento passam do que você consegue acompanhar de cabeça, normalmente por volta de três agentes e várias tarefas abertas, ou quando uma equipe precisa ver as mesmas decisões. Para um ou dois agentes, uma tabela mental e terminais separados bastam.
O Sharkly substitui o Claude Code ou o Codex? Não. O Sharkly não substitui o Claude Code, o Codex ou outras ferramentas de execução. Ele adiciona a camada compartilhada de tarefas, Computer, contexto e revisão em torno dos agentes de código que sua equipe já usa.
