Omnigrex is a platform that coordinates specialized AI agents - Developer, Reviewer, and more roles to come. A human files a need as a tracked issue, and the system carries it all the way to a reviewed change ready to merge - on a collaboration platform humans already use.
We already know that part. The real question Omnigrex answers is a different one.
Can we create an autonomous organization of agents that, across many consecutive tasks, maintains product, architecture, and project-knowledge consistency - without constant human supervision? The project's core hypothesis (project-concept.md, section 27)
Instead of a general-purpose assistant: specialized roles like in a real team - Developer, Reviewer, and eventually Product Owner, Architect, QA.
Decisions, requirements, and history are stored in durable project artifacts - not only in the fleeting context of a model conversation.
The system asks a human only where their decision genuinely adds value - not as another mandatory stage of the process.
The loop currently being built is the simplest complete cycle: from an Issue to a Pull Request ready for human review.
Labels on the Issue (omnigrex:run, omnigrex:developing, omnigrex:reviewing, omnigrex:pr-ready, omnigrex:needs-human) act as the visible state of the state machine - humans see progress without entering the system. The first iteration builds this on GitHub; the principle is a shared, human-readable surface, not any single vendor.
The description may be terse, e.g. "I want sign-in with Google". The label fires a webhook to the orchestrator.
The agent gets its own session and an isolated environment, implements the change, and opens a Pull Request linked to the Issue.
A separate agent with a separate session - not another phase of the same conversation. It approves or sends the work back to the Developer (limit: 3 rounds).
Approval means a PR ready for review. A blocker, an exhausted round budget, or a failure means an escalation with diagnostics posted back on the platform.
The orchestrator decides, agents execute. All state is durable, and agents are cut off from secrets.
Receives webhooks from the collaboration platform (GitHub in the first iteration), runs the state machine as pure functions, queues durable work, and enforces review-round budgets. After a restart it reconstructs everything from the database.
The durable source of operational state: webhooks, workflows, assignments, sessions, turns, leased jobs, operation reservations. One transaction per transition - no lost or duplicated events.
Each agent runs in its own non-root container, cut off from secrets, with its own workspace at /workspace. Sessions survive container replacement; runtime versions are pinned by digest.
The only channel through which an agent touches the world: reading context (Issue, PR, reviews, checks) and controlled mutations (publishing changes, opening a PR, reviewing). Per-turn tokens, idempotent operations, reconciliation of ambiguous outcomes.
A Developer App (write access) and a separate Reviewer App (Pull Requests only, webhook disabled). Split identities guarantee the review genuinely comes from an independent reviewer. GitHub is the first platform binding, not the point of the design.
The first iteration is Developer and Reviewer. Eventually, the team is assembled to fit the task.
Implements the task from the Issue, writes tests, opens a Pull Request. No right to publish directly outside the controlled gateway.
Independently verifies the diff, the tests, and requirements conformance. Approves or requests changes - at most 3 rounds, then escalation.
Requirements refinement, implementation plans and ADRs, acceptance testing from the user's perspective. Team composition depends on task complexity.
Agrees on direction, resolves product doubts, approves risky decisions. Observes the team through the same artifacts used with human developers - where they already work.
The philosophy written into the concept before the first line of code existed.
The process lives on a collaboration platform humans already use to manage work and see results - issues, change requests, reviews, comments. GitHub is the first binding; GitLab, Gitea, or similar fit the same shape.
Switching AI models must not mean losing the organization's memory. Memory lives in the repository, not with the provider.
A role means responsibilities, permissions, goals, and decision boundaries - not just instruction text.
Not every task goes through the full pipeline. A small fix is Developer plus Reviewer; a large topic splits into Issues.
A future agent should know not only what exists, but why it was done that way - hence ADRs and product decisions.
Round budgets, cost limits, stuck-progress detection, and escalation to a human instead of endless agent debates.
Dogfooding is how the idea gets evaluated: once the Developer-Reviewer loop is usable, new Omnigrex features become Issues its own agents pick up, implement, and review - on a real codebase, with real bugs and changing requirements.
Go, PostgreSQL, Docker Compose. Agent runtime: OpenCode over the ACP v1 protocol, versions pinned by digest.
Sessions survive container replacement, history replays, controlled runtime upgrades work, webhooks are durable and idempotent.
The MCP tool gateway, the turn executor, the full Developer-Reviewer loop, and operator documentation.