Two AI layers, at opposite ends of the stack
People say "the AI" as if there is one. There are two, they do different jobs for different people, and they have very different reach. Confusing them is the source of most worried questions about what an AI can get to.
| Build-time AI | Run-time AI | |
|---|---|---|
| Who talks to it | You, in the studio. | The people using your published app. |
| What it does | Writes and edits your interface; can create tables, fields and workflows. | Answers questions about live data, surfaces trends, runs actions you switched on. |
| What it acts as | You. It has your builder account’s reach. | The signed-in end user. Nothing more. |
| Where it runs | In the studio, while you build. | Inside the published app, at run time. |
| What it costs | Credits, as it works. | Credits, per question or action. |
The studio agent
This is the agent you chat with while building. It reads your app’s schema so it knows your real tables and fields, writes React and server code into your project, and can reach back into the backend to add a table or a workflow when the thing you asked for needs one.
Its reach is your reach. It is doing work you would otherwise do by hand in the builder, so it can see what your builder account can see — which is also why it can only touch apps you have access to.
The AI your users talk to
Ask, Analyze and Action Agents live inside the published app. They belong to your end users, and this is where the interesting design decision is: none of them has an API key of its own.
Every query one of them runs is made as the signed-in person, carrying that person’s token, evaluated against the same row-level security you already wrote. So an AI answer can never contain a record the person could not have opened by hand — not because the AI was told to be careful, but because the server never sent it the row.
Turning these on is per interface, which is the other reason interfaces are a useful seam: you can give staff an AI assistant on the internal console and leave the customer portal without one.
Permissions, approvals & auditHow approvals work for agents that write, and what gets logged.A third way in: AI tools outside Tadabase AI
You can also point an AI tool you already use — Claude, ChatGPT, Cursor, and others that speak MCP — straight at your Tadabase account. You paste one address, sign in to Tadabase AI in the browser, and from then on that tool can read your schema, query records, and build parts of your app from wherever you already work.
This one acts as you, not as an end user. It is a builder-side capability, not something your app’s users ever touch.
Connect an AI tool with MCPStep-by-step for Claude, ChatGPT, Claude Code, Cursor and VS Code, with screenshots.Why this shape matters
The usual worry about AI over business data is that it becomes a way around your access rules — a helpful assistant that cheerfully reads the whole table because nobody thought to stop it. That failure mode is only possible when the AI holds its own credentials.
Here it does not. Run-time AI is just another caller at the same door as your screens, holding the same token as the person who asked. The rules that protect a list page protect an AI answer, automatically, including in features you switch on months from now.
How everything connectsThe full stack this sits in, drawn out layer by layer.