E2B
Sprites
DedalusRoute runtime and substrate in one account — deploy persistent agent workers with tools and supervise your fleet from one dashboard.
Run agentson any substrate.
Choose the runtime, provider, and model path from one account — the home base for persistent workers. Provision the worker, install its loadout, keep its disk-backed state, and watch console, logs, usage, cron, and artifacts from one dashboard.
Hermes
hermes-prod · Dedalus
CPU
0.3 vCPU
MEM
128 MB
DISK
2.1 GB
OpenClaw
openclaw-browser · Dedalus
CPU
0.5 vCPU
MEM
256 MB
DISK
1.4 GB
Claude Code
claude-code-ci · Dedalus
CPU
1.0 vCPU
MEM
512 MB
DISK
4.7 GB
Codex CLI
codex-sandbox · Dedalus
CPU
0.5 vCPU
MEM
256 MB
DISK
1.8 GB
ACTIVITY -- 6 MONTHS
146 active daystap a cell . click a chip to filter
filter by agent . 6
filter by service . 23
CONTROL PLANE
OpenRouter for agents and containers.
Route the agent runtime and the container substrate from one account, then deploy a persistent worker with its full harness — supervised from a single dashboard.
Route runtime and substrate
Pick the agent runtime and provider lane separately. Agent Machines wires the same worker surface on top: console, gateway, loadout, cron, logs, and usage.
Supervise a specialist fleet
One Clerk sign-in stores provider credentials, runtime choices, machine records, and profile metadata. The dashboard shows the fleet instead of one local terminal.
One worker, full harness
Not a bare sandbox. The worker carries runtime, skills, MCP, cron, gateway, logs, usage, artifacts, and the browser console in one deployable unit.
WORKFLOW
The worker is runtime, substrate, and loadout together.
The control plane turns account settings into a machine recipe: agent runtime, provider lane, model route, environment profile, and active tools.
AGENT MACHINES · CONTROL PLANE
Configure once, supervise the whole fleet.
Setup, lifecycle, terminal, logs, artifacts, usage, and chat all read from the same account objects. The dashboard shows what is configured, running, and saved.
- →→Route
runtime + substratefrom one account settings model - →→Worker lifecycle:
wake · sleep · destroy(per substrate capability) - →→Persistent state in
/home/machine/.agent-machines
ClerkVercelAGENT MACHINES · RUNTIME ROUTES
Four runtimes, two operation models, one worker.
Hermes and OpenClaw run as longer-lived agent routes. Claude Code and Codex run as task CLIs. Each lands inside the same machine record and persistent runtime root.
- →→Autonomous routes:
Hermes · OpenClaw - →→Task-driven routes:
Claude Code · Codex - →→Reusable per-account
agent profiles
AGENT MACHINES · LOADOUT
Skills, MCP servers, CLIs, and plugins — one harness.
Loadout is the active stack on a machine: skills, MCPs, service routes, CLIs, plugins, and source entries. Registry is where new entries get added.
- →→
161 skillsin SKILL.md protocol - →→
27 service routes· MCP → CLI → skills - →→
24+ CLIs· closed-loop verification - →→Custom loadout:
skill · tool · mcp · cli · plugin
Agent MachinesAGENT MACHINES · SUBSTRATE ROUTES
Four substrate lanes — E2B, Sprites, Dedalus, and Vercel.
Each lane implements the same MachineProvider shape. The UI shows only the lifecycle actions and streaming behavior that provider supports.
- →→
E2B— sandbox with pause/resume - →→
Sprites— persistent microVM on Sprites.dev - →→
Dedalus Machines— strong default on boot and sleep/wake - →→
Vercel Sandbox— persistent microVMs with auto-snapshots
AGENT MACHINES · ENVIRONMENT
Gateway and env profiles follow every new worker.
Gateway modes, named variable sets, and bootstrap presets are account-level objects a new worker inherits on deploy.
- →→Gateway modes:
tunnel · ai gateway · byo - →→Named variable sets with
env profiles - →→Phase-tracked
bootstrappresets
Cloudflare
AGENTS
Chat and terminal commands for every agent.
Autonomous agents have built-in drivers that wake up on schedule. Task-driven CLIs run per-task but can be automated via headless flags and cron.
╭─────────────────╮
│ ◈ H E R M E S │
│ ╱╲ ╱╲ │
│ ╱ ╲──╱ ╲ │
│ ╱ ╲╱ ╲ │
│ ╲ ╱╲ ╱ │
│ ╲──╱ ╲──╱ │
│ nous research │
╰─────────────────╯Self-improving agent with persistent memory, cron scheduling, session history, MCP host, subagents, and FTS5 search. Works with any OpenAI-compatible endpoint -- 30+ providers out of the box.
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bashhermeshermes gatewayhttps://hermes-agent.nousresearch.com/docs/https://github.com/NousResearch/hermes-agentLOADOUT
Your agent's complete kit.
Mirrors the wiki's tool-hierarchy.mdc: every tool the agent picks from, ranked. Built-in tools fire in one turn. MCP servers get auto-spawned at bootstrap. Service entries cover 27 platforms (Vercel, Stripe, Supabase, Sentry, ...). Task entries rank which skill or tool to use for code review, design review, QA, research, and more.
callable tools
267
skills
161
services
27
task categories
12
built-in tools . 23
view >- Browser6
- Filesystem4
- Memory3
- Search3
- Shell1
- Vision1
- Image1
- Audio1
- Code1
- Delegate1
- Schedule1
services . 27
view >- Vercel
- Stripe
- Supabase
- Clerk
- Firebase
- Figma
- PostHog
- Sentry
- Datadog
- Linear
- Slack
- Shopify
tasks . 12
view >- Browser automationagent-browser
- Frontend verificationagent-browser diff
- Generative UIjson-render
- Code reviewcode-review
- Design reviewdesign-review
- QA + testingqa
Mirrors tool-hierarchy.mdc
129 trusted add-ons available
MCPs, CLIs, skills, sources, and providers composable into custom presets.
OBSERVABILITY -- DASHBOARD
The worker state you can inspect.
6 panels . API-shaped examples
illustrative panels, matched to the dashboard APIs for gateway, logs, usage, loadout, and cron
SCROLL RUNTIME
Watch the agent machine assemble.
Account settings become a machine recipe. The provider creates the host, the runtime installs the agent, the loadout defines its tools, and observability proves what is running.
Account settings become a machine recipe.
Provider, agent, gateway, env, tools, and custom loadout are not onboarding-only values. They are durable account objects that every new machine can inherit.
control plane routeThe runtime router chooses the host shape.
E2B, Sprites.dev, Dedalus Machines, and Vercel Sandbox are substrate routes behind one provider interface. The UI exposes lifecycle actions only when that lane supports them.
four substrate lanesFour agents install into the same durable boundary.
Hermes, OpenClaw, Claude Code, and Codex install into the same runtime root. Gateway agents and CLI agents use different launch paths, but share machine state.
The dashboard reads the same system the agent writes.
Chats, artifacts, logs, terminal snapshots, sessions, usage, and settings all converge on the same storage and provider execution model.
Browse and install from six live registries.
skills.sh, the MCP server registry, npm, Cursor plugins, GitHub repos, and URL manifests are searchable from Registry. Add entries to loadout, then sync on deploy or reload.
FAQ
Common questions about Agent Machines.
13 answers
- 01
Can I run multiple agents for different jobs?
- Yes. Provision specialist machines from opinionated presets: Hermes for memory and scheduled work, OpenClaw for browser work, Claude Code or Codex for coding tasks. Each preset bundles runtime, model route, memory, and loadout. One dashboard supervises activity, chat, cron, logs, usage, and artifacts.
- 02
What is Agent Machines?
- Agent Machines is the product layer above sandboxes: a control plane that provisions a persistent agent worker as one unit — runtime, model route, skills, MCP, integrations, cron, observation, and fleet management — on the machine provider you choose. Pick Hermes, OpenClaw, Claude Code, or Codex, then pick E2B, Sprites.dev, Dedalus Machines, or Vercel Sandbox. Provision specialist workers from opinionated presets (Hermes, OpenClaw, Claude Code, Codex). Each preset is runtime + model route + memory bundle + loadout, visible from one fleet dashboard. The dashboard supervises the fleet. The long-term control surface is dashboard for humans, MCP/CLI for agent-to-agent orchestration.
- 03
How is this different from a regular chatbot?
- 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.
- 04
Which agents can I run?
- Hermes, OpenClaw, Claude Code, and Codex are supported. Hermes is the default memory, cron, sessions, and MCP-native runtime. OpenClaw is the computer-use runtime. Claude Code and Codex are task-driven CLIs. All persist state under ~/.agent-machines/.
- 05
Which providers can host the machine?
- E2B Sandbox, Sprites.dev, Dedalus Machines, and Vercel Sandbox are live provider implementations. Each plugs into the same MachineProvider abstraction for provision, state, lifecycle, exec, streaming where available, and public URLs where supported.
- 06
How is this different from a sandbox like E2B or Daytona?
- Those are machine substrates. Agent Machines is the product layer above them: route to E2B, Sprites.dev, Vercel Sandbox, or Dedalus and get runtime install, loadout, gateway, cron, logs, usage, artifacts, and the browser console in one worker. Provider-specific features like sleep, snapshots, and public URLs are surfaced when the selected lane supports them.
- 07
How do I get my own machine today?
- Sign in with Clerk, add provider credentials in /dashboard/setup, pick the agent, provider, spec, and model, then provision the machine record. The browser flow creates the provider machine and stores it in your fleet; the reliable agent bootstrap path is still the matching root CLI deploy command until browser-driven bootstrap lands.
- 08
What tools and skills come pre-installed?
- The harness ships 161 SKILL.md files, 27 ranked service routes (MCP → CLI → skills per vendor), 39 MCP catalog entries (2 core + 32 bundled + 4 IDE), 24+ closed-loop CLIs, and 9–23 agent-native tools depending on runtime (Hermes, OpenClaw, Claude Code, Codex). The loadout registry — not static marketing copy — is the source of truth.
- 09
Is Cursor required?
- 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.
- 10
What is ~/.agent-machines?
- ~/.agent-machines is the unified runtime root for Agent Machines. It holds all agent state -- skills, crons, sessions, logs, MEMORY.md, USER.md, config, chats, and artifacts. The repo checkout at /home/machine/agent-machines is used by reload-from-git.sh to sync knowledge from GitHub.
- 11
What inference providers are supported?
- Models route through any OpenAI-compatible /v1 endpoint. The CLI defaults to a vendor-agnostic inference URL; override with DEDALUS_CHAT_BASE_URL or configure model.base_url on the machine. The dashboard stores a model slug per machine.
- 12
What happens when a machine sleeps?
- On supported providers, sleep pauses compute while preserving the persistent volume. The next wake resumes from disk: app artifacts, agent runtime state, skills, cron schedules, sessions, and the venv remain available.
- 13
Where does my data live?
- Provider credentials and gateway bearers live in Clerk private metadata. Machine state lives on the provider machine under /home/machine, with all agent runtime data and app state under ~/.agent-machines. The public client only sees redacted provider and machine status.