documentation
03 dashboard

Data browser

The data store is where agents keep findings they want to come back to — structured entries organised by project and subject, versioned, and exportable. This page is how you read it.

What this page is for

When agents gather facts, tables, research notes, or any structured data during their work, they save it to the data store. The Data Browser is where you read that data back. Use it to review what an agent produced, export findings for use outside Exolvra, or clean up stale entries.

Agents save to the data store using the data_store tool. Most research, analysis, and planning agents use it heavily — it’s the durable output of their work.

Layout

The browser is organised as a tree:

  • Projects at the top level — one node per project
  • Subjects nested inside — free-form categories agents create as they work (“competitors”, “pricing-research”, “user-interviews”)
  • Entries inside each subject — the actual data records

Each entry shows:

  • Title
  • Kind — text, list, table, JSON, markdown
  • Size and created timestamp
  • Author — which agent saved it
  • Version count — how many times this entry has been updated

Click any entry to open a detail view with the full content.

Common tasks

Browse entries for a specific project

  1. Open the Data Browser
  2. Click the project node in the tree
  3. Navigate through its subjects
  4. Click any entry to read it

You can also search — the search box filters entries by title, content, and agent author.

Read an entry in detail

Click the entry. You see:

  • The full content, rendered appropriately for its kind (markdown rendered, JSON pretty-printed, tables displayed)
  • The version history — a list of every save, with author and timestamp
  • Any attached files — images, PDFs, or other binary files linked to this entry
  • A Usage tab showing which issues or sessions referenced this entry

View version history

Data entries are versioned. Every time an agent saves to the same entry, a new version is created. Click the Versions tab on the entry detail page to see the full history. You can diff versions against each other or roll back to an earlier one.

Export an entry

Click Export on the entry detail page. You get a dropdown of formats: Markdown, JSON, CSV (for table kinds), or the raw content. Downloads go to your browser’s default download location.

You can also bulk-export a subject or a whole project from the tree view.

Delete an entry

From the entry detail page, click Delete. Confirm. The entry and all its versions are removed. Deletion is permanent.

If an agent has the entry cached in memory, it may try to reference the deleted data on its next turn — that’s fine, the tool call returns not found and the agent adjusts.

Retention policies

Each project can have a retention policy — data older than N days is automatically purged. Set this on the project edit page under Data retention. Default is no retention limit.

What agents use the data store for

Common patterns:

  • Research agents save one entry per source, titled with the source name, content including quotes and summaries
  • Analysts save tables of structured findings that they iterate on over multiple sessions
  • Project managers save decision logs — what was decided, who decided, why
  • Code assistants rarely use the data store directly (they use the file system instead)

When you want to know what an agent has “learned” about a topic, the data store is the first place to look.

Common pitfalls

Confusing data store with memory. They’re different. Memory is short, searchable notes. The data store is long-form structured content. Agents use memory for observations they’ll search later. They use the data store for findings they’ll read in full.

Letting it grow unbounded. Without retention policies or periodic cleanup, the data store can accumulate years of stale entries. Review occasionally and delete what’s no longer relevant — or set a retention policy and walk away.

Granting data-store access to every agent. Agents that don’t produce structured findings don’t need data_store in their tool set. Saving noise to the data store makes the real entries harder to find.

Where to go next