Apollo Summit 2026: agents, routing, and smaller graphs

Apollo used Summit 2026 to show the next shape of GraphOS. Two previews are the ones I keep coming back to.

GraphOS Agent Services sits between an agent and the systems it calls. It brokers credentials, applies policy down to a field, and keeps a record of the interaction. Agents connect to one endpoint, and they do not hold the upstream keys.

Router 3.0 rebuilds the request pipeline. Apollo says the Incremental Query Planner spends 95% less time on query planning than Router 2.0 on typical workloads, and the release adds circuit breaking so an overloaded subgraph can drop out of the path while it recovers.

Both are public previews. I am treating that as a reason to look closely, and as a reason to wait for production evidence before I treat either one as finished.

The authorization space around agents is moving fast. A demo that can read one system is easy to stand up. A fleet of agents, each acting for a different person, against APIs that were built for trusted developers, is a different problem. Those APIs usually return a blob. If an agent should not see a credit limit, the old choices were to allow the call or block it.

GraphOS Agent Services is Apollo's attempt to make that decision precise. Identity can travel with the person who asked, from the client all the way to the upstream system. Fields can be tagged, and a policy can mask a value, deny it, or leave it out of the request so the upstream system is never asked for it. The policy engine makes the call.

I am excited to look deeper at what this can do. GraphOS already orchestrates more than 2 trillion operations a month. Agent Services is the bet that the same control plane can govern agents at that kind of scale. Intuit is piloting it. I want to see how search, identity, policy, and audit hold once more than one team is depending on them. Security review stalls agent programs when nobody can say what an agent will touch. A field-level answer, with a log of the denials, is the problem worth solving.

I talked with some of the engineers who built Router 3.0. What stayed with me is how far down they are willing to go. A request moves through stages.

1. Parse and validate the request
2. Plan how the subgraphs will satisfy it
3. Execute those fetches
4. Merge the responses
5. Serialize them back to the client

They are taking each of those stages apart to get time back.

The published gains are concentrated in planning, which is the stage that blows up on a large, highly connected graph. The Incremental Query Planner drafts a plan quickly, then spends a bounded budget improving it, instead of searching until the space is exhausted. Apollo tested that planner on 200,000 operations from some of the most complex customer graphs. Each one planned in under two seconds. The slowest cases were up to 300 times faster, with 97% less memory. On typical workloads they report 95% less time in query planning than Router 2.0.

Circuit breaking belongs in the same story. If a subgraph is already failing, the router can stop sending it traffic, give it room to recover, and try to resolve a field somewhere else when that is possible. Speed and resilience are the same effort here: keep the request path useful when one dependency is not.

I left that conversation wanting the traces from a real graph. The discipline is measuring every stage of the lifecycle, then spending the next release on the stage that still costs too much.

I gave a presentation on smaller graphs. The claim is straightforward. Split a graph on trust boundaries, for security and for privacy. A schema that crosses those boundaries asks every caller to carry data, and every reviewer to reason about data, that the caller was never meant to touch.

There is a second cost, and agents make it obvious. A large schema stuffed into a context window costs tokens. The model spends them on types and fields it will not use. The same waste shows up below the model. Every field you fetch, join, and ship is work. Churning data you do not need to process has a real cost in latency, in load on the subgraphs, and in the time people spend explaining where that data went.

Agent Services tries to keep the wrong fields out of an answer. Smaller graphs try to keep the wrong schema out of the problem. I want both. Draw the trust boundary in the architecture, so the schema an agent can even see already matches what that agent is allowed to know. Then use field-level policy for the cases that still have to share a graph.