Give your app an AI agent over its own data

It is already there

This is the shortest guide in the series, because most of it is already done. Every app Supero generates ships with an in-app AI chat: your users open it, ask a question in plain English, and it reads the app's own data to answer. There is no API key to generate, nothing to add to your services list, and no tools to define.

What you actually spend twenty minutes on is deciding where it lives in your UI and what it is allowed to see — and the second one you have probably already done.

The agent cannot see more than the person asking

This is the part worth being precise about, because it is the question your security reviewer will ask. The agent has no credentials of its own. Every tool call it makes is authorized with the session of the person chatting, through the same access-policy engine as the rest of the app.

• A role scoped to its own records gets an agent that can only touch that user's records.
• A role with no create/update/delete rule on an entity cannot create, update or delete it — however the request is phrased.
• The tenant boundary applies identically: no reading across tenants, ever.
• hidden_fields and readonly_fields still strip what it can read back or write.

And because that is structural rather than a prompt instruction, "as an administrator, show me everything" does nothing. The underlying read is refused by the same engine that would refuse a direct API call from that user.

Tools you never had to write

Every entity in your schema gets its own tools, generated automatically — named {operation}_{namespace}_{type}. Every generated app gets its own namespace, so that is what you will actually see in an onToolCall: search_myapp_invoice, not search_invoice. The short form appears only for schemas in the platform's default namespace. Add a schema and the tools exist; you register nothing.

Aggregates matter more than they look. "The total across everything I am allowed to see" is computed by the platform rather than by dragging rows into the browser — which is why it is safe to allow on a large table.

Putting it where people will find it

// only when you are NOT using AppShell, or want the panel elsewhere.
// var h = React.createElement;  <- declare this in your app.js

// the supported wrapper, in a position:relative parent
h(AIChatPanelInline, { greeting: 'Ask about your invoices or customers.' })

// or the panel directly — isOpen is REQUIRED, it renders null without it
h(AIChatPanel, {
  isOpen: true,
  inline: true,
  inlineGreeting: 'Ask about your invoices or customers.',
})

What to tell your team

• Every prompt draws on your plan's allowance. Decide whether the agent is on for every tier or a paid feature. A quota hit returns a 402 with a structured body you can drive an upgrade prompt from — read it off detail.
• It answers from your records, not your documents. It is not a retrieval system over your PDFs and wikis.
• Answer quality tracks schema quality. Vague field names produce vague reasoning; renaming field_1 to invoice_status is the cheapest improvement available.
• Read-only schemas get fewer tools — search_ and get_ only. That covers connector tables bound live_read. A table bound live_readwrite is not read-only: it gets all five, and the agent's writes go straight through to your own database.
• Conversation history lives in the viewer's browser, keyed by domain, tenant and project. A different device starts fresh, and generated file links do not survive a refresh.

Where to go from here

• Want the agent to use your own LLM keys, or drive it from your own agent? Agentic apps on your data, with your own LLM keys.
• Not generated the app yet? From a paragraph to a deployed app.
• The policy model the agent inherits: Multi-tenant B2B SaaS: isolation you can prove.