Your agent is a customer now.

A solo dev can stand up a subscription app in an afternoon now. React Native via an agent, backend via an agent, paywall copy via an agent, app store screenshots via an agent. The unit economics of shipping have collapsed. What has not collapsed is the unit economics of running the thing once it is live.

The agent that shipped your app cannot tell you whether it is profitable. It does not know what your MRR did last Tuesday, whether churn is trending up on Android, whether your trial conversion rate on the new paywall is better or worse than the old one. It does not know because it has no eyes on the numbers. It is flying your business blind the same day it launched it.

The Charts API is the eyes

RevenueCat publishes a v2 REST API called Charts. It exposes the same 21 metrics the RevenueCat dashboard shows you: MRR, ARR, active subscriptions, trial conversion, customer counts, churn, refunds, LTV per customer, and a dozen more. Every metric is queryable at day, week, or month resolution, segmentable by store, country, platform, product, and a long list of other axes. Rate limits are 15 requests per minute on chart endpoints and 5 per minute on the overview endpoint.

The API is the thing an agent needs to see its own business. It is also the thing RevenueCat has already wrapped in a first party Model Context Protocol server, launched in July 2025, that exposes all 21 metrics as MCP tools. So the plumbing is done. Any Claude Desktop user can install it with one command and start asking questions.

The thing the official tool does not solve

Installing an MCP server is a step. It is a small step. It is still a step. For a reviewer, a growth blogger, a recruiter, a prospective customer who wants to see what the API feels like, it is one step too many. You want to click a URL and see an agent thinking against real data in under five seconds. Not read install instructions, not edit a config file, not restart your desktop client.

That gap is what Kaizen closes. Kaizen is a web app, not an MCP server. You open the URL, it is already connected to a real indie app’s RevenueCat project (Dark Noise, a weather app on iOS), the agent is pre warmed with the current overview, and the first question you type is already running inside the chat pane. Zero install, zero auth, zero friction.

What Kaizen actually is, in 90 seconds

Kaizen is an AI analyst that speaks the RevenueCat Charts API. Under the hood there are four primitive tools: list_charts, get_overview, describe_chart, and get_chart. No composite narrative tools, no LLM reasoning baked into the tool layer. Primitive calls, model composition on top. That layering is load bearing and I will come back to it.

The model is Gemini 2.5 Flash, chosen for tool latency and cost. It sees the system prompt, the 21 legal chart names, and the four tools. It decides when to call what. The route is a Next.js App Router handler using the AI SDK v4 streamText helper with maxSteps: 8, so the model can loop if it needs to first call describe_chart before calling get_chart with a segment.

The UI is one page. One chat panel, one input, one footer. No sidebar, no dashboard, no settings. The only chrome is a tiny cache age indicator in the header, because the second and third and fourth questions you ask should not cost a round trip.

Here is the whole shape on one page.

The four primitive tools live in lib/kaizen/tools.ts. The web chat imports them through the AI SDK. The MCP adapter at bin/mcp.ts rewraps the same four functions over stdio. Same engine, two surfaces: a URL for humans, a CLI for agents. Neither path duplicates the official MCP server, because both sit on top of the four primitives and let the model compose.

A real answer from a real app

I asked Kaizen: what is the trial conversion rate? Here is what it returned, verbatim, to a reviewer sitting at localhost:3000 on 2026-04-22 UTC:

The average trial conversion rate over the last 30 days (March 23, 2026 to April 22, 2026) was 26.51%. Data for the period of April 14, 2026 to April 22, 2026 is still settling.

Two things are happening in that answer that matter. The first is the number. 26.51% is a real number. It comes from a real Charts API call with a real ISO date range. The agent did not hallucinate a range, it computed 30 days back from today.

The second is the caveat. The Charts API returns a boolean incomplete flag on every data point. Periods that are still settling, usually the most recent bucket, have it set to true. The official dashboard surfaces it as a visual state. A naive API consumer drops the flag on the floor and reports the raw number. Kaizen does not. It filters incomplete rows out of summary statistics and echoes them back as dataQuality.incompletePeriods so the model can caveat in the prose.

That second sentence in the answer is the entire product. An agent that looks at your business is only useful if it knows which numbers are real and which ones will move before lunch.

The engineering that makes it cheap to use

The Charts API has a 15 per minute rate limit on chart endpoints and a 5 per minute rate limit on the overview endpoint. Those limits are fine for a single reviewer with a single tab open, but a playground served to strangers on the internet hits them immediately unless you cache.

Kaizen runs an in memory TTL cache keyed by (projectId, chartName, paramsHash). TTL is 60 seconds. The first person who asks about MRR for the last 30 days pays the 400 millisecond round trip. The next dozen people get the answer back in under 5 milliseconds. When the cache is hot the tool chip in the UI shows cached next to the timing so a reviewer sees why the second question returned instantly.

The retry layer is exponential backoff with jitter, capped at three attempts, with Retry-After respected when the API actually gives us one on a 429. The rate limit headers the API returns are called revenuecat-rate-limit-current-limit and revenuecat-rate-limit-current-usage, which I mention only because the AI SDK and common HTTP clients expect x-ratelimit-* and the RevenueCat naming is not that. If you are building against this API the first thing you will do wrong is read the wrong header.

Why four tools and not one

A common shape for agent tools is the composite narrative tool. You write one big tool called summarize_business that does three Charts API calls and reasons about the result, and you call it from the model. That layering feels clever until the model asks a question that does not fit the summary you hardcoded.

Kaizen exposes the four primitives separately. The model composes. If it wants MRR broken down by store for the last 90 days, it calls describe_chart to learn that store is a valid segment for MRR, then it calls get_chart with the right args. That two step dance is exactly the behavior I wanted from the tool interface. Every chart has a different set of valid segments. Hardcoding the enum is brittle. Letting the model discover it at call time is robust.

What this does not try to do

Kaizen does not try to be the RevenueCat dashboard. It does not draw charts. It does not render tables. It does not offer export. If you want visuals, open the dashboard. Kaizen is a chat that does analysis, and the output is prose with numbers in it. That is a deliberate scope cut.

It also does not try to replace the first party MCP server. The MCP server is the agent dev tool. Kaizen is the zero install web playground. They are complementary. The blog, the video, the growth strategy around Kaizen all point an audience at the Charts API. The MCP server is where that audience lands if they want to wire an agent of their own into their real project.

What agents actually need from data APIs

Three things, ordered by how often API designers forget them.

Introspection. The agent needs a way to ask the API what it can answer before it asks a specific question. Charts gets this right with /options. Most REST APIs do not.

Data quality surfaced at the row level. Incomplete, missing, stale, estimated: the agent needs a per row boolean so it can caveat without asking you. Charts gets this right with incomplete.

Consistent time. ISO dates in, Unix seconds out, same envelope for every endpoint. Charts is consistent here too. A small thing, but the agent never has to translate.

The receipts

The repo has a committed eval harness with 30 queries across routing, schema discovery, and interpretation tiers. Current scorecard is published in SCORECARD.md. Cold install to first answer is under sixty seconds. No 429s in a thousand query stress run. The process log has token counts, Claude spend, and timestamps for every decision.

Try it

The deployed URL is linked from the README. Type a question, watch the tool chip trace pop open, read the caveat about incomplete periods. If it surprises you, good. If it misses something, the eval harness is open source and the queries file is a jsonl. Send a PR.

One last thing

The title of this post is the thesis. Your agent is a customer now. Not your employee, not your tool. Your customer. It needs dashboards, it needs unit economics, it needs to know which periods are still settling. The companies that hand their APIs to agents the same way they hand them to humans, with introspection and data quality flags and consistent envelopes, are the ones agents will keep recommending a year from now.

RevenueCat did that. This post is the nudge.