Introducing GraphOS Factory
David Walter
GraphOS Factory is an agent skill that turns an existing REST API into an Apollo Connectors subgraph. Point it at an OpenAPI or Swagger spec, or at the API’s public docs, and it inventories the API, then works with you through the design questions: which operations and fields belong in the graph, what each field means, how the data relates, and what stays out. It validates the result and exports a subgraph you can add to your supergraph and run in Router.
Answering those questions is domain modeling, not wrapping. A REST API describes how one service happens to be exposed. A graph describes the things your business works with and how they relate, and that is what you are building each time you bring a service into it. One connector is one bite of a larger problem. You model a few endpoints at a time, on your own terms, and over many services those pieces add up to a domain model for your business. GraphOS Factory is built for that work: for engineers who make these decisions, record them, and keep the model current as the APIs behind it change.
What makes that possible across many services are the artifacts that GraphOS Factory collects as you work. Every decision, every pinned source, and everything the agent learned along the way is written to disk in Git. That means the work can be resumed, refined, handed to a teammate, and maintained like any other code in your software development lifecycle, instead of being regenerated from scratch each time.
GraphOS Factory is available today as a preview skill in the Apollo Skills repository.
Less manual work to bring a REST API into your graph
Bringing an existing REST API into a graph with Connectors has taken more work than it should. You have to read the API, decide which operations and fields belong in the graph, name things the way the domain thinks about them, work out how pagination and batching map onto GraphQL, and decide what to keep out. For a large API, with hundreds of endpoints and thousands of fields, it is weeks of careful work before the first query runs.
We have been simplifying that work directly in Connectors. The latest release adds request-less connectors, a cleaner mapping language, and native support for abstract types, so more of the mechanics are handled for you.
Agents can speed this up too, but the way most people use them today creates a second problem. Generation is a one-shot event. You get a Connector, you fix it by hand, and the next time you regenerate you lose every decision you made and risk breaking what was working. The API adds endpoints, deprecates a field, or you want to add scope you left out the first time, and you are back to a blank prompt. With a large API it gets worse: the agents might lose the context partway through leading to modifications in the schema that you did not intend to change.
GraphOS Factory treats Connector generation as something you iterate on. The decisions you make, the sources the agent pinned, and what it learned about your API all live in Git next to the output. When the API changes, when you find a bug, or when Connectors ships a feature you want to use, you pick up where you left off. Because the context is on disk and not in one person’s chat history, a teammate can continue the work too.
How it works
You give the agent an OpenAPI or Swagger spec, or a link to the API’s documentation. From there the skill runs a guided process rather than a single generation step.
- Workspace. The agent sets up a dedicated Git workspace for this API. Everything it produces from here on, including its working notes, lands in that workspace.
- Inventory. It pulls the sources, pins them, and builds an inventory of the API’s operations and types.
- Scope. You choose which operations and fields belong in the graph. You can model three endpoints or thirty. You do not have to take the whole API surface.
- Design decisions. The agent walks you through the choices that shape the subgraph: read-only or mutations too, how to handle PII, batching and pagination, what each field means in your domain, and what stays out. Each answer is recorded.
- Validation. Every change is checked with composition, Connector unit tests, and a mocked end-to-end run against the Router. If you provide a credential, it also runs live against the real API.
- Export. When you confirm, it exports a Connectors subgraph you can add to your supergraph.
The result is a subgraph that composes, passes tests, and reflects decisions you made on purpose, with a record of why.
Iterative by design
The difference between GraphOS Factory and a one-shot generator is what gets written to disk. Alongside the subgraph, the workspace holds three kinds of state:
- Decisions. Every scope and design choice you made, in a form the agent reads back before it changes anything.
- Pinned sources. The spec or docs the inventory was built from, so a later run can tell what the API changed rather than re-reading it from scratch.
- Agent discoveries. What the agent worked out about the API along the way: quirks in pagination, fields that turned out to be optional, endpoints that behaved differently than documented.
All of it is in Git, so it is reviewable, diffable, and travels with the code. That changes what a second session looks like. When the API adds or deprecates endpoints, the agent reconciles against the pinned inventory and your existing decisions instead of regenerating. When you want to widen scope, fix a bug, or adopt a newly released Connectors feature, you make that one change and the validation layers tell you whether anything else moved. And because none of this depends on a particular person’s chat history, a teammate can open the workspace and continue where someone else stopped.
Over time, the skill itself gets better, which will lead to higher quality Connectors. Apollo has spent years maintaining Federation and working with teams on domain model design across many industries and scales. As we fold more of that into the skill’s references, users get the latest best practices without changing their workflow.
Who it’s for
GraphOS Factory is for engineers who need to bring an existing REST API into a graph and keep it there as both the API and the graph evolve. In practice that means people doing domain modeling: deciding what a service exposes, what its fields mean, how the data relates, and what stays out of scope. The skill handles the mechanics of Connectors so that your time goes into those decisions.
It also fits teams that do not all use the same agent. The workflow and its decision history live in the workspace, not in the harness, so someone working in Claude Code, someone in Codex, and someone in an IDE plugin can all pick up the same Connector.
Getting started
GraphOS Factory is part of the Apollo Skills collection. Installation instructions are in the apollographql/skills repository.
Once installed, the skill activates when you ask your agent to build a Connector or subgraph from a REST API. In Claude Code you can also invoke it directly:
1/apollo-skills:graphos-factoryGive it the API’s OpenAPI or Swagger spec, or a link to its docs. The agent will set up the workspace, inventory the API, ask you to select operations and fields, and work through the design decisions with you. Each change is validated as you go. When you confirm, it exports a Connectors subgraph ready to add to your supergraph.
A good first run is a few endpoints from an API you already know well. You will see how the decision prompts work, and you will have a workspace to come back to when you want to widen scope.
Where this is today
GraphOS Factory is available in preview. We have validated it with evals on the AppWorld dataset and used it to onboard more than 40 internal services, but it is early and the shape of the skill will change as people use it. We are sharing it now because the iterative, Git-backed approach is the part we most want feedback on.
Try it on an API you care about and tell us what worked and what did not. Issues are welcome in the skills repository. If you’re joining us at Summit, you’ll hear more about it in the Apollo Keynote. And if you can’t be there in person, you can tune in to the keynote live from anywhere via the Summit livestream. We’d love to hear what you think.
