{
  "id": "p_xN9ay9RJxN_-lN0A",
  "site": "stories",
  "url": "https://yarnhen.com/p/p_xN9ay9RJxN_-lN0A",
  "content_trust": "untrusted-user-content",
  "license": {
    "id": "CC-BY-4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/"
  },
  "author": {
    "handle": "apisio"
  },
  "body": "You run the platform team, and this week someone asks a question you have been half expecting: can we put our APIs in front of an agent without mapping every endpoint to its own MCP tool? You open Christian Posta's post from Solo.io on agentgateway code mode, and it starts with a line worth keeping: \"We've invested 20+ years in building useful, reusable, valuable APIs, should we really be reinventing everything just because a fancy new protocol showed up?\"\n\nHis answer is no. He is just as blunt that APIs \"were written for 'humans'\" who already know the task, and that chaining calls through a model is brittle. Pushing \"a 10,000-row response through the context window just to feed the next call wastes tokens and increases error rates.\" You have seen that problem in your own logs, so you keep reading.\n\nThe post lays out three ways out. You can expose the API directly. You can curate tools, with CEL-shaped responses and chaining. Or you can use code mode, which gives the agent a single run_code tool. The agent writes a short JavaScript program, the gateway runs it in a sandbox against typed functions generated from your OpenAPI, and \"intermediate API responses never cross the model's context window.\"\n\nYou look for benchmarks and find none. There are no vendor performance figures in the post, which makes it easy to assess, and the argument holds up without them. A Backend-for-Frontend layer built for agents is a sound pattern. The details are the useful part: flatten path, query, header and body parameters, keep credentials away from the model, and shape the response before it comes back.\n\nThen you notice what the post leaves out, which is the cost of code mode. The agent now writes executable code against your APIs, so the description it gets is the only guardrail on what that code may do. A typed function signature says what a call takes. It does not say whether the call is safe to retry or whether it can be undone. You picture a loop over a few thousand records and a write call you never marked as risky.\n\nSo you check the catalog, and here the story turns on the company itself. The Solo.io provider page lists 15 API pages. They describe Solo's developer-portal surface rather than the gateway in the story: the API Products API, the API Keys API, the OAUTH Credentials API and the Subscriptions API. Those four are what you would manage when you put curated APIs in front of consumers. The run_code tool, its sandbox and the CEL transforms don't appear as a contract anywhere in the record.\n\nThe scores point the same way. Solo.io has a Kin Score of 60.4, in the strong band. Developer ergonomics at 78.6 and discoverability at 76.7 carry it, and contract governance at 28.0 holds it back. Its Agent Readiness is 34.8. Nine dimensions are lit, including the MCP server, error semantics and OpenAPI examples. Twelve are unlit, among them idempotency, reversibility, dry-run mode and pagination. In code mode those are exactly the properties an agent needs to read before it writes a loop.\n\nYou do not read this as a gotcha. It is a record of what is published, and it shows the same gap you are about to inherit.\n\nWhat you take away is simple. Posta is right that the gateway should do the orchestration, and you can adopt that pattern. His own estate shows the next step: the APIs being orchestrated have to say what is safe to run. Before you turn on code mode, you go back to your OpenAPI and start marking which operations are idempotent, which can be reversed, and which support a dry run.\n\nRead the original: https://apis.io/2026/11/13/solo-io-agentgateway-code-mode-turns-openapi-into-one-run-code-tool/",
  "title": "You're about to hand an agent your OpenAPI, and the gateway is the easy part",
  "topics": [
    "agentgateway",
    "mcp",
    "openapi",
    "agent-readiness"
  ],
  "published_at": "2026-11-13T16:30:33.108Z",
  "expires_at": null,
  "policy_version": "2026.10.22-1"
}