q-q.dev

notes on agent systems, security primitives, and the things under agentic-research

Constraint-Driven Development: Why the 60% of Agent Projects That Survive All Look the Same

Constraints compose. Opinions don't. That's the whole difference between the systems that ship and the ones that don't.

· 11 min read · updated

rosary agents orchestration methodology

the map · part 3 of 8

rosary · part 1 of 4

The Peak

Last week, Kaushik Rajan showed that unstructured multi-agent networks amplify errors 17x. Gartner says 40% of agentic AI projects will be canceled by 2027. The DeepMind scaling paper that Rajan builds on found failure rates between 41% and 86.7% across seven frameworks, with coordination breakdowns accounting for 36.9% of all failures.

But Klarna saved $60M with a multi-agent architecture.

Warp’s Oz writes 60% of their PRs.

Gas Town coordinates 20–30 parallel Claude Code instances overnight.

My own system — rosary — processes beads across 11 repositories in overnight runs.

The 60% that survive aren’t lucky. They share an architecture.

This article names that architecture. I’m calling it Constraint-Driven Development — and I think it explains why the surviving systems converge, why the failing ones don’t, and what the difference actually is.

Here is what it looks like for a single person to just… ship: https://github.com/jamestexas/

The Valley

The Multi-Agent Trap is real. But Rajan’s diagnosis — that topology separates winners from losers — is half the story. Which topology? And why does hierarchy specifically outperform flat coordination?

The conventional answer is:

hierarchy reduces coordination overhead.

That’s true but insufficient. Plenty of hierarchical agent systems fail. The MAST taxonomy found failures across every architectural pattern, including hierarchical ones. Hierarchy is necessary but not explanatory.

Here’s the diff: most multi-agent systems encode opinions about how work should be done.

  • Use dependency injection.
  • Write clean code.
  • Follow SOLID principles.
  • Decompose into microservices.

Tell me, which of those are judgments of taste vs binary correctness? That taste is exactly what LLMs don’t have.

The systems that survive encode something different. They encode constraints.

Critically, a constraint is not a spec.

  • The diff must be under 500 lines
  • Tests must pass
  • The agent may only use Read, Glob, and Grep tools.
  • Work touching overlapping files cannot be dispatched concurrently.

That distinction does real work. A constraint is structural and verifiable — you can write a function that returns true or false. An opinion requires the implementer to share the specifier’s judgment. When your implementer is a stochastic text generator, judgment is the wrong thing to depend on.

The property that makes constraints win at scale: constraints compose. Opinions don’t.

“Write clean code” and “minimize abstraction” can conflict.

“Use dependency injection” and “keep it simple” can conflict.

Resolving opinion conflicts requires exactly the judgment you’re trying to avoid delegating. But “diff under 500 lines” and “tests must pass” and “only 3 files changed” never conflict. If, and only if, the work is scoped down properly.

They’re independent predicates. Stack as many as you want. The intersection of their shapes is always well-defined.

And yes, I (like most) have been burned by AI’s testing. You know — the mock database returns a mocked value in the mocked function. It happens.

But. This is also why hierarchy works when it works. Not because hierarchy is magic — but because hierarchical systems naturally create layers of constraints. Each layer defines a shape. The thing inside each shape is free. But it must fit the shapes above and below.

Another word for a hierarchical system of constraints?

A lattice.

And you might not see it, but the way Open AI’s Harmony works, and “Progressive Disclosure” aren’t all too different.

The Distinction

I didn’t start with a design, but I did have industry (and personally) informed theory. I started with a system that needed to run overnight without supervision. So I made Rosary (I love puns, it’s built on beads).

Rosary is a Rust (Elixir and rust in hosted) based multi-repo agent orchestrator. It dispatches Claude, and (soon!) Gemini, and soon also local agents against work items tracked in Dolt (a version-controlled SQL database). The first version was a god-file reconciliation loop — everything in memory, all decisions in one place.

It kept breaking. Crash recovery was fragile. Stuck agents went undetected. Continuations got lost between pipeline phases. So I started looking at what other people were building.

What I found: every system I could find required a human to start it. That was the biggest design constraint of all — and the first one I removed.

OpenAI’s Symphony reminded me that Elixir/OTP existed. Supervision trees solve crash recovery, stuck detection, and lost continuations for free — these are problems the BEAM runtime was built for. The Elixir layer replaced the Rust reconciliation loop entirely. The bugs didn’t get fixed at this point.

I realized that Elixir was an excellent “Orchestrator of orchestrators” but shipping a container or daemon to run locally just to supervise (what was a claude -p process at the time) was ridiculous. The Rust reconciler loop is now correct, and the Elixir was moved out. As an aside, I may OSS a version of the orchestration code in Gleam later, as Gleam has typed OTP support among other things.

The system works. It runs overnight. I review in the morning. But when I looked at why it worked, I found something I wasn’t expecting: every design decision that survived contact with unreliable agents was a constraint. Every decision that got reverted or replaced was an opinion.

Then I looked at the other systems.

Convergent Evolution

Between January and March 2026, at least eight independent agent orchestration systems shipped or were announced. They were built by different teams, in different languages, for different use cases. None of them referenced each other’s work. And they all arrived at the same structural pattern:

Constrained dispatch → Isolated execution → Independent verification → Lifecycle management.

  • Symphony (OpenAI) | Lang: Elixir | Dispatch: Linear poll | Isolation: Codex sandbox | Verification: CI gate | HITL: No
  • Agent Teams (Anthropic) | Lang: — | Dispatch: Lead agent | Isolation: Shared task list | Verification: Lead reviews | HITL: Yes
  • Conductor.build (YC startup) | Lang: — | Dispatch: Dashboard UI | Isolation: Git worktrees | Verification: Human watches | HITL: Yes
  • Gas Town (Yegge) | Lang: Go | Dispatch: Mayor agent | Isolation: Git worktrees | Verification: Refinery merge | HITL: Semi
  • Wasteland (Yegge) | Lang: Go | Dispatch: Wanted Board | Isolation: Rig isolation | Verification: Trust stamps | HITL: No
  • Warp (Oz Warp/Sequoia) | Lang: — | Dispatch: Triggers/schedule | Isolation: Docker envs | Verification: Audit trails | HITL: Hybrid
  • Hermes (NousResearch) | Lang: — | Dispatch: GitHub Issues | Isolation: Per-issue branch | Verification: CI | HITL: No
  • rosary (Gardner) | Lang: Rust | Dispatch: Scored triage | Isolation: Worktrees + Dolt | Verification: Tiered pipeline | HITL: Optional

Eight systems. Four languages. Three continents. One pattern.

None of them converged on opinions about code quality, architecture, or methodology. All of them converged on constraints: what’s allowed, what’s verified, what happens on failure.

This is not a coincidence. This is the architecture that survives contact with non-deterministic agents.

The Constraint Stack

CDD formalizes what these systems share into six layers. Each layer constrains a different dimension of agent behavior:

1. Work Constraints — What gets worked on and in what order. Priority is arithmetic (P0–P4), not judgment. Severity floors prevent low-priority work from auto-dispatching. File scope overlap prevents concurrent conflicts. Dedup suppresses structurally similar work.

2. Permission Constraints — What an agent is allowed to do. ReadOnly for review. Implement for code changes. Plan for decomposition. Permission derives from the work item’s type, not the agent’s identity — the same model operates under different constraints depending on its pipeline step.

3. Verification Constraints — What must be true for work to be accepted. Tiered: commit exists → compiles → tests pass → linter clean → diff sanity → adversarial review. First failure short-circuits. None of these tiers express an opinion. They’re predicates.

4. Pipeline Constraints — What order things happen in. Sequential, parallel-race (first to pass wins), parallel-all (all perspectives collected), and gate (proposal precedes action). Phase advancement is a closure that survives crashes.

5. Channel Constraints — What the model can output. Structured generation via constrained decoding (JSON schema, regex patterns) eliminates an entire class of “the agent returned something weird” failures. The constraint is on the shape of output, not the content.

6. Lifecycle Constraints — What happens when things fail. Retry with backoff. Deadletter after max attempts. Supervision trees restart crashed agents. The constraint is structural: N retries, then human review. Not “try to figure out what went wrong.”

Every surviving system implements some version of layers 1–4. The more layers they implement, the more autonomous they can be.

The Concrete Example

Here’s what an overnight run looks like under CDD.

Rosary scans 11 repositories, discovers work from Dolt beads. The triage score is arithmetic: 0.4 × priority + 0.3 × dependency_readiness + 0.2 × age + 0.1 × retry_discount. No LLM involved.

Dispatch respects file scope overlap — two beads touching the same files are never dispatched concurrently. Each agent gets a permission profile matching its pipeline step: the reviewer gets ReadOnly, the implementer gets Implement, the planner gets Plan.

The agent works in an isolated git worktree. It can do whatever it wants inside its constraints. The constraint system doesn’t care how the agent solves the problem — it only cares whether the result fits the shape.

Verification runs the tiered pipeline. If the diff doesn’t compile, nothing else runs. If tests fail, the linter doesn’t run. If the diff touches more than 10 files, it’s rejected regardless of quality. The agent’s opinion about whether the change is good is irrelevant. The predicates are the evaluation.

On failure, the bead gets retried with exponential backoff and a fresh agent session. After three failures, it’s deadlettered for morning review. The morning review is “what failed the constraints” — not “what did the agent produce.”

170 beads. Zero human supervision during execution. That was the plan. And while it was closer to 47 or so without an interrupt, the velocity is the proof. Honestly the biggest problem from this is that it makes more work than it does (partially due to me getting around API key stuff via claude -p). ACP support is baked in. Claude originally wrote this blog, and included the mind-blowing statistic: 1.7% human messages, 98.3% machine. Read the code for yourself.

The human’s job was constraint design: what priority thresholds, what file scope limits, what verification tiers, what retry budget. That work happened before the overnight run. The run itself was autonomous.

The Topology

Peak, valley, discovery — these are topological features of a constraint landscape.

The peak is where production systems live: high constraint density, low failure rate. Every verified predicate is a gradient pointing upward. The systems at the peak — Klarna, Warp, rosary — got there by adding constraints, not by adding intelligence.

The valley is the multi-agent trap: low constraint density, high error amplification. Systems in the valley delegate judgment to agents and hope for emergent quality. DeepMind’s 17x error amplification is the valley’s gradient — each unconstrained step compounds the error of the last.

The discovery is the path between them: the realization that constraints compose and opinions don’t. That the topology of a multi-agent system — its hierarchical layers, its verification gates, its permission boundaries — is a constraint surface. And that the human’s highest-leverage contribution is designing that surface, not reviewing individual outputs.

Every experienced engineer knows this intuitively. When a senior engineer scopes a task, they’re defining constraints: “touch these files, not those. Run these tests. The change should be under N lines.” They don’t say “write clean code.” They say “here’s the shape it needs to fit.”

CDD is the observation that this is not just good practice — it’s the only practice that scales to non-deterministic agents. Define the shape. Verify the shape. Don’t care what’s inside the shape.

The full CDD methodology spec, including the six-layer constraint stack and the properties of composable constraints, is available at github.com/agentic-research/rosary. A companion paper on the general theory — four categories of constraint and friction as the irreducible human signal — is forthcoming.

Rosary is open source today. More information can be found at https://rosary.bot

References

  • Rajan, K. “The Multi-Agent Trap.” Towards Data Science, March 2026.
  • Moran, S. “Why Your Multi-Agent System Is Failing: Escaping the 17x Error Trap.” Towards Data Science, January 2026.
  • Kim, Y. et al. “Towards a Science of Scaling Agent Systems.” Google DeepMind, December 2025.
  • Cemri, M. et al. “MAST: Multi-Agent Systems Failure Taxonomy.” March 2025.
  • Gartner. “Over 40 Percent of Agentic AI Projects Will Be Canceled by End of 2027.” June 2025.
  • OpenAI. “Symphony.” March 2026.
  • Anthropic. “Agent Teams.” February 2026.
  • Yegge, S. “Welcome to Gas Town.” January 2026.
  • Yegge, S. “Welcome to the Wasteland: A Thousand Gas Towns.” March 2026.
  • Warp. “Introducing Oz: The Orchestration Platform for Cloud Agents.” February 2026.
  • Osmani, A. “Conductors to Orchestrators: The Future of Agentic Coding.” O’Reilly, February 2026.
  • Goldratt, E. The Goal: A Process of Ongoing Improvement. 1984.