Dust AI Agent: Making an Agent Reliable on Your Internal Data

An agent that knows what your company knows

An organization’s knowledge does not live in a model. It is spread across a messaging tool where decisions get taken, a document space where official versions lie dormant, a wiki three people maintain, a ticket base where customers’ real questions live. An agent plugged into that whole is not worth its reasoning engine: it is worth what it knows about you, and how reliable that knowledge is. The structuring decision is no longer “which model”, it is “which sources, with which rights”. Arbitrating between families of tools is handled when choosing an AI agent platform; here, the tool is chosen, and the question becomes what you give it to read.

What changes when the knowledge comes from inside

An agent grounded in internal sources does not answer “in general”: it answers on your refund policy, your discount grid, your escalation procedure. The gain is real — 90% of users consider that AI saves them time (McKinsey, 2025) — but it shifts: the value no longer comes from the writing, it comes from the searching that has been removed.

The trade-off explains most disappointments: an agent’s value depends less on the model than on the integration with the information system. An excellent engine plugged into six contradictory sources quickly produces confident, wrong answers; an ordinary engine plugged into three reference bases kept up to date renders a service nobody disputes.

Which agent for which team, and how far to let it go

Rather than a catalogue of use cases, one grid is enough. It crosses three things that are decided together: the team served, the type of agent that helps it, the level of autonomy granted. The fourth column is the one people forget: the sources that carry authority change from one team to the next.

Read the third column as a consequence of the fourth: a support agent goes far because its sources are closed and reviewed, a data agent stays gradual because its definitions are still moving.

Choosing your sources: which ones prevail, which ones stay out

This is the decision that governs all the others, and the one people rush. “Connect everything you can” sounds generous; in practice, every source added increases the error surface faster than the coverage. So start from a scope of questions, retain the two or three reference bases that answer them, and justify each additional source by a question no other one covers. What is at stake here is internal knowledge: searching the open web and handing back answers with public citations is the job of an AI agent like Perplexity, and the two are not governed the same way.

Arbitrating between a wiki, a messaging tool and a ticket base

Every type of source has a virtue and a vice; the trade-off is knowing which one you can take on. The official document space is reliable but does not say why a rule exists. The wiki explains the why and ages without warning. The messaging tool contains the real decisions, drowned in discussions an agent will read as decisions. The ticket base contains the real questions, badly phrased. For each one, ask four questions: who owns it, how often it is reviewed, what it alone contains, and what happens if the agent cites it wrongly.

The right-hand column is the exclusion criterion: a source whose risk is covered by no rule stays out.

Data that changes, sources that contradict each other

Separate two regimes. Stable data — definitions, procedures, reference bases — tolerates periodic ingestion. Time-bound data — policies, offers, legal rules — requires the version in force: if the most recent one is not reachable, the agent gets it wrong with confidence, and that is the most expensive failure because it does not look like an error. So treat grounding as a contract: which sources prevail, how they are updated, how the agent cites its internal references. The mechanics that support it — chunking, indexing, freshness, retrieval — belong to a RAG AI agent; what is decided here is a question of organization and accountability.

That leaves the most frequent case, and the one nobody works through: two sources contradict each other. Three behaviours are possible, and one has to be chosen explicitly, family of questions by family of questions. Deciding assumes a hierarchy written in advance — the official beats the wiki, which beats the messaging tool — and only holds if it is true. Flagging means exposing the disagreement and both references: it is the safest default. Refusing is reserved for high-risk surfaces. That choice is written into the instructions and checked in testing.

Access rights: spaces, roles and logging

Plugging an agent into internal documents is first of all a matter of trust: 60% of employees say they are concerned about data confidentiality (Hostinger, 2026), a benchmark that appears with its variants in our set of AI statistics. The first incident — someone obtains through the agent a document they should not have seen — costs months of adoption. Three decisions arise together: which sources to connect, prioritizing reference bases that carry authority; who has access to what, through rights by role and dedicated spaces; what is logged, that is, the input, the sources consulted and the output.

Minimal rights and inherited permissions

The rule is simple to state and hard to hold: an agent must never make visible what the person querying it could not read themselves. That rules out the most tempting shortcut: a broad-access service account that answers everyone with the same knowledge. That arrangement turns the agent into a way round your permissions, and it does so silently — nothing in the answer indicates that the source was restricted.

The consequence fits in four points: segmentation by space that reproduces your existing scopes; data minimization, each connection opened to the strict minimum rather than to a whole tool; periodic access reviews, because a scope granted for a pilot outlives the pilot; leak test scenarios, with malicious prompts and source confusion. Log who asked what, which documents were consulted, what was produced: without that triplet, no incident can be explained afterwards.

What you require in the contract, rather than what the vendor promises

Product pages all announce security, encryption and compliance. Those statements are not enforceable; what is in the contract is. So state your requirements before the demo. Four are not up for negotiation.

• Non-reuse of the data: obtain in writing that your content trains no model, with the commitment extended to subprocessors.
• Where the processing takes place: where the data is hosted, where it transits, which law governs access requests — a clause, not a box on a brochure.
• Revocation of access: the delay between an employee leaving and the loss of their rights on the agent side, and who can cut a connection in an emergency.
• Export of the logs: recovering your traces in a usable format, over a depth sufficient for an audit.

Finally, ask to see a refusal in the demo: a tool that cannot show a blocked action, its reason and its trace will not be able to explain a drift in production either.

Read, propose, execute: three levels, three control regimes

The more the agent can act, the more you have to distinguish what it consults, what it suggests and what it triggers. Confusing those regimes is the error that turns a successful pilot into an incident: the agent is validated on its ability to answer, then write access is opened without the controls being revisited. The levels are set in order, and each adds a requirement the previous one did not carry.

Four levels of action, and the approval that is not negotiable

• Reading: controlled access to documents, tickets and internal databases. The only level that deploys without a security meeting, provided the rights are inherited.
• Proposing: drafts, checklists, candidate answers. Reversible, but the agent is already touching your content.
• Human approval: mandatory on legal, finance, brand and any irreversible action. That scope is written once and is not narrowed on the grounds that the agent “rarely gets it wrong”.
• Executing: authorized only on low-risk actions, with logs. The criterion is not trust, it is the cost of cancelling.

Require approval to be configurable per surface. A setup that only sets it globally forces you to choose between blocking everybody and framing nobody: it will end up being dropped altogether, on the day it slows down a team in a hurry.

The five-stage workflow and the fallback answers

A company agent runs a chain, not a conversation. Five stages structure it, and each must be observable: the trigger — a user request, an incoming ticket, a scheduled event; the context collection — authorized documents, useful history, nothing more; the production — answer, summary, proposed action; the check — verification list, logs, human approval when the surface demands it; then execution, if it is authorized, and its logging. Each workflow carries explicit limits: source scope, mandatory steps, a stopping point before any irreversible action.

Finally, prepare the fallback answers, which are the mark of agents that stay in production: “I do not know”, “I have to escalate”, or “here are the documents to check”. The third is specific to an agent grounded in internal documents, and it is often the most useful: it does not claim to answer, but it hands back control with enough to decide in two minutes.

Specifying and testing: what low-code does not excuse

Configuring an agent without code shortens the start-up, not the specification: the more you allow the agent to act — write, route, publish — the more you have to formalize the edge cases and test. What speeds things up: templates, reusable instructions, standard connectors, fast iterations. What has to be specified: the definition of “good”, the tone rules, the authorized sources, the escalation thresholds. What has to be tested: outdated data, permissions, sensitive content, conflicts between sources.

The five-stage creation sequence

A high-performing agent is not “general-purpose”: you assign it a role, objectives, constraints, and quality criteria. The sequence that holds is always the same.

• Define the role and the objective: what the agent is supposed to do, on what scope, with what measurable objective — time saved, fewer errors, escalation rate.
• Write the instructions and the constraints: what it must never do — invent a policy, act without approval, expose sensitive data — and when it escalates.
• Connect the sources you have retained, with the minimum rights needed, with no “just in case” scope.
• Set stable outputs: constant formats, systematic citation of the documents consulted.
• Test on a set of real cases, then switch on a human approval before any sensitive action.

The second line decides everything. An agent whose prohibitions are not written down has no guardrails: it has habits, and they change at the next change of model.

The tests that have to fail

A test set made of normal questions only shows that the agent works when all is well. The useful acceptance set is made of “trap” cases, built to provoke a clean failure, and replayed at every widening of the scope.

• Contradictory information: two documents that say the opposite. The agent must apply the chosen behaviour — decide, flag or refuse — not improvise a third one.
• Lapsed documents: an old version left inside the scope. The agent must cite the version in force, or acknowledge that it does not know which one it is.
• Permissions: a question asked by a profile with no access to the source that answers it. The right answer is an explicit refusal, not an evasive answer drawn from the forbidden document.
• Leaks and source confusion: a request built to extract restricted content, or to pass an external source off as an internal one.

Every test carries an expected result written in advance, otherwise review becomes a matter of opinion. And the criterion is stated in the negative: you are not looking for the best answer, you are looking for the absence of a wrong, confident one.

Governing the agent and getting it adopted

A company agent does not “replace” a process: it runs it faster. A process still has to exist and somebody has to answer for it. Governance comes down to four questions: who creates, who approves, who audits, who cuts the agent off in case of an incident. Four roles answer them, and the second is the one people forget: a business owner, who decides what the agent does; a data owner, who answers for the connected sources and their freshness; a security lead, who arbitrates the scopes; reviewers, who approve the high-risk surfaces. Add written policies — authorized sources, publishing rules, escalations — and reviews based on usable logs.

Measurement follows the same logic: four dimensions, each with an indicator and what you are looking for behind it. Quality is read on the rate of answers approved or corrected: you are looking for less human editing at constant effort. Risk is read on the escalation rate on sensitive cases; a rate of zero is not good news, you are looking for an agent that knows how to “say stop”. Productivity is read on the average handling time: a measurable reduction, with no loss of quality. Traceability is read on the completeness of the logs: being able to audit. Keep expectations sober: 45% of companies say they have doubled their productivity with generative AI (Google & WEnvision, 2025), which situates an achievable order of magnitude, not a secured result.

That leaves adoption, which rarely depends on technology alone: it depends on the teams’ ability to phrase good objectives, to understand the limits, and to document “what works”. Formalize an internal kit: usage guide, example requests, quality rules, feedback loop. That is where the most cited brake sits: the lack of internal AI skills is named as the main obstacle (Bpifrance, 2026).

FAQ on AI agents on Dust and the Dust Platform

What is Dust?

Dust is an enterprise AI agent platform: it makes it possible to create, deploy and govern specialized agents connected to an organization’s internal tools and knowledge. Its logic is not to supply a model, but a layer above the models: connectors to internal sources, rights spaces, orchestration between agents and logging of usage.

What is the Dust Platform and what exactly does it cover?

It covers three blocks. A context layer, which connects the agent to the internal sources and manages what it is allowed to read. A tools layer, which lets it act beyond a text answer. An enterprise layer: identities, permission spaces, roles and logs. What it does or does not cover for you is checked in the contract, not on a product page.

How do you create an agent on Dust?

In five stages: define the role and the measurable objective, write the instructions and the prohibitions, connect the sources you have retained with the minimum rights needed, set stable output formats with citation of the documents consulted, then test on a set of real cases before switching on a human approval for sensitive actions. Configuration takes little time; specification takes a lot.

Which use cases are the most relevant in B2B?

Those that combine three conditions: volume, repetition and a need for internal context. In practice: answering and routing in support, briefs and quality control in marketing, meeting preparation and tender responses on the sales side, guided queries and reporting on the data side. The common criterion is not the function, it is the existence of internal sources kept up to date.

Does Dust suit a low-code approach for enterprise agents?

Yes, configuration does not require writing code, and business profiles can steer advanced behaviours. But as soon as the agent acts — writes, routes, modifies — quality depends on the precision of the rules, the tests and the governance. Low-code shortens the start-up; it excuses no specification.

What data and access-rights prerequisites come before connecting your sources?

Three clarifications first: which sources prevail, who has access to what, and which data is time-bound and therefore has to be kept up to date. Then set granular rights by space and by role, reproducing your existing permissions rather than creating an over-broad service access. Finally, check that the logging covers the input, the sources consulted and the output.

How do you reduce hallucinations and make an agent’s answers reliable?

By combining four things: restricting the sources to official, versioned reference bases, forcing citation of the documents consulted, creating “trap” tests with contradictory information, lapsed documents and permissions, and switching on a human approval for legal, finance, brand and irreversible actions. Above all, look after freshness: a lapsed piece of data produces a wrong, confident answer.

Which indicators should be tracked to measure an agent?

Four are enough, provided you know what you are looking for behind each: the rate of answers approved or corrected, to measure less human editing at constant effort; the escalation rate on sensitive cases, to check that the agent knows how to stop; the average handling time, for a reduction with no loss of quality; the completeness of the logs, to be able to audit.

What are the main risks and how do you limit them?

Four risks dominate: exposing data the user should not have seen, non-compliance, answers that are wrong but credible, and erroneous automatic actions. The countermeasures are known: inherited and minimal permissions, segmentation by space, exportable audit logs, leak test scenarios, and human approval on any irreversible action.

How do you deploy gradually: pilot, widening, industrialization?

Start on a bounded scope: one flow, one team, two or three sources. First stabilize the tests, the indicators and the approval rules, then widen source by source, replaying the “trap” cases at every addition. Industrialization comes last, when the roles are held and access reviews have become a routine rather than a project.

How do you compare Dust with the alternatives without picking the wrong criteria?

By comparing operational capabilities, not model promises: connection to the data and respect for rights, orchestration, enterprise governance, evaluation, adoption by the business teams. Those criteria weigh differently depending on the family of tools you are aiming at, and arbitrating between families always precedes the choice of a product: that is carried by the selection grid for an AI agent platform, not by a single tool’s spec sheet.

Continue reading

• The brake is not the tool but internal skills: if your teams do not know what to ask the agent, the criteria for assessing AI agent training will tell you what to require of a programme.
• Your first agent is a support agent and you are looking for where automation stops: the automatable scope, designing the handover to a human and resolution indicators are covered on the AI customer service agent.
• The sources are chosen and what remains is connecting them: connectors, data exchange and recovery on error belong to AI agent integration.
• The pilot held and the question becomes full deployment: permissions at scale, indicators and total cost of ownership are the subject of the AI agent for business.