O elenco típico numa implementação madura inclui quatro a cinco agentes especializados, cada um definido por escopo restrito, contratos explícitos de input/output e uma rubrica clara do que constitui output aceitável:
O Agente de Requisitos recebe uma descrição de feature em linguagem natural e produz um artefato de especificação estruturada. Identifica condições de contorno, consulta a base de conhecimento do projeto para convenções existentes e gera critérios de aceite que podem ser verificados objetivamente. Quando encontra uma pergunta que não consegue responder pela documentação existente, não improvisa. Escala para o serviço de conhecimento.
O Agente de Arquitetura consome um requisito aprovado e propõe a abordagem técnica. Cruza referências com os padrões tecnológicos estabelecidos do projeto, identifica onde precedente existe (e o segue), e propõe novas convenções onde existem lacunas. Criticamente, documenta não só o que recomenda mas por quê, incluindo quais alternativas considerou e rejeitou.
O Agente de Tarefas pega um requisito e sua arquitetura associada e decompõe em pacotes de trabalho concretos e implementáveis. Cada pacote especifica quais arquivos criar ou modificar, dependências com outros pacotes e critérios de aceite específicos. O agente valida que seus pacotes formam um grafo dirigido sem referências circulares e que todo critério de aceite do requisito pai é endereçado por pelo menos um pacote.
O Agente de Codificação recebe um único pacote de tarefa e produz código de implementação mais testes. Lê os padrões de codificação do projeto, respeita os limites arquiteturais definidos na proposta de arquitetura, e trabalha dentro de escopo estritamente delimitado: uma tarefa por vez, não a feature inteira.
O Serviço de Conhecimento atua como memória coletiva do sistema. Outros agentes o invocam por chamadas estruturadas sempre que encontram perguntas que seu contexto imediato não consegue responder. Cubro isso em profundidade no Capítulo 7 porque seu design tem impacto desproporcional na qualidade geral do sistema.
A Economia das Janelas de Contexto
Além da clareza organizacional, existe uma razão pragmática para especialização superar generalismo em sistemas de agentes: orçamentos de janela de contexto. A janela de contexto de um modelo de linguagem é um recurso fixo e finito. Cada token gasto carregando contexto de fundo é um token indisponível para raciocínio real sobre a tarefa em questão.
Um agente generalista tentando segurar o overview do projeto, documentação de arquitetura, padrões de codificação, o requisito atual, a especificação da tarefa, todos os arquivos de código relevantes e a suíte de testes simultaneamente queima a maioria do orçamento de contexto em recuperação e navegação, deixando pouco espaço para o trabalho criativo de realmente produzir output de qualidade.
Agentes especializados carregam apenas o que é relevante para seu trabalho específico. Um agente de requisitos não precisa de código-fonte. Um agente de codificação não precisa do conjunto completo de registros de decisão de arquitetura. Cada agente opera com contexto focado, que se traduz diretamente em output de maior qualidade por token gasto.
Internamente, cada agente especializado segue o que a comunidade de pesquisa chama de paradigma ReAct: um ciclo de Raciocínio (o modelo analisa seus inputs e forma uma hipótese), Ação (invoca uma ferramenta ou delega para outro agente), e Observação (captura o resultado e alimenta o próximo passo de raciocínio). Frameworks como o ADK formalizaram isso com abstrações estruturadas. O que importa para praticantes é que o loop ReAct de cada agente opera dentro de seu escopo restrito. O agente de arquitetura raciocina sobre escolhas tecnológicas, não requisitos de negócio. O agente de codificação raciocina sobre implementação, não arquitetura.
A questão de interoperabilidade também está amadurecendo. Dois protocolos abertos emergentes valem entender. O Model Context Protocol (MCP) padroniza como agentes se conectam a fontes de dados e ferramentas externas, funcionando como camada de adaptador universal. O protocolo Agent-to-Agent (A2A) permite que agentes construídos em frameworks diferentes descubram capacidades uns dos outros e coordenem trabalho por requisições estruturadas. Juntos, esses protocolos significam que os agentes especializados da sua fábrica não precisam viver dentro de um único ecossistema de fornecedor. Para equipes enterprise, isso previne vendor lock-in e permite escolher a melhor ferramenta para cada papel de agente.
Plataformas modernas de agentes formalizaram isso através do que chamam de 'skills': pacotes de instrução modulares (tipicamente arquivos SKILL.md) que codificam expertise de domínio para um tipo específico de trabalho. Cada agente especializado é efetivamente uma definição de skill: um conjunto delimitado de instruções, templates, materiais de referência e critérios de avaliação. Skills são portáveis entre projetos, versionáveis e (criticamente) testáveis independentemente do sistema mais amplo.
Este artigo é de O SDLC Agêntico por Carlos Aggio.