Comparison
Hosted agents vs a sovereign workspace
Dust, out of Paris, builds hosted agents over the tools a modern company lives in — Slack, Notion, Google Drive — and does it well. If "hosted" is a word your security team can sign, it belongs on your shortlist and this page will not talk you out of it. This page is for the organisations where "hosted" is itself the question: where the agents, the automations and the retrieval have to run on infrastructure you hold, against a model you chose — possibly one on your own network — with an audit trail you own.
Build the same agent here All comparisonsWhere the two differ
Their Slack and Notion connectors are deeper than what we ship — Slack reaches Bee Flow through an MCP server rather than a native integration, and if your company thinks in Slack threads and Notion pages, Dust meets it exactly there. The product also moves quickly, with serious backing behind it. If those tools are your centre of gravity and hosting elsewhere is acceptable to your reviewers, Dust is a strong choice and you should evaluate it properly.
Agents, automations, knowledge bases and apps share a single grant-only rights model, with groups synced from Microsoft Entra ID or Nextcloud deciding membership. A workflow that calls an agent leaves one audit trail, not two systems to reconcile afterwards.
Six provider adapters — OpenAI, Anthropic, Google, Google Vertex, Azure OpenAI, Mistral — plus any OpenAI-compatible endpoint, which is how a model on your own GPU joins the list. Chosen per assistant or per conversation, with cost tracked per model.
The workflow engine is in the same building: 27 step types with conditions, loops, parallel branches, approval gates and dry runs, triggered by schedules, webhooks, forms, app events or an agent deciding to call one. An automation can tokenise personal data on the way out and restore it on the way back, using the same privacy layer the chat runs behind.
Sovereignty here is measured, not promised: the usage report resolves each integration and model endpoint to a destination, guardrail events record every privacy decision without copying the sensitive text, and the audit trail is a table in your own database rather than an export you request from a vendor. When somebody accountable asks where the data went, the answer is a report you generate, not a ticket you open.
Once the detector is installed, names, mail addresses and account numbers are tokenised on your own CPU before a prompt leaves for any model provider, and restored in the reply — 21 categories, with Dutch identifiers validated rather than guessed. That is a different posture from trusting a provider’s retention agreement: the provider never receives the customer name in the first place.
Side by side
Their column is drawn from public documentation. Treat their docs as authoritative — this page will age, theirs will not.
| Bee Flow | Dust | |
|---|---|---|
| Deployment | Self-hosted — Docker Compose or Kubernetes — or hosted by us on EU infrastructure | Hosted SaaS; code is public on GitHub — their docs describe the supported path |
| Focus | A workspace: chat, agents, automations, meetings, knowledge, internal apps | Agents and assistants over SaaS connectors |
| Slack and Notion | Via MCP servers — honestly, thinner than theirs | Native, deep connectors |
| Model choice | Six providers plus any OpenAI-compatible endpoint, local models included | Major hosted providers |
| PII handling | On-CPU detector, 21 categories, tokenise before the provider sees it | Provider retention agreements, per their documentation |
| Audit | Audit trail, guardrail log and sovereignty report in your own database | Platform logs, per their documentation |
Questions
Through MCP servers, yes — install the Slack or Notion MCP server and their tools become available to assistants and automations with the same permissions and audit trail as built-in integrations. Native first-party connectors for those two we do not have, and Dust’s are genuinely deeper. If Slack is your company’s operating system, weigh that heavily.
Their code is public on GitHub and their documentation is the authority on what is supported — check there rather than taking a competitor’s word for it. On our side, running Bee Flow yourself is a supported, documented, one-command path on the free tier. That difference is most of this page.
Yes — one grant-only model across chat, agents, automations, knowledge bases and apps, with group sync from Microsoft Entra ID or Nextcloud keeping membership current. The identity page walks the whole chain, including what is deliberately not implemented.
OpenAI, Anthropic, Google, Google Vertex, Azure OpenAI and Mistral through built-in adapters, plus any OpenAI-compatible endpoint — which is how Ollama, vLLM or llama.cpp on your own hardware join the list. The model is a per-assistant or per-conversation choice, and the usage report knows what each one spent.
Source-available, and we would rather be precise than borrow the word. The server and frontend are published under the Sustainable Use License v1.0: read it, modify it, run it internally without paying — what you may not do is resell Bee Flow as your own hosted service. It is not an OSI-approved open-source licence. We are working toward AGPL-3.0-or-later; today the Nextcloud connector is the only part that carries it.
Take one real piece of work — a weekly summary, a support draft, a research brief — and build it in both products. The differences this page describes become concrete within an afternoon.
Try the assistant editor Run the whole stack