OMO Teams: Structured Multi-Agent Project Delivery with Governance Gates

The cloud development landscape is evolving rapidly, with AI agents increasingly handling code generation, security reviews, and infrastructure deployment. However, a critical gap has emerged: while individual agents perform specific tasks well, there's been little structure connecting their work, creating governance vacuums where accountability disappears. The result is projects where no one can definitively say who approved what architectural decision or why a particular approach was chosen.

This is the problem OMO (Oh My OpenAgent) Teams addresses through a structured, five-phase approach to AI-assisted project delivery with Architecture Review Board (ARB) gates. The system introduces real governance, immutable audit trails, and structured escalation paths for AI agent work, addressing the accountability vacuum that has emerged in cloud development workflows.

The Five-Phase Governance Model

The OMO Teams framework organizes the entire project lifecycle into five distinct phases, each with dedicated AI agent teams and ARB gates that must be passed before progression. This structure ensures that critical decisions receive proper review and documentation before implementation.

Each phase has different voter sets because the decisions at each gate address different concerns:

Phase	Voters	What they're signing off
Phase 0 - Intake	Product Owner, Cloud Economics	Is the business case sound? Is the budget real?
Phase 1 - Architecture	Principal Architect, Security Lead, Product Owner	Are the ADRs correct? Is the threat model complete?
Phase 2 - Build	Principal Architect, Product Owner	Does the code match the architecture?
Phase 3 - Validate	Security Lead, Product Owner, Cloud Economics	Do the tests pass? Are there open security findings?
Phase 4 - Prod	Product Owner, Security Lead, Cloud Economics	Are the runbooks ready? Has DR been tested?

The voters are defined in a YAML configuration file that feeds into a Python tally script. This script reads individual vote files, checks quorum requirements, and writes an immutable outcome. The system avoids complex dashboards or SaaS approval workflows, instead using Markdown files and a simple Python script to maintain governance as code.

Dynamic Team Composition Through Conditional Skill Loading

What makes OMO Teams particularly powerful is its dynamic team composition. Each team is defined by a JSON configuration file in .omo/teams/, specifying a lead (always the "atlas" subagent acting as phase coordinator) and a list of members with specific capabilities.

Each member has two skill loading mechanisms:

1. always_load: Skills that load regardless of project context
2. conditional_load: Skills that load only when specific keywords are found in Architecture Decision Records (ADRs)

For example, a backend architect working on a Cosmos DB project would automatically have "cosmos-db-nosql-patterns" loaded, while one working on Postgres would get "postgresql-npgsql" instead. This allows the same team configuration to adapt to different technological contexts while maintaining consistent governance processes.

Members also consume load_instructions - paths to instruction files containing coding standards, style guides, and compliance rules that get prepended to their prompts. This keeps domain knowledge centralized rather than duplicated across every member prompt.

The system includes a trivial_project_skip flag that allows the orchestrator to skip members irrelevant to simpler projects. For a straightforward API project, specialized roles like data architect or frontend builder can be automatically excluded, streamlining the process without compromising governance.

Phase Progression and State Management

The orchestrator tracks project progression through marker files in .sisyphus/state/. When phase1-gate-approved.md exists, Phase 2 can begin; if it doesn't exist, ARB Gate 1 must run first. This file-based state management eliminates the need for complex state variables or databases, keeping the system simple and auditable.

The ARB Gate System: Real Governance in Practice

The Architecture Review Board represents the core innovation of OMO Teams. Every gate invokes the same arb-review team with four members:

1. Janus (chair): Always loads governance-gate, azure-well-architected-assessment, pressure-test, and risk-register. Runs evidence inventory, writes WAF assessment, assembles gate checklist, collects votes, and tallies outcomes.
2. Product Owner voter: Always loads pressure-test and votes on alignment with business intent, success metrics, budget, and scope.
3. Security voter: Always loads threat-modelling and votes on threat mitigation, OWASP findings, and compliance.
4. Cloud Economics voter: Always loads cost-optimization, agent-economics, and azure-cost-calculator and votes on budget adherence and cost variance.

The quorum rules are strict: 4/5 votes = APPROVED, 3/5 = CONDITIONAL (mandatory revisions), 2+/5 = REJECTED (phase must be redone). In case of deadlock, Janus writes an escalated.md file that surfaces to a human arbiter.

Every vote, checklist, and outcome is committed to .sisyphus/knowledge/arb/{phase-gate}/, creating an immutable audit trail of all decisions.

Real-World Application: The LinkSnap Project

To demonstrate the system, the author applied OMO Teams to LinkSnap, a deliberately simple URL shortener API built with FastAPI, deployed on Azure Container Apps, with Cosmos DB for NoSQL. The simplicity ensured the focus remained on the process rather than the product.

Phase 0: Intake

The intake phase featured a single product-owner agent with substantial capabilities including business-case development, risk register creation, and agent economics estimation. The output required six documents before the ARB would convene: problem statement, success metrics, budget constraints, compliance scope, risk register, and stakeholder map.

For LinkSnap, the product-owner identified seven risk items, including a prescient note about the team's lack of production experience with Azure Container Apps secrets (R01). The agent economics budget was set at approximately $18 in total token spend across all phases.

Phase 1: Architecture

The architecture phase involved the most complex team structure, with six members running in three sequential waves. Wave 1 featured parallel work by backend and infrastructure architects. The backend architect produced API design ADRs, while the infrastructure architect handled hosting platform, secret management, and deployment decisions.

Conditional skill loading proved valuable here - the backend architect automatically loaded "cosmos-db-nosql-patterns" when "cosmos" appeared in the project brief, while the infrastructure architect loaded "identity-managed-identity" when "key vault" was mentioned.

The ARB gate at the end of Phase 1 caught a critical issue: the managed identity ADR specified using managed identity but didn't address local development authentication. The security lead's conditional vote forced two mandatory revisions: documenting the DefaultAzureCredential fallback path and deciding between Cosmos DB private endpoint or public access with IP firewall.

This conditional approval proved the system's value - catching a security vulnerability before it became code, saving what would have been a painful retrofit later.

Phase 2: Build

The build phase featured six members running in two waves. Wave 1 produced contracts, with the backend member generating the OpenAPI specification. Wave 2 implemented the actual solution, with four members active for LinkSnap (two skipped due to trivial project mode).

The backend member built the FastAPI app with three endpoints, managed identity authentication to Cosmos DB, and a container image pinned to a specific Python 3.12-slim digest. The infrastructure member created the Bicep template for Container Apps environment, Cosmos DB, ACR registry, and RBAC assignments.

Code review caught issues including a hardcoded ACR URL in the CI pipeline and an unpinned base image - both resolved before merge. This demonstrates the advantage of agents that review their own work rather than discovering issues in production incidents.

Phase 3: Validation

The validation phase ran three members without skips. The integration member verified architecture alignment, the QA member performed functional testing, and the security engineering member implemented threat mitigations and security hardening.

Load testing with 50 concurrent users showed average response times of 180ms for writes and 45ms for reads, with Container Apps scaling appropriately. Security scans found no critical vulnerabilities, and known gaps were documented in the runbook.

Phase 4: Production

The final phase focused on production readiness, with reliability, runbooks, and cloud economics members. The runbook covered health checks, log queries, scaling commands, and escalation contacts, with DR documented as a single-region best-effort arrangement appropriate for a quickstart project.

Economic Impact and Efficiency

The system tracked agent token budgets across all phases, with the agent-economics skill allocating 510,000 tokens total. Actual usage came in under budget at approximately 460,000 tokens, costing roughly $16 at current API pricing - making it "the cheapest governance process I've ever run."

Key Lessons and Business Impact

Three significant insights emerged from implementing OMO Teams:

1. Conditional gates provide maximum value: The conditional approval at Gate 1 caught real issues that would have been expensive to retrofit later, proving the system works when things aren't perfect.

2. Dynamic team adaptation: The conditional skill loading and trivial project skip features allow the same team configuration to adapt to different project scopes, from simple APIs to complex multi-service systems.

3. Artifact trail as audit foundation: Every approval, condition, and rejection rationale is committed as Markdown files, creating an immutable record that answers "who approved what and why" months later without digging through communication channels.

For organizations deploying AI agents in cloud environments, OMO Teams provides a governance framework that transforms unstructured AI work into accountable, auditable processes. The system's strength lies in its structural approach to governance rather than relying on individual diligence or chance discovery of issues.

The complete implementation is available in the OMO Teams Quickstart repository, containing all ADRs, vote files, gate outcomes, risk register entries, and the full application code. For organizations running AI agents on cloud projects and seeking governance structure, this pattern offers a practical starting point that can be adapted to specific organizational needs.