REOPT
ARCHITECTURE

A REFERENCE MANUALfor AI-native product teams.Fast to build, hard to break.

An architecture methodology for AI agent governance

In an era when AI ships an MVP in a day, speed is no longer the differentiator. Leading with speed and no structure accumulates agentic debt. reopt architecture is a reference methodology for designing AI products along three axes: ownership of outcomes, contracts for judgment, and evolution of structure.

In an era when AI makes everything fast, agentic debt accrues whenever speed outpaces structure. reopt architecture is the methodology for building fast without breaking.

Subject
Ownership of outcomes, contracts for judgment, evolution of structure
Audience
Every team building AI products — product, engineering, operations
Core question
Three months from now, can you explain why this AI product made that call?
OCLS · EXPLODED VIEW[ 04 STAGES ]OWNAssign the ownerCONTRACTDeclare the conditionsLAYERLayer the structureSHARPENTune from operations
OCLS — the governance loop

Core Thesis

Products Scale by Structure

As an AI product grows in complexity, three questions become the ones that matter: who owns this outcome (OWN), what are the conditions of this judgment (CONTRACT), and is this structure scalable (LAYER). If you cannot answer all three, the product becomes a black box.

The Trap of Speed Without Structure

Building a working product is easy now. The hard part is keeping it explainable and controllable as time passes. Without structure, speed turns into poison.

  1. 01

    Prompts alone do not become structure

    No matter how carefully you tune the prompt, it still cannot answer who owns the outcome or what happens when it fails.

  2. 02

    The faster you ship, the faster it becomes a black box

    A demo takes a day. But when cost, quality, approval, and accountability tangle, within three months no one can explain the product.

  3. 03

    There is no path from demo to production

    The first demo is easy. Without a structural path to team-scale operation and iterative improvement, the project stops at the demo.

The Five-Phase Methodology

01

Assess

Make the current state objective

Scan the product's requirements and structural risks across 17 engineering and business attributes. The first phase is the team seeing the same picture and agreeing on priorities.

Product Assessment
02

Define

Document the structural commitments

Lock the assessment results into GOVERNANCE.md. Declaring the four — ownership, judgment contracts, collaboration rules, improvement criteria — gives the loop and the execution a direction.

GOVERNANCE.md guide
03

Loop

Sharpen the structure through the four OCLS phases

  • OWNName the owner of the outcome — governance changes with whether the owner is human or AI.
  • CONTRACTDeclare judgment conditions and boundaries — the more an AI owns it, the stricter the contract.
  • LAYERLayer the product structure and scale.
  • SHARPENRefine the structure from operational outcomes.
Checklist
04

Execute

Make design decisions with patterns

Pick the right pattern for the situation and make the design decision. Responsibility Partitioning, Module Contract, Context Routing — when the team answers the judgment questions of the eight patterns, GOVERNANCE.md's commitments turn into real design.

Pattern catalog
05

Evaluate

Measure outcomes and iterate

Evaluate execution outcomes through the agentic-debt lens. Update GOVERNANCE.md, return to the assessment (phase 1). Each pass sharpens the structure.

Re-assess

Evolution Path

01

Single-Agent Start

Start AI automation on a small scale and accumulate baseline contracts and logs.

Transition signals
One agent juggles several roles and you can no longer tell which role caused a failure. · Prompt changes spill into unrelated capabilities. · You have enough per-module logs (call count, cost, success/failure) to track them independently.
Core deliverables
Per-module draft input/output contracts · Baseline execution logs (call count, cost, success/failure) · List of points where roles conflict
02

Responsibility Separation

Separate conflicting roles such as planning, execution, review, and deployment to sharpen responsibility boundaries.

Transition signals
Handoffs between separated agents repeatedly drop or duplicate context. · Parallel work is required that a single agent cannot perform. · Each agent reaches a state where it can be evaluated and improved independently.
Core deliverables
Per-agent responsibility statements · Handoff rules and context-passing schemas · Per-agent independent evaluation criteria
03

Multi-Agent Collaboration

Define collaboration rules and information flow to stabilize the product flow.

Transition signals
Collaboration flow is stable but quality variance is wide or cost is unpredictable. · Agents start acting beyond their authority, or human-approval situations recur. · Scale demands explicit enforcement of governance rules.
Core deliverables
Stabilized collaboration flow diagrams · Context-routing rules · State/memory separation policy
04

Governance by Design

Bake evaluation, approval, cost control, and policy enforcement into the product's baseline structure.

Transition signals
The OCLS loop runs as a standing operating cadence; boundaries and contracts update on a regular schedule. · Governance metrics (quality score, cost, policy-violation rate) are tracked steadily.
Core deliverables
Automated evaluation and guardrail pipelines · Approval classification matrix and escalation rules · OCLS-based recurring review process