Let's do an honest agent roast. If you've tried using an AI agent in real work, tell us about a time it didn't work.
What were you trying to get done? What did the agent do instead? What did you have to redo or clean up? Stories from sales, operations, research, support, coding, or anywhere else are welcome.
Maybe it lost context between tools. Maybe it lacked permission, made something up with confidence, or broke in a completely different way. No polished demos, no pitches, and no need to have a fix. I'm curious which failures keep showing up when agents leave the demo and enter daily work.
What's your most memorable agent fail?
honestly for dev teams I'd still keep that context in git, every coding agent already reads the repo. from my experience building Voiden that works well. is Busabase mostly for the business side, or do you see engineering teams moving it out of the repo too?
@nikolas_dimitroulakis Nikolas, I agree that Git works well for code and repo-local instructions. Busabase is primarily for work Git makes hard for non-engineers: marketers coordinating campaigns, sales teams maintaining CRM and follow-ups, and operations or finance teams reviewing agent-produced records. Asking them to use branches and PRs just to share context is a high bar.
What surprised me is how much engineers and PMs use it too. They keep code in Git, then use one Busabase Space for cross-repo changelogs, specs, product docs, decisions, and tasks. Connected agents can pick up that context and record the result for the next person. We’ve seen this support a nearly end-to-end R&D workflow in a customer project, with a dramatic effect on team capacity.
So Git remains the home for code; Busabase gives the wider team shared operating context. For Voiden, where do customer feedback and product decisions go when they span several repos?
Congrats, Kelly and team! The before-and-after view of an agent's changes caught my eye. I'd want to see that before letting it update shared records.
@oleksii_sekundant Thank Q, Oleksii!
Seeing exactly what an agent changed makes it much easier to decide whether to accept the update.
@oleksii_sekundant Oleksii, thank you. The before/after view is one of the parts I care about most. With proposal-level access, an agent submits a change instead of making the shared record live immediately. The record owner can inspect the changed fields, compare the old and proposed values, and approve or request changes. The decision and history stay with the result. I’ve attached an example of a normal review screen; it isn’t a conflict screen. The Inbox walkthrough is here: https://busabase.com/docs/inbox. Which record would you put behind review first?
Love this concept. A shared source of truth for agents is long overdue. Upvoted!
@carlvert Thanks for the support, Carlvert! I'd love to hear your use case if convenient
@carlvert Thank you, Carlvert. I’d test the shared-base idea with one real handoff: save a project brief and its decisions in a Doc, keep status and next steps in a Base, then have one agent record what it finished. Connect a second agent to that same Space and ask what changed and what should happen next. The useful test is whether it can answer from the recorded work without replaying the first agent’s chat. Here’s how to connect an agent: https://busabase.com/docs/agents-getting-started. What would your team put into that shared context first?
Looks so cool!
@freedomkelly Thanks for the comment
@freedomkelly Thanks, Kelly! If you give it a try, I’d start with one project brief in a shared Space, connect the agent you already use, and ask it to create a small tracker from that context. The setup guide is here: https://busabase.com/docs/agents-getting-started. I’d love to hear what you build.
shared memory for agents is the real peice 🔥 teams or solo users so far?
If I connect an agent, what actually enters the shared workspace? Do private chats and local files stay private unless someone chooses to add them?
@stellylin Thanks for commenting, Stelly!
Connecting an agent doesn't automatically share your private chats or local files. Content enters Busabase when you or your agent explicitly adds it. You can also set permissions so that agent changes go through review before being merged into your team's data.
What kind of information would you like to share with your team? I may be able to help you find a setup that fits.
@stellylin Stelly, connecting an agent does not automatically copy its existing private chats or local files into Busabase. Content enters the shared workspace when you or an authorized agent submit it.
You can put a rule in your project’s AGENTS or CLAUDE instruction file, such as “save approved project briefs to Busabase, but never save private chats.” That tells the agent when to use the Skill. The permission grant is the stronger boundary: start with read-only or proposal-level access, verify the workspace it connected to, and check the agent app’s own local-file permissions separately. Connection and permissions guide: https://busabase.com/docs/mcp
Which are you most concerned about: chat history, local files, or customer data?
Congratulations on the launch, Team
Connecting Claude code, Codex and other tools to the same base saves a lot of repeat setup. How long does it take to connect a new agent for the first time?
@rohit62661 Thank You Rohit!
About 30 seconds, because you only need to copy Prompt to the Agent to connect.
@rohit62661 Rohit, copying the setup prompt can take seconds. On a first connection, sign-in, choosing permissions, and checking the target Space may take longer. In Cloud, open Agent Skills, paste the Space-specific prompt into Codex or Claude Code, complete authorization, and ask the agent to verify the Space and list its Bases. Then give it one real brief to read before a task. A second agent can connect to that same Space without rebuilding the brief. The full guide is here: https://busabase.com/docs/agents-getting-started. The screenshot shows a reusable Skill prompt once connected. Which agent are you trying first?