Developers • Connections • Engineering Council • AI Developer Agents

Build against evidence, not assumptions.

The OMOS developer surface exposes runtime health, provider state, persistence state, governed Council APIs, Decision Records, connection contracts, and the Engineering Council workflow used to move changes from issue to production proof.

Model Gateway

OpenAI, Anthropic, Gemini, xAI, and future OLLM connectors normalize capability, health, invocation, review, telemetry, error, and provenance fields.

Open Model Connectors

Connection Gateway

Model connections answer who OMOS reasons with. Data, action, and environment connectors answer what OMOS can securely read, synchronize, invoke, or operate. These remain separate contracts.

Open Connections & Adaptation

Source-of-Record Sync

GitHub, Drive, WordPress, Stripe, PostgreSQL/Supabase-compatible infrastructure, QRV, OneGodian APIs and ACC keep their own authoritative roles. OMOS correlates state without silently replacing the source system.

View source matrix

MCP

The OneGodian MCP Standard is architecturally defined but not represented as a completed production gateway until conformance, authorization, deployment, and runtime evidence pass.

MCP architecture

Developer applications are not the OMOS control plane

Codex, ChatGPT, Claude, Gemini, Antigravity, GitHub agents, and other development environments may hold their own connected-app permissions. Those integrations are useful for engineering, review, and deployment work, but they do not automatically grant the OMOS runtime equivalent access. Runtime access requires a separately defined OMOS connector, capability scope, health state, provenance record, and authorization policy.

AI Developer Agent Registry

Agents may perform engineering work. They do not self-authorize Production.

OMOS separates engineering roles so implementation, review, security, deployment, and final human authorization are not collapsed into one unverified action. Named products are tool bindings to these roles only when the binding and permission scope are actually configured.

Codex Developer Agent

Deep implementation, APIs, refactors, tests, debugging, schemas, and repository changes. Default authority: branch and pull request; not final Production certification.

GitHub Engineering Agent

Issue-native implementation, branch/PR maintenance, repository automation, CI remediation, and evidence collection within configured GitHub permissions.

Antigravity Developer Agent

Application and UI implementation, browser validation, integration testing, and independent application-level inspection where configured.

Architecture Agent

Interfaces, service boundaries, ADRs, schemas, dependency analysis, and architecture review. Advisory unless separately authorized to write code.

QA / Test Agent

Unit, integration, regression, replay, browser, and failure-path validation. A code-writing agent cannot be the sole certifier of its own changes.

Independent Review Agent

Code, architecture, evidence, contradiction, and release review independent from the primary implementation role.

Security Agent

Secrets, authentication, authorization, dependency risk, permissions, data boundaries, and attack-surface review. Security findings can block release.

Deployment Agent

Staging/Production rollout, smoke checks, deployed-SHA verification, runtime health evidence, rollback readiness, and deployment records under approved authority.

Documentation Agent

README, API, architecture, operations, changelog, runbook, migration, and evidence documentation synchronized to implemented behavior.

OMOS Engineering Coordinator

Classifies work, assigns roles, tracks dependencies/evidence, enforces separation of duties, and produces the Engineering Record. Coordination is not unilateral Production authority.

Agent permission rules

Least privilege and repository scope by default.
No developer agent is granted provider secrets or Production credentials merely because it is registered.
No implementation agent is the sole final reviewer of its own consequential changes.
Tests, security findings, dissent, and deployment failures remain part of the evidence record.
R3/R4 changes require stricter independent review, explicit human approval, and deployment proof.
Human authorization remains the final boundary for consequential merge, credential, payment, destructive, infrastructure, and Production actions.

Canonical Engineering Council

GitHub Issue → Task Classification → Agent Assignment → Agent Work → Pull Request → Cross-Agent Review → Tests / CI → Security Gate → OMOS Review → Human Approval → Merge → Deployment Proof → Engineering Record.

Green CI is necessary but not sufficient. A merge is not completion; production proof must identify the exact deployed revision and demonstrate the required behavior in the target environment.

Engineering task states

INTAKE → CLASSIFIED → ASSIGNED → WORKING → PR_OPEN → CROSS_REVIEW → CI → SECURITY → OMOS_REVIEW → HUMAN_APPROVAL → MERGED → DEPLOYING → PROOF → COMPLETE. Hold/failure states: BLOCKED, NEEDS_REVISION, REJECTED, ROLLED_BACK.

Risk classes

R0 documentation/non-executable · R1 low-risk UI/content · R2 application logic/API/schema · R3 authentication/payments/data/migrations/infrastructure · R4 production/security/destructive/high-impact.

ACC relationship

ACC is the operator control plane for registering approved agents, assigning work, observing queues/tasks/workflows, supervising separately authorized execution, and preserving execution evidence. OMOS supplies governed reasoning, policy/evidence discipline, Human Gate and Decision Record boundaries; connected source systems retain their own authority.

Runtime endpoints

Health · Manifest · Providers · Persistence · OMOS-REF-0001 · Oru’Valen