Stanislas Polu expects AI work to move from isolated human-agent sessions to shared projects where several humans and agents coordinate over longer tasks.
2
Dust is building pods that combine people, agents, sessions, tasks, and shared state so agents can prepare work and route it to the right people.
3
Dust uses short planning horizons, dynamic project rankings, enterprise governance, and model choice to operate while AI capabilities and inference costs keep changing.
Summary
Stanislas Polu describes the shift from single-player AI, where one person works privately with an agent, toward multiplayer AI for work that spans teams and lasts days or weeks. Dust's pod model groups humans, agents, sessions, tasks, and shared files around one project. He explains how this can automate a team weekly by creating sessions for each slide, gathering company data, asking owners for input, and assembling the final presentation. Polu also discusses the product and infrastructure issues behind this model, including agent handoffs, stateful sandboxes, governance, model choice, file-system concurrency, and context. He is candid about the uncertainty of building on models that change every few weeks. Dust responds with six-month direction, a dynamic stack rank, and conviction that can be updated. The conversation also covers inference pricing, horizontal platforms, and why enterprise adoption needs richer collaboration surfaces than local coding agents provide.
Stripe's early culture worked like a flocking algorithm
Stanislas Polu says Stripe's growth from 150 to 3,000 people taught him how little management a well-aligned group may need. He compares the culture to a flocking algorithm, where simple local rules create autonomous group behavior. The three rules he names are separation, attraction, and alignment. Open writing through mailing lists helped people find others discussing the same subject. Trust meant people did not look over each other's shoulders when someone owned a problem. A simple company vision, described as a developer API for payments, gave everyone a shared direction. Polu says Dust turned this theory into an operating principle.
Current agents are still single-player because their work is short and uneven
Polu says most agent interaction remains single-player. Agents can currently work for a few hours or half a day, especially on coding tasks, which fits one person working alone. Their capabilities are also jagged. An agent can look superhuman on one task, then appear extremely poor after a small change in the task. People therefore share an agent's output in GitHub, Notion, or Google Drive rather than sharing the live session. Polu expects this to change as agents handle week-long tasks. Work lasting a week usually crosses teams and requires product managers, designers, infrastructure specialists, or other collaborators.
Longer tasks will make agents coordinate people and sessions
When agents can handle longer-horizon work, Polu expects the relationship to reverse. The agent will orchestrate a task across multiple human contributors and possibly multiple agents, while people steer the work at the points where their judgment is needed. Demetrios Brinkmann asks whether this is mainly a user experience problem. Polu agrees that it is mainly a product problem rather than a machine learning problem. He says a local harness such as Claude Code is inherently single-player, so collaborative work needs a shared environment with multiple humans, multiple sessions, and shared state. Dust is exploring that product surface.
A Dust pod gives a team a shared place for agent work
Polu describes a pod as a shared state containing multiple human-agent sessions. He gives Dust's weekly team meeting as an example. An agent creates a session for each slide, assigns it to the relevant owner, retrieves current information about revenue, customers, product work, and support, then asks each person what they want to add. Later, the agent checks unfinished work and combines the completed frames into one presentation. Each session has its own sandbox and file system, while the pod has a shared file system. Agents can move files between the session and pod spaces, allowing work to pass between contributors.
Dust treats humans and agents as equal users of every feature
Dust follows a principle Polu calls bidirectional access. Anything a human can do in Dust should also be available to an agent, and anything an agent can do should be available to a human. Tasks in a pod therefore need to be created, listed, edited, and used to trigger sessions by both types of user. Polu says this constraint changes product design because features cannot be built only for human workflows. He believes the symmetry will make it less clear whether a piece of work was completed by a person or an agent. Demetrios Brinkmann connects this to documentation that agents can read while remaining understandable to people.
Agent handoffs depend on better context and shared work units
Demetrios Brinkmann compares a finished project to a DAG, where each node can be handled by the person or agent best suited to that part of the work. Polu agrees that the goal is to make it easy to create the next handoff and route work to either a human or an agent. The hard infrastructure problem is context. Agents need enough information to be useful when they enter a new session. Polu says current approaches involve long agent loops and many MCP calls, while another approach turns work into skills. He does not claim to have a settled answer because agent capabilities remain uneven and change quickly.
Polu says teams fail when uncertainty makes them refuse to describe a direction. Dust instead tries to create conviction around a three-to-six-month goal while stating clearly that the plan may change. The company maintains a dynamic stack rank of projects that are actively being worked on. Anyone can request a stack-rank update, which brings the founders into a discussion about changing priorities. Polu says this gives people across the company a way to act like product contributors. He sees this as a response to the 'fog of AI', since models change every few weeks and make long-range plans unreliable.
Inference economics pushed Dust from flat pricing to credits
Polu explains that Dust originally used flat pricing to encourage usage and value creation. That approach depended on the expectation that model costs would eventually fall. As model capability and demand increased, the economics stopped working, so Dust had to move toward credit-based pricing. He argues that a company cannot safely hide provider costs when it does not know what future models will cost. Using smaller models can reduce spending in selected tasks, but Polu says he usually wants the best model for agent work. He also expects agents to choose smaller models themselves, while context caching and avoiding repeated file ingestion may offer other savings.
Enterprise agent platforms need collaboration, governance, and model freedom
Polu gives three reasons Dust remains different from local tools such as Claude Code. Multiplayer collaboration around a unit of work is difficult to reproduce with a local agent. Enterprise governance is another difference, since companies need controlled distribution of MCP servers, tools, skills, and data access. Finally, customers should not be tied to one model provider because the next strong model may come from elsewhere. Dust uses Slack and other systems as entry points and writes work back into them, while directing richer collaboration into Dust. Slack can support better approvals than GitHub, where an agent cannot easily ask a user to approve the next action.
