Agents, Federation, and a Community

Every year, GraphQLConf brings the community together and reminds us how much can change in a year. This time we made the trip to the Bay Area for GraphQLConf 2026, stayed for the Working Group Day at Meta, and came home with a lot of notes, a lot of ideas, and a camera roll that was mostly redwoods.

A few themes kept coming up in the talks, hallway conversations, and working sessions. AI agents are becoming a real part of the GraphQL world, both as consumers of APIs and as tools that help us build them. Federation now has a shared, vendor-neutral standard. And underneath both of those things, the community is putting more structure in place for what comes next.

Here are the parts that stood out to us.

When agents meet your schema

Pascal opened one of our favorite threads of the conference with a simple question: what if an agent could pick up any GraphQL API and use it reliably, without a human wiring everything together first?

GraphQL is, on paper, an ideal foundation for agents. The schema describes exactly what exists, the introspection gives an agent a way to discover capabilities, queries let it retrieve information, and mutations let it take action. Yet in the real world, schemas are large, and contexts are tiny.

Semantic introspection is a way to work around this problem. Instead of handing an agent an entire schema and hoping it figures things out, semantic introspection gives it a more reliable way to explore a graph, understand the meaning behind types and fields, and pull in only the context it needs.

The goal is simple: any agent should be able to work with any GraphQL endpoint without a pile of custom glue code. If you want the deeper version, we wrote about it earlier this year in Semantic Introspection.

Closing the loop for coding agents

Where Pascal looked at agents using your API, Michael looked at agents changing it. Coding agents now implement features, refactor systems, and ship changes at a pace that would have sounded made up twelve months ago. But an agent is only as good as its feedback loop.

If you point an agent at your product API and ask it to add a review system, it might produce something that looks reasonable in isolation. And without knowing what clients actually use, it might happily reshape your types, move fields, and break consumers you had forgotten were out there.

GraphQL has a quiet advantage here: every client operation declares exactly which fields and types it needs. That gives you field-level usage data.

Give that information to a coding agent, and it is no longer guessing. It can understand what is actually used, make safer schema changes, and avoid breaking existing consumers.

That combination of GraphQL's visibility and capable coding agents creates a feedback loop we did not really have before. It means less time reviewing AI-generated code that (just) almost works, and more time working with changes that are much closer to correct the first time.

You can try out our prototyping skills with:

dnx skillz chillicream/agent-skills

The state of GraphQL federation

The community has spent a lot of time standardizing how distributed GraphQL systems should work, with GraphQL acting as the gateway. The result is the Composite Schema specification, now being developed under the GraphQL Foundation.

The important detail is where the spec stands today: it is still Stage 0, Preliminary. In other words, it is an active proposal, not a finished standard yet, and parts of it can still change before it reaches Draft.

Even so, this is already a big step. Instead of every vendor shipping its own version of federation, Composite Schema gives the ecosystem a shared, vendor-neutral direction for composition, validation, and distributed execution.

Fusion is our implementation of that direction, and it is already compatible with the Composite Schema spec as it evolves. If you want to try it today, start with the Fusion getting started guide.

A community shaping what comes next

GraphQL has always been a community-driven project, and the closing keynote was a good reminder of how much of the ecosystem exists because people kept showing up and doing the work.

The GraphQL GAP proposal is part of that next phase. It is meant to create new ways for people across the community to collaborate and contribute. Together with updates from the Working Groups, it made one thing very clear: GraphQL's next chapter will not be written by one company or one team.

Behind the scenes: Working Group Day at Meta

One of our highlights was the community day after the conference. This year, we spent a full day together on Meta's campus, split across different Working Group tracks.

A big part of the day focused on semantics, taking semantic introspection and turning it into concrete next steps. Salome spent the day working on the community side: shaping a new Community Hub to give the ecosystem a clearer home, and helping improve the Ambassador program to recognize and support the people bringing GraphQL into their companies, communities, and local meetups.

The best part of the day was the side discussions. A casual conversation turned into Jordan shipping a new Relay.js feature, and Benjie could move several Golden Path initiatives forward, because so many maintainers were in one room. Community Day also turned out to be one of the most productive GraphQL Working Group sessions we've had. It's amazing what happens when you lock the TSC in the same room: suddenly discussions start, opinions align, and quorum is reached!

When we were not talking GraphQL

Outside the conference schedule, we managed to see a bit of the Bay Area too. We hiked through Big Basin Redwoods State Park, saw the Mother of the Forest, and met a few banana slugs moving through the forest at their own pace.

We also drove across the Golden Gate Bridge, spent some time wandering through malls, and drank enough coffee to keep the whole trip moving. More than anything, it was a reminder that one of the best parts of any conference is getting to experience a new place with good people.

Wrap up

What stayed with us after GraphQLConf was not one single talk or announcement, but the feeling that GraphQL is entering a new phase.

Agents are starting to change how APIs are used and built. Federation now has a shared, vendor-neutral standard. And just as importantly, the community is putting real structure behind the work through Working Groups, GAP, the Community Hub, and the Ambassador program all pointing in the same direction.

That is what made the week feel so energizing. GraphQL does not feel like something being handed down by one company or one team. It feels like something a lot of people are building together.

If you want to follow along, watch for the GraphQLConf recordings, read our deep dive on Semantic Introspection and if you want to try GraphQL Federation yourself, give Fusion a go!

And if you want to talk GraphQL with people who think about it a little too much, our Slack is always open.

See you at the next one.

A few snapshots from the trip