Oronts Engineering Harness

We do not let AI grade its own homework

Work passes a fixed loop, an independent model, and evidence gates before it reaches your repository.

The harness is a proprietary control plane we built and operate in-house. It turns AI coding from fast generation into an engineering organization with durable memory, independent review, and owner gates. It governs our own delivery, including this website.

claude · order-service
$ claude fix the order status race
understandtraced 3 consumers
implementRED test, minimal slice
verify18 passed
reviewcodex + 2 opus lenses
findingHIGH race on status transition
fixroot cause, reviews re-run
reviewclear
gatepush: your approval

How does Oronts keep AI-written code trustworthy?

By removing the two shortcuts that make agentic coding unreliable. The model that writes the code never clears it, and the conversation is never the source of truth. Review runs on a different model, and state lives in durable files that survive a context reset.

  • A different model reviews the work, backed by two adversarial lenses and specialists routed by changed surface
  • Reuse is checked against the real dependency graph, so it cannot simply be asserted
  • Done means acceptance met with current evidence, not one passing test
  • Product, legal, and irreversible decisions stay with the owner
The problem

Four failure modes, four mechanisms

Ordinary agentic coding fails in four predictable ways. The harness answers each one with a mechanism rather than a promise.

Failure modeWhat actually happensThe mechanism
It generates instead of engineeringNew code appears even when the framework, the standard library, or the repository already solved it.A reuse ladder that stops at the first correct rung, plus a checker that fails a plan citing a package or path that does not exist.
It forgetsContext fills, the conversation is compacted, and the agent loses the goal and asks you to re-explain.Durable memory files are the source of truth. Resume injection fires on start and on compaction and continues the exact next action.
It grades its own homeworkThe model that wrote the code reviews the code and clears it.A different model reviews, plus two independent adversarial lenses and routed specialists, reconciled by evidence and re-run fresh after every fix.
It ships the happy pathOne passing test, no negative cases, no runtime proof, and it is called done.Done means acceptance met, risk-appropriate evidence current against the live Git fingerprint, reviewers clear, and state synchronized.
Real output

What a run actually looks like

Two panes from a real session. On the left the loop reports each stage as it happens. On the right the read-only status observer derives one snapshot from the memory files and live Git, and prints it.

claude · order-service
$ claude
SessionStart: reconciling git, injecting durable state
resumeT-008 active, next action recorded, 1 gate open
understandtraced 3 consumers of OrderProjection
reuseladder stopped at rung 4 (framework native)
checkplan cited @acme/retry, not in dependency graph
planrewritten, acceptance + non-goals recorded
implementRED test first, then minimal root-cause slice
verify18 passed, runtime proof at exact scope
reviewcodex + 2 opus lenses + database specialist
findingHIGH race on concurrent status transition
fixroot cause, reviews re-run fresh
reviewclear, evidence current against ad2fcd4
gateG-004 push to origin: owner approval required
stopped at owner gate, state persisted

A finding sends the work back to verification rather than forward to a commit. The run stops at an owner gate instead of pushing.

oronts-status --watch

$ node .claude/tools/oronts-status.cjs --watch

HEAD
ad2fcd4 · tree: clean
active
T-008
next
German barge-in
gates
G-004
TASKS
12 total · active 1 · ready 4 · completed 7
BLOCKERS
1
FINDINGS
crit 0 · high 0 · med 2 · low 5 (2 open of 7)

The observer never writes a file and never mutates Git. Deleting it would leave the engineering loop unaffected.

The loop

One cadence, effort proportional to consequence

Every substantial task follows the same cadence. A typo gets one focused check. A payment race, a migration, or an authorization path gets a design debate, specialist review, and live runtime proof. The depth comes from consequence, never from how many lines changed.

1

Understand

Reconcile the live repository state, trace the real flow and its consumers.

2

Research and reuse

Walk the reuse ladder and ground every claim in the actual manifests.

3

Debate

Only for genuine design forks. Independent alternatives, then an adjudicated decision.

4

Plan

An executable task contract with acceptance criteria and explicit non-goals.

5

Implement

A failing test or characterization evidence first, then the minimal root-cause slice.

6

Verify

Risk-appropriate evidence at exact scope, run against the current tree.

7

Independent review

A different model, two adversarial lenses, and specialists routed by changed surface.

8

Record and continue

Sync docs, memory, decisions and history, then take the next item or stop at a gate.

Findings send the work back to verification, not forward to a commit. The loop closes only when reviewers are clear.

Reuse ladder

Stop at the first rung that solves it correctly

The harness optimizes for the minimum new code required for a correct system, not for maximum visible coding. A deterministic checker grounds every reuse claim in the real dependency graph, so a plan that cites a package the repository does not have will fail before implementation starts.

  1. 1Does this need to exist at all?
  2. 2Does the repository already do it?
  3. 3Does the standard library do it?
  4. 4Is it native to the framework or platform?
  5. 5Does an installed dependency do it?
  6. 6Is there an existing extension point?
  7. 7Only then: the minimum new code
Architecture

One engine, three concerns, one gate

Named entry points feed a single engine. The engine drives reasoning, determinism and durability in parallel, and everything irreversible leaves through a gate that belongs to you.

Entry points

Plain language, a named skill, or a bounded autonomous campaign.

  • Skills33
  • Goal
  • Campaign

Engine

A single readable file handles the lifecycle events: reconcile Git, inject state, route effort, enforce gates. No hidden services and no background daemons.

  • engine.cjs1
  • Git reconcile
  • Resume injection

Reasoning

Independent reviewers and deterministic multi-agent fan-outs.

  • Review agents21
  • Workflows5

Determinism

Checks that pass or fail without a model in the loop.

  • Tools24
  • Rules37

Durability

State that outlives the conversation and any context reset.

  • Memory files15
  • Hash-linked ledgers

Owner gate

Irreversible and commercial actions stop here in every permission mode, including unattended runs.

  • Push and publish
  • Release and deploy
  • Destructive operations
  • Secret stores

The control plane is copied into a repository and governs it. It ships generic; each project fills its own state.

Independent review

A different model, not a second opinion from the same mind

Four independent review questions plus a decision mechanism. Findings are reconciled by evidence, not by majority vote. One correct blocker outweighs ten clears. After any fix, reviews re-run fresh against the changed work, because a reviewer that touches the tree invalidates the previous fingerprint.

ReviewerThe question it asks
Cross-model reviewWhat is wrong that the writing model, being the same mind, may have missed?
Correctness lensCan this fail, corrupt, leak, race, or violate expected behavior?
Maintainability lensIs this understandable, minimal, free of duplication, and correctly placed?
Routed specialistsIs this correct for security, database, API contract, UI, infrastructure, or AI?
ArchitectWhich way does a genuine design fork go? It decides rather than voting.

Specialists activate by changed surface, not per project. A migration pulls in the database reviewer, an authorization boundary pulls in security, a distributed workflow pulls in concurrency.

When the cross-model reviewer is unavailable, the harness records it as unavailable and adds another independent lens. It never reports a review that did not happen.

Evidence ranking

What outranks what

The ranking is explicit and survives a change of model. A passing test is authoritative about observed behavior. A reviewer is authoritative about whether that behavior is the right invariant. Neither substitutes for the other.

  1. 1Executable tests and runtime evidence
  2. 2Independent cross-model review
  3. 3Same-model review
  4. 4Lead reasoning
  5. 5Assertion
Durable memory

Compaction is a checkpoint, not a reset

The hardest problem in long autonomous runs is context. It fills, the conversation is summarized, and a naive agent forgets the goal and stalls. The harness treats the summary as a checkpoint. Durable files hold the goal, the current task, the exact next action, decisions, blockers, evidence and history, so the conversation can be discarded while the state survives.

State, not conversation

Memory files are the source of truth. The transcript is disposable.

Resume on start and on compaction

A hook reconciles Git and re-injects the live fingerprint, the active task, its acceptance criteria and the open gates.

Owner instructions survive

Prompts are captured deterministically, so ad-hoc instructions that never became a task are not lost.

It continues rather than waiting

After reconciling, it resumes the recorded next action instead of asking for context it already holds.

Capabilities

Skills, plugins and MCP servers

Capabilities sit in three layers so the system stays cohesive and fast rather than a bundle of overlapping tools. Prefer a core capability, escalate to a specialist only for genuine depth, never install a duplicate of something the core already does.

33 named entry points into the loop

A skill is how a task enters the cadence at the right depth. Names are the product's own identifiers and stay unchanged in every language.

Start and route

  • start
  • route
  • triage
  • plan
  • estimate
  • capabilities

Build

  • implement
  • fix
  • refactor
  • ui
  • api-change
  • database-change
  • ai-change
  • infrastructure-change
  • dependency-change

Assure

  • review
  • verify
  • audit
  • security-review
  • red-team
  • gdpr
  • debate

Operate and hand over

  • autopilot
  • campaign
  • memory
  • doctor
  • handoff
  • finish
  • release
  • present
  • team
  • adopt

Bundled

  • excalidraw-diagram

Enabled plugins

Six plugins form the reasoning and review backbone. They are wired into the loop rather than offered as optional extras.

  • superpowers

    Systematic debugging, test-first method, planning and verification, invoked on every task so debugging is reproduce-then-fix rather than guess-and-check.

  • codex

    An independent, genuinely different model for review. Same-model review shares the same blind spots; a different model breaks that correlation.

  • andrej-karpathy-skills

    Guardrails against common model coding pitfalls: assuming instead of asking, over-engineering, and sprawling diffs.

  • impeccable

    Product and design grounding for interface work, so screens are anchored in a real product job rather than generic output.

  • claude-mem

    Cross-session recall, supplemental to repository memory and never overriding what Git says.

  • claude-obsidian

    Optional knowledge-base integration for durable business and domain context.

Every enabled plugin loads its descriptions into every session, so the enabled set is deliberately small.

MCP servers, routed on demand

Data connectors are wired to read and search operations only, so an autonomous session cannot mutate those systems. Browser automation can act on a page, so any external effect is owner-gated rather than performed silently.

  • Context7read

    Version-correct library and framework documentation instead of guessing from training data.

  • GitHubread

    Current dependency facts, pull request and issue context, and upstream source.

  • Playwrightbrowser

    Real browser proof for interface journeys, so a screenshot supplements the proof rather than being it.

  • filesystemread

    Scoped, structured file access for research across a large tree.

  • memoryread

    A supplemental recall graph, subordinate to repository state.

  • sequential-thinkingreason

    Structured multi-step reasoning for a genuinely hard problem.

  • opentabsbrowser

    Authenticated browser access through your own session, used sparingly and gated for any write.

Per-project specialists

Language experts, real static analysis and narrow domain tools are installed per repository rather than baked into the shared configuration, because every enabled plugin costs context in every session.

For security-critical work the gap over model review is real analysis: a static analysis engine plus a dependency, container and infrastructure scanner run alongside the security reviewer, because an analyzer catches classes a model review misses.

Anatomy

What is inside the control plane

The harness ships generic and project-agnostic. It is copied into a repository, and each project fills its own state. One readable engine file drives the lifecycle. There are no hidden services and no background daemons.

LayerCountRole
Engineering rules37Always-loaded standards, plus language and surface packs
Skills33Named entry points into the loop
Review agents21Independent reviewers, specialists and investigators
Workflows5Deterministic multi-agent fan-outs
Deterministic tools24Self-checks, graders, synchronization and the status observer
Memory files15Durable state that survives compaction
Reference documents36Architecture and protocol specifications
Templates34Decision records, contracts, runbooks, threat models
Engine1A single readable file handling the lifecycle events

Measured against the repository on 5 September 2026. The harness is a proprietary Oronts product and is not published; we walk through it live on a call or under an NDA.

Owner gates

What it never does on its own

Autonomy is bounded by design. Irreversible and commercial decisions are denied at the permission layer in every mode, including unattended runs, and cannot be granted by an instruction in chat.

  • Product semantics, visibility and retention policy
  • Licensing, pricing and public breaking contracts
  • Production access, deployment and release
  • Publishing, force pushes and destructive git operations
  • Destructive infrastructure actions
  • Reads of credential and secret stores
  • Any reduction of a security control

When it must ask, it asks with evidence: the options, the tradeoffs, an analysis, a challenge from the independent model, and a recommendation. The decision is yours; the research is not your job.

Honest limits

What we do not claim

Known limits are engineering facts, not things to hide. An enterprise system is not one with zero uncertainty. It is one where uncertainty is known, bounded, visible, and backed by evidence proportional to its consequences.

Enterprise does not mean maximum architecture

The harness carries a process that derives the right architecture per project, not one universal stack. A small internal utility and a multi-tenant platform get different rigor from the same system.

A healthy process is not a shipped product

A green harness proves the engineering process is healthy. Your product becomes production-ready when its own gates are green: load numbers, migration and rollback proof, isolation tests, and a security pass.

The reuse checker has a boundary

It is a sound reference-integrity check against manifests and files, not a full package resolver for every ecosystem.

Architecture quality is partly judgment

It is backed by independent review rather than claimed as an automated guarantee.

What you get

Why this matters to you, not to us

Code you can defend in review

Every change carries its acceptance criteria, its evidence, and the reviewer verdicts that cleared it.

A decision record, not folklore

Design decisions are written down with their alternatives and reasoning, so your team inherits the why and not just the what.

Speed as a consequence

Rigor is the goal and speed follows from not rebuilding what exists and not re-litigating settled decisions.

Full ownership at handover

The control plane governs the work. The code, the decisions and the documentation are yours.

Questions engineering leaders ask

AI writes code inside a governed loop with a senior engineer accountable for the result. The mechanism that matters is not who typed the line, it is what had to be true before it could ship: acceptance criteria met, tests and runtime evidence current, an independent model finding nothing, and the design decision written down.
A style file gives consistent formatting and a few rules. It has no durable state, no independent review, and it loses the goal when context is compacted. The harness adds memory that survives a reset, review by a different model, deterministic checks, and gates that stop the work rather than warn about it.
It is recorded as unavailable and an additional independent lens runs in its place. The harness never reports a review that did not happen. That rule is why the evidence trail is usable in an audit.
No. Deployment, release, publishing, force pushes, destructive git and infrastructure operations, and reads of credential stores are denied at the permission layer in every mode. They cannot be enabled by an instruction during a session.
The harness is a proprietary Oronts product and is not part of the deliverable. What you receive is the outcome: your code, your tests, your decision records and your documentation, with full ownership and no dependency on our tooling to run or change the system.
Yes. We walk through a real run on a call, or under an NDA if the repository content is sensitive. The 90-Day Production Pilot is the normal way to see it applied to your own codebase.

See it run against a real problem

Bring a change you would normally be nervous about. We will walk through how the loop handles it, what evidence it produces, and where it would stop and ask you.

Who you're working with

HRB 288224
Registered in Munich
15+
Years, founder-led
DE · EN · AR
Delivery languages
2
Open source on GitHub
EU
Data residency, Frankfurt
AVV/DPA
Ready to sign, Art. 28

Engagement levels

Oronts works with serious teams that need senior delivery, not low-cost outsourcing.

Production Pilot
from 25k EUR
Custom software and AI projects
from 50k EUR
Ongoing technical retainers
from 15k EUR/month

Exact pricing depends on scope, responsibility, delivery speed, team size, integrations, support expectations and production risk.