Building a Horizontal Enterprise Agent Platform with Infrastructure-First Approach

dust.tt · Tech · 2024 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Enterprise agent infrastructure

Dust needed to make LLM agents useful across whole companies, not just for developers or one vertical workflow, by giving non-technical teams access to data, tools, models, and safe product surfaces for creating simple operational agents.

Constraints:

• horizontal adoption requires many internal integrations and data types rather than one prescribed workflow
• non-technical users need approachable terminology and defaults
• model-driven tool selection is unreliable when agents receive broad instructions and too many tools
• enterprise data sources require API-first access, structure-aware chunking, and ongoing connector maintenance
• agent quality is hard to evaluate from traces alone because user satisfaction is ambiguous

Architecture

Dust evolved into a horizontal enterprise agent platform. Its core architecture combines owned connectors to systems such as Notion, Slack, GitHub, and Salesforce-like data, API-first tool execution, a model-agnostic gateway with sane defaults, a builder interface that frames prompts as instructions, and Temporal-backed background workflows that keep connected company data fresh and trigger agents when relevant information changes.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  company-saas-apis[Company SaaS APIs] --> dust-connector-layer[Dust connector layer]
  dust-connector-layer --> agent-context-layer[Agent context layer]
  agent-context-layer --> agent-builder[Agent builder]
  agent-builder --> model-gateway[Model gateway]
  agent-builder --> tool-execution-layer[Tool execution layer]
  model-gateway --> tool-execution-layer
  tool-execution-layer --> company-saas-apis
  temporal-workflows[Temporal workflows] --> dust-connector-layer
  temporal-workflows --> tool-execution-layer
  tool-execution-layer --> end-user-feedback-loop[End-user feedback loop]
  end-user-feedback-loop --> agent-builder

Components

Data flow

Company data flows through Dust-maintained connectors into a model-oriented context layer that preserves source-specific structure. Users create simple instruction-defined agents with tools such as semantic search, structured database querying, web search, and actions. Runtime requests use model defaults or advanced model selection, call tools through APIs when available, and rely on Temporal to ingest updates from Slack, Notion, GitHub, and other systems in semi-real time so agents can alert users or prepare artifacts.

Why this architecture

Dust chose platform infrastructure because horizontal enterprise agents need access to company-specific data and actions before model cleverness matters. Owned integrations let Dust preserve the structure needed for LLM context, API-first execution avoids brittle RPA where APIs exist, and simple instruction-defined agents fit current model capabilities better than broad AutoGPT-style autonomy.

Models used: GPT-4 · GPT-4 Turbo · GPT-4o · Claude 3.5 Sonnet · frontier model providers through a unified interface

Scale

• Dust reports up to 88% daily active users across an entire customer deployment.
  “The highest penetration we have is 88% daily active users within the entire employee of the company. The kind of average penetration and activation we have in our current enterprise customers is something like more like 60% to 70% weekly active.”article, stated
• Average enterprise adoption is around 60% to 70% weekly active users.
  “The kind of average penetration and activation we have in our current enterprise customers is something like more like 60% to 70% weekly active.”article, stated
• Dust targets scale-up companies with roughly 500 to 5,000 employees.
  “I think for most of the ICP companies, the companies that ICP for us, the scale ups that are between 500 and 5,000 people, tech companies, most of the SaaS they use have APIs.”article, stated
• A weekly-meeting automation target is framed as saving an hour of company time on each run.
  “It's going to run those different assistants and get that notion page just ready. And by doing that, if you get there, and that's an objective for us to us using Dust, get there, you're saving an hour of company time every time you run it.”article, stated

Alternatives considered (roads not taken)

Vertical end-to-end agent products

Rejected because: Vertical products have easier go-to-market but limit adoption to one function instead of letting company-specific uses emerge across teams.

AutoGPT-style broad autonomy

Rejected because: Dust viewed current models as unreliable when given high-level instructions and many tools, so it started with simpler scripted workflows.

Generic third-party integration providers

Rejected because: Generic connectors did not preserve enough source-specific structure for high-quality model context, especially for tools like Notion.

Browser automation as the default enterprise action layer

Rejected because: For Dust's target customers, most useful internal systems expose APIs, making API-based integrations more reliable than watching agents click UIs.

Building a custom durable orchestrator

Rejected because: Dust chose to pay for Temporal because buying mature infrastructure helped the company move faster and focus on its core product.

Patterns

tool-use-orchestration (agent_architecture)

Dust constrains agents to user-authored workflows with explicit tools such as semantic search, structured queries, web search, and actions, rather than asking the model to discover a full plan from scratch.

rag-retrieval (knowledge_retrieval)

The platform's connector and context layer exists so agents can retrieve company knowledge from systems like Slack, Notion, GitHub, and structured databases.

model-routing (model_operations)

Dust exposes multiple model providers through a unified interface, keeps a default for ordinary users, and lets advanced users choose models for an assistant.

durable-execution (operations)

Temporal manages the background ingestion and triggered workflow work needed to keep connected company data fresh and run agents in response to changes.

observability-tracing (operations)

Dust's original developer product emphasized UI-based introspection over console token streams, and the enterprise product continues to treat feedback and trace interpretation as core product problems.

prompt-versioning (prompt_operations)

The product translates technical prompting concepts into user-facing instructions, making agent behavior configurable without exposing non-technical builders to prompt-engineering jargon.

Tradeoffs

Build a horizontal agent platform instead of vertical workflow agents

Chose Horizontal platform for company-specific agents over Vertical end-to-end products for one team or function.

Rationale: Horizontal infrastructure makes go-to-market harder, but it can reach far more of the company and let use cases emerge from actual operations.

Own important integrations end-to-end

Chose Dust-maintained connectors and source-specific processing over Generic integration-as-a-service feeds.

Rationale: LLM applications need structural distinctions and chunking choices that generic sync tools do not optimize for.

Use APIs before browser automation for internal systems

Chose API-based data retrieval and actions over RPA-style agents watching and clicking enterprise UIs.

Rationale: Dust's target scale-up customers mostly use SaaS tools with APIs, making API integrations more robust than UI automation for internal work.

Hide model choice behind sane defaults

Chose Model-agnostic platform with default model selection over Exposing every model choice in the main user flow.

Rationale: Technical users can care about model choice, but ordinary users need a simpler builder surface.

Buy durable workflow infrastructure

Chose Temporal Cloud over Replacing or building a custom orchestration engine.

Rationale: Temporal was good enough infrastructure to buy, allowing Dust to focus on product and connector value.

Gotchas (what bit them)

Generic data connectors can preserve the wrong shape for LLM use.

Root cause: Tools built for analytics may expose raw block structures or tabular forms without distinguishing what should become qualitative text versus quantitative context.

Resolution: Dust maintains source-specific connectors and chunking so model context respects each product's structure.

Too many tools plus high-level instructions cause model mistakes.

Root cause: Current function-calling and agentic capabilities are not reliable enough for broad AutoGPT-style autonomy in enterprise workflows.

Resolution: Start with simple, instruction-defined agents that use a couple of tools, then compose reliable smaller agents later.

Agent interaction traces are hard to evaluate directly.

Root cause: A conversation log does not reveal whether the user left satisfied, confused, or blocked.

Resolution: Make feedback a product feature so builders can iterate before pursuing deeper model training or optimization loops.

Horizontal products inherit a harder go-to-market motion.

Root cause: The buyer and workflow are less obvious than in vertical products that solve one named job.

Resolution: Use company-wide penetration and emergent use cases as the strategic payoff for carrying the infrastructure burden.

Evaluation

Dust treats evaluation as both model/tool quality and product feedback. It cares about function-calling correctness, but the case emphasizes adoption, user feedback mechanisms, and pragmatic product iteration over formal evals as the near-term priority.

Metrics: 88% daily active users in the highest-penetration deployment · 60% to 70% weekly active users in current enterprise customers · qualitative end-user feedback for builders · function-calling correctness and parameter accuracy

Outcomes

• Dust reports unusually high enterprise penetration for a horizontal agent platform.
• The company moved from developer framework to browser extension to enterprise infrastructure platform.
• Simple internal assistants can already automate concrete meeting-preparation tasks.
• The platform creates durable value through owned connectors and model/provider abstraction rather than a single model bet.

The source reports up to 88% daily active users in the highest-penetration deployment and 60% to 70% weekly active usage across current enterprise customers, with a target customer profile of tech companies around 500 to 5,000 employees.