# Build or buy an agent developer workspace? > Source: > Published: 2026-07-09 18:25:47+00:00 # Build or Buy? Agent-Developer Workspaces Learn how Monaco is accelerating developer productivity using cloud-hosted, cost-effective, agent-developer workspaces at scale. ## The Million Interns Initiative 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](https://linear.app/changelog/2025-05-01-mcp) 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](https://github.com/nickgnd/tmux-mcp) 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](http://agents.md) and viola our goal is realized… Sadly, this did not work well. This approach had a number of problems: - Tmux is not a universally loved interface for developers to work in - Ports clashed on localhost - Docker daemon resource contention - Git worktrees are pretty flimsy and require some setup (eg. pre-commits, venv, pnpm) - Bloated local disks required constant pruning - There wasn’t an elegant solution when notifying the human in the loop for inputs A couple of us tried this for a bit but this was never adopted company-wide and quickly went by the way-side. ## Claude Code Evangelism 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](https://builders.ramp.com/post/why-we-built-our-background-agent) about Inspect, their built-in-house AI coding agent and orchestration tool. A month later, Stripe [published their version](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents), Minions. Meanwhile, our team had been casually exploring various agent orchestration platforms and technologies. We experimented with [Cyrus](https://www.atcyrus.com/) 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: - They lacked a populated data plane. - It was a challenge to consolidate all the divergent ways teams are running their services locally. - The cost is high for a Claude code wrapper when we are already paying for a team subscription. 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. ## Coder → Monacoder [Coder](https://coder.com/) 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: **Control plane**— runs on the existing Kubernetes cluster in our dev account, alongside our self-hosted CI infrastructure.** Workspace cardinality**— 1:1, one app per VM.** Dependencies**— baked into an internally-maintained AMI with everything needed to run Monaco locally; versioned and continuously deployed.**Ephemerality**— workspace VMs are replaceable; the EBS volume persists across restarts and AMI updates but is not shared across VMs.** Runtime**— docker-compose; we had services there already and didn't want to introduce k3s or microk8s.** 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.**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.**Claude access**— developers upload their claude setup-token to Secrets Manager, protected by ResourceTag IAM conditions scoped to workspaces owned by them.**Agent safety**— no machine user proliferation; auth happens through OAuth-capable apps or personal API keys only.** MCPs wired in to start**— Linear, Datadog (readonly), Postgres (workspace-scoped DB clone), and Coder itself. It is worth mentioning Coder supports starting and connecting to Devcontainers natively; we put a good chunk of work behind getting that working for our app. This became a complicated architecture for several reasons: 1) interacting with Docker Compose from a Devcontainer implies nested (Docker-in-Docker) or host-mounted (Docker-out-of-Docker) container virtualization, 2) building, caching, and optimizing the Devcontainer image itself so it is quick and easy to start up is not a negligible effort, and 3) AWS-native integration like IAM instance profiles, EBS volumes, and security group network access all required some additional hack to get them working in the Devcontainer. For these reasons, we just went with occasionally building an internal AMI with Packer which pre-installed all our system dependencies. We got this working well and called our series of curated workspace templates **Monacoder**. All in, the above took 1 cloud platform engineer, [John Tracy](https://www.linkedin.com/in/jwtracy/), about 2 weeks of dedicated effort to achieve. Though it does not entirely sport feature-complete deployments of Monaco, it has averaged weekly usership of about half of our ICs and growing since it has been released. Many folks use 3-6 agent workspaces at a time, often submitting several prompts before lunch, commutes, or signing off to keep drafting PRs while AFK. This brought its own new challenge of context switching at this scale and getting comfortable with something engineers have long-believed ultimately impedes productivity, multi-tasking. A powerful workflow using Monacoder has been reviewing your own PR drafts and directing the Monacoder workspace template system prompt poll for review comments and failing CI checks to address them automatically. Combined with our usage of [Devin.ai](http://devin.ai) and [Hex](https://hex.co/) static security scanning PR reviews, this platform has greatly accelerated our time-from-prompt-to-quality-code. Paired with repo-defined skills mentioned in Monacoder’s system prompts for `/watch-and-address-pr-comments` and `/watch-and-address-ci-failures` , we often see a few rounds of agent-driven quality and security improvements *before* human reviews. The Monacoder system has been surprisingly low-touch so far without many blocking issues requiring immediate attention. Particularly, the shared “golden” database and its Postgresql operator clones have never had any issues apart from obvious Alembic migration version skew. Similarly, about the only extra incurred cost is a handful of Pods/Nodes in EKS, a few dozen small-medium size workspace VMs at any given time (Coder supports scheduled instance hibernation after X hours of inactivity), and some NAT gateway egress charges due to installing dependencies and using Anthropic as a model provider. We extended Monacoder’s initial success criterion to support additional agent interaction surface areas beyond the Coder UI. We also implemented an assignable Monacoder Linear agent which receives delegation webhook events and uses Coder Tasks on behalf of the delegator to spin up workspaces with context from the Linear issue and immediately begin work. A similar recent extension was adding a Github Webhook event for PR’s labeled with `monacoder` to surface UI previews for frontend changes. We want to continue adding functionality to Linear, Github, and Slack touch points in the near future to have Monacoder meet developers where they work and become, the definitively obvious choice for development. ## Fleeting or Foundational? Time will tell if Monaco’s developer experience engineering can keep pace with the burgeoning competition in the agent coding environment industry. Cursor’s latest cloud environments auto-running your app on effectively sandboxed VDI deployments with touchpoints in all the above mentioned, mobile, and more is an extremely compelling product for this problem-space which some developers at Monaco have been pivoting to. Similarly, [Niteshift](https://niteshift.dev/) has an awesome approach to the seeded data plane issue using Neon and has recently launched their product mid-June, rich with up-market governance feature. That said, the reality of how quickly and frequently we are all pivoting to the latest and greatest models, harnesses, and technologies provide a compelling argument to build something in-house that has the capacity to be free of vendors and model provider agnostic for the time being. If systems like this interest you, we are currently hiring a [Senior Developer Experience Engineer](https://jobs.ashbyhq.com/monaco/d1d6c47f-5649-4127-946b-01f7d8ecf565) to continue trail blazing this initiative and many others. In the next article, we will discuss our in-house solution to AI Slack assistants with SRE-type use cases.