Launched this week
Backdrop
AI Coworkers that run your projects and operations
191 followers
AI Coworkers that run your projects and operations
191 followers
AI made execution faster. The bottleneck has shifted to deciding what to build while the knowledge behind those decisions is scattered across people, tools, and AI chats. Backdrop provides AI coworkers for projects and operations that understand your company, work with your team,and build shared company context. Across Slack, GitHub, Linear, Notion, Asana, Google Workspace and more, they synthesize customer feedback, create plans and specs, manage tickets, draft documents, and keep work moving.
Backdrop
Hi Product Hunt! 👋 I'm Akanksha, one of the founders of Backdrop.
AI has made execution dramatically faster. But as execution gets easier, the bottleneck shifts to deciding what to build, why it matters, how to prioritize it, and keeping everyone aligned. At the same time, the knowledge behind those decisions is becoming even more fragmented. It's scattered across Slack, docs, tickets, meetings, and now private AI conversations.
Customer feedback gets trapped in someone's ChatGPT. A feature gets rebuilt because nobody remembers why it was killed. Someone joins the team and suggests an idea that was already tried six months ago. Two teammates ask AI the same question without realizing the other already did.
The problem isn't that teams lack information. It's that they can't build on what they already know. Too often, what people learn in AI stays with them instead of the company. We think AI should make companies smarter, not just individuals. That's why we built Backdrop.
Backdrop provides AI coworkers for projects and operations that understand your company, work alongside your team, and carry context across every project and decision.
We're launching with Alex, our AI coworker for projects and operations. Alex connects to Slack, GitHub, Linear, Notion, Asana, Google Workspace, and more to turn customer feedback into product plans, discussions into decisions, meetings into action items, and plans into execution.
If your team ships software, Alex can also bring in Sam, our AI engineering coworker, to implement features, review code, investigate bugs, and turn plans into shipped products.
We're incredibly excited to finally share Backdrop with the Product Hunt community. We'd genuinely love your feedback, questions, and ideas. We'll be here all day, so ask us anything. Thanks for checking us out! 🚀
Backdrop
@akanksha_backdrop Hey everyone, I'm Caitlin, CTO at Backdrop 👋
Building AI that actually works for a company is a different problem than building a chat demo. Most tools reset every session and context lives in someone’s head, a Notion page, or a private ChatGPT thread, and the next person starts from zero again.
My focus has been making Alex and Sam compound instead of reset: pull what’s already known, work across Slack, GitHub, Linear, Notion, and the tools you already use, and leave the company smarter than they found it, not just a longer chat history.
One of the hardest engineering challenges has been getting that right without making the system feel like a black box. Agents should carry real context forward, but teams still need enough visibility and control to trust what happens next. Here to answer questions and appreciate the support!
The shared company context across Slack, GitHub, Linear and Notion is the piece I would test first — for a community or product team the risk is not capability, it is a coworker surfacing something from a private channel into the wrong doc. On setup, can I scope what each coworker reads — connect Slack but exclude specific private channels, or restrict a coworker to one Linear team — or is it all-or-nothing per integration? And when it synthesizes customer feedback into a spec, does it cite the source threads so I can trace a claim back before acting on it?
Backdrop
@hazy0 Great question! On scoping, it’s not all or nothing. In Slack, agents only see the channels you invite them into. In Linear, you can restrict a coworker to specific teams. Private channels and other teams stay out of reach unless you bring them in. On synthesis and traceability, when an agent turns feedback into a plan or spec, the conversations, links, and comments also show up in one place on the dashboard. So you can see what happened and trace claims before you act on them.
That per-channel invite model is the right primitive, thanks. The follow-up that matters for me: once it synthesizes across tools into that shared dashboard, does the output inherit source-level permissions? Concretely — if I invite a coworker into a sensitive Slack channel and it rolls that into a spec, can a teammate who is not in that channel read the synthesized claim on the dashboard, or does the traceability view stay gated to people who had access to the underlying source?
the part that's interesting to me is the cross-tool synthesis rather than just another single-tool assistant - pulling customer feedback and turning it into an actual plan across Slack/Linear/Notion is the annoying manual glue work most teams still do by hand. what's been the hardest integration to get genuinely useful vs. just surface-level read access?
Backdrop
@omri_ben_shoham1 Good question, this is honestly where most of our engineering time goes.
Out of the box integrations from agent builder tools are basically API wrappers. Create a ticket, post a message, read a doc. For some tools that's enough and we keep those light. But for the tools where the core role work happens, it's not. Real PM work means knowing which project the feedback belongs in, what your labels and states mean, who owns what, how to write a ticket someone can actually pick up. The API doesn't give you any of that, it's all in how your team uses the tool.
Then there's the part you called glue work. Feedback sits in Slack, the ticket's in Linear, the plan's in Notion, and none of them know about each other. A lot of what we built is that connective layer, plus auth living outside the agent, tight control over what tools it can touch, and skills that teach it the working path per app and per role.
Hardest ones so far have been tools like Google Workspace and Figma. A PM reviewing a design and drafting a plan is a completely different job than an engineer implementing from that same file and checking the live UI, so a generic read the file integration doesn't cut it. We had to build for each role separately.
Honestly, reading data was maybe 20 percent of the work. The rest was making the agent behave like someone who's actually used the tool before. For eg: Slack isn't just read the channel, it's pull the right signal. Linear and Notion aren't just create a page or ticket, it's write it the way your team would, etc.
Arc
This is cool, all these shared context cos are building stuff for the user but for not the org and its hard to flow context (and importantly, source of truth) across the org. Also daisy chaining tool use is pretty unique in this context.
Is orchestrator multi model?
Backdrop
@basile_senesi1 Thank you! Yeah the user vs org distinction is the key. Personal AI memory is a solved-ish problem, getting a team to one source of truth is not, and that gap is where we live. On the orchestrator, we pick the model for the job under the hood, different kinds of work run on different models. We'll expose that choice eventually, we just don't want teams thinking about model selection on day one
the "someone joins the team and suggests an idea already tried six months ago" scenario is such a specific and true pain point, that's the real cost of tribal knowledge living in people's heads instead of anywhere searchable. when Slack, Linear, and a doc genuinely disagree on the current state of something, does Backdrop surface the conflict to a human, or does it pick one source as authoritative and move on?
Backdrop
@galdayan That scenario is exactly why we built this.
When Slack, Linear, and a doc disagree on the current state of something, Backdrop doesn’t quietly pick one source as truth and move on. It pulls the relevant context, flags the mismatch, and asks clarifying questions so a human can decide. Once that decision is made, that’s what should stick as company knowledge so the next person doesn’t rediscover the same conflict six months later. If a task already points at an authoritative source (linked spec, approved plan), we treat that as the directive. But unresolved disagreement across tools is a clarifying-question moment, not something we want an agent to paper over.
Everyone here is reacting from the "team with scattered Slack/Notion knowledge" angle, which makes sense since that's who you built for, but I'm curious where the line is for a one-person team. If it's just me, GitHub, and a task tracker, is there still enough fragmented context for Alex to be worth wiring up, or is the value fundamentally about reconciling multiple people's half-knowledge? Not knocking it, genuinely trying to figure out if this category applies below a certain team size.
Backdrop
@cannetjam Really fair question. The reconciling everyone's half knowledge part won't do much for you solo, that's honestly a team thing. But a decent chunk of the value doesn't really care about team size. You still don't have to build the agent or set up the integrations (in your case Alex just shows up already working across GitHub and your tracker). And your context is still scattered, just across time and tools instead of people. Why you scoped something the way you did, what you decided and why, what's sitting half done where, etc. Having a memory of all that is valuable. And honestly the delegation part might matter more solo, stuff keeps moving while you're heads down and there's no one else to hand things to.
So yeah it applies, the team stuff is just another layer on top when you grow
that's a great breakdown, especially the point about reading data being maybe 20% of the work. the Google Workspace / Figma example makes sense too, since a PM and an engineer looking at the same file are basically doing 2 different jobs even though the underlying API call is identical. are you building the role-specific behavior as hardcoded rules per app, or is there a more general framework so a new integration doesn't mean starting from scratch each time?
Backdrop
@omri_ben_shoham1 Thanks! Honestly a bit of both. There's a general framework underneath, the integration layer deals with auth and tool access, and the role specific stuff lives in skills (eg how a PM works). So new integrations aren't starting from scratch, a lot of it carries over. But some tools are just weird enough that parts end up custom. There's always some last stretch per app you end up custom building.