Comparisons

Nimbus vs Dust: A Shared Agent Studio or a Place Departments Finish Work?

Dust is a shared studio for building and publishing AI agents; Nimbus is where departments finish a job with a named signer and a lasting record.

Dust is a shared agent studio. Your people write agents in plain language, connect them to Slack, Notion, Google Drive, GitHub, Salesforce, Zendesk and other apps, and pick which AI model each agent should use. Nimbus is the place those drafts have to survive contact with the rest of the company: go-to-market, finance, and ops on one job, with a sign-off and a record of what changed.

Dust’s centre of gravity is the agent itself: create it, share it, run it. Nimbus’s centre of gravity is the job. That is not a slight. Studios are how teams stop trapping a useful helper in one person’s chat history. Jobs are how several departments finish something that still makes sense next quarter. If you buy a studio and expect a ledger, you will be disappointed in the studio. If you buy a work OS and expect a flexible agent workshop as the main experience, you will be disappointed in the OS.

Dust is a French company, and that is part of why European buyers look at it closely. GDPR still applies when agents process personal data in company tools. Teams share agents, so the same helper is not trapped in one person’s history. Admins get company sign-in, roles for who can build or run an agent, and activity logs. Engineers can plug Dust agents into other developer tools. Model choice is real: OpenAI, Anthropic, Google, Mistral and others. Dust’s rollout guide describes that studio as an enterprise AI platform connecting models to internal knowledge, tools, and workflows.

Words you’ll hear

  • Agent studio. A place to build, share, and run custom agents. Dust’s product. Useful. Not the same as a place several departments finish one job.
  • Multiplayer agents. Dust’s term for agents that are not trapped in one person’s chat history. Real. Still primarily shared agents, not a lasting record of what finance approved.
  • Model choice. Dust works with OpenAI, Anthropic, Google, Mistral and others, so you are not locked to one chatbot brand. Nimbus does the same, and treats the choice as an operating decision: do not use the most expensive model for every small task.
  • Workstream. In Nimbus, a shared workspace for one job, with the right people, tools, and approval rules.
  • Wiki. Official playbooks agents must follow.
  • Write-back. Changing a live system. In Nimbus, connectors stay read-only until a named person signs.
  • Lifecycle Graph. The causal record of what the AI did, who approved it, and what changed.
  • CNIL. France’s data-protection authority. Dust is a French company; GDPR still applies when agents process personal data in company tools.

Why the difference matters

Teams can share Dust agents, so the same helper is not trapped in one person’s history. That “multiplayer” claim is fair. Admins get company sign-in, roles for who can build or run an agent, and activity logs. Engineers can plug Dust agents into other developer tools. Dust’s rollout guide is written as a programme: connect models to internal knowledge, tools, and workflows. That is a studio you roll out, not a toy.

Whether finance ever sees a discount field depends on how disciplined you were about who can invoke that agent, and whether anyone filed the run somewhere finance actually looks. Activity logs tell you that an agent ran. They do not automatically become a signed-off version of a CRM change. In Nimbus, go-to-market and finance sit on the same workstream. An agent team drafts against the wiki. Customer records stay read-only until someone who is allowed to approve writes actually does. The Lifecycle Graph keeps the signed-off version, not only the chat that produced it.

Dust searches connected sources and whatever you put in an agent’s knowledge. That works well when the files are clean. It gets fragile when the same fact lives in Slack, a deck, and a CRM field, and nobody is the official owner. If your failure is “the agent answered from an outdated Notion page,” Dust’s freshness and permission model matter most. If your failure is “we ran this last quarter and nobody can find the version finance signed,” you need a record of the job, not another shared agent.

Because Dust is French, the natural data-protection authority is the CNIL. CNIL is clear that GDPR still applies when you develop and run AI that processes personal data, including when those systems later connect to company tools. A shared Salesforce agent is not “just a helper.” It is processing with a purpose. CNIL’s security sheet puts Article 32 in plain language: security of processing is a risk-based obligation. European origin does not exempt you from deciding who may change production data. Dust’s buyers often arrive with that question already on the table — which is healthy.

Model choice is a shared strength. Dust lets you pick a model per agent. Nimbus treats that choice as an operating decision: do not use the most expensive model for every small task. See models. The difference is whether the choice sits on an agent you published, or on a step inside a job with a budget in NTUs (work credits).

The fork is practical by role. A team lead who wants reusable helpers on Slack, Notion, and Drive will feel at home in Dust — publishing an agent is the product. An engineer who wants Dust sitting in the middle of existing tools has a path; that is a hub, not a COO login. Finance cares whether a discount field changed, who signed, and which playbook applied. Legal and a DPO in Europe will read CNIL and still ask purpose, retention, and who can write. Ops eventually wants one canvas for a cross-department job, not a catalogue of agents each team invented.

The hidden cost in Dust is operational: who owns the write policy when an agent can change production data. The hidden cost in Nimbus is adoption: operators must run workstreams, not only chat. Pick the cost you can staff.

When Dust is a better fit

Choose Dust when your job this quarter is “let teams publish reusable agents on our Slack, Notion, and Drive,” you are happy for knowledge to live in those source systems, and you want a flexible studio rather than an opinionated place to finish cross-department work.

Dust is also the better match if you have engineers who want Dust sitting in the middle of your existing tools, and you do not want a workstream-and-record layer yet. It is a strong alternative to ChatGPT Enterprise when you need company context and custom agents you can share — especially in Europe and the mid-market.

Many teams start in an agent studio and later need sign-off, a ledger, and department-shaped work. That is the path Nimbus is built for — not an insult to Dust. You can keep Dust at the edge for engineering-tool agents and put Nimbus on the business jobs that need a sign-off. Coexistence is a policy: Dust agents do not hold production write passwords for money-moving systems; those writes wait in Nimbus.

How this shows up in Nimbus

You are not buying a folder of shared agents. You are buying a place go-to-market can draft, finance can review, and the company can still explain the change six months later.

Connectors are scoped to the workspace and kept read-only until a write is approved. Nimbus publishes 2,000+ integrations; Dust publicly emphasises 70-plus, plus custom developer plug-ins. Count is not the whole story. Dust’s set on Slack, Notion, Drive, GitHub, Salesforce, and Zendesk may be exactly what a studio needs. Nimbus’s catalogue matters when the job spans a longer tail — and when the write path is a release, not an invocation.

You can set this up yourselves. You do not need vendor engineers sitting with your team for months. Dust’s own rollout guide is still a rollout. Run that if you are buying a studio. Do not wait for it to grow a Lifecycle Graph.

See Governance and the Lifecycle Graph.

Questions people actually ask

Can Nimbus replace Dust?

If Dust is a handful of shared agents on Notion and Slack, yes — you move the jobs into workstreams and the playbooks into the wiki. If you have invested heavily in Dust as a hub for engineering tools, keep Dust at the edge and put Nimbus on the business jobs that need a sign-off.

Does Nimbus lock you to one AI vendor?

No. Both products let you choose models. Dust lets you pick a model per agent. Nimbus treats that choice as an operating decision. See models.

Is Dust more “multiplayer” than Nimbus?

Dust coined multiplayer for shared agents, and that is real. Nimbus’s shared surface is the workstream: humans and agent teams across departments on one job, with the Lifecycle Graph as shared memory. Both are multiplayer. Nimbus includes the sign-off and the record.

Dust vs ChatGPT Enterprise vs Nimbus?

Dust is the closer peer: a shared agent studio with connectors. ChatGPT Enterprise is the default assistant plus team-owned agents inside OpenAI’s product. If you are leaving ChatGPT because you need shared, model-choice agents, Dust is the usual next stop. If you are leaving because you need write gates and a ledger, skip the studio. Three products, three centres of gravity: chat, published agent, job.

How should we think about cost?

Dust is typically seats plus usage on a workspace of agents. Nimbus meters the work you run, in NTUs (work credits). Compare a real workload — one programme that updates customer records — not list price per seat. The hidden cost in Dust is operational: who owns the write policy when an agent can change production data. The hidden cost in Nimbus is adoption: operators must run workstreams, not only chat.

Does Dust’s French base make GDPR easier?

It makes the conversation more natural. CNIL’s guidance still applies: GDPR applies when you develop and run AI that processes personal data, and security of processing is a risk-based obligation. Publishing an agent is not a sign-off on the write.

Can we run Dust agents that draft and Nimbus that releases?

Yes. Treat Dust as the place teams publish helpers for knowledge work. Feed anything that must change a live system into a Nimbus workstream. Do not let the published agent hold the write password.

Who should own Dust vs Nimbus?

Platform or IT often owns a studio: who may build, who may run, which models, which connectors. Line operators own Nimbus workstreams because they own the outcome. If engineers want Dust in the middle of developer tools, let them — and keep money-moving writes off that hub.

What is multi-agent AI, What is write-back governance, and Nimbus vs ChatGPT Enterprise.

Sources

See what governed AI looks like on your stack.

Connect your tools, run a workstream, and keep every decision on your ledger - free for 7 days.