How we build · you⊕us

Watch a change earn its merge.

Our agents write the code. That is exactly why every change walks a gauntlet no human team would sit still for: adversarial review by an agent that didn't write it, a merge gate that refuses unproven work, and an expert sign-off at the end. Below is one real change from our own platform — sanitized, but not simplified.

01 · One real change

The change that got caught

A pull request from our own repositories, carrying a security claim and a green test suite. Most processes would have merged it. Here is what ours did instead.

Step 1 · Dispatch

The task is written down before work begins

Every task starts as a spec in the state store — scope, constraints, and what done means. Agents work from the record, not from memory of a conversation. If it isn't written down, it doesn't get built.

Step 2 · Implementation

An implementer agent opens the pull request

Isolated working copy, focused diff, tests included. The PR body made a containment claim: requests to internal network targets are refused. Attached was the evidence — a passing test with exactly the right name.

“Internal targets are refused — see test_internal_targets_refused, passing.”
Step 3 · Adversarial review

A reviewer agent rebuilds the attack

The reviewer is never the author, and on security-relevant paths it does not accept the implementer's evidence — it re-derives it. It traced the claim from the shipped entry point and found the test had built its own client to prove the guard worked. The product's real code path never routed through that guard: on the shipped path, the request went out first.

Verdict: block — the test proves the guard works, not that the product uses it.
Step 4 · The gate refuses

The merge gate reads verdicts, not arguments

Merging is mechanical: the gate evaluates its conditions and one of them — no blocking verdict at this exact commit — now fails. There is no one to persuade. The only way through is to fix the code and clear the review.

Step 5 · Fix and re-review

The fix is proven the way the claim was made

The guard moved onto the shipped path, and the test now exercises it through the product's own entry point. Re-review happens at the new commit — a review of an older version of the code counts for nothing.

Step 6 · Merge

Gate green, expert signs off

Checks green, review at the exact commit being merged, reviewer distinct from implementer, no blocking verdict. The gate authorizes; a person — not a model — approves what ships. That is the expert review gate from our homepage, doing its job.

merge-gate · sanitized replay
$ merge-check
── gate ───────────────────────
✓ required_checks_green
✓ review_exists
✓ covers_head_sha
✓ reviewer_not_implementer
✕ no_blocking_verdict
└ security review: block
refused — merge not authorized
 
… fix lands, review clears …
 
$ merge-check
── gate ───────────────────────
✓ required_checks_green
✓ review_exists
✓ covers_head_sha
✓ reviewer_not_implementer
✓ no_blocking_verdict
✓ authorized — awaiting expert
02 · The standing rules

Rules that don't depend on anyone's mood

The walkthrough above isn't a story about one good catch. It's what happens when the process is built to distrust its own output. Four rules do most of the work.

Claims cite their source

Any claim of the form “X is refused” or “Y cannot happen” must cite a test that exercises the control through the shipped entry point — not a test that merely exists. Reviewers check this as a named item, every time.

The reviewer is never the author

A separate agent, with a mandate to rebuild the attack rather than read the diff. On sensitive paths the review is adversarial by charter: it assumes the evidence is wrong and tries to prove it.

The gate reads verdicts, not prose

Merging is authorized by a mechanical gate over a checklist of conditions — checks green, review at the exact commit, no blocking verdict, reviewer distinct from implementer. A persuasive PR body moves it not at all.

State outlives the conversation

Tasks, reviews, verdicts, and decisions live in a database, not in a chat window. Any agent can pick up where another left off, and the audit trail of every change — who built it, who reviewed it, what blocked it — is queryable after the fact.

03 · What this means for you

Your system gets built the same way

This page describes the process we run on our own platform — the one that builds our products and this website. Client engagements run on the same machinery: agent teams do the building, adversarial review does the doubting, and the expert review gate keeps a person accountable for everything that ships.

When the engagement ends, the process hands over with the system: the review checklist, the gate conditions, the documentation. You keep the discipline, not just the code.

04 · Start

Have a system that needs to ship?

Your domain expertise ⊕ our engineering team. A 30-minute call is enough to tell whether this is a fit — bring the problem, no prep needed.

Book a call

Founded by scientists turned AI leaders — national-lab research backgrounds, then senior data science and AI roles shipping production systems across logistics, security, and adtech.