Apollo Summit 2026 Product Highlights: The Governed Graph for Agents and Apps

There’s a clear chain of logic that most companies adopting agents discover through trial and error:

• Agents need enterprise context to do meaningful work. Without information about the business, they’re glorified chatbots: off-the-shelf LLMs with a thin wrapper.
• To get the right context, agents need APIs. APIs run the business. Knowledge management tools and data warehouses provide some helpful information, but when agents need to get real-time data, access business logic, or take action, you’ll need to connect them to your APIs.
• APIs weren’t built for agents. Responses contain sensitive data like PII intermingled with innocuous material. They use shorthand field names or otherwise obscure what a field means and how it should be used. How one API relates to another is opaque, so just handing them all to an agent becomes a guessing exercise.

Solving this problem requires a domain model: a clear, governed map of what a company’s systems and APIs are, how they relate, and who or what is allowed to see and act on them. Most enterprise systems do not have one built for this purpose today. A single request for a customer’s record can return sensitive fields an agent was never meant to see, and every one of those fields is now sitting in a log or a model’s context window. Identity also gets dropped at the agent boundary, because most APIs were built for trusted developers and an agent has no human to authenticate as. 

Apollo has spent more than a decade orchestrating APIs for the production applications enterprises run on. GraphOS today handles more than 2 trillion operations every month for companies like Wayfair, Expedia, and Indeed. This week at Apollo Summit in San Francisco, we showed what it means to extend that same graph, the one companies already use to govern access for people, to govern access for agents.

We introduced GraphOS Agent Services, giving AI agents secure, governed, and auditable access to enterprise systems and data, and expanded agentic development tooling that helps any team build a working domain model in minutes. Alongside these, we shipped continued investment across the Apollo GraphOS platform, spanning developer experience, performance, and security.

Here’s a closer look at what shipped. 

Introducing GraphOS Agent Services

Building your first AI agent is relatively easy. Scaling agents across an enterprise is harder. As more agents connect to more APIs and MCP servers, organizations need a way to control which systems and data each agent can access, understand who is acting through an agent, and prove what happened after every interaction. GraphOS Agent Services is now available in public preview, giving organizations a secure and governed way to connect AI agents to enterprise systems and data. 

GraphOS Agent Services sits between AI agents and an enterprise’s systems. It translates each agent request into the right API calls, brokers the credentials for each one, and enforces controls on what a person or agent is allowed to see or do, field by field. It uses a domain model to provide context for every interaction: the services and entities in your business, how they relate, and the policies that apply to them. 

To control how agents interact with a domain model, it adds four new capabilities to GraphOS:

1. Search, to let agents find the right data and tools to use
2. Identity, to manage credentials for agents
3. Policy, to apply field-level controls on what each agent can see and do
4. Audit, to maintain a log of everything that happened for observability, insights, and compliance

Because policies apply at the field level, sensitive data can be kept out of an agent’s context entirely, while agents can still reach the information they are authorized to use. Your teams can give each agent its own identity, carry the identity of the person using it through a request, enforce policies against specific data, and keep an auditable record of agent activity. The result is a deterministic way to govern agent access to APIs, with the policy engine making each decision rather than the model. Where an Apollo MCP server exposes a GraphQL API as tools an agent can call, GraphOS Agent Services sits at the access control layer above it, controlling what any agent is allowed to see and do. 

GraphOS Agent Services is available today in public preview. For the full story, read the GraphOS Agent Services announcement blog and documentation. Interested in bringing secure, governed agent access to your organization? Book a demo.  

A first look at GraphOS Desktop

At Summit, we’re giving you a first look at GraphOS Desktop, a new agentic development environment designed to help developers get their APIs ready for agents. GraphOS Desktop brings functionality from Rover and Studio together on your desktop, with agent assistance to help you build your domain model from existing APIs, systems, or specifications rather than starting from a blank page.

This is an early look at GraphOS Desktop as we continue to develop and refine the experience before making it available more broadly.

Continued GraphOS platform investment

Apollo’s continued investment in GraphOS gives software teams practical solutions to the challenges of running API orchestration at scale. The latest improvements focus on agentic development, performance, security, and developer experience.

Agentic development

GraphOS Factory: build your domain model faster

GraphOS Factory is an agent skill that builds your domain model quickly by turning existing REST APIs into Apollo Connectors, the fastest way to bring a service into your graph. Point it at an OpenAPI or Swagger spec, or a link to the API docs, and it walks you through the design decisions that shape the model, then exports a Connectors subgraph you can add to your supergraph.

What sets it apart is that it is iterative, not one-shot. Decisions and sources are recorded in Git, so as APIs change or you widen the scope, your domain model grows with them instead of starting from scratch, and a teammate can pick up where you left off. GraphOS Factory is available now as a preview skill in the Apollo Skills collection on GitHub.

Read the GraphOS Factory blog post. 

A full suite of agent-ready tools in GraphOS MCP Server

The GraphOS MCP server has grown into a full suite of agent-ready tools for building and managing the graph. The GraphOS Platform API is how teams automate GraphOS from their own code, from publishing schemas and running checks to managing variants and reading insights. The MCP server now exposes more of that API to agents, so those same actions can be driven in natural language instead of custom code. 

An agent can read a live graph and answer questions like “Is my graph healthy?” using launch history, composition errors, lint, and metrics, the same diagnostics an engineer would otherwise run by hand, in minutes instead of an afternoon. The MCP server now supports OAuth as well, so developers can connect their tools without managing personal API keys.

Read the GraphOS MCP Server documentation. 

Performance, reliability, and security

GraphOS Router 3.0

The GraphOS Router sits at the heart of GraphOS, orchestrating every request across your graph and serving as critical production infrastructure for your applications. Today, we’re announcing the public preview of GraphOS Router 3.0, with a redesigned request-processing pipeline that improves how the Router handles requests while making it easier for us to safely test, improve, and evolve the runtime. That new foundation is already enabling major improvements in performance and resilience. 

GraphOS Router 3.0 introduces circuit breaking to help protect subgraphs when they become overloaded or unavailable. The router can stop sending requests to an unhealthy subgraph to give it time to recover and, when fields can be resolved elsewhere, attempt to route around the affected subgraph. 

This release also introduces the Incremental Query Planner, a ground-up reimplementation of Apollo’s query planning algorithm designed for fast planning and predictable memory usage even for highly complex operations. On typical workloads, GraphOS Router 3.0 will spend 95% less time on query planning compared to GraphOS Router 2.0. In testing across 200,000 operations from some of the most complex customer graphs, it planned each operation in under two seconds, with up to a 300x speedup on the slowest operations and 97% less memory usage. Read the Incremental Query Planner deep dive blog. 

Additionally, GraphOS Router 3.0 now supports Federation version 3, including support for the @oneOf directive from the September 2025 GraphQL specification. We’re also expanding Graph Artifacts to deliver router licenses and feature entitlements alongside your supergraph schema, reducing the router’s dependency on Uplink. Together, these changes make GraphOS Router 3.0 faster and more resilient today while creating a stronger foundation for what comes next. Explore everything new in the GraphOS Router 3.0 announcement blog and documentation. 

Strengthen environment isolation with variant API keys

API keys allow GraphOS to identify actors and the permissions they have in the system. Until now, teams have typically used graph API keys for build and deployment automation. But graph API keys grant access across all variants of a graph, meaning a key provisioned for a development or staging pipeline could also authenticate against production.

With variant API keys, you can scope credentials to one or more specific variants, enforcing stronger environment isolation and least-privilege access at the key level. Managed directly within GraphOS Studio, these keys can be used to publish variant schema updates, run subgraph checks, and create subgraphs in CI/CD pipelines without granting access to every variant in the graph. Variant API keys are generally available today. 

GraphOS Router Support Tool 

Troubleshooting a production issue often means piecing together context from multiple places including router configuration, logs, pod health, metrics, and more. The new GraphOS Router Support Tool simplifies that process by collecting a diagnostic snapshot of your GraphOS Router and its Kubernetes environment into a single, sanitized support bundle.

With one on-demand collection, the tool captures router version and configuration, current and previous-container logs, pod status and resource information, and a point-in-time metrics snapshot when available. Sensitive information including credentials, tokens, authentication configuration, and other router specific data is automatically redacted before the bundle is written. Collection happens externally without affecting the running router, making it safe to use even when your router is already degraded.

The bundle stays entirely within infrastructure you control locally or in customer-owned storage and Apollo support team only sees it if you choose to share it. The result is a more complete diagnostic picture, often enough to diagnose and fix the issue yourself, and if not, provides the context Apollo Support needs to help troubleshoot faster. Read the GraphOS Router Support Tool blog for details. 

Repeatable GraphOS Router release validation

Testing distributed systems across the range of real-world environments they run in is hard. That’s why we built the Runtime Testing Framework (RTF), a repeatable, declarative approach for validating GraphOS Router releases against deployed, production-like environments. RTF lets us test across different supergraphs, configurations, resource limits, and traffic patterns, helping us identify meaningful performance changes before releases reach production. Read our two-part blog series to learn how we built RTF and how we’re using it to strengthen the GraphOS Router performance testing and release quality. 

Developer experience improvements

Faster Apollo Connectors development

Apollo Connectors v0.4 is generally available, with improvements across developer experience, performance, and security. It resolves issues teams hit adopting Connectors in the past, which makes Connectors a stronger fit for larger production use cases. 

Highlights include request-less connectors, which let you define a GraphQL field from a pasted example response before you have credentials for the real API, a cleaner mapping language that both developers and agents get right more often, and native support for abstract types. Connectors now serve as the primary way to pull services into your graph, and the same mechanism GraphOS Agent Services uses to connect to the systems it governs. 

Read the Apollo Connectors v0.4 blog and documentation.

What’s New in Apollo Client 4.3

Apollo Client 4.3 adds custom scalars, the number one most requested feature. You define how a scalar is parsed once, and values like dates arrive as ready-to-use types like Date, consistent everywhere they appear, including variables and cache writes. The release also brings TypeScript improvements for safer cache and incremental data handling.

Read the Apollo Client 4.3 blog.

Mock data for Apollo Kotlin with Apollo Mock 

Apollo Mock lets you use LLM-generated mock data straight from your schema, so you can build and test without waiting on a finished backend or a stable staging environment. It generates a full set of fake entities once, then serves them from a small GraphQL server, so results are fast and deterministic and do not depend on a model at runtime. Apollo Mock is experimental and starts with Apollo Kotlin, with the intent to expand to Apollo’s other clients.

Read the Apollo Mock blog and documentation.

Rover 1.0

Rover 1.0 is now generally available, giving teams a stable, enterprise-grade CLI they can standardize across CI/CD and local development. The headline is OAuth-based authentication: run rover login instead of managing long-lived API keys. This means agents can now work directly with the Rover CLI,. Rover 1.0 also adds native contract variant checks and Rover profiles for configuration, and brings client operation checks in from the legacy Apollo CLI, which is now fully deprecated. 

Read the Rover 1.0 blog and documentation. 

More consistent schema proposals

Earlier this year, we introduced a range of schema proposal improvements to make authoring, reviewing, and integrating proposals into developer workflows easier. We’re continuing that investment with improvements that make proposal changes easier to understand and track over time. 

• Compare revisions more easily: Previously, reviewers had to revisit an entire proposal to understand what changed after an approval. Now, they can compare any two revisions and quickly see what changed between them. 

• Focus on what actually changed: Previously, changing a single field on a large type displayed the entire type in the diff, making the actual change harder to find. Now, proposal diffs show only the changed lines and surrounding context, with a Show full type option when reviewers need the complete definition. 

• Preserve implemented changes: Previously, implemented markers could be lost across republishes or Pull Changes. Now, implemented changes retain their credit even when formatting differs, and shipped changes pulled into a proposal’s starting schema are marked as “Absorbed” rather than disappearing, preserving a permanent record of their completion. Check out our documentation to learn more. 

Apollo GraphOS Operator supports Apollo MCP Server

With Apollo GraphOS Operator 1.5.0, you can now deploy and manage Apollo MCP Server directly in Kubernetes. A new MCPServer custom resource lets the Operator handle the configuration needed to run an MCP Server in front of any graph it controls. You can also use the Operator to run a fleet of MCP Servers for graphs already registered in GraphOS Studio, making it easier to deploy and manage MCP infrastructure at scale. 

Get started with Apollo GraphOS 

Get hands-on with all of these features and more by starting your Apollo GraphOS free trial today and check out our documentation. 

GraphOS Agent Services is available today in preview. If you’re exploring how to give AI agents secure, governed access to your enterprise systems and data, join the waitlist to learn more and talk with our team. 

Want the full story? Watch the Apollo Summit 2026 keynote from Matt DeBergalis.