We gave our database a chat box. I haven't asked a developer for a report since.

The most expensive part of product analytics was never the tooling. It was interrupting a developer every time I needed a number.

On a Tuesday in August I typed a question into a new chat box in our internal admin dashboard: how many users who tried studio mode ended up saving an item? The agent worked out what to query, checked how our data is shaped, and ran its read-only queries. Twenty seconds later I had the answer as a chart, plus a few suggested follow-ups. No developer was interrupted in the making of that report.

What changed in our daily workflow

I'm a product manager at LI Solutions. We run Shop Minis, four AI shopping apps inside Shopify's Shop app, and that chat box gave us a data analyst on call around the clock.

Before we built it, every number meant asking a developer: about twenty minutes of context switching on his side, an hour to a day of waiting on mine. That friction trained me to stop asking small questions. I only asked for data when I had a big proposal to defend.

Now I ask maybe ten times more questions than I did in spring. Some go nowhere and are forgotten by lunch. A few became real roadmap items I would never have found in a quarterly report. The monthly model bill for all of it is lunch money.

Safety was the first concern when we connected an agent to a production database. The agent physically cannot change anything: its access is read-only and every query is checked before it runs. The worst a bad query can do is return a wrong answer or a slow one. A wrong answer I can catch. A dropped table I can't.

Giving the agent our business rules

Generic text-to-SQL tools advertise 85%+ accuracy on benchmarks and drop to 10-20% on real company data. They fail because they lack business context: they don't know what matters in your product or how you define success.

We handed our agent that context. It knows the full data model, the event funnel in canonical order, and the business rules. A save to favorites is the real conversion, and save rates matter more than raw counts. That knowledge lives with the code, so when developers change what the apps record, the agent's picture of reality updates with it, quirks and edge cases included.

The ML layer runs on the same rails today. A trained model scores every generation for how likely it is to end in a save and shows which factors push that probability up or down. Projections run next to it: estimated daily usage and AI spend per app, weeks ahead, so capacity and budget planning starts from a forecast curve instead of a guess.

The predictions land in the same chat conversation. I ask which mode drives more saves according to the model, and the answer comes backed by its numbers instead of a hunch. And the ML side stays strictly additive. If it ever goes down, the apps our users touch don't notice.

Running the models on our own hardware

The most important part of this architecture is where it lives. The ML models can run entirely on your own hardware, and local LLMs are now capable enough for analytics work. So the whole analyst, agent and models both, can sit inside your own infrastructure, and sensitive rows never leave it.

For us this is practice, not theory. We build healthcare products under strict NDAs where sending usage patterns to an external API is simply not an option. Running the models locally is how those projects get analytics at all. The same logic covers fintech and any product under serious data rules.

Local models have less dramatic benefits too. You know what your hardware costs each month, so a vendor's price change can't blow up the analytics budget. An external outage can't take your dashboard offline. And when a better open model ships, you upgrade on your own schedule. The analytics infrastructure belongs to you.

Having a private analyst changed how I treat my own curiosity. I no longer check how busy the engineering team looks before asking a question. I explore a hunch immediately and drop it if the data says no.

If you have a product database and an internal dashboard, this is a one-to-two-week feature. Give the agent read-only access. Write your tribal knowledge down where it can see it, and keep it beside the code. Someone does have to spend a few days translating your business rules into words. In our case that was me.