Introducing Murmur

For the last two months, 90% of the code we shipped at Macroscope was orchestrated through an internal tool we built for ourselves.

It allowed each of our engineers to direct dozens of cloud agents in parallel and dramatically increased the amount of software we could ship. We loved this tool so much that we decided to turn it into a product that we serve to customers. We call it Murmur.

A murmuration is a natural phenomenon where hundreds of starlings move as one, wheeling through the sky in tight coordination. Murmur brings that same idea to software development: allowing engineers to direct a coordinated fleet of coding agents in the cloud.

In this post, we’ll explain why today’s coding agents are bottlenecked, how Murmur removes those bottlenecks, and what changes when a single engineer can keep dozens of agents moving at once.

The problem

A single engineer might be capable of directing dozens of productive agents, yet in practice can only keep a handful moving at once.

Not because the models aren’t capable, but because the tooling around them hasn’t caught up.

If you work like most engineers today, you have a few terminal windows open, an agent running in each, and every one of them halting the moment it needs your attention. You spend the day bouncing between tabs, unblocking agents one interruption at a time. Your output is capped not by what the models can do, but by how many agents you can personally keep moving.

The first bottleneck is the development environment itself. Coding agents can only work autonomously on complex tasks if they can verify their own work: running the code, executing tests, interacting with the UI, and inspecting the results. That requires a real development environment. Laptops were built for developers, not fleets of developers. Even the most powerful machine struggles to run multiple fully grounded software stacks in parallel.

The second bottleneck is everything that happens after the code is written. Opening a pull request is often the beginning of the process, not the end. Review comments arrive. CI fails. The branch falls behind. Merge conflicts emerge. A change can spend far more time moving through the GitHub lifecycle than it spent being implemented.

The result is a strange mismatch: the models are ready to keep working, but the systems around them aren't. The bottleneck is no longer writing code. It’s keeping work in motion.

We felt this ourselves. We lived the meme of leaving laptops open on the nightstand, on the kitchen counter, even outside the bathroom door, just to keep our agents moving forward.

So we built something better.

The solution

Murmur keeps work in motion.

It gives every agent its own development environment, connects every agent to the GitHub lifecycle, and allows engineers to coordinate entire fleets of agents from the tools they already use. Instead of stopping at a pull request, agents continue working until the change has landed.

A few core capabilities make this possible.

Cloud sandboxes

Coding agents can only work autonomously on complex tasks if they can verify their own work: running the code, executing tests, interacting with the UI, and inspecting the results.

Every Murmur agent runs inside its own dedicated cloud VM, provisioned to your specifications, with your repository checked out and your stack running. In our organization, that means each VM runs a single node kubernetes cluster running dozens of microservices.

You are no longer limited by how many development environments your laptop can support. Every task gets its own VM, allowing agents to run in parallel without competing for local resources.

Because each agent has a complete development environment, it can run tests, launch services, interact with the UI, and validate its implementation before opening a pull request that includes screenshots, recordings, and evidence that it actually works. By default, agents are provisioned to run on VMs in Murmur’s cloud environment with little setup, but you can also easily configure your agents to run on VMs in your own cloud environment for tighter security and coupling with internal services.

Self-driving

Coding agents have made writing code dramatically cheaper and easier. But opening a pull request is often only half the battle.

Review comments arrive. CI fails. The branch falls behind and merge conflicts accumulate. A change can spend as much time moving through the GitHub lifecycle as it spent being implemented.

Murmur agents are connected directly to those lifecycle events.

They respond to review comments as they arrive. Repair failing checks. Rebase when branches move. Resolve merge conflicts. Murmur shepherds the task forward until the pull request is clean and ready for human approval.

Opening a pull request is no longer the finish line. It’s just another step in the loop.

Director

Together, these capabilities allow agents to own changes end-to-end, from implementation through review.

Once those agents exist, a new question emerges: how do you coordinate dozens of them at once?

Murmur ships with a CLI that exposes the full agent lifecycle: spawn a task, inspect its status, send follow-up instructions, view artifacts, manage pull requests, and coordinate work across the fleet.

Because the CLI is available from your local Claude Code or Codex session, your local agent can act as a Director: understanding your project, coordinating remote agents, monitoring progress, and routing work across the fleet.

In practice, a large percentage of Murmur tasks at our company are spawned this way. We begin in a local agent session, ask it to explore a project, break the work into parallel streams, dispatch those tasks to cloud agents, check their progress, issue revisions, and pull the results back together.

The orchestration happens locally. The implementation, testing, inference, and verification happen remotely, inside dedicated cloud environments.

Your local agent session becomes the control plane for a fleet of remote agents.

Integrations

Murmur meets your team where work already happens. Agents can be launched, directed, and monitored from the tools your engineers use every day.

• Slack. At Macroscope, we use Murmur extensively through Slack. When a complex customer issue appears, our workflows can automatically spawn agents to investigate the problem, triage potential causes, and handle resulting bug fixes. Engineers can follow the work and provide additional direction without leaving the conversation.
• Linear. Linear issues can be delegated directly to Murmur, turning the backlog into a queue of work agents can begin moving forward. We use this to burn down well-scoped issues while our engineers remain focused on work that requires deeper context or judgment.
• GitHub and CI. Murmur connects to the full GitHub lifecycle. Agents can open pull requests, respond to review feedback, repair failing CI checks, resolve merge conflicts, and continue working until a change is ready for human approval.
• Automation and extensibility. Murmur’s REST API and MCP integration let teams launch and coordinate agents from virtually any system. Trigger recurring work on a schedule, respond to events such as new pull requests or issues, or build always-on services that monitor Slack channels, Datadog, and other data sources—spawning agents whenever something needs attention.

Wherever work enters your organization—Slack, Linear, GitHub, or your own systems—Murmur can turn it into coordinated agent work.

Enterprise control

Murmur is designed to fit into complex engineering environments rather than forcing teams into a single deployment model.

• Bring your own agents and keys. Murmur is agent-agnostic. Choose between Claude Code, Codex, and other coding agents, and bring your own model keys.
• Infrastructure. Run agent environments on Murmur-managed infrastructure or in your own AWS or GCP environment. For organizations with stricter requirements, Murmur’s control plane can also be self-hosted. This allows agents to interact with the same systems your engineers use, including internal services, staging environments, databases, and other infrastructure inside your VPC.
• Infrastructure as code. Configure Murmur for your team with Terraform. Define environments, service profiles, network access, and integrations declaratively, then version and review those changes alongside the rest of your infrastructure.
• Service profiles and access controls. Define different classes of workloads, each with its own VM image, network boundary, credentials, and access policies. For example, a standard engineering profile might have access to development and staging systems, while a production investigation profile can additionally access logs, observability tooling, or operational databases. Profiles can be restricted to specific users or teams, ensuring that agents only have access to the systems and credentials required for their task.
• Auditability and analytics. Audit and event logs give teams a record of agent activity, while analytics provide visibility into usage and outcomes across the organization. Engineering and security teams can understand how Murmur is being used without slowing developers down.

Trying Murmur

Murmur is currently in early preview. If your team is interested in trying it, reach out to us here.