Dust.tt: How to Build Your First AI Agent Step by Step

Dust describes itself as a platform for creating customizable and secure AI agents powered by leading large language models, sitting on top of the tools your company already uses. That is a fair description of what you get. The part people underestimate is that an agent is something you design, not something you switch on.

This guide walks the whole build once, in order, so you finish with an agent your colleagues can actually call. It assumes you already have a Dust workspace and can log in. Everything here comes from Dust's own documentation, and anything their docs do not state plainly is flagged rather than guessed.

Before you touch the builder, write one sentence describing the job. Something like "answer support questions about our billing policy using the help centre" is a job. "Be helpful to the team" is not, and it produces an agent that is vague at everything.

What do you need before you start?

You need a Dust workspace, a clear task for the agent, and access to whichever data it should read. That last one matters more than people expect, because in Dust an agent can only draw on data you can already reach.

Dust's access model runs through roles and spaces. Their documentation describes three roles: members, who interact with agents; builders, who can create agents from the data in spaces they belong to; and admins, who manage workspace settings, connections, member roles, and subscriptions.

• A role that can build. Dust's docs state that users create agents based on the data of the spaces they have access to, so builder or admin access is what you want here.
• Data already connected. Connections are managed by workspace admins. If the knowledge you need is not synced yet, ask an admin first, because you cannot select what has not been added.
• One narrow job. Dust's own guidance notes that the more data an agent has access to, the lower the chance it retrieves the right information. Narrow beats broad.

How do you open the agent builder in Dust?

Click Create from the Dust homepage. You can start fresh or begin from a template, and Dust opens Sidekick alongside the builder to help you draft instructions and configuration as you go.

The builder is a set of areas rather than a wizard, so you can move between them freely and come back. In practice you will spend most of your time in two of them: the instructions and the knowledge and tools selection. The rest is naming, sharing, and optional automation.

What goes in the instructions?

Instructions are where you define the agent's behaviour in plain language. Dust's documentation frames them as the core of the agent, covering its role, the process it should follow, the tone it uses, the output format, and the constraints it must respect.

Write them the way you would brief a new hire on their first morning. Say who they are helping, what to do when the answer is not in the knowledge base, and what the finished output should look like. Sidekick can draft a first pass and refine it inline, which is genuinely useful for getting past a blank field.

Expect to rewrite this several times. Dust's docs are honest that agents usually need a few iterations on the instructions or the tools before they behave the way you want, and that is normal rather than a sign you did something wrong.

How do you give the agent knowledge and tools?

You pick a space, then choose which connected data inside it the agent may read. Dust's quickstart walks through selecting a space such as Company Data, choosing a connected source such as Notion, then narrowing to the specific data sources you want.

There is one step here people skip and later regret. Dust asks you to add descriptions so the agent understands when to use each tool or source, and a vague description is the usual reason an agent reaches for the wrong thing.

Build your first agent in Dust

1. Click Create from the homepage — Start from scratch or from a template. Sidekick opens beside the builder to help draft the configuration.
2. Write the instructions — Define the role, the process to follow, the tone, the output format, and the constraints. Iterate with Sidekick until the preview behaves.
3. Attach knowledge and tools — Choose a space, choose the connected data inside it, then select the specific sources. Add a description for each so the agent knows when to use it.
4. Test in the preview area — Dust puts a preview next to the builder. Ask the questions your colleagues will actually ask, not the ones you know it can answer.
5. Fill in the settings — Set the handle people will @mention, write a description of what the agent does, and add tags. Dust offers a Suggest option for tags.
6. Choose editors and publish — Add anyone who should be able to edit it in the Editors section, then publish it so the workspace can use it. Unpublished agents stay visible to you and the other editors only.

If that reads like a fair amount of design work for one agent, it is. You are choosing the data, writing the behaviour, describing each tool, and then tuning all three until the answers hold up. Teams that enjoy that level of control get a lot out of Dust, and the platform rewards the effort with agents that are genuinely grounded in company knowledge.

Setup work like this is exactly what we removed at Sistava. Instead of configuring an agent, you hire an AI Employee that already has a role and its tools connected, then tell it in plain English what you want handled. It asks when it is unsure and sets itself up, so there is no configuration to maintain later.

Back to the build. Once the agent answers reasonably in the preview, the next question is almost always about models, because the default is doing more work than most people realise. Dust keeps this setting deliberately out of the way so that non-technical users are not forced to have an opinion on it.

Which model should you pick for a Dust agent?

Start with an auto model and leave it on the standard setting unless you have a specific reason to change it. That is Dust's own recommendation in their documentation, and it is good advice for a first agent.

The setting lives under Advanced, in the model selection area, where you can also adjust reasoning effort. Auto models let Dust route to a suitable model for the work, while picking a specific model pins the agent to one exact model.

The case for pinning is repeatability. Dust's docs give the example of needing a guarantee that the agent always runs on one exact model, for instance to reproduce a known output. If you are not chasing that, auto is the lower maintenance choice, because you are not left behind when models improve.

How do you test, publish, and then call the agent?

Test in the preview area next to the builder, publish when it holds up, then call the agent by starting a message with an @ sign followed by its handle. In Slack, Dust's documentation shows the form @dust followed by a plus sign and the agent name.

Test with real questions, including the awkward ones. The useful test is not whether the agent answers a question you designed it for, it is what it does with a question that sits just outside its knowledge, because that is where a confident wrong answer costs you trust.

Publishing is a visibility decision, not a permission override. A published agent is visible and usable across the workspace, but only for people who can reach the data sources it uses, and an unpublished agent stays visible to you and its other editors.

Plan for maintenance too. An agent is a small internal product: the knowledge behind it moves, the instructions drift out of date, and somebody has to own it. That ownership question is the one that decides whether you end up with three agents that work or thirty that nobody trusts.

It is also the reason we took a different route. A Sistava AI Employee is briefed rather than built, so when the work changes you correct it in conversation the way you would coach a junior colleague, instead of reopening a builder and editing a configuration.

Whichever route you take, the discipline is the same. One clear job, the smallest set of knowledge that job needs, and a real test with the questions your team actually asks. Agents fail far more often from vague scope than from the wrong model.

Sources

• Dust documentation, Create your first agent
• Dust documentation, Managing Agents
• Dust documentation, What settings and model should I use?
• Dust documentation, Access Controls and Permissions
• Dust documentation, Spaces management
• Dust documentation, Intro to Dust

Build one agent properly before you build five. A single narrow agent that your team trusts is worth more than a shelf of half-configured ones, and the lessons from the first build carry straight into the next.