Os agentes decidem. O código executa. O trabalho é saber onde está a linha.

Anda uma frase pelas administrações que soa a futuro e se comporta como uma fatura: os agentes vão substituir as aplicações. Vale a pena levá-la a sério, porque a parte que é verdade é genuinamente nova, e a parte que não é vai ser paga por quem construir em cima dela.

A pergunta útil não é se se usam agentes. É onde cai a linha entre o que um agente decide e o que o código executa. Ponha-a no sítio errado e fica com um sistema lento, caro, impossível de auditar, e de vez em quando confiante a respeito de uma coisa que nunca aconteceu.

O que mudou de facto

Os modelos ficaram bons em três coisas em que o software era historicamente mau: ler uma instrução escrita por uma pessoa, parti-la em passos, e escolher a ferramenta certa para cada passo. Não é uma mudança pequena. Dispensa antecipar todas as formas como alguém pode formular um pedido, que é a maior parte do que torna rígidas as interfaces tradicionais.

O que não mudou foi tudo o que está por baixo. Uma regra fiscal continua a ser uma regra fiscal. Um pagamento ou liquida ou não liquida. Uma verificação de permissões tem uma resposta certa e nenhuma margem para interpretação. Essas coisas nunca foram difíceis por serem maçadoras de exprimir. Foram difíceis porque têm de estar exatamente certas, sempre, e de forma demonstrável depois.

O cérebro e o esqueleto

A comparação que sobrevive ao contacto com um projeto real é anatómica. O modelo é o cérebro: percebe, pesa e decide. As ferramentas são os braços: estendem-se e agem. O código é o esqueleto, e sem ele o cérebro não tem o que mover.

Os esqueletos não dão espetáculo. Ninguém demonstra um numa conferência. Mas a analogia vale a pena porque prevê o modo de falha: um sistema construído com cérebro e braços, sem esqueleto, não cai de forma dramática. Funciona na demonstração, funciona uma semana, e depois começa a produzir respostas plausíveis e erradas, a um custo por pedido que ninguém orçamentou.

Reserva-me um voo

O exemplo canónico vale a pena percorrer, porque a linha cai num sítio muito concreto.

O agente deve perceber que uma viagem a Berlim na próxima terça significa partir depois da reunião da manhã. Deve comparar opções, reparar que poupar duas horas custa trezentos euros, e perguntar se essa troca compensa. Tudo isso é juízo sobre um pedido ambíguo, e é exatamente para isso que serve um modelo.

O agente não deve debitar o cartão. Não por o modelo não ser de confiança, mas porque debitar um cartão é uma transação: ou acontece uma vez, ou a contabilidade fica errada. Precisa de idempotência, de política de repetição, de caminho de reversão e de um registo que sobreviva a uma auditoria. Nada disso são decisões. São garantias, e as garantias vivem no código.

Onde cai a linha

O padrão não é arbitrário. A coluna da esquerda é tudo o que tem de ser idêntico em cada execução, demonstrável depois, e correto mesmo quando a entrada é estranha. A da direita é tudo o que ganha com ler o contexto e exercer juízo.

O que quer que se queira testar unitariamente pertence à esquerda.

O erro que continuamos a ver

O erro de arquitetura mais comum é pôr a lógica de negócio no prompt. Funciona logo, e é isso que o torna perigoso.

As regras vão para o prompt de sistema, depois as exceções, depois as exceções às exceções. Seis meses depois o prompt tem quatro mil tokens, cada pedido paga-os todos, e ninguém consegue dizer com confiança o que o sistema faz com uma entrada invulgar, porque a resposta não está escrita em sítio nenhum que se leia como lógica. Mudar uma regra arrisca mudar outras três, e não há teste que apanhe isso.

As mesmas regras escritas em código são mais baratas em cada pedido, revistas num pull request, e testáveis. O prompt passa a fazer aquilo em que é bom: decidir qual daquelas regras se aplica a esta situação.

O agente nunca toca na base de dados

Se há uma regra que valha a pena guardar deste artigo, é esta.

Uma pergunta como "que clientes estão sem backup?" não deve tornar-se SQL escrito por um modelo. Deve tornar-se uma chamada a uma coisa que já existe:

# A API é o contrato. O agente escolhe chamá-la;
# o código decide o que isso significa e quem pode perguntar.
@router.get("/customers/without-backup")
def clientes_sem_backup(user: User = Depends(current_user)):
    if not user.can("read:customers"):
        raise Forbidden()
    return repositorio.clientes_sem_backup(tenant=user.tenant)

O agente escolhe a ferramenta. O código impõe quem pode perguntar, sobre que cliente pode perguntar, e o que a pergunta significa. Se o modelo de permissões mudar, muda uma função e todos os chamadores herdam a mudança, incluindo o agente.

Escrito ao contrário, com o modelo a gerar consultas contra a base de dados, o modelo de permissões passa a viver num prompt, e um prompt é uma sugestão.

É a mesma fronteira de que falámos em o assistente de IA que só lê o que o utilizador pode ler: o assistente é tão seguro quanto a camada que tem por baixo, e mais nada.

Para que serve o MCP

O Model Context Protocol é a parte disto que mais depressa avançou, e vale a pena ser preciso sobre que problema resolve.

Antes dele, cada assistente falava com cada ferramenta à sua maneira. Ligar um modelo a um sistema interno obrigava a escrever um adaptador para aquele modelo, e a escrevê-lo outra vez para o seguinte. O MCP normaliza essa conversa: a ferramenta descreve o que sabe fazer, e qualquer cliente que fale o protocolo consegue usá-la.

O repositório da especificação tornou-se público em setembro de 2024 e a coleção de servidores seguiu-se em novembro. Essa coleção leva hoje mais de oitenta mil estrelas no GitHub, o que diz menos sobre qualidade do que sobre a falta que a norma fazia.

O que importa em arquitetura é que o MCP é uma camada de descrição, não de execução. Diz a um modelo o que uma ferramenta faz e como chamá-la. Não torna a ferramenta segura, correta nem auditável. Isso continua a ser propriedade do que está por trás do endpoint, ou seja, propriedade do seu código.

Onde isto ajuda mesmo

A versão honesta do valor é mais estreita do que o discurso e mais útil.

Um agente ganha o seu lugar onde a entrada é ambígua e a ação é delimitada. Ler o email de um fornecedor e propor a que encomenda corresponde. Transformar a descrição de um problema na consulta certa a sistemas que não partilham esquema. Ler um contrato e assinalar as cláusulas que diferem do modelo. Em cada caso a parte difícil é a interpretação, e a ação que se segue passa por código que correria de forma idêntica se tivesse sido uma pessoa a carregar no botão.

Não ganha nada onde a entrada já é estruturada e as regras já são conhecidas. Se um formulário tem oito campos e a validação é uma lista de condições, um agente acrescenta latência, custo e incerteza a troco de nada.

O que isto significa para a arquitetura

Os agentes são uma camada nova, não um substituto das que estão por baixo. A pilha que construímos é a mesma de sempre, com um acrescento no topo:

A camada de API é onde isto se ganha ou se perde. Já existia antes dos agentes, e se foi bem construída quase nada precisa para os servir: já sabe quem pergunta, o que essa pessoa pode ver, e o que cada operação significa.

O que é a conclusão incómoda para quem espera que os agentes tornem o trabalho antigo desnecessário. Tornam-no mais valioso. Uma organização com APIs limpas e um modelo de permissões a sério põe um agente à frente delas em semanas. Uma organização sem isso não está lenta por lhe faltarem agentes. Está lenta porque a fundação nunca foi construída, e pôr um modelo por cima torna isso mais visível, não menos.

A parte que envelhece bem

As ferramentas vão mudar. O modelo que hoje está em produção será substituído duas vezes antes de isto ficar velho, e o protocolo pode ser substituído também.

O que não vai mudar é a divisão do trabalho. O juízo de um lado, as garantias do outro. Os sistemas que os mantêm separados trocam de modelo sem tocar nas regras, e mudam as regras sem treinar nada. Os que os misturam têm de reconstruir os dois de cada vez que um deles se mexe.

Escrevemos há pouco que a IA resolveu a sintaxe, mas não o julgamento. Esta é a versão arquitetural da mesma conclusão. Os melhores sistemas que estão a ser construídos com agentes não são os que substituíram o seu software. São os que souberam que metade valia a pena guardar.