A platform team runs four MCP servers for its coding agents: GitHub, internal docs search, a read-only Postgres server and the ticketing system. Someone wants per-tool rate limits and a log of which agent called what, so a gateway evaluation goes on the calendar. Nobody has asked the cheaper question yet, which is how much of that the reverse proxy they already run can handle.

Since July, quite a lot. The 2026-07-28 revision made MCP stateless at the protocol layer: the initialize handshake is gone, the Mcp-Session-Id header is gone, and every request carries its own protocol version, client info and capabilities. Two new headers, Mcp-Method and Mcp-Name, copy the JSON-RPC method and (for a tool call) the tool name out of the body and into headers, where proxies already look. Without sessions, an MCP server behaves much like any other HTTP API, which is why the difference between an API and MCP now comes down to who reads the docs. Before the revision, a proxy needed a body-parsing module to learn which tool was being called, and usually session affinity to keep each client on the backend holding its session. Now stock nginx covers the basics:

LLM routing usually starts as if statements. One service picks the cheap model for ticket summaries. Another hardcodes the strong model because it needs tool calling. A third has a comment reading “never send this to the cloud” directly above a fallback that sends it to the cloud when the local server times out. Changing a model, a price or a provider means editing all three.

The router worth building is a small one: ordered rules over properties you can compute before the request leaves, written like an nginx config in a single file, with no database and no UI. Input size, whether tools or images are present, a data classification tag, a cost ceiling for the single request, which upstreams are healthy. One binary on a cheap VPS reads the file, accepts the OpenAI request shape and picks where each request goes. The rule that justifies the exercise is that privacy routing fails closed.

A gigabyte of disk costs almost nothing. The same gigabyte sent to a log vendor that prices by ingestion costs real money, and pasted into a model’s context window it costs money and answer quality at the same time. Storage is cheap per byte. Everything that touches the bytes afterward is not: ingestion fees, query time, bandwidth on a thin link, a context window that holds only so much, and the attention of whoever has to read the result. Observability is the oldest place this shows up, and agents have just made it louder.

Orkes, the workflow and agent orchestration platform founded by the original engineers behind Netflix’s microservices infrastructure, has closed a $60 million Series B round led by AVP, with participation from Prosperity7 Ventures, Nexus Venture Partners, Battery Ventures, and Vertex Ventures US. The raise signals growing enterprise demand for orchestration infrastructure that can take AI workloads from prototype to production without falling apart.

The company’s foundation is Conductor, an open-source orchestration engine originated at Netflix in 2016 and still actively maintained by Orkes. Netflix’s own internal usage of Conductor has grown fivefold in recent months, and the project counts developers at JP Morgan Chase, Tesla, Atlassian, Oracle, American Express, and GE Healthcare among its users. Since its $20 million Series A in 2024, Orkes has tripled its paying customer base and built a developer community in the hundreds of thousands.

gRPC documentation is thorough on the protocol’s features and sparse on the operational realities of running it at production scale. The gap between the getting-started experience and the production experience is wide enough to have surprised most of the teams that have made the journey. The surprises are not fatal. They are the kind that would have been useful to know before the architecture decision was made.

The gRPC pitch is compelling: Protocol Buffers serialization that is faster and smaller than JSON, HTTP/2 multiplexing that reduces connection overhead, generated client and server stubs that eliminate serialization bugs, strong typing that catches integration errors at compile time rather than runtime. All of these benefits are real. All of them come with operational requirements that the pitch does not emphasize.

The choice between request-response and event-driven communication patterns is one of the most consequential architectural decisions in distributed system design. It determines how services couple to each other, how failures propagate, how the system scales under load, and how difficult it is to trace the flow of data through the system when things go wrong. Most teams treat it as a technology choice — Kafka versus REST — when it is primarily a design choice about how services should relate to each other.

Internal APIs — interfaces between services within an organization’s own systems — receive less design attention than public APIs because they lack the external consumer accountability that forces quality. The teams that consume internal APIs are colleagues, not customers. Breaking changes can be coordinated by Slack message rather than deprecation notice. Documentation is optional when the API author sits nearby.

The organizations that operate this way accumulate a specific kind of technical debt: internal integrations that are brittle, undocumented, and implicitly coupled to implementation details that were never meant to be part of the interface. The cost of this debt is the engineering time spent maintaining integrations that should be stable, debugging failures caused by undocumented behavior changes, and slowing down service evolution because teams are afraid to change APIs that other teams depend on in ways nobody has mapped.

Third-party API integrations are the debts that engineering organizations incur with optimism and repay with regret. The integration that takes two days to build and saves six months of custom development looks like an unambiguous win until the third-party API changes its pricing, introduces a breaking change, degrades in availability, or is discontinued entirely. The costs of the dependency were deferred, not eliminated. They appear later, at a time not of the integrating team’s choosing, with a magnitude that was not budgeted.

The API gateway decision — whether to build custom routing and middleware infrastructure or to adopt a commercial or open-source gateway product — is one of the more consequential infrastructure choices an API team makes, and it is frequently made at the wrong time with the wrong information.

The wrong time is too early: a team of three engineers building an API with one consumer has different infrastructure requirements than a team of thirty engineers building an API platform with hundreds of consumers. The wrong information is a product comparison done without a realistic understanding of the operational overhead that gateway products introduce regardless of their feature set.

The choice between REST, GraphQL, and gRPC is treated in most discussions as a question of technical preference when it is primarily a question of context. Each protocol was designed for a specific problem space. Each performs well in that space and poorly outside it. The comparison articles that declare one winner across all use cases are either selling something or have not operated all three at production scale.

REST’s dominance in public API design is not accidental. The constraints it imposes — statelessness, uniform interface, resource-based addressing — map naturally to HTTP’s caching infrastructure, client library ecosystems, and the mental model that most developers already carry from web development. A REST API can be consumed with curl. It can be documented with OpenAPI. It can be cached at the edge. These properties have real operational value that architectural elegance alone cannot purchase.