I stopped building dashboards and started asking my database questions. SaaS is about to do the same.

TL;DR: I store every touch a player makes in the game. When something feels off, I don’t open a dashboard. I ask AI to investigate the raw data and tell me what looks wrong. Doing that for a few months has convinced me the “end of SaaS” talk is pointed at the wrong target. SaaS isn’t dying. The screen factory is. What replaces it is a layer that lets AI read your data freely and act on it safely, and right now that layer doesn’t really exist.

Dashboards can’t tell you when they’re wrong

I built an analytics area for the game. The usual cards. Active players, session length, sessions per day, time per day. For years I’ve built screens like this and checked them the way you check any dashboard. Glance, nod, move on. Not one of them ever told me when a number was wrong.

Take session length. I looked at it properly and the raw median came out at about 77 seconds. If I’d trusted that, I’d have decided people open the game, glance at it, and leave. That’s a grim number and it’s wrong. Most of those short sessions are a page load with nothing behind it. Once you only count sessions where the player actually did something, the typical sitting is around 23 minutes, and an active player spends about an hour a day in the game across three or four visits.

It’s the same data telling two opposite stories, and the dashboard only ever showed me one of them. A screen full of numbers has no idea whether it’s misleading you, and it can’t answer the obvious next question either. Why is it 77 seconds? It just sits there.

Now I just ask the database

Now when something feels off, I don’t go to the screen. I open the database and ask.

I store everything. When a player joins, every page they touch, every session, every action they take. So I can ask real questions in plain language and let the AI build the query. A few days ago I changed the sign up flow. Instead of a registration form, new players now drop straight into the game as a guest. About 80 people came in over a few days. Those changes are the dangerous ones. The headline number looks great and buries everything that actually matters.

Here’s roughly what I asked:

Recently we let players sign up as a guest, no registration needed. Over the last few days almost 80 people signed up.

How many signed up as a guest? How many came through normal registration? How many guests went on to register a real account? How many tried to register but something maybe broke? That last one worries me most.

How many guests kept playing as a guest and came back the next day? How many are still playing as a guest who should be converting before they lose their session?

Check /live, focused on world 5.

There’s no card for “guests who tried to register and hit an error I didn’t know about.” I’d have to build one. Instead I asked, the AI pulled it apart, and I went through it.

I don’t want it to just hand me counts. I want it to look at the counts and tell me when something doesn’t add up. And it does that on its own, before it even gets to an answer. If you watch it think, you’ll catch it stopping halfway through. “Actually, that looks wrong, let me check it from another angle.” It requeries, pulls the number a second way, and only then comes back. A dashboard would have shown me the wrong figure with a straight face.

When the answer’s worth keeping, I get it to build a screen

Some questions I only ask once. Some I’ll want again. When it’s the second kind, I tell the AI to build a screen for it.

That’s how the analytics area actually grew. None of it was designed up front. Each card started as an investigation that turned out to be worth keeping. And once a screen exists it earns its keep twice, because next time I can point the AI at it. “Look at the sessions screen” hands it the existing queries and the shape of the data, so the next question starts from working code instead of a blank prompt.

I always put too many stats on a screen at first. Years ago that was a real problem, because every one cost time to build and you were stuck with the clutter. Now it barely matters. After you’ve looked at a screen ten times you know which numbers are junk, which are tourist data, which are quietly misleading. So you tell the agent to drop them or change them and it’s done in a minute. No big deal.

And the screen still earns its place. I don’t always want to ask and wait for the AI to work the numbers out from scratch. Sometimes I just want to glance and move on. The screen is the fast path. The conversation is for when I need more than the number.

Remember the query, not the screen

I’m not building a big harness around any of this. No agent sitting on the database watching for changes and pinging me. That’s a lot of work to save me a question I can type in a sentence, and at my size it isn’t worth it.

The next step I want is smaller than that. When I land on a number after some back and forth, instead of asking for a new screen, I ask the AI to remember how I got it. That’s really just a markdown file. The query, the filters, the gotchas, the things we worked out together about what counts and what doesn’t.

Next time I ask for that number, it reads the recipe back from memory instead of working it out from nothing. Fewer tokens, faster answer. But the real win is that I’m still talking to it, not staring at a fixed card. So I can keep going. Cross-check it against something else. Add a filter, only the last 7 days, only players who used a certain mechanic a lot. A dashboard hands you the number and stops. A data engineer you can talk to hands you the number and then digs. The saved query is what lets the AI be the second one without starting over every time.

Where this runs into a wall

Here’s the wall, and it’s the whole reason I think something’s missing.

For reading, I want as much freedom as possible. For writing, I want as much safety as possible. Nothing I have gives me both, and most things give me neither.

Reading is the easy half. Raw SQL is the most flexible thing I’ve got. I can group, join, sub-select, ask for anything in the database. People are putting MCP servers in front of their data to give AI access, and that’s useful, but it’s a fixed menu. You get the queries the author thought to expose. Ask for something they didn’t, a slightly awkward grouped query with a sub-select in it, and you can’t have it. SQL is an open language. A tool list is a closed one. For digging around, open wins every time.

There’s a second problem with reading through an API or MCP. They paginate. You ask for data and it comes back a page at a time, a hundred rows, then the next hundred. For a human clicking through a table that’s fine. For an AI trying to reason over a whole dataset it’s death by a thousand calls, and it loses the thread between pages. With SQL it pulls everything it should be looking at in one query, holds it, and works from the full picture. If it needs to keep that data around it saves it somewhere before it does the next thing. You can’t reason about a number when you can only see a hundred rows of it at a time.

Writing is where it falls apart. Raw SQL is fine for reading and dangerous for writing. When I update a record through the game it doesn’t just change a row. It goes through a controller, a service, a repo. Along the way things fire. Write an activity log. Check whether other players should get a notification, and if so, call the email service. Recalculate something downstream. A direct SQL write skips all of it. The row changes and none of the rules run. For anything past read-only, giving AI raw database access walks straight around your auth, your validation, your side effects, all of it.

What’s missing is an agentic domain layer

So nothing I have does both jobs. Same thing as a table.

Approach	Read freedom	Safe writes	New question, no new code
REST API	Only the endpoints that exist	Yes, goes through your app	No
GraphQL	The shape you want, but only what the schema exposes	Yes, mutations go through your app	Only within the schema
MCP	Only the tools you exposed	Yes, if the tool wraps your service	No
Raw SQL	Anything in the database	No, walks around your rules	Yes
Agentic domain layer	Anything you can access	Yes, runs through your service path	Yes

REST, GraphQL and MCP are safe but rigid. They make the AI go through your application, so your rules hold, but the AI can only do what you already built. SQL is the opposite, full freedom and no guardrails. There’s no crossover. Today you pick flexibility or safety, not both.

The bottom row is the thing I keep wanting and don’t have. I’ve started calling it an agentic domain layer. It sits between the AI and your application. For reads it gives the AI full freedom. Ask anything, pull anything, as long as you have access to it. For writes it refuses to go around your business logic. The AI doesn’t say “set this player’s wood to 50000.” It says “grant this player the founder reward, here’s why,” and the layer runs that through the same path a human admin action would take, with the same checks and the same side effects.

What makes it work

A few things have to be true for that to hold up:

• It asks first. Before it does anything, the AI asks the system what it can do, and gets back a plain description of the entities, the fields and the actions it’s allowed to touch. No guessing.
• It speaks in commands, not SQL. The request is structured, so the layer can read it and check it before it runs.
• It doesn’t care where the data lives. Behind it sit adapters, one for the database, one for the existing REST API, one for an outside service like the payment provider or email. The AI asks the domain a question. The layer works out where to get the answer.

Free reads, governed writes

I kept calling what I wanted “unlimited,” and that’s where I confused myself. Unlimited is right for reads. You want the AI able to ask anything it has access to. It’s wrong for writes. A write that goes around your business rules is unsafe by definition, so the write side has to be bounded, and that isn’t a gap someone will close later. It’s the point. So it isn’t one layer doing one job. It’s two. Free on the way in, governed on the way out.

The other piece is preview. Before the AI changes anything, the layer should be able to tell me what will happen. This will change the player’s resources, write an activity log entry, send them a notification, schedule a follow-up. Then I approve it, or a policy does. You don’t get that from a row update, and you don’t get it from a tool call that just does the thing and tells you afterwards.

What it isn’t

If that sounds a bit like GraphQL, it isn’t, but I get why it rhymes. GraphQL lets you ask for the exact shape of data you want without a new endpoint for every question, which is the read half of the idea. But it’s still a schema someone defines up front, and it knows nothing about your write rules or the side effects sitting behind them. So it’s a cousin of this, not the thing itself.

It isn’t a new kind of database either. The database already does its job well. This is application logic, the stuff that knows a price change should notify someone and a message going out to a player shouldn’t leak something internal. That lives above the database, in the layer SaaS companies already build. They just build it as screens today.

And it doesn’t replace what you’ve already got. The frontend still calls the same REST API, the services still do the work. This sits beside them and goes through that same service layer, so the rules that protect a human action protect an AI one too. It’s something you add to an app that already exists, not a reason to rebuild one.

I’m sure people are already trying versions of this, under a few different names. The shape isn’t settled and neither is what you call it. But the gap is real, and I hit it every single time I go past reading.

The end of SaaS, or just the end of screens

This is why I think “the end of SaaS” is aimed at the wrong thing.

SaaS isn’t built on storing data. Anyone can store data. It’s built on the screens. The buttons, the tables, the filters, the forms, the dashboards. That’s where the money goes. Frontend, design, product, the lot. If the main way you use a tool becomes “the AI asks it for what you need and acts on it,” most of those screens stop earning their place.

The data doesn’t go anywhere. The business rules don’t go anywhere. If anything they matter more, because now an agent is leaning on them instead of a careful human clicking through a form. What shrinks is the screen layer on top. You still want some screens. For reviewing what the AI did, for approvals, for the odd edge case, for trust. Just not forty of them.

So I don’t think SaaS dies. I think it stops being a screen factory and becomes the thing underneath. The data, the rules, the permissions, the actions, exposed to AI in a way that’s actually safe. The company that wins that isn’t the one with the nicest interface. It’s the one that’s the safest place to let an agent read and act.

I only got here by poking at my own game’s database for a few months. But the wall I keep hitting in a small game is the same wall every SaaS product is about to walk into.