Likeable
Sign inStart free

AI chat & agents

Put an AI assistant into any app you build. Add the ChatAi brick, point it at an AI provider you've connected, and your app has a chatbot. Attach a database and the assistant can answer from your data — it writes and runs read-only SQL for you (retrieval-augmented Q&A / text-to-SQL over the DuckDB data layer).

The fastest way: tell the builder "add an AI assistant" (or "add a chatbot that can answer questions about my orders table") and it wires the brick to your AI connection. This page is the reference.

Connect an AI provider

AI credentials live in the same encrypted vault as your databases. Open the Data panel → Add → AI, pick a provider, and paste your token:

  • OpenAI (or any OpenAI-compatible endpoint — Azure, OpenRouter, a local gateway via the optional Base URL)
  • Anthropic (Claude)
  • Google (Gemini)

Optionally set a default model (e.g. gpt-4.1-mini, claude-sonnet-4-6, gemini-2.5-flash); a chat can override it. Likeable stores the token encrypted at rest and shows only a credential-free summary afterwards.

The API token is a secret — enter it in the Data panel, never in chat. The built app calls the provider server-side; the token never reaches the browser, the chat transcript, or a brick's props. Rotate it with "Update token" on the connection.

Whose token — shared or per-viewer

Just like a database connection, an AI connection chooses whose credentials run its requests:

  • Shared (default) — one org-wide token; every viewer's chat runs on it (your key, your quota).
  • Per-viewer — each signed-in user brings their own token, stored encrypted per user, and their chats run on their key and quota. A user who hasn't connected a token is asked to before they can chat; there's no fallback to a shared token. Set yours from the Data panel ("🔑 connect your credentials" on the connection). Use this for multi-tenant apps where users bring their own AI.

Add the chat

Place a ChatAi brick and set:

  • connectionId — the AI provider connection (required).
  • system — a system prompt that steers the assistant's role, e.g. "You are Acme's support agent. Be concise and friendly."
  • greeting — an assistant message shown before the user types.
  • suggestions — starter prompts shown as clickable chips, e.g. ["Top 5 customers", "Revenue this month"].
  • model — override the connection's default model for this chat (optional).

Replies render as markdown (tables, lists, code). The conversation can be mirrored into a store key (messagesKey) so other bricks can bind to it.

Answer from your data (RAG / text-to-SQL)

Set the ChatAi brick's dataConnectionId to a database connection. The backend then gives the model a read-only SQL tool: it introspects your schema (information_schema) and runs SELECT queries to ground its answer in your actual data — before replying. This turns the chat into a "chat with your data" analytics copilot.

ChatAi
  connectionId      → your OpenAI/Anthropic/Google connection
  dataConnectionId  → your Postgres / MySQL / DuckDB connection
  system            → "You answer questions about our sales data. Show numbers as tables."

Ask "which region grew fastest last quarter?" and the assistant writes the SQL, runs it (read-only, with the same row cap and timeout as any query), and explains the result. Because the data layer is DuckDB, the assistant can query a single database or a federation across your Postgres + MySQL + Parquet/Iceberg in one place. The connection's access mode and credentials (shared or per-viewer) apply unchanged — a read-only connection stays read-only.

How the agent loop works

Each request is a small, bounded state machine: the model may call the SQL tool, read the rows, and call it again (e.g. list tables → inspect columns → run the real query) before answering. The loop is capped (a handful of steps) so it always terminates. The model only ever sees rows it queried through your read-only connection — never the connection string or token.

Combine with a dashboard

ChatAi pairs naturally with the dashboard bricks: put the assistant beside live charts and a table bound to the same database. The user can read the dashboard and ask the assistant to dig deeper — both backed by the same connection.

Deploying

The chat needs a backend that holds your token. In the builder (and any Node host serving the app's /api/ai) it works as soon as you set connectionId. To keep it working in a deployed export, the chat runs as a baked backend operation:

  • The builder bakes an AI operation from your chat (or the agent defines one with define_operation and sets the ChatAi brick's opName). On deploy it becomes a function at /api/op/<name>.
  • That function runs on your app's own backend and reads your token from its environment — LIKEABLE_CONN_<ID>_AI_KEY (and the data connection's …_DSN for the SQL tool). The generated .env.example lists exactly what to set. Secrets are never baked into the export — only the non-secret config (provider, model, system prompt) ships.
  • AI runs on Node deploy targets (Vercel, Netlify, Lambda, the persistent server). Cloudflare Workers can't run it (the provider + SQL tool need Node) — deploy AI apps to a Node target.

So the same chat you preview in the builder keeps working for your end-users once deployed, on your infrastructure and your key.

Next steps