Guide

What Is an Agent Workspace?

An agent workspace is a durable, shared place where AI agents and people work on the same material — structured data, documents, files, reusable Skills, and small apps — so the work persists across sessions instead of living in a chat log.

The term covers four quite different kinds of product, and picking the wrong kind is the most common mistake in this category. This page sorts them out, gives three tests for any candidate, and shows what the shared kind looks like in Busabase.

Last verified 13 November 2026

Connect your agent All comparisons

Why the term appeared

Agents got good enough to produce real work before anyone decided where that work should live. Output landed in chat transcripts, scattered files, and half-finished SaaS records. On the next run the agent rediscovered its context from scratch, and the person supervising it could not tell what had changed or why.

“Agent workspace” is the market's name for the missing place.

The four kinds

1. Desktop and coding agents

The workspace is your filesystem and repository — Claude Code, Cursor, Codex. Best for writing and changing code. Weak at anything that is not a file, and at sharing work without sharing a machine.

2. Cloud task runners

A hosted sandbox that exists for the length of a job. Best for scheduled and triggered automation. Weak at accumulation — each run starts near zero.

3. No-code agent builders

Visual flow builders; the workspace is the canvas. Best for connecting SaaS tools without code. Weak at being a home for the data — state lives in whatever apps the flow touches.

4. Shared data and knowledge workspaces

A persistent workspace of records, Docs, files, Skills, and apps that agents and people both read and write. Best for work that accumulates and is read later by people and other agents. Weak at being an app backend or an execution sandbox. Busabase is this kind.

The four kinds, job by job

Rows are the jobs teams bring to an agent workspace. Most of them are the shared kind's job; writing code is not, and the table says so. Cells describe each category in general — individual products vary.

What you need	Coding agents	Cloud task runners	No-code builders	Shared workspace (Busabase)
Work survives the session and accumulates	In the repo, as files	Usually not; each run starts fresh	In the apps the flow touches	Yes — records, Docs, files, and Skills persist
Colleagues read it without the agent's machine	Via git, for engineers	Results only	In each connected app	Yes — table, gallery, kanban, calendar, and Gantt views
See what an agent changed, field by field, and undo it	For code, via git diffs	Run logs	Run history	Yes — every edit is a Change Request with a diff, author, and rollback
Hold one agent's changes for a person	Code review on pull requests	Varies	Approval steps in a flow	Yes — a proposal-only key sends changes to the Inbox
Give every agent the same team Skills	Per machine or per repo	Per job configuration	Per flow	Yes — uploaded once, read by every connected agent
Find exact text across everything	grep over local files	—	—	Yes — one grep across files, Doc bodies, records, and prompts
Turn the data into an app or a website	Build and host it yourself	—	Forms and simple interfaces	Yes — AirApps, including websites on your own domain
Write and refactor code	Yes — their home ground	Yes, in a sandbox	No	Not its job — pair it with Claude Code or Codex

How to tell which one you need

Three questions, in order. Each one eliminates categories.

Does the output need to survive the session? If not, you want a runtime, not a workspace — kinds 1 and 2 are fine and you can stop here.
Is the output files, or records? Code is files, and kind 1 handles it through git. Customer records, research findings, content calendars, and datasets are records — forcing them into Markdown is how teams end up with a folder nobody can query.
Who reads it next, and can they see what changed? If the next reader watched the agent work, this is not a problem. If it is a colleague, an app, or another agent next month, the workspace has to carry provenance: where a value came from, who changed it, and what it was before.

Three tests for any candidate

Are agents first-class? Can an agent read and write through an API, MCP, or a Skill as capably as a person can through the UI — or is this a human tool with an AI button attached?
Does output become a system? Does work land as structured, queryable, reusable material — or as transcripts and attachments only a person can interpret?
Are writes traceable and reversible? Can a later reader see where a value came from, who changed it, and roll it back? If a wrong agent write is indistinguishable from a right one, the workspace is storage, not a record.

Plenty of good products pass one or two. That means they solve a different problem; match the problem to the product.

What the third test looks like in Busabase: every change 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 immutable commits, a message, and a field-level diff. It is the same whether the edit came from Claude Code, Codex, ChatGPT, a script, or a teammate in the browser.

Many workspaces built for people answer “who changed this” with page history or an activity feed. A Change Request keeps the exact before and after of every field, the agent and key behind it, and a one-step rollback — and it lets you decide, per agent, whether changes land at once or wait for a person.

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.

What else Busabase gives your agents and your team

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 you do not need one at all

If your agents only write code, your repository already is the workspace, and adding another is overhead. If the agent's output is read once by the person who prompted it and then thrown away, a chat interface is enough. The workspace question becomes real when output accumulates and is read by someone who was not there when it was produced.

Plain limits of Busabase today: it is not an execution sandbox for long-running jobs or an app backend — it 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 an agent workspace the same as agent memory?

No. Memory helps an agent recall what happened; a workspace is where the work itself lives, in a form other people and systems can read. They complement each other.

Can Notion or Airtable be an agent workspace?

For document- or table-shaped work, increasingly yes. Notion announced External Agents — Claude Code, Cursor, Codex, and Decagon among the launch partners — on 13 May 2026, with access through a private-beta waitlist. The usual gap is the third test: field-level history of what an agent changed, and control over when it lands. See Busabase vs Notion.

Do I need one if I use Claude Code?

Not for code. For everything else your agent produces — research, records, documents other people need — the repository is a poor fit. Claude Code connects to Busabase through a plugin or MCP.

Does every agent change need approval in Busabase?

No. Writes with write access merge immediately and still carry a diff, an author, and undo. Give an agent a proposal-only key when you want its changes to wait for a person.

Is this just a database with extra steps?

A database answers where the bytes go. A workspace also answers who may write, what a person can see and undo, and how the next reader knows where a value came from. See which database your agent should use.

Next step

Connect one agent to a Busabase workspace, let it do one real task, and look at what it leaves: records your team can read and a Change Request for every edit.

Connect your agent Browse templates

Sources: Notion: Introducing the developer platform