As empresas passaram a última década construindo programas API. Uma grande organização agora executa milhares de APIs internas, cada uma com especificação, proprietário, esquema de autenticação e políticas de acesso aplicadas em um gateway. À medida que os agentes passam para a produção, essas APIs são a fonte óbvia do contexto de que os agentes precisam: registros de clientes, status de pedidos, estoque, preços e tickets de suporte.
A questão mais difícil agora é como os agentes alcançam esses sistemas em grande escala. O Model Context Protocol (MCP) deu à indústria uma maneira padrão de conectar agentes a ferramentas. Mas a maneira mais comum pela qual as equipes expõem APIs no MCP, uma ferramenta por operação de API, começa a falhar bem antes de um agente atingir uma parcela significativa do patrimônio da API da empresa.
Veja por que isso acontece, como seria um padrão melhor e como as equipes de plataforma podem construir uma camada de contexto que reutilize a governança que já possuem.
Por que uma ferramenta por endpoint não é escalável
A maneira padrão de transformar uma API em um servidor MCP é pegar sua especificação OpenAPI e gerar uma ferramenta por operação. Isso funciona para uma API pequena. No entanto, uma API corporativa típica de CRM ou ERP pode ter centenas de operações, e um agente que precisa de algumas dessas APIs rapidamente enfrenta centenas de definições de ferramentas.
Usando essa abordagem, três coisas dão errado rapidamente.
- Custo. Cada definição de ferramenta é carregada no contexto do modelo antes que o agente execute qualquer trabalho, e cada resultado intermediário flui de volta pelo modelo. Um fluxo de trabalho de rotina, como procurar um cliente, retirar seus pedidos em aberto e verificar o status da remessa, paga por cada salto em tokens.
- Precisão. Uma vez que a lista de ferramentas ultrapassa o que o modelo pode raciocinar, a seleção de ferramentas se degrada. O agente escolhe a ferramenta errada em um conjunto de opções de aparência semelhante ou faz três ligações onde uma delas serviria.
- Latência. Mais contexto para processar e mais idas e vindas entre o modelo e suas ferramentas retardam o agente. Os usuários percebem isso muito antes de alguém ver a nota do token.
As equipes geralmente respondem com curadoria. Eles cortam listas de ferramentas e dividem APIs grandes em muitos servidores MCP pequenos. Isso ajuda, mas agora cada caso de uso de agente precisa de sua própria integração mantida manualmente. Isso cria a mesma expansão de integração que os programas API foram criados para eliminar.
Modo de código: deixe o agente escrever código na API
A indústria convergiu para um padrão melhor, muitas vezes chamado de “modo de código”. Um servidor em modo de código expõe uma API como uma interface única semelhante a um SDK, em vez de uma lista simples de ferramentas. O agente escreve pequenos trechos de código nessa interface, o código é executado em uma sandbox e apenas o resultado final retorna ao contexto do modelo.
Na prática, o padrão é pesquisar, compreender e executar. O agente pesquisa na superfície da API a operação necessária, extrai o esquema dessa operação sob demanda e a executa. A API completa permanece disponível e apenas as partes que o agente realmente usa alcançam seu contexto.
Isso influencia o que os modelos já fazem bem. Grandes modelos de linguagem têm visto enormes quantidades de código em treinamento e comparativamente pouca sintaxe de chamada de ferramenta. No nível do SDK, um agente pode usar uma API grande na qual nunca foi treinado porque lê a interface da mesma forma que um desenvolvedor faria.
Os ganhos de eficiência são substanciais. Como o agente funciona em código, um snippet pode encadear várias chamadas de API com loops, condicionais e tratamento de erros. Dessa forma, o fluxo de trabalho de várias etapas acima exige menos viagens de ida e volta. Os resultados intermediários ficam fora da janela de contexto. Em nossos testes, um fluxo de trabalho que consumiu cerca de 120.000 tokens por meio de chamadas de ferramentas padrão usou cerca de 1.200 no modo de código.
Para ser claro, o modo de código tem seu próprio custo. Executar código escrito pelo agente significa que você precisa de um sandbox confiável e de total observabilidade do que o código realmente chamou. Uma equipe de plataforma que adota o padrão deve tratar ambos como requisitos desde o primeiro dia.
Roteie o tráfego do agente através do gateway que você já executa
O modo de código resolve o problema da janela de contexto, mas o problema de governança permanece. Um agente que chama uma API de produção precisa de tudo que qualquer outro cliente precisa: autenticação, autorização, limitação de taxa e registro de auditoria.
Muitas equipes que criam integrações de agentes recriam esses controles em um servidor MCP por vez. As credenciais acabam nas configurações do servidor. As regras de acesso são redefinidas por quem escreveu a integração. O tráfego do agente ignora o gateway, por isso nunca aparece nos logs que as equipes de segurança já monitoram.
Uma abordagem melhor trata a camada de contexto como uma extensão da plataforma API. As especificações, esquemas, requisitos de autenticação e políticas de acesso para cada API já estão disponíveis onde a API é gerenciada. Gere a interface voltada para o agente a partir dessa fonte de verdade e encaminhe as chamadas do agente através do mesmo gateway que controla todos os outros consumidores. As políticas existentes então se aplicam automaticamente aos agentes, e o agente se torna mais um cliente governado.
A descoberta também é importante. Registre cada interface pronta para agente em um catálogo central, para que a próxima equipe que estiver construindo um agente possa encontrá-lo e reutilizá-lo, em vez de criar uma quarta integração com o mesmo CRM.
Componha uma superfície de contexto por agente
APIs são apenas parte do cenário. A maioria das empresas já executa servidores MCP, alguns de fornecedores de SaaS e outros construídos por equipes internas. Os agentes também precisam de acesso a fontes de dados empresariais. Um agente útil recorre a todos eles.
Uma camada de contexto deve permitir que as equipes da plataforma componham as fontes. Pegue várias APIs internas e alguns servidores MCP existentes e exponha-os juntos como uma interface de modo de código com escopo definido para o trabalho de um agente específico. Um agente de suporte ao cliente recebe emissão de ingressos, CRM e remessa. Não recebe folha de pagamento.
Esse escopo realiza duas tarefas ao mesmo tempo. É um controle de segurança, pois o agente só pode alcançar o que sua tarefa exige. É também um controle de desempenho, porque uma interface menor e relevante mantém o modelo focado.
Curadoria é o ponto. Mais contexto não é automaticamente melhor contexto. O objetivo é disponibilizar aos agentes a amplitude do empreendimento e, ao mesmo tempo, manter o que chega ao modelo pequeno e relevante.
Como implementamos o modo de código no Kong
Na Kong, incorporamos esses princípios no Kong Context Mesh, agora disponível como parte do Kong AI Management. Eles ampliam a abordagem que introduzimos com Kong Context Mesh no início de 2026.
As equipes da plataforma reúnem suas APIs, servidores MCP existentes e fontes de dados corporativos, e o Kong AI Gateway gera as interfaces MCP em modo de código que os agentes usam para alcançá-los. Como o gateway gera e atende essas interfaces, o acesso do agente fica na mesma plataforma que as equipes já usam para controlar o tráfego de API e IA.
Os agentes são tão bons quanto o contexto que podem alcançar. Agentes eficazes necessitam de amplo acesso aos sistemas empresariais, fornecidos de forma seletiva e sob demanda. As empresas que avançam mais rapidamente estão a tratar esse contexto como infra-estrutura. Eles irão gerá-lo a partir de sistemas que já gerenciam, governá-lo com políticas que já aplicam e definir o escopo do trabalho que cada agente precisa realizar.
As APIs se tornaram a espinha dorsal dos negócios digitais porque as equipes de plataforma as tornaram detectáveis, seguras e governadas. Os agentes precisam da mesma disciplina. A boa notícia é que a maioria das empresas já construiu a base.
–
Fórum de Nova Tecnologia oferece um local para líderes de tecnologia — incluindo fornecedores e outros colaboradores externos — explorarem e discutirem tecnologias empresariais emergentes com profundidade e amplitude sem precedentes. A seleção é subjetiva, baseada na escolha das tecnologias que acreditamos serem importantes e de maior interesse para os leitores do InfoWorld. A InfoWorld não aceita material de marketing para publicação e reserva-se o direito de editar todo o conteúdo contribuído. Enviar tudo consultas para [email protected].
