amux for Enterprise Engineering Teams

Run a parallel AI engineering team on your own infrastructure. Self-hosted, audit-logged, no vendor lock-in — Claude Code, Codex, and Gemini CLI agents working from a shared task board across all your repositories. Published July 2026.

amux is an open-source control plane for AI agent teams. It launches, monitors, and self-heals simultaneous AI coding sessions across every repository your team owns — with a shared kanban board for task coordination, event-sourced execution logs for compliance, and CLAUDE.md–enforced code quality standards. One Python file. Zero external services. Deploy on a VM inside your VPC. 300 GitHub stars, MIT + Commons Clause licensed.

What enterprise engineering teams are solving with AI agents in 2026

The question most engineering leaders are navigating right now is not whether to use AI coding agents — it is how to use them at team scale without losing code quality, introducing security risk, or creating an ungoverned shadow-IT situation where individual engineers run agents however they prefer.

The failure mode at enterprise scale: individual engineers run Claude Code locally in ad-hoc sessions. There is no shared visibility into what agents are working on. Two agents touch the same file. One runs against production credentials because the dev had an open shell. A session fails overnight and nobody knows. The agent commits directly to main because YOLO mode was on. There is no audit trail when a compliance team asks "what exactly did the AI change and why?"

amux addresses this at the infrastructure level. It is a coordination layer, not just a launcher — it enforces isolation, logs everything, and gives the team a single pane of glass for every running agent across every repo.

Self-hosted deployment: code stays inside your network

amux runs on any server your team controls — an EC2 instance in your VPC, an internal GCP VM, an on-prem box. There are no amux cloud accounts, no data transmitted to amux servers, and no external API dependencies beyond the AI model providers your team already uses (Anthropic, OpenAI, or Google). The server is a single Python file. Deploy it in under five minutes:

# On your team's VM or server
pip install amux   # or: uvx amux serve (zero-install)
# or: brew install mixpeek/amux/amux (macOS)

amux serve --host 0.0.0.0 --port 8822
# Dashboard accessible at https://your-server:8822 for your whole team

Because amux is a single Python file with no external dependencies, it passes most enterprise security review processes faster than SaaS tools: the full source is auditable, there is no third-party CDN, and you can pin a specific commit and diff upgrades before deploying. For environments that prohibit internet egress during code execution, amux can run fully air-gapped — agents use only locally installed CLI tools and your internal git remotes.

Shared kanban board with atomic task coordination

The core coordination primitive in amux is a kanban board backed by a SQLite database on the server. Every engineer and every agent shares the same board. Tasks move through `todo → doing → done → verified`. Agents claim tasks atomically via SQLite compare-and-swap — if two agents try to claim the same task simultaneously, exactly one succeeds and the other gets the next task. This prevents the most common multi-agent failure: two agents writing conflicting implementations of the same feature.

# An engineer adds tasks to the shared board
amux board add "Refactor UserService to use repository pattern — see ADR-042"
amux board add "Add rate limiting middleware to /api/v2/* routes"
amux board add "Write integration tests for PaymentProcessor class"

# Multiple agents claim and work in parallel — no overlap
# Session agent-1 atomically claims "Refactor UserService"
# Session agent-2 atomically claims "Add rate limiting"
# Session agent-3 atomically claims "Write integration tests"

Board state is the single source of truth for all active agent work across the team. Engineering managers and tech leads can see at a glance which agent is working on which task, what is queued, what is done but not yet verified, and what is verified in production — without reading terminal output or checking individual git branches.

The board also enforces a distinction between done (agent has opened a PR) and verified (a human has reviewed, CI is green, and it is deployed to production). Agents never self-promote to `verified` — that requires a human to confirm the full pipeline end-to-end. This is an important control for teams that want to track what agents shipped vs. what has actually been validated.

CLAUDE.md: organization-wide code quality enforcement

Every amux session reads the CLAUDE.md file from the project root before starting any task. This file is committed to your repository — it is version-controlled, peer-reviewed, and applies uniformly to every agent that ever works in that repo. It is the mechanism for encoding your team's standards into agent behavior without building a custom agent wrapper.

A well-written team CLAUDE.md for an enterprise repo typically includes:

• Architecture decisions that agents must follow (service layer patterns, dependency injection conventions)
• Which libraries are approved vs. prohibited (no new ORM dependencies, use the existing HTTP client)
• Security requirements (no secrets in code, no SQL string interpolation, all user input validated at the controller layer)
• Testing standards (unit tests required for all new functions, integration tests for all API endpoints)
• PR conventions (branch naming, commit message format, PR description template)
• Repo-specific gotchas (known performance cliffs, deprecated APIs to avoid, modules under active rewrite)

Because CLAUDE.md is checked into the repo, it is subject to the same PR review process as code. When your team's conventions evolve, you update CLAUDE.md in a PR, get it reviewed, and all subsequent agent sessions immediately reflect the updated standards. No agent configuration to update, no model fine-tuning — just a markdown file in the repo root.

Event-sourced execution logs for compliance and audit

amux maintains an append-only execution log per session. Every agent action — message sent, tool call, file write, context compaction, restart, resume — is recorded with a timestamp and session identifier. The log is accessible via the dashboard and the REST API.

This gives compliance teams a direct answer to "what exactly did the AI change and when?" without reconstructing history from git blame. Combined with git commit attribution (each session's commits are attributed to that session name), you get a full audit trail: which human queued the task, which agent session picked it up, what the agent did step by step, and what ended up in the final PR.

For SOC2 or ISO 27001 audits, the relevant controls are:

• Change management: All agent changes go through PRs, reviewed by humans before merge. Agents never push directly to main.
• Access control: Agents run with the credentials of the user who launched the session. No shared credentials, no agent-specific service accounts required.
• Audit logging: Event-sourced execution log per session, retained on your server.
• Data residency: All code and logs stay on your infrastructure. The only data leaving your network is the AI model API calls (to Anthropic, OpenAI, or Google, depending on which runtime you use).

Multi-runtime: no vendor lock-in on AI providers

amux is multi-runtime from the start: each session declares its runtime — Claude Code (Anthropic), Codex CLI (OpenAI), or Gemini CLI (Google). You can run sessions using different AI providers simultaneously on the same amux instance. This matters for enterprise teams that need to:

• Comply with data processing agreements that restrict which model providers can see which codebases
• Use the best model for a specific task type (e.g., one provider is better at TypeScript refactors, another at SQL migration scripts)
• Avoid single-vendor dependency for a critical infrastructure component
• Test model performance across providers before committing to a company-wide agreement

Team dashboard: one view for all agent activity

The amux web dashboard at https://your-server:8822 is designed for team visibility. Multiple engineers can have it open simultaneously. Changes update in real time via SSE — when an agent claims a task, it appears as "doing" on everyone's board within about 2 seconds. When a session emits output, the live-tail view updates for anyone who has it open.

Key team-facing views in the dashboard:

• Sessions grid: All running agents, their current status, token spend, uptime, and last output line at a glance
• Board: Shared kanban with per-agent assignment, task status, and quality gate acknowledgment
• Peek panel: Click any session to tail its live output — useful for quickly verifying an agent is on track without sshing into the machine
• Event log: Per-session append-only execution history for compliance and debugging
• Scheduler: Recurring tasks assigned to specific sessions (e.g., "run security dependency audit every Monday at 9am in the infra-maintenance session")

The iOS native app and PWA give team leads and engineering managers the same view from a phone — useful for checking agent status during off-hours or approving a task queue change without opening a laptop.

Enterprise vs. self-managed comparison

Deploying amux for your team

The recommended enterprise setup is a shared Linux VM (EC2, GCP Compute Engine, or on-prem) that all engineers and agents use as the coordination hub. Individual engineers can still run local sessions, but the shared board, scheduler, and logs live on the server. The server runs continuously; agents connect to it from whatever machine they're running on.

1. Install on your team's server.

   # Recommended: pipx for isolated install
   pipx install amux
   
   # Zero-install alternative (no pip)
   uvx amux serve --host 0.0.0.0 --port 8822

2. Add org-wide CLAUDE.md to each repository. Start with your most important repo. The CLAUDE.md should encode standards that currently live only in team memory — things a new engineer would get wrong on their first PR. Commit and have it reviewed like any other change.
3. Register sessions per team or repo.

   # Register one session per active workstream
   amux register backend-agents --dir /repos/backend --yolo
   amux register frontend-agents --dir /repos/frontend --yolo
   amux register infra-agents --dir /repos/infrastructure --yolo

4. Use the board for task assignment. Train your team to add well-scoped tasks to the board instead of giving agents open-ended prompts directly in sessions. Well-scoped board tasks are the single biggest lever for overnight output quality.
5. Set quality gates on the board. Use the board's `gate_checked` array on high-stakes task types (security changes, database migrations) to require agents to explicitly acknowledge checklist items before marking a task done.
6. Restrict push access. Configure your git remotes so that the agent-running user can push to feature branches but not to main/protected branches. PRs are the merge point — agents open them, humans approve them.

For teams that want a hands-on guided setup — including CLAUDE.md templates, CI integration patterns, and board workflow design for your specific team structure — see the amux Concierge.

Frequently asked questions

Can enterprise teams run AI coding agents on their own infrastructure?

Yes. amux is a single Python file with zero external dependencies. It deploys on any Linux server your team controls — EC2, GCP, on-prem — with no data leaving your network except AI model API calls to your chosen provider. Full source is auditable. No third-party CDN. Deploy from a pinned commit.

How do agents coordinate on a shared codebase without overwriting each other?

Atomic SQLite compare-and-swap task claiming means exactly one agent can hold a task at a time. Each agent works in its own isolated git worktree — structurally preventing file-level conflicts. The shared board is the coordination layer. Two agents cannot work on the same task simultaneously by design.

How does amux handle code quality and style consistency?

CLAUDE.md in each repo root is read by every agent session before starting a task. It is version-controlled, reviewed in PRs, and applies to all agents uniformly — no per-agent configuration required. When your standards evolve, update CLAUDE.md and the change applies to all subsequent sessions.

What does the audit trail look like for agent actions?

An append-only execution log records every agent action (message, tool call, restart, resume) per session with timestamps. Accessible via dashboard and REST API. Combined with git commit attribution, you get a complete reconstruction of what each agent did and why — sufficient for SOC2 change management controls.

Does amux support multiple AI model providers?

Yes — each session declares its runtime: Claude Code (Anthropic), Codex CLI (OpenAI), or Gemini CLI (Google). Different sessions can use different providers simultaneously. This avoids single-vendor dependency and lets you route task types to the best available model per your data processing agreements.

pip install amux
amux serve --host 0.0.0.0 --port 8822
# Dashboard at https://your-server:8822 for the whole team

Related resources: Getting Started Guide · Team Workflow Setup · Claude Code Headless Mode · AI Coding While You Sleep · AI Agent Quality Gates · Concierge