Guide

System of Record for AI Agents

A system of record for AI agents is the one place where the business facts an agent produces are stored, attributed, and treated as authoritative — so every later decision, report, or agent run reads from it instead of from a chat log. A store earns that title when every write can be traced to who made it, what it changed, and how to undo it.

That is a property of the write path, not the storage engine. This page explains the distinction, gives five tests you can run against any candidate, and shows how Busabase answers them with one mechanism: every edit is a Change Request.

Last verified 13 November 2026

Connect your agent How Change Requests work

The short answer

What it is

The authoritative home for facts agents produce — customer records, research findings, content, operating docs — that people and other agents read as true.

What earns the title

Attribution, an accountable person, and a history you can replay and roll back. A database with an API gives you a row and a timestamp; the rest has to live in the write path.

Where Busabase fits

Busabase is a workspace built as that write path: every edit by an agent or a person is a Change Request with a diff, an author, and full history. Review is there when the stakes call for it.

Two different things are called a “system of record for agents”

The phrase is used for two different jobs in 2026. Picking the wrong one wastes an evaluation, so start here.

	Agent System of Record (ASOR)	System of record for agent-written data
What it governs	The agents themselves — registration, permissions, activity	The business records the agents produce
Closest analogy	A directory and HR system for non-human workers	The authoritative workspace people and agents both read and write
The question it answers	“Which agents are running, with what access, and are they working?”	“Is this record true, who changed it, and what did it say before?”
Who to look at	Workday sells a product under this name; agent registries and catalogs do the same job	Busabase, or a database plus the audit, review, and interface layers you build yourself

If leadership wants an inventory of every agent running in the company, an agent registry is the right category and Busabase is not it. The rest of this page is about the second job: agents producing real work that your business should be able to rely on.

Why agents make this urgent

Systems of record are not new. What changed is the write rate.

A team writing into a shared database works at human speed, and mistakes get caught by the same friction that slows the writing down. An agent can produce two hundred plausible, well-formatted rows in a minute — and a plausible wrong record is more dangerous than an obviously broken one, because nothing about it invites a second look.

So the honest framing is not “agents need a database.” Agents already have databases. At agent write speed, storage is the easy half; knowing what changed, who changed it, and how to reverse it is the part that breaks.

What makes a store authoritative: the write path

When two sources disagree, the system of record wins. Three properties earn that authority, and all three belong to the write, not to the storage:

Attribution. Every record can name its source — not “API key 7,” but which agent, acting through which key or tool, with what message.
Accountability. A person is answerable for the record in its current form: they wrote it, they gave the agent write access, or they approved the change.
Reconstructability. You can replay how the record reached its current state, compare any two versions, and roll a change back.

Put those together and the shape is one developers already know: a pull request, applied to data instead of code. A diff of exactly which fields changed. An author. An optional review where the stakes justify one. A merge that is recorded, never a silent overwrite. The same applies to what an agent knows — prompts, instructions, and Skills drift the way code does.

How Busabase builds the write path: every edit is a Change Request

In Busabase, every edit — a record, a Doc, a Skill file, a schema change — is a Change Request: a branch with a chain of immutable commits. Merging moves the record forward; nothing is overwritten. It does not matter whether the edit came from Claude Code over MCP, a script over the API, or a teammate in the browser.

Most databases answer the write question with permissions: a write is allowed or denied, and once allowed, the new value replaces the old one. A Change Request keeps both, plus who made the change and why.

A message and a diff on every write. Each change says what it does and shows the field-level before and after.
Know which agent did it. The author, and the key or tool the change came through, stay on the commit.
Undo is built in. Records, Docs, and Skills keep their full history; merging never overwrites, and any change can be rolled back.
Review when you choose. Writes with write access merge at once. Give an agent a proposal-only key, or send a change with autoMerge: false, and it waits in the Inbox for a person to approve or send back. Read the Change Request docs.

A Busabase Change Request under review: its message, a before-and-after diff of a record's body, and Approve or Request changes controls — A Change Request in the Inbox: what changed, who proposed it and through which tool, and the before and after of the field.

This is what lets you give agents real write access to the data your business runs on: nothing they change is untraceable, and nothing is irreversible.

Five tests to apply to any candidate

Run these against a database you maintain, a doc tool, a vector store, or Busabase. The right-hand column is how Busabase answers each one; the last row is the job it does not do.

Test	What passing looks like	Busabase
1. Can a write wait when you want it to?	A change can be stored and reviewable without being true yet — for the agents and records where that matters	Yes — a proposal-only key or `autoMerge: false` holds the Change Request in the Inbox; trusted agents merge at once
2. Is the diff legible to a person?	A reviewer can judge 40 changed records in minutes	Yes — field-level before and after, with rich-text preview, on every change
3. Does provenance survive the merge?	After a change lands, the record still knows its author, tool, and message	Yes — commits stay attached to the record permanently, rejected proposals included
4. Can both people and agents use it?	Structured enough for an agent, legible enough for a person	Yes — Bases with real field types and visual views for people; MCP, CLI, and API for agents
5. Can you leave?	Data, history, and files export in a usable form	Yes — MIT open source, self-hostable, and a space exports to Markdown, Base definitions, and JSON
Inventory every agent, its access, and its activity (the ASOR job)	A registry of agents	Not its job — use an agent registry such as Workday ASOR

Test 1 separates the categories. Tools designed for human writers rarely have it, because a person who writes into a shared database has already applied judgment. In Busabase it is a setting per key, not a different product.

A system of record is more than a table

A business fact is rarely just a row. It comes with the policy behind it, the file it was derived from, and the instructions the agent followed. Busabase keeps them together:

Visual tables people can read

Every Base opens as a table, gallery, kanban board, calendar, or Gantt chart, with saved views and AND/OR filters. A teammate checks an agent's work without SQL.

A team knowledge base

Docs, files, and Bases sit in one tree with one permission model. Members join with read, write, or manage roles; agents join with their own keys.

grep across everything

One regex search over files, Doc bodies, Base records, and agent prompts, returning the line and its context. How grep works.

Shared team Skills

Upload your team's Skills once and every connected agent reads the same version. Editing a Skill is a Change Request, so you can see who changed an instruction and why.

AirApps on live data

Ask an agent to build a small web app on your workspace data. It runs in the browser, on this machine, in a cloud sandbox, or as a website.

Websites on your own domain

The Website engine runs on Cloudflare Workers, can have backend endpoints, and takes a custom domain (Plus and above on Cloud). Agents preview and publish through the CLI, API, or MCP. Website docs.

Agents connect in minutes

MCP, a CLI, an OpenAPI REST API, webhooks, a Python SDK, and plugins for Claude Code, Codex, and DeepSeek Harness that bundle the official skills. Connect your agent.

Open source, runs anywhere

MIT-licensed. Run it on a laptop, self-host it, run it offline or air-gapped, or use Busabase Cloud. A space exports to plain files: Markdown, Base definitions, and JSON records.

Flat, predictable pricing

Free plan for small teams; paid Cloud plans are a flat price per seat with no metered overage. Self-hosting is free with no seat limit. Pricing.

A Busabase Base showing agent-written posts as a table with title, cover image, and body columns, plus saved views — A Base in Busabase: records an agent wrote, readable by anyone on the team. Saved views filter the same records.

Coming next

These are being built now. They are not available yet, and this page will say so until they ship.

App usersIn development

People who use an app you publish sign in with an email code and see only their own records. Enforced by the platform; they are not workspace members and take no seat.

OntologyIn development

Define business objects — Company, Contact, Deal — and the links between them on top of your existing Bases, so people and agents share one vocabulary. Changes to it go through Change Requests.

Fine-grained permissionsIn development

Row- and field-level access inside a Base, agent grants scoped to a task with an expiry date, and access requests that a person approves.

When Busabase is not the right choice

You need an agent registry, not a data store. That is the ASOR category described above.
Your writes are high-frequency machine telemetry or an app's transaction path. Events, logs, metrics, or checkout writes belong in a database built for that shape — see which database your agent should use.
You need pure semantic recall. “Find the passage that resembles this question” is a vector store's job. It is good for retrieval and has no opinion about whether the passage is true.

Plain limits today: Busabase has no realtime subscriptions or vector index, and sign-in for end users of the apps you publish is still in development.

Frequently asked questions

Is a system of record for AI agents just a database?

A database is the storage half. A system of record is storage plus the rules that make a stored value authoritative — attribution, an accountable person, and a reconstructable history. You can build that on any database; Busabase ships it as the default write path.

How is this different from an agent's memory?

Memory serves the agent: it makes the next run better informed and is optimised for recall. A system of record serves the business: it exists so a person can rely on a fact. Agents should read from the system of record, but nothing should be true only because it was in a context window.

Do agents need approval for every write?

No. In Busabase, a write with write access merges immediately — and still arrives as a Change Request with a diff, an author, and undo. Hold changes for review only where they carry consequences: customer records, figures, published content. Draft material and scratch work do not need a gate.

Can multiple agents share one system of record?

That is most of the point. Claude Code, Codex, ChatGPT, and your own scripts can work in one workspace, each with its own key, so every change shows which agent made it and the next agent picks up from the current version.

What happens to a rejected change?

It stays in the history with its status instead of being deleted. A rejected proposal is evidence about the agent, the prompt, and the data.

Can I run it on my own infrastructure?

Yes. Busabase is MIT-licensed and runs on a laptop, on your own servers, or fully offline, as well as on Busabase Cloud. A space exports to plain files.

Next step

The fastest way to judge any of this is to run one real change through it: connect an agent, let it edit a record, and read the Change Request it leaves behind.

Connect your agent All comparisons

Sources: Workday Agent System of Record