> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/pt-br/2026/w33-five-steps-toward-the-future-work-paradigm-seen-through-agent-teams.md). # W33-Cinco degraus do trabalho futuro vistos por uma equipe de agentes Recentemente, Boris Cherny, responsável pelo Claude Code, publicou uma tabela chamada [Etapas de adoção da IA](https://docs.google.com/document/d/1R91ayvj7uvlxgNi--__2-Bf3w8x5r1nF-xIBN7ds8Ns/edit). Na [publicação original](https://x.com/bcherny/status/2077929379661844559), ele descreve um fenômeno recorrente: uma pessoa da equipe aumenta sua produção em uma ordem de grandeza com o Claude, mas o restante da organização não acompanha. Essa observação se aproxima da minha experiência recente. A diferença produzida pela IA já vai além da familiaridade com ferramentas. Pessoas diferentes estão usando paradigmas de trabalho completamente distintos. Boris divide a adoção de IA em cinco níveis, de L0 a L4. Mais precisamente, são cinco estados e quatro transições. Prefiro entendê-los como cinco degraus do paradigma de trabalho futuro. ## Cinco degraus | Nível | Papel humano | Forma de trabalho | Principal gargalo | | --------------------------- | --------------------- | ------------------------------------------------------------------------------------- | -------------------------------- | | L0 Restrito | Observador | Quer usar IA, mas os modelos realmente capazes não têm acesso ao trabalho | Permissão de acesso | | L1 Assistido | Parceiro de dupla | Você trabalha com um agente; ele executa e você verifica passo a passo | Atenção humana | | L2 Paralelo | Orquestrador | Você organiza vários agentes; eles executam e se verificam, você aceita os resultados | Capacidade de revisão | | L3 Autonomia supervisionada | Gestor de gestores | Tarefas agendadas ou eventos iniciam o trabalho; pessoas aprovam exceções | Confiança e vazão de decisões | | L4 Nativo em IA | Definidor de intenção | Centenas ou milhares de agentes trabalham por objetivos; pessoas gerenciam exceções | Julgamento de valor e governança | Na tabela de Boris, o número de agentes vai de 0 a 1, 10, 100 e mais de 1000. Esses números representam ordens de grandeza, não critérios de promoção. A mudança relevante é o papel humano. Em L1, a pessoa ainda está ao volante de cada tarefa. O agente se parece mais com um assistente muito rápido. Em L2, a pessoa começa a desenhar a divisão de trabalho, controlar o contexto e estabelecer critérios de aceitação. Vários agentes avançam em paralelo, enquanto a atenção humana se concentra em resultados e exceções. L3 dá outro passo. As tarefas deixam de ser todas iniciadas, uma a uma, por pessoas. O sistema escuta eventos, executa agendas, encontra problemas e cria trabalho por iniciativa própria. A pessoa deixa de gerenciar cada agente para gerenciar o sistema de trabalho formado por eles. ## Vários agentes não formam necessariamente uma equipe Antes, estávamos preocupados em tornar um agente mais forte e fazê-lo concluir tarefas mais longas e complexas. A capacidade individual sempre tem limites, e cada vez mais pessoas passaram a usar vários agentes ao mesmo tempo. Com mais agentes, surgem novos problemas. A capacidade individual deixa de ser o único gargalo; a organização começa a definir o teto do conjunto. Se cada trabalho ainda exige que uma pessoa escolha a entrada, reúna o histórico, transporte contexto e entregue o resultado de um agente a outro, esses agentes continuam sendo, em essência, ferramentas independentes. A pessoa continua sendo o único roteador do sistema e seu gargalo de fato. Minha definição de equipe de agentes tem três características. Primeiro, cada agente responde de forma duradoura por seu domínio. Sabe o que deve tratar, quais são seus limites e quais problemas não lhe pertencem. Segundo, parte da responsabilidade de colaboração passa das pessoas aos agentes. Dentro de relações claras de responsabilidade, eles encaminham tarefas, fazem passagens e devolvem resultados, sem exigir que uma pessoa conecte cada etapa. Terceiro, a pessoa continua na equipe, mas em outra posição. Volta para definir direção, confirmar fatos, escolher, revisar e autorizar, sem acompanhar toda a execução. Mas, quando a pessoa deixa de participar de cada passo, surge imediatamente outra pergunta: como saber se a equipe está funcionando bem? Por isso, uma equipe de agentes também precisa ser observável, compreensível e ajustável continuamente. Caso contrário, apenas troquei o agendamento manual de cada agente por uma situação em que não consigo enxergar o que fazem. ## A primeira vez que senti ter uma equipe de agentes Minha experiência mais marcante com L2 veio do Multica. Inicialmente, criei nele um Engineering Squad para construir um MCP conectado à plataforma interna de hospedagem de código da empresa. Na primeira versão, o Claude cuidava da estratégia, decomposição e roteamento; o Codex, da implementação; e o Gemini, da exploração e aceitação independente. Eu mantinha a intenção do produto, as prioridades, as escolhas e a aprovação final. Essa combinação me deu, pela primeira vez, uma forte sensação de equipe. Depois que eu esclarecia o objetivo e os limites, o líder continuava decompondo as tarefas e escolhendo os agentes adequados para explorar, implementar e verificar. Só recebia uma notificação quando algo exigia julgamento, e então voltava à tarefa para decidir. No início de uma tarefa, dois materiais descreviam o estilo das interfaces e a autenticação de forma conflitante. O líder não mandou o Codex programar imediatamente. Primeiro, delegou uma investigação exploratória com limites claros. Ela deveria responder apenas a algumas questões factuais, apresentar requisições reais como evidência e não implementar o MCP. Alguns minutos de investigação evitaram uma implementação inteira na direção errada. A aceitação posterior também revelou o valor real da equipe. Um relatório usava uma resposta 401 a um token inválido como prova de que certo mecanismo de autenticação não existia. A conclusão estava correta por acaso, mas o raciocínio era inválido. Em outra rodada, todos os testes passaram, mas o único fixture real era um array vazio, incapaz de verificar a estrutura dos campos de dados não vazios. Os relatórios não eram falsificados. Eram corretos, mas incompletos. O líder precisava examinar novamente a evidência com outra função objetivo, e implementador e avaliador não podiam compartilhar a mesma lógica de autocomprovação. A tarefa produziu algumas regras estáveis. Exploração limitada vem antes da implementação. O autor não pode ser o único revisor de mudanças de alto risco. A evidência precisa dizer o que comprova e o que não comprova. Ações visíveis externamente, irreversíveis ou que envolvam endosso de identidade param para decisão humana. Essa foi minha experiência direta com L2: uma pessoa passa a ter uma equipe de entrega com custo de coordenação muito baixo. ## De uma configuração isolada a um modelo operacional Depois, comecei a transformar o uso do Multica de uma configuração temporária em um modelo operacional que pudesse ser mantido, organizado em um repositório Git. A prática central foi separar quatro objetos. | Objeto | Responsabilidade | Ritmo de mudança | | ------------------ | ----------------------------------------------------------------------------- | -------------------------------------- | | Profession Profile | Deveres do papel, limites de julgamento, ferramentas e contrato de evidências | Estável e versionável | | Agent Instance | Runtime, modelo, permissões e concorrência concretos | Substituível | | Squad | Missão persistente, regras de roteamento e relações entre membros | Ajustado às filas estáveis de trabalho | | Issue Run | Objetivo, contexto, evidências e riscos remanescentes de uma tarefa | Diferente a cada tarefa | O valor central é separar contratos estáveis de implantações variáveis. As responsabilidades dos papéis devem ser estáveis. O Delivery Lead responde continuamente por decomposição, roteamento, resolução de conflitos e consolidação de evidências. O Implementation Engineer cuida da implementação e dos testes. O Challenger procura contraexemplos e faz revisões somente de leitura. O Explorer-Validator explora contextos grandes, analisa impactos e realiza aceitação independente. Runtime e modelo concretos podem mudar. Hoje, o Delivery Lead pode rodar no Claude; o Implementation Engineer, no Codex; o Challenger, no Grok; e o Explorer-Validator pode usar Gemini via Antigravity. Se os modelos mudarem no futuro, as instâncias podem ser substituídas sem reescrever ao mesmo tempo todas as responsabilidades da equipe. Isso não significa troca de modelos sem custo. Permissões, ferramentas, sessões e modos de falha de cada runtime precisam ser verificados novamente. Ser substituível significa que o contrato organizacional não está preso a uma marca de modelo, não que se possa pular a aceitação da implantação. ## Minha configuração atual no Multica Ao escrever este artigo, gerencio oito instâncias de agentes e quatro squads persistentes no Multica. Os quatro papéis principais que atravessam os squads são Delivery Lead, Implementation Engineer, Challenger e Explorer-Validator. Há ainda Product Architect, Market Researcher, Ops Engineer e Data Analyst, voltados às tarefas de pesquisa, arquitetura e confiabilidade. Os quatro squads são organizados por filas estáveis de trabalho. | Squad | Critério de entrada | Caminho padrão | | ----------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | Engineering | Funcionalidades cotidianas, refatorações, bugs comuns e entregas de engenharia | Claude encaminha, Codex é o único autor, Gemini verifica e Grok contesta quando necessário | | Reliability & Incident | Causa desconhecida, problemas entre módulos, difíceis de reproduzir ou de confiabilidade em produção | Coleta paralela de evidências somente de leitura; Claude consolida hipóteses; Codex é o único autor da correção; outra pessoa ou agente faz a regressão | | Research & Architecture | Escolhas técnicas, decisões de produto, migrações ou investigação limitada | Gemini reúne evidências, Grok ataca premissas, Codex faz apenas experimentos delimitados | | Frontend Experience | Fluxos de usuário, visual, responsividade, acessibilidade e aceitação no navegador | Gemini estabelece a referência, Codex implementa, Gemini verifica na página real | Squads não são divididos por repositório nem criados apenas porque apareceu um modelo novo. Um repositório novo é somente um novo recurso Project. Tarefas com responsável conhecido são atribuídas diretamente ao agente correspondente. Só entram em um squad quando exigem várias capacidades e, ao criar a issue, ainda não é possível definir o responsável concreto. Essa configuração também tem limites rígidos. Cada tarefa tem apenas um responsável atual. Cada worktree tem apenas um autor. Agentes que escrevem têm concorrência 1; papéis que não escrevem podem ter 2; o daemon local tem limite total de 3. Produção, credenciais, publicação, envios externos e ações irreversíveis sempre exigem minha aprovação. ## Ativar apenas os papéis mínimos necessários É fácil entender uma equipe de agentes como colocar todos os modelos para trabalhar em todas as tarefas. Isso normalmente só aumenta contexto, tokens e custo de coordenação. No Multica, o squad é apenas um objeto de roteamento. Quando recebe uma issue, o sistema desperta primeiro o líder. Ele lê o contexto e decide a quem entregar o próximo passo. O squad não executa todos os membros automaticamente nem aumenta a concorrência. Minha regra padrão, portanto, é ativar a cada vez o menor conjunto de papéis suficiente para concluir a tarefa. Uma pequena correção bem delimitada pode ir direto para o Codex, sem iniciar um squad. Em um repositório grande e desconhecido ou em uma tarefa de UI, o Gemini primeiro estabelece o impacto e a referência de aceitação, depois passa ao Codex. Só acrescento a revisão adversarial do Grok em falhas difíceis de reproduzir ou diffs de alto risco. Por padrão, no máximo dois membros executores ficam ativos ao mesmo tempo. O paralelismo se limita a investigações independentes, revisões independentes sobre o mesmo commit estável ou worktrees com escopos de arquivos totalmente separados. Vários agentes alterando o mesmo estado parecem acelerar o trabalho, mas normalmente acabam gerando conflitos e retrabalho. O número de agentes não mede a maturidade da equipe. A capacidade de orquestração está em ativar o papel certo no momento certo. ## O DoD é a interface entre agentes A possibilidade de colaboração direta não significa que basta dizer “continue daqui”. Exijo que cada delegação esclareça quatro pontos. ``` outcome: 最终可观察结果 evidence: 证明结果的测试、命令、截图、数据或链接 verification: 由谁、用什么方式验收 max_rounds: 最多返工轮数，默认 2 ``` Isso é a Definition of Done: o contrato de evidências que precisa ser cumprido antes de aceitar o resultado. O Implementation Engineer entrega mais do que código: informa o escopo das mudanças, o commit, os comandos de teste e os resultados brutos. O revisor independente lê o objetivo, o diff e os testes; não aceita a declaração de conclusão do autor como evidência. Ao encerrar, o líder lista os resultados reais, os pontos não verificados, os riscos remanescentes e as decisões que cabem à pessoa. `max_rounds` é igualmente importante. Agentes podem mencionar uns aos outros, mas o sistema não decide por mim quando a colaboração deve acabar. Se, após duas rodadas de retrabalho, as evidências ainda conflitarem, a equipe precisa interromper o ciclo e levar a divergência à pessoa. No Multica, uma task marcada como `completed` indica apenas que aquela execução do agente terminou normalmente, não que o objetivo da issue foi cumprido. O DoD e as evidências determinam se a tarefa pode entrar em revisão. Essa distinção separa o estado de execução do agente do estado de conclusão do trabalho. ## Equipes de agentes também precisam de engenharia de configuração Por melhor que seja o prompt de um papel, ele não prova que a equipe funcione no ambiente real. Defini o repositório Git como fonte de verdade da configuração. `config/agents/` guarda os contratos dos papéis; `config/squad-*.md`, as regras de roteamento; e `config/topology.json`, a topologia de agentes, runtimes, permissões, concorrência e squads. Os objetos em execução no Multica são apenas cópias operacionais dessas declarações. Por padrão, o sincronizador só produz um plano de alterações. Ele é aplicado após revisão humana, e uma nova execução precisa resultar em `No changes.`. Objetos não gerenciados são apenas relatados, nunca excluídos automaticamente. IDs de workspace e agente, tokens, webhooks e caminhos locais ficam fora do repositório. Esse mecanismo trata os desvios de configuração. Quando papéis e rotas mudam, posso ver o diff, revisá-lo e reconciliar novamente o estado em execução com o estado desejado. A integração real também mostrou que uma equipe de agentes vai muito além de alguns prompts. O líder precisa operar o plano de controle do Multica sem escrever arquivos do projeto. O Grok precisa revisar em modo somente de leitura sem herdar permissões excessivas de rede e escrita. Runtimes de desktop também sofrem influência de proxies, sandboxes, argumentos de comando e ambiente local. À medida que esses problemas apareceram, corrigi o acesso direto ao plano de controle, os limites do sandbox e a correspondência de subcomandos do CLI. Uma permissão declarada no arquivo de configuração não garante um runtime saudável. Cada papel central precisa de testes de fumaça reais, positivos e negativos. ## Os cinco degraus vistos pela equipe de agentes Desse ponto de vista, os cinco degraus do trabalho futuro representam, em essência, a transferência gradual das responsabilidades de roteamento, colaboração e aceitação das pessoas para o sistema. | Nível | Organização dos agentes | Principal trabalho humano | | ----- | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | L0 | Agentes não entram no trabalho real | Continuar nos processos existentes | | L1 | Ferramentas independentes; a pessoa é o único roteador | Fornecer contexto a cada vez e verificar cada resultado | | L2 | Papéis e squads persistentes; o líder escolhe a equipe mínima | Definir objetivos e DoD, aceitar evidências e fazer escolhas essenciais | | L3 | Agendas ou eventos iniciam a equipe | Gerenciar exceções, permissões, orçamento e condições de parada | | L4 | Várias equipes operam por intenção; a organização pode se ajustar dinamicamente | Definir direção, valores e limites não delegáveis | Atualmente, estou entre L2 e L3. Minha configuração do Multica resolveu questões de papéis, roteamento, evidências e observabilidade, mas a maioria das tarefas ainda é criada por mim. A mudança central de L3 é o poder de iniciar. O [Autopilot](https://multica.ai/docs/autopilots) do Multica permite que tarefas recorrentes ou eventos de webhook criem issues automaticamente e as entreguem a um agente ou squad. Em [O Mac de um Builder também precisa de um Sweeper](https://weekly-essay.mikey.wang/pt-br/2026/w32-a-builders-mac-also-needs-a-sweeper), escrevi sobre rotinas diárias de governança de Skills e verificações semanais do ambiente do Mac. Esse trabalho está mais próximo de L3. Mas o poder de iniciar não pode avançar à frente da capacidade de verificar. Sem DoD, evidências, permissões, condições de parada e registros observáveis, despertar mais agentes automaticamente apenas fará os erros acontecerem mais cedo e se tornarem mais difíceis de detectar. A equipe como um todo ainda está sobretudo em L1, com a maioria das pessoas na transição para L2. Todos já sabem usar agentes. O próximo passo é transformar papéis, roteamento, aceitação e permissões em um sistema de trabalho comum.