Self-hosted infrastructure for a fleet of long-lived AI agents. Each agent runs in its own sandboxed container with a persistent workspace, internet access, and a pluggable driver.

Yes. Single-VM deploy on plain Docker with your own keys and data. No vendor lock-in, no per-seat SaaS tax, nothing leaves your stack.

Which agent engines (drivers) are supported?

One identical API across swappable brains: Vanilla, Opencode, Codex, and Claude Code. The driver is part of an agent's config and can be swapped anytime.

How do you keep my data and agents secure?

Every agent runs in a hardened container: read-only root filesystem, dropped capabilities, network egress filtering, and CPU/memory limits. LLM keys are stored server-side, encrypted, and never sent to the browser.

Can I watch what an agent is doing?

Yes. Every task streams over Server-Sent Events (assistant messages, tool calls, results, file changes, a live token meter), and reconnects resume where they left off.

Accounts are provisioned by admins; you self-host the stack. Use Get started, or sign in if you already have an account.

Multi-Agent Coding Orchestration Is Ops Now

Multi-agent coding orchestration works best when agents run in parallel, but accountability stays serialized. Let agents research, test, review, and implement in bounded slices. Then force every result through visible diffs, logs, pull requests, validation evidence, and human or policy-controlled review.

This is for engineering leaders and platform teams evaluating agent fleets for real software delivery. The question is no longer whether several coding agents can work at once. They can. The question is whether your team can keep branches, runtime state, secrets, review quality, and merge decisions under control while they do.

Why multi-agent coding orchestration is ops

Vendor docs have moved beyond single-chat coding. Claude Code documents parallel sessions with Git worktrees and custom subagents. Codex web can run cloud tasks in the background and in parallel. OpenCode has configurable agents for implementation, codebase exploration, and external dependency research. Warp describes local tabs, worktrees, and cloud orchestration. GitHub Copilot cloud agent works through branches and PRs. VS Code is moving toward one surface for managing Claude, Codex, and Copilot sessions.

That shift changes the bottleneck. A team does not need ten agents all editing the same files. It needs a controlled way to assign ten bounded jobs, isolate them, inspect the outputs, and decide what lands.

The workflow that holds up

Start with an issue, bug report, migration plan, or product spec.
Split it into bounded slices: research, implementation, tests, docs, migration checks, or review.
Route each slice by model, tools, permissions, cost, and repo area.
Run each agent in an isolated branch, worktree, container, or cloud sandbox.
Require validation evidence: tests run, changed files, known risks, and unresolved questions.
Review diffs and logs before merging anything.
Reconcile the winning outputs into one owned branch or PR.

The short version is parallel execution, serialized reconciliation. That is the difference between throughput and chaos.

Route by risk, not model preference

The newer tools make routing more concrete. Claude Code subagents can have separate context windows, prompts, tool access, model choices, permission modes, MCP scope, hooks, and optional worktree isolation. Codex subagents run only when explicitly asked and inherit sandbox controls unless changed. OpenCode supports agents such as general, explore, and scout with per-agent permissions.

A read-only research task can use no write permission. A risky database migration should run in a tightly scoped branch with stricter approvals. A test-generation task can be limited to test directories. A dependency research task may need external docs access but no edit rights. A final reviewer should inspect diffs and run safe commands without being allowed to write.

Worktrees solve files, not runtime state

Git worktrees solve one important problem: file collisions. Each agent gets its own files and branch, then humans compare diffs later.

But agents can still collide on local databases, ports, environment variables, package caches, browser sessions, background services, queues, seeded test data, and secrets. MindStudio's practitioner guidance calls out dev servers fighting over one port and shared database mutations invalidating tests. The fix is to assign ports, disposable databases, test data scope, environment files, browser profiles, and cleanup rules.

Cloud sandboxes help because they isolate more state by default, but they move trust into cloud setup scripts, internet access policies, CI rules, and secret handling.

Approval gates are part of orchestration

The same question appears across products: when should the agent stop, and who decides? Claude has permission modes and hooks. Codex has sandbox and approval behavior. OpenCode supports ask, allow, and deny settings. GitHub Copilot cloud agent has workflow approval and firewall controls.

GitHub's warning is concrete. If Copilot cloud-agent GitHub Actions workflows run without approval, unreviewed Copilot-written code can receive repository write access or Actions secrets. As of the March 13, 2026 changelog, admins can choose to skip that approval, but human approval remains the default. GitHub also limits internet access by default to reduce exfiltration risk, and an April 2026 changelog added organization-level firewall settings.

Before agents write code, answer these questions:

Which agents can edit files?
Which agents can run shell commands, tests, package installs, or setup scripts?
Which agents can access the internet, MCP tools, secrets, or CI workflows?
Which outputs require human approval before merge, deployment, or workflow execution?

What to measure

Speed alone can lie. More PRs can still mean slower delivery if review load, conflicts, flaky tests, and rework rise faster than useful output.

Agent tasks started, completed, discarded, and merged
Median review time per agent-created PR
CI pass rate before and after reconciliation
Merge conflict rate by repo area
Rollback or defect rate for agent-assisted changes
Human interruption rate and approval volume
Token, model, cloud, and CI cost per merged change

GitHub already exposes Copilot cloud-agent PR lifecycle metrics such as total PRs created and merged, Copilot-created PRs merged, and median time to merge. That is a start. Teams still need their own data on review capacity and defect rate.

What good looks like

A good agent fleet feels boring. Every agent has a task, workspace, permission profile, and validation command. Every finished run reports changed files, tests, risks, and open questions. Every merge decision has an owner. Every discarded branch can be deleted without drama.

The opposite is easy to spot: three agents edit the same files, two invent incompatible architecture decisions, one passes tests against shared state that no longer exists, and the human reviewer spends the afternoon reconstructing the story.

The priority is not the number of agents running. It is the number of agent outputs your team can safely understand, validate, merge, and maintain.