Build or Buy? Agent-Developer Workspaces | Monaco
Log inRequest demo<br>Open menu
← Back to blog<br>The Million Interns Initiative<br>Last year, we became deeply invested in realizing the vision of industrialization of automated software development. At Monaco, we originally called this the “Million Interns” initiative. The rough concept was “what if I can work in 1 ‘manager’ agent that spins off dozens of ‘intern’ agents to handle individual tasks?” With Linear being an early MCP adopter, it became possible to define and organize the work in an obvious source of truth. A bit of digging found a tmux MCP server option to kick off claude|gemini|aider --prompt "..." in a different session pane, maybe add some iTerm2 notifications when input is required, mint a new Git worktree, spin off a tmux session, add one long-winded AGENTS.md and viola our goal is realized…
Sadly, this did not work well. This approach had a number of problems:<br>Tmux is not a universally loved interface for developers to work in<br>Ports clashed on localhost<br>Docker daemon resource contention<br>Git worktrees are pretty flimsy and require some setup (eg. pre-commits, venv, pnpm)<br>Bloated local disks required constant pruning<br>There wasn’t an elegant solution when notifying the human in the loop for inputs<br>A couple of us tried this for a bit but this was never adopted company-wide and quickly went by the way-side.<br>Claude Code Evangelism<br>We saw a huge swell of adoption in Claude Code usage at Monaco in late 2025 and early 2026 when Opus 4.6 was released. Developers were starting to do more agent sessions in parallel across work trees and learning how to context switch between their sessions.
Around this time, Ramp published an article about Inspect, their built-in-house AI coding agent and orchestration tool. A month later, Stripe published their version, Minions. Meanwhile, our team had been casually exploring various agent orchestration platforms and technologies. We experimented with Cyrus and found some success and inspiration. While looking around for a suitable solution for our own development, we noticed some familiar gaps and new issues among vendors:<br>They lacked a populated data plane.<br>It was a challenge to consolidate all the divergent ways teams are running their services locally.<br>The cost is high for a Claude code wrapper when we are already paying for a team subscription.<br>The tradeoff between ease of maintenance, cost, and efficacy of these AI development orchestration platforms did not feel worth it at the time.
With that backdrop, our goal became to cost effectively run multiple agents in parallel, each with their own version of the application and APIs to exhaustively test against for their objectives, populated with test data that (safely) resembles that of a real production application, with a still-developer-centric approach to inter-operate sync/async, local/remote, agent-only/human-in-the-loop/by-hand development at any point.<br>Coder → Monacoder<br>Coder checked a lot of boxes for us. It got us up and running fast because it was open source with extensible, community-maintained Terraform modules. The workspace templates for AWS worked out of the box and were easy to version-control, and continuously deploy. Infrastructure orchestration was essentially solved on day one, and critically, Coder's control plane and everything it spins up never need a public IP. Environments live entirely in our VPC and are accessed over our VPN, with full access to our telemetry and integration with our intrusion detection stack.
Key decisions that shaped the implementation:<br>Control plane — runs on the existing Kubernetes cluster in our dev account, alongside our self-hosted CI infrastructure.<br>Workspace cardinality — 1:1, one app per VM.<br>Dependencies — baked into an internally-maintained AMI with everything needed to run Monaco locally; versioned and continuously deployed.<br>Ephemerality — workspace VMs are replaceable; the EBS volume persists across restarts and AMI updates but is not shared across VMs.<br>Runtime — docker-compose; we had services there already and didn't want to introduce k3s or microk8s.<br>Data plane seed — a one-time de-identified snapshot of our own Monaco sales org data. We use Monaco to sell Monaco, so we had a ready-made, realistic dataset with a small footprint.<br>DB writes — handled by the Postgres Kubernetes Operator (WAL to S3), making it trivial to clone any DB from its current state. The golden DB and all workspace clones live in Kubernetes.<br>Claude access — developers upload their claude setup-token to Secrets Manager, protected by ResourceTag IAM conditions scoped to workspaces owned by them.<br>Agent safety — no machine user proliferation; auth happens through OAuth-capable apps or personal API keys only.<br>MCPs wired in to start — Linear, Datadog (readonly), Postgres (workspace-scoped DB clone), and Coder itself.
Monacoder Workspace Infrastructure ArchitectureIt is worth mentioning Coder supports starting and connecting to Devcontainers...