How Specialised Sub-Agents Enhanced Rovo Dev CLI Reliability for My Project
Over the last little while I’ve been using Rovo Dev CLI on a personal side project. It started as a fun experiment: “How far can I get if I let an AI agent write most of the code?”
At first I did what I suspect many of us do: I pointed one big, do-everything agent at the repo and asked it to build the whole thing.
For a surprisingly long time, that worked really well.
As the codebase grew and the context ballooned, that single agent became less reliable, more forgetful, and – most painfully – it started breaking the working agreements we’d set up together.
This post is about how I fixed that by moving to a network of sub-agents, and why that shift has made Rovo Dev CLI feel dramatically more reliable and “fire-and-forget” for me.
When the “One Big Agent” Started to Break Down
For a while, the single‑agent setup felt magical. I’d describe a feature, it would wire things up, and I’d move on.
As the project grew, though, some natural limits started to show up, such as occasionally losing track of important context or losing consistency in following my instructions and working agreements.
The biggest friction point was testing.
I’d explicitly asked it to always:
- Write tests
- Run tests
- Run pre‑commit verification
These were meant to be our shared guardrails to avoid regressions. On paper, it sounded solid. In practice, as the codebase grew it was harder to keep all of these tasks in check and some regressions slipped in quietly.
This all surfaced during a particularly confusing debugging session. When I finally paused to assess what was going on, I realised:
- My test coverage had dropped to around 20%
- Some existing tests were no longer passing
- I had to spend time re‑stitching things together manually
In hindsight, the root issue wasn’t “bad AI,” it was my setup. I was asking one general‑purpose agent to remember too much, juggle too many responsibilities, and never drop a ball. That’s a lot to expect from any system (human or AI) once the work stops being small and tidy and starts looking like a real product.
Instead of abandoning the agent, I treated this as a signal that my collaboration model needed to mature.
A Different Approach: Specialised Sub-Agents
After chatting with a colleague about this, I decided to try a very different setup.
Instead of one monolithic agent, I introduced a set of specialised sub-agents and a main orchestrator whose only job is to coordinate them.
Each sub-agent has a narrow responsibility. The orchestrator worries about who should do what and when – not about every implementation detail.
Here’s what that network looks like.
Backend Agent
- Owns the backend code
- Responsible for database-related changes
- Focuses purely on server-side behaviour
Frontend Agent
- Owns the React frontend
- Handles UI and client-side logic
- Keeps concerns clearly separated from backend work
Test Agent
Responsible for the full testing pyramid:
- Backend tests
- Frontend tests
- Unit tests
- Component tests
- Integration tests
It also acts as a testability reviewer – making sure the code being written is actually testable, and pushing back when it’s not.
Performance Guardian
- Focuses on performance and scalability
- Looks for bottlenecks, concurrency issues, and anything that might not scale
- Helps avoid building performance problems in by default
Architecture Guardian
- Keeps an eye on the overall system architecture
- Pushes back on questionable design decisions
- Helps maintain coherence as the project grows
Historian Agent
- Logs the progress of the project over time
- Tracks what changed and why
- Acts as a lightweight project history and narrative
Documentation Agent
Owns written artefacts, including:
- Architecture Decision Records (ADRs)
- User-facing documentation and explanations
Git / Quality Gate Agent
- Makes sure everything is correctly wired up with Git
- Ensures we:
- Commit changes properly
- Run pre-commit verification
- Acts as a final quality bar before changes land
Orchestrator (Main Agent)
Sitting above all of these is the main orchestrator agent. Its job is to:
- Understand the feature I want to build
- Pull in the right sub-agents
- Coordinate work across them
- Ensure the whole thing hangs together
In other words: the orchestrator is the conductor; the sub-agents are the orchestra.
What Working With This Setup Actually Feels Like
Day-to-day, I don’t talk directly to most of the sub-agents. I talk to the orchestrator.
A typical feature looks like this:
- I describe the next feature I want.
- The orchestrator pulls in the Architecture guardian (and often the Performance guardian) to explore possible approaches.
- We have a short back-and-forth: pushback on ideas, trade-offs, alternatives.
- Once we agree on a plan, I say, “Okay, let’s go with that.”
- The orchestrator then delegates:
- Implementation work to the Backend / Frontend agents
- Test work to the Test agent
- Docs and history updates to the Documentation and Historian agents
- Final checks and commits to the Git / quality gate agent
This whole process can take a little while to run, but the key difference is:
I no longer feel like I’m babysitting the AI.
When it comes back with a change:
- I’m not seeing mysterious regressions
- Tests are present and passing
- Pre-commit checks have run
- The feature is much closer to “done” when it hits my review
I still review the diff, of course, but it feels more like reviewing a junior engineer’s well-structured work than chasing down random side effects.
Why This Has Been a Game Changer (For Me)
For me, this setup has been genuinely game changing.
A few reasons why:
- Each sub-agent has a narrow, clear responsibility
- The orchestrator can focus on coordination and decision-making, not remembering every detail
- Quality concerns (tests, performance, architecture, docs, Git hygiene) are owned by agents whose only job is to care about them
It also unlocks some useful model-routing strategies.
I use a stronger model for:
- The orchestrator
- Architecture guardian
- Performance guardian
And I use lighter, cheaper models for simpler roles:
- Git / quality gate agent
- Possibly Historian or Documentation, depending on what I’m optimising for
The end result is that the whole thing feels much more:
- Reliable
- Fire-and-forget
- Predictable, even as the project grows
If You’re Using Rovo Dev CLI Today
This is just one person’s side-project setup, not an official pattern or prescription. But if you’re already using Rovo Dev CLI (or anything similar) for non-trivial projects and finding that a single agent keeps dropping balls, I’d strongly encourage you to experiment with sub-agents.
You don’t need to copy this exact structure. Even starting with:
- A dedicated Test agent, and
- A simple Git / quality gate agent
…can make a noticeable difference.
From there, you can grow into architecture, performance, documentation, or whatever quality concerns matter most in your context.