No momento em que uma aplicação começa a chamar tools, a saída do modelo deixa de ser texto para ler e vira uma instrução para agir, e toda garantia que esta série construiu até aqui era sobre tokens. Um framework pode tornar esse loop fácil de escrever e, no mesmo movimento, esconder o throttling, contornar o roteamento do gateway e transformar uma requisição medida em onze que ninguém planejou. A Parte 7 deu retrieval às aplicações. Esta parte trata do que fica em cima disso, e especificamente de quais trabalhos o framework não deveria estar fazendo, porque a plataforma já os faz.

Aponte o framework para o gateway, e pare aí

A mecânica é trivial, e é por isso que a disciplina precisa ser explícita. Um orchestration framework fala o formato OpenAI Chat Completions, o gateway expõe exatamente isso, então a integração é uma base URL e uma credencial:

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    base_url="https://apim-genai-prod.azure-api.net/llm/v1",
    api_key=gateway_token,        # Entra ID token, not a model key
    model="chat-default",         # gateway alias, never a deployment name
    max_retries=0,                # the gateway owns retry and failover
    timeout=60,
)

max_retries=0 é a linha que importa, e é a primeira que as pessoas apagam. Frameworks vêm de fábrica com retry no lado do cliente, exponential backoff e muitas vezes fallback de provider, tudo isso defaults razoáveis para uma aplicação falando direto com um provedor de modelos e tudo ativamente nocivo na frente de um gateway que já faz routing, load balancing e circuit breaking.

Considere o que o retry no lado do cliente faz com o circuit breaker da Parte 3. O breaker abre e retorna 503 precisamente para que os chamadores parem de martelar um backend em falha. Um framework configurado para repetir o 503 cinco vezes com backoff converte esse sinal em cinco vezes a carga, chegando exatamente quando o backend está menos apto a recebê-la. O mesmo vale para o 429: um token limit existe para moldar a demanda, e um cliente que insiste através dele não está sendo moldado. Retries pertencem a um só lugar, e esse lugar já existe.

A contrapartida honesta: um único retry em uma falha de nível de conexão, no cliente, é aceitável. A regra é sobre repetir as respostas do próprio gateway, não sobre instabilidade de rede.

O que o framework ainda deve fazer

Removidos abstração de provider, routing, retry e failover da sua descrição de cargo, um framework fica com as partes que são genuinamente tediosas de escrever à mão e não carregam nenhuma preocupação de plataforma: prompt templating com inputs tipados, geração de tool schema a partir de assinaturas de função, parsing de saída em tipos estruturados e a contabilidade do loop que transforma um tool call em uma mensagem de follow-up. Isso é uma quantidade real de trabalho e uma razão razoável para assumir a dependência.

O que ele não deve virar é o lugar onde a escolha de modelo mora. O alias no código acima é um alias do gateway, resolvido pelo model catalog da Parte 2. O registro de modelos próprio de um framework, suas próprias cadeias de fallback, sua própria lista de providers, tudo isso é um segundo catálogo que vai discordar do primeiro no dia em que um modelo for aposentado.

Tools são a segunda superfície, e podem compartilhar a primeira porta

As tools de um agente merecem o mesmo tratamento que seus modelos: um ponto de entrada governado, acesso por tenant, uma trilha de auditoria. O API Management pode expor uma REST API que ele já gerencia como um MCP server remoto, publicando operações selecionadas como tools que clientes MCP chamam, disponível nos tiers Developer, Basic, Standard e Premium, incluindo suas variantes v2. Associar esse MCP server a um product significa que o acesso às tools é gerenciado pelos mesmos products e subscriptions do acesso aos modelos, que é exatamente o ponto: uma identidade, uma história de quota, um lugar para revogar.

Duas limitações decidem até onde isso vai hoje. O API Management suporta MCP server tools, mas não MCP resources nem prompts, para servers expostos a partir de REST APIs gerenciadas. E MCP server capabilities não são suportadas em workspaces, o que importa exatamente para os times isolados que a Parte 5 apontou para workspaces. Um time que precisa de um workspace gateway e da publicação de tools via MCP tem que escolher um dos dois, e é melhor aprender isso enquanto desenha a arquitetura.

Content safety no caminho do prompt

Um agent loop amplia a superfície de entrada: documentos recuperados, saídas de tools e texto do usuário acabam todos em um prompt. A policy llm-content-safety roteia o conteúdo para o Azure AI Content Safety antes que o modelo o veja.

<llm-content-safety backend-id="content-safety-backend" shield-prompt="true">
  <categories output-type="EightSeverityLevels">
    <category name="Hate" threshold="4" />
    <category name="Violence" threshold="4" />
  </categories>
</llm-content-safety>

Três atributos pedem leitura cuidadosa em vez de cópia. O threshold funciona como uma tolerância, não como um limite: com threshold="4" o filtro permite severidade 0 a 3 e bloqueia 4 a 7, então subir o número aumenta a tolerância e bloqueia menos. É a mesma inversão do threshold de score do cache na Parte 6, e pega as pessoas do mesmo jeito.

shield-prompt="true" liga a verificação de ataques adversariais do usuário, e o default é false. Para um agente que concatena documentos recuperados no seu contexto, esse default é o errado: prompt injection chegando por um documento é a ameaça realista, não um usuário digitando um ataque em uma caixa de chat.

enforce-on-completions, também false por default, estende a verificação às respostas do modelo quando a policy fica no inbound. E window-size, cujo default é o limite de 10.000 caracteres do Content Safety, é configurável apenas para respostas; para requisições a janela default é sempre usada. Um contexto recuperado muito longo é, portanto, avaliado pelo mesmo janelamento que você não controla, o que é um argumento para manter os resultados de retrieval limitados em vez de confiar que o filtro escale com eles.

O que um loop faz com cada número da Parte 5

Uma única pergunta de usuário que dispara quatro tool calls não é uma requisição, são cinco invocações de modelo, cada uma reenviando o transcript que só cresce. Três consequências para a plataforma:

  • A quota por minuto deixa de ser sobre volume de usuários. Ela vira volume de usuários multiplicado pela profundidade média do loop, e a profundidade do loop é uma propriedade do prompt da aplicação, que muda sem uma revisão de plataforma.
  • Um loop descontrolado é indistinguível de carga. O gateway vê requisições bem formadas dentro da quota. A aplicação tem que limitar suas próprias iterações, e a plataforma deve publicar isso como requisito em vez de presumir.
  • Chargeback precisa de um correlation ID por interação de usuário, não por requisição, ou os números por time são verdadeiros e inúteis. Esse ID pertence ao registro de log, que é onde a Parte 5 colocou os dados de alta cardinalidade exatamente por essa razão.

Um teto de tokens por requisição no gateway é um backstop útil, não um substituto. Ele limita o dano de uma chamada enorme; não faz nada contra um loop que faz duzentas pequenas.

Modos de falha para observar

  • Retry do framework derrotando o circuit breaker. O default é ligado. Desligue deliberadamente e documente o porquê, ou o mecanismo de proteção da plataforma vira um amplificador de carga.
  • Um segundo model catalog dentro do framework. Ele vai discordar do catálogo do gateway no dia da aposentadoria, e a aplicação estará presa a um deployment name que ninguém sabia que ela tinha.
  • Threshold de content safety lido como limite. Mais alto é mais permissivo. Um time ajustando falsos positivos pode desabilitar o filtro na prática enquanto acredita que o apertou.
  • shield-prompt deixado no default. Desligado. Em um agente que ingere documentos recuperados, esse é o caminho de injection deixado aberto.
  • Loops sem limite. Nenhuma policy de gateway expressa "pare depois de seis iterações". Só a aplicação pode, então isso é um contrato, não um controle.
  • MCP mais workspaces. Não suportados juntos hoje. Descobrir isso depois de prometer os dois a um time é um rollback de arquitetura.

O que a Parte 9 herda

Aplicações com orquestração, tools publicadas pelo mesmo gateway e content safety no caminho da requisição. Tudo isso configurado em policy XML, mapeamentos de alias e definições de product que hoje chegam à produção como qualquer outra mudança, que é a parte que ainda não foi examinada. A seguir: Azure DevOps, e o que significa condicionar uma mudança de versão de modelo a uma avaliação em vez de a um comentário de review.

Leia isso a seguir

Para o lado de infraestrutura e plataforma de rodar isso em escala, as notas de campo estão em ercan.cloud, e o hub fica em ercanermis.com.

Referências