Launched this week
Busabase
The general system of record for AI agents
1.1K followers
The general system of record for AI agents
1.1K followers
Different agents. One shared base. Busabase is a general-purpose database and workspace for people and AI agents. Keep business records, docs, skills, and apps in one place so the next task can build on them. Connect Claude Code, Codex, and more. Set access, review changes when needed, and see what changed. Busabase is open source, with Cloud, Personal Desktop, and self-hosting options.
Free
Launch Team
Floot MCPBuild and ship web and mobile apps inside Claude or ChatGPT
Promoted
If an agent updates a business record off a copy it read an hour ago and a teammate edited it in between, which change wins? Curious how "review changes when needed" works when it's an agent racing a person.
@lancelot_d_souza1 It's a bit like Git, and collaborative editing.
@lancelot_d_souza1 Lancelot, the teammate’s edit isn’t silently replaced. At merge time, Busabase compares the version the agent started from, the current record, and the agent’s proposal. Changes to different fields can combine. If both changed the same field differently, the proposal is marked as conflicted and needs to be revised against the current record before it can merge. With changeRequest access, it also waits for human review regardless of whether there’s a conflict. Is this happening with CRM records in your workflow?
@mrkelly Yeah, pretty much. Call notes syncing into a contact while someone on the team is editing the same record. Field-level merge plus a conflict flag sounds right. When a proposal gets marked conflicted, does the person resolving it see why the agent wanted the change, or just the diff?
@lancelot_d_souza1 Great follow-up. The diff alone wouldn’t be enough for me either. The reviewer can also see the Change Request message, so I’d have the agent write down which call the update came from, link the notes, and explain why that contact field should change. If the agent leaves that out, Busabase can’t recover the reason from its private chat. When there’s a conflict, it flags the fields that collided and lets you revise the proposal against the current record. I’m attaching a normal CRM review screen so you can see the layout; it isn’t a conflict screen.
Curious about the permission system. Is it possible to set granular access so different team members can only view certain project records？
@ysssss33 Thanks, Yuan! We currently control access at two levels: the workspace and individual tables.
For example, you can keep each project's records in a separate table and grant access to the relevant teammates.
That covers most of the common permission needs in collaborative tools. [Our old job is collaborative editing. Haha]
@seey That's sounds great, just like what we want.
@ysssss33 Yuan, yes for project-level separation, but I want to be precise about the boundary. Today access can be scoped to a Space and to nodes such as a Base; a filtered view isn’t a security rule for individual rows. If Project A and Project B need different readers, I’d keep their records in separate Bases, make the relevant nodes private where needed, and grant each teammate access to the right project. I wouldn’t promise different permissions for arbitrary records mixed in one Base. The node API shows the visibility model: https://busabase.com/docs/api-openapi/nodes. Do you have separate projects, or different viewers for rows in the same table?
@mrkelly Thanks! My use case is more on separate projects.
@ysssss33 How's about it? Since our powerful permissions center is building. And I am going to release it maybe next week.
If a company already uses agents across engineering, marketing, and sales, what should it add to Busabase first so managers can get useful project updates by simply asking?
@alexia_li Hi, Alexia, I'd start with one project that spans those teams.
Add its goal and brief, then a simple tracker with owners, status, blockers, and next steps. You don't need to move all three departments' information at once.
Have each team's agents record relevant updates there. A manager can then ask, "What changed this week, what's blocked, and who needs to act next?" The answer is grounded in the information your team has recorded and kept up to date.
@alexia_li @matthewwei asked a related question about sharing context between Codex and Claude Code. In my reply, I shared an example of using project instructions to tell agents when and where to fetch relevant business context from Busabase.
For a company using agents across departments, I’d start with one active project. Add its brief, goals, and relevant product or business information as a shared knowledge base. That gives each department’s agents the same factual starting point, helping keep their work consistent.
Then add the information a manager needs for updates: current status, owners, recent progress, blockers, key decisions, and next steps. Include when each update was recorded, and make keeping those records current part of the team’s workflow.
With that context available and the right access, a manager can ask, “What changed this week?” or “What’s blocking the launch?” Their agent can pull the relevant records across engineering, marketing, and sales.
If you’d like a more detailed example for your team’s workflow, feel free to reach out!
@alexia_li Seey’s suggestion to start with one cross-team project is exactly right. If you’d rather begin with something tangible, Busa Standup is a starting template for team check-ins and blockers: https://busabase.com/templates/busa-standup
I’d adapt it around one project: keep its brief in a Doc, and ask each connected agent to record its dated outcome, owner, blocker, next step, and source after completing work. Then the manager can ask what changed and inspect the underlying updates. The template won’t collect every agent’s activity automatically; that write-back step is what makes the answer useful. Which project would you pilot first?
As a fellow AI founder, I’m really glad to see someone working on this. There’s so much attention on what agents can do in a single session, but I’m just as interested in what the next session—or another teammate—can actually build on. That’s what makes the shared base idea compelling to me.
I’d love to hear how you handle two agents updating the same record. How does a person review conflicting changes and decide what to keep?
Congrats on the launch, team. This feels like a problem worth spending years on, and I’m rooting for you.
@leo_ye Thanks, Leo! I care about that too: the next task should be able to build on work already done.
If two agents start from the same version and change different fields, those changes can be combined. If they change the same field to different values, the merge is blocked and the conflicting fields are flagged.
On the review page, a person can inspect the proposed changes and open the current record for comparison. They can then revise the proposal to keep the current value, use the proposed value, or combine the information before reviewing and merging it. They can also close the proposal and leave the record unchanged. The changes and revisions stay in the history.
It's a bit like Git, but for business data such as customer records and project statuses.
It means a lot to have your support as the founder of MyClaw.ai, Leo! Thanks Again。
Are you thinking about agents collaborating within your team, or agents in your product maintaining shared data? I can walk through an example for your use case.
@leo_ye Leo, thanks for rooting for us. Seey explained how conflicting fields are detected. The human part matters just as much to me: a reviewer can open the current record beside an agent’s proposal, inspect the diff, request a revision against the latest state, and then approve and merge it or close it. Nobody has to pick “Claude wins” or “Codex wins” blindly, and a conflicting proposal doesn’t silently replace the accepted value. Here’s what the review surface looks like: https://busabase.com/docs/change-requests. For MyClaw, are your agents maintaining customer data inside the product or shared operations for your own team?
One shared base where different agents read the same records, docs and skills is the missing piece once you have more than a couple of agents, since context gets rebuilt from scratch every time otherwise. Reviewing changes before they land is a sensible safety net. How do you keep two agents from overwriting each other when they edit the same record at once?
@karimbenkeroum Thanks, Kareem! Conflict handling seems to be on everyone’s mind; it’s come up a few times today.
Our approach is quite similar to Git, with some ideas from collaborative editing mechanisms like OT/CRDT in how we handle conflicts. Feel free to try it with mutil agents updating the same record and see how it works.
@karimbenkeroum Kareem, here’s the concrete rule behind Seey’s answer. Suppose both agents read version 1: Agent A changes the owner, while Agent B changes the status. Those different fields can be combined at merge. If both change status to different values, Busabase marks the later proposal as conflicted; it must be revised against the current record before merging. With proposal-level access, even a clean change waits for human review; a trusted write connection can merge a non-conflicting change immediately. The permission choices are here: https://busabase.com/docs/mcp. Do your agents usually edit the same field or separate parts of a record?
the "review changes when needed, see what changed" line is what sold me, not the shared-base idea itself. every team I've seen try a shared context store for agents eventually hits the same wall: one agent writes something subtly wrong into the base and every agent downstream inherits it as fact, with no one noticing until output looks off three steps later. does the change review actually block a write until a human looks at it, or is it more of an audit log you check after the fact once something's already gone sideways
@galdayan It works similarly to Git and code review（Change log, Change review and Approval gate）, with humans acting as the final line of defense.
@galdayan Gal, it can be a real approval gate. With a changeRequest connection, an agent’s proposed edit waits for an authorized reviewer; the live record does not change just because the agent submitted it. The reviewer can inspect the diff and approve or request changes. A write connection is different: a non-conflicting change may merge immediately. So for shared facts you don’t want an agent to publish on its own, I’d use changeRequest access. Would you review every agent edit, or start with the most consequential records?
@mrkelly start with the most consequential records, reviewing every single edit defeats the point of having an agent do the work in the first place. the hard part is defining "consequential" in a way that doesn't just become everything within a month, since almost any record can end up load-bearing for some later decision. is that classification something a team configures up front per-table, or does it learn from which records actually got disputed later