Why We Built Murmur: Coding Agent Orchestration for the Software Development Lifecycle

We built Murmur because we could not manage our own coding agents anymore. Not because the models were too weak, but because nothing around them understood the software development lifecycle. Coding agent orchestration is the missing layer: a system that gives every agent a real machine, keeps the agent connected to what happens after the pull request opens, and lets one engineer direct dozens of agents instead of babysitting three.

Murmur started as an internal tool. For roughly two months before it became a product, about 90% of the code Macroscope shipped was orchestrated through it. We did not set out to enter the agent orchestration category. We set out to stop losing our afternoons to tab-switching, and the tool we built to do that turned out to be the product.

This is the honest version of why it exists, what specifically broke, and what we think agent orchestration has to do to be worth adopting.

TL;DR: Why we built Murmur

• The bottleneck moved. Writing code got cheap. Keeping work in motion did not. A single engineer can direct dozens of productive coding agents in theory and manages three or four in practice.
• Agents need real machines. A repository checkout lets an agent write code. Only a running stack lets it verify code. Laptops were built for one developer, not a fleet.
• The pull request is not the finish line. Review comments, failing CI, stale branches, and merge conflicts are where changes actually die, and every one of those routes back through a human unless the orchestration layer handles it.
• Agent orchestration has to be lifecycle-aware. A task launcher that stops at the PR just relocates the bottleneck. Murmur agents subscribe to GitHub events and keep working.
• One session, many agents. A Director session becomes the control plane: it plans, spawns, monitors, and reports back, so orchestration is a conversation rather than a dashboard you police.
• Agent-agnostic, BYO keys, your cloud. The orchestration layer should outlive any single model generation, and it should be able to run inside your VPC.

What Is Coding Agent Orchestration?

Coding agent orchestration is the layer that runs many AI coding agents at once: provisioning an environment for each one, routing work to them, keeping them connected to the software development lifecycle, and coordinating their output into changes a human can approve.

The word "orchestration" gets used loosely across the AI agent market, so it is worth being specific about what a coding agent orchestration platform actually has to own:

1. Execution environment. What machine does each agent get, and can that machine run your application?
2. Task distribution. How does work reach agents, and can it fan out in parallel or express dependencies?
3. Lifecycle awareness. Does the system know what happened to the pull request the agent opened?
4. Coordination interface. How does a human direct a dozen agents without becoming the scheduler?

Most tools in the agentic coding space answer the first two and stop. That is the gap Murmur was built to close, and it is why we describe the category as cloud agent orchestration rather than "an AI coding agent."

The Problem: You Cannot Manage All Your Agents Anymore

Here is the shape of the problem, exactly as we lived it.

You have a few terminal windows open. An AI coding agent is running in each one. Every one of them halts the moment it needs your attention. You spend the day bouncing between tabs, unblocking agents one interruption at a time, mentally tracking which agent is stuck on what. Your output is capped not by what the models can do, but by how many agents you can personally keep moving.

We were running three to five concurrent projects this way. The models were not the limit. We were.

The meme version of this is real: we left laptops open on the nightstand, on the kitchen counter, and outside the bathroom door, just to keep agents moving forward. That is a funny story and a genuinely bad operating model, and it is what convinced us the missing piece was agent orchestration rather than a better prompt or a bigger context window.

Two things break when you try to scale a single-machine agent setup, and they break for structural reasons that no amount of tooling discipline fixes.

Bottleneck One: Every Coding Agent Needs a Real Machine

A coding agent can only work autonomously on complex tasks if it can verify its own work: running the code, executing tests, interacting with the UI, and inspecting the results. That requires a real development environment, and laptops were built for developers, not for fleets of developers.

This is the constraint people underestimate. Agents that cannot verify do not stop guessing, they just guess with more confidence. You get a plausible diff, a claim that tests pass, and no evidence.

Resource contention on one machine is unforgiving. Agents compete for the same CPU, the same ports, the same local database. Even a very powerful laptop struggles to run multiple fully grounded software stacks in parallel. In our case a single development environment means a one-node Kubernetes cluster running dozens of microservices. You are not fitting six of those on a MacBook.

So in Murmur, every agent gets its own dedicated cloud VM, provisioned to your specification, with your repositories checked out and your stack running. Because the stack is genuinely running, an agent can execute the test suite, hit your services, read the logs, and click through the UI before it ever opens a pull request. The PR arrives with screenshots, recordings, and evidence that the change works.

That is the difference between an agent that reports "tests pass" and an agent that opened the app, saw the console error, and fixed it before you looked.

Bottleneck Two: The Pull Request Is Not the Finish Line

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.

This is the half of the problem that most agent orchestration tools ignore, and it is the half that quietly eats the gains. If your agent stops at the PR, then every subsequent step routes back through a person: you relay the review comment, you read the failing check, you rebase the branch. You have automated the writing and kept all of the shepherding.

Multiply that by a dozen agents and you have not removed a bottleneck. You have moved it onto yourself and made it worse, because now there are twelve open pull requests waiting on you instead of three.

This is why we think agent orchestration has to understand the software development lifecycle to be worth anything. Not as a feature. As the premise.

Why Agent Orchestration Has to Understand the Software Development Lifecycle

An agent orchestration platform that only knows how to start tasks is a job queue. One that understands the software development lifecycle knows that a pull request has a state, that CI results and review comments are events, and that an agent's job is not done until the change is mergeable.

Concretely, lifecycle-aware coding agent orchestration means the platform subscribes to what happens to the work after the agent's first turn:

Lifecycle event	What a lifecycle-aware agent does
Review comment posted on the PR	Reads the feedback, makes the change, replies on GitHub
Code review requests changes	Addresses the requested changes and asks for re-review
CI check fails	Investigates the failure, repairs it, pushes a fix
Base branch moves	Rebases, resolves merge conflicts
Child agent finishes	Processes the result and continues the parent task

In Murmur these are first-class events delivered to the running agent, not webhooks you wire up yourself. The agent is still alive and still holds the context of the change it made, which is why it can respond to a review comment cheaply instead of re-deriving the whole task from scratch.

The result is what we call self-driving: the agent keeps working until the pull request is clean and ready for human approval. Opening the PR becomes just another step in the loop.

What "Self-Driving" Actually Means

The phrase is doing real work here, so it is worth pinning down. A self-driving pull request means these things happen without a human in the middle:

• Review comments are answered. The agent reads the comment, makes the change, and replies in the thread.
• Failing checks are repaired. A red build wakes the agent, which investigates and fixes rather than reporting.
• Branches stay current. Rebases and merge conflict resolution happen as the base branch moves.
• Iteration continues until approval. The loop runs until a human can look once and merge, rather than looking eight times.

The bar we hold ourselves to is that you should be able to close your laptop and come back to a merge-ready pull request. Human approval is still required, deliberately. Self-driving is about removing the shepherding, not the judgment.

The Director: One Session, Many Agents

Once agents can own a change end to end, a new question appears immediately: how do you coordinate dozens of them?

Our answer was to make orchestration conversational rather than administrative. A Director is an interactive local coding session, with the Murmur CLI and MCP server attached, that plans work, spawns agents, monitors them, reviews what comes back, and reports to you.

In practice you start in the local agent session you already have open, ask it to explore a project, break the work into parallel streams, dispatch those tasks to cloud agents, check progress, issue revisions, and pull the results back together. A large share of Murmur tasks at our company are spawned exactly this way. One session ran six agents benchmarking six models in parallel, plus a seventh to synthesize the results.

The split is the point: orchestration happens locally, in the tool you are already in. Implementation, testing, inference, and verification happen remotely, inside dedicated cloud environments. Your local session becomes the control plane for a fleet.

This matters for evaluating any agent orchestration platform: if the only way to drive it is a web UI, your orchestration ceiling is how many browser tabs a human can hold in their head. Which is the ceiling you were trying to escape.

Beyond a single Director session, Murmur supports the coordination patterns that multi-agent work actually needs: parent agents spawning child agents recursively with clean context windows, fanout across a list of modules or repositories, and Flights, which are Markdown documents that define a DAG of agent tasks with explicit dependencies so multi-step workflows are reproducible.

Why We Did Not Just Use Git Worktrees and More Terminals

We tried. It is the obvious first move and it works for a while.

Git worktrees plus a terminal multiplexer gets you parallel branches on one machine. What it does not get you is isolation of the running stack, which is the thing agents need in order to verify. Every worktree still shares your ports, your database, your CPU. The second and third agent degrade the first.

It also does nothing for the lifecycle problem. Worktrees are a source-control convenience, not an orchestration layer. Nothing is listening to GitHub on your behalf, so the post-PR work still lands on you.

The honest summary is that local parallelism scales to about the number of agents you can watch, and agent orchestration is what you need past that point.

Agent Orchestration Approaches Compared

Approach	Environment per agent	Post-PR autonomy	Parallel ceiling	Who schedules
Murmur	Dedicated cloud VM running your full stack	Review comments, CI repair, rebase, conflicts	Dozens	Director session, CLI, MCP, Slack, Linear, API
Terminals plus git worktrees	Shared laptop, contended resources	None	3 to 5	You
In-editor agents (IDE-embedded)	Your machine, your session	None	1 to a few	You
Local multi-agent dashboards	Shared laptop, per-agent branch	Limited	3 to 10	You, via the dashboard
Single-vendor cloud agents	Vendor sandbox, repo checkout	Usually task-to-PR	Varies	Vendor UI or GitHub

The two structural columns are environment depth and post-PR autonomy. Those are the ones that determine whether an agent orchestration platform raises your throughput or just relocates your attention. For a vendor-by-vendor comparison of the cloud agent category, see best cloud AI coding agents in 2026.

Why Agent-Agnostic, and Why Bring Your Own Keys

We made Murmur agent-agnostic because an orchestration layer that hard-codes one model provider turns your infrastructure into a bet on that provider. The frontier moves every few months. Rebuilding your orchestration each time it does is not a strategy.

So Murmur runs Claude Code, Codex, and other coding agents, with bring-your-own-keys and the provider configurable per workspace. If your team already pays for agent subscriptions, you are paying Murmur for orchestration and compute rather than re-buying model access you already have.

This was also a self-interested decision. We wanted to be able to change our own minds about models without rewriting the platform, and we wanted to run head-to-head model benchmarks on our real codebase, which is much easier when the orchestration layer is neutral.

Why It Has to Run in Your Cloud

The least glamorous section of any agent orchestration evaluation, and frequently the one that decides it.

If your source code cannot leave your cloud account, a SaaS-only agent platform is not a candidate regardless of features. And if agents are going to verify their work against real systems, they need to reach the internal services, staging environments, and databases that live inside your VPC.

So Murmur lets you choose the execution placement for every workload: agent VMs in Murmur Cloud, or in your own GCP or AWS environment with your own credentials. For stricter requirements the control plane can be self-hosted. Configuration is declarative through Terraform, so environments, service profiles, network access, and integrations are versioned and reviewed like the rest of your infrastructure.

Service profiles are the piece we use most internally. Each profile defines a class of workload with its own VM image, network boundary, credentials, and access policy. A standard engineering profile reaches development and staging. A production investigation profile additionally reaches logs and observability tooling, and is granted to fewer people. Agents get exactly the access their task requires, and audit and event logs record what they did.

Where the Work Enters: Slack, Linear, GitHub, and Your Own Systems

Agent orchestration is only useful if work can reach it from wherever work already appears.

• Slack. We use Murmur heavily through Slack. When a complex customer issue lands, a workflow can spawn agents to investigate, triage causes, and handle the resulting fix, with engineers steering in the thread.
• Linear. Issues can be delegated directly to Murmur, which turns a backlog into a queue agents can start moving.
• GitHub and CI. The full lifecycle connection described above: open PRs, answer review feedback, repair checks, resolve conflicts.
• REST API and MCP. Launch and coordinate agents from any system. Trigger recurring work on a schedule, respond to events, or run always-on services that watch a channel or a dashboard and spawn agents when something needs attention.

What Changed for Us

The measurable change was throughput, but the qualitative change was where our attention went.

Before Murmur, an engineer's day was spent unblocking agents. After, it was spent deciding what should be built and reviewing what came back. Roughly 90% of the code we shipped in the two months before Murmur became a product was orchestrated through it, which is the number that convinced us to productize an internal tool rather than keep it.

The other change worth naming: we stopped treating the pull request as a milestone. It became a checkpoint that the system moves past on its own.

Where Code Review Fits When Agents Write Most of the Code

When a fleet of coding agents produces most of your pull requests, code review stops being a style conversation and becomes the primary quality gate. Its throughput becomes the constraint on the entire system.

This is why agent orchestration and AI code review belong in the same conversation. An agent fleet that opens twenty pull requests a day and a review process that assumes a human reads every diff line by line are not compatible. One of them has to change.

Macroscope's AI code review is built for that volume, reviewing every change for correctness, security, tests, and regressions before it lands. Fix It For Me turns a finding into a committed fix rather than another comment for someone to action. Check Run Agents let teams define their own review checks in Markdown, which is how you encode the conventions an agent fleet needs to respect.

An orchestration layer that produces pull requests and a review layer that can keep up with them are two halves of the same problem, which is why we build both.

How to Tell If You Need Agent Orchestration Yet

Not every team does, and the honest signal is behavioral rather than aspirational. You are ready for coding agent orchestration if:

• You are already running multiple coding agents and losing time to switching between them.
• Your agents produce diffs you do not trust because they could not verify them.
• Your pull requests sit waiting on a human to relay a review comment or read a failing check.
• You have work that is embarrassingly parallel (test coverage, migrations, dependency upgrades) and no way to fan it out.
• Your laptop fan is a load-bearing part of your development process.

If you are not using coding agents heavily yet, orchestration is premature. The teams getting the most out of Murmur are the ones who already hit the wall we hit.

Getting Started With Murmur

Murmur is in early preview and we are onboarding teams now.

1. Request access on the Murmur page. Tell us about your codebase and what you would point a fleet at.
2. Connect your GitHub org and pick an execution placement: Murmur Cloud, or your own GCP or AWS VPC.
3. Bake an image with your language and tool stack preloaded, and link the repositories agents should clone.
4. Spawn agents from the dashboard, the CLI, or straight from a local coding session over MCP, and let them run in parallel.
5. Review what comes back. Agents open pull requests and keep iterating on review comments and CI until the change is ready for your approval.

The Murmur documentation is public if you want to read the architecture before applying, and the launch post has video of the fleet, the sandboxes, the self-driving PR loop, and the Director in action.

Frequently Asked Questions

Why did Macroscope build Murmur?

We built it for ourselves first. We were running three to five coding agents at once from our laptops, and the limit was not model capability, it was that every agent halted whenever it needed attention and none of them could verify their own work. About 90% of the code we shipped in the two months before Murmur became a product was orchestrated through the internal version of it. Productizing it was the obvious next step once it was clear the missing layer was agent orchestration rather than a better agent.

What is coding agent orchestration?

Coding agent orchestration is the layer that runs many AI coding agents in parallel: it provisions an execution environment per agent, routes work to them, keeps them connected to the software development lifecycle, and coordinates their output into reviewable changes. The distinguishing question is whether the platform knows what happened to the pull request after the agent opened it. If it does not, it is a task launcher.

Why does agent orchestration need to understand the software development lifecycle?

Because that is where most of the elapsed time lives. Writing the diff is now the cheap part. Review comments, failing CI, stale branches, and merge conflicts are what a change actually spends its life on, and every one of those steps routes back through a human unless the orchestration layer subscribes to those events and lets the agent respond. An orchestration tool that stops at the pull request automates the easy half and leaves you holding the rest.

What does a self-driving pull request do on its own?

It answers review comments, repairs failing CI checks, rebases when the base branch moves, resolves merge conflicts, and keeps iterating until the change is ready for human approval. What it does not do is merge itself. Approval stays with a person on purpose.

How many AI coding agents can one engineer run in parallel?

On a laptop with terminals and git worktrees, realistically three to five before resource contention and context-switching cancel out the gains. With agent orchestration where each agent gets its own cloud VM and the platform handles the post-PR lifecycle, dozens. The ceiling shifts from how many agents you can watch to how much work you can specify and review.

How do coding agents verify their own work?

By running your actual application, which requires a machine that can boot it. Each Murmur agent gets a dedicated cloud VM with your repositories checked out and your development stack running, so it can execute the test suite, call your services, read logs, and interact with the UI before opening a pull request. A repository checkout is enough to write code. Only a running stack is enough to verify it.

What is a Director agent?

A Director is an interactive local coding session with the Murmur CLI and MCP server attached, running a persona built for coordination rather than implementation. It plans work, spawns agents, monitors them through real-time events, reviews the pull requests they open, and recommends merging, following up, or killing them. It is the recommended way to manage anything involving more than one agent.

Is Murmur just a wrapper around Claude Code?

No, and it is deliberately not tied to Claude Code. Murmur is agent-agnostic: it runs Claude Code, Codex, and other coding agents with bring-your-own-keys, configurable per workspace. The parts Murmur owns are the ones an agent cannot provide for itself, namely a provisioned cloud environment that runs your stack, the connection to GitHub lifecycle events, fleet coordination, and enterprise controls like service profiles and audit logging.

Can Murmur run inside our own cloud?

Yes. Execution placement is per workload: host agent VMs in Murmur Cloud, or run them in your own GCP or AWS VPC with your own credentials. The control plane can be self-hosted for stricter requirements. Placement, environments, service profiles, and network access are all configurable as code with Terraform.

How does Murmur compare to Devin, Cursor cloud agents, or the GitHub Copilot coding agent?

Those are largely single-vendor cloud agents oriented around a task-to-PR arc: you give them a task and they produce a reviewable pull request. Murmur is an orchestration layer rather than an agent, so the differences that matter are environment depth (a dedicated VM that runs your full stack, not a repo checkout), post-PR autonomy (the agent keeps working through review comments, CI, and conflicts), model neutrality with BYO keys, and the ability to run in your own VPC. A fuller vendor comparison is in best cloud AI coding agents in 2026.

What happens to code review when an agent fleet writes most of the code?

Review becomes the binding constraint. A human reading every agent-authored diff reintroduces exactly the bottleneck the fleet was meant to remove, so teams adopting agent orchestration generally automate review in the same motion. Macroscope's AI code review is built for that volume, and teams evaluating it against other tools often start from CodeRabbit alternatives or Greptile alternatives.

How is Murmur priced, and is it generally available?

Murmur is in early preview, not yet generally available. Pricing is usage based with no per-seat charges: you pay for the resources your agents consume, including compute and storage, and detailed pricing will be published at general availability. Because Murmur supports bring-your-own-keys, model spend stays on the agent subscription your team already has.