I Built an Orchestration Layer to Manage Multiple Cursor Agents

DevDev — Sun, 22 Mar 2026 12:12:53 +0000

I Built an Orchestration Layer to Manage Multiple Cursor Agents

Once I started using multiple coding agents in parallel, I ran into an unexpected problem:

The bottleneck was no longer code generation.

It was coordination.

Running one agent feels magical.

Running five or six agents at once feels like managing a messy engineering team with no org chart, no ownership boundaries, and no reliable way to validate what just happened.

That was the reason I built SAMAMS:

Sentinel Automated Multiple AI Management System

It is an orchestration layer for managing multiple Cursor agents like an actual engineering organization.

The problem

At first, using more agents sounds like obvious leverage.

More agents should mean:

more parallel work
faster iteration
less time writing repetitive code

But in practice, I kept hitting the same problems:

multiple agents touched the same files
work was duplicated
outputs conflicted with each other
one agent could quietly drift off course and burn tokens
I still had to manually babysit the entire process

So instead of getting leverage, I got overhead.

The more agents I added, the more coordination cost I created for myself.

That was the real problem:

we have coding agents, but we do not really have agent management systems.

The idea

My basic thought was simple:

If humans scale through ownership, boundaries, task decomposition, and validation, then agents should probably be managed the same way.

So instead of treating agents like glorified autocomplete, I started treating them more like workers in a structured engineering system.

That became SAMAMS.

Its job is to:

break work into manageable layers
assign bounded responsibility
isolate agent execution
monitor progress
detect conflicts
recover when things go wrong

How it works

The planning model is divided into three levels:

Proposal

A large project or initiative.

Milestone

A meaningful feature-level chunk inside the proposal.

Task

An atomic execution unit that one agent can handle in a single working session.

This gives the system a hierarchy instead of just a pile of prompts.

Each task also gets a constrained instruction document, which I call a frontier.

It tells the agent what it should do, what it should avoid touching, and what boundary it should stay within.

That part matters a lot.

Without boundaries, agents do not really parallelize well.

They collide.

Bounded ownership

One of the main design ideas came from Domain-Driven Design.

Each agent is assigned a bounded context:

a set of files
a module
a responsibility area
a clearly scoped task

The goal is to reduce chaos.

Instead of every agent working inside the same shared mess, each one gets a defined workspace and a defined responsibility.

This makes parallel execution much more practical.

Git worktree isolation

To make that boundary real, each agent runs in its own git worktree.

That means agents do not just have conceptual separation.

They have physical workspace separation too.

This helps prevent:

accidental file overlap
branch confusion
chaotic local changes
merge disorder

On top of that, I added merge control logic so agent outputs do not all slam into the main branch at once.

Failure handling

This was one of the most important parts for me.

In most agent workflows, when something goes wrong, the human has to stop everything, inspect the state, figure out what happened, and manually decide what to do next.

That does not scale.

So I added a structured recovery flow.

If an agent keeps failing, or if conflicts are detected, the system can:

pause the task
collect current state
inspect diffs and logs
run a planning pass
decide whether to retry, resume, or cancel

I call this a strategy meeting.

It is basically a controlled intervention step for agent failure cases.

What I realized while building this

The deeper lesson was that the hard problem is not:

"How do I get an agent to write code?"

It is:

"How do I coordinate many agents safely and predictably?"

And that question leads directly to another one:

How do you validate outcomes deterministically?

Agents are not deterministic.

But validation must be.

That means the long-term answer is not just better orchestration.

It is orchestration plus strong validation:

build checks
test automation
type checks
conflict detection
duplication detection
structured success/failure metrics

I think this is the missing layer in a lot of current agent tooling.

Current stack

Right now the project uses:

Go for the backend
Go for the agent process proxy
React for the frontend

It currently runs locally and supports Cursor agents.

The architecture is meant to be extensible, though.

My goal is not "a Cursor-only hack," but a general orchestration layer for multi-agent development workflows.

Current status

This is still early.

It works, but it is definitely not polished production software yet.

There are still rough edges around:

cleanup flows
existing repo onboarding
error handling
broader runner support

So this is less of a "finished launch" and more of a serious prototype for a problem I think will become much more important.

Why I open sourced it

Because I do not think this is just my problem.

As more developers move from using one agent to using many in parallel, I think they will hit the same wall:

not generation,

but coordination.

That is the problem I am trying to solve with SAMAMS.

Repo:

https://github.com/teamswyg/samams

I would especially love feedback on:

multi-agent coordination
deterministic validation
failure recovery
support for more agent runners

Final thought

We already know agents can generate code.

The harder and more interesting problem is building the system around them:

the structure, the boundaries, the validation, and the recovery logic that make parallel agent work actually usable.

That is what I am exploring with SAMAMS.

DEV Community: DevDev

[Boost]