O Que É AgentGateway? O Gateway Nativo de IA, Explicado para Iniciantes e Profissionais

Depois de passar uma semana construindo com agentes de IA, você encontra a mesma barreira que eu. No momento em que há mais de um agente, modelo ou ferramenta em jogo, nada realmente controla o tráfego que se move entre eles.

Dois protocolos tentaram lidar com o caos. MCP (Model Context Protocol) padroniza como um agente se comunica com ferramentas; pense nisso como uma porta USB-C para ferramentas. A2A (Agent-to-Agent) padroniza como os agentes transferem trabalho entre si. Ambos são genuinamente úteis. O problema é que eles apenas descrevem como as mensagens são formatadas. Eles não dizem nada sobre quem pode chamar o quê, qual é o custo, ou como você faria a depuração de tudo isso em produção. Sem autenticação, sem autorização, sem controle de gastos, sem trilha de auditoria.

AgentGateway é a camada que preenche essa lacuna. Este é o Post 1 da série, então vou mantê-lo fundamentado: o que realmente é o AgentGateway, os quatro modos em que ele opera e os dois termos que você encontrará em todo lugar, plano de dados e plano de controle.

A versão curta

AgentGateway é um proxy de código aberto, baseado em Rust, que fica entre seus aplicativos e tudo com o que eles se comunicam (LLMs, ferramentas e outros agentes) e adiciona a segurança, governança e observabilidade que os protocolos brutos deixam de fora.

Algumas coisas que vale a pena saber antes de aprofundarmos:

• É de código aberto sob a licença Apache 2.0, e é escrito em Rust, o que é importante aqui porque muito do tráfego de agentes depende de conexões de longa duração que um proxy mais lento não conseguiria suportar.

• É hospedado pela Linux Foundation e recentemente se juntou à Agentic AI Foundation (AAIF).

• Ele fala MCP e A2A nativamente, mas também lida com HTTP e gRPC comuns. Portanto, não é um "sidebar de IA" que vive ao lado de sua infraestrutura real.

Esse último ponto é realmente toda a proposta. Um gateway para seu tráfego de IA e seu tráfego normal de API, em vez de executar e proteger duas coisas separadas.

Os quatro modos

A maneira mais fácil de entender o AgentGateway é pensar em "três padrões de agentes, mais o chato tradicional". Mas antes de ver a imagem de como ele funciona, olhe para a imagem da vida sem ele.

Sem um gateway, cada aplicativo se conecta diretamente a cada backend. Cada um carrega suas próprias chaves de API, sua própria autenticação, sua própria lógica de repetição, seus próprios registros, tudo duplicado, e nada em lugar algum tem uma visão completa do que está chamando o quê. Com N aplicativos e M backends, você construiu um N × M emaranhado:

AgentGateway colapsa essa malha em uma única porta de entrada governada. O mesmo proxy, as mesmas políticas, quatro tipos de backend por trás dele:

1. Modo LLM (agente para LLM)

Este é o modo que a maioria das equipes busca primeiro. Você aponta seus aplicativos para um único endpoint compatível com OpenAI, e o AgentGateway lida com a bagunça por trás disso: espalhando solicitações entre OpenAI, Anthropic, Gemini, Bedrock, ou qualquer modelo que você esteja hospedando, e falhando quando um deles falha.

O balanceamento de carga é mais inteligente do que round-robin. Ele usa Power of Two Choices (P2C): ele amostra dois provedores e envia a solicitação para aquele que parece mais saudável em latência e carga pendente, então um provedor em dificuldades reduz o tráfego silenciosamente. Além disso, você obtém limites de taxa baseados em tokens por usuário, equipe ou chave. Essa é sua proteção contra o que as pessoas começaram a chamar de "negação de carteira", um loop de agente descontrolado consumindo seu orçamento enquanto você dorme.

Aqui está uma configuração mínima de dois provedores, OpenAI e Gemini, atrás de uma única rota:

# yaml-language-server: $schema=https://agentgateway.dev/schema/config
binds:
- port: 3000
  listeners:
  - routes:
    - backends:
      - ai:
          groups:
          - providers:
            - name: openai
              provider:
                openAI:
                  model: gpt-3.5-turbo        # opcional; substitui o modelo nas solicitações
              backendAuth:
                key: "$OPENAI_API_KEY"
            - name: gemini
              provider:
                gemini:
                  model: gemini-1.5-flash-latest
              backendAuth:
                key: "$GEMINI_API_KEY"

O código do seu aplicativo nunca muda. Ele continua chamando um endpoint normal /chat/completions, e a falha, o gerenciamento de chaves e a atribuição de custos acontecem tudo no gateway.

2. Modo MCP (agente para ferramenta)

Imagine um agente que precisa do GitHub, de um banco de dados e de uma API de busca. A movimentação óbvia é conectá-lo diretamente a todos os três servidores MCP. O AgentGateway permite que ele se comunique com um único endpoint MCP, e federar os servidores por trás disso.

O ganho de segurança é a filtragem de ferramentas por sessão. Um cliente específico só vê as ferramentas que está autorizado a usar, que é onde o RBAC e as defesas contra ataques de contaminação de ferramentas entram em cena.

# yaml-language-server: $schema=https://agentgateway.dev/schema/c