TL;DR

This is a “state of multi-agentic-driven development” article. It is a personal consolidation of my last month’s learnings, thoughts and vision.

During the research for this article, I also compiled a dataset of agent configuration formats and features across providers, and I tracked the emergence of common patterns and standards in the ecosystem.

In the end, I made a multi-agent development repoitory pattern called Monoswarm, built to work with many agent formats, many providers, and many projects at the same time. It is a monorepo with a shared .ai submodule for agent definitions and symlinks to provider-specific config files in each project. The orchestration logic is still a missing piece, but it would be an OpenClaw plugin that routes events between agents and workflows without relying on LLM inference.

If my opinion offends or contradicts someone, remember everyone is still learning about this industrial revolution everyday and there is no certainty about the outcome.

Obviously, Claude helped me to write this article, but I needed to rewrite myself almost entirely as it didn’t fully capture my perspective.

Table of contents

Why multi-agents

The default mental model for AI coding assistants is a single agent answering questions in a chat window. This works for isolated tasks, like explaining a function, generating a snippet, or fixing a bug. But as soon as you try to build a sustained development workflow, a single agent becomes a bottleneck for two distinct reasons:

• Role separation. Different tasks demand different system prompts, personas, and domain knowledge. Also, each agent benefits from its own identity - a name, a behavioral profile, constraints on how it should respond, and explicit boundaries on what it should not do.
• Skill/tool set. AI coding agents operate through tool calls: file operations, shell commands, API requests, browser actions. A code review agent needs read-only access to a repository and the ability to post review comments. A deployment agent needs access to CI/CD pipelines and infrastructure tooling. A testing agent needs to run test suites and parse their output. Granting all tools to a single agent increases the attack surface and the likelihood of unintended side effects. It also forces the LLM to navigate a larger tool catalog on every invocation, which dilutes attention and wastes context window tokens on irrelevant tool definitions.

Why multi-projects

• Parallel clones. Having a well-defined team of agents - a programmer, a reviewer, a tester, etc. - solves the role separation problem. But a single team can only work on one project at a time. If you manage multiple repositories, you need the ability to spawn clones of the same agent configuration across different projects simultaneously. A “reviewer” agent for project A and a “reviewer” agent for project B should share the same behavioral template but operate in completely independent sessions, with no shared context or state between them.

  This is a parallel workforce problem. The agent definitions (system prompts, tool permissions, model selection) act as blueprints. Each project instantiates its own copy of the team, running in its own workspace with its own git branch, session history, and checkpointing. In platforms like OpenClaw, this maps to isolated session keys per project, but very thighted to the channel/routing layer. In Ralph Orchestrator, each loop operates on its own workspace directory. The multiplier is straightforward:

  N agent roles × M projects = N×M concurrent sessions
  

• Project-level instructions. Beyond cloning, each project also carries its own custom instructions. Project-level directives, like coding standards, architectural guidelines, and definition of done, need to be injected into every agent that works on that project, layered on top of the agent’s own role-specific instructions. The orchestration system must support this two-dimensional configuration:

  agent identity (role) × project context (goals and constraints)
  

Why multi-providers

• Model diversity and volatility. The AI model landscape shifts weekly. A model that leads benchmarks today may be surpassed tomorrow by a release from a different provider. Locking your entire agent infrastructure to a single provider means you cannot capitalize on these shifts without re-architecting.
• Cost optimization. Provider diversity also has a direct cost dimension. Different models have vastly different pricing per token, and not every task requires the most expensive model. An agent that plans or reviews work benefits from a high-reasoning model like Claude Opus or GPT-5.2-Codex. A worker agent executing straightforward file edits or running shell commands can use a faster, cheaper model (Haiku, GPT-5-mini, or a local open-weight model using Ollama) without meaningful quality loss.
• Feature specialization. Finally, providers differ in features beyond raw model quality. Some offer native tool use with parallel execution, others have larger context windows, others support image input or structured output with JSON schema validation. Some have better streaming performance, others have more generous rate limits. A multi-provider setup lets you match each agent to the provider whose feature set best fits its role, rather than accepting the lowest common denominator of a single vendor.

[!NOTE] Projects like OpenRouter and OpenCode attempt to abstract this fragmentation by providing a unified API layer across multiple providers. They solve the interface problem: you get a single endpoint that speaks the same protocol regardless of the underlying model. But they are wrappers, not consolidators. You still manage separate API keys, separate billing accounts, separate rate limits, and separate subscription tiers across providers. The operational complexity of multi-provider doesn’t disappear, it just moves one layer down.