Working with data

Beyond text and pages, a workspace can hold structured data in SQLite files and
build interactive apps on top of them.

SQLite files

Any .sqlite file in the workspace opens in a read-only table viewer. You can
page through tables, see columns and row counts, and read the data without
writing a single query. Open sample-data.sqlite from the sidebar to try it: it
has a few small tables (customers, products, orders).

This is the quickest way to make a dataset legible. The agent drops a database
in, and it is immediately browsable.

Apps: data plus an interface

Sometimes a table viewer is not enough. You want filters, charts, totals, a real
interface. That is what an app is.

An app is a folder with three things:

• index.html: the frontend, with its own design and JavaScript.
• manifest.json: a list of named operations.
• a .sqlite database it reads from.

The important part is the manifest. Instead of letting the browser send raw SQL,
the agent declares each query once, gives it a name, and the browser calls it by
name:

POST ./api/categoryBreakdown   { "month": "2026-05" }

The server looks up the named operation, binds the parameters, runs the canned
SQL, and returns rows as JSON. The browser never sends SQL, so a public app
cannot be turned into a way to run arbitrary queries against the data.

Operations can take parameters (like the month above), which is how the
expenses app powers its month picker and its searchable table from a handful of
declared queries.

See it in action

Open the expenses app in the sidebar. Every tile, chart, and table on it is
a named operation defined in that app's manifest.json, reading from
expenses.sqlite.