This is a summary of a longer piece published on the WunderGraph blog. , including how entity keys get propagated across subgraphs. Tooling then identifies which subgraphs are affected, propagates entity key requirements automatically, and routes the proposal to the right owners for review. Each team approves their slice. Implementation begins with a validated, agreed-upon spec.
The result is that the coordination which currently happens informally — across Slack, Miro boards, and meetings — gets a structured surface. Affected teams are identified automatically rather than through institutional knowledge. Sign-off is tracked rather than assumed.
What this means for teams running large supergraphs
The value of this model scales with graph size. At five subgraphs with one team, informal coordination is fine. At fifty subgraphs with fifteen teams, the absence of a structured design-time workflow is itself a product risk. Changes move slowly not because engineers are slow, but because the process of getting alignment has no tooling support.
Fission is positioned as a design-time complement to Federation's runtime machinery — not a replacement. Query planning and execution stay with Federation. The workflow for deciding what the supergraph should look like, and getting teams aligned on it before implementation begins, is what Fission addresses.
It's also, the post notes, the model that makes most sense as AI agents start contributing to API development. An agent that can query the supergraph for existing capabilities and propose structured changes for missing ones — with a human reviewing before anything ships — fits naturally into this workflow. The coordination layer has to exist for that to work at all.
The full article walks through an example of a schema change. Read it on the WunderGraph blog.
SOCIAL SHARE CARD GENERATOR