Delivering complex projects involving multiple AI agents can be chaotic without a clear structure linking the various roles and responsibilities. While individual AI agents excel at isolated tasks—writing code, running security reviews, or checking pull requests—the lack of central governance often leads to confusion over who approved what, why, and when. This gap results in missed risks, fragile audits, and unpredictable delays.

Luke Murray’s OMO Teams project tackles this challenge head-on by combining multi-agent workflows with Architecture Review Board (ARB) gates—real governance checkpoints with human-like quorum rules executed through AI and formalized in Markdown documents. Leveraging the OpenCode AI agent harness and the Oh My OpenAgent Team Mode, OMO Teams breaks down project delivery into five discrete phases, each with dedicated AI voter teams that approve project artifacts before passing the baton.

In this post, we’ll walk through how OMO Teams structures AI agents into specialized teams, adapts their capabilities dynamically, and enforces governance as code along the end-to-end lifecycle of an Azure Container Apps project called LinkSnap. You’ll gain insight into the architecture, technical innovations, core workflows, and practical tips for delivering projects with AI-powered governance.

---

Architecture Overview

┌─────────────────────────────┐
│    Project Artifacts        │
├─────────────────────────────┤
│ • Architecture Decision     │
│   Records (ADRs)            │
│ • Threat Models             │
│ • Risk Registers            │
│ • Agent Economic Budgets    │
└─────────────────────────────┘
              ↓
┌─────────────────────────────┐
│     OMO Teams Framework     │
├─────────────────────────────┤
│ • OpenCode Agent Harness    │
│ • Oh My OpenAgent Team Mode │
│ • AI Skill Loading          │
│ • ARB Gate Voting & Quorum │
│ • Governance-as-Code        │
└─────────────────────────────┘
              ↓
┌─────────────────────────────┐
│  Multi-Agent Phase Teams    │
├─────────────────────────────┤
│ • Intake & Product Owner    │
│ • Architecture & Security   │
│ • Build & Code Review       │
│ • Validation & Testing      │
│ • Production & Operations   │
│ • ARB Review Board          │
└─────────────────────────────┘

This diagram shows the flow from project artifacts—key documents and models—through the OMO Teams framework that manages AI skills and voting, down to the multi-agent teams organized by project phase. The ARB gate enforces governance with quorum and escalation paths, committing all decisions as immutable Markdown files.

OMO Teams architecture overview – Source: luke.geek.nz

---

Key Technical Observations

• Structured Multi-Agent Lifecycle – The project divides delivery into five phases (Intake, Architecture, Build, Validate, Production) with dedicated AI teams and unique voter sets per phase, enabling specialized checks and balances upstream.

• Governance as Code with ARB Gates – Instead of relying on external ticketing or SaaS workflows, ARB gate votes, checklists, and outcomes are coded into Git as Markdown, creating an auditable, immutable governance trail.

• Dynamic Conditional AI Skill Loading – Agents load baseline capabilities plus conditional skills based on ADR keywords, enabling adaptable knowledge like Cosmos DB patterns or managed identity best practices only when relevant.

• File-System State Management – Phase progression is gated by the presence of marker Markdown files (e.g., phase1-gate-approved.md), eliminating the need for in-memory state or central databases and simplifying orchestration.

• Agent Economics and Token Budgeting – Token costs are budgeted at project intake, reported in architecture and production phases, and tracked via the agent-economics skill, grounding AI compute costs in business terms to avoid surprises.

• In-Line Code Review and Security Scanning – Build phase agents not only generate code but review their own output, catching issues like hardcoded secrets or unpinned image hashes before PR merges, preventing costly post-production fixes.

---

How It Works: The Five-Phase Model and ARB Gates

Phase 0: Intake

The intake phase involves a single product-owner AI agent that builds foundational project documents: project requirements (PRD), business case, stakeholder map, risk register, and critically, an agent economics budget estimating token spend across all phases. Only when six essential documents exist will the ARB gate convene.

For example, in LinkSnap—a FastAPI URL shortener on Azure Container Apps—the intake highlighted risks like no experience managing ACA secrets and lack of a disaster recovery (DR) plan. The gate required unanimous approval on business case and budget before progressing.

Artifacts produced in Phase 0 intake – Source: luke.geek.nz

Phase 1: Architecture

Architecture involvement is the most complex, with six AI members executing in waves constrained by prerequisite ADR files:

• Wave 1: Backend and infrastructure architects asynchronously produce backend API ADRs, hosting platform strategy, secret management, DR, and cost estimates.
• Wave 2: Data and agent architects (who sat out for LinkSnap’s trivial scope).
• Wave 3: Security and cloud economics members produce threat models, security reviews, and cost variance reports.

An ARB reviewer flagged a conditional approval here: the managed identity ADR lacked a documented local development authentication path and network security decision. This early catch forced corrective revisions, preventing security gaps from reaching code.

Phase 2: Build

Build is split into contract production and implementation waves:

• Wave 1 generates API contracts such as OpenAPI specifications.
• Wave 2 implements backend services, infrastructure templates (Bicep), runs self code reviews, and applies conditional domain skills like managed identity usage.

For LinkSnap, agent skips occurred on trivial roles like frontend and data engineer. Code reviews detected critical issues—such as unpinned container images and hardcoded URLs—that were fixed before merge, exemplifying the advantage of agent-in-the-loop quality assurance.

Phase 3: Validate

Validation tests integration points, security hardening, performance, and functional tests through three members:

• Integration testing and WAF assessment
• QA functional verification
• Security engineering checks against threat models and OWASP Top 10 mitigations

Evidence files must be present to pass the exit gate. The LinkSnap load test verified scalability and speed; security scans reported zero critical vulnerabilities; and documented known limitations were acknowledged.

Phase 4: Production

The final phase prepares reliability documentation, runbooks, and cloud economics variance reports:

• Reliability members write SLOs, create dashboards, and document DR testing.
• Runbook members compose clear operational docs, incident response plans, and release notes with writing guidelines.
• Cloud economics finalizes cost reporting against budgets.

Despite LinkSnap’s simple DR plan and best-effort single-region design, the production gate passed unanimously, culminating in a fully governed, audited release.

---

Quick Tips & Tricks

1. Define Clear Voter Roles Per Phase
   Tailor voting teams to project milestones (e.g., security votes beginning at Architecture) to ensure relevant expertise drives approvals.

2. Use Markdown Files for Governance Artifacts
   Commit all votes, checklists, and outputs to Git as immutable Markdown files. This creates a transparent, version-controlled audit trail without extra tooling.

3. Load Agent Skills Conditionally Based on Context
   Use keyword scanning of ADRs to activate only the relevant domain-specific AI skills, reducing noise and computational cost.

4. Employ Simple File-Based State Markers
   Manage phase transitions with existence checks on marker files instead of complex state management systems for robustness and simplicity.

5. Run Agent-Initiated Code Reviews Before PR
   Let AI agents audit generated code and pipelines inline, catching vulnerabilities or misconfigurations early in the build phase.

6. Budget API Token Spend Early
   Integrate agent economics into project intake and review phases to monitor and control AI compute costs across the delivery lifecycle.

---

Conclusion

The OMO Teams approach elegantly combines AI agent collaboration, adaptive skill loading, and strict governance with ARB gates to solve a thorny problem in multi-agent project delivery. By codifying governance as Markdown-committed outcomes and using real multi-voter quorum rules, it injects accountability and auditability into automated workflows often criticized for their opaque decision-making.

Most compelling is how early detection of risks—manifesting as conditional ARB approvals—significantly lowered project risk and increased confidence. The adaptive agent teams and minimalist orchestration model reinforce flexibility without sacrificing control.

As AI agents become staples of software delivery, frameworks like OMO Teams offer a blueprint for managing complexity and aligning AI workstreams with business and security priorities. The future of governance-as-code in AI project workflows looks promising and poised for wider adoption.

---

References

1. OMO Teams: Multi-agent project delivery with ARB gates — Original project walkthrough by Luke Murray
2. Oh My OpenAgent Team Mode — Agent team orchestration framework documentation
3. OpenCode AI Agent Framework — Underlying AI agent harness for OMO Teams
4. Azure Container Apps Documentation — Hosting platform used in LinkSnap project
5. Cosmos DB Serverless Overview — NoSQL database service powering LinkSnap’s backend
6. Agentic Operations Lakehouse: Drasi & Microsoft Framework — Related agentic operational frameworks from Luke Murray