Sim vs Dust
Sim is the open-source AI workspace where teams build, deploy, and manage AI agents visually, conversationally, or with code. Here is how Sim compares to Dust on platform architecture, AI capabilities, integrations, pricing, security, and support. Every fact below is sourced and dated.
Sim is an open-source AI workspace for building, deploying, and managing AI agents. This page compares Sim to Dust across platform architecture, AI capabilities, integrations, pricing, security and compliance, observability, and support, using sourced, dated facts for buyers evaluating both platforms.
What is Sim?
Sim is the open-source AI workspace where teams build, deploy, and manage AI agents, connecting 1,000+ integrations and every major LLM to automate real work visually, conversationally, or with code.
What is Dust?
Dust is an enterprise AI agent platform where teams build no-code agents connected to company data and tools in a shared, multiplayer workspace, then deploy them to chat, Slack, and other surfaces.
Sim vs Dust: feature-by-feature comparison
CompareSim vs Dust
Sim
Dust
Platform
Builder type
Visual canvas, chat, or codeVisual drag-and-drop canvas, natural-language (Chat), or code (API/SDK)
Form/instruction-based builder, not a node canvasForm-based, instruction-driven agent builder (name, description, instructions, model, tools, knowledge), not a visual node/flow canvas. Dust's Agent Builder manages agent metadata, model settings, instructions, actions/tools, Skills, triggers, and access permissions through structured form fields and natural-language instructions, guided by an 'Agent Builder Sidekick' conversational assistant. Its earlier visual, block-based orchestration product ('Dust Apps', with Input/Data/LLM/Code/Map/Reduce blocks) is deprecated as of October 2025.
Learning curve
Low, plus natural-language Chat for non-technical usersLow for visual building; natural-language Chat surface for non-technical builders. Chat lets users describe a workflow in plain language and have Sim build it.
Easy for templated agents, steeper for custom tools/SQL/GitOpsLow for simple no-code agents from a template; steeper for custom MCP tool integrations, Query Tables/SQL, and GitOps-managed configurations. Dust markets itself as a no-code agent builder for business users starting from templates with Sidekick guidance, while custom MCP servers, SQL-based Query Tables, and Git-based configuration management assume technical familiarity.
Self-hosting
No: the core repository is MIT-licensed and public on GitHub, but self-hosting isn't an officially supported deployment path. Dust is sold and operated only as hosted SaaS. dust-tt/dust is publicly available and MIT-licensed, but Dust the company documents only its hosted product (with US/EU region choice), not a supported self-managed installation.
Deployment options
Cloud-hosted or self-hosted, no mid-tier VPC optionCloud-hosted (managed, multi-tenant SaaS) or self-hosted (Docker/Kubernetes). No documented managed single-tenant/VPC hosting tier in between. The Enterprise plan's only hosting-related row in the pricing comparison table is a boolean "Self Hosting" flag; there is no dedicated-instance/VPC offering.
Hosted cloud, US/EU regions, single-tenant on EnterpriseMulti-tenant hosted cloud with a choice of US or EU data-hosting region; Enterprise plan adds single-tenant deployment. Dust's Enterprise plan documentation lists 'US & EU data residency options' and 'single-tenant deployment' alongside SSO/SCIM; lower tiers are multi-tenant cloud only.
Templates
Yes: a Template Gallery of pre-built agents organized by department/use case (Sales, Support, Marketing, Engineering, HR, IT operations). Selecting a template opens a Sidekick-guided creation flow pre-loaded with the template's instructions and suggested tools/data sources, which the builder then reviews, adjusts, and publishes.
License
Apache 2.0Apache License 2.0
MIT-licensed code; product sold only as SaaSCore repository MIT-licensed (dust-tt/dust), but commercially offered only as hosted SaaS. The dust-tt/dust GitHub repository, written primarily in TypeScript, is published under the permissive MIT License. The commercial dust.tt product is a proprietary hosted service on top of that code, and no self-hosted licensing tier is offered.
Environment promotion
Yes: fork a whole workspace into a dev/qa/prod-style child, diff it, and promote or roll back changes in either direction. Credential and env-var remapping is required before every promote, so secrets are never silently copied across environments. Gated to Enterprise plan on hosted Sim, or a FORKING_ENABLED flag on self-hosted deployments.
Git-based config sync/rollback, not a formal environment-promotion pipelinePartial: an official GitHub Action version-controls and syncs Skills/agent configurations from a Git repository into a workspace, but this is configuration sync, not a documented dev/test/prod promotion model. The dust-github-action lets teams define Skills and agent configurations as files, review changes via pull request, and sync them into a Dust workspace from CI/CD, giving change history and rollback. No separate-environment (e.g. staging vs. production workspace) promotion pipeline is documented beyond this Git-to-workspace sync.
Version control
Deployment rollback plus Copilot edit diff/revertDeployed-version history with rollback for every workflow; server-persisted checkpoint/revert and visual diff (accept/reject) specifically for Copilot AI edits. Manual drag-and-drop undo/redo is client-side/localStorage only (capped at 100 ops, 5 stacks), not server-synced across devices. Deployment history does not include an arbitrary version-to-version diff tool, and knowledge base documents have no version history.
Versioned configs with prompt history and Git-based rollbackAgent configurations carry an incrementing version number, each prompt/instruction version is saved and recoverable, and Git-based rollback is available via the GitOps GitHub Action; no dedicated visual diff/compare view is documented. Each agent configuration change increments a version number, and 'each version of a prompt is now saved and accessible, with the ability to recover previous assistant instructions'. The GitOps GitHub Action separately provides Git history, PR review, and rollback for configurations managed as code.
Realtime collaboration
No: Dust calls itself 'multiplayer AI', with shared conversations, mentions, notifications, and to-dos between people and agents in a workspace, but this is asynchronous collaboration, not live concurrent editing of the same agent configuration with synced cursors. Dust's own materials describe a shared workspace where 'teams and agents work in the same workspace with shared projects, context, conversations, to-dos, notifications' rather than live co-editing of a single agent's configuration.
Native file storage
Yes: a native Files area with folder hierarchy, link-based sharing (public, password, email OTP, or SSO auth), and a workspace-level Recently Deleted view covering workflows, tables, knowledge bases, files, and folders. Admins can restrict which share-auth modes (public/password/email/SSO) a permission group is allowed to use.
No: Dust has no folder-hierarchy, link-sharing, recycle-bin file manager of its own; files are handled as agent-conversation uploads/outputs or through connected external services (Google Drive, Notion, etc.). Agents can generate, read, and edit files (PDF, Word, Excel, Google Docs/Sheets/Slides) within a conversation or a connected Drive/Notion account, but there is no standalone Dust-native shared-drive surface with folder hierarchy and permissioned link-sharing.
Sub-workflows (composition)
Yes: a "Run agent" tool lets one Dust agent call another saved agent as a step, waiting for it to finish and receiving its output back before continuing. By default the called agent runs in a separate conversation and returns its output to the calling agent, which then continues processing (the calling agent can also enable a handoff mode where the called agent responds directly to the user instead). Recursion is capped at a maximum depth of 4 nested calls.
Pricing
Pricing model
Credit-based billing, BYOK exempt from capsCredit-based usage billing (Stripe), with bring-your-own-key exemption from metered caps
Per-seat pricing with monthly credit allocationsPer-seat subscription with a monthly AI-usage credit allocation per seat. Business plan seats (Pro, Max) each include a monthly credit allocation that resets every billing period; credit consumption depends on the model used, task complexity, and any tools the agent invokes (search, retrieval, code execution, connected-app actions).
Entry paid plan
Pro plan at $25/user/monthPro: $25 per user/month
$30/month per seat (or $24/month annual), 8,000 creditsBusiness Pro: $30/month per seat ($24/month billed yearly), 8,000 credits/month. The Business plan's Pro tier is the entry paid tier above the free plan; a higher Max tier ($150/month, or $120/month billed yearly) includes 40,000 credits/month.
Free tier
Bring your own key
No dedicated BYOK program: Dust bills usage via plan-included AI credits rather than a bring-your-own-provider-API-key option. Pricing is structured around per-seat monthly credits that scale with model/task/tool complexity; no Dust source describes letting a workspace supply its own OpenAI/Anthropic API key in place of credit consumption.
Security & compliance
SOC 2
Yes: SOC 2 Type II certified, achieved audit readiness with Vanta in three weeks. Dust's own security page states SOC 2 Type II certification; a Vanta customer case study describes Dust achieving SOC 2 Type II audit readiness in three weeks using Vanta's automation, reducing compliance workload by roughly 50%. The report is downloadable via Dust's Trust Center.
Data residency
Full control via self-hosting; Cloud region toggle is global, not per-customerFull data control via self-hosting (Docker/Kubernetes); data never leaves customer infrastructure when self-hosted. On Sim Cloud, async job execution has an internal US/EU region toggle, but it is deployment-wide, not a customer-selectable per-workspace residency option
Role-based access control
Yes: three workspace roles (Member, Builder, Admin) plus per-Space access control, where only members of the Spaces an agent uses can see and use that agent. Members can chat with and build agents; Builders additionally manage Folders and use the API; Admins manage workspace settings, connections, and member roles. Spaces (open or restricted) gate which members can see specific data sources, tools, and the agents built on them.
Audit logging
Additional compliance
SOC2SOC2. Self-hosting is the primary lever Sim offers for data-residency-sensitive compliance needs beyond SOC2, rather than additional certifications.
GDPR, HIPAA-capable, SOC 2 Type IIGDPR compliant, HIPAA-capable, SOC 2 Type II. No ISO 27001, PCI, or FedRAMP. Dust's security page and enterprise materials state GDPR compliance and HIPAA-compliance capability alongside SOC 2 Type II. No source confirms ISO 27001, PCI-DSS, or FedRAMP.
Model & tool governance
Yes: enterprise "permission groups" let an admin allow-list/deny-list specific LLM providers and models, and separately deny specific tools/integrations (or disable all MCP or custom tools) per group, layered on top of workspace admin/write/read roles. This does not control whether an LLM provider retains prompts. Sim offers no "zero data retention" mode or governed AI gateway. A separate, Enterprise-gated feature lets orgs set a log-retention window and redact PII, but that only controls how long Sim itself keeps execution logs.
Not publicly documentedNot publicly documented. No Dust source describes admin-configurable restrictions on which LLM providers/models or which specific tools a role may use, beyond Space-level data/tool access and workspace-wide model settings.
Credential governance
Yes: shared credentials (connected accounts, service accounts, workspace secrets) are their own nested permission level (Member/Admin) below organization and workspace roles, and enterprise permission groups can further allow-list specific integrations and restrict which file-share auth modes (public/password/email/SSO) a group may use. A user's personal environment variables/secrets are never shared or inherited by anyone, including org owners/admins.
Space-level connection gating, not per-credential role restrictionPartial: Space-based access control governs which members can use a given connection/data source, but no documented feature restricts which specific stored credential a role may use for the same connector. Only workspace admins can add data from Connections to a Space, and only members of that Space can use the agents/tools built on it; this gates access to a Connection as a whole rather than choosing among multiple stored credentials for the same service by role.
Single sign-on (SSO)
Vetted first-party integrations
Yes: every one of Sim's 302 blocks is first-party authored and code-reviewed through the standard pull-request process in the main Sim repository; there is no public marketplace where an arbitrary third party can publish and have other users install executable tool code without going through Sim's own review. Custom code steps run inside Sim's own isolated-vm sandbox rather than as an installable third-party skill package, so the supply-chain trust boundary is Sim's codebase review, not an open registry.
First-party connectors, open bring-your-own-URL MCP toolsPartial: native data connections (Slack, Notion, GitHub, Salesforce, and 50+ others) are first-party and built/maintained by the Dust team, but agent tools can also be extended with any external MCP server by pasting its public URL, with no Dust-led vetting or review of that server. Docs describe adding a remote MCP server as entering the server's public URL, with workspace admins responsible for choosing and authenticating it. No formal Dust review process is described, unlike the fully managed first-party connectors, and no publicly documented security incident involving a malicious or compromised third-party MCP server on Dust was found.
PII redaction
Not publicly documentedNot publicly documented. No Dust source describes a built-in PII detection/redaction feature for workflow content or retained logs.
Custom data retention
AI capabilities
Multi-LLM support
21 providers incl. OpenAI, Anthropic, Google, Bedrock21 provider integrations (OpenAI, Anthropic, Google/Gemini, Azure OpenAI, Azure Anthropic, Groq, Cerebras, Mistral, xAI, Bedrock, Vertex, Ollama, OpenRouter, and more). apps/sim/providers/models.ts defines 21 provider entries; openrouter/litellm/vllm/ollama resolve models dynamically at runtime rather than from a hardcoded model list.
Yes: agents can be configured with a choice of model (e.g. GPT-5, Claude, Gemini, Mistral) and a creativity/temperature setting, selectable per agent. Advanced agent settings let a builder pick the model and a temperature preset (Creative, Balanced, Factual, Deterministic); marketing materials name GPT-5, Claude, Gemini, and Mistral as selectable models.
Agent reasoning blocks
Yes: agents autonomously select and call tools (data-source search, Query Tables, MCP tools, code execution, web search) based on the instructions and conversation, rather than following a fixed, pre-wired step sequence. Documented as 'multi-tool agents': a single agent can be given multiple tools/actions and picks which to invoke per user turn, distinct from Dust's deprecated block-based Dust Apps, which used a fixed chain of blocks.
Natural-language building
Yes: an 'Agent Builder Sidekick' converses with the builder to draft instructions, and suggests tools/data sources, from a plain-language description or a selected template. Selecting a template opens a Sidekick-guided creation flow; Sidekick drafts initial instructions and suggests tools/data sources for the builder to review and adjust before publishing.
Knowledge base / RAG
Yes: agents can be given Search/RAG access to connected Data Sources (Slack, Notion, Google Drive, Confluence, GitHub, and more), with semantic search over synced content. Dust's Search method retrieves and ranks relevant passages from selected Data Sources for an agent to ground its answer in, distinct from the Query Tables SQL-based tool used for structured data.
MCP support
Yes: admins can add Remote MCP Servers (Dust-built or any public MCP server) to a Space, and Client-Side MCP Servers let a local client register tools for a specific conversation at runtime. Remote MCP Servers are added via Spaces > Tools > Add Tool; Client-Side MCP Servers execute tools in the client's own environment for sensitive local operations, distinct from server-hosted tools.
Evaluation & guardrails
LLM-judge Evaluator plus Guardrails validation blockEvaluator block (LLM-judge scoring against user-defined named metrics) and Guardrails block (JSON validity, regex, RAG/hallucination scoring, PII detection/masking). These are per-call scoring/validation primitives, not a batch golden-dataset eval-suite runner or A/B prompt-testing harness.
No dedicated pre-deployment evaluation/guardrail framework: Dust says it is 'not a pre-deployment evaluation platform', and that dataset-based regression testing belongs in CI/CD pipelines, not a built-in feature. Dust instead builds observability signals (usage trends, tool execution patterns, feedback tracking, latency, RAG behavior) natively into the Agent Builder dashboard rather than a formal test-dataset evaluation suite comparable to a dedicated evals feature.
Human-in-the-loop
Yes: MCP tool execution supports an approval step ('always ask' vs. auto-execute) before a tool call runs, and Dust's own guidance recommends human approval checkpoints before irreversible agent actions. Dust's MCP tool architecture includes an approval-workflow layer for tool execution, and Dust recommends 'mandatory steps, and human approval points before any irreversible action' for consequential agent actions. This is tool-execution approval, not a single named workflow node like a dedicated approval action in a workflow tool.
Generative media
Native image generation with reference images; no native video/audio genPartial: native image generation (via Gemini/Nano Banana) with reference-image consistency and parallel generation is built in; there is no dedicated native video-generation or text-to-speech/speech-to-text block. Dust's Image Generation capability uses an underlying Gemini image model, supports up to 14 reference images for visual consistency across a series, and can run multiple generations in parallel; generated images are filtered for safety. Video and TTS/STT were not found as native Dust capabilities.
Dynamic tool use
No: an Agent block calls tools the workflow author explicitly added to it at build time, rather than browsing and picking from a broader pool (e.g. an entire MCP server catalog) at inference time. Runtime MCP "discovery" exists to resolve/refresh the schema of an already-configured tool. The model does not browse or choose from the server's full tool list.
Yes: a single agent can be configured with multiple tools/actions and dynamically chooses which to invoke per turn based on the conversation, rather than following one pre-wired tool call. Documented as 'multi-tool agents': the agent picks from its configured tool pool (data-source search, Query Tables, MCP tools, code execution, web search) at inference time.
Automatic model fallback
No: a failed or rate-limited LLM call is retried using Sim's own hosted API keys for the same model, rather than automatically switching to a different model or provider. A "fallback" comment in the provider layer refers to rotating among Sim's own hosted API keys for the same model, not switching models.
Not publicly documentedNot publicly documented. No Dust source describes automatic fallback to a different model/provider on a failed or rate-limited call.
Agent skills
Yes: named, reusable "Agent Skills" (built on the open Agent Skills / SKILL.md format) that agents load on demand via progressive disclosure, editable in-app or imported from a SKILL.md file or GitHub URL. Only the skill name and description sit in the agent's system prompt (~50-100 tokens each); the full instructions load into context only when the agent calls load_skill.
Yes: 'Skills' are named, reusable packages of instructions, knowledge, and tools shareable across multiple agents, distinct from a one-off system prompt on a single agent. Updating a Skill's instructions automatically propagates the change to every agent using it. Skills can also be managed as files via the GitOps GitHub Action for version-controlled, PR-reviewed updates.
Native chat deployment
Yes: agents are used and deployed through a native web chat surface and directly inside Slack and Microsoft Teams, without a separate form/API/webhook deployment step. Agents are invoked with an '@handle' in Dust's own chat interface, in Slack, and in Teams; this is the primary interaction surface for the product, not an optional add-on channel.
Parallel execution
Yes: a native Parallel block fans a run out into concurrent branches (fixed count or one per list item) and joins their results back into the workflow automatically. Contained blocks run concurrently instead of sequentially, either a fixed number of times or once per item in a list/collection, and each branch's output aggregates for downstream blocks.
Some tools run concurrently; no general branch/fan-out modelPartial: agents can run multiple tool calls (e.g. several image generations) concurrently within a turn, but Dust has no visual branch/fan-out-and-join execution model since it is not a node-based workflow builder. Documented parallel behavior is scoped to specific tools (e.g. simultaneous image generations for an asset pipeline), not a general-purpose concurrent-branch primitive across an agent run.
Agent2Agent (A2A) protocol
Not publicly documented by DustNot publicly documented. No official Dust documentation describes native Agent2Agent (A2A) protocol support; Dust appears only in third-party community lists of A2A-adjacent tools, not in its own docs or blog.
Loop / iteration block
No: Dust has no dedicated for-each/while loop container; its tools page lists default tools (data visualization, web search, file/image creation, agent memory, run-agent), third-party integrations, remote MCP servers, and Dust Apps, none of which is a loop/iterator block. Dust's agent builder is tool-and-instruction driven rather than a step-sequence canvas, so repeated execution over a list or count relies on the model's own reasoning (or delegating subtasks to sub-agents) rather than an explicit loop container that guarantees sequential per-item iteration.
Integrations
Integrations
302 blocks, ~3,900 tool actions302 first-party blocks, ~3,900 underlying tool actions. Sim's landing page cites "1,000+ integrations," a broader figure counting individual API actions rather than top-level blocks. Both numbers describe the same integration surface.
50+ native connections per Dust50+ native connections (Slack, Notion, Google Drive, Confluence, GitHub, Salesforce, HubSpot, Zendesk, and more), plus MCP servers for further extensibility. Dust's enterprise page states 'native integrations to 50+ business tools'; some third-party listings cite higher figures (100+) that likely include MCP-based and community integrations beyond the core native connector count.
Trigger types
Webhook, cron, chat, REST API, triggers for 61 appsWebhook, schedule/cron, chat, REST API, and event-based triggers for 61 apps (Slack, Gmail, GitHub, Stripe, etc.)
Natural-language schedules plus event-based triggersNatural-language scheduled triggers and event-based triggers from connected systems (e.g. Slack messages), invoked in addition to manual chat invocation. Scheduled triggers run an agent on a recurring, plain-language schedule ('Every weekday at 8:30am') without cron syntax; Dust's Triggers feature separately supports agents reacting to events from external systems rather than only manual chat.
Custom code steps
Val Town serverless functions; legacy Code block is deprecatedPartial: Val Town integration lets an agent create/deploy and call serverless JavaScript/TypeScript functions from a conversation; the legacy Dust Apps Code block is deprecated. The Val Town integration supports function creation and deployment of serverless JS/TS functions directly from agent conversations, with real-time results; the earlier general-purpose Code block belonged to the now-deprecated Dust Apps orchestration product.
API publishing
Yes: a documented Conversation API lets external applications create conversations and post messages to Dust agents programmatically, and a Developer Platform covers broader API access. Client-Side MCP Servers register local tools by creating conversations and posting messages through the Conversation API, which functions as a callable integration surface for external applications.
SDKs & extensibility
Open MIT repo, API, GitHub Action, MCP ecosystemMIT-licensed core repository (dust-tt/dust) on GitHub, a documented Developer Platform/API, an official GitHub Action for GitOps config sync, and community-built MCP bridges. There is no separate first-party multi-language client SDK beyond the API/GitHub Action; extensibility instead centers on the open MIT-licensed codebase, the public API, and the MCP ecosystem, including third-party community projects (e.g. a community-built dust-mcp-server bridge).
Publish as MCP server
Yes: Dust can be exposed as an MCP server so external MCP-compatible clients (e.g. Claude Desktop, Cursor) can call Dust agents and data as tools, in addition to consuming external MCP servers itself. Dust's architecture is described as playing a dual role: a client (consuming external MCP tools) and a server (exposing its own agents/data sources) for external AI tools to call, positioning it as a hub rather than a one-directional MCP consumer.
Observability & durability
Tracing & observability
Yes: execution logs include a per-block/per-span trace view (duration, cost, token counts, and latency stats like TTFT/TPS) with expandable nested iteration groups, plus a "View Snapshot" frozen copy of the workflow structure and block states at run time for debugging. This trace view is built directly into Sim rather than a raw export browsable in an external tool like Jaeger, and does not expose aggregate latency-percentile charts (p50/p95/p99). The run snapshot serves as a log-detail/debugging artifact rather than a resumable mid-run checkpoint.
Yes: an Agent Builder dashboard shows real-time usage trends, tool execution patterns, feedback tracking, latency metrics, and RAG behavior tied to specific agent versions. Described as built natively into the agent-builder workflow with 'zero setup', showing signals specific to how agents work on the Dust platform, rather than a general-purpose distributed-tracing/span export product.
Durability & retries
Tool-call retries (up to 10x); single-attempt job orchestrationIndividual tool/API calls have configurable exponential-backoff retry (up to 10 attempts). The background job-orchestration layer itself retries only once by design. Durability instead comes from consecutive-failure tracking on schedules and the human-in-the-loop snapshot pause/resume mechanism. Sim does not offer guaranteed-once-only block execution, a failed-run holding queue for manual recovery, or a "replay a past execution with its original inputs" feature. The per-execution debugging snapshot serves as a log-detail artifact rather than a resumable mid-run checkpoint.
Not publicly documentedNot publicly documented. No Dust source describes automatic retries, checkpointing, or replay of a past agent run with its original inputs.
Failure alerting
Not publicly documentedNot publicly documented. No Dust source describes proactive alerting when an agent run fails or crosses a cost/latency threshold.
Data drains
Yes: Enterprise orgs can continuously export workflow logs, job logs, or audit logs on a schedule to a customer-owned S3 bucket, GCS bucket, Azure Blob container, BigQuery table, Snowflake table, Datadog logs intake, or an HTTPS webhook. Each drain exports exactly one data source; multiple drains are created to export multiple sources. Viewing drain config/run history is restricted to org owners/admins.
Not publicly documentedNot publicly documented. No Dust source describes continuous export of execution/audit/usage data to an external destination (S3, BigQuery, webhook, etc.).
Async execution
Yes: a workflow can be triggered in fire-and-forget async mode, returning HTTP 202 with a job ID immediately, then polled via a dedicated jobs endpoint through queued/processing/completed/failed states. Async jobs are tracked via polling the job endpoint rather than a completion webhook/callback option.
Yes: scheduled and event-based Triggers run an agent in the background without a synchronous chat request, and results are delivered to a configured destination (e.g. Slack) rather than blocking a caller. Scheduled triggers execute on a recurring cadence (e.g. daily pipeline review posted to Slack every morning); this is inherently asynchronous relative to a live chat turn.
Execution limits
5-50 min sync timeout, 90 min async, 15-300 concurrentPlan-gated: synchronous API calls time out at 5 minutes on the free plan and 50 minutes on paid plans, async calls at 90 minutes on every plan, with 15 to 300 concurrent executions per billing entity depending on plan. These limits are not published in docs; request bodies are separately capped at 10 MB.
Not publicly documentedNot publicly documented. No Dust source publishes concrete numeric limits for maximum single-run duration or concurrent agent-run caps.
Partial-failure handling
Not publicly documentedNot publicly documented. No Dust source describes routing one failing tool call to an error-handling path while the rest of an agent turn continues, versus the whole turn failing.
Support
Support channels
Community support plus Enterprise 'Dedicated Support'Community (open source, GitHub) plus an unquantified "Dedicated Support" flag on the Enterprise plan. Enterprise and pricing pages do not include CSM, onboarding/enablement, or professional-services details beyond a plan-comparison-table "Dedicated Support" flag.
Docs, community forum, changelog, enterprise onboardingDocumentation (docs.dust.tt), a public community (community.dust.tt), a blog/changelog, and enterprise account support; Enterprise plans reference dedicated onboarding. Dust maintains a structured documentation site, a community forum, and a regularly updated changelog; enterprise customers are documented as receiving allocated onboarding/training hours scaled to customer segment.
SLA
Not publicly documentedNot publicly documented. No Dust source publishes a product-specific uptime SLA percentage.
Community
100,000+ buildersOver 100,000 builders use Sim
Active but newer community forum plus AcademyActive: a public community forum (community.dust.tt) and Dust Academy course discussions. community.dust.tt hosts help/support threads (e.g. troubleshooting Table Query tool usage); it is smaller and newer than long-established open-source automation communities.
Academy / training
Yes: Dust Academy (dust.tt/academy) offers structured, hands-on courses on navigating the platform, chaining agent calls, connecting company data, agent actions/integrations, and scheduling agents. Positioned explicitly as handling fundamentals so enterprise implementation teams can focus on customer-specific use cases rather than repeating basic training.
Sim standout features
AI Copilot / Chat agent-building surface
Chat and in-editor Copilot suggest and build workflow changes directly.
A natural-language surface (Chat) and in-editor Copilot that can explain, suggest, and build workflow changes directly, backed by a dedicated copilot module with its own tool registry.Hybrid semantic + keyword knowledge base
Combines vector and full-text search with configurable chunking across 11 file formats.
Built-in RAG with pgvector embeddings and a generated tsvector column for combined vector + full-text search, plus a token-based chunker with configurable chunk size/overlap and 11 supported file formats (csv, doc, docx, html, json, md, pdf, pptx, txt, xlsx, yaml).Native MCP client and server
Call external MCP servers as tools, or expose Sim workflows as an MCP server.
A dedicated MCP block lets any workflow call external MCP servers as a tool, and a serve/workflow-servers API surface lets Sim expose its own workflows as MCP servers.Fork a workspace into dev, qa, and prod environments
Fork, diff, and promote environments with mandatory credential remapping.
Fork a whole workspace into a dev/qa/prod-style child environment, preview a diff, and promote changes bidirectionally. Credential and env-var remapping is required on every promote, so secrets never cross environments silently.Human-in-the-loop approvals with durable resume
Pause a run for human approval and resume later via a durable snapshot link.
A dedicated block pauses a run and waits for a human-submitted approval form, backed by persisted execution snapshots so the run can resume later via a link, even after a server restart.Self-hostable under Apache 2.0
Fully open source with Docker Compose and Helm deployment options.
Fully open source (Apache 2.0), with Docker Compose files and a Helm chart for Kubernetes deployment, alongside a managed cloud-hosted option.Documented Dust limitations
No visual, node-based canvas: agents are configured through forms and text
Agent builder is form/instruction-based; the older visual block builder is deprecated.
Dust's agent builder is a form-based, instruction-driven interface (name, description, instructions, model, tools, knowledge), not a drag-and-drop node/flow canvas. Its earlier block-based visual orchestration product, 'Dust Apps', is deprecated: only apps created before October 2025 remain accessible, and creating new ones is disabled.No dedicated pre-deployment evaluation/dataset-testing framework
Dust says it is not a pre-deployment evaluation platform.
Dust says it is 'not a pre-deployment evaluation platform': dataset-based regression testing belongs in CI/CD pipelines and specialized testing tools, and Dust builds observability signals into the agent-builder workflow instead of a formal eval-suite feature.Self-hosting is not a supported deployment path despite an MIT-licensed core
Code is MIT-licensed on GitHub, but only a hosted SaaS deployment is supported.
The core dust-tt/dust repository is MIT-licensed on GitHub, but Dust is sold and operated only as hosted SaaS. There is no documented, supported way to self-host a production Dust workspace on customer infrastructure.No native spreadsheet-like data table; structured data is queried, not edited
Query Tables runs SQL over external data; there is no native editable data grid.
Dust's Query Tables tool lets an agent generate and run SQL over structured sources (CSVs, Notion databases, Google Sheets, Snowflake, BigQuery), but Dust has no native, editable spreadsheet-grid feature with arrow-key navigation and copy-paste, unlike a dedicated data-table product.Bottom line
Choose Sim if you want an open-source, self-hostable AI workspace that treats AI agents as first-class citizens: native multi-LLM support, real-time multiplayer editing, environment promotion (dev/qa/prod), human-in-the-loop approvals, and enterprise governance (SSO, credential-level permissions, audit logs) built in rather than bolted on.
Choose Dust if you specifically need 'Skills' as reusable, shared agent instruction/tool packages: Skills are named, reusable packages of instructions, knowledge, and tools that can be attached to multiple agents at once. Updating a Skill's instructions automatically propagates the improvement to every agent using it, rather than requiring each agent to be edited individually.
Frequently asked questions
Sim is an open-source AI workspace where teams build, deploy, and manage AI agents visually, conversationally, or with code. Dust is an enterprise AI agent platform where teams build no-code agents connected to company data and tools in a shared, multiplayer workspace, then deploy them to chat, Slack, and other surfaces. Teams considering a switch typically weigh licensing (Sim is Apache 2.0 and self-hostable), pricing model, and how AI-native the platform's agent-building experience is.