How Namuna was built

The question we started with

Can an agent answer revenue questions well enough that a founder acts on them?

Getting a number is easy. Trusting it is not. Multi-currency prices, coupons, trials and churn make even MRR easy to get wrong, and an AI answer reads the same whether it is right or not.

So every answer had to come with its code, and the agent had to be graded by something it can't fool: values recomputed from Stripe's own objects. When an answer leads to a price change, the same idea applies to the change itself: Stripe's billing engine, fast-forwarded with Test Clocks, is the judge.

What we built

A revenue analyst first, a market view of where price is losing customers, and a pricing rehearsal for when an answer becomes a decision.

Both write code, run it in an isolated sandbox, and are checked against Stripe.

How a run works

Write, run, compare, fix: until Stripe agrees or the agent stops and says why.

Guardrails

The agent can only touch what the rehearsal created.

• Isolated micro-VM per run

  Agent code runs in a CreateOS sandbox, never on our servers.

• Network allowlist

  Egress is limited to api.stripe.com.

• Scoped writes

  Rehearsals write only to subscriptions and schedules they created.

• Code screened first

  Generated analysis code is checked before it runs.

• Test mode only

  Live Stripe keys are refused.

• A human applies it

  Applying a migration to real customers requires approval.

How we know it works

We measure the agent against Stripe, not against itself.

The first benchmark run scored 3/5. The agent produced a confident, wrong MRR because multi-currency amounts live in a different field. Grading caught it; we fixed the agent's tools, not the test.

The rehearsal caught a real bug the same way. On the first attempt the migration dropped a 20% coupon after signup, and the diff showed 13 mismatches on that customer type. The fixed script produced none.

The data we test on

A realistic Stripe account, not a toy.

Relaywise is a synthetic SaaS business with 420 customers across 23 countries (top and emerging markets), 15 industries and 16 currencies. It has localized pricing, coupons, trials, churn reasons, failed payments and disputes. All data is synthetic and lives in a Stripe sandbox.

One assumption is built in, and we say so: churn and price complaints rise with price burden, what a customer pays relative to local purchasing power. That gives the market analysis a real signal to find. Pointed at a real account, the same code reads real cancellations. The analyst benchmark ran on the previous version of the data; its runs are published as they were.

The stack

Provisioned with Stripe Projects.

stripe projects add stripe/sandbox
stripe projects add createos/project
stripe projects add openrouter/api

TypeScript orchestration, Python executed in the sandbox, Next.js for this site.

Honest limits and what's next

What it doesn't do yet.