A database for your AI agent

An agent can research fifty companies in a few minutes and give you a tidy table. The chat keeps it, but as text in one conversation. Next week, a new chat can’t query it, another agent can’t see it, and updating it means pasting it back in, or asking for the research again and getting a slightly different list.

rho gives the agent somewhere to keep that table: by a name, typed, versioned, and reachable from any chat or agent you connect.

Why agents need persistent structured data

An agent works with three kinds of memory, and each is good at something different:

• The conversation. Everything in the chat so far. It’s what the agent reasons over now, but it belongs to one conversation, and a long table crowds out everything else in it.
• Memory of facts. Some agents keep notes between chats, such as your name, your preferences, or a project’s goals. That works for a few facts and doesn’t for two hundred rows.
• Structured data. Rows and columns: a list of competitors with prices, a catalogue, figures pulled from files, the results of a run. It needs to be queried, updated, compared with last month’s, and handed to someone else.

The third kind is what rho is for. Some examples:

• a comparison of vendors, updated each quarter;
• prices of products you track, checked every week;
• figures an agent pulled out of a stack of PDFs;
• an evaluation’s results, written by one agent and read by another.

What rho provides

• Tables by name. The agent saves rows under a path, such as research/vector-dbs. rho reads each column’s type from the values (numbers, dates, true/false, text), so there’s no schema to write first. The table still has one: rows added later that don’t fit it are turned down, with the columns that conflict and how to fix them.
• SQL over every row. The agent reads each column’s summary first, then asks SQL (DuckDB) for what it needs. Only the answer comes back to the chat, so a big table doesn’t fill it.
• A version for every write. Versions never change, and the agent can read any of them by number, restore one, and see who changed what and why. A deleted table goes to the trash. See Tables and versions.
• The same tables in every agent. Claude, ChatGPT, Cursor, Codex and Claude Code connected to one account all see the same tables.
• A link for people. Make a table public, and anyone with the link can open it in the browser, without signing in.

One table, three agents

In ChatGPT:

You: Find the main open-source vector databases and save them in rho as research/vector-dbs, with their licence and main language.

ChatGPT: Saved 4 rows as research/vector-dbs. Version 1.

A few days later, in Cursor:

You: Add Chroma and LanceDB to research/vector-dbs.

Cursor: Appended 2 rows. Version 2.

The next week, in Claude Code:

You: Check each licence in research/vector-dbs against the project’s repo, and update the rows that changed.

Claude Code: Updated 2 rows. Version 3.

Later, in any of them, you ask a question. The agent answers with a query, and the rows stay in rho:

SELECT licence, count(*) AS projects
FROM "research/vector-dbs"
GROUP BY licence
ORDER BY projects DESC

And to see what the licence check changed, it compares the latest version with version 2:

SELECT * FROM "research/vector-dbs"
EXCEPT
SELECT * FROM "research/vector-dbs@2"

That’s the two rows as they are now. Each version also says which agent made it and why, and if the check got something wrong, restoring version 2 puts it back, as a new version. For a list you keep up to date like this, see Research your AI agent keeps up to date.

How to connect rho

rho is a remote MCP server. Add its URL to your agent:

https://api.rho.store/mcp

The first time the agent uses rho, you sign in with a link rho emails you and choose what the agent may do: read and write, or read only. Step by step for each client: Claude, ChatGPT, Claude Code, Cursor, Codex, or any MCP client.

Then you ask in plain words, as above. The agent picks the tools itself: write_table to save, list_tables and describe_table to find and read a table, query to answer. They’re all listed in MCP tools. rho keeps only what an agent writes to it: it doesn’t save your conversations.

From your own code, there’s a Python SDK and a REST API to the same tables.

rho, files, SQLite and Postgres

Each of these can hold an agent’s tables. What differs is how much you set up, and what you get without building it.

• Files (a CSV in the chat, or on disk). Nothing to set up, and fine for a one-off. A CSV keeps no types (a date comes back as text), every change is a new file to keep track of, and a chat’s file isn’t there in the next one.
• SQLite. A real database in one file, and a good choice for an agent working on your own machine, such as Claude Code or Cursor. Agents in a browser, such as Claude.ai or ChatGPT, can’t reach a file on your laptop. Version history and sharing are yours to build.
• Postgres. The most capable of the four. You run it (or a service does), design its tables, give the agent credentials and an MCP server for it, and decide what the agent may change: an UPDATE or DROP changes the data in place unless you’ve set up something to undo it.
• rho. Hosted, so there’s nothing to run, and the same tables reach every agent you connect, in a browser or on your machine. Every write is a version an agent can’t destroy, and a table is a link away from a person. It’s built for tables agents build up and come back to, not for an app’s traffic.

When rho isn’t the right choice

• The database behind an app. For transactions, and rows that change many times a second, use Postgres, such as Neon or Supabase.
• An agent’s memory of conversations. For facts and text, a memory store such as Mem0 or Zep is made for it.
• A one-off answer. If you won’t come back to it, the chat is enough.
• A sheet people edit by hand. If people do most of the editing, a spreadsheet is the better tool.