Most launch announcements arrive after the fact, polished and certain. This is the opposite kind of post. Gravity is still pre-launch, on a waitlist, and this is a candid look at exactly where things stand: what is built, what is in progress, where reliability sits, and what has to be true before we open the platform to everyone. We would rather tell you the real state of the work than market a finished story we have not earned yet.

The short framing is simple. Gravity is an AI agent platform where you describe an outcome in plain words and an expert-built agent runs it and hands back a finished result in about 60 seconds, paid per use. The product we are building is not a clever demo; it is reliability. That single commitment shapes every line below, including the part where we explain why we have not announced a launch date and why that is a feature, not a delay.

Where Gravity is heading into launch

Gravity is an AI agent platform built by XAI Technologies in Bangalore. The premise is that running expert-built, tested agents should be as simple as asking for the outcome you want. You do not assemble a stack, write prompts for hours, or babysit a tool. You describe the job, the right agent handles it end to end, and you pay only when it runs. If you are new to the category, our explainer on what an AI agent is sets the baseline, and our buyer's framework for evaluating AI agent platforms covers the questions worth asking of any platform, including ours.

Heading into launch, the work splits into three layers: the run-and-results experience that users touch, the credits system that meters usage, and the catalog of agents that builders create and maintain for Gravity. Each layer is at a different stage of maturity, and being honest about that difference is the whole point of this update. A platform is only as ready as its weakest load-bearing piece, so we track each one separately rather than averaging them into a comforting single number.

What we mean by ready

Plenty of products launch when they look finished. We are using a stricter definition. For Gravity, ready means the core loop works end to end for real users, repeatably, under real load: you describe an outcome, the right agent runs it, and it returns a usable result in about 60 seconds, again and again, not just in a staged demo. Ready is measured in consistency, not in screenshots.

Reliability before features

The temptation in any pre-launch sprint is to add one more capability. We have inverted that. An agent that does three things dependably beats one that attempts ten and fails on the fourth, because a failed run on someone's real work costs them far more than a missing feature ever would. So the launch question for each agent is not "what else can it do" but "does it do its job every time." That is why we treat reliability testing as core engineering, not a final QA pass.

The catalog and pay-per-use credits

Ready also means the commercial mechanics work cleanly. Gravity is pay per use, metered in credits where one US dollar equals 1,000 credits, so you are charged when an agent runs rather than locked into a seat. For that to be launch ready the metering has to be accurate and transparent: a user should always be able to see what a run cost and why. We walk through the model in full in Gravity pricing explained, and getting it right is as much a part of readiness as the agents themselves.

Built versus in progress

Here is the honest split, kept qualitative on purpose. We would rather describe the state of the work accurately than attach precise numbers that would be stale by next week.

What is built

The core run-and-results experience exists and works: a user can describe an outcome, the right agent picks it up, and a finished result comes back. The credits system that meters pay-per-use runs is in place. The testing harness that every agent is graded against before it joins the catalog is built and in active use, which is the piece we are proudest of because it is what makes the reliability promise more than a slogan. A growing waitlist is queued and ready to be invited in stages.

What is in progress

The catalog is the live edge of the work. Dozens of agents are in testing at any given time, with builders creating and maintaining them for Gravity, and only the ones clearing the bar get listed. We are hardening the run experience under heavier concurrent load, tightening the failure messaging so that when an agent cannot complete a task the user gets a clear explanation rather than a dead end, and expanding the range of jobs the catalog covers without dropping the quality threshold. None of this is glamorous, and all of it is what separates a demo from a service people can depend on.

How we think about launch criteria

We do not have a launch date pinned to a calendar, and that is intentional. The criteria are about behavior under real conditions, not about a quarter. Concretely, we are watching three things before we open access wider.

Consistency under real use. An agent has to clear its quality bar not once but across the variety of inputs real users actually send, including the messy ones. A demo proves a happy path exists; launch readiness proves the agent holds up when the input is malformed, ambiguous, or unusual. That is the gap most agent products quietly ship with, and the one we are unwilling to.

Graceful failure. No agent succeeds on every conceivable task, so a launch-ready platform fails well. When an agent cannot complete a job, the user should get a clear, honest message and not be charged as if it had succeeded. Designing for the failure case is, in our view, a better signal of readiness than any success rate alone.

Coverage that grows without diluting quality. It is easy to expand a catalog by lowering the bar. We are doing the opposite: growing coverage only as fast as agents can clear the threshold. That means early users see a smaller catalog that they can trust, which expands over time. We wrote about how that engine actually runs in the content engine behind Gravity, and the same discipline applies to how the agent catalog grows.

The waitlist and what early users get

Access is rolling out in stages through the waitlist, not in a single big-bang launch. The reason is straightforward: reliability is easiest to protect when load grows in steps you can watch. If we opened to everyone at once and an agent started failing under unfamiliar volume, the people who trusted us first would pay the price. Staging access lets us catch that before it reaches scale.

So what does an early user actually get? A smaller, well-tested catalog first, with new agents added as they clear the bar. The full run-and-results experience: describe a job, get a finished result in about 60 seconds. Pay-per-use pricing from day one, so there is no subscription to commit to before you know the platform earns it. And a direct line into the roadmap, because early usage is exactly what tells us which agents are ready to open up to more people next. If you are weighing whether to wait for a platform like this or build the capability in-house, our piece on build versus buy an AI agent lays out the trade-offs.

Open questions, answered honestly

A status update that pretends there are no risks is not honest, so here are the open questions we are actively working, stated plainly.

Will reliability hold as the catalog grows? This is the central risk of the whole model. A bar is easy to hold over a handful of agents and harder over many. Our answer is to keep the testing harness as the non-negotiable gate and to grow coverage only as fast as that gate allows, even when it means a smaller catalog at launch. We would rather list fewer agents that work than more that sometimes do not.

Can the 60-second promise survive heavier load? Speed and reliability can pull against each other under concurrency. We are hardening the run experience specifically against that, and staged access exists in large part to test it before scale rather than after.

What happens when an agent simply cannot do a task? The honest answer is that some requests will fall outside what the current catalog covers. The right behavior is to say so clearly and not charge for a non-result, which is why graceful failure is one of our explicit launch criteria rather than an afterthought. For the wider picture of how we run month to month, our June 2026 monthly retro covers what is working and what is not in more detail.

The short version

Frequently asked questions

When does Gravity launch?

We have not committed to a public launch date, and that is deliberate. Gravity opens when the agents in the catalog clear our reliability bar consistently, not when a calendar quarter ends. We would rather move a date than ship an agent that fails on a real task. People on the waitlist get access first, in stages, so we can watch reliability under real load before we open the doors wider.

What does launch ready mean for Gravity?

Launch ready means the core loop works end to end for real users: you describe an outcome, the right expert-built agent runs it, and it hands back a usable result in about 60 seconds, repeatably. Concretely that is a stable run-and-results experience, pay-per-use credits that meter correctly, and a catalog of agents that each clear our internal quality bar before they are listed. Reliability is the gate, not feature count.

What is the 80-test quality bar?

Every agent built for Gravity is run against a structured battery of test cases that cover the normal path plus edge cases, malformed inputs, and known failure modes, and it has to clear a high pass rate before it is listed. The point is to catch the ways an agent breaks before a user does. An agent that passes a demo but fails one task in five is not good enough to carry someone's real work, so it stays out of the catalog until it is fixed.

Can I get early access to Gravity?

Yes. The waitlist is the way in. We are rolling out access in stages rather than all at once so we can keep reliability high while load grows, which means early users get a smaller, well-tested catalog first and see it expand over time. If you join the waitlist you will be among the first invited, and your real usage helps us decide which agents are ready to open up next.

How much will Gravity cost?

Gravity is pay per use. Pricing runs on credits, where one US dollar equals 1,000 credits, and you are charged when an agent runs rather than through a fixed monthly seat. There is no subscription to buy access to the catalog. You pay for the work you actually run, which keeps the cost tied to value delivered instead of to a license you may not fully use.

Why are you sharing pre-launch progress publicly?

Because the thing we are asking people to trust is reliability, and trust is built by showing your work, not by waiting for a polished launch event. Building in public keeps us honest about what is done versus in progress, it gives the waitlist a real view of where things stand, and it invites feedback while changes are still cheap to make. A status update that admits the open questions is more useful than a launch that hides them.