Give Your Dev Team AI Teammates
Engineering managers use amux to deploy a fleet of Claude Code, Codex, or Gemini CLI agents alongside their engineers — each developer gains a parallel AI teammate that handles the backlog while they focus on architecture and review. Monitored from one dashboard or your phone. Updated July 2026.
Engineering managers use amux to multiply team velocity without adding headcount. Instead of each developer working on one task at a time, amux lets every engineer run 3–5 parallel AI agent sessions — tackling the backlog, writing tests, fixing bugs, and drafting docs simultaneously. amux is the open-source control plane that makes running an AI-augmented engineering team possible at the team level, not just the individual level.
The result: your developers spend their time on the work that requires human judgment — architecture decisions, code review, customer conversations — while agents handle the parallel execution work that currently creates context-switching bottlenecks.
What Does the Team Look Like When Running amux?
Here is a snapshot of what a 4-person engineering team might have active on a given sprint day:
| Session | Assigned To | Task | Agent |
|---|---|---|---|
| feat-auth-mfa | Dev A (agent) | Implement TOTP MFA flow + migration | Claude Code |
| fix-perf-dashboard | Dev A (agent) | Profile and fix slow dashboard queries (N+1) | Claude Code |
| test-payments | Dev B (agent) | Add integration tests for the billing module | Codex |
| docs-api-v2 | Dev B (agent) | Generate OpenAPI spec + usage examples for v2 endpoints | Claude Code |
| refactor-event-bus | Dev C (agent) | Migrate event handlers to the new async queue | Claude Code |
| triage-bug-queue | Dev D (agent) | Reproduce top-5 open bugs, write failing tests, tag severity | Claude Code |
All six sessions run simultaneously. The EM sees all statuses in one dashboard view. Developers review agent output in the afternoon and queue the next batch. The sprint throughput multiplies — without adding to the payroll.
How Does amux Actually Speed Up a Sprint?
The bottleneck in most sprints is not developer skill — it is context-switching. Developers jump between tasks, get blocked waiting on review, and lose flow state constantly. amux attacks this directly:
- Parallel execution: While a developer works on the hard problem that needs their full attention, agents handle the adjacent tasks — tests, docs, small fixes — in parallel. Nothing waits in queue.
- Overnight throughput: Queue a batch of well-defined tasks before end of day. Agents run with self-healing while the team sleeps. The morning standup starts from completed pull requests, not from "still in progress."
- Backlog drain: Those low-priority "we'll get to it" tasks — test coverage gaps, stale docs, deprecated API migrations — can run as background agent work without displacing sprint priorities.
- No babysitting: amux's self-healing watchdog restarts crashed sessions and handles context overflow automatically. The EM does not need to monitor terminals — the dashboard surfaces status, and alerts go to your phone only when something needs attention.
Without amux vs. With amux — Team Velocity Comparison
| Scenario | Without amux | With amux |
|---|---|---|
| Parallel tasks per developer | 1–2 | 4–8 (developer + agents) |
| Overnight throughput | Zero | Full agent fleet running |
| Backlog visibility (cross-team) | Jira / Linear board | Live amux board + session status |
| Test coverage gaps | Accumulate sprint over sprint | Addressed as background agent work |
| Agent crash recovery | Manual restart needed | Auto-restart in seconds |
| EM visibility into agent work | None | Live output peek from phone or desktop |
| Developer context-switching | High — blocked tasks stall progress | Low — agents handle adjacent work |
| Time from task definition to PR | 1–3 days | Hours (agent) + review time |
How Do I Roll This Out to My Team?
A practical rollout for a 3–8 person engineering team takes less than a day:
- Install amux per developer (5 minutes each):
Each engineer runs their own amux instance. No shared server required for the initial rollout.git clone https://github.com/mixpeek/amux && cd amux && ./install.sh - Register the shared project on each machine:
Theamux register myapp --dir ~/Dev/myapp --yolo--yoloflag disables per-command approval prompts — appropriate for feature branches where developers review at the PR level. For production-critical paths, omit it. - Write a team CLAUDE.md in the project root. Check it into version control so every agent session on every machine reads the same context: project architecture, branch conventions, test commands, what to avoid. This is the single highest-leverage thing you can do to ensure consistent agent output quality across the team.
- Define sprint tasks as amux board cards. The shared board is the coordination layer — everyone can see what is in-progress, who owns what, and what agents have completed. Map existing sprint issues from Jira or Linear into the amux board at the start of each sprint, or run both in parallel during an evaluation period.
- Launch agents from the dashboard or CLI. Each developer starts their agent sessions at the beginning of the day. The EM sees cross-team status from their own dashboard instance (or via the shared server setup for full cross-team visibility in one view).
- Queue overnight runs before end of day. Developers define the next batch of tasks on the board before they sign off. Agents run with self-healing. Morning standup reviews completed PRs.
For a guided setup, amux Concierge installs and configures the full team workflow for you, including CLAUDE.md templates, board structure, and overnight run scheduling.
Can I Run Agents Myself as the Engineering Manager?
Yes — and many EMs use amux this way even before rolling it out to their team. The EM use case is slightly different from the developer use case:
- Late-night batch work: You define 5–10 well-scoped tasks in the board before you go to sleep. Agents run overnight. You wake up to pull requests waiting for developer review — your team's morning is unblocked before they start.
- Backlog processing: Long-tail issues that never make a sprint — outdated tests, deprecated dependency migrations, doc gaps — can be batched into an agent run over a weekend without displacing sprint priorities.
- Spec-to-skeleton acceleration: Write the design doc, give it to an agent to generate the initial scaffold — routes, models, test structure — so developers start from a working skeleton rather than a blank file.
- On-call triage support: While on call, redirect an agent to investigate a failure mode — reproduce the error, trace the stack, write a failing test — so you have a head start before routing to the right developer.
Phone-First Monitoring — No Need to Be at a Desk
amux is designed for asynchronous management. You do not need to babysit a terminal to know what your agents are doing. From the amux mobile app (iOS PWA or native iOS app from the App Store):
- See every session's live status (working / waiting / idle) across the team
- Peek at any agent's live terminal output
- Send a steering instruction to redirect an agent that's going off-track
- Move board cards between todo / doing / done
- Check token spend across all sessions
For remote access from outside your local network, set up Tailscale on the amux server. See the team workflow setup guide for full configuration instructions.
How Does amux Scale Beyond 10 Agents?
A single amux instance on a modest VM can comfortably manage 10–20 concurrent agent sessions. Scaling beyond that follows two patterns:
- Vertical scaling (10–50 agents): Move amux to a larger VM — 8–16 vCPU, 32–64 GB RAM. tmux sessions are lightweight; the bottleneck is typically API throughput and disk I/O from simultaneous git operations, not CPU. See the running 10+ agents guide for tuning recommendations.
- Horizontal scaling (50+ agents): Run multiple amux instances with separate project registrations, or use the shared board as a coordination layer across instances. The scaling to 50 agents guide covers multi-instance coordination and task partitioning strategies.
Self-Healing Means Agents Run Overnight Without a Babysitter
The single most common concern EMs raise is: "what happens when something crashes at 2 AM and nobody's watching?" amux handles this automatically:
- Crash recovery: The watchdog detects a dead session within seconds, restarts it, and replays the last steering message. The agent resumes from the last checkpoint without manual intervention.
- Context overflow: When a long session fills the model's context window, amux triggers automatic compaction — the agent summarizes earlier context and continues. No session hangs waiting for a human to clear it.
- Stuck detection: Sessions that have produced no output for a configurable timeout are flagged as stale and restarted. Agents that get into a loop or wait forever for a tool response are recovered automatically.
Queue your overnight batch at end of day. The agents run. You review pull requests at standup.
Want the Team Set Up by the amux Team?
If you want to skip the setup and go straight to results, amux Concierge is a managed onboarding service. The amux team installs and configures the full team workflow — CLAUDE.md templates for your codebase, board structure mapped to your sprint process, overnight batch scheduling, and mobile access for the EM. The team hands it off to you running and walks your developers through the new workflow. It is the fastest path from "we want this" to "our team is shipping with it."
Start multiplying your team's velocity today
amux is open-source, free to self-host, and installs in minutes per developer. No per-seat fees, no vendor lock-in. Your engineers keep their existing workflows — amux adds the agent layer on top.
git clone https://github.com/mixpeek/amux && cd amux && ./install.sh
amux register myapp --dir ~/Dev/myapp --yolo
amux serve # → https://localhost:8822
Frequently Asked Questions
Do engineers need to learn new workflows to use amux?
No. Developers keep using their existing editors, git workflows, and PR review processes. amux manages tmux sessions in the background and surfaces agent output through a shared dashboard. Engineers who already use Claude Code or Codex CLI will feel at home immediately. For those new to AI coding agents, the amux board provides a familiar kanban interface for assigning tasks without requiring any terminal interaction.
Is amux safe to run in production repositories?
amux itself does not touch your repository — it manages the terminal sessions that agents run in. Safety is determined by how you configure those sessions. For production codebases, most teams run agents on feature branches only, require PR review before merging, and use CLAUDE.md to restrict what the agent is allowed to modify. The --yolo flag is appropriate for sandboxed feature branches; for production-critical paths, omit it so agents pause for human confirmation on destructive commands.
How does amux handle multiple engineers working on the same codebase?
Each engineer runs agents on their own git branches. The shared amux board acts as the coordination layer — everyone can see which tasks are in-progress, who owns what, and what agents have completed. Since agents work on isolated branches, there is no conflict at the file level. Conflicts happen at merge time, just like with any parallel development. For full cross-team visibility in a single dashboard, set up a shared amux server — all engineers' sessions appear in one view for the EM.
What does amux cost for a team?
amux is MIT licensed and free to self-host. Your costs are AI API tokens billed directly by Anthropic, OpenAI, or Google at standard rates. For a team of 5 engineers each running 2–3 parallel agent sessions during business hours, expect $200–800/month in total API costs — a fraction of one engineer-day per month. There is no per-seat fee, no SaaS subscription, no vendor lock-in. Use the cost calculator to model your team's specific scenario.
Can I see what all agents across the team are doing from my phone?
Yes. The shared amux board gives the EM a cross-team view of every active task and its status. For session-level output — the live terminal stream of what an agent is actually doing — you can peek at any session from the dashboard without logging into the developer's machine. Available on mobile from anywhere via Tailscale.
What happens when an agent crashes or runs out of context overnight?
amux's self-healing watchdog detects crashes within seconds and restarts the session, replaying the last steering message so the agent resumes where it left off. Context overflow triggers automatic compaction — the agent summarizes earlier context and continues without losing the thread of work. Queue overnight runs before leaving the office. Review completed pull requests at standup.