Dots and Muse: how personal AI assistants work, and what they open up for SaaS

How Dots and Muse combine execution, memory, and permissions, what economic questions they raise, and how to use that in your SaaS with embedded assistants and a solid CLI.

OpenAI and Meta's personal assistants combine memory, tools, and a computer in the cloud. That architecture makes it possible to delegate real work, and it also raises questions about cost, scale, and how these assistants should relate to our products.

Preparing a report can mean consulting documents, downloading files, cross-checking data, and generating a presentation.

To do that, the assistant needs to run tools, keep results, and continue when new information appears. Dots and Muse turn that capability into a product experience: assign a job and come back later to review the result.

For those of us building SaaS, there are two opportunities: put expert assistants inside the product, and let external assistants use it.

But first it helps to understand what sits behind them.

The code examples are teaching sketches with fictional interfaces. They illustrate the patterns described. They do not reproduce Muse or Dots internals.

How Muse's architecture works

Muse gives the user a dedicated Linux environment. The agent can work with files, run programs, and use tools.

Meta separates that environment from the services that hold credentials and authorize actions. The agent does its work inside an isolated cell based on systemd-nspawn, with limited privileges. Muse's official architecture.

1. The model proposes work; the environment runs it

Imagine the user asks to analyze a CSV. The agent can prepare a script and run it in its environment.

The flow, simplified, could look like this:

// Identity comes from the authenticated session.
const workspace = await workspaces.forUser(session.userId);

const result = await workspace.run({
  executable: "python",
  args: ["analyze_sales.py", "sales.csv"],
  timeoutMs: 30_000,
  network: "disabled"
});

await runState.append({
  exitCode: result.exitCode,
  stdout: result.stdout,
  stderr: result.stderr
});

// Identity comes from the authenticated session.
const workspace = await workspaces.forUser(session.userId);

const result = await workspace.run({
  executable: "python",
  args: ["analyze_sales.py", "sales.csv"],
  timeoutMs: 30_000,
  network: "disabled"
});

await runState.append({
  exitCode: result.exitCode,
  stdout: result.stdout,
  stderr: result.stderr
});

// Identity comes from the authenticated session.
const workspace = await workspaces.forUser(session.userId);

const result = await workspace.run({
  executable: "python",
  args: ["analyze_sales.py", "sales.csv"],
  timeoutMs: 30_000,
  network: "disabled"
});

await runState.append({
  exitCode: result.exitCode,
  stdout: result.stdout,
  stderr: result.stderr
});

The script does the analysis. The system around it selects the user's environment, sets limits, and keeps the result so the agent can decide how to continue.

A parameter like network: "disabled" only matters if the infrastructure enforces it. Writing it into an instruction to the model does not create isolation.

This pattern explains much of the product's power: it can combine existing tools and small programs to solve tasks nobody designed one by one.

2. Permissions live outside the agent

In Muse, Sentinel controls connector actions and outbound traffic. Another service, hatch-authd, holds the credentials.

The agent's environment can work with substitute tokens. After a request is authorized, the system attaches the real credential at the exit point. Permissions and credentials in Muse.

The split of responsibilities can be illustrated like this:

// This code runs in the control service.
const decision = await policy.evaluate({
  identity: session.identity,
  action: proposedAction
});

if (decision.status === "deny") {
  throw new Error("Action not allowed");
}

if (decision.status === "approval_required") {
  return approvals.createPending(decision.action);
}

return connectorService.executeAuthorized(decision);
// Credentials are resolved outside the agent's environment.

// This code runs in the control service.
const decision = await policy.evaluate({
  identity: session.identity,
  action: proposedAction
});

if (decision.status === "deny") {
  throw new Error("Action not allowed");
}

if (decision.status === "approval_required") {
  return approvals.createPending(decision.action);
}

return connectorService.executeAuthorized(decision);
// Credentials are resolved outside the agent's environment.

// This code runs in the control service.
const decision = await policy.evaluate({
  identity: session.identity,
  action: proposedAction
});

if (decision.status === "deny") {
  throw new Error("Action not allowed");
}

if (decision.status === "approval_required") {
  return approvals.createPending(decision.action);
}

return connectorService.executeAuthorized(decision);
// Credentials are resolved outside the agent's environment.

The system checks the identity and the specific action. If it needs approval, it leaves the operation pending. A later continuation has to validate that approval and the permissions still in force before it runs.

The architectural consequence matters: the model can propose an operation, but it cannot grant itself permission to carry it out.

3. Memory is stored and retrieved

Peter James's analysis of the Muse environment describes memory in Markdown files, search through PostgreSQL, and background processes that review records and keep references to their sources.

He also found reusable instructions, command-line tools, and traces of subagents. These observations come from one instance and are not an audit of the whole service.

In a system with that pattern, preparing context for a new task could look like this:

// The repository applies per-user isolation.
const memory = memoryStore.forUser(session.userId);

const relevantNotes = await memory.search({
  query: task.description,
  limit: 5
});

const context = {
  task,
  preferences: await memory.getPreferences(),
  evidence: relevantNotes.map(note => ({
    text: note.text,
    sourceId: note.sourceId,
    updatedAt: note.updatedAt
  }))
};

// The repository applies per-user isolation.
const memory = memoryStore.forUser(session.userId);

const relevantNotes = await memory.search({
  query: task.description,
  limit: 5
});

const context = {
  task,
  preferences: await memory.getPreferences(),
  evidence: relevantNotes.map(note => ({
    text: note.text,
    sourceId: note.sourceId,
    updatedAt: note.updatedAt
  }))
};

// The repository applies per-user isolation.
const memory = memoryStore.forUser(session.userId);

const relevantNotes = await memory.search({
  query: task.description,
  limit: 5
});

const context = {
  task,
  preferences: await memory.getPreferences(),
  evidence: relevantNotes.map(note => ({
    text: note.text,
    sourceId: note.sourceId,
    updatedAt: note.updatedAt
  }))
};

The agent receives a selection of stored information, with references and dates. It can recover a preference or an earlier decision without loading the whole history.

Quality depends on what is kept, how it is updated, and when it is treated as stale. Saving every conversation indefinitely does not, by itself, solve memory.

Dots likely follows a similar pattern

OpenAI documents that Dots has a computer and a browser in the cloud, persistent notes, connected apps, and the ability to delegate work in the background. It also distinguishes access to apps, to the local computer, and to conversation channels. Dots documentation.

It is reasonable to expect a functional architecture similar to Muse: a model that coordinates, an environment that executes, persistent state, and controls that govern actions.

That is an inference about the system's responsibilities. The public information reviewed does not allow us to say that Dots uses the same components or isolation mechanisms.

For an engineering team, what matters is the convergence: offering continuity means building and operating that whole system around the model.

The economic question: what it costs to keep that capability

A computer expands what the assistant can do. It also adds execution, memory, storage, browser, and network costs on top of the inference bill.

In a business product, a process of enough value can justify it. In consumer or freemium, we have more doubts: willingness to pay is limited and usage varies a lot between accounts.

The delicate point appears if reserved resources stay up through long periods of inactivity.

We do not have the internal data needed to declare that model unviable. There is a relevant question: how much useful work can each account offer before it threatens the margin?

A VM per user can run on shared physical infrastructure. It is also possible to keep files and context while assigning execution capacity on demand.

The alternatives include suspending environments, capacity pools, and resources fitted to each task. The challenge is to gain efficiency without losing isolation, continuity, or acceptable response times.

The metric ends up being the cost of completing a useful task, beyond the price per token.

Two opportunities for a SaaS

Put an expert personal assistant inside your product

The first opportunity is to bring that experience inside the SaaS.

An embedded assistant can know the product's functions, work with the customer's authorized context, and stay with them through recurring processes.

In a CRM, it could prepare the weekly review of opportunities. In a project tool, identify blockers. In an analytics product, investigate a change and generate a report with its sources.

Its differentiating value would be understanding the domain: what the data means, which rules apply, and what result the user needs.

The patterns above are still necessary, pointed at the product: memory per customer, specific tools, verifiable permissions, and controlled execution.

This is one of the lines we are exploring at Devic: provide the infrastructure to offer specialized assistants inside SaaS products, and let the team concentrate on delivering value to the customer.

Build a good CLI for external assistants

The second opportunity is to let Dots, Muse, and other assistants use the product from their own environments.

A CLI can express its capabilities through understandable commands. For example, in a fictional analytics SaaS:

# Discover the available operations.
acme reports --help

# Get structured data.
acme reports export --period last-month --format json

# Preview an update before applying it.
acme dashboards update sales \
  --file proposal.json \
  --dry-run \
  --format json

# Discover the available operations.
acme reports --help

# Get structured data.
acme reports export --period last-month --format json

# Preview an update before applying it.
acme dashboards update sales \
  --file proposal.json \
  --dry-run \
  --format json

# Discover the available operations.
acme reports --help

# Get structured data.
acme reports export --period last-month --format json

# Preview an update before applying it.
acme dashboards update sales \
  --file proposal.json \
  --dry-run \
  --format json

The assistant can discover an operation, fetch data, and prepare a change. The CLI needs stable output, useful errors, and scoped authentication. The server must validate permissions, resource ownership, and business rules.

Using it requires that the assistant's environment can run it, and that the user connects their account.

We cover that in MCP vs CLI: what an agent should use to act. Both interfaces can coexist on the same product capabilities.

Your SaaS can have an assistant and be used by others

The two paths complement each other.

The embedded assistant offers specialization inside the product. A CLI lets those capabilities take part in work that starts outside it and combines several applications.

In both cases, the product work is to define useful actions, results you can check, and clear permissions.

Dots and Muse raise expectations about what can be delegated. For a SaaS, the opportunity is to choose which tasks it can solve better for its customers, and to make them easy to run, both from its own interface and from a personal assistant.