#Why xQL

Shipping product features almost always means orchestrating APIs. Not calling one endpoint and returning its payload — combining data from several services, reshaping responses for the screen or agent that needs them, handling partial failures, and coordinating multi-step side effects safely.

When that orchestration logic lives in ad hoc BFF handlers, client glue, and one-off scripts, it becomes expensive to maintain and hard to reason about. The problem gets worse as the number of surfaces grows: web, mobile, internal tools, and now AI agents that are expected to take real actions on behalf of users.

#The pattern that worked

GraphQL addressed a large part of this problem. Instead of hand-writing orchestration code for every screen, clients describe the data they need and a runtime plans the execution — fanning out across services, enforcing policies, and stitching results together behind a typed contract. That model replaced brittle BFF code with something declarative, composable, and reviewable.

Federation extended the pattern to organizations: many teams contribute to a shared supergraph, and a router takes care of cross-service orchestration so individual services don't have to know about each other. For the teams that adopted it, this was a genuine step change.

#Where it hits limits

Federation was designed around a specific bet: that teams will converge on a single, coherent schema. That bet works when it works, but schema design often becomes a bottleneck. Teams need to move faster than coordinated design allows, and the cost of getting everyone to agree on one model up front is high enough that many organizations never finish the project — or never start.

At the same time, the landscape is shifting. AI agents are becoming first-class API clients, and they bring sharper constraints. Agents need to compose across services, reshape responses, and orchestrate multi-step workflows — reliably and efficiently, not through probabilistic trial and error. They're at least as sensitive to latency, overfetching, and inconsistency as mobile apps ever were, and they have far less context about why your APIs look the way they do.

That combination — the schema bottleneck on one side, and the growing demands of agents and modern clients on the other — is what xQL is designed to address.

#One graph doesn't have to mean one API

The key insight behind xQL is a reframe of what a supergraph is for.

Instead of thinking of the supergraph as a single schema that every team must contribute to and every client must query through, think of it as a catalog of data and services — something clients can query into, reshape, and build targeted APIs on top of.

That shift has practical consequences. Teams can bring services onto the graph without upfront schema unification. Clients get a richer language: one with expressions, data restructuring, and direct access to APIs regardless of the protocol they sit behind. The supergraph becomes a foundation to build on, not a bottleneck to push through.

#What xQL keeps and what it adds

xQL keeps what makes GraphQL powerful:

• Strong typing — every value, field, and operation has a known type.
• Composability — small pieces combine into larger plans.
• Field-level selection — output contracts are explicit and reviewable.

And extends it with the primitives that integration work actually demands:

• Expressions and data restructuring — reshape, combine, and transform values directly in the language instead of in glue code.
• Direct API access — call services regardless of protocol; the graph is a catalog, not a wall.
• Namespacing — teams own their slice of the graph and evolve independently.
• Declarative orchestration — multi-step workflows with explicit ordering, failure handling, and compensation.

The result is a single declarative language where shaping and orchestration compose into plans that tooling can validate, runtimes can optimize, and people can review.

#Design goals

The language looks the way it does because of a few concrete goals:

1. Keep output contracts explicit. Selection bodies are the core surface so shaping is reviewable and statically checked.

2. Make identity a first-class concept. Entities make join points explicit, which reduces brittle integration logic and enables cross-service connections without upfront schema unification.

3. Separate what from how. Plans describe intent and dependencies, not imperative scheduling. This lets tooling catch issues early and lets runtimes optimize safely.

4. Keep ownership local. Namespaces and extensions let teams add semantics without centralizing every decision.

5. Express workflows declaratively. op bodies, phase barriers, and compensation make multi-step behavior understandable by people and tooling alike — whether those plans are written by humans or generated by agents.

#One language across the stack

xQL uses one consistent shape language across a progression of capabilities:

• Shaping (->) — You already have data from an API response. Pick the fields you need, restructure them, combine values. No network calls, just reshaping what's present.

• Augmentation (query) — You need data that isn't in the current response. Mark a boundary where the runtime can fetch from external services to fill in missing fields. xQL keeps these boundaries explicit so teams can see exactly where external calls happen.

• Extensions (extension) — A team needs product-specific fields on a shared entity. Extensions let them add those fields locally, in their own namespace, without negotiating changes into a central schema.

• Orchestration (op) — A workflow spans multiple services and steps: hold a flight, hold a hotel, authorize payment, confirm both. op bodies make ordering, failure handling, and rollback explicit and analyzable.

Each level builds on the one before it. You can start with simple shaping and only reach for augmentation, extensions, or orchestration when they pay off.