Um API gateway sabe que um cliente chamou POST /refunds. Um agent gateway também precisa saber quem delegou a tarefa, qual agente escolheu a ferramenta, qual efeito era esperado, quanto budget resta e se o resultado pode disparar outra ação.
Gateways tradicionais oferecem TLS, autenticação, roteamento, load balancing, timeouts, retries, quotas, WAF e telemetria. Tudo isso permanece essencial. Tráfego agentic adiciona operações semânticas sobre MCP, A2A, APIs de modelos, sessões streaming e HTTP normal. A pergunta deixa de ser apenas “este cliente pode chamar esta rota?” e vira “este agente pode descobrir e invocar esta capacidade para este usuário, tenant, tarefa, alvo e efeito?”
Inference gateway é outra camada relacionada. Envoy AI Gateway e Kubernetes Gateway API Inference Extension adicionam roteamento por modelo, abstração de providers, limites por token, prioridade, rollout e otimização de serving. Agent gateway vai além da inferência, cobrindo agent-to-tool e agent-to-agent. As camadas podem compartilhar data plane, mas possuem objetos de política diferentes.
| Dimensão | API gateway | Inference gateway | Agent gateway |
|---|---|---|---|
| Objetos principais | Rotas, métodos, clientes, serviços, headers e payloads. | Modelos, providers, prompts, tokens, filas, aceleradores e inference pools. | Agentes, usuários, tenants, tarefas, ferramentas, skills, recursos, planos e efeitos. |
| Discovery | Catálogo estático ou OpenAPI. | Aliases de modelo e endpoints de serving. | Tools, resources e prompts MCP filtrados por autorização, além de Agent Cards e skills A2A. |
| Autorização | Scope da rota ou recurso, papel, claim, rede e tenant. | Entitlement do modelo, provider, classe de dados e custo. | Sujeito delegado e agente ator, finalidade, tool, objeto, argumentos, efeito e aprovação. |
| Rate limiting | Requests, bytes, conexões ou quota de negócio. | Tokens de entrada e saída, requests, capacidade, custo e prioridade. | Tool calls, mutações, destinatários, profundidade, agentes delegados, tokens, dinheiro e risco. |
| Confiabilidade | Timeouts, retries, circuit breakers e failover. | Fallback de provider, filas, rollout de modelo e streaming. | Efeitos idempotentes, estado durável, cancelamento, espera de aprovação, compensação e fim de loops. |
| Auditoria | Request, identidade, rota, status e latência. | Modelo, provider, tokens, custo, latência e finish reason. | Intenção, plano, versão da tool, política, aprovação, argumentos, resultado e outcome da tarefa. |
Listas de ferramentas e Agent Cards influenciam o que o agente acredita poder fazer. O gateway não deve expor o registry inteiro a todos. Filtre discovery por usuário, agente, tenant, ambiente, tipo de tarefa, classificação, região e aprovação. Retorne apenas capacidades potencialmente autorizáveis no contexto atual e reavalie a política na invocação.
O registry precisa de proveniência: owner, protocolo, endpoint, schema, versão, signer, scopes, classificação de entrada e saída, efeitos, idempotência, classe de aprovação, egress, limites, dependências e depreciação. Trate mudanças na descrição da tool como mudança de contrato porque o comportamento de seleção do modelo pode mudar sem alteração do endpoint.
A especificação de autorização MCP exige protected resource metadata conforme RFC 9728 e enfatiza least privilege. A orientação atual exige validação de que tokens foram emitidos para o recurso e proíbe token passthrough. O gateway deve trocar ou obter token downstream para o protected resource exato, não encaminhar um token amplo recebido do agente.
Preserve o usuário ou serviço sujeito e o agente ator como identidades distintas. Credenciais curtas devem estar limitadas a tarefa, tool, tenant, objeto e operação. Se um agente delega a outro, a cadeia deve continuar limitada e auditável; delegação nunca deve ampliar scope silenciosamente.
Um agente pode respeitar quota de requests e ainda produzir comportamento agregado inaceitável: chamar uma tool barata milhares de vezes, enviar muitas mensagens, criar uma cadeia profunda, gastar tokens ou repetir mutação não idempotente. Aplique limites por call, tarefa, usuário, tenant, agente, tool, modelo e destino.
Reserve budgets antes da execução e reconcilie uso real depois. Inclua tokens, custo, tool calls, writes, registros afetados, destinatários, wall-clock, concorrência, retries, profundidade e score de risco. Ao exceder limite, pause para aprovação em vez de retornar apenas HTTP 429 e incentivar retry automático.
Retries de transporte são perigosos em operações com efeitos. O gateway precisa de metadata declarando idempotência, suporte a idempotency key, erros retryable, compensação e pós-condições. Fallback de provider pode servir para texto, mas ser proibido quando residência de dados, aprovação do modelo ou compatibilidade diferem.
Streaming e tarefas longas também precisam de política de sessão. Reautorize após mudança material de contexto, registry, aprovação ou delegação. Cancelamento e revogação devem chegar aos upstreams, não apenas fechar a conexão do cliente.
Correlacione discovery, autorização, request de modelo, tool call, mensagem A2A, retry, aprovação e resultado sob IDs de tarefa e trace. OpenTelemetry oferece convenções para HTTP e GenAI, e convenções específicas de MCP estão evoluindo. Use atributos estruturados em vez de tratar tudo como POST opaco.
Não armazene prompts, argumentos, segredos ou outputs indiscriminadamente. Registre schemas, hashes, classificações, IDs, versões de política, uso, decisões e referências protegidas. Operações precisam de causalidade; atacantes não precisam de um arquivo de transcrições.
Eu construiria um gateway com data plane HTTP e gRPC compartilhado e extensões conscientes de APIs de modelos, MCP e A2A. O control plane gerenciaria registry assinado, políticas, credential exchange, budgets, egress, aprovações, schemas e telemetria.
A visão principal reconstruiria uma tarefa entre agente, modelo, tool, API e agente downstream. Mostraria por que cada capacidade apareceu, por que cada call foi permitida, como o budget mudou, quais efeitos ocorreram e onde a execução parou.
Um agent gateway não deve decidir se o plano do modelo é inteligente. Deve tornar toda capacidade visível por política, toda identidade explícita, todo efeito limitado, todo retry semanticamente seguro e toda tarefa reconstruível.
Artigo comparando API, inference e agent gateways, com registry de tools, discovery filtrado, autorização delegada, política semântica, budgets, retries e event logs.