Topologia de Equipes para Equipes Formadas por Pessoas e Agentes: Onde os Agentes Realmente se Encaixam

Por Victor Hoang · Atualizado em 22 de setembro de 2026

O Team Topologies é o framework de Matthew Skelton e Manuel Pais para organizar equipes em torno de quatro tipos (stream-aligned, enabling, complicated-subsystem e platform), de modo que o trabalho flua com o menor custo de coordenação possível. Aplicado a equipes em que um agente de IA faz parte do trabalho, os mesmos quatro tipos continuam valendo, mas duas coisas mudam: a carga cognitiva ganha uma nova categoria (responder por uma saída que você não produziu pessoalmente) e a Lei de Conway passa a valer para um sistema em que parte da "equipe" que faz o trabalho é software, e não só pessoas. Esta é a metade estrutural de uma mudança mais ampla abordada em o que é o futuro do trabalho.

Fatos principais

• O Team Topologies define quatro tipos fundamentais de equipe: stream-aligned (alinhada a um fluxo de valor de negócio), enabling (ajuda uma equipe stream-aligned a superar obstáculos e detecta capacidades ausentes), complicated-subsystem (responde por trabalho que exige profundo conhecimento especializado ou matemático) e platform (oferece um produto interno atraente que acelera as equipes stream-aligned). Fonte: Team Topologies, "Key concepts and practices"
• O artigo de 1968 de Melvin Conway enunciou a tese original: "Qualquer organização que projeta um sistema... inevitavelmente produzirá um design cuja estrutura é uma cópia da estrutura de comunicação da organização." Ele também observou que os caminhos de comunicação possíveis em um grupo crescem aproximadamente com o quadrado do seu tamanho. Fonte: Melvin Conway, "How Do Committees Invent?" (Datamation, 1968)
• Na pesquisa DORA de 2025, 90% das organizações adotaram ao menos uma plataforma interna, e o relatório encontrou uma correlação direta entre a alta qualidade da plataforma e a capacidade da organização de obter valor da adoção de IA. Fonte: Google Cloud, anunciando o DORA Report 2025
• O Work Trend Index 2026 da Microsoft constatou que os fatores organizacionais (cultura, apoio do gestor e práticas de gestão de talentos) respondem por mais do que o dobro do impacto medido sobre os resultados com IA em comparação com os fatores individuais, e identificou os profissionais "Frontier", aqueles em que a capacidade individual e a prontidão organizacional se reforçam mutuamente, como cerca de 19% da força de trabalho usuária de IA pesquisada. Fonte: Microsoft WorkLab, "2026 Work Trend Index"

O Que o Team Topologies Realmente Diz

Skelton e Pais criaram o Team Topologies para resolver um problema específico: os organogramas costumam ser desenhados em torno de linhas de reporte, e não do modo como o trabalho realmente flui, e essa distância aparece como implantações lentas, responsabilidades pouco claras e equipes que não conseguem entregar sem a aprovação de outras três. A resposta deles é organizar-se em torno de exatamente quatro tipos de equipe e ser deliberado sobre como essas equipes interagem, em vez de deixar os padrões de interação surgirem por acaso.

Uma equipe stream-aligned responde por uma fatia de valor de negócio de ponta a ponta e é estruturada para entregá-la com o mínimo de repasses. Uma equipe enabling existe para fechar uma lacuna de capacidade em outra equipe, de propósito e de forma temporária, e dar um passo atrás quando a lacuna se fecha. Uma equipe complicated-subsystem assume a parte do sistema que realmente exige conhecimento profundo e restrito (o motor de pagamentos, o modelo de recomendação, o algoritmo de precificação) para que as equipes stream-aligned não precisem, cada uma, de um especialista próprio. Uma equipe de plataforma constrói o produto interno, a infraestrutura compartilhada, as ferramentas e a capacidade de autosserviço que permitem às equipes stream-aligned andar rápido sem reinventar a mesma infraestrutura cinco vezes.

Nada desse vocabulário precisa mudar para descrever uma equipe em que parte do "trabalho" é feita por um agente de IA em vez de uma pessoa. O que precisa ser acrescentado é uma resposta clara a duas perguntas para as quais Skelton e Pais não estavam escrevendo: onde, dentro desses quatro tipos, o trabalho do agente realmente se encaixa, e o que acontece com a carga cognitiva quando uma pessoa responde por uma saída que não produziu pessoalmente.

A carga cognitiva sempre foi a restrição real

O Team Topologies trata o tamanho e o escopo da equipe como consequência de uma única variável: a carga cognitiva, o esforço mental total que uma equipe consegue sustentar antes que a qualidade e a velocidade caiam. Uma equipe stream-aligned que recebe uma quinta responsabilidade sem relação com as demais não fica mais capaz, fica mais lenta e mais descuidada nas cinco. É por isso que o framework insiste em responsabilidades de equipe estreitas e bem delimitadas, em vez de amplas.

Os agentes mudam o que preenche esse orçamento sem necessariamente reduzir o total. Uma equipe que antes gastava a carga cognitiva produzindo uma entrega agora gasta parte dela especificando a tarefa com precisão suficiente para um agente tentar fazê-la, e parte verificando uma saída que parece confiante, esteja ou não correta. De Executor a Orquestrador trata dessa mudança no nível do trabalho de uma pessoa. No nível da equipe, a mesma mudança significa que a carga cognitiva ganha um novo item: a carga de responsabilização, o custo contínuo de responder por uma decisão ou um artefato que um agente, e não um colega, realmente gerou. Ignore esse item ao dimensionar uma equipe e você terá uma equipe stream-aligned que parece enxuta no papel e está se afogando em silêncio em saídas de agentes sem revisão.

Onde os Agentes se Encaixam em Cada Tipo de Equipe

A resposta honesta é que os agentes não criam um quinto tipo de equipe. Eles mudam a composição interna e a carga de interação dos quatro que já existem.

Equipes stream-aligned: o agente trabalha dentro do fluxo e uma pessoa continua dona do resultado

É aqui que mora a maior parte do uso de agentes hoje, e deve continuar sendo o padrão. Um agente redige o código, o texto da campanha, a resposta de suporte ou a análise de primeira passada, e uma pessoa nomeada da equipe continua responsável pelo que for entregue. O escopo da equipe não muda; muda a divisão interna do trabalho. Fique atento ao escopo que cresce na outra direção: uma equipe stream-aligned que começa, em silêncio, a construir e manter a própria infraestrutura de agentes (bibliotecas de prompts, estruturas de avaliação, conectores de ferramentas) além do trabalho real de produto assumiu um segundo trabalho, sem limites, que não aceitou. É o padrão de augmentação, não automação funcionando como previsto, até o trabalho de infraestrutura ultrapassar o orçamento cognitivo da equipe.

Equipes enabling: os agentes aceleram a transferência de habilidades, mas não a tornam automática

Skelton e Pais desenharam as equipes enabling para serem temporárias por natureza: existem para fechar uma lacuna específica de capacidade e se dissolver ou seguir adiante quando ela se fecha. Em um contexto de pessoas e agentes, essa é a equipe que ensina as outras equipes stream-aligned a escrever um briefing de agente utilizável, a definir um padrão de avaliação e a pegar uma saída plausível, mas errada, antes que ela seja entregue. A tentação é deixar uma equipe enabling virar, em silêncio, uma plataforma-sombra permanente, fazendo o trabalho em vez de transferir a habilidade. Isso anula o propósito e esconde a carga cognitiva real dentro de uma equipe que ninguém acompanha à luz do framework.

Equipes complicated-subsystem: o especialista raramente é substituído, o alcance dele é ampliado

Uma equipe complicated-subsystem existe porque alguma parte do sistema exige, de fato, conhecimento profundo e difícil de distribuir. Os agentes são uma escolha ruim para assumir esse subsistema por completo, justamente porque a razão de a equipe existir é que os erros ali são caros e difíceis de pegar sem o conhecimento especializado. Onde os agentes ajudam é no alcance: um especialista que revisa dez primeiras versões, redigidas por IA, de uma mudança no modelo de precificação faz um uso diferente, e muitas vezes melhor, de uma expertise escassa do que o mesmo especialista construindo as dez à mão do zero. É o human-in-the-loop funcionando como previsto: o especialista continua sendo a verificação final, e não um carimbo. O headcount da equipe do subsistema pode diminuir ou a produção pode crescer, mas sua fronteira de responsabilidade e seu padrão de verificação não devem se mover.

Equipes de plataforma: por que uma equipe interna de plataforma de IA surge quase de imediato

Este é o tipo de equipe que mais rápido se expande quando mais de duas ou três equipes stream-aligned começam a usar agentes de forma independente. Deixada por conta própria, cada equipe tende a resolver os mesmos problemas separadamente: qual modelo chamar, como lidar com credenciais e limites de custo, como registrar o que um agente fez para fins de auditoria, como conectá-lo a dados e ferramentas internas com segurança. A pesquisa DORA de 2025 constatou que esse padrão não é exclusivo da IA: 90% das organizações já haviam adotado ao menos uma plataforma interna por esse motivo, e a qualidade da plataforma previa diretamente se a adoção de IA se tornava ganho real de desempenho ou esforço disperso e duplicado.

Uma equipe interna de plataforma de IA se forma pelo mesmo motivo que uma equipe compartilhada de plataforma de DevOps: construir a infraestrutura uma vez, bem feita, e oferecê-la como capacidade de autosserviço vence cada equipe stream-aligned construindo a sua. O que ela costuma assumir: conexões compartilhadas com os provedores de modelos, uma camada de interoperabilidade baseada em MCP para que os agentes alcancem ferramentas e dados internos de forma consistente, e não por cinco integrações pontuais, limites de custo e de uso e um padrão compartilhado de avaliação e registro, para que ninguém reinvente do zero o "como saber se esta saída é boa o bastante". Ela também é a dona natural de tudo que envolva vários agentes coordenando uma tarefa, o tipo de infraestrutura compartilhada e de alto risco que nenhuma equipe stream-aligned deveria assumir sozinha. A Rework trata isso da mesma forma no lado do produto: padronizar os workflows voltados a agentes e a interoperabilidade MCP é território do Work Ops, porque essa infraestrutura não deveria viver de forma redundante dentro de cada equipe que a toca.

A Lei de Conway Quando Parte da Equipe É Software

A observação original de Conway, de 1968, era sobre pessoas: uma organização que projeta um sistema tende a produzir um design que espelha a própria estrutura de comunicação, porque as interfaces entre os módulos acabam combinando com as interfaces entre as equipes que os construíram. Ele também apontou algo menos citado, mas igualmente útil: o número de caminhos de comunicação possíveis em um grupo cresce aproximadamente com o quadrado do seu tamanho, e é exatamente por isso que grupos grandes e pouco coordenados produzem designs dispersos e mal integrados.

Essa lógica não deixa de valer quando um agente faz parte do trabalho. As conexões de ferramentas e os limites de acesso de um agente são, em si, uma interface, estruturalmente igual à fronteira de API entre duas equipes humanas. Se cinco equipes stream-aligned montam, cada uma, a sua versão de "um agente que lê o CRM e redige um e-mail", você ganha cinco integrações ligeiramente diferentes, cinco modos de falha e cinco lugares que uma revisão de segurança precisa checar separadamente. É a Lei de Conway se cumprindo exatamente como previsto, com o acesso do agente às ferramentas ocupando o lugar de um canal de comunicação.

A jogada útil aqui é a mesma que o Team Topologies toma emprestada da intuição original de Conway: a manobra inversa de Conway, que consiste em moldar de propósito a estrutura organizacional que você quer para obter a arquitetura de sistema que você quer, em vez de descobrir sua arquitetura por acaso depois que o organograma já está definido. Se o objetivo é uma única forma coerente e auditável de os agentes se conectarem aos sistemas internos, a organização precisa traçar uma fronteira clara (em geral, a equipe de plataforma) que seja dona dessa interface, em vez de deixar cinco equipes stream-aligned a reinventarem de forma independente e chamar a bagunça resultante de "flexibilidade".

Quatro Padrões de Equipe para o Trabalho entre Pessoas e Agentes

Nenhum destes é uma prescrição para copiar à risca. São formatos reconhecíveis, e a maioria das organizações operará mais de um ao mesmo tempo, em estágios diferentes de maturidade.

Um diagnóstico útil: se você não consegue dizer em qual desses quatro formatos um determinado trabalho com agentes se encontra hoje, esse costuma ser o problema de fato, e não o modelo que você usa nem o prompt que alguém escreveu.

Sinais de que Sua Topologia Não Acompanhou

Alguns sintomas aparecem de forma consistente em organizações que acrescentaram agentes aos workflows sem rever a estrutura das equipes:

• Duplicação silenciosa. Várias equipes stream-aligned construíram, cada uma, a própria versão da mesma capacidade de agente, porque não existe uma equipe de plataforma para oferecê-la uma única vez. É o padrão de Conway fragmentado descrito acima, e costuma aparecer primeiro como um achado de revisão de segurança que revela cinco formas diferentes de os agentes tocarem o mesmo banco de dados de clientes.
• Carga de responsabilização invisível. O plano de pessoal de uma equipe ainda reflete "quanto trabalho esta equipe consegue produzir", sem contabilizar o tempo agora gasto verificando a saída dos agentes. É a versão, no nível da equipe, do paradoxo da produtividade da IA: a atividade sobe, enquanto a vazão confiável não se move como as métricas de atividade sugerem que deveria.
• Uma equipe enabling que nunca vai embora. Uma transferência temporária de habilidades virou, em silêncio, uma equipe que faz o trabalho com agentes para todas as outras, anulando o propósito de uma equipe enabling e escondendo necessidade real de headcount dentro de uma equipe que ninguém acompanha pelo escopo real.
• Uma fronteira de subsistema atravessada. Alguém de fora da equipe especializada começou a usar um agente para gerar saída em um domínio que antes exigia a aprovação da equipe do subsistema, e ninguém atualizou quem de fato responde pelo resultado.

Como Começar a Aplicar Isso

A ordem importa menos do que fazer isso de forma deliberada, e não deixar acontecer por acaso:

1. Mapeie as equipes atuais contra os quatro tipos, com honestidade, sem idealizar. A maioria das organizações descobre trabalho informal de plataforma já acontecendo dentro de duas ou três equipes stream-aligned, sem rótulo e sem coordenação.
2. Pergunte onde a carga de responsabilização mudou e confronte isso com o quadro real de pessoal. Se o tempo de verificação cresceu e o headcount não, a carga cognitiva real daquela equipe é maior do que o organograma sugere.
3. Decida, de propósito, quando vale montar uma equipe de plataforma. A constatação da DORA de que a qualidade da plataforma prevê o retorno organizacional da IA é um bom teste de bom senso: duplicação visível entre equipes costuma significar que o investimento se paga.
4. Dê às equipes enabling uma condição de saída antes de começarem. Defina de antemão como é "a lacuna estar fechada", para que a equipe tenha um ponto natural de dissolução, em vez de se tornar uma função permanente e sem controle.
5. Proteja de forma explícita a fronteira do complicated-subsystem. Registre por escrito quais decisões ainda exigem a aprovação da equipe especializada, qualquer que seja o que gerou o primeiro rascunho, e trate o desrespeito a essa fronteira como um incidente, e não como um ganho de eficiência.

Nada disso é uma reorganização pontual. O próprio enquadramento da Microsoft sobre o papel de "agent boss" e a frontier firm trata a estrutura entre pessoas e agentes como uma questão operacional contínua, e não como um gráfico desenhado uma vez e arquivado, e construir uma cultura preparada para a IA é o que impede que ela volte aos velhos hábitos em um trimestre. As equipes de pessoas e agentes já tratam do lado das normas e da confiança dessa mudança, de como as pessoas constroem relações de trabalho com os agentes no dia a dia. Esta é a metade estrutural do mesmo problema, e as duas só funcionam se alguém de fato for dono da decisão de desenho organizacional, em vez de cada equipe improvisar a própria resposta.

Um organograma de equipes que nunca é redesenhado depois que os agentes chegam não é neutro. A duplicação, o tempo de verificação não contabilizado e a responsabilidade pouco clara acontecem de qualquer jeito, em silêncio, dentro de qualquer estrutura que existia antes de alguém pensar em fazer a pergunta de propósito.