Governed software development for coding agents.
The agent writes code. DynosAI governs what may change, what must be proven, and when the work is actually done.
v1.0.0-rc.3 · Python + MCP · Local Studio · Codex and Cursor
Quick start
From source to a governed agent workflow.
Clone the RC, install it locally, configure Codex or Cursor once, then work with the provider normally.
Why DynosAI
A chat transcript is not an engineering control plane.
Coding agents can forget context, overstate changes, skip validation, silently broaden scope, or lose state when a session restarts. DynosAI turns the session into a persistent, evidence-driven workflow where Git and durable project state—not the chat—are authoritative.
Read why DynosAI exists- 1Need
Define the engineering need and create durable work state.
- 2Discovery
Inspect repository context, constraints, and relevant existing behavior.
- 3Specification
Turn intent into requirements and acceptance criteria before implementation.
- 4Plan
Define tasks, dependencies, files, actions, and validation profiles.
- 5Implementation
Execute only the approved work and keep changes inside governed scope.
- 6Verification
Compare agent claims with Git, scope, task, requirement, and evidence state.
- 7Validation
Run the configured project checks and record their real outcomes.
- 8Done
Finish only after required gates, evidence, and validation are resolved.
What it provides
Governance around the agent, not another agent wrapper.
Durable workflow state
Requirements, acceptance criteria, tasks, decisions, evidence, scopes, and gates live outside the provider chat.
Governed scope
DynosAI compares planned files and actions with the actual Git diff instead of trusting the agent's description.
Independent verification
An agent cannot simply mark its own work verified. Repository state and recorded evidence are checked by the Core.
Validation profiles
Run governed unit, lint, type-check, build, integration, security, or project-specific commands and store real outcomes.
Brownfield support
Index existing code, symbols, tests, and relationships to build an evidence-backed inferred baseline.
Governed teams
Approved plans become serial or parallel leases only when files do not overlap. Extra coding agents are not spawned.
Eval intelligence
Local failures become bounded eval cases. Improvement work stays in inbox. Predictive routing stays in shadow mode.
Execution profiles
Strict, Balanced and Autonomous are host-owned. Human gates stay required. OS-level network interception is not shipped.
Certified providers
Cursor ACP and Codex app-server are the shipped Studio transports. Additional clients are not assumed certified.
Model control
Track phase budgets, complexity, failures, context pressure, route candidates, and historical recommendations without reckless escalation.
Measurable evals. No invented waste.
RC3 imports failed acceptance ZIPs into bounded eval cases, publishes governed-change cost aggregates, and hashes a stable authority prefix. Unused advertised MCP tools are not scored as waste. This is not production-ready 1.0.
What DynosAI actually checks
Evidence before completion.
DynosAI verifies deterministic facts: Git files and status versus the plan, path scope, planned actions, requirement-to-evidence traceability, validation command exit codes, unresolved gates and scopes, recovery integrity, provider isolation, and acceptance Oracle results.
A Quality 100 score is a workflow/governance result. It does not claim universally perfect architecture, security, performance, or maintainability.
Read quality & validationHistorical 0.13 evidence
The core matrix remains historical, not a 1.0 live certification.
Codex and Cursor passed greenfield and brownfield in the 0.13.0 promotion. RC1 freezes contracts on that core; it does not copy those Quality 100 results forward as 1.0 proof. The four 1.0 cells stay unproven until real provider runs exist.
See validation evidenceTry it on one real feature.
DynosAI is open source under MIT. 1.0.0-rc.3 publishes eval-maturity evidence; it is not production-ready 1.0. Use normal engineering review and project-specific validation.