Stop building software AI can't read.

Not "stop writing code." Stop shipping black boxes—pages only humans can click, wikis only humans can skim, private APIs only the app itself can call—then watching the next agent bounce off a wall while people quietly stop using the thing. If agents can't read it and people stop showing up, the software was wasted work the day it shipped.

After you ship software for humans, the next agent still faces pages, wikis, and private APIs it cannot enter

Stacking more of that kind of software does not expand capability. It stacks more black boxes. People become translators, porters, the "please read that table back to me" API in the middle. That is not a product. That is waste.

Working on software recently, we put it more bluntly:

Stop building software AI can't read. If you build, open interfaces for agents—and keep every write behind a Change Request. That beats hand-crafting more UI as the only door.

UI still matters. It just should not be the only entrance. What pays off is a system agents can read, write, and leave in a state people can still understand and hold accountable.

That, to us, is the point of Busabase.

A small field note

Once, an agent followed open interfaces far enough to turn a payment trail into "course top-up"—not by guessing, by reading. Someone nearby put it plainly: open the interfaces enough, and it digs everything out.

The shorter version:

That's the value of Busabase: read as you need.
Change Requests also cover you.

Illustrated exchange: open interfaces let agents dig up facts; Change Requests keep writes covered

"Read as you need" is openness. "Cover you" is control. An agent workspace only stands if both are true at once.

1. Structured openness: Skills, data, and docs agents can actually use

Most "open" software stops at a human page, or at a private API meant for the app itself. For agents, that is not enough—if they can't get in, you might as well not have built it.

Busabase makes the workspace a node tree: Bases (typed records, relations, views), Docs, Files, Drives, Skills, AirApps, whiteboards, workflows. People and different agents share the same structured ground. The product line is blunt on purpose:

The System of Record for AI Agents
Different agents. One shared substrate.

Openness is not dumping Markdown into a folder. It needs at least three layers:

Data is structured.
Records have field types, relations, and views. Agents can list, grep, and query. They are not "remembering" from a chat log; they work on a fact base people and agents can open, cite, and correct.

Knowledge and operating manuals are structured too.
Skills are first-class nodes: a SKILL.md plus supporting files, hung in the workspace. Playbooks catalog them so an agent looks up "how this space does this job" before acting. Templated apps arrive with manuals—what tables mean, what fields do, what not to touch—so the next agent reads the same handbook instead of a paste from someone's clipboard.

The access surface is designed for agents.
Agent Skills, MCP, OpenAPI, CLI, SDK. No built-in model. No vendor lock for the agent runtime. Agents stay mostly stateless; the work stays in the workspace—reading what the team and other agents already left, then writing results back.

We publish our own site content the same way: the publishing flow, field contract, and target Base live in the Busabase workspace. A Blog Post is a structured write, not another MDX file buried in a repo. The content itself becomes something the next agent can keep reading.

Open interfaces are what let agents dig. Clear structure is what keeps what they dig up as fact instead of hallucination.

That is closer to "let AI work" than stacking more hand-built UI. UI serves people. Structured interfaces serve people and agents together—and keep you from shipping software nobody (agent or human) will keep using.

2. Freedom with control: permissions + Change Requests

Openness without control turns an agent into an unauditable mess. Control without openness puts you back on "everything needs a human click"—the same wall agents can't read through.

Workspace nodes on the left; every write becomes a Change Request with propose, permission, and audit on the right

Busabase's path looks like this:

Agent reads workspace context
        ↓
Agent writes data, docs, Skills, or app changes — always as a Change Request
        ↓
Permissions decide: merge now, or land in Inbox for review
        ↓
Either way, the change is visible, attributable, and reversible

Every write is a Change Request: a message, a field-level diff, an author, plus history and an audit trail. It is not "mutate the table, then bolt on a log." The change itself is first-class.

Permissions set how free the agent is:

Credentials with write can merge immediately—and still leave a diff and history;
Credentials capped at changeRequest can only propose into Inbox;
A single call can still ask for a human look;
Agents are told not to approve their own in-review CRs—approval is a human decision.

So "freedom" is not unbounded writing. It is fluent read/write inside the permission boundary. "Control" is not a roadblock on every step. It is changes you can read, assign, roll back, and hold when a person should decide.

That is the product meaning of "Change Requests also cover you": openness lets agents get work done; Change Requests let people—and the next agent—see, review, and take it back.

How this differs from a traditional database

A traditional database really is a database.

Postgres and MySQL are excellent at storage for applications. They were not built as an agent workspace: no shared Skills, no proposal boundary, no default path that weaves message / diff / author / review into every write. Tools like Airtable and Notion are strong for direct human editing; once agents become the main writers, what is often missing is native agent access, shared operating manuals, and a reviewable proposal layer.

Vector stores and "agent memory" help one agent recall context. They usually do not give you a structured fact base a person can open, cite, and correct on the spot.

Busabase itself runs on Postgres (or embedded PGlite). It is not trying to replace the database inside your product. It adds a shared workspace for people and agents: structured openness for reads, Change Requests for writes.

In one line:

Traditional databases were not designed for agents. Busabase was.

So should we still build software?

Yes—just not the kind AI can't read.

The center of gravity has to move: from "a few more pages only humans can click" toward "a few more doors agents can actually open, with locks and audit on those doors." Software that agents can still read, write back to, and get reviewed against will not become the next barrier—and will not go meaningless the moment people stop acting as translators.

Open the interfaces enough, and details like a course top-up actually surface. Keep Change Requests complete enough, and after the dig—and after the edit—someone can still cover it.

Stop building software AI can't read. Read as you need. Keep a human safety net.
That is the value Busabase is trying to hold.

FAQ

No. Busabase can run on Postgres / PGlite. The goal is not to replace your application database; it is a shared structured workspace for people and agents—records, docs, Skills, apps—and a Change Request on every write.

Yes. That is why writes are Change Requests: write-level credentials can merge immediately (still with a diff); lower credentials land in Inbox. Openness solves "can read / can propose." Control solves "can explain / can reverse."

Vector stores and session memory help one agent recall context. Busabase aims at structured facts people and many agents can open, cite, and correct—plus a reviewable write path. Closer to a system of record than private memory.