Um agente é uma integração. Cem são um problema de governação.

A pergunta interessante sobre agentes deixou de ser se funcionam. Nos projetos que vemos, um agente que lê o email de um fornecedor e propõe a encomenda correspondente funciona suficientemente bem para se guardar. A pergunta interessante é o que acontece no dia em que existem quarenta, construídos por quatro equipas, três das quais já passaram a outra coisa.

Isso não é um problema de IA. Cada uma das suas partes é um problema que a indústria já conhece pelo nome: identidade, atribuição de acessos, auditoria, imputação de custos, alcance de uma falha, controlo de alterações. A dificuldade é chegarem todos ao mesmo tempo, colados a uma coisa que decide por si.

Três vagas, e só a terceira é difícil

A primeira vaga foi sobre modelos. Qual, com que tamanho, a que preço por milhão de tokens. Parecia decisiva na altura e revelou-se a menos duradoura: o modelo que hoje está em produção será substituído duas vezes antes de este artigo ficar velho.

A segunda vaga foi sobre agentes. Como ligar um a um sistema real, onde cai a linha entre o que ele decide e o que o código executa. Escrevemos sobre essa linha em os agentes decidem, o código executa, e a resposta mantém-se: juízo de um lado, garantias do outro.

A terceira vaga não é sobre agentes melhores. É sobre um conjunto deles. E um conjunto comporta-se de forma completamente diferente de uma integração, porque muda o modo de falha. Um agente que erra uma permissão é um defeito. Quarenta agentes a partilhar um service principal é um incidente sem forma de saber qual deles agiu.

O que mudou mesmo no último ano

Aconteceram duas coisas que vale a pena enunciar com precisão, porque a precisão é o argumento.

Os agentes passaram a ter identidade a sério. O Microsoft Entra Agent ID introduz quatro tipos de objeto novos: um agent identity blueprint, um blueprint principal, uma agent identity e um agent user. Uma agent identity é uma conta no Entra ID, governada com a mesma maquinaria de ciclo de vida de uma pessoa: pacotes de acesso, gestão de direitos, Acesso Condicional aplicado ao nível do blueprint para que todos os agentes dele criados herdem a política, e sinais de risco vindos do Identity Protection.

A parte desse desenho que merece uma pausa é o patrocinador. Cada agent identity tem uma pessoa responsável pelo seu acesso e pelo seu ciclo de vida. Se essa pessoa sair da organização, o patrocínio transfere-se automaticamente para a chefia. Há sempre alguém a responder pelo agente, por construção, e o sistema recusa-se a deixar que esse alguém seja ninguém.

Os agentes não ganharam forma estável de registar o que fizeram. As convenções semânticas GenAI do OpenTelemetry, o vocabulário neutro para os rastos dos agentes, passaram para um repositório próprio na versão v1.42.0, de 12 de junho de 2026, e continuam pré-estáveis. Não há 1.0. O formato já é bom e amplamente emitido, e continua explicitamente sujeito a mudar.

Postas lado a lado, a assimetria é a história toda:

Já se consegue dizer quem é um agente, no que pode tocar e quem responde por ele. Dizer exatamente o que fez, num formato que ainda se leia no ano que vem, é a parte que não chegou. Quem planeia um conjunto de agentes este ano planeia à volta dessa falta, tenha dado por ela ou não.

O protocolo criou uma estrutura de governação

Há uma segunda prova, e não é uma analogia.

O Model Context Protocol passou o primeiro ano a ser uma camada de descrição: esta ferramenta existe, chama-se assim. As revisões seguintes foram quase todas sobre controlo. A revisão de junho de 2025 classificou os servidores MCP como Resource Servers de OAuth 2.0, tornou obrigatórios os metadados de recurso protegido do RFC 9728, e passou a exigir que o cliente ligue cada token a um servidor concreto através do parâmetro de recurso do RFC 8707. A revisão de novembro de 2025 acrescentou consentimento incremental de âmbitos pelo cabeçalho WWW-Authenticate, documentos de metadados de client ID para registo, e um mecanismo experimental de tasks para pedidos duradouros, com sondagem e recolha diferida do resultado.

Este último importa mais do que parece. As tasks existem porque os agentes começaram a fazer trabalho que dura mais do que um pedido. Trabalho que dura mais do que um pedido é trabalho que precisa de estado, de dono e de forma de ser cancelado, que é a definição de uma coisa que tem de ser governada.

E depois o protocolo fez o que a infraestrutura faz quando passa a ser estrutural: formalizou a sua própria governação. Grupos de trabalho, grupos de interesse, uma estrutura documentada, um sistema de níveis para os SDKs com compromissos de manutenção. Protocolos que ficam brinquedos não criam comissões.

O que um conjunto de agentes exige, e a quem pertence cada parte

As nove matérias abaixo são as que vimos correr mal. Agrupá-las assim é útil porque mostra que quase nenhuma pertence à equipa de IA.

Só a última linha é nova, e só é nova porque a indústria ainda não criou o hábito.

Uma identidade por agente, e porque é que o atalho sai caro

O atalho mais comum que vemos é um service principal partilhado por todos os agentes que uma equipa publica. É fácil, funciona no primeiro dia, e destrói três propriedades de uma vez.

Perde-se a imputação: o registo de auditoria guarda o principal, não qual dos agentes o usou, e a resposta a "qual deles fez isto" passa a ser um exercício de reconstrução a partir de registos de aplicação que podem não existir. Perde-se o menor privilégio: o principal partilhado acumula a união de todas as permissões de que algum agente precisou, portanto o agente mais recente e menos revisto herda os direitos do mais antigo e mais confiado. E perde-se a capacidade de revogar: desligar o agente comprometido desliga todos.

O desenho que sobrevive é aborrecido e conhecido:

Um blueprint transporta a política. Cada agente recebe dele a sua identidade. O acesso chega num pacote com aprovador e data de fim, em vez de ser uma concessão permanente que sobrevive ao projeto que dela precisou.

O pormenor que merece uma decisão, não uma predefinição

O Entra Agent ID permite que uma agent identity peça um pacote de acesso por via programática, em seu próprio nome, criando um pedido de atribuição. O patrocinador também pode pedir em nome do agente, e um administrador pode atribuir diretamente.

Vale a pena reler a primeira via. Um agente pode pedir mais acesso.

Isto não é um defeito. É a primitiva correta para um sistema onde o trabalho se descobre em execução, e o pedido continua a cair num fluxo de aprovação com um aprovador humano. Mas é uma bifurcação de arquitetura a sério, e deve ser uma decisão tomada de propósito pela organização, em vez de uma coisa que ela descobre numa auditoria.

A nossa posição, pelo mesmo raciocínio que aplicamos a qualquer caminho de elevação de privilégio: poder pedir é aceitável, a aprovação nunca pode ser automática, e o aprovador tem de ser alguém que perceba o que é aquele recurso. Um fluxo de aprovação que encaminha para quem não consegue avaliar o pedido é um carimbo com melhor registo.

A aprovação pertence ao passo irreversível

O instinto, quando uma equipa percebe quanto um agente consegue fazer, é pôr uma pessoa à frente de tudo. Isso falha em quinze dias: quem revê deixa de ler, e acrescentou-se latência sem acrescentar juízo.

A linha que se aguenta é a mesma que governa o resto do sistema. Peça-se uma pessoa onde a ação é irreversível ou visível para fora, e em mais lado nenhum.

O critério não é a importância que a ação parece ter. É se um erro que passe despercebido ainda se corrige na segunda-feira.

O custo é um controlo, não um relatório

O consumo de tokens costuma ser tratado como assunto financeiro descoberto ao fim do mês. Num conjunto de agentes é um mecanismo de segurança, porque custo descontrolado e comportamento descontrolado são o mesmo acontecimento visto de dois ângulos. Um agente preso num ciclo de repetição contra uma ferramenta que falha produz exatamente um sintoma visível antes de alguém reparar no comportamento: a fatura.

O que significa que o orçamento pertence à identidade, e não a um painel:

# O limite pertence à identidade do agente, não a uma revisão mensal.
# Um agente preso num ciclo gasta o seu próprio orçamento e para. Não
# gasta o da equipa, nem o do agente do lado.
def chamar_modelo(agente: AgentIdentity, pedido: Pedido) -> Resposta:
    if orcamento.gasto(agente.id, hoje()) >= agente.limite_diario:
        raise OrcamentoEsgotado(agente.id)       # falha fechado, e avisa
    resposta = modelo.invocar(pedido)
    orcamento.registar(agente.id, resposta.tokens, resposta.custo)
    return resposta

Limites por agente dão três coisas que um relatório mensal não dá: o ciclo trava-se sozinho, a falha é imputada a um agente em vez de a uma equipa, e o alerta dispara enquanto a causa ainda está no ecrã.

Auditoria, quando a razão é uma probabilidade

A auditoria tradicional responde ao que aconteceu e sob que autoridade. Com agentes há uma terceira pergunta, e é a que se faz na sala a seguir a um incidente: porque é que escolheu aquilo.

Essa resposta não pode ser uma explicação do modelo, porque uma explicação dada depois do facto é uma narrativa plausível, não um registo. O que se pode registar é tudo o que rodeia a decisão, e acaba por chegar:

• a identidade do agente, não o principal partilhado;
• as ferramentas disponíveis naquele momento, e as suas versões;
• as entradas que o agente recebeu de facto, incluindo o que um passo de pesquisa devolveu;
• as chamadas a ferramentas, por ordem, com os parâmetros;
• as aprovações concedidas, por quem e quando;
• o modelo e a versão, porque o comportamento muda entre elas.

Recriando isso, reproduz-se a decisão, que é o que um auditor quer. É também exatamente a superfície que as convenções GenAI do OpenTelemetry descrevem, e exatamente por isso o seu estado pré-estável é uma restrição de planeamento e não uma nota de rodapé. Instrumentar agora, fixar a versão da convenção, e contar com migrar.

A conclusão incómoda

Uma organização com identidade arrumada, gestão de direitos a funcionar, auditoria a sério e imputação honesta de custos põe um conjunto de agentes em produção este ano. Uma organização sem isso não está lenta por lhe faltarem agentes. Está lenta porque essa fundação nunca foi construída, e os agentes tornam a falta mensurável de uma forma que nada antes deles conseguiu.

Escrevemos coisa parecida sobre o assistente que só lê o que o utilizador pode ler e sobre o que pôr em ordem antes de ligar o Copilot. O padrão repete-se porque no fundo não é sobre IA. Cada vaga de automatização faz a mesma pergunta a uma organização, e fá-la cada vez mais alto: sabe quem pode fazer o quê, e consegue provar o que foi feito?

Os agentes são a versão mais alta dessa pergunta até hoje. São também a primeira que a vai repetir várias centenas de vezes por dia, sem se cansar, até alguém responder.