Dots y Muse: cómo funcionan los asistentes personales de IA y qué oportunidades abren para los SaaS

Cómo Dots y Muse combinan ejecución, memoria y permisos, qué retos económicos plantean y cómo aprovecharlos en tu SaaS con asistentes embebidos y una buena CLI.

Los asistentes personales de OpenAI y Meta combinan memoria, herramientas y un ordenador en la nube. Esa arquitectura permite delegar trabajo real, pero también plantea preguntas sobre costes, escalabilidad y cómo deberán relacionarse con nuestros productos.

Preparar un informe puede requerir consultar documentos, descargar archivos, cruzar datos y generar una presentación.

Para resolverlo, el asistente necesita ejecutar herramientas, conservar resultados y continuar cuando aparece nueva información. Dots y Muse convierten esa capacidad en una experiencia de producto: encargar un trabajo y volver después para revisar el resultado.

Para quienes construimos SaaS, hay dos oportunidades: incorporar asistentes expertos dentro del producto y permitir que asistentes externos lo utilicen.

Pero primero conviene entender qué hay detrás.

Los ejemplos de código son esquemas didácticos con interfaces ficticias. Ilustran los patrones descritos; no reproducen el código interno de Muse o Dots.

Cómo funciona la arquitectura de Muse

Muse dispone de un entorno Linux dedicado al usuario. El agente puede trabajar con archivos, ejecutar programas y utilizar herramientas.

Meta separa ese entorno de los servicios que custodian credenciales y autorizan acciones. El agente ejecuta su trabajo dentro de una celda aislada basada en systemd-nspawn, con privilegios limitados. Arquitectura oficial de Muse.

1. El modelo propone trabajo; el entorno lo ejecuta

Imaginemos que el usuario pide analizar un CSV. El agente puede preparar un script y ejecutarlo en su entorno.

El flujo, simplificado, podría verse así:

// La identidad procede de la sesión autenticada.
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
});

// La identidad procede de la sesión autenticada.
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
});

// La identidad procede de la sesión autenticada.
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
});

El script resuelve el análisis. El sistema que lo rodea selecciona el entorno del usuario, establece límites y conserva el resultado para que el agente decida cómo continuar.

Un parámetro como network: "disabled" solo tiene valor si la infraestructura lo hace cumplir. Escribirlo en una instrucción al modelo no crea aislamiento.

Este patrón explica buena parte de la potencia del producto: puede combinar herramientas existentes y pequeños programas para resolver tareas que nadie ha diseñado individualmente.

2. Los permisos viven fuera del agente

En Muse, Sentinel controla las acciones de los conectores y el tráfico de salida. Otro servicio, hatch-authd, custodia las credenciales.

El entorno del agente puede trabajar con tokens sustitutos. Después de autorizar una petición, el sistema incorpora la credencial real en el punto de salida. Permisos y credenciales en Muse.

La separación de responsabilidades puede ilustrarse así:

// Este código se ejecuta en el servicio de control.
const decision = await policy.evaluate({
  identity: session.identity,
  action: proposedAction
});

if (decision.status === "deny") {
  throw new Error("Acción no permitida");
}

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

return connectorService.executeAuthorized(decision);
// Las credenciales se resuelven fuera del entorno del agente.

// Este código se ejecuta en el servicio de control.
const decision = await policy.evaluate({
  identity: session.identity,
  action: proposedAction
});

if (decision.status === "deny") {
  throw new Error("Acción no permitida");
}

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

return connectorService.executeAuthorized(decision);
// Las credenciales se resuelven fuera del entorno del agente.

// Este código se ejecuta en el servicio de control.
const decision = await policy.evaluate({
  identity: session.identity,
  action: proposedAction
});

if (decision.status === "deny") {
  throw new Error("Acción no permitida");
}

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

return connectorService.executeAuthorized(decision);
// Las credenciales se resuelven fuera del entorno del agente.

El sistema comprueba la identidad y la acción concreta. Si necesita aprobación, deja la operación pendiente. Una continuación posterior deberá validar esa aprobación y los permisos vigentes antes de ejecutarla.

La consecuencia arquitectónica es importante: el modelo puede proponer una operación, pero no concederse permiso para realizarla.

3. La memoria se guarda y se recupera

El análisis del entorno de Muse publicado por Peter James describe memoria en archivos Markdown, búsqueda mediante PostgreSQL y procesos en segundo plano que revisan registros y conservan referencias a sus fuentes.

También encontró instrucciones reutilizables, herramientas de línea de comandos y trazas de subagentes. Estas observaciones proceden de una instancia y no constituyen una auditoría de todo el servicio.

En un sistema con ese patrón, preparar el contexto para una nueva tarea podría tener esta forma:

// El repositorio aplica el aislamiento por usuario.
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
  }))
};

// El repositorio aplica el aislamiento por usuario.
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
  }))
};

// El repositorio aplica el aislamiento por usuario.
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
  }))
};

El agente recibe una selección de información persistida, con referencias y fechas. Así puede recuperar una preferencia o una decisión anterior sin cargar todo el historial.

La calidad depende de qué se conserva, cómo se actualiza y cuándo se considera obsoleto. Guardar cada conversación indefinidamente no resuelve por sí solo la memoria.

Dots previsiblemente sigue un patrón parecido

OpenAI documenta que Dots tiene ordenador y navegador en la nube, notas persistentes, aplicaciones conectadas y capacidad para delegar trabajo en segundo plano. También distingue el acceso a aplicaciones, al ordenador local y a los canales de conversación. Documentación de Dots.

Es razonable esperar una arquitectura funcional similar a Muse: un modelo que coordina, un entorno que ejecuta, estado persistente y controles que gobiernan las acciones.

Esa es una inferencia sobre las responsabilidades del sistema. La información pública revisada no permite afirmar que Dots utilice los mismos componentes o mecanismos de aislamiento.

Para un equipo de ingeniería, lo relevante es la convergencia: ofrecer continuidad requiere construir y operar todo ese sistema alrededor del modelo.

La pregunta económica: cuánto cuesta mantener esa capacidad

Un ordenador amplía lo que puede hacer el asistente. También añade costes de ejecución, memoria, almacenamiento, navegador y red a la factura de inferencia.

En un producto empresarial, un proceso de suficiente valor puede justificarlo. En consumo o freemium, tenemos más dudas: la disposición a pagar es limitada y el uso varía mucho entre cuentas.

El punto delicado aparece si se mantienen recursos reservados durante largos periodos de inactividad.

No tenemos los datos internos necesarios para declarar inviable ese modelo. Sí existe una pregunta relevante: ¿cuánto trabajo útil puede ofrecer cada cuenta antes de comprometer el margen?

Una VM por usuario puede ejecutarse sobre infraestructura física compartida. Además, es posible conservar archivos y contexto mientras se asigna capacidad de ejecución bajo demanda.

Las alternativas incluyen suspensión de entornos, pools de capacidad y recursos adaptados a cada tarea. El desafío consiste en ganar eficiencia sin perder aislamiento, continuidad ni tiempos de respuesta aceptables.

La métrica termina siendo el coste de completar una tarea útil, más allá del precio por token.

Dos oportunidades para un SaaS

Incorporar un asistente personal experto en tu producto

La primera oportunidad es trasladar esa experiencia al interior del SaaS.

Un asistente embebido puede conocer las funciones del producto, trabajar con el contexto autorizado del cliente y acompañarlo en procesos recurrentes.

En un CRM, podría preparar la revisión semanal de oportunidades. En una herramienta de proyectos, identificar bloqueos. En un producto de analítica, investigar una variación y generar un informe con sus fuentes.

Su valor diferencial estaría en comprender el dominio: qué significan los datos, qué reglas se aplican y qué resultado necesita el usuario.

Los patrones anteriores siguen siendo necesarios, pero orientados al producto: memoria por cliente, herramientas específicas, permisos verificables y ejecución controlada.

Esta es una de las líneas que estamos explorando en Devic: proporcionar la infraestructura para ofrecer asistentes especializados dentro de los SaaS y concentrar el esfuerzo del equipo en aportar valor al cliente.

Crear una buena CLI para asistentes externos

La segunda oportunidad consiste en permitir que Dots, Muse y otros asistentes utilicen el producto desde sus propios entornos.

Una CLI puede expresar sus capacidades mediante comandos comprensibles. Por ejemplo, en un SaaS ficticio de analítica:

# Descubrir las operaciones disponibles.
acme reports --help

# Obtener datos estructurados.
acme reports export --period last-month --format json

# Previsualizar una actualización antes de aplicarla.
acme dashboards update sales \
  --file proposal.json \
  --dry-run \
  --format json

# Descubrir las operaciones disponibles.
acme reports --help

# Obtener datos estructurados.
acme reports export --period last-month --format json

# Previsualizar una actualización antes de aplicarla.
acme dashboards update sales \
  --file proposal.json \
  --dry-run \
  --format json

# Descubrir las operaciones disponibles.
acme reports --help

# Obtener datos estructurados.
acme reports export --period last-month --format json

# Previsualizar una actualización antes de aplicarla.
acme dashboards update sales \
  --file proposal.json \
  --dry-run \
  --format json

El asistente puede descubrir una operación, obtener datos y preparar un cambio. La CLI necesita salidas estables, errores útiles y autenticación acotada. El servidor debe validar permisos, pertenencia de los recursos y reglas de negocio.

Su uso requiere que el entorno del asistente permita ejecutarla y que el usuario conecte su cuenta.

Lo desarrollamos en MCP vs CLI: qué debe utilizar un agente para actuar. Ambas interfaces pueden convivir sobre las mismas capacidades del producto.

Tu SaaS puede tener asistente y ser utilizado por otros

Los dos caminos se complementan.

El asistente embebido ofrece especialización dentro del producto. Una CLI permite que sus capacidades participen en trabajos que empiezan fuera de él y combinan varias aplicaciones.

En ambos casos, el trabajo de producto consiste en definir acciones útiles, resultados comprobables y permisos claros.

Dots y Muse elevan las expectativas sobre lo que se puede delegar. Para un SaaS, la oportunidad está en elegir qué tareas puede resolver mejor para sus clientes y facilitar su ejecución, tanto desde su propia interfaz como desde un asistente personal.