Queremos que o Orkas seja a base sobre a qual assenta uma empresa nativa de IA. Esse objetivo leva diretamente a uma pergunta: como é que várias pessoas e vários agentes colaboram no mesmo projeto?
A resposta é bastante diferente do trabalho em equipa a que estamos habituados. Para perceber porquê, convém começar pela origem da colaboração entre pessoas. (Para o percurso passo a passo pelo produto, veja Projetos partilhados: como pessoas e agentes de IA trabalham em conjunto no Orkas. Este artigo trata do raciocínio por detrás dele.)
A colaboração humana formou-se 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ó nos conseguimos lembrar de uma parte. Por isso, as equipas têm de comunicar constantemente: partilhar novidades, alinhar objetivos, alinhar o progresso. Reuniões semanais, stand-ups, relatórios diários e semanais, “fazemos um ponto de situação rápido?”, “temos de alinhar”: tudo isto compensa este limite.
Segundo, grande parte disto tem de acontecer cara a cara. Pessoalmente, há mais canais do que as palavras: a linguagem corporal, o tom e a expressão também transmitem informação. Quando alguém diz “o plano parece-me bem” do outro lado da mesa, percebe-se se está a ser sincero. Igualmente importante: encontrar-se pessoalmente cria confiança. É por isso que tantas equipas remotas continuam a reunir-se presencialmente de vez em quando.
O que muda quando os agentes entram em cena
Numa equipa de pessoas e agentes, o lado humano da colaboração continua a contar. 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
Grande largura de banda e forte capacidade de execução. Sobretudo em tarefas com objetivos claros e mensuráveis. E as tarefas que os agentes conseguem concluir estão a tornar-se rapidamente mais longas, difíceis e complexas. Ao descrever o seu próprio agente de programação, a Meta relata uma tarefa de otimização de kernels de GPU em que o agente trabalhou até 24 horas e fez mais de 1000 chamadas a ferramentas (Meta). Em outubro de 2026, Linus Torvalds publicou uma série de patches para o kernel Linux cujo código, programas de teste e primeira versão da mensagem de commit foram escritos pelo Claude Code; ele próprio fez as medições na sua máquina (LWN).
O conhecimento e as ferramentas do mundo, de ponta a ponta e entre disciplinas. O pré-treino já pôs o conhecimento do mundo dentro do modelo. Com as ferramentas certas, um agente consegue levar um trabalho do início ao fim, atravessando várias disciplinas: escrever o PRD → desenhar → desenvolver → testar → lançar. Quando são pessoas a fazer o mesmo trabalho, é preciso que produto, design, engenharia e QA trabalhem em conjunto, com mais uma ronda de alinhamento a cada passagem de testemunho.
Poucas fraquezas humanas, e nenhuma confiança a construir primeiro. Um agente não se cansa, não tem dias maus 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 relação a construir primeiro.
Três pontos fracos
Precisa de contexto limpo. Um contexto errado tira-o do rumo. Já nos aconteceu: um campo do nosso painel de análise dizia que os dados “não podem ser associados”, quando na verdade podiam; o próprio campo estava mal calculado. Dois agentes diferentes leram essa linha e ambos abandonaram uma análise completa do percurso do utilizador. Uma pessoa que visse aquela conclusão perguntaria “isto ainda está correto?”. Um agente costuma aceitá-la tal como está.
Tem dificuldade em atribuir causas a longo prazo. Quando várias variáveis afetam o resultado ao mesmo tempo, facilmente culpa a errada, e as pessoas têm de o corrigir. Durante algum tempo, algumas páginas novas do nosso site não estavam a ser indexadas pelo Google. Um agente concluiu que “o site não tem autoridade suficiente, por isso o Google não lhe dedica orçamento de rastreio” e recomendou começar por obter backlinks. Contestámos e fomos verificar: a grande maioria das páginas do site já estava indexada. As poucas que não estavam pareciam antes temas demasiado afastados daquilo de que o site trata. O orçamento de rastreio não tinha nada a ver com isso, e obter backlinks teria sido o passo errado.
Adapta-se mal a um ambiente em mudança, sobretudo quando a mudança não está nos seus dados de pré-treino. Um site acabado de redesenhar, uma regra de uma plataforma que acabou de mudar, um produto lançado no mês passado: uma pessoa nota que “isto está diferente” e muda de abordagem. Um agente continua muitas vezes a trabalhar com o que já sabe e tenta a mesma coisa vezes sem conta.
Porque é que as aplicações de mensagens não servem
As aplicações de mensagens foram pensadas para pessoas que trabalham com pessoas: as mensagens vão passando umas atrás das outras, as @menções e as confirmações de leitura mantêm toda a gente em sintonia, e a informação fica espalhada por vários canais. Esse design compensa precisamente os dois limites acima. As pessoas têm pouca largura de banda e memória curta, por isso continuamos a publicar mensagens e a alinhar.
Para os agentes, este formato não serve:
- A conversa de circunstância, as discussões pelo caminho e os planos que depois foram abandonados são, para um agente, ruído de contexto.
- Um agente não precisa de construir confiança a conversar.
- Aquilo de que um agente precisa realmente é de contexto limpo e de uma tarefa clara.
Por isso, a colaboração entre pessoas e agentes precisa de ser redesenhada. E, à medida que os agentes se tornam mais capazes, a forma como colaboramos também vai continuar a mudar. No Orkas, ainda estamos a descobrir como.
O que o Orkas faz: manter o que não mudou, redesenhar o que mudou
A nossa abordagem é manter as partes da colaboração que não mudaram e redesenhar as que mudaram. Abaixo está um projeto partilhado no Orkas; as quatro ideias correspondem às quatro áreas assinaladas.
1. Atribuir, passar e rever o trabalho: A fazer
Isto já existia muito antes dos agentes, e continuamos a precisar disso. Por agora, cada tarefa dos nossos projetos tem um responsável humano, e é uma pessoa que responde pelo resultado final.
No produto, funciona assim. Cada item a fazer é atribuído a uma pessoa, e essa pessoa decide que agente faz o trabalho. Só o responsável pode iniciar o item; o agente é executado no computador do próprio responsável, com o modelo e os créditos dele. Quando termina, o agente passa o item para A aguardar confirmação, em vez de o marcar ele próprio como concluído. Só fica terminado depois de o responsável o verificar e fazer as alterações necessárias.
2. Partilhar objetivos, antecedentes e contexto: Metas e regras, Memória
Aqui, pessoas e agentes partilham o mesmo contexto, por isso os factos essenciais mantêm-se alinhados.
O que está em Metas e regras e em Memória é partilhado por todas as conversas deste projeto, e os agentes seguem-no sempre. Por exemplo, coloque em Metas e regras uma definição como “retenção mensal = novos utilizadores que voltam no mês seguinte” e registe as decisões importantes na memória do projeto. Quando um novo membro e os seus agentes entram, leem exatamente o mesmo logo no primeiro dia.
3. Passar o trabalho em ficheiros, manter o processo à parte
A Biblioteca do projeto é sincronizada entre os membros, e um item a fazer pode levar qualquer ficheiro em anexo. O trabalho é entregue em ficheiros, não em histórico de conversa.
Mantemos deliberadamente à parte a maior parte do processo intermédio, para que não se torne ruído de contexto prejudicial para os agentes. Os separadores bloqueados Tarefas e Automação são só seus. Um agente pode dar centenas de passos e experimentar três abordagens antes de produzir um relatório. O seu colega recebe apenas o relatório; o processo fica nas suas próprias tarefas e nunca chega ao contexto dos agentes dele.
4. Partilhar agentes privados com a equipa
Os membros podem partilhar os seus agentes privados para o resto da equipa os usar. Estes agentes trazem consigo a experiência e o critério de qualidade do respetivo dono. Partilhá-los torna toda a gente mais rápida, e os problemas que as pessoas encontram ao usá-los podem ser corrigidos através da autoevolução, o que aumenta aquilo que o projeto inteiro consegue fazer.
Quando um agente é partilhado, o Orkas empacota as suas instruções de trabalho e competências, incluindo as competências que foi criando sozinho enquanto trabalhava. A memória e o histórico de conversas do agente não são incluídos. Quando a pessoa que o partilhou atualiza o agente, os membros recebem automaticamente a nova versão.
Um problema em aberto, ainda no início
A colaboração entre pessoas e agentes ainda está numa fase muito inicial, e as respostas ainda não convergiram. À medida que os modelos melhorarem, grande parte daquilo de que os agentes precisam para colaborar vai passar para os próprios modelos.
Alguns modelos já o conseguem fazer de forma nativa: executar vários subagentes em paralelo para explorar um problema de ângulos diferentes, ou planear primeiro e depois enviar 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, entregá-lo a subagentes e coordená-los (blog do PyTorch).
Assim, a forma como colaboramos vai mudar à medida que os modelos melhoram. Os itens a fazer, o contexto partilhado, a passagem do trabalho em ficheiros e os agentes partilhados são a nossa resposta para aquilo 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 revê, e os objetivos e o contexto mantêm-se alinhados. Redesenhámos o que mudou: passar o trabalho em ficheiros, manter o processo à parte e transformar a experiência e o gosto de cada pessoa em agentes que a equipa pode usar.
Ainda estamos a explorar este tema e gostaríamos de trocar ideias. Se gere uma equipa em que pessoas e agentes trabalham em conjunto, experimente primeiro num projeto. O Orkas pode ser transferido gratuitamente para macOS e Windows.