Distributed Agent Systems Architecture for AI Agent Platform

dust.tt · Tech · 2024 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.6 (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: Distributed infrastructure for long-running AI agents

Dust needed to move from synchronous, stateless assistant calls to reliable long-running agents that can use tools, preserve state, survive deployment failures, and avoid duplicate side effects.

Constraints:

Traditional web request/response architecture is synchronous and stateless.
Reasoning agents can run long enough that a failure after many minutes becomes costly and bad UX.
Agents need tool orchestration, persistence, and state across retries.
Deployments and infrastructure failures must not duplicate external side effects.
Brain/planning and hand/tool execution components must coordinate without brittle direct messaging.

Architecture

Dust redesigned its agent platform around a continuous orchestration loop. A Temporal workflow coordinates planning and tool-execution activities, while PostgreSQL tables for agent step content and agent actions act as a database-backed protocol between the planner brain and tool-executing hands. Versioned step/index/version records make tool execution idempotent: retries check whether a successful version already exists before running tools again, and durable checkpoints let long-running multi-tool agents survive failures.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  agent-user-request["Agent user request"] --> plan-respond-activity["Plan/respond activity"]
  plan-respond-activity --> agent-step-content-table["Agent step content table"]
  agent-step-content-table --> run-tool-activity["Run tool activity"]
  run-tool-activity --> external-tools["External tools"]
  run-tool-activity --> agent-actions-table["Agent actions table"]
  agent-actions-table --> plan-respond-activity["Plan/respond activity"]
  temporal-workflow["Temporal workflow"] --> plan-respond-activity
  temporal-workflow --> run-tool-activity

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Agent user request`	User request to an agent that may require reasoning, tools, and long-running work.	`Plan/respond activity`
`Plan/respond activity`	Planner or brain that decides the next tool/action steps.	`Agent step content table`, `Temporal workflow`
`Agent step content table`	Stores planning outputs with step, index, and version metadata.	`Run tool activity`, `Plan/respond activity`
`Run tool activity`	Execution hand that reads planned tool instructions and runs external tools.	`External tools`, `Agent actions table`, `Temporal workflow`
`External tools`	APIs such as email, Slack, datasets, databases, calendars, or Stripe-like systems.	`Run tool activity`
`Agent actions table`	Stores tool execution results and successful versions.	`Plan/respond activity`, `Run tool activity`
`Temporal workflow`	Workflow orchestrator that retries activities and preserves ordering/checkpoints.	`Plan/respond activity`, `Run tool activity`

Data flow

The planner writes decisions into agent step content; tool executors read those instructions, run tools, and write results into agent actions. Temporal loops between plan/respond and run-tool activities, checkpointing progress between steps. Version checks prevent duplicate side effects during retries, deployment interruptions, and infrastructure failures.

“the tool tables are actually a protocol where brain and hands communicate through the database state rather than messages.”transcript, stated

“Each iteration loop represents a step in the agent reasoning process. And with durable checkpoints between each step.”transcript, stated

Why this architecture

Dust separated orchestration from tool state because long-running reasoning agents break the assumptions of synchronous stateless web calls. The database protocol gives distributed components a shared source of truth, while Temporal provides retries and durable workflow ordering without rerunning whole agent sessions.

“we are actually trying like to have modern agents run on traditional web architecture.”transcript, stated

“the DB actually acts as the distributed memory for the the whole system and it allows activity to coordinate without direct communication.”transcript, stated

Models used: Temporal · PostgreSQL · LLM reasoning agents (unspecified) · Tool APIs including Slack/email/datasets

Scale

Dust agents can run long enough that a 15-minute failure would waste work and money.
“then it fails Because after 15 minutes then what happens? You just need to retry everything like you lose some money and also if you're actually like userf facing then from a UX point of view that's very bad.”transcript, stated
The architecture supports multiple tools running simultaneously.
“we can actually handle very complex scenarios with multiple tools running simultaneously while maintaining the the proper coordination.”transcript, stated

Alternatives considered (roads not taken)

Keep the synchronous stateless assistant architecture

Rejected because: It could not handle long reasoning tasks, orchestration, persistence, or failure recovery.

“still the same we are synchronous stateless and my point is that now and bear with me that's the last slide with code”transcript, stated

Retry the whole workflow after a tool failure

Rejected because: Temporal retries only the failed activity and checks database versions to avoid duplicate side effects.

“instead of like retrying the entire workflow the cool thing is that temporal so we use actually temporal yeah I forgot to mention that but we use temporal just a workflow orchestrator”transcript, stated

Direct brain-to-hand messages

Rejected because: Dust chose database state as the coordination protocol, avoiding direct component communication.

“brain and hands communicate through the database state rather than messages.”transcript, stated

Patterns

`durable-execution` (workflow)

Temporal orchestrates plan/respond and tool-running activities with durable checkpoints between reasoning steps.

“the temporal workflow provides the orchestration logic. So we don't need to care about anything temporal uh does it and it ensures that the steps execute in the right order and survive any infrastructure failures.”transcript, stated

`tool-use-orchestration` (agent)

The agent platform coordinates tool calls, parallel tool running, and tool-result feedback through workflow activities and database state.

“So we need to orchestrate tools tool running and then the third slide actually introduced the need for persistence.”transcript, stated

`agent-memory` (state)

PostgreSQL tables function as distributed memory/shared version state for agent activities.

“the database becomes the single source of truth and every agent activity coordinates through the this shared version state.”transcript, stated

`semantic-caching` (reliability)

Successful tool versions are reused on retries to prevent duplicate executions and side effects.

“before we run any tool, the system checks if a successful version already exists and if it found a successful one, then it actually just return the cache results.”transcript, stated

Tradeoffs

Use database state as the coordination layer

Chose Agent step/action tables with versioning over Direct component messages.

Rationale: Database state creates a durable protocol and single source of truth for retries.

“the database becomes the single source of truth and every agent activity coordinates through the this shared version state.”transcript, stated

Use Temporal for orchestration

Chose Workflow retries around plan/respond and run-tool activities over Application-level manual retry loops.

Rationale: Temporal handles ordering, retries, and survival of infrastructure failures while the database handles idempotent version checks.

“temporal workflow provides the orchestration logic. So we don't need to care about anything temporal uh does it”transcript, stated

Introduce version records for tool execution

Chose Step/index/version safety locks over Blind tool execution on every retry.

Rationale: Version checks allow multiple attempts while preserving history and avoiding duplicate tool effects.

“the version acts as a sort of safety lock which allows multiple attempt and still maintaining like a history of what actually happened.”transcript, stated

Gotchas (what bit them)

Traditional stateless web architecture breaks for long-running reasoning agents.

Root cause: Reasoning and tool use can last far longer than a request/response cycle and lose progress on failure.

Resolution: Use workflow orchestration and persistent state across reasoning/tool steps.

“we basically need to change something. So we are actually trying like to have modern agents run on traditional web architecture.”transcript, stated

Retries can create duplicate external side effects.

Root cause: Network retries, deployments, or infrastructure failures may rerun the same tool action.

Resolution: Store step/action versions and check for successful versions before executing tools.

“network retries, deployment interruptions or infrastructure failure whatever that's no longer going to cause any duplicate side effect.”transcript, stated

Planning and execution components need coordination without tight coupling.

Root cause: The brain and hands must communicate progress/results but should survive independent retries and failures.

Resolution: Use database-backed protocol tables as the communication and version state.

“the hands read their instructions from the agent step content and write their results back to the agent agent actions.”transcript, stated

Evaluation

The source validates the architecture through failure-mode reasoning rather than published benchmarks: retries, deployment interruptions, tool failures, parallel tools, and infrastructure failure survival.

Metrics: No duplicate side effects on retries · Successful version reuse · Durable checkpoints between reasoning steps · Survival of infrastructure failures · Coordination of multiple simultaneous tools

“This architecture enables reliable, scalable deployment of AI agents that can handle complex multi-step tasks while surviving infrastructure failures and preventing duplicate actions.”summary, stated

Outcomes

Redesigned Dust's agent infrastructure around orchestration and persistence.
Used database version state to prevent duplicate side effects.
Used Temporal to retry failed tool activities and preserve workflow progress.
Supported complex, multi-tool, long-running agent scenarios.

The source does not disclose request volume, but it describes long-running user-facing tasks, multiple simultaneous tools, deployments, and infrastructure failures.

“we can actually handle very complex scenarios with multiple tools running simultaneously while maintaining the the proper coordination.”transcript, stated

“And with that in mind at dust we decided to redesign our infrastructure.”transcript, stated