Omnigrex: experimenting with AI agents for software development
I’ve been using coding agents more and more in my day-to-day software development, and it made me curious about what comes next.
My current workflow is already more than simply asking one agent to write some code. For more complex tasks, I often start with a planning phase using a more capable model, then let a cheaper model handle much of the implementation. I also usually have a separate subagent review the result.
That independent review matters. A separate reviewer often catches problems the implementation agent missed, and in my experience it improves the quality of the final output.
So my baseline is not a single coding agent working unchecked. It’s a developer already orchestrating different models and agents for different parts of the job.
The question behind Omnigrex (from Latin grex, a flock or group) is whether this kind of workflow can be pushed much further.
Can a coordinated team of specialized agents automate a larger part of the software development lifecycle? Can it work effectively without a developer manually orchestrating every step? And can it ultimately be better than working with coding agents directly from a development machine?
That’s the experiment behind Omnigrex.
From coding agents to an AI software team
The long-term idea behind Omnigrex is to coordinate agents representing roles normally found in a software team: Product Owner, Architect, Developer, Reviewer, QA and potentially others.
Each role should have its own responsibilities and perspective.
A Product Owner shouldn’t make technical implementation decisions. A Developer shouldn’t silently make important product decisions. A Reviewer should independently evaluate the Developer’s work rather than simply being another step in the same conversation.
In a way, this extends patterns that already work when using coding agents manually. Different models or agents can be better suited to planning, implementation and review than a single agent trying to do everything equally well.
Omnigrex starts with one of the simplest of those patterns: independent implementation and review. It makes that separation automatic and turns it into a first-class part of the workflow.
Coordinating these agents raises its own set of problems. The system needs to decide which agent should work next, preserve the right context when an agent comes back to a task, and make sure important information survives outside individual conversations.
It also needs clear boundaries. Agents will sometimes disagree, get stuck or encounter decisions they should not make on their own. At some point, control needs to return to a human.
To me, those coordination problems are more interesting than simply creating a collection of prompts with different role names.
Coordinating the workflow
In the current prototype, the workflow happens through GitHub Issues and Pull Requests.
A human starts work from an Issue. Omnigrex reacts to the relevant events, starts the appropriate agent, manages its session and coordinates what should happen next. The agents can inspect the current state of the work and publish their results back as normal development artifacts such as commits, Pull Requests, reviews and comments.
I can follow what the agents are doing using the same artifacts I would normally use when working with other developers.
I’m also experimenting with protocols such as ACP (Agent Client Protocol) for controlling agent sessions and MCP (Model Context Protocol) for exposing tools and project information to agents.
They’re useful building blocks, but the protocols themselves aren’t the point of the project. The workflow is.
Starting with something I already know works
The eventual vision is broad, but the first version is intentionally small:
Human → GitHub Issue → Developer → Pull Request → Reviewer → Human
The Developer gets its own persistent session, implements the task and opens a Pull Request. A separate Reviewer agent independently reviews the change.
If the Reviewer requests changes, Omnigrex brings the Developer back in the same session. The Developer can continue with the context of its previous work, update the Pull Request and send it for another review.
Once the Reviewer approves the change, control goes back to a human.
This is deliberately close to the workflow I already use manually, which gives me a useful baseline for comparison.
I want to see whether Omnigrex can automate the Developer and Reviewer loop without reducing quality, and whether removing myself from the middle of every iteration actually saves meaningful time.
There’s one more question worth asking: if Omnigrex does produce better results, how much of that improvement comes simply from making independent review mandatory?
Those questions are enough for the first iteration. I don’t need Product Owners, Architects, QA agents or dynamic teams yet. First I want to find out whether this small loop works well in reality.
Dogfooding as the test
The most important part of the experiment is that I don’t just want to build Omnigrex.
I want Omnigrex to build Omnigrex.
Once the initial Developer and Reviewer workflow is usable, I want to start using it for the development of the project itself. New Omnigrex features will become Issues that its own agents can pick up, implement and review.
That means dogfooding isn’t just a convenient way to develop the project. It’s how I want to evaluate the idea.
I’ll be able to see how the workflow behaves on a real codebase with real bugs, refactorings, design decisions and changing requirements. I’ll be looking at whether it saves time, whether the dedicated Reviewer consistently improves the Developer’s work, and how often I still need to intervene.
Later, I’ll start experimenting with more specialized roles. Adding a Product Owner, Architect or QA agent might improve the process. It might also just add communication, latency and cost. I want those additions to be driven by what I learn from the simpler workflow rather than by an assumption that more agents must be better.
I don’t know the answers yet.
That’s why I’m building Omnigrex.
I’ll be documenting what I learn as the project develops. If you’re interested in the same questions, you can follow the Omnigrex repository on GitHub and, once the first usable version is ready, try it on your own projects.