Dust gives teams shared agents, knowledge and working spaces

Dust is a collaborative AI platform where teams build and use agents with company knowledge, connected tools and reusable skills. Its current product includes shared Pods for conversations, tasks and files, alongside access controls and a credit-based commercial model. The useful question is whether a team can turn individual AI assistance into maintained procedures and shared work that colleagues can understand and continue.

01 / ProductWhat Dust provides

The product overview¹ describes a multi-model workspace that brings people, agents, knowledge and tools together. Agents can retrieve connected company material and use external tools; shared skills package recurring expertise. This is broader than a personal chat subscription because the surrounding workspace holds the team’s process and collaborative context.

A Pod³ groups conversations, tasks and files around a goal. Agents can participate through tools that read and write those resources. Pods can be open to the organization or restricted to invited members. A customer project, product launch or ongoing operational initiative can therefore have a shared working area rather than a collection of isolated chats.

For a buyer, it helps to separate the containers. A Pod organizes collaboration around a project. Spaces govern access to resources. A connected tool uses either shared or personal credentials. Those concepts interact, but they are not interchangeable: putting a conversation in the right Pod does not by itself establish which account an external action will use.

02 / AudienceThe teams likely to benefit

Dust is a plausible fit for cross-functional teams whose work depends on knowledge spread across several systems. Customer onboarding, product operations and account preparation often require an employee to read documents, inspect records and produce an output others must use. A shared agent becomes valuable when the process repeats and the organization wants the learning to survive beyond one person’s chat history.

The strongest starting point has a clear shared deliverable. For onboarding, that might be a launch-readiness brief containing the agreed scope, outstanding dependencies and named owners. If no one can explain what makes the brief complete, connecting more sources will mainly produce a larger body of context for the agent to interpret.

The Glean blueprint is a useful comparison when finding and understanding company information is the central problem. Dust’s Pods and skills invite a broader discussion about doing collaborative work with that information. Compare the specific retrieval, permission and action requirements instead of treating all enterprise AI workspaces as equivalent.

03 / WorkflowA proposed customer onboarding workspace

Imagine a software company coordinating onboarding across sales, implementation and support. The proposed Dust setup should produce a shared readiness brief, track open tasks and prepare updates for the project owner. It should distinguish an agreed customer commitment from an internal target.

Start with the project’s evidence

Create a restricted Pod for the onboarding effort, with the project description, approved scope and relevant working files. Link the authoritative company material through the supported data layer rather than copying every document into a new format. The Pod should help the team find the current work, while the underlying contract or implementation plan remains clearly identified as its source.

Define a small output: scope, target date, outstanding dependencies, owners and unresolved decisions. Ask the agent to name the basis for each item. If the sales handover says “expected in June” but the implementation plan contains no committed date, the brief should preserve that distinction. A single polished timeline can be misleading if it blends aspiration and agreement.

Package the readiness procedure as a skill

The skills documentation⁴ describes reusable bundles of instructions, knowledge and tools. Updates apply to agents using the skill, and skills can reference other skills. Builders and admins create them, while resource access depends on the required Spaces. A skill is therefore both reusable process knowledge and a dependency on particular resources.

For this example, define how to identify a blocker, what evidence confirms completion and how to handle contradictory dates. Keep the skill focused on readiness rather than combining every possible customer-success task. If another team uses the same skill for a different product, the mandatory fields should remain consistent while product-specific material is attached explicitly.

A change to the skill can improve several agents at once, but it can also change their behavior together. Review a normal onboarding, a delayed integration and an account with an unapproved scope change before making a shared update. The meaningful test is whether the procedure handles those distinctions, not whether the prose sounds more confident.

Design access using Spaces and credentials

The access-control guide⁵ describes administrator-selected data scope and open or restricted Spaces. Users can create and interact with agents based on the Spaces they can access. For onboarding, separate broadly useful implementation guidance from customer-specific commercial material, then give the working team access to the resources it needs.

The credential guide⁶ adds a second distinction. Shared credentials mean users with access to a tool act through the same external account. Personal credentials mean each user authenticates individually after administrator setup. This is material when an agent reads CRM records or creates a task: the external service’s account permissions and attribution still matter.

For the proposed workflow, make the connected identity visible during setup and verify the resulting record in the destination system. A task created with a shared service account should not be described as personally created by the project owner. Choose the credential model because it matches the operating process, not simply because one option makes onboarding shorter.

Turn the brief into maintained work

Ask the agent to prepare a readiness brief and propose tasks for unresolved dependencies. The project owner should review the proposed tasks before using them as the shared plan. A dependency such as “customer supplies identity-provider metadata” should retain the customer owner and the agreed deadline; it should not become an internal engineering task merely because the integration team reads the Pod.

The shared workspace is useful when a colleague can continue the work without reconstructing the preceding conversation. Keep the latest accepted brief easy to identify, retain the basis for changed conclusions and close obsolete tasks deliberately. An agent-generated file is a working artifact until someone has accepted its interpretation of the project state.

04 / PricingDust pricing and seat credits

The current pricing page² allows Business workspaces to mix Free, Pro and Max seats. Free has a lifetime allowance rather than a monthly renewal. Paid seat allocations reset monthly without rollover; administrators can enable capped overage. Enterprise offers negotiated usage and administration arrangements. The table shows euro prices excluding VAT.

The credits guide⁷ separates token consumption from action credits. Tool actions have different tiers, and sub-agent consumption contributes to the overall result. An interaction can therefore cost more because it reads a long context, uses a more capable model, calls several tools or delegates work. A message count alone is a poor predictor.

For illustration, ten Pro seats at the annual-billing rate represent €240 per month equivalent before VAT. That does not mean every member can use a common pool of all ten allowances under every arrangement. Business seat credits are individually allocated; the public offer describes workspace pooling as an Enterprise feature. Confirm how automation and overage draw from the specific workspace configuration.

A useful pilot compares accepted readiness briefs and maintained tasks with total consumption and review effort. A complex onboarding may justify more research than a routine one. The objective is not to make every response equally cheap; it is to understand which work creates useful shared output and which repeatedly consumes credits without resolving the project’s uncertainty.

05 / DistinctionsWhat distinguishes Dust’s shared working model

The most interesting feature is the combination of knowledge access with a place where people and agents can continue working together. A retrieved answer helps one moment; a maintained Pod can hold the discussion, accepted files and next tasks around a longer-running project. That can reduce the need to explain the same context repeatedly across separate chats.

Reusable skills make another difference. A team can formalize its approach to onboarding readiness and use it across several agents, rather than copying a large instruction block into each one. The value comes from maintaining the procedure and its dependencies. A skill that accurately reflects an obsolete process will spread the wrong convention efficiently.

The Gumloop blueprint offers a relevant adjacent comparison for agents carrying out work across business applications. Compare where the ongoing collaboration happens, how reusable procedures are maintained and how the connected account is controlled. A product that feels effective for one employee’s recurring task may need a different operating model when several departments share the output.

06 / QuestionsQuestions to resolve before a broad rollout

Does shared context preserve the right distinctions?

Give the agent a sales handover, an implementation plan and a support note that disagree about readiness. Ask for the conflict to be explained with its sources. The desired result is a clear unresolved decision, not a compromise sentence that hides the disagreement. If the team cannot trace the conclusion quickly, the shared workspace has not yet made the evidence easier to use.

Who can change the process and its access requirements?

A shared skill can depend on several Spaces. Changing those dependencies can affect which agents can use it. Review who owns the skill, who can edit it and which users should retain access after a team change. Treat a new connection or a broader data scope as a functional change to the agent, even when its main instructions remain identical.

Can the team distinguish a proposal from an accepted update?

The Pod gives agents tools to create and complete work items. Decide what evidence should establish that an onboarding dependency is actually complete. A customer’s promise to send a file is not the file’s arrival, and a drafted update is not a sent message. Use explicit output wording and destination records so the project owner can recognize what happened.

Which work should use a heavier model or sub-agent?

Dust supports model choice, but a more capable model is not automatically necessary for every task. Compare a routine status digest with a complex scope reconciliation. The second may benefit from more reasoning or isolated research, while the first may need a concise, stable procedure. Review the actual credit detail alongside usefulness rather than assigning the most expensive configuration globally.

07 / DecisionDeciding whether Dust fits the organization

Dust is worth evaluating when the goal is shared, reusable AI work across a team’s knowledge and applications. Start with a restricted project, a focused skill and a deliverable whose quality the owner can assess. Confirm the access model and the identity behind each connected action before inviting a wider group.

The platform’s value grows when colleagues can reuse the procedure and continue from an accepted artifact. If the real need is simply finding a document or assisting one person in an isolated task, compare the more focused alternatives. Choose Dust when the collaborative workspace and maintained shared expertise materially improve how the team finishes the work.