Dust

The headline figure is MCP based and outbound: "70+ out-of-the-box MCP connectors," described as putting company understanding into action. That is Dust consuming other systems' tools. The pricing table lists MCP servers (native and remote) on both tiers, capped at 5 remote on Business and unlimited on Enterprise, so the mechanism is a metered entitlement.

Native connections sit alongside the MCP path: Dust says to connect "Slack, Notion, GitHub, Drive + 20 more" or any tool via MCP, with the feature table listing connectors to 20+ data sources, capped at 3 on Business and unlimited on Enterprise. Confluence, Zendesk and Salesforce are named elsewhere on the site. The two track design is the point: twenty odd deeply maintained native connectors for the systems that matter most, and MCP for the long tail.

The agent acts rather than only reads, and the credits FAQ is the clearest evidence because it prices the actions: credit consumption depends on "any tools the agent uses, such as search, data retrieval, code execution, or actions in connected apps." Zapier, Make, n8n and Power Automate, listed on both tiers, extend the reach further.

Permission scoping travels with the connector: integrations are scoped to the Spaces they belong to, so what an agent can reach through a connector is bounded by the customer's own access model rather than a blanket service account. Dust's own inbound APIs are a separate surface, for outside systems calling Dust. No connector directory page is cited, so the 70+ and 20+ figures are the vendor's own rather than enumerated.

Sourcedust.tt/home/product, /home/pricing feature table and credits FAQread 2026-09-12

Multi agent orchestration is a named entitlement by tier rather than a marketing adjective: the pricing feature table lists "multi-agent orchestration and triggers (scheduled + event-driven)" on both plans, and the Business feature list repeats multi agent workflows on schedules and triggers.

The coordination surfaces are named and distinct. Pods are a "persistent shared workspace where humans and agents collaborate around any topic, project, or initiative," with shared conversations, tasks, files and agents in one place. Frames are interactive dashboards and apps agents produce. The product page ties them together: "Orchestrate complex work across digital teams of people and agents using Pods and Frames, powered by a shared virtual computer and automations." A shared execution environment, a shared workspace and automations together make a runtime.

Composability is the stated design: composable workflows that compound with use, executing work with "reusable, governable AI skills, agents, and memory." Skills, agents and memory as separable primitives a customer assembles is a workflow model rather than a fixed pipeline.

The credits FAQ confirms depth from an unexpected angle: "A deep research task that requires complex, multi-step orchestration and tool use will consume more." A vendor pricing multistep orchestration by consumption is describing runs that span many steps and tool calls.

Long running work is assumed, since agents run on schedules and triggers without a person present. Participants are distinct: the people in a Pod, the agents working in parallel, the connected systems each step reads and writes, and the model chosen per agent. No page describes failure handling, retries or what happens when a step in a multi agent run fails.

Sourcedust.tt/home/pricing feature table and /home/productread 2026-09-12

The mechanism is named in the vendor's own documentation: "Retrieval augmented generation (RAG) for accurate, context-aware responses," listed as the first of Dust's advanced technical capabilities.

The corpus is maintained, not assembled per run. Dust maintains its own connectors rather than leaning on a generic integration provider, and "real-time synchronization ensures agents always work with current information." The pricing table sells the retrieval layer as an entitlement in its own right ("search, query and extract across all company data"), and the product page describes putting "a deep understanding of how your company works, through semantic search and 70+ out-of-the-box MCP connectors, into action."

There are two retrieval modes. Semantic search covers unstructured content, and Table Query, described as quantitative analysis tools "to combine semantic search capabilities with SQL to analyze data," covers structured data, so an agent can answer a numeric question from a warehouse and a policy question from a wiki in the same run. The docs state the platform handles structured and unstructured data across multiple sources, and multimodal capabilities including image analysis are named alongside.

Scoping is enforced at retrieval: data is organized into Spaces with configurable access controls, and integrations are scoped to the Spaces they belong to, so what an agent can retrieve is bounded by the asking user's permissions. The named sources are Slack, Notion, Google Drive, Confluence and GitHub, plus twenty odd more natively and anything else over MCP. No page describes chunking, embedding, citation back to a source passage, or a freshness signal on a retrieved answer.

Sourcedocs.dust.tt welcome page with dust.tt/home/product and /home/pricingread 2026-09-12

Dust bounds what an agent can do before it runs, but documents no approval step over the agent's own actions. It describes itself as "governed by design" and sells "reusable, governable AI skills." Three mechanisms sit under that. Access scoping decides what an agent can reach at all: "Control access to data, tools, and systems across teams of people and agents. Use Spaces and Groups to define permissions."

Economic limits cap what it can spend: "Use programmatic rate limits to control automated usage and manage a shared credit pool across teams and workflows," and the credits FAQ adds that Pro and Max users can continue through workspace overage only if enabled by an admin and up to a capped amount. An administrator deciding whether an autonomous agent may keep spending past its allocation is a real hard stop. And Pods put people and agents in the same workspace, so work is visible to colleagues as it happens.

No approval gate over the agent's own action is documented. No review and approve step, confirmation before a write to a connected system, confidence threshold, escalation path, review queue or hold before send appears across the product page, the pricing feature table, the docs welcome page or the security writing. Agents run on schedules and triggers and take actions in connected apps, and nothing published pauses them for a person.

Bounding what an agent may do and capping what it may spend are design time controls, and neither holds an action for a person while the agent runs.

Sourcedust.tt/home/product governance section and /home/pricing credits FAQread 2026-09-12

The pricing feature table names both the certifications and the access controls. SOC 2 Type II covers both Business and Enterprise, GDPR compliance is stated repeatedly, and HIPAA enablement is named in Dust's own security writing. A Trust Center is published at trust.dust.com and a vulnerability disclosure page at dust.tt/home/vulnerability.

Business includes SSO with Okta, Entra ID and JumpCloud (5+ seats, on demand), and both plans use Spaces for data segmentation and permissions. Enterprise adds SCIM provisioning, audit logs and advanced security controls, plus custom data retention and a custom MSA and DPA.

The access model is the product's own shape rather than a bolt on: data is organized into "Spaces with configurable access controls, so admins determine exactly which teams can access which data sources," and integrations with Notion, Slack and Google Drive are scoped to the Spaces they belong to, with Groups alongside to define permissions. For a platform whose premise is agents reading across a company's whole knowledge estate, scoping at the source is the control that decides whether the premise is safe.

Encryption is specified: AES-256 at rest and TLS 1.2+ in transit. The training position is precise and includes a disclosure most vendors omit: prompts, documents and outputs are never used to train models, but "third-party model providers may retain data for up to 30 days for safety and abuse monitoring purposes, after which it is deleted."

SCIM and audit logs are Enterprise only, so a Business buyer has SSO and Spaces but no provisioning or activity trail.

Sourcedust.tt/home/pricing feature table, /blog/what-is-data-sovereignty, /blog/secure-enterprise-software-ai-powered-teams and docs.dust.tt admin guideread 2026-09-12

Dust is strong on cost and usage observability. The product page names AI observability and analytics, to "track and manage AI usage and adoption across the organization with analytics that show how agents and models are being used over time," and pairs it with economics for each workflow: "usage analytics by agent and model show what each workflow costs."

The pricing table lists usage analytics and adoption reporting on both tiers, and the credits FAQ says customers will be able to track credit usage to understand how different workflows consume credits. Attribution down to the individual agent and the individual model is fine grained.

A security trail exists at Enterprise: audit logs and advanced security controls, described as "use Spaces and Groups to define permissions, with audit logs to track activity." That sits inside the access control section, so what it records is who reached what, an access trail rather than a record of agent execution. Audit logs are Enterprise only, so a Business buyer has usage analytics and no activity trail.

No run log, execution trace, step by step record of what an agent did, replay, or export of agent activity is described anywhere across the product page, the pricing table, the docs welcome page or the security writing. A buyer can see that an agent ran, which model it used and what it cost, and cannot see what it did.

For a platform selling multi agent workflows that fire on schedules and triggers and take actions in connected apps, reconstructing which action hit which system is the question that follows the first incident, and it is unanswered. With no published way to test agent behavior beforehand either, output quality cannot be verified from outside in either direction.

Sourcedust.tt/home/product, /home/pricing feature table and credits FAQread 2026-09-12

Memory is a named primitive here: the product page sells "composable workflows that compound with use," executing work "using reusable, governable AI skills, agents, and memory that compound with use." Measured against memory the agent writes and the customer governs, it meets some conditions and not others.

Agent written state is only partly present. Self improving skills, "skills that get smarter with every use... without any manual effort," are learning absorbed into the product rather than a store. What Pods retain is shared conversations, tasks, files and agents: conversation history and human artifacts, partly produced by agents, in a collaboration workspace rather than state the agent keeps about its own operation.

Scoping is met at two levels: Pods scope to a topic, project or initiative, and Spaces scope data with configurable access controls.

A lifetime is published only at Enterprise. Custom data retention is an Enterprise entitlement, and the sovereignty post states "a minimum conversation retention period applies to support your workspace history." A minimum is a floor rather than a purge path, and administered retention is not available to a Business buyer.

No write surface over retained state is documented. The Conversation API and Data Source API exist and are plausibly write capable, but no page states that an outside caller can inspect, correct or delete what the platform has retained about a run. So retained state is scoped through Pods and Spaces, can be inspected as shared conversation history and can expire at Enterprise, but what it holds is a shared workspace and a learning process rather than a documented store of run state a buyer can address.

Sourcedust.tt/home/product, /home/pricing feature table and /blog/what-is-data-sovereigntyread 2026-09-12

Dust clears this bar three separate ways. A named region list on every tier: the pricing feature table lists data residency as US / EU for Business and Enterprise alike, and the Business plan's headline feature list repeats US and EU data residency, so a self serve buyer at €24 a seat gets the choice. A named customer environment option: single tenant deployment is listed on Enterprise. And an open source path: the site footer links a public repository at github.com/dust-tt/dust under Developers, so the platform itself is inspectable, though self hosting is claimed rather than documented.

The residency position is argued, not merely listed. Dust publishes a long piece distinguishing sovereignty, residency and localization, states that "Dust offers EU-hosted infrastructure, meaning your data is stored on servers located within the European Union, with model inference routed to EU regions where available," and concedes the limit of the category: "a European data center operated by a US-based company can still be compelled to hand over data to American authorities." Dust is Paris based, so the CLOUD Act argument runs in its favor, and it makes it explicitly.

Inference residency is addressed separately from storage residency: model inference is routed to EU regions where available, with Mistral named as the European provider option. Where available means not all models.

A named customer, Ardabelle, is described choosing Dust on EU hosting and GDPR grounds for private equity deal documents. No page names which EU region is used.

Sourcedust.tt/blog/what-is-data-sovereignty and /home/pricing feature tableread 2026-09-12

What is documented is a gallery of the customer's own agents, not a pack the vendor ships. The docs describe Dust as a "builder-centric platform" that "supports a community of internal builders who create custom AI agents" and "provides a gallery for discovery and sidekick-guided creation for quick deployment." The units in that gallery are the ones the customer's own builders made; discovery across colleagues' agents is a collaboration feature, and on an empty workspace the gallery is empty.

What supports Partial is the reusable unit layer. The product page names "reusable, governable AI skills" as a primitive alongside agents and memory, sold as composable workflows that compound with use, and the pricing table lists custom agents with skills, knowledge and tools on every tier. A named, reusable skill that does work when selected counts.

Frames adds a second unit class (interactive dashboards and apps, standard on Business and white labeled on Enterprise), and Pods a third, collaborative workspaces with shared context. Sidekick guided creation implies a guided start, but no template library is documented on the pages cited.

It is not None because skills and Frames are shipped, named, reusable primitives; it is not Full because nothing published shows a catalog the vendor supplies for a customer to select from before building anything.

Sourcedocs.dust.tt welcome page with dust.tt/home/product and /home/pricingread 2026-09-12

Both trigger classes are named in one line on the pricing feature table, "multi-agent orchestration and triggers (scheduled + event-driven)," listed on Business and Enterprise alike. The Business headline list repeats multi agent workflows on schedules and triggers, and the product page names automations as one of the mechanisms powering Pods and Frames.

The event side is architecturally real. Dust maintains its own connectors with real time synchronization, so a change in Notion, Slack or GitHub propagates rather than waiting for a poll, and an agent triggered on that change is reacting to the customer's own systems.

Channel coverage is wide, and each surface is named first party: the Dust workspace itself, including Pods as a shared surface where people and agents work in parallel; a Chrome extension with its own product page, bringing "Dust agents right in the tools you work in"; Slack, Notion, GitHub and Drive as connected surfaces; and four automation platforms listed as a tier entitlement (Zapier, Make, n8n and Power Automate), which are themselves trigger sources, letting a customer start a Dust agent from anything those platforms can see. Events, schedules and multiple channels are all documented, and none is gated to Enterprise.

No page lists which event types are available per connector, or whether a customer can define compound conditions, and the word automations appears without elaboration on the product page.

Sourcedust.tt/home/pricing feature table, /home/product and docs.dust.tt welcome pageread 2026-09-12

Customer selection is explicit and not gated by plan. Dust offers "20+ frontier models" across GPT, Claude, Gemini, Mistral and DeepSeek, and the pricing FAQ states it flatly: "All plans include access to 20+ models from OpenAI, Anthropic, Google, Mistral, and DeepSeek. You choose the model per agent.

No model is locked behind a higher plan, though higher-capability models may consume more credits per message." Letting the customer choose per agent, with no plan gating, is unusual. The product page repeats it as model flexibility without lock in, letting a team "choose the right model for each workflow and switch as your needs change."

Five providers are named, including open source and a European option, and the sovereignty post makes the last a deliberate position: Dust "supports multiple model providers, including Mistral AI, a French-founded company," and for workloads requiring European jurisdiction provides EU hosted infrastructure with model inference available in EU regions.

Model choice is sold as a sovereignty control as well as a quality one, a way to "protect your company's data from vendor lock-in and geopolitical risk by controlling where it is processed and which model providers you rely on." The docs also state model agnosticism as a core differentiator.

The cost surface is attached to the choice: usage analytics report by agent and by model, so a buyer can see what each model costs per workflow and switch on that evidence.

Dust's MCP connectors (outbound) and its Conversation and Data Source APIs (inbound) are separate from model routing.

Sourcedust.tt/home/pricing model list and FAQ, /home/product, and /blog/what-is-data-sovereigntyread 2026-09-12

Dust publishes a documented API for its own platform, listed as an entitlement by tier: a Conversation API on Business, plus a Data Source API on Enterprise. One drives conversations with agents from outside; the other writes into the knowledge layer.

A documentation host with machine readable specs backs it. docs.dust.tt is linked in the site footer as Platform Documentation, and it advertises an llms.txt index of every page in Markdown with endpoints in OpenAPI. An OpenAPI specification is the artifact a builder needs.

Three further surfaces are published: a public repository at github.com/dust-tt/dust, linked from the footer; a developer platform at dust.tt/home/solutions/dust-platform, with Dust Apps described in the docs as an "extensible platform... for custom integration and LLM orchestration" and an "API-first architecture"; and a metered programmatic path with a published rate, $0.01 per credit on Business and custom on Enterprise. A vendor pricing its own API by the unit expects outside callers.

Automation platforms are listed separately on both tiers (Zapier, Make, n8n and Power Automate), plus a Chrome extension bringing agents into other tools. The MCP servers and 70+ MCP connectors run the other way, letting Dust call other systems' tools, while the Conversation and Data Source APIs are how outside systems reach Dust. No endpoint reference or SDK page is cited, and the OpenAPI specification is advertised rather than quoted.

Sourcedust.tt/home/pricing developer tools table, docs.dust.tt welcome page and site footerread 2026-09-12

Nothing puts a change under test. No sandbox, staging workspace, dry run, agent preview, holdout, A/B comparison, versioning or rollback of an agent configuration, evaluator, scored verdict or regression surface appears across the product page, the pricing page and its full feature comparison table, the docs welcome page, or the sovereignty and security posts. The pricing table lists entitlements line by line down to support tier and programmatic rate, which is where a test or evaluation feature would appear if one shipped.

Two near misses pull in opposite directions. Self improving skills, "skills that get smarter with every use. As your team runs agents, the system learns and improves, compounding your organization's intelligence over time without any manual effort," are learning absorbed into the product: an agent that improves is not an agent under test, and without any manual effort says no one inspects the change. Usage analytics and adoption reporting show how agents and models are used over time and what each workflow costs, but they measure consumption and adoption, not output quality.

The gap matters on this platform because Dust sells composable multi agent workflows on schedules and triggers, running unattended against connected systems, with credit consumption rising for deep research and tool heavy orchestration. A buyer can see exactly what an agent cost and has no published way to see whether it was correct, and no run trace to reconstruct it afterward.

Sourcedust.tt/home/product and /home/pricing feature tableread 2026-09-12

Three features could look like computer use, and none is. The product page states that Pods and Frames are "powered by a shared virtual computer and automations." What is described is a shared execution environment in which agents run code and produce artifacts, not an environment in which an agent operates a graphical interface. The credits FAQ confirms the shape by pricing it: credit consumption depends on tools such as search, data retrieval, code execution or actions in connected apps. Code execution is billed as a tool; interface control is not billed because it is not offered.

Code execution itself is compute, not interface operation. And the Chrome extension, which has its own product page, brings "Dust agents right in the tools you work in": a surface through which a person reaches Dust while browsing, the opposite direction from an agent driving a browser.

Every path in is a maintained connector, an MCP server or an API, and every path out is a connector write or an API call, so a third party redesigning its interface does not touch any of it; Dust's architectural argument is that it maintains typed connectors rather than scraping.

No hosted or local browser session, desktop control, remote computer control, RPA, recorder or extension that acts on a page on the agent's behalf appears across the product page, the pricing feature table, the docs welcome page or the security and sovereignty posts. The phrase shared virtual computer is ambiguous, and the documentation is where its limits would be stated.

Sourcedust.tt/home/product, /home/pricing credits FAQ and /home/chrome-extensionread 2026-09-12