Customer.ioAutomate Messaging Everywhere — Startups Get 12 Months Free
Promoted
BearDrive
The open-source shared folder for your team's AI agents
239 followers
The open-source shared folder for your team's AI agents
239 followers
Your AI agents create real files locally: reports, decks, CSVs, research. BearDrive syncs the folder they already work in, so every file is born shared: versioned, attributed down to the agent session, with links only your team can open. Unlike Notion or Drive, nobody moves anything; a teammate's agent reads your agent's work at a real local path seconds later. Works with Claude Code, Cowork, Codex, Gemini CLI, any local tool. Open source and self-hostable. Managed service free during beta.
Runbear
Runbear
A few folks asked the same great question (thank you for the great question!), so answering once here: how is this different from Notion/ClickUp/Drive with MCP?
Different layer. Notion is where your team writes docs; BearDrive is the folder your agents already work in, made shared. Our agents' output is mostly not prose (HTML reports, CSVs, decks), and moving those into a workspace is a step a human or an MCP call has to perform. That step is what fails, which is how reports end up as Slack uploads named report-v2-FINAL.html.
With BearDrive there is no step. The file syncs the second the agent writes it, with authorship down to the agent session, and a teammate's agent reads it at a real local path with its normal tools. Most teams keep Notion for docs and run BearDrive underneath for the working files.
@snowlee Nice launch congrats🙌i really like the focus on actual files rather than creating another separate AI workspace. It keeps the workflow simple.
Runbear
@priya_kushwaha1 thank you for your kind reply, Priya!
Dial
the "syncs to your team in seconds" part is what gives me pause rather than the storage question everyone else is asking. an agent working on something sensitive - a customer contract draft, a research doc that accidentally captured an API key or PII from a scraped page - now propagates to the whole team's synced folder before any human looks at it, since there's no workspace-level review step like a PR or a Slack post someone has to actually send. is there any per-file or per-folder gate before something syncs, or is the model "everything your agent writes locally is now everyone's by default" and you're expected to gitignore-style exclude the sensitive stuff yourself?
Runbear
@galdayan Thank you for this question, Gal! It's the sharpest one here, and it's exactly the right thing to press on.
To your last point first: yes, there's a `.bdriveignore`, exactly gitignore-style, and it syncs with the folder itself, so the exclusion rules are team-wide policy rather than per-person discipline. `.env`, key files, raw scrape dumps, whatever patterns you define never leave the machine.
But it's not the only gate, and honestly not the main one. The main one is scope: BearDrive doesn't sync your whole project. You connect a specific subfolder (ours is `shared/`) and only what's written inside it ever syncs. Your agent keeps working in the project root as usual; scratch work and intermediate junk stay local. Writing a file into the synced subfolder is the send, the same deliberate act as posting to Slack.
And you control that behavior directly: the rules for what belongs in the shared folder live in your own AGENTS/CLAUDE.md ("deliverables only, never secrets or raw scrapes"), so it's an instruction your agents actually follow, versioned and team-visible like everything else.
When something wrong lands anyway: every change hits the feed with author, device, and agent-session attribution, files can be removed, versions rolled back. Recoverable in a way a Slack upload isn't. Though I won't oversell it: if a real API key syncs, rotate it. Same rule as git.
You're right that there's no review-before-sync step today. We're going to add more gates there, and if you have opinions on what it should look like (per-folder rules? a PR-style diff before something becomes the team's copy?), I'd genuinely love to hear them.
Dial
@snowlee a full PR-style diff on every sync would undo the thing that makes this better than slack in the first place, the whole pitch is that writing the file is the send, no extra step. i'd rather see it scoped by risk than by ceremony: most folders keep syncing instant like today, but specific subfolders (or patterns) get flagged "review required" and hold in a pending state until someone approves. that way a team's throwaway research notes don't feel a PR queue but the finance or legal folder does.
the other thing i'd want on top of .bdriveignore is a passive scanner that flags high-entropy strings or common secret shapes on anything about to sync. not to block by default, just to catch it, because "forgot to ignore this" is the real failure mode, not "meant to share it." pattern lists always miss the one thing your team didn't think to list.
Runbear
@michael_vavilov It's a fair question! Thank you, Michael. Honest answer first: if Notion + MCP is working for your team, don't migrate. Notion is great for prose the team reads.
The category is different though: we're much closer to Google Drive than to Notion. Notion is a place agents write into; BearDrive is a folder agents work in. And being the native file system makes a bigger difference than it sounds.
Our agents' output is mostly not prose: HTML reports, CSVs, PDFs, deck files. In Notion those become attachments, and an attachment is a dead end for the next agent. In a real folder they're just files at real paths, so when my agent continues a teammate's work it greps, edits, and re-renders with its normal tools. No fetching blocks over an API, no markdown-to-blocks conversion loss, no re-explaining context.
So in practice teams run both: Notion stays the wiki humans read, the shared folder is where working artifacts live, with attribution per change down to the agent session (which already caught an accidental rollback of a teammate's edits for us).
If your agents' output is mostly prose pages, you're honestly not our user yet, and that's fine. Curious though: what happens today when an agent produces something that isn't a page, like a CSV or an HTML report?
Runbear
@samdcbu Thank you, and honest respect for the rclone + jujutsu rig, that's exactly the duct tape we keep finding in the wild, and "sync with provenance" is precisely the job. If BearDrive gets to retire it, I'll consider that the best compliment we've gotten.
On large files, to be transparent: BearDrive isn't specialized for synchronizing big files, but we've confirmed it handles 100 MB+ files without problems, so your `.lbdb` files should sync fine today. The one thing worth knowing is that history is kept per change, so a large file that gets rewritten very frequently costs storage and bandwidth on every write. If your agents touch the `.lbdb` constantly, you may want it in `.bdriveignore` with periodic snapshots synced instead; if it changes a few times a day, just sync it and don't think about it.
Your use case is exactly the kind that should shape how we handle big binaries going forward, so we'll take extra care there. Thank you for the kind words!
ByteNite
Nice launch and glad this streamlined your team's productivity. :)
I'm still unsure why this should replace workspace setups like Notion/ClickUp connecting via MCP or a team Shared Drive folder though. At my previous company we were particularly concerned about the same docs centralization problem you're describing, which is why we would have still chosen Notion/ClickUp over an extra drive to store key resources and collaborate on docs.
Runbear
@fabcairo Thank you for your support, Fabio! Thank you! And honestly, it doesn't replace Notion. For docs humans write and collaborate on, Notion is the right choice.
What changed for us: once the whole team ran agents daily, most new artifacts weren't docs anymore, they were files on local disk: HTML reports, CSVs, decks (in HTML). Getting those into Notion or a Shared Drive takes a step someone has to perform, and that step is what fails. That's how reports end up as Slack uploads.
BearDrive removes the step. It syncs the folder agents already work in, so files are born shared: authorship down to the agent session, and teammates' agents read them at a local path with their normal tools, no API fetch, no paste.
So: Notion for the docs, BearDrive for the working files underneath. Curious, at your previous company, when an agent produced a CSV or an HTML report, where did it end up?
May be I am missing some thing here, we use Notion for this now. How do you differ from that approch ?
Runbear
@jay_janarthanan1 Not missing anything, it's a fair question (a few folks asked, so the short version):
Notion is where your team writes docs. BearDrive is the folder where your agents already work, made shared. Different layer.
Concretely: our agents produce HTML reports, CSVs, and decks on local disk. Moving those into Notion is a manual step (or an MCP call that turns a file into a page, lossy for anything that isn't prose). With BearDrive there's no step: the file syncs the second it's written, with authorship per change, and a teammate's agent reads it at a real local path with its normal tools.
So most teams keep Notion for docs and use BearDrive for the working files underneath. If your agents' output is mostly prose pages that end up in Notion anyway, your current setup is honestly fine. The difference shows up the day it isn't just prose.
BearDrive
Maker here. Really proud of the team for bringing BearDrive to life🔥
AI agents are having their Dropbox moment!
Our agents can produce dozens of HTML pages and PDFs in a day: quick dashboards, analysis reports, launch docs.
Creating useful files is easy now.
Finding them again is not.
A week later, I know the report exists. I just don’t know whether it’s on someone’s laptop, attached in Slack, or buried under a filename nobody remembers.
And when I do find it, I’m not always sure it’s the latest version.
That’s the Dropbox moment: not another place to dump files, but a way to stop agent-made work from feeling scattered and disposable.
The part I care about most is the handoff. One agent creates something, and another teammate’s agent can actually find it and build on it later.
When an agent creates a useful file on your team, how does the next person find it a week later?