---
title: "Architecture"
description: "The four-layer model (Module → Agent → Collaboration → Governance), the design principles, and the relationship to existing methodologies."
canonical: "https://architecture.reopt.ai/architecture"
language: "en"
last-updated: "2026-10-20"
alternate-markdown: "https://architecture.reopt.ai/ko/architecture.md"
site-index: "https://architecture.reopt.ai/llms.txt"
source: "reopt architecture"
---

# Architecture

> The four-layer model (Module → Agent → Collaboration → Governance), the design principles, and the relationship to existing methodologies.

Execution unit, owner, collaboration rules, governance — the four layers stack to complete the structure. Each layer answers a question the previous one cannot.

## Why four layers

Each layer answers a question the previous one cannot. Module alone cannot answer "who owns this outcome," so Agent is required. Agent alone cannot answer "how do they collaborate," so Collaboration rules are required. Collaboration alone cannot answer "is the product evolving safely," so Governance is required.

## 4 Layers

### Module

Defines the conditions and boundaries of an execution unit.

- **Responsibility:** The product's minimum execution unit. Performs one capability and returns a result.
- **Contract:** Declares input conditions, output format, authority scope, and refusal conditions as a contract. Because the contract is decoupled from the model, swapping the model leaves the contract intact.
- **Operation:** Tracks call count, cost, output quality, and failure reasons.
- **Observed metrics (examples):** Average cost per call, failure rate, average response time, contract-violation count
- **Protocol reference:** MCP Tool Definition — input/output schemas play the same role as the MCP tool schema

### Agent

The actor that owns and judges outcomes.

- **Responsibility:** The actor that owns and judges outcomes. Uses one or more modules to reach a goal.
- **Contract:** Declares goal, authority scope, delegation policy, and termination condition.
- **Operation:** Records judgment rationale, execution steps, and approval events.
- **Observed metrics (examples):** Goal-completion rate, average handle time, collaboration frequency, escalation rate
- **Protocol reference:** A2A Agent Card — declares the agent's goal, authority, and termination condition

### Collaboration

Rules for collaboration and information transfer between actors.

- **Responsibility:** Defines role allocation, information transfer, and flow coordination between actors.
- **Contract:** Defines collaboration rules, information-transfer scope, and cost-attribution rules.
- **Operation:** Monitors bottlenecks, wait time, rework, and collaboration failures.
- **Observed metrics (examples):** Collaboration-failure rate, average wait time, rework frequency
- **Protocol reference:** A2A Task Lifecycle — collaboration flow, state transitions, information transfer

### Governance

The operational layer that enforces evaluation, approval, cost control, and policy.

- **Responsibility:** Enforces evaluation, approval, cost control, and policy so the product evolves safely. It treats the model as a replaceable part and accrues expertise into internal traces and private evals to preserve model sovereignty.
- **Contract:** Provides guardrails, approval policy, evaluation criteria, and correction criteria.
- **Operation:** Monitors quality variance, policy violations, and human-intervention points.
- **Observed metrics (examples):** Guardrail-block count, approval wait time, quality-score distribution, policy-violation rate
- **Protocol reference:** Infrastructure-level guardrails (OPA, RBAC) — a policy-enforcement layer above protocol

_The point of the four layers is not to slice the product more finely. It is to make explainable who owns the outcome, who absorbs the failure, and how improvement iterates._

## Premises of the AI-Native Product

reopt architecture rests on the premise that AI-native products differ fundamentally from traditional software.

- **Non-deterministic execution** — The same input can produce different outputs. The design discipline is therefore not to guarantee outputs but to declare judgment conditions and refusal boundaries.
- **Duality of ownership** — The owner of an outcome can be a human or an AI. Human ownership allows contextual judgment; AI ownership requires every condition to be made explicit. This distinction determines how strict the governance must be. And human ownership is not merely defensive responsibility — setting an ambitious goal and connecting domains is the active half of ownership.
- **Balance of autonomy and control** — AI's value comes from autonomous judgment, but unchecked autonomy produces agentic debt. To raise autonomy, you must first define the structure.
- **Speed is the default, structure is the choice** — In an era where AI can ship an MVP in a day, speed is not the differentiator. Only structure separates a sustainable product from a one-off demo.
- **Structure is governance** — Adding governance as a separate process invites teams to bypass it. Governance must come from the product's own structure to operate naturally.
- **Sovereignty lives in the loop, not the model** — Models get swapped; the learning loop remains. When a human sets direction and AI scales it, that expertise accrues as ours no matter which model arrives. What you control is not the model but the structure you build on top of it.

## Goals of this architecture

- Keep it explainable, at any scale, who owns which outcome.
- Declare judgment conditions and failure paths as contracts, so that structure itself becomes governance.
- Use the OCLS loop so that operational data continuously corrects the structure.
- Let the whole team (product, engineering, operations) communicate in the same structural vocabulary.

## Non-goals

- Does not prescribe the usage of any particular framework or library.
- Does not cover prompt-engineering technique.
- Does not recommend model selection or fine-tuning strategy.
- Does not require changes to organizational structure or HR systems.

## Agentic Debt — the debt that accrues when speed outpaces structure

Technical debt accrued at low speed. Agentic debt accrues at high speed. The faster AI builds, the faster a structureless product becomes a black box.

- **Authority Sprawl** (OWN) — As agents multiply, who holds which authority becomes untraceable. Agent identities, access scopes, and execution rights expand tacitly, producing security incidents and accountability gaps at the same time.
- **Contract Gap** (CONTRACT) — Modules and agents run without documented input/output, refusal conditions, or failure modes. Side effects of a module swap or prompt change become unpredictable, and there is no basis to define evaluation criteria.
- **Observability Gap** (LAYER) — Reasoning paths, decision rationale, and handoff reasons go unrecorded. When something fails, the cause cannot be pinpointed and the entire reasoning process turns opaque.
- **Validation Gap** (SHARPEN) — Evaluation criteria and guardrails are missing or exist only as ritual. Quality variance widens, dangerous behavior is found only after the fact, and the feedback loop for improvement is broken.

## Design Principles

If the principles below stop holding, reopt architecture regresses into yet another bundle of feature-driven automation.

- **Design around responsibility units, not features** — An agent is not a function caller — it is a continuously explainable owner of outcomes.
- **A module is not a callable tool — it is an execution unit with a contract** — Only when a module has a contract does the structure support evaluation, replacement, authority control, and testing.
- **Scale is possible only when governed through classification and structure** — As agents multiply, structuring them into categories, layers, and boundaries is what keeps governance intact and scale sustainable.
- **Architecture is a system that evolves in operation** — Responsibility boundaries and policies must keep adjusting from failure logs and evaluation outcomes.

## Relationship to existing methodologies

reopt architecture inherits insights from existing software architectures, extending them to the non-deterministic execution and governance requirements of AI agents.

### DDD — Bounded Context

- **Shared:** Bounded Context and Responsibility Boundary address the same problem: explicitly separating responsibility boundaries and structuring communication across them.
- **Difference:** The DDD Bounded Context is a static boundary for domain-model consistency. The responsibility boundary in reopt architecture is designed for non-deterministic agent execution and is adjusted dynamically from operational data. DDD also does not treat governance as part of the architecture, while reopt architecture includes the governance layer as a baseline structural element.

### 마이크로서비스 — Service Contract

- **Shared:** Service Contract and Module Contract share the same principle of defining contract-based interfaces between services.
- **Difference:** Microservice contracts focus primarily on the input/output schema of the success path. The Module Contract in reopt architecture treats failure conditions, refusal logic, and authority scope as required elements. Because AI agents are not deterministic, "when to refuse" matters as much as "what to return."

### Conway's Law

- **Shared:** The observation that system structure mirrors organizational structure applies to agent systems too. The collaboration structure between agents becomes the system architecture.
- **Difference:** Conway's Law describes the passive reflection of organizational structure into the system. reopt architecture flips this: by deliberately designing the agent organization, it determines the system structure. The Responsibility Partitioning pattern is the concrete method of that deliberate design.

### Anthropic — Brain/Hands/Memory 분리

- **Shared:** Both share the principle of separating the system into components that can evolve independently. Anthropic's three-way split — Session (memory), Harness (brain), Sandbox (hands) — corresponds structurally to reopt architecture's four-layer model.
- **Difference:** Anthropic's separation comes from an infrastructure-operations perspective (container fault recovery, security isolation, deployment independence). The four layers in reopt architecture come from a governance perspective (attribution of responsibility, contract validation, collaboration coordination, policy enforcement). reopt architecture also breaks out Collaboration as its own layer, treating inter-agent handoff and context-passing rules as a separate design subject.

## Relationship to implementation patterns

The governance patterns of reopt architecture are complementary to Google's multi-agent implementation patterns and others. Governance patterns answer "what must be honored"; implementation patterns answer "how to build."

| Governance pattern | Implementation pattern | How they connect |
| --- | --- | --- |
| Responsibility Partitioning | Hierarchical Decomposition, Parallel Fan-out/Gather | A parent agent decomposes the goal into sub-responsibilities and delegates them. Parallelizable responsibilities are realized as Fan-out; sequentially dependent ones as Hierarchical. |
| Module Contract | Spec-Driven Development | The contract's input/output schema becomes an executable spec that generates code, docs, and mocks. An MCP Tool Definition is one concrete realization of a module contract. |
| Context Routing | Sequential Pipeline, Routing Pattern | At each pipeline step, rules filter and structure the context passed to the next agent. The Routing Pattern branches inquiries to the appropriate agent based on type. |
| State and Memory Control | Session Store / Vector Memory | Mostly an infrastructure-design concern. Key implementation work: separating session store (short term) from vector DB / knowledge base (long term) and controlling read/write authority. |
| Evaluation and Guardrails | Generator-Critic, Evaluator-Optimizer | A reviewer agent evaluates the generator agent's output. Up-front guardrails block before execution; post-hoc evaluation is realized through the Generator-Critic loop. |
| Human Approval | Human-in-the-Loop | Asynchronous approval queues and approve/deny callbacks are the core implementation elements. The default is an asynchronous structure that lets other work continue while approval is pending. |
| Cost Control | Token Budget Management, Model Routing | Combines route-based model selection (high risk = strong model, low risk = lightweight), per-agent token budgets, and caching/batching strategies to control the cost curve. |
| Decision Traceability | Structured Logging, Distributed Tracing | Collects per-agent decision logs in structured form (JSON, OpenTelemetry spans) and implements tracing infrastructure that captures causal relationships. |

---

_Markdown representation of https://architecture.reopt.ai/architecture. Full index: https://architecture.reopt.ai/llms.txt HTML original: https://architecture.reopt.ai/architecture · 한국어: https://architecture.reopt.ai/ko/architecture.md_
