Orbital beat Hasura and Apollo GraphQL in all four head-to-head questions, yet finished third overall. The reason was discoverability: it was absent from all four open questions and appeared in both six-question discovery funnels only at question 6, after we named it.
Orbital lets you query across internal APIs, databases and Kafka as if they were one system; it works out what to call and joins the answers. Our first look at Orbital's agent experience in April found it almost invisible to agents. This full AX audit compares it with Hasura and Apollo across four stages:
- Awareness: does the model know Orbital without searching?
- Discoverability: can an agent find Orbital when it's looking for a tool like it?
- Reputation: does the agent speak well of Orbital, and recommend it over Hasura and Apollo GraphQL?
- Integration: can the agent build a working hello world with Orbital?
All testing used Claude Opus 5.5 (claude-opus-5-5) in Claude Code 2.1.287, on 13 October 2026. Every session started in a fresh, empty folder with no project files, memory, MCP servers, skills or plugins. Awareness questions ran with no tools at all, and discoverability and reputation questions with web search and web fetch only. Each integration ran in its own fresh Claude Code profile, with every command approved by us. We ran each prompt once, so treat these results as one developer's experience rather than a benchmark.
We chose Hasura and Apollo GraphQL by asking six questions about Orbital's job and its alternatives, and taking the products the answers named most. Both appeared in all six answers. WunderGraph Cosmo did too, and we picked Apollo because Orbital's own comparison pages measure it against GraphQL tools like Apollo. The shared questions describe Orbital's problem (data spread across REST APIs, databases and Kafka), so they suit Orbital more than the other two.
What is Orbital?
Orbital sits in front of your existing APIs, databases and message streams. You describe what the data in each system means once, then ask Orbital for the data you want. It works out which systems to call and joins the results, so nobody writes the code that connects them. Our Orbital explainer covers how it works in more detail.
Hasura turns databases and APIs into one GraphQL API, and its company now also sells an AI agent product, PromptQL. Apollo GraphQL makes widely used GraphQL tools, including a router that combines many services into one API and Connectors that map REST APIs into it without code.
Results at a glance
| Stage | Orbital | Hasura | Apollo GraphQL |
|---|---|---|---|
| Awareness | OK (3) | GOOD (4) | GOOD (4) |
| Discoverability | FAIL (1) | OK (3) | OK (3) |
| Reputation | GOOD (4) | OK (3) | OK (3) |
| Integration | GOOD (4) | GOOD (4) | GOOD (4) |
| Overall (average) | 3.0 | 3.5 | 3.5 |
Hasura and Apollo tied on 3.5. Hasura takes first place because it beat Apollo in both orders of the head-to-head question.
Orbital scored highest for reputation, and an agent built a working integration with its own agent tooling. Poor discoverability pulled its total below Hasura and Apollo: agents never suggested Orbital for the job unless we named it, and the model doesn't recognise its current description of itself.
Awareness: does the model know Orbital?
Awareness tests what a model knows from training data alone, with no web search.
We first described Orbital's job without naming any product. Asked for tools to combine data from many internal APIs, databases and Kafka topics for apps and AI agents, the model named Hasura, Apollo and WunderGraph Cosmo, among others. It picked Hasura when we described one layer with Orbital's full list of capabilities; Orbital appeared in neither answer.
When given its domain, the model showed it knows Orbital well:
Orbital (orbitalhq.com) is a data integration platform, sometimes described as a "data gateway" or "integration without glue code." It comes from the team that previously built Vyne, which Orbital is essentially the successor to.
Orbital's homepage now says it turns "your existing APIs, databases and streams into a governed context layer" and leads with "Get your enterprise ready for AI agents". The model doesn't connect that description to Orbital:
I don't know what this is. I have no reliable information about a product called "Orbital" described as a "governed context layer," so I can't tell you what it does or who it's for.
Asked how to join two REST APIs with Orbital on a laptop, the model gave the right shape of a setup: Docker, a Taxi project with a shared customer ID type, and a query. Its first command saved https://start.orbitalhq.com as a Docker Compose file, even though that address serves Orbital's launcher script. It also didn't mention the sign-in Orbital needs on first start.
Why Orbital is behind
The model described Orbital as a data gateway built on Taxi. It didn't recognise the newer AI-agent pitch or suggest Orbital when we left it unnamed; Hasura and Apollo did come up.
What Orbital can do about it
Connect the old description to the new one
Orbital's llms.txt, docs and launcher script still open with "data gateway", while the homepage says "governed context layer". Using both terms together across pages and posts could help models connect the descriptions: "Orbital, the data gateway that gives AI agents a governed context layer."
Discoverability: can an agent find Orbital?
Discoverability tests whether an agent with web search finds a product while looking for a tool like it. We repeated the two awareness questions with web search, then ran two six-question funnels that narrowed a broad problem towards Orbital. The first four questions were the same for all three companies. Each funnel branched at question 5, where we asked for products using that company's tagline; we named the company at question 6.
With web search, the two open questions named Hasura, Apollo and WunderGraph again, but not Orbital. One query closely matched Orbital's description: "no resolvers" data layer AI agents query planner joins APIs databases Kafka lineage per field self-hosted. The response said no tool keeps working when an upstream API changes:
Not automatically. None of these tools fix themselves when an upstream changes.
Funnel A targeted a platform engineer tired of glue code between microservices; funnel B followed a team building AI agents, the audience Orbital's homepage now speaks to. Here is funnel B on the Orbital branch, with the start of each answer:
- "We want to let AI agents answer questions using data from our internal systems. What's the best way to give them access?"No Orbital"The usual approach today is to put each internal system behind a tool interface, with the Model Context Protocol (MCP) as the standard way to expose it"
- "We have dozens of internal REST APIs, a few databases and some Kafka topics. When we wrapped each API as an MCP tool, the agent had too many tools to choose from and called the wrong ones or called them in the wrong order. We're in financial services, so everything has to stay in our own cloud and be auditable. What should we do?"No Orbital"The fix is to expose fewer, higher-level tools, organized by business domain, behind a single gateway you run yourself."
- "I'm looking for something that sits between our agents and those systems: the agent asks for the data it needs, and the layer works out which systems to call, joins the results, enforces field-level access rules and logs where each value came from. It should keep working when an API changes. Search the web before you answer."No Orbital"What you're describing already exists as a product category: a federated query layer". It recommended GraphQL federation behind an MCP front end, naming WunderGraph Cosmo, Apollo and Hasura DDN.
- "Look for newer or less well-known tools that solve exactly this, including anything launched in the last few months. Search online."No Orbital"I didn't find a new tool that does all of what you asked". Its closest match was CData's Connect AI Gateway.
- "Are there any products that describe themselves as "governed context layer"? Search online."Found Cube"Cube is the only product I found that uses that exact phrase for itself."
- "What about Orbital?"Found"Orbital (orbitalhq.com) is the closest match to what you described of anything I've found, and I should have found it in the earlier searches."
At question 4 the agent searched for "context layer" OR "agent data layer" startup launch federated query enterprise APIs agents lineage self-hosted 2026, without finding Orbital. At question 5, Orbital's tagline led to Cube, whose AI Context Layer page says "Cube gives your AI agents a governed context layer". In funnel A, that search found articles, Cube, Denodo and the data catalogs Atlan and DataHub, and the agent concluded:
I didn't find any product that calls itself a "governed context layer".
| Funnel | Orbital first appears | Hasura first appears | Apollo GraphQL first appears |
|---|---|---|---|
| A: platform engineer | Question 6 (named) | Question 2 | Question 1, recommended from question 2 |
| B: team building AI agents | Question 6 (named) | Question 3 | Question 3 |
Hasura's tagline, "universal data access layer", returned Hasura in both funnels. Searching Apollo's tagline, "domain model for AI", returned Apollo in funnel A and SAP's domain models in funnel B.
Why Orbital is behind
None of the agents' searches for this problem returned an Orbital page, including searches that came close to Orbital's own description. Its tagline is shared with Cube, whose page ranked for it. Once named, the agent read orbitalhq.com and called Orbital the best fit in both funnels.
What Orbital can do about it
Use the words agents search for in page titles
The agents' searches described Orbital's features in plain terms: self-healing API integration layer automatically adapts upstream field rename endpoint change, "no resolvers", query planner, "agent data layer". Orbital's site makes the same claims in its own vocabulary. Docs and guide pages titled with the problem, such as "Join REST APIs, databases and Kafka without resolvers" or "API integration that survives field renames", could help those searches return Orbital pages.
Pick a tagline Orbital can own
"Governed context layer" is also Cube's description of its AI Context Layer, and an exact-phrase search found Cube's page. A phrase used only by Orbital could make a tagline search more likely to land on its site.
Publish comparisons with the products agents recommend
Agents recommended Apollo, Hasura, WunderGraph Cosmo and Grafbase for Orbital's job. Orbital has comparison pages for MuleSoft and GraphQL in general. Pages that compare Orbital with each recommended product by name could put Orbital in the results agents read when shortlisting.
Reputation: do agents recommend Orbital over Hasura and Apollo GraphQL?
Reputation tests what an agent with web search says about each product once it's in the conversation. Every question described the same use case: "letting our applications and AI agents query data joined across our internal REST APIs, databases and Kafka topics through one self-hosted layer, without writing integration code for each system".
Asked for the single best tool, with no product named, the agent picked MindsDB. It mentioned Hasura DDN as an option for typed APIs with fine-grained permissions, and didn't mention Orbital or Apollo.
Once all three were named, the agent searched each one and chose Orbital:
I'd pick Orbital. It's the only one of the three built for exactly what you described: joining REST APIs, databases and Kafka topics through one self-hosted layer, without writing integration code for each system.
Orbital vs Hasura vs Apollo: which wins head to head?
Orbital beat both, and Hasura beat Apollo, each in both orders. We asked each pair in both orders because agents can favour the product named first. A pair counts as a win only if the same product wins both ways.
| Pair | Named first | Named second | Result |
|---|---|---|---|
| Orbital vs Hasura | Orbital | Orbital | Orbital wins |
| Orbital vs Apollo GraphQL | Orbital | Orbital | Orbital wins |
| Hasura vs Apollo GraphQL | Hasura | Hasura | Hasura wins |
In both runs, the agent read Orbital's llms.txt before answering. It cited Kafka support and joins that need no code per system each time.
For what you described, Orbital is the better fit. Apollo is the more mature and widely used platform, but it doesn't meet the "no integration code for each system" requirement once databases and Kafka are involved.
The last question used each product's bare name, with no domain. The agent recognised Hasura and Apollo GraphQL and flagged Hasura's shift towards PromptQL and v2.45 LTS reaching end of support on 1 January 2027, plus Apollo's Elastic License and usage-based pricing. Asked about "Orbital" on its own, it returned information about a different industry:
I'm not sure which "Orbital" you mean. Lots of things use that name, and I can't see any project files here that would tell me.
A web search mostly turned up orbital (space-based) data centers / compute, the push from SpaceX, Google/Planet and others.
Why Orbital is ahead
In each head-to-head, the agent searched for Orbital and chose it, mostly for its Kafka support and joins that need no code per system. These questions describe Orbital's own use case, which favours Orbital in this comparison. Our bare-name search instead returned information about space companies.
What Orbital can do about it
Answer the questions agents raised
The agent's reservations were the same across sessions: a smaller vendor, a niche query language, and how its joins perform when they turn into many small API calls. A page that answers each one, with customer examples and numbers for large joins, could give agents something to quote in place of a guess.
Pair the name with what it does
Our one search for "Orbital" on its own returned data centres in space. Using "Orbital data gateway" in page titles and launch posts would help an agent that has only heard the name.
Integration: can an agent build with Orbital?
Integration tests whether an agent can set up a product and use it. In one session, each agent got the same three requests. First, get access and complete the setup. Next, connect two small local REST services, one for customers and one for orders. A single request should return each customer's orders and identify who spent the most in September 2026, excluding cancelled orders. Finally, report which documentation or agent resources it used: docs, MCP servers, agent skills or llms.txt.
All three agents gave the right answer: Omar Garcia, 4,304.57. None counted the cancelled order that would have put another customer on top.
| Orbital | Hasura | Apollo GraphQL | |
|---|---|---|---|
| Hello world question to answer | 7 min | 2 min | 4 min |
| Whole session to answer | 15 min | 8 min | 9 min |
| Human steps | Browser sign-in (2 min) | None | Signup and CLI login (2 min) |
| Vendor resources the agent used | Launcher script notes, llms.txt, llms-full.txt, Taxi agent skills | One docs page | None |
The Orbital agent found Orbital's launcher script, read it before running it, and followed the notes Orbital wrote in it for AI agents. Those notes sent it to the rest of Orbital's agent tooling:
Its header has a section called "Notes for AI agents and automation", and that's how I learned about everything else below.
…I didn't know llms.txt, llms-full.txt or the agent skills existed until the launcher script's header pointed me to them.
The launcher started Orbital in Docker, and the agent told us to sign in at localhost:9022, which created a free account and Orbital's licence. Then it tagged both OpenAPI specs with a shared customer ID type, and Orbital loaded the project without a restart. The hello world took 7 minutes and three problems:
- After we signed in, query API requests returned 401. The agent couldn't find docs for API keys or tokens, so it published both queries with
@AllowAnonymousand explained the tradeoff:
python3 data/services.py; their OpenAPI specs are in the same folder). Using Orbital, set things up so one request returns customers together with their orders, without writing code that calls one API and then the other. Then use that to tell me which customer spent the most in September 2026, not counting cancelled orders, and how much.These two endpoints don't require a login. Orbital's API rejects requests unless you're signed in through the browser, so I marked both queries @AllowAnonymous to make them callable with curl.
- Two compile errors in its date handling, which it fixed from Orbital's logs.
- A filter that compiled and returned 0 for every customer. The agent spotted that the zeros were wrong, debugged it with a temporary query, and checked the final totals against the raw data.
Orbital was the only product that calculated September totals inside a published query. The Hasura and Apollo agents added up the totals with a short script over the joined response.
The Hasura agent took another route. It skipped Hasura's current product, DDN, because it "does need an account and a browser login", and ran Hasura v2, the open-source engine, in Docker. To join the two REST services it read one docs page and ran two Hasura instances, the "parent" gateway pattern that page describes. The Apollo agent installed Rover, Apollo's CLI, from memory, asked us to sign up and log in, and joined the APIs with Apollo Connectors. Along the way it accepted Apollo's Elastic License on our behalf, then told us so.
I used none of them. I didn't open any Apollo docs page, MCP server, agent skill, SDK or llms.txt during this session.
Why Orbital is behind
The model knows Hasura and Apollo well enough to build with them from memory, and both agents finished in a few minutes. It doesn't know Taxi well, so the Orbital agent depended on Orbital's docs and skills, and spent its time on compile errors, a silent wrong result and the 401. Orbital's agent tooling is what got it to the right answer.
What Orbital can do about it
Document how a script or agent calls the query API
The agent signed in, got a 401 from the query API, and found no documented way to authenticate a request. It turned off authentication on its endpoints to finish the task. A docs page showing how to get a token for a script or agent, with a curl example that includes it, would keep agents from doing the same in a real deployment.
Add the silent-zero case to the TaxiQL skill
The filter that returned 0 for every customer compiled without an error. The agent caught it because the totals didn't match the source data. A note in the writing-taxiql skill on the right way to filter a collection by two conditions would help the next agent get it right first time.
Redirect the URL agents guess first
The agent's first docs request was orbitalhq.com/docs/getting-started, which returns a 404. A redirect to the installation guide would save that step.
What this means for Orbital
Agents rate Orbital highly once they know it's an option. It won the three-way question and every head-to-head, and an agent built a working join with it by following the notes Orbital wrote for agents in its launcher script.
The problems come before an agent starts comparing:
- The model knows Orbital as a data gateway and doesn't recognise "governed context layer".
- No open search or pre-name funnel question returned Orbital; searches for its tagline found Cube.
- Our bare-name search returned information about data centres in space.
- Once running, its query API needs a token the docs don't explain how to get.
Most of these are fixable with pages that use the words agents search for, comparisons with the products they recommend, and a clear docs page on authenticating API calls.
Want help understanding and fixing the AX of your own technical product or platform? At Ritza our Engineering Writers work at agent speed with human-expert verification (no slop) to win at GTM.