I lead Business Systems and AI Enablement at a software company, and I've watched plenty of AI tools get installed and quietly abandoned. Rebel is one that stuck.
What sets it apart from a chat window is that it plugs into the actual work. It connects to all our SaaS apps with API or MCP access, then acts across them. One team has it pull from several systems every Monday and draft a leadership briefing, replacing an hour of manual system hopping. A product manager connected it to a live codebase and shipped a real UI change in under two hours. Our sales team is running roughly 30% more demos because Rebel handles most of the admin work in the CRM for them. None of this is staged. It's daily use.
Three things I rate:
Memory done right. It distinguishes what's private to me, what's for my team, and what's company wide, and stores things accordingly. That's the foundation of trust.
Automations and skills. You teach it a workflow once and it runs on a schedule, so the time savings compound.
Privacy by design with a real safety layer. It drafts rather than auto sends and asks before anything sensitive.
It's not flawless. Complex tasks take time, and it wants capable hardware. But the output quality makes the wait worth it.
If you want a chatbot, there are cheaper options. If you want an agent that lives inside your tools and does the work, this is the one I'd back.
A few honest rough edges:
Speed. It's the most common gripe. For multi step agentic work the wait is justified, but for quick one shot questions it can feel slower than a plain chatbot. Snappier responses on simple tasks would close the gap.
Onboarding and discoverability. The capability surface is huge, and new users struggle to find what it can actually do. It rewards people who invest time learning it, but the first week is a climb. Better in product guidance would shorten that.
Cost control on simple tasks. It can spend a lot of model power on tasks that don't really need it, which drives the underlying AI cost up faster than you'd expect. Smarter matching of effort to task would keep spend in check.
ChatGPT, Claude, and Gemini are excellent at responding, but you feed them context and copy the output back out. Rebel was the only one that lives inside the work rather than beside it. It routes to whatever model fits the task, so I'm not locked to one provider. It keeps memory with real privacy boundaries between what's mine, my team's, and the company's. And it gives me a governance and safety layer I can actually administer, which is what let me put it in front of the whole company. For quick one off drafting a raw chatbot is fine, but on cross tool, repeatable work nothing else came close.
Hey Product Hunt, I’m Melissanthi, Senior Product Engineer at Mindstone.
We’re launching Rebel as a Fair Source AI desktop app for agentic work.
The reason we’re doing this now is simple: AI work shouldn’t be trapped inside one closed platform or one model provider. Rebel is built as a desktop workspace that people can download, run locally, inspect, customise, and connect to their own tools through MCP.
Fair Source means the code is available, but with practical restrictions that let us keep building the product sustainably. Small teams and individuals can use and adapt Rebel freely, while larger organisations need a commercial licence.
This release is also part of a broader push toward more portable AI workflows: model choice, local-first files, MCP connectors, and workflows that teams can actually understand and adapt.
We’d love feedback from makers, developers, operators, and AI teams on:
• what you’d want from a Fair Source AI workspace
• how you think about model choice and local-first AI tools
• what would make Rebel useful in your own workflow
@melissanthi_papacharalampous1 Asking first before taking actions is such a better default for agent behavior. What surprised you most when you started testing this with actual developers?
the approval checks for sensitive actions is something more agent tools should be doing. most platforms either give the agent full access or keep it so restricted it can't do anything useful. that middle ground where the agent works freely on low risk stuff but pauses for human approval on anything sensitive is how you actually get teams to trust agents with real workflows. curious how granular the approval rules are, can you set different thresholds per agent or per action type?
@shubham4real we have a few approaches and systems working together. 1) the system learns from your approvals over time and you can tell it to “approve in X context”. 2) the system is aware of original query. Sending an email when specifically asked to do so is normal. Sending an email when the query was about research, less so. 3) the system is aware if impact (writing to shared spaces is more risky than writing to a private space). 4)you can switch individual tools on/off so you can have an email mcp with rights to draft, but not send for example
@shubham4real After each approval request, you can give it guidance, e.g. "In future, it's always fine to send emails to internal people".
The system makes suggestions for rule-updates of different granularity, or you can write a custom one.
If I’m understanding this right, the local-first/customisable thing makes sense, especially if the point is not getting stuck inside one AI vendor’s way of working.
One thing I’m wondering though is what happens once this moves from one person using it to a small team using it. If people start adapting their own workflows, connectors and approval rules, do you risk everyone ending up with slightly different ways of working?
Is there a way to share the setups that work well without making it feel like one central locked-down workspace again? Curious how you’re thinking about that.
@tobiasfleischer Hi Tobias, thanks for the question. We know that the impact of Rebel compounds when teams can use it together effectively, we see this in our team every day. Its quite easy for colleagues to share or build upon each others skills or automations. Safety settings, model configurations and connector suggestions can all be managed centrally by admins if required.
@tobiasfleischer One more thing to build on what Liam said - we allow for one user to customise a base (i.e. shared) skill. So there might be a base sales proposal skill shared with the whole team, and one person could choose to create a customised version that varies slightly, based on their preferred style.
Strong angle, and the maker replies show you've thought about the hard part. One thing I'd add from doing this on customer-facing work: the risk with ask-first isn't only where you draw the line, it's approval fatigue. If the agent interrupts too often, people start rubber-stamping every prompt and the gate quietly stops protecting anything. Two things seem to matter most: making each approval information-rich enough to decide in a couple of seconds (what it's about to do, why, and the source it's acting on), and the auto-updating rules you mentioned so it stops re-asking about things someone has already approved a dozen times. Get those right and ask-first scales; get them wrong and it becomes click-through noise. Curious whether Rebel surfaces the "why" and the source inline at the approval moment. Congrats on the launch.
@syed_noor4 great shout and totally agree. Yes we try to surface the context and all information required to easily make a “yes/no” call within a few seconds. Not perfect yet (and will continue iterating), but hopefully better than what’s out there at the moment.
@syed_noor4 Yes yes yes to everything you're saying here. We went through so many iterations trying to get this right.
As you say, it needs to give you enough for a quick decision, but also access to the full details if you want to dig in.
I'd be interested to hear what you think of where we landed.
@greg_detre Thanks Greg, Joshua. That is the right place to land, the quick yes/no with full detail one click away is exactly it, and it sounds like you have thought it through more than most.
One dimension I would add to round it out: ask-first protects you before the action, but the other half of trust is
what happens after a yes that turns out wrong, because at any volume some approvals get rubber-stamped no matter how good the prompt is. What lets people approve fast without anxiety is knowing a wrong yes is bounded, a clear record of what the agent actually did, and ideally an undo for the reversible stuff. Pair that with your impact-awareness (draft vs send, private vs shared) and the cost of a mistaken approval stays low, which is what makes the gate feel safe rather than scary.
The other quiet signal worth surfacing is the approval rate itself: if someone has approved the same action 20 out of 20 times, that is the system telling you a rule is overdue, which sounds like exactly what your rule-suggestions already do. Genuinely nice work, I will be watching where this goes.
The 'ask first' principle is something we've had real debates about internally. Autonomous agents that act without confirmation can compound errors in ways that are hard to recover from, especially in stateful workflows. What's your approach to calibrating when the agent should interrupt vs. proceed? Does it use confidence thresholds, or is it more rule-based?
@anand_thakkar1 it’s a combination of confidence thresholds, with auto updating rules (you can tell the system how to update it’s own rules for future calls) and hard lines (like a non understood bash command).
All of this in context of the user’s query: if the query specifically asked to send an email, the “send-email” tool is fine. If the request was “do some research” that same tool call appears more risky.
The approval-before-action model works well for individual workflows but gets complicated fast in team settings. Imagine two people on the same team have given Rebel conflicting learned rules for the same action type. One has approved it, one has flagged it. When a shared automation runs, whose learned policy governs? This seems like it could silently diverge across team members over time, especially as each person's rule set adapts independently. Have you thought about a policy reconciliation layer for shared workflows, or is the current model intentionally keeping rules personal and non-shared?
@binu_george Hmmm, great point!
Company Technical Admins can set some company-wide safety prompts and settings.
Within that, each person can tune the safety approval based on their own preferences.
That's the balance we've tried to strike, but you're right that there are subtleties here that deserve close exploration, especially with shared automations.
@greg_detre yeah, admin/user hierarchy makes sense as a design choice. Company-wide floor, individual tuning above it. The scenario I'm still curious about is when a shared automation fires and hits an action that sits in the gray zone between an admin rule and a user's individual preference, does Rebel surface that conflict explicitly, or does one silently override? That's the edge case worth designing for early. silent overrides are where trust erodes in team tooling.
@binu_george I think in that case, the general-purpose safety classifier would run (which checks all tool calls, shared memory writes, etc), and it would make a decision about whether it's ok or whether to ask for user approval.
Since it's local-first with model choice, can the approval checks for sensitive actions run entirely on a local model, or does the gating logic still require a cloud model call?
@nikita_zaro You are two steps ahead! That is exactly the kind of thing we're thinking.
Right now, there are 3 different tiers of model:
- Planner for overall task decomposition, needs a smarter model
- Worker does most of the heavy lifting, could be a mid-tier model
- Background/behind-the-scenes model: does a lot of the lower-level house-keeping (e.g. safety-approval classification).
You could set that background/BTS to a local model, and then the safety approval decisions would be routed through it.
I haven't tried this, but it's a great idea.
@greg_detre Love this — the three-tier setup is really elegant, and routing safety approvals through a local background model makes a lot of sense. Thanks for the detailed reply!
@nikita_zaro you can configure it to entirely rely on your local model even for the gating logic
@joshuawohle That's great to hear — full local model support even for the gating logic is exactly what I was hoping for. Thanks!
ChatGPT by OpenAI
Gemini
Claude by Anthropic
Thanks for the thoughtful review. We’re working on the speed bit as we indeed built it for “real work” (as opposed to many others which did this the other way around).
Cost is also very high on the roadmap, with real movement already from next week