O Conductor é a ferramenta que a maioria das pessoas cita primeiro quando o assunto é rodar vários agentes de código ao mesmo tempo. E com razão. Um app nativo para Mac, agentes em workspaces isolados, diffs limpos para revisar e nada da ginástica com tmux que esse padrão costumava exigir.
Então a comparação útil não é “qual deles roda agentes em paralelo”. Os dois rodam. A questão é o que acontece quando o trabalho deixa de ser a tarde de um único desenvolvedor: quando uma segunda pessoa precisa acompanhar a execução, quando alguém no Windows entra no time, quando o agente precisa de uma máquina que não é um notebook e quando o planejamento precisa morar em outro lugar que não seja uma lista de workspaces. Este guia marca essas fronteiras e diz sem rodeios onde o Sharkly não é a resposta certa.
TL;DR
O Conductor roda agentes Claude Code, Codex e Cursor em paralelo, em workspaces isolados no macOS, com um plano gratuito em que você traz suas próprias assinaturas e chaves e planos pagos que adicionam o Conductor Cloud, uma API, colaboração ao vivo para times e controles de identidade corporativa. Sua documentação afirma que ele ainda não está disponível para Windows ou Linux. O Sharkly roda agentes em Computers que você conecta, incluindo servidores remotos e contêineres, no macOS, Linux e Windows, e os envolve em um sistema de trabalho: Tasks, Projects, Sprints, Crews e sincronização bidirecional com o Jira. Se seu time está inteiramente no macOS e quer a experiência nativa mais refinada, o Conductor é uma ótima resposta. Se a execução precisa sair do notebook ou o planejamento precisa ficar junto da execução, é aí que o Sharkly entra.
O que o Conductor faz certo
O Conductor provou algo que hoje toda a categoria assume: trabalho paralelo com agentes exige isolamento e uma superfície de revisão, e ambos devem estar a um clique de distância, e não depender de um ritual no shell.
Sua página inicial descreve o produto sem rodeios: “Rode agentes Claude Code, Codex e Cursor em paralelo, em workspaces isolados no seu Mac.” Cada agente recebe seu próprio workspace, então dois agentes editando os mesmos arquivos deixam de ser um desastre de merge. Criar um workspace, atribuir um agente e revisar o diff resultante são ações de interface, não comandos que você precisa memorizar.
O preço é honesto quanto à relação com o runtime. O plano gratuito deixa claro que você traz suas próprias assinaturas e chaves, o que é a postura correta para uma camada que não executa o modelo em si. Os planos pagos adicionam o Conductor Cloud, com horas de workspace na nuvem e uma API do Conductor no Pro, enquanto o plano Teams adiciona colaboração ao vivo para times de qualquer tamanho, cobrança centralizada e um portal de administração. O Enterprise adiciona um acordo de processamento de dados, SAML SSO, SCIM e um SLA com suporte dedicado.
Essa última parte importa para uma comparação justa, porque a antiga ideia de que “o Conductor é uma ferramenta individual” está desatualizada. Ele tem um plano para times, com colaboração e controles administrativos. Qualquer comparação que ignore isso está querendo te vender algo.
Se você quer o panorama mais completo dos executores locais, nossa comparação entre Claude Squad, Conductor e tmux mostra como essas abordagens se diferenciam na prática.
Onde um app nativo para Mac chega ao seu limite
Três limites decorrem do design, e apenas um deles tem a ver com recursos.
Plataforma. A documentação de instalação do Conductor afirma: “O Conductor ainda não está disponível para Windows ou Linux”. Para um time só de Mac, isso não é problema. Para um time com um desenvolvedor no Windows, uma estação de trabalho Linux ou uma máquina de build próxima ao CI, isso decide a questão antes mesmo de qualquer comparação de recursos começar.
O host de execução. Os workspaces rodam onde o app roda. O Conductor Cloud adiciona horas de workspace hospedadas nos planos pagos, o que ameniza isso, mas o modelo local ainda gira em torno da máquina do desenvolvedor. Trabalho de agente que precisa de uma máquina com rota de VPN, um banco de dados populado ou uma GPU exige outro tipo de host, e normalmente não é um notebook.
A unidade de trabalho. Um workspace é uma sessão. É uma boa abstração para “este agente, esta branch, este diff”. Não é um item de backlog. Ele não carrega prioridade, participação em sprint, critérios de aceite, um bloqueio que outra pessoa precisa resolver nem o histórico do que um revisor decidiu três semanas atrás. Times que precisam disso mantêm essas informações em outro lugar, o que significa que o planejamento e a execução vivem em dois sistemas que se distanciam.
Nada disso é defeito. É o formato de uma ferramenta local focada, e o foco é justamente o motivo de ela ser tão agradável de usar.
As duas decisões
Use o Conductor quando todo mundo está no macOS, os agentes que você quer são Claude Code, Codex ou Cursor, o trabalho roda bem nas máquinas dos desenvolvedores ou em horas de workspace hospedadas e seu planejamento já vive em um tracker com o qual você está satisfeito. Um app nativo com colaboração ao vivo é mais leve que um sistema de trabalho, e ser mais leve é um recurso.
Use o Sharkly quando a execução precisa acontecer fora do notebook ou em plataformas mistas, ou quando o time quer planejamento, execução e revisão em um único registro.
A definição que sustenta a diferença: um Computer no Sharkly fornece o host de execução para o trabalho dos Agents, e pode ser um computador local, um servidor remoto, um contêiner ou um host de nuvem compatível. Um pequeno serviço local conecta o Computer ao Sharkly, detecta os Runtimes disponíveis, recebe o trabalho, prepara o diretório da Task, inicia o Runtime selecionado e transmite o progresso de volta.
Essa separação é todo o design. O Agent define como o trabalho deve ser conduzido. O Computer fornece o host e os recursos locais. O Runtime realiza a sessão do agente propriamente dita. A Task permanece como o registro compartilhado do time.
O que o sistema de trabalho acrescenta
Se você já está satisfeito com o isolamento em paralelo, esta seção é o único motivo para continuar lendo.
O trabalho tem um lar que sobrevive à sessão. A Task é a unidade principal de trabalho. Ela pertence a uma Organization e a um Space, e também pode pertencer a um Project ou Sprint. Ela registra o objetivo e a descrição, status, prioridade, datas, etiquetas e tipo de task, a pessoa responsável, o Agent ou Crew designado para executá-la, comentários e anexos, além do estado de execução do Agent, o trace e o resultado. Quando uma execução trava, o travamento fica na Task, onde a pessoa que retomar o assunto amanhã vai encontrá-lo.
As configurações de agentes passam a ser patrimônio do time. Um Agent é uma configuração de trabalho salva, e não um prompt avulso: instruções, Runtime, Skills, repositórios, ambiente e configurações de execução. Um time pode manter Agents separados para mudanças de código, revisão, testes, documentação ou triagem operacional sem reescrever as mesmas instruções toda vez. Nosso explicador sobre o que é uma Skill de agente de código cobre a parte das instruções reutilizáveis.
A coordenação ganha estrutura quando é preciso. Uma Crew é um grupo reutilizável de Pessoas e Agents coordenado por um Agent líder, para trabalhos que se beneficiam de colaboração baseada em papéis, sequenciamento ou de um líder decidindo qual Agent age em seguida. Use um único Agent quando um único Agent basta; o guia de Crews é explícito sobre quando não recorrer a uma.
O tracker continua conectado. A integração do Sharkly com o Jira oferece suporte ao Jira Cloud e ao Jira Server ou Data Center, com importação, sincronização unidirecional ou sincronização bidirecional, vinculando um projeto do Jira a um Space. Times que não podem abandonar o Jira não precisam fazer isso.
Os Runtimes são extensíveis. Quando o serviço local não detecta a capacidade de execução que você quer, você pode adicionar um Runtime ACP personalizado nos detalhes do Computer: configure o ícone, o nome e o comando de inicialização, salve e selecione Test connection.
Um exemplo prático
Um time de doze pessoas mantém um app web e um serviço interno de dados. Oito desenvolvedores usam Mac, dois usam Windows e dois fazem a maior parte do trabalho via SSH em uma máquina Linux que tem o pipeline de dados.
Os oito desenvolvedores de Mac estavam felizes rodando agentes em paralelo localmente. Os outros quatro não conseguiam participar, e esse era o problema de verdade: o ferramental descrevia como oito pessoas trabalhavam, não como o time trabalhava.
Eles conectaram Computers em vez de padronizar o hardware: vários notebooks, mais a máquina Linux que já tinha o ambiente do pipeline e a rota de rede para o staging. O trabalho que precisa do pipeline roda lá. O trabalho que precisa da configuração local de um desenvolvedor roda naquele notebook. Os desenvolvedores no Windows se conectam da mesma forma.
Cada execução ainda recebe um worktree isolado, que era a parte da qual eles não abriam mão. Nosso guia sobre rodar agentes em paralelo em worktrees isolados cobre a mecânica que torna execuções simultâneas seguras.
O que mudou é o que um revisor vê. Em vez de um diff surgindo da máquina de alguém, a Task mostra o objetivo, o Agent que a executou, o Computer onde ela rodou, o trace, os bloqueios e a discussão. A daily lê o sprint, e não oito listas de workspaces separadas.
Sharkly vs Conductor: uma comparação justa
| Conductor | Sharkly | |
|---|---|---|
| Categoria | Executor nativo de agentes em paralelo para macOS | Camada de gestão de trabalho e execução para Pessoas e Agents |
| Plataformas | macOS; a documentação afirma que Windows e Linux ainda não estão disponíveis | Instaladores para macOS, Linux e Windows da CLI e do serviço local |
| Agents | Claude Code, Codex e Cursor | Runtimes detectados no Computer, além de Runtimes ACP personalizados que você configurar |
| Host de execução | Seu Mac, além de horas de workspace do Conductor Cloud nos planos pagos | Computers que você conecta: computador local, servidor remoto, contêiner ou host de nuvem compatível |
| Isolamento | Workspaces isolados por agente | Worktrees isolados por execução, vinculados a uma Task compartilhada |
| Unidade de trabalho | Workspace ou sessão | Task, opcionalmente em um Project ou Sprint |
| Recursos para times | Colaboração ao vivo, cobrança centralizada e portal de administração no Teams; SAML SSO e SCIM no Enterprise | Organizations, Spaces, Agents compartilhados, Crews e fluxo de revisão |
| Cobrança do modelo | Traga suas próprias assinaturas e chaves | As assinaturas ou chaves de API já configuradas nessas ferramentas |
| Integração com tracker | Funciona em conjunto com seu tracker | Sincronização bidirecional com o Jira Cloud, Server e Data Center |
Erros comuns
Comparar apenas pelo paralelismo. Os dois isolam bem execuções em paralelo. Decidir com base nesse recurso não diz nada. Decida com base na cobertura de plataformas, no host de execução e em se o planejamento precisa ficar junto da execução.
Usar a ideia desatualizada de “ferramenta individual”. O Conductor tem um plano Teams com colaboração ao vivo e portal de administração. Se alguém disser que ele não atende um time, é porque não verificou recentemente.
Adicionar um sistema de trabalho de que você não precisa. Se todo mundo está no macOS, o planejamento funciona bem no seu tracker e os agentes rodam tranquilamente nos notebooks, uma camada de trabalho é só custo extra. Diga não a ela.
Padronizar o hardware para se encaixar na ferramenta. Comprar Macs para que uma ferramenta funcione é uma decisão que vale a pena examinar antes de tomar, principalmente se parte do trabalho pertence a um servidor de qualquer forma.
Conclusão
O Conductor é a melhor versão de uma ideia focada: agentes em paralelo, workspaces isolados, revisão limpa, nativo no Mac e planos para times por cima. Se seu time cabe dentro do macOS e seu planejamento já tem um lar, esse foco é um recurso e você não deveria trocá-lo por algo mais pesado.
O Sharkly responde a uma pergunta diferente: onde o trabalho dos agentes roda quando ele pertence a um servidor, como um time de plataformas mistas entra nesse fluxo e como o planejamento permanece no mesmo registro que o trace de execução e a decisão humana. O Sharkly não substitui o Claude Code, o Codex ou outras ferramentas de execução. Ele acrescenta a Task compartilhada e a camada de Computer, contexto, controle e revisão em volta das ferramentas que seu time já usa.
Se sua configuração de agentes em paralelo funciona, mas só para parte do time, aí está a lacuna. Comece com o Sharkly, conecte um Computer que não seja um notebook e atribua uma Task a ele.
FAQ
O Conductor funciona no Windows ou no Linux? Sua documentação de instalação afirma que o Conductor ainda não está disponível para Windows ou Linux e convida você a se cadastrar para ser notificado. Consulte a documentação atual antes de decidir.
O Sharkly roda agentes em worktrees isolados, como os workspaces do Conductor? Sim. As execuções são isoladas para que agentes em paralelo não colidam, com o isolamento vinculado a uma Task compartilhada em vez de uma lista local de workspaces.
Posso continuar usando o Conductor e adicionar o Sharkly? Sim, embora geralmente seja mais organizado escolher um único lar por trabalho. Uma divisão comum é usar execuções paralelas locais para trabalho pessoal e o Sharkly para o trabalho que o time precisa ver, atribuir e revisar.
Quais agentes o Sharkly suporta? Qualquer Runtime que o serviço local detecte no Computer conectado, além de qualquer Runtime ACP personalizado que você configurar com ícone, nome e comando de inicialização.
Quem paga pelo uso do modelo em cada um? Os dois deixam isso por sua conta. O plano gratuito do Conductor diz para trazer suas próprias assinaturas e chaves; o Sharkly afirma que o uso do modelo continua pelas assinaturas ou chaves de API configuradas nessas ferramentas.
O Sharkly precisa de um servidor dedicado? Não. Um Computer pode ser um notebook. A questão é que ele não precisa ser, então o trabalho que exige um ambiente específico pode rodar onde esse ambiente já existe.
