Queremos que o Orkas seja a base sobre a qual uma empresa nativa de IA funciona. Esse objetivo leva direto a uma pergunta: como várias pessoas e vários agentes colaboram no mesmo projeto?
A resposta é bem diferente do trabalho em equipe a que estamos acostumados. Para entender por quê, vale começar pela origem da colaboração entre pessoas. (Para o passo a passo do produto, veja Projetos compartilhados: como pessoas e agentes de IA trabalham juntos no Orkas. Este post trata do raciocínio por trás dele.)
A colaboração humana se formou em torno de dois limites humanos
Primeiro, as pessoas têm largura de banda e memória limitadas. Só conseguimos absorver uma certa quantidade de informação de cada vez e só conseguimos lembrar até certo ponto. Por isso as equipes precisam se comunicar o tempo todo: compartilhar atualizações, alinhar metas, alinhar o andamento. Reuniões semanais, dailies, relatórios diários e semanais, “fazemos um sync rápido?”, “vamos alinhar”: tudo isso compensa esse limite.
Segundo, boa parte disso precisa acontecer cara a cara. Pessoalmente, há mais canais do que as palavras: linguagem corporal, tom e expressão também carregam informação. Quando alguém diz “o plano parece bom” do outro lado da mesa, dá para perceber se a pessoa está sendo sincera. Tão importante quanto isso: encontros presenciais criam confiança. É por isso que tantas equipes remotas ainda se reúnem pessoalmente de tempos em tempos.
O que muda quando os agentes entram
Numa equipe de pessoas e agentes, o lado humano da colaboração continua importando. Mas trabalhar com agentes é muito diferente de trabalhar com pessoas. Os agentes têm três pontos fortes claros e três pontos fracos claros.
Três pontos fortes
Alta largura de banda e forte capacidade de execução. Isso vale principalmente para tarefas com metas claras e mensuráveis. E as tarefas que os agentes conseguem concluir estão ficando rapidamente mais longas, difíceis e complexas. Ao descrever o próprio agente de programação, a Meta relata uma tarefa de otimização de kernels de GPU em que o agente trabalhou por até 24 horas e fez mais de 1.000 chamadas de ferramentas (Meta). Em outubro de 2026, Linus Torvalds publicou uma série de patches para o kernel do Linux cujo código, programas de teste e primeiro rascunho da mensagem de commit foram escritos pelo Claude Code; ele fez as medições na própria máquina (LWN).
O conhecimento e as ferramentas do mundo, de ponta a ponta e entre disciplinas. O pré-treinamento já colocou o conhecimento do mundo dentro do modelo. Com as ferramentas certas, um agente consegue levar um trabalho de ponta a ponta, passando por várias disciplinas: escrever o PRD → fazer o design → desenvolver → testar → lançar. Quando pessoas fazem esse mesmo trabalho, é preciso que produto, design, engenharia e QA trabalhem juntos, com mais uma rodada de alinhamento a cada passagem de bastão.
Poucas fraquezas humanas, e nenhuma confiança para construir antes. Um agente não se cansa, não tem dias ruins e não tem vergonha de fazer uma pergunta básica. Um agente novo pode começar assim que tiver o contexto do projeto. Não há período de adaptação nem relacionamento para construir primeiro.
Três pontos fracos
Ele precisa de contexto limpo. Contexto errado o tira do rumo. Já passamos por isso: um campo do nosso painel de métricas dizia que os dados “não podem ser vinculados”, quando na verdade podiam; o próprio campo estava calculado errado. Dois agentes diferentes leram aquela linha e os dois abandonaram uma análise inteira da jornada do usuário. Uma pessoa que visse essa conclusão perguntaria: “isso ainda está certo?”. Um agente geralmente aceita a informação como ela está.
Ele tem dificuldade em atribuir causas no longo prazo. Quando várias variáveis afetam o resultado ao mesmo tempo, ele facilmente culpa a errada, e as pessoas precisam corrigi-lo. Durante um tempo, algumas páginas novas do nosso site não estavam sendo indexadas pelo Google. Um agente concluiu que “o site não tem autoridade suficiente, então o Google não gasta orçamento de rastreamento com ele” e recomendou construir backlinks primeiro. Questionamos e fomos verificar: a grande maioria das páginas do site já estava indexada. As poucas que não estavam pareciam mais temas muito distantes do assunto do site. O orçamento de rastreamento não tinha nada a ver com isso, e construir backlinks teria sido a decisão errada.
Ele se adapta mal a um ambiente que muda, principalmente quando a mudança não está nos dados de pré-treinamento. Um site que acabou de ser redesenhado, uma regra de plataforma que acabou de mudar, um produto lançado no mês passado: uma pessoa percebe que “isso está diferente” e muda de abordagem. Um agente muitas vezes continua trabalhando com o que já sabe e tenta a mesma coisa de novo, e de novo.
Por que os apps de chat não servem
Os apps de chat foram feitos para pessoas trabalhando com pessoas: as mensagens vão passando uma atrás da outra, @menções e confirmações de leitura mantêm todo mundo em sincronia, e a informação fica espalhada por vários canais. Esse design compensa exatamente os dois limites acima. As pessoas têm pouca largura de banda e memória curta, então a gente continua postando e continua alinhando.
Para agentes, esse formato não serve:
- Bate-papo, discussões ao longo do caminho e planos que depois foram abandonados são, para um agente, ruído de contexto.
- Um agente não precisa construir confiança conversando.
- O que um agente realmente precisa é de contexto limpo e de uma tarefa clara.
Por isso, a colaboração entre pessoas e agentes precisa ser redesenhada. E, conforme os agentes ficam mais capazes, a forma como colaboramos também vai continuar mudando. No Orkas, ainda estamos descobrindo como fazer isso.
O que o Orkas faz: manter o que não mudou e redesenhar o que mudou
Nossa abordagem é manter as partes da colaboração que não mudaram e redesenhar as que mudaram. Abaixo está um projeto compartilhado no Orkas; as quatro ideias correspondem às quatro áreas destacadas.
1. Atribuir, repassar e revisar o trabalho: A fazer
Isso já existia muito antes dos agentes, e continuamos precisando disso. Por enquanto, toda tarefa nos nossos projetos tem um responsável humano, e uma pessoa responde pelo resultado final.
No produto, funciona assim. Cada item a fazer é atribuído a uma pessoa, e essa pessoa decide qual agente faz o trabalho. Só o responsável pode iniciar o item; o agente roda no computador do próprio responsável, com o modelo e os créditos dele. Quando termina, o agente move o item para Aguardando confirmação, em vez de marcá-lo como concluído por conta própria. Ele só está pronto depois que o responsável confere e faz os ajustes necessários.
2. Compartilhar metas, informações de fundo e contexto: Metas e regras, Memória
Aqui, pessoas e agentes compartilham o mesmo contexto, então os fatos principais continuam alinhados.
O que está em Metas e regras e em Memória é compartilhado por todas as conversas deste projeto, e os agentes seguem isso sempre. Por exemplo, coloque em Metas e regras uma definição como “retenção mensal = novos usuários que voltam no mês seguinte” e registre as decisões importantes na memória do projeto. Quando um novo membro e os agentes dele entram, todos leem exatamente a mesma coisa desde o primeiro dia.
3. Repassar por arquivos, manter o processo à parte
A Biblioteca do projeto é sincronizada entre os membros, e um item a fazer pode levar qualquer arquivo como anexo. O trabalho é entregue em forma de arquivos, não de histórico de chat.
De propósito, mantemos a maior parte do processo intermediário à parte, para que ele não vire ruído de contexto prejudicial para os agentes. As abas bloqueadas Tarefas e Automação são só suas. Um agente pode dar centenas de passos e tentar três abordagens antes de produzir um relatório. Seu colega recebe só o relatório; o processo fica nas suas próprias tarefas e nunca vai parar no contexto dos agentes dele.
4. Compartilhar agentes privados com a equipe
Os membros podem compartilhar os próprios agentes privados para o resto da equipe usar. Esses agentes carregam a experiência e o critério de qualidade do seu dono. Compartilhá-los acelera todo mundo, e os problemas que as pessoas encontram ao usá-los podem ser corrigidos pela autoevolução, e isso amplia o que o projeto inteiro consegue fazer.
Quando um agente é compartilhado, o Orkas empacota as instruções de trabalho e as habilidades dele, incluindo as habilidades que ele desenvolveu sozinho enquanto trabalhava. A memória e o histórico de chat dele não vão junto. Quando quem compartilhou atualiza o agente, os membros recebem a nova versão automaticamente.
Um problema em aberto, ainda no começo
A colaboração entre pessoas e agentes ainda está num estágio muito inicial, e as respostas ainda não convergiram. Conforme os modelos melhorarem, boa parte do que os agentes precisam para colaborar vai passar para dentro dos próprios modelos.
Alguns modelos já conseguem fazer isso nativamente: rodar vários subagentes em paralelo para explorar um problema por ângulos diferentes, ou planejar primeiro e depois despachar subagentes para executar o plano. O Muse Spark Open, que a Meta lançou com pesos abertos em outubro de 2026, é descrito como treinado para dividir o trabalho, repassá-lo a subagentes e coordená-los (blog do PyTorch).
Ou seja, a forma como colaboramos vai mudar conforme os modelos melhoram. Itens a fazer, contexto compartilhado, repasse por arquivos e agentes compartilhados são a nossa resposta para o que os modelos conseguem fazer hoje, não a forma final.
Considerações finais
Mantivemos o que não mudou: alguém é dono do trabalho, alguém o revisa, e metas e contexto continuam alinhados. Redesenhamos o que mudou: repassar por arquivos, manter o processo à parte e transformar a experiência e o bom gosto de cada pessoa em agentes que a equipe pode usar.
Ainda estamos explorando esse tema e gostaríamos de trocar ideias. Se você lidera uma equipe em que pessoas e agentes trabalham juntos, experimente primeiro em um projeto. Você pode baixar o Orkas de graça para macOS e Windows.