Question 1

Can I run multiple agents for different jobs?

Accepted Answer

Yes. Save starting configurations for coding, research, browser tasks, and other workflows. Each preset suggests a runtime, instructions, and selected abilities. Connect credentials and install the tools you need before running it. One dashboard shows your machines, terminals, files, logs, and usage.

Question 2

What is Agent Machines?

Accepted Answer

Agent Machines provides open-source building blocks for agent harnesses: runtime adapters, sandbox providers, browser terminals, editable instructions and memory, skills, and MCP configuration. Start from a preset or assemble your own setup, run the actual agent CLI, and manage remote agents from one dashboard. Inspect, modify, and extend the source as your workflow changes.

Question 3

How is this different from a regular chatbot?

Accepted Answer

A regular chatbot mostly returns messages. Agent Machines gives the agent a machine record, runtime root, terminal, filesystem, logs, usage, cron schedules, sessions, artifacts, and installable tools. State lives with the worker instead of disappearing after one request.

Question 4

Which agents can I run?

Accepted Answer

Claude Code, Codex, Hermes, and OpenClaw have runtime adapters. You can use the actual native CLI in a browser terminal or use managed execution. Native tools, model paths, and session formats vary by runtime; selecting a runtime does not install every integration in the catalog.

Question 5

Which providers can host the machine?

Accepted Answer

Daytona, E2B Sandbox, Sprites.dev, and Vercel Sandbox. Daytona stop/start retains files but restarts processes; E2B supports pause/resume; Sprites manages idle suspension; Vercel resumes from filesystem snapshots. Each provider exposes only the lifecycle and terminal operations it supports. Historical benchmark results do not establish Daytona performance.

Question 6

How is this different from a sandbox like E2B or Daytona?

Accepted Answer

Those supply compute. Agent Machines adds runtime setup, editable instructions and memory, tool configuration, terminals, files, and logs. You can reuse and modify the open-source adapters instead of rebuilding this layer. Provider-specific features such as pause, snapshots, and preview URLs remain available only where supported.

Question 7

How do I get my own machine today?

Accepted Answer

Sign in and add provider and model credentials in Settings. Open Starter setups, preview a preset, and save it. Review its configuration and provision a machine when ready; saving a setup alone does not launch compute. Quick launch on the overview creates a machine directly. Compute and inference use your connected accounts.

Question 8

What tools and skills can I add?

Accepted Answer

The source includes 161 SKILL.md entries and 39 MCP catalog entries, plus CLI and service guides. These are available building blocks, not a promise that every tool is installed, authenticated, or compatible with every runtime. Preview and select abilities, connect the required services, then use the dashboard installation controls. Runtime-native tools vary by agent.

Question 9

Is Cursor required?

Accepted Answer

No. Cursor is optional delegation for code edits through cursor-bridge and @cursor/sdk. Without CURSOR_API_KEY, the rest of the machine still runs: chat, files, browser automation, closed-loop tools, skills, cron, memory, dashboard polling, artifacts, and provider lifecycle controls.

Question 10

What is ~/.agent-machines?

Accepted Answer

~/.agent-machines holds Worker configuration, canonical memory, skills, schedules, logs, chats, and artifacts. Native runtimes also keep their own state directories. The ~ prefix means the sandbox user's home: /home/daytona, /home/user, /home/sprite, or /vercel/sandbox. Knowledge updates use ~/.agent-machines/knowledge-source, separate from the Worker's project at ~/agent-machines.

Question 11

What inference providers are supported?

Accepted Answer

Compatibility depends on both runtime and interface. The hosted dashboard uses native Anthropic for Claude Code and native OpenAI for Codex; Hermes and OpenClaw expose supported router or native-compatible paths. The direct mux SDK has a separate upstream map: Claude Code and Codex support native keys, OpenRouter, and Vercel AI Gateway; Hermes uses native Anthropic or OpenAI. An arbitrary endpoint is not guaranteed to work with every runtime.

Question 12

What happens when a machine sleeps?

Accepted Answer

The behavior is provider-specific. Daytona stop/start retains files but restarts processes. E2B supports pause/resume. Sprites manages idle suspension rather than manual sleep. Vercel uses filesystem snapshots with bounded sessions. Moving files between providers does not migrate live process memory or guarantee that a native conversation can resume unchanged.

Question 13

Can I share or customize a setup?

Accepted Answer

You can fork the MIT-licensed source, reuse direct SDK configuration files, bring your own skills, and export memory documents as Markdown. Full executable setup import/export, a public marketplace, and a copy-into-app component installer are not available yet. The shadcn analogy describes the source-first design principle, not an existing shadcn integration.

Question 14

Where does my data live?

Accepted Answer

Provider credentials and model keys are stored privately for your account. Worker configuration and history also use the hosted data store; workspace files and runtime state live in the selected sandbox user's home, including ~/.agent-machines. The public client receives redacted credential and machine status.

A control plane for agent workers.

12 workers. Four agent runtimes.

Docs, API notes, and operator playbooks.

From the workshop.

No posts published yet.

Go straight to the source.

Documentation

Inside the product

Architecture paper