Imagine uma equipe com quarenta conversas abertas. Em uma delas, alguém pede a um agente que prepare uma proposta para um cliente. Em outra, uma colega pede uma previsão de entrega. Uma terceira pessoa verifica se o mesmo recurso pode sair neste mês.
Cada conversa começa com uma explicação. Este é o cliente. Foi isso que prometemos. Foi esta a decisão de ontem. Os agentes começam a trabalhar, mas cada um vê um recorte diferente. Até alguém perceber que a proposta promete uma data já descartada na discussão de engenharia.
Então uma Task termina. Sua conversa fica quieta. Uma semana depois, outra pessoa começa um trabalho relacionado e explica o contexto novamente.
Voltávamos sempre a essa cena enquanto construíamos nossos agentes. Queríamos que o próximo trabalho partisse do que a equipe já havia aprendido. Isso nos levou a um projeto de sessão única: uma conversa principal persistente, com Workers independentes executando Tasks individuais.
Subagentes ajudam a dividir o trabalho. A sessão única responde a outra pergunta: onde fica a compreensão desse trabalho ao longo do tempo? Usamos os dois. A conversa principal dá continuidade à equipe; os Workers dão espaço para cada trabalho avançar.
Uma pessoa, um canal, uma equipe
Poke deu ao agente pessoal um lugar simples: uma pessoa, uma conversa (setembro de 2025). Conectava e-mail, calendário e arquivos de uma pessoa a uma conversa por texto. Pedir um rascunho de resposta ou remarcar uma reunião podia começar no mesmo lugar do pedido anterior. A conversa se tornava um ponto de retorno ao longo do dia. O relacionamento pessoal era o centro da experiência e nos deu um exemplo concreto de continuidade entre trabalhos diferentes.
Claude Tag trouxe um Claude para um canal (23 de junho de 2026). Qualquer pessoa ali podia mencionar o mesmo agente, ver seu trabalho e continuar de onde um colega parou. Claude guardava informações relevantes e usava as ferramentas disponibilizadas pelos administradores. O lançamento também descrevia o aprendizado com outros canais e fontes, quando permitido. A conversa compartilhada nos interessava: era possível delegar onde o trabalho já era discutido. Nosso projeto usa a conversa principal da equipe como ponto de retorno para as discussões e Tasks que a alimentam.
Escolhemos explorar uma equipe, uma conversa. O escopo acompanha o trabalho da equipe entre discussões. Uma decisão sobre entrega pode orientar a proposta, mesmo quando esses trabalhos começaram em lugares diferentes.
Em 28 de abril de 2026, publicamos nosso primeiro artigo sobre Bridge, nosso produto anterior. Essa parte da exploração veio depois de Poke e antes de Claude Tag. Continuamos esse trabalho no produto atual, Comma (1º de outubro de 2026), onde esse projeto funciona hoje.
DeepSeek Harness apresentou outra exploração em 31 de outubro de 2026: Super-agent. Seu trabalho proativo em conversas de grupo aponta na mesma direção: passar a coordenação das pessoas para o sistema. O protótipo de pesquisa segue seu próprio projeto.
O artigo de projeto da DeepSeek, §8.4, deixa duas questões em aberto: invasões na nuvem ou injeções de prompt que exponham dispositivos conectados, e vazamento de credenciais pelo contexto do modelo. Nossa resposta já em operação para o conteúdo é IFC: declarar fontes, verificar os leitores do destino, recusar envios não permitidos e pedir autorização humana delimitada quando necessário.
As credenciais seguem outro caminho. O modelo indica uma referência; a camada de execução resolve e injeta seu valor sem devolvê-lo ao modelo.
O que a equipe leva adiante
Uma nova colega entra no trabalho da proposta. Ela participa da mesma conversa principal que o restante da equipe já usa. Pode ver as decisões compartilhadas, perguntar por que uma data mudou e continuar sem pedir três resumos a três pessoas. Fazer parte do espaço de trabalho dá acesso à conversa; os materiais por trás de uma decisão mantêm suas próprias permissões.
Uma Task concluída mantém resultado e histórico. Talvez a equipe tenha descoberto que um cliente exige um formato de exportação incomum. O relatório volta ao Router, e uma proposta futura pode citar a descoberta e sua fonte. A Task terminou, mas a equipe ainda tem onde recuperar o que aprendeu.
O trabalho paralelo torna esse retorno importante. Um Worker pode ler os requisitos do cliente enquanto outro investiga um limite técnico. Se as descobertas passam por uma sequência de relatos, uma ressalva importante pode desaparecer. Cada Task devolve suas descobertas com as fontes. O Router as recebe no mesmo contexto principal.
Isso nos deu um motivo para dividir o harness em dois papéis. Um acompanha a conversa contínua da equipe. Os outros executam trabalhos individuais.
Como Router e Workers dividem o trabalho
Damos a cada espaço de trabalho um Router residente. Ele mantém o contexto principal da equipe e acompanha pedidos, mudanças de decisão e resultados. Um pedido sobre a proposta chega ao mesmo contexto da discussão de entrega já em andamento. Cada mensagem recebida traz a identidade da conversa e da mensagem de origem. O Router compartilha contexto entre discussões e conserva a procedência de cada entrada.
O Router entrega um trabalho definido a um Worker. Cada Task inicia uma nova sessão de Worker com instruções e repasse daquele trabalho. Os históricos dos outros Workers permanecem nas próprias sessões. Vários Workers podem investigar questões distintas ao mesmo tempo.
Definimos cada Task com um objetivo, o contexto para buscá-lo e uma entrega esperada. “Investigue este cliente” deixa coisas demais implícitas. “Verifique os requisitos de exportação e proponha um formato, com fontes e questões em aberto” dá ao Worker um trabalho que pode concluir e ao Router um resultado útil.
Suponha que a proposta precise da verificação de exportação e de uma estimativa de entrega. Podemos enviá-las a Workers diferentes. Um retorna os requisitos do cliente. O outro retorna a estimativa e suas premissas. O Router leva os resultados à conversa principal, onde a equipe decide. O trabalho concluído tem um caminho de volta.
Toda resposta visível exige envio explícito, inclusive na conversa principal. O Router informa o destino e passa pelas verificações desse destino. A saída do modelo e o fim de um turno não publicam uma resposta. A regra também vale quando um Worker relata resultados ou se dirige a outro participante. Ler materiais dá contexto à Task; enviar continua sendo uma ação separada.
Controle de fluxo de informação
Tasks paralelas reúnem fontes com públicos diferentes. Cada envio declara as fontes usadas. O controle de fluxo de informação, ou IFC, verifica se os leitores do destino podem ler essas fontes.
Com a aplicação das regras ativada, um envio recusado retorna um motivo. O agente pode remover o material restrito e tentar novamente ou obter a aprovação humana necessária para aquele escopo. Uma nova tentativa deve revisar tanto o conteúdo quanto a declaração das fontes.
IFC dá à equipe uma etapa verificável entre preparar uma resposta e compartilhá-la.
Voltando à proposta, o Router pode apresentar a estimativa à equipe, pedir a decisão pendente e enviar a resposta combinada pelo canal adequado. O trabalho do Worker tem limites definidos. A conversa da equipe continua pelo repasse.
Uma nova Task abre uma nova sessão de Worker. Quando trocamos de sessão, levamos o trabalho inacabado e suas referências à próxima. A equipe ainda precisa conseguir voltar às decisões anteriores.
O que a equipe aprende em conjunto
Procedimentos reutilizáveis viram skills compartilhadas pelo grupo: instruções e recursos editáveis. O agente criador controla as edições feitas por agentes. Outros agentes podem usar a skill sem reescrevê-la; uma skill integrada somente para leitura pode ser copiada para personalização. As sessões recebem o catálogo de seu escopo e abrem as instruções relevantes.
O Router mantém memória duradoura sobre pessoas, ambientes, fatos gerais e episódios datados. Ele a lê ou pesquisa quando necessário. Workers comuns trabalham a partir dos repasses das Tasks; Triage Workers designados têm acesso de leitura vinculado à fonte. A escrita na memória cabe ao Router.
Quando ativado, o Condensed Workspace fornece a todas as sessões internas de Router e Worker a mesma lista curta de fatos atuais do grupo. O proprietário do espaço de trabalho pode editá-la diretamente.
Atualizações de agentes passam por uma verificação consultiva de relevância como fatos atuais úteis a outros agentes. Revisões e último autor são registrados. O proprietário pode corrigir ou remover afirmações, tornando as premissas compartilhadas visíveis e editáveis. Uma atualização recusada pode ser reenviada com seu ID de rejeição como substituição explícita da decisão.
O custo de manter uma conversa
Essa organização pressiona a sessão principal. Workers podem trabalhar em paralelo, mas o Router ainda precisa reunir seus resultados. Um pedido pode chegar enquanto ele cuida de outro. Para as pessoas, isso é uma fila, por mais Workers que estejam disponíveis.
Ainda trabalhamos nas filas seriais. Delegar uma investigação longa deixa mais espaço para o Router responder, mas decisões relacionadas precisam de uma ordem. Na proposta, alguém precisa definir a data de entrega antes da promessa final. A conversa compartilhada deixa essa dependência visível e dá ao Router mais responsabilidade por manter o trabalho andando.
O histórico traz outro custo. Cada Task concluída acrescenta algo que pode importar depois, junto de muita coisa que nunca mais será útil. À medida que o histórico cresce, encontrar a decisão certa e seus motivos dá mais trabalho.
Queremos encontrar uma decisão antiga sem pedir a um colega que reconstrua toda a discussão. Seus motivos ajudam a equipe a perceber quando ela precisa mudar.
É aqui que nossa exploração está. Escolhemos uma conversa principal compartilhada porque equipes voltam ao mesmo trabalho por meio de pessoas e Tasks diferentes. Quando alguém abrir uma discussão relacionada, queremos que o esforço anterior da equipe continue ali.
