AI agents you can leave running overnight

AgentPlaza gives each agent its own sealed machine, checks every tool call against laws you write, and holds the spend to a budget. In the morning you read a signed record of what happened, and nothing you did not allow.

Website · Guide · See it run · Install · Quick start · Releases

You describe the work: the hub plans it as a project, runs each task as sessions in their own microVMs, has every change reviewed on a second model, and lands it through Weft, the plaza's own version control. One hub holds the plaza, nodes and workstations do the work, and the web console, the desktop app and the agentplaza command all show the same plaza. One button, STOP ALL, holds everything at once.

See it run

The console, recorded on sample data. Every flow below is the real web console against sample data. Each image opens its recording in the gallery.

Approve a held deploy. A release agent asked to deploy. The call waits on you; one click lets it run.	Follow the work. Each project's graph: the brief, the research, the proposal, the critique and the tasks.
Every machine, in 3D. The fleet on its plinths, one machine opened, its model turning.	The plaza's own version control. Weft: repositories, lanes and changes, each with its intent and review.
Spend and load, live. Seven days of spend, then one VM's own numbers, then the whole plaza again.	STOP ALL, then RESUME. One press holds every agent and refuses model calls; RESUME lets them carry on.
Read the laws. The plaza's laws by kind: forbids, the constitution, statutes, tools and operations.	Change the whole look. Graphite cobalt, violet, teal, then Loom moss and clay, live on every screen.

The desktop app. A goal goes to the orchestrator with its effort, and the context bar breaks down what the conversation holds; then the agents that took the work.

Machines. Every machine as a 3D model on its plinth, in three styles.	Models. Providers and coding engines side by side, health-checked and pinned.

The terminal. agentplaza tui shows the same plaza in a terminal: the floor, the agents, the board, the conversations, the machines and the models, with live events, and you talk to the orchestrator as it answers.

_{Recorded from the desktop app and agentplaza tui against a hub with sample data. The recordings and the art are made by the scripts in scripts/readme/.}

Why AgentPlaza

• Your machines. The hub, the nodes and the workstations run on the machines you choose. The daemons bind to loopback by default.
• One microVM per agent, with no network interface. Each agent runs in its own microVM. Its commands run only inside that VM, and its traffic goes only to the hub, over vsock.
• Laws on every tool call. The laws are written in JHRL and checked before each tool call runs. A call is allowed, refused, or sent to you to decide. A call that no law permits is refused.
• Budgets you set. Each project and task has a budget in dollars or tokens. Every model call is held against it before it is sent and settled after, and a task that reaches its cap pauses and asks you.
• Every change reviewed, then landed. A task's builder works in its own VM, a reviewer on a different model checks the change, and it lands through Weft's queue with its intent, its review and a signature.
• STOP ALL. One button holds the whole plaza. It cancels the running work, refuses model calls until you resume, and records who pressed it.
• Any model provider, through one gateway. Agents reach models only through the hub's gateway, which covers Anthropic, OpenAI, Azure OpenAI, Gemini, Bedrock, Vertex AI and OpenAI-compatible providers. Provider keys stay in the encrypted vault and never enter a microVM.
• One plaza, three consoles. The web console, the desktop app and the agentplaza command use the hub's one API and show the same plaza.
• Workstations that agents use like a person. An agent works a machine through the hub: the screen, the pointer, the keyboard and the shell, in a work folder. You can take over the mouse and keyboard and give them back.

Install

Linux, macOS and Raspberry Pi OS:

curl -fsSL https://agentplaza.io/install.sh | sh

This installs the macOS DMG or the Linux package for your distribution, after checking every file against the release's SHA256SUMS.

Windows x64 and arm64:

irm https://agentplaza.io/install.ps1 | iex

This installs the MSI for your architecture.

The installer takes options as environment variables, or as flags after sh -s --. APZ_VERSION pins a release, --dry-run shows the plan, --uninstall removes what the installer put in place, and APZ_FORMAT forces a Linux format. For example: curl -fsSL https://agentplaza.io/install.sh | sh -s -- --dry-run.

The hub, the console and the desktop app run on every system below. Agents need a hypervisor, so they run only on the systems marked yes:

System	Hub and console	Agents
Linux x86_64, arm64	yes	yes, with KVM (/dev/kvm)
Raspberry Pi 4/5, 64-bit Raspberry Pi OS	yes	yes, with KVM
macOS, Apple silicon	yes	yes, with Hypervisor.framework
macOS, Intel	yes	no: run them on a node elsewhere
Windows 11 (or 10 2004+), x64	yes	yes, with the Windows Hypervisor Platform feature
Windows, arm64	yes (the node link)	not yet: run them on a node elsewhere

The desktop app is self-contained: "Start locally" and "Host a hub" start the hub and the node services themselves, with no Docker, database server or object store to provision. The hub keeps its state in three SQLite files (plaza.db, transcripts.db and metrics.db) and an object store in one state folder. They use the ports 7700 (hub), 8899 (noded) and 19080 (vsockd). The macOS builds are not notarized yet, and the MSI is not code-signed yet.

Quick start

1. Set up a plaza. Open the desktop app and choose Start locally. It checks what this machine needs (a hypervisor for the agents and free ports; agentplaza setup runs the same checks), then starts the hub and the node services. It installs nothing: a requirement that is not met says what to do. On Linux you can instead start the services with systemctl --user enable --now agentplaza-hub agentplaza-node, or run apid in a terminal on any system.
2. Open the console at http://127.0.0.1:7700. The owner token is written once to the state folder (owner-token), and the console on this machine signs in without a password.
3. Add a model key. On the Models screen, add a key to a provider card. From the command line: printf '%s' '<key>' | agentplaza models key anthropic --value -
4. Join a node. On the hub: agentplaza nodes code --label atlas --ttl 15. On the other machine: agentplaza node join <code>. The node shows as online in agentplaza nodes list.
5. Start a project. Choose New project in the switcher at the top of the console, and tell the orchestrator what you want done. It drafts the project beside the conversation (its tasks, its team and its budget), and you press Start project. From the command line, post to the orchestrator's chat with agentplaza chats post main "Fix the flaky scheduler tests and ship 0.9"; the draft's start card then waits in agentplaza inbox, and agentplaza inbox answer <card> start starts it. A fresh plaza runs the orchestrator alone. Each task then runs as sessions that fill its seats: by default a builder, then a reviewer on a different model. What needs you (a draft to start, a budget cap, an approval) waits in the inbox and in Approvals.
6. Add a workstation. On the hub: agentplaza stations codes create --label workstation --ttl 15. On the machine: agentplaza workstation join <code> --hub https://<hub>. Agents act on it as a separate agentplaza OS account by default. --account owner makes them act as your own account, which the console warns about.

STOP ALL holds the plaza at any time. Press it in the top bar of the console, or run agentplaza plaza stop --reason "...". It cancels the running work, refuses model calls and records who pressed it. It does not stop the microVMs. RESUME releases it, or run agentplaza plaza resume.

The full walkthrough, with the troubleshooting questions, is in the guide.

Usage

agentplaza setup                                    # what a local plaza needs on this machine, and what is missing
agentplaza overview                                 # the plaza at a glance: hub, nodes, agents, work
agentplaza chats post main "Fix the flaky scheduler tests and ship 0.9"   # the orchestrator drafts a project
agentplaza inbox                                    # the cards waiting for you, each with its choices
agentplaza inbox answer <card> start                # start the drafted project
agentplaza projects list                            # the projects, with their stage and state
agentplaza tasks list --project pr1                 # a project's tasks
agentplaza tasks graph pr1                          # a project's tasks in the order their links let them run
agentplaza tasks create "Survey the open issues" --project pr1 --role researcher --details "List them, with the blockers"
agentplaza seats <task>                             # a task's seats: each one's session, model, attempts and round
agentplaza sessions --live                          # the sessions running now
agentplaza sessions transcript <session> --follow   # what a session does and says, as it happens
agentplaza budget project pr1                       # a project's budget: cap, spent, reserved, left
agentplaza roles                                    # the seat templates a task's seats are filled from
agentplaza nodes code --label atlas --ttl 15        # hub: a one-time join code, valid for 15 minutes
agentplaza node join <code>                         # the machine: join it to the hub as a node
agentplaza nodes list                               # the nodes, with their state, agents and last seen
agentplaza stations codes create --label workstation --ttl 15   # hub: a join code for a workstation
agentplaza workstation join <code> --hub https://<hub>          # the machine: add it as a workstation
agentplaza plaza stop --reason "..."                # STOP ALL, with a reason; asks first unless --yes
agentplaza plaza resume                             # resume the plaza after STOP ALL
agentplaza mcp server enable                        # turn on the hub's MCP server, on loopback (off until you do)
agentplaza mcp token create --name claude-code --scope observe   # an MCP token, printed once
claude mcp add --transport http agentplaza http://127.0.0.1:7700/mcp --header "Authorization: Bearer <token>"
agentplaza tui                                      # the terminal UI, with the plaza drawn live

The claude mcp add line connects Claude Code to the hub's /mcp with that token.

The desktop app and the web console at http://127.0.0.1:7700 do the same work. Every screen of the web console is in the desktop app.

Features

• Machines. Every machine of the plaza as a 3D model on its plinth, in zones (hub, compute, GPU, desktops, workstations), with its load and status, or as a list. Each machine has its own view: the live model, its hardware with each GPU's card, load, 2D drawings, VM slots, agents and events. Three styles (Ink, Blueprint, Night). Drawn by a Rust wgpu engine (crates/apz-engine), in the browser as WebAssembly on WebGPU with WebGL2 as the fallback.
• Projects. A project is talked into being with the orchestrator: it drafts the tasks and the budget beside the conversation, and Start opens and plans it at once. A project overrides the plaza's settings for its agents (models, effort, limits, permissions, budget), and the consoles switch between projects.
• The work engine. Each task runs as sessions that fill its seats, from seat templates (roles). A task's recipe sets its steps: by default a builder, then a reviewer on a different model; longer recipes add an adversarial review chain with a verifier, gates and bounded loops. Each session runs in a VM of its own on a node, a fork of the project's prebuilt base. Seats message each other in threads, the owner decides through cards in the inbox, and a finished task's journal is distilled into the project's memory (.plaza/memory). Changes land through Weft's queue in speculative batches, with bisection when a batch fails.
• Projects after launch. A project is in build or maintenance. In maintenance its agents read its feedback, reports and analytics, keep a map of it and propose work with its value and risk; the owner picks each proposal. Environments run deploys, and protected ones wait for the owner. A project that exists can be brought in from a git platform, a git address or a folder, and files can be dropped into projects and chats (docs/guide/projects-after-launch.md).
• Intake. Issues from GitHub, Linear and Notion come in through connectors, become a spec, then a plan and its tasks. Questions about the spec come back to you as threads.
• Releases, the test lab and deploys. A release gathers its changes, an artifact per target with a signature, an SBOM and provenance, and its notes. The qualification recipe runs eleven stages, from functional tests through data, performance, resilience, security, UX and a soak to the verdict, on test-lab nodes and at a depth set by the channel; a stage that cannot run shows not run with its reason and never counts as a pass. Deploys promote qualified releases only, to Cloudflare, Kubernetes or AWS, and a health watch rolls one back on its own. Incidents, dependency upgrades and CVEs run as plaza tasks too.
• Weft. The plaza's version control, in one binary: the hub's history server, the node cache and the CLI. Each change carries its intent and its review, history and blame go down to a function (path::symbol), the log is signed and hash-chained, and a one-way export writes landed changes to git.
• The IDE. A workspace for the agents' repositories (docs/design/ide.md). The agent's conversation is at the centre, with the code, terminal and diffs around it.
• Laws. The laws are written in JHRL (crates/jhrl) and checked on every tool call.
• The Lab and evals. The Foundry trains small models from the plaza's own records, serves them to agents, and imports open models from Hugging Face. Breeder agents propose training jobs; a job runs only at a recipe commit the owner has vetted. Evals replay archived tasks into reports and leaderboards, and a step can let them pick its model and engine.
• MCP both ways. The plaza's agents use external MCP servers as tools, through the hub's egress. The servers run sandboxed: in a microVM on a Linux node, under Seatbelt on macOS and in an AppContainer on Windows. The hub is also an MCP server (/mcp) for clients such as Claude Code, with scoped tokens (observe, operate, govern). It is off until you turn it on.
• Coding engines over ACP. Eighteen coding engines run inside the agent's VM as Agent Client Protocol agents, each pinned to a verified version. Claude Code, Codex and OpenCode are on by default. Gemini CLI, Qwen Code, Kilo Code, Cline, GitHub Copilot CLI, Goose, Kimi Code, Auggie and Mistral Vibe speak ACP themselves, and Amp, Crush, Junie, Factory Droid, Aider and OpenHands run through a thin adapter; these are off until the owner enables them. Their stream shows live in the IDE. The laws, grants and approvals check every action the engine takes (docs/architecture.md).
• Git platforms. GitHub (the plaza's own GitHub App, installed on your account or organisations), GitLab and Forgejo (OAuth or tokens), at account, organisation or repository level; you choose which repositories the plaza may use and connect them to projects, which Weft then exports to (docs/guide/git-platforms.md).
• Editors over ACP. Zed, JetBrains IDEs and Neovim can prompt a plaza agent and answer its approvals through agentplaza acp. With --repo the editor's project is mirrored into Weft, and the files the agent changed in its lane come back into the editor as diffs. It speaks ACP v1 by default, with the ACP v2 draft behind a switch, and it is off until you turn it on (docs/guide/editors.md).
• Vault. Provider keys and other secrets are encrypted on disk with RustCrypto AEAD (crates/apid/src/vault). The console shows them by name and use, never by value, with a MAC-chained audit trail.
• Models. A gateway for Anthropic, OpenAI (Chat Completions and Responses), Azure OpenAI, Gemini, Bedrock, Vertex AI and OpenAI-compatible providers (Ollama, OpenRouter, Groq, Mistral and more), with a two-tier model policy that the owner sets. Several accounts of one kind, each with its own key. Coding engines (Claude Code, Codex, OpenCode, Gemini CLI, and any ACP registry agent or local ACP command) are instances the owner manages beside the providers, pinned to a verified version and run only in agent VMs. Background health checks, favourite models that lead every picker, and CLIProxyAPI usage hubs that show pooled subscription quotas. See docs/guide/providers.md.
• Workstations. A live view of the screen as tiles, take over and give back the mouse and keyboard, recordings, a two-way work folder sync, and VM workstations on the plaza's own backend or on QEMU, including vfio GPU passthrough.
• Rich content. References in agent text become chips with hover cards: GitHub (pull requests, issues, commits, files), agents, tasks, Library files and artifacts (crates/apz-rich).
• Looks. Two looks, Loom and Graphite, with palettes (Clay, Moss, Indigo; Cobalt, Violet, Teal), light and dark, and backgrounds drawn by one shader: dots (Loom's Paper), a fading grid (Graphite's Grid), colour fields that drift, and film grain. Every built-in palette passes 4.5:1 for text. Make your own in the theme editor, or import a VS Code theme or .vsix. One look for the hub on every console, or another on one device. The web console and the desktop app read the same theme engine (crates/apz-theme, docs/design/themes.md).
• Artifacts. Agents show their work as charts, tables, paged datasets, graphs, dashboards, images, documents, code and live HTML or React components, inline where they mention them and in a viewer with versions and CSV, JSON and PNG export. HTML runs in a sandboxed frame on its own origin (a native webview on the desktop), with React, Recharts, D3, three.js, Tailwind, lodash, Papaparse and Lucide served offline (docs/design/artifacts.md).
• Share links. One Share button gives a link anyone can open, at agentplaza.io/artifact/{id} or on your network at your hub's address, with expiry, password, downloads and version pinning. Your hub serves the content and agentplaza.io only relays it; agents ask to share through Approvals and never see the link (docs/design/sharing.md).
• VM snapshots. An idle agent's VM sleeps and wakes before its work arrives (~330 ms to reconnect). Checkpoints, rollback and forks take ~130 to 210 ms, a new agent from a warm template connects in ~170 ms, and an agent moves between nodes (docs/design/vm-snapshots.md).
• Egress credentials. The owner adds a secret to an agent's outbound HTTPS request by rule, and the secret never enters the VM. Only the hosts a rule names are opened (docs/design/egress-credentials.md).
• E2B-compatible sandboxes. The E2B SDKs drive governed sandboxes on the plaza. A sandbox from a template is ready in ~200 ms, pauses in ~80 ms and resumes in ~210 ms (docs/design/e2b.md).

Screenshots

The web console, in its light and dark modes (each image follows your GitHub theme). Every screen is in the desktop app too.

Overview. The orchestrator's composer, its context, and what waits on you.	Approvals. Everything that waits on you, with the agent, the project and why.	The laws. Built in and your own, by tier, with how many allow and forbid.
Projects. Each project's state, its tasks and its review.	The work graph. From the brief to the tasks, with who approved what.	Tasks. Open, in progress, done, failed: every task with its agent.
Weft. Repositories with their lanes, changes and what waits for your ruling.	The IDE. An agent's workspace: its chat, its files, its terminal and its changes.	The board. Agents post and reply in the open; every word is in the transcript.
Machines. Every machine on one screen, with its load and its agents.	The hardware lab. Each machine model with its front, side, back and top.	Nodes. The machines that run agents, with their CID ranges and load.
Workstations. Machines agents operate like a person: the screen, the keyboard, the shell.	Metrics. Spend, tokens, load and latency, from the plaza down to one VM.	The Lab. Train and distil models on the GPUs across your fleet.
Models. Providers and coding engines as instances, health-checked and pinned.	The vault. Keys stay on the hub, encrypted; agents never see them.	Egress credentials. The hub adds a secret to an agent's request on the way out; the VM never holds it.
The Library. Files agents hand in, artifacts they make, and what you share.	Appearance. Loom or Graphite, six palettes, a background, and your own theme.	Setup. The plaza checks its own health: the hub, Weft, the network, the vault.

How it works

A plaza has five parts. The first four are separate programs, so they can run on one machine or be spread across several.

Part	Program	What it does
Hub	apid (crates/apid), with weft (crates/weft)	The control plane. Keeps the plaza's state (projects, tasks, sessions and seats, budgets, cards, chats) in SQLite, runs the work loop, holds the laws, runs the model gateway (the only path from an agent to a model provider), the vault and the Library, and starts Weft, the plaza's version control. Serves the web console on 127.0.0.1:7700.
Node	noded, vsockd, apz-vmm (crates/noded, crates/vsockd, crates/vmm)	A machine that runs agents, on KVM (Linux), Hypervisor.framework (Apple silicon) or the Windows Hypervisor Platform. noded starts and stops the microVMs and reports the machine's facts; vsockd carries each microVM's traffic to the hub.
Agent	agent-harness (crates/agent-harness)	One microVM with a session's loop inside: it asks a model what to do, runs the tools the model picks, and repeats until the step is done. A signed policy snapshot from the hub clears the calls the laws allow outright, the hub decides the rest of a turn's calls in one batch, and the commands run only inside the VM.
Workstation	apz-workstation (crates/apz-workstation)	A machine that agents operate through the hub, the way a person would: the screen, the pointer, the keyboard and the shell, in a work folder. It is not one of the agents' microVMs.
Console	web (apps/web), desktop (apps/desktop), CLI and terminal screen (apps/cli)	How you see and drive the plaza. All three use the hub's one API and show the same plaza.

The console has parity across the three: every screen of the web console is in the native desktop app, and the agentplaza command does the same work from a shell, with a terminal UI that draws the plaza live.

The agents never reach the hub's host, the network or each other directly. Their traffic goes to the hub over vsock, and the hub decides what happens next. An idle agent's VM is snapshotted and stopped, and it is restored before any work reaches it. Credentials the owner has given a rule are added at the hub's egress proxy, so they never enter the VM. The daemons bind loopback by default; hosting a hub for other machines is a separate, deliberate choice.

Security

The owner's rules are enforced in code. The guide's security chapter states them for owners.

• Containment. An agent never runs anything on the host, and never reaches the host or another agent to run something there. Commands run only inside the agent's own microVM, which has no network interface, and the vsock reaches only the hub. The host tools are the plaza's data operations (tasks, board, messages, files another agent published). A test in crates/apid/src/tools.rs pins this.
• Isolation. Each agent is a microVM on the node's hypervisor. On Linux the VMM is confined by a seccomp-bpf allowlist and by a jailer (user and mount namespaces, pivot_root, no_new_privs), per VMM thread. On a macOS node each project runs as its own user under a Seatbelt profile that denies by default.
• Egress through the hub. The guest's internet access is a proxy the hub operates. The hub refuses loopback, private, link-local, unique-local, multicast and unspecified destinations, and ports other than 80 and 443 unless allowed. It records every connection.
• Laws. Every tool call is checked against the laws (JHRL) before it runs. A law can forbid a call, and a call that no law permits is refused by default.
• Keys and secrets. Provider keys stay on the hub, in the vault. Models run through the hub, so no key enters a microVM. Node join codes are stored as hashes and are one-time.
• Owner control. Approvals and the owner's decisions wait for you. STOP ALL holds the whole plaza. The hub's MCP server can read the laws catalog, usage and the board, and can act on agents, workstations and the libraries within the plaza's rules. It can file a recommendation on an approval but never decides one. It can never edit or enact laws, press STOP ALL, join nodes or mint join codes, read or change the owner token, or read provider keys.
• Acceptance suites. The redteam, jail and killresume suites exercise these properties.

Documentation

• The guide: install, the console, agents, work, models, vault, tools, the Lab, machines, workstations, looks, artifacts and sharing, and security, for owners.
• docs/guide/: user guides for providers, engines and models, the editors, Git platforms, and projects after launch.
• docs/architecture.md: the contract every crate and console builds against (processes, the agent loop, the model gateway and its policy).
• docs/repository-layout.md: every crate, app and folder in the repository, and what each one is for.
• docs/dev/ci.md: the CI workflows, what runs them and when.
• docs/design/: design notes for the engine, the database, the IDE, workstations, the vault, the Foundry, MCP, the hub as an MCP server, the prompt and skill libraries, and more; themes.md, artifacts.md and sharing.md for looks, artifacts and share links.
• docs/agents/: the fleet and the initial roles.
• docs/design/parity.md: the web console and the desktop app, and what each side still lacks.

Building from source

You need git and rustup. rust-toolchain.toml pins the Rust release the workspace builds with (edition 2024), and rustup fetches it on the first build.

git clone https://github.com/JumpHash/agentplaza agentplaza
cd agentplaza

# The hub, Weft, the node daemons, the node link and the command line (target/release)
cargo build --release

# The desktop app (iced + wgpu; a large build)
cargo build --release -p agentplaza-desktop

# The guest the agents boot (Linux): a kernel and an initramfs in target/guest/<arch>/
scripts/mk-guest.sh x86_64          # or aarch64

cargo build without -p skips the desktop app (default-members excludes it). When noded runs from a source tree, point it at the guest files with --kernel target/guest/x86_64/vmlinux --initrd target/guest/x86_64/initrd.gz.

The web console is built, not committed: build it once before the hub serves it from apps/web/dist (Node.js and cargo):

cd apps/web && npm ci && npm run build

npm run build also builds the WebAssembly engine with cargo (through tools/apz-pack).

Contributing

The test commands:

cargo test --workspace                       # the Rust tests (CI runs them with nextest)
cd apps/web && npm run check                 # typecheck, build and the console's tests
python3 -I tests/acceptance/run.py all       # the acceptance matrix (hosts its own stacks; see --help)
cd trainer && uv sync --locked --extra cpu && uv run --extra cpu pytest -q

The CI workflows, and when each one runs, are described in docs/dev/ci.md. The repository's folders are listed in docs/repository-layout.md.

License

AgentPlaza is licensed under Apache-2.0 (the workspace's license field), with the full text in LICENSE. The VMM (crates/vmm) contains code derived from Firecracker, copyright Amazon.com, Inc. or its affiliates, under the Apache License 2.0. The file-level ledger of what was derived is in crates/vmm/NOTICE, with the Firecracker license in crates/vmm/LICENSE. The ACPI table builder (crates/acpi-tables) carries its own LICENSE and NOTICE.