COLORADO STARTUP WEEK · SEP 14 2026

Build Your Own Harness
for Fun And Profit

How to choose, evaluate, and build harnesses
with explicit guarantees

Define it
Judge it
Build it
01

What you'll get

Sixty minutes buys you
a checklist and a live demo.

0:00Calibrate the room
0:06What a harness actually owns
0:16The authority test + ownership matrix
0:26Off-the-shelf vs build-your-own
0:35A live demo, and what it shipped
0:52Your decision template

Message passing between panes,
live. Then an app the harness
shipped at a hackathon.

02

One-room calibration

Where does
this room sit?

PromptRaise a hand if · why I am asking
Technical fluencyYou ship code most weeks — Sets how deep the internals go
Agent tooling todayYou used Claude Code or Codex this week — Picks which examples land
Build intentYou have considered your own tooling — Decides how long we spend on Beat 4
03

Why are we doing this?

Agents on a boat.

Hours, not minutesthis one was started on land and was still working when the photo was taken
Your laptop is not the runclosing it, or losing signal, ends nothing
Check in, do not babysitread the record, answer one question, put the tablet back down

None of that is a model capability. It needs durable execution and a record you can read from anywhere, which is what the rest of this hour is about.

A tablet on a table on a boat, showing a terminal with agent output, a reservoir and mountains behind itA gate run finishing. On a reservoir. On a Saturday.
04

Why now

The same model.
Two harnesses.

One model, ARC-AGI-3 Semi-Private.
Standard harness at max reasoning: 62.7%.
Provider adapter at high reasoning: 99.9%.
The adapter kept reasoning state across turns.

62.7% → 99.9% ARC Prize, 3 Sep 2026.
Not an AGI claim; one closed,
deterministic benchmark.
05

The landscape today

You are already choosing.
These are just a few options.

Vendor coding harnessesco-trained with their own model; they own context, tools and permissions for you
Claude CodeCodexGemini CLICursor
Open, model-agnostic harnessesMIT-licensed; the harness ships nearly opinion-free and you bring the model
OpenCodePi (pi.dev)
Research harnessesbuilt to measure the model, not to ship a product; maximum expressivity
Prime Agent
Personal assistantsthe agent gets its own computer and your personal context
OpenClawHermesOpenJarvis
Built inside a company, then openedshaped around one org's systems and permission model
QM
Yourswhatever you build after the exercise at the end
Orris + Orrisd

A snapshot, and this moves fast.

06

First principles

Strip it down.
What is left is the harness.

The model isfixed weights, a visible context, tokens in, tokens out. One prediction at a time.
The model is notfiles, tools, memory, other sessions, or anything that survives the call.
So the harness iseverything you added to make it useful. The layer between it and the world.

Every capability you think of as the agent's is something you built, bought or inherited. This is the subtraction to run before you design anything.

07

A short history · part one

The harness kept
taking things over.

A loopgenerate until the model stops. That was the whole harness.
Contextput examples in front of it, then let it reason in steps.
Toolslet it call something that is not itself.
Memorylet it read and write its own context, not just append.
Skillslet it keep what worked and reuse it.
Verificationlet something other than the model say whether it worked.
Orchestrationlet it start, sequence and stop other agents.

Each row is a responsibility the model could not hold on its own.

08

A short history · part two

Now it can
improve itself.

01The promptsearch over system prompts instead of writing one
02The harnessgenerate and score variants of the harness code itself
03The weightsfold what just happened back into the model

Everything before this was a static harness: a spec, a tool list, a skills list, a sub-agent list, in a loop. Past that line the harness starts rewriting itself — recursive self-improvement — and that is where the last year of progress sits.

Adapted from the YC Harness Club history. We build on the static side on purpose. Slides 20 to 22 cover what the other side actually is, and what it costs.

09

The inventory

A harness is seven-ish authorities
around a shared model.

Owns a fact
the model
can't assert
the lens
1Context & statewhat it sees · window, memory
2Toolswhat it can call · schemas, permissions
3Executionwhere work happens · worktrees, sandbox
4Orchestrationsequencing, delegation, cancellation
5Verificationwhat certifies the result · gates
6Observabilitywhat happened · traces, redaction
7Governance & recoverywho may stop, resume, reject

Governance + recovery constrains every other authority.

10

The configuration surface

An agent spec fits
on one index card.

System promptwho it is, what it may assume
Turn + tool budgetwhen it must stop
Tool listwhat it may call
Skills listwhat it already knows
Sub-agentswho it may delegate to
Context policywhat it keeps, what it compacts

Not the whole harness. Execution, verification, observability and governance still need owners.

Adapted from the YC Harness Club agent-spec summary. Write yours at the end.

11

WHO OWNS THE FACTS

A harness component owns a fact
the model cannot safely assert.

Evaluate every component by asking what guarantee breaks when it is absent.

Model proposes“it's done.”
Harness certifiesartifact + gate

If the model's claim is the only evidence, the claim is the oracle.

is it done?Ralph Wiggum, asking whether the work is done
12

The method, in two questions

Ask capability first.
Then set the authority boundary.

01 · Karten · expressivityExpressivityWhat can the system not do unless we build the missing primitive?run code · manage context · delegate
02 · This workshop · authority testAuthorityWhat must the model never be the sole authority to assert or control?completion · observed history · permissions

Build the first surface wide. Keep the second surface outside it.

Expressivity without an external boundary becomes unsafe. Authority without expressivity becomes brittle.

13

Apply the test

Name the fact.
Name the owner.

CATEGORYTHE FACTIF NOBODY OWNS ITEXAMPLE
ContextWhat state this run can seeThe model invents its historyReasoning state
OrchestrationWho does the work, in what orderThe planner also implementsPlan ≠ implement
VerificationWhether the result is acceptableA claim becomes the oracleGate, not claim
ObservabilityWhat happened, inspectablyFailure is unreconstructableJournal first
GovernanceWho may stop or reject a runPolicy drifts silentlyDefault deny

Five representative authorities. Tools and Execution are covered on the inventory and the execution-boundary slide.

14

HOT TAKE

Adding every component
is not automatically better.

Each part owns a fact
Each part costs you upkeep

A component that does not own a guarantee is cost without coverage.

15

You are here

The vocabulary is built.
Now the decision.

01Calibrate the room
02What a harness actually owns
03The authority test + ownership matrix
04Off-the-shelf vs build-your-own
05A live demo, and what it shipped
06Your decision template

Next: what an off-the-shelf harness already owns for you.

16

Off-the-shelf

What you get,
what stays shut.

What you getContext assembly and compaction, tuned. A tool contract that already works. Sensible permission defaults. Someone else's bug fixes.
What stays opaqueWhich harness produced a result. ARC Prize now labels both harness conditions for exactly this reason.

Most people should take the first. Some workloads require the second.

17

Name the layer

Workers execute.
The harness decides.

If you own a guarantee, this is the layer that holds it.

The control plane

Admitdecide which work may start
Chooseselect the worker and the budget
Enforcestop, gate, or retry when policy requires it
Recordpreserve what happened outside the worker

Workers can fail. The control plane must stay authoritative.

18

Proof object · Orris + Orrisd

Five facts the model
cannot assert itself.

DecisionWhat breaks without it · status
Append-only journal per runA crash becomes a guess — DELIVERED
Gate result is the oracle“Looks done” ships — PARTIAL
Two products, one contractOne process owns everything — PARTIAL
Telemetry is derived onlyDashboards drive behavior — PARTIAL
No run ends by vanishingA dead run reads as success — DEMOED

Our split: one product owns sessions and panes, the other owns runs, gates and the journal.

19

What it is actually built with

Built on the BEAM.
Status column included.

The harness I built, and where each authority actually lives in it.

RuntimeElixir on the BEAM; one OTP app per product — RUNNING
Durabilityappend-only JSONL journal, typed versioned events — DELIVERED
Run lifecyclea gen_statem over a pure reducer, supervised — PARTIAL
Panesstate machines, a registry, a durable intent store — PARTIAL
Typed edgesZoi validates the wire and document edges — PARTIAL
Gatessupervised Port workers holding real deadlines — PLANNED
API and consoleAsh actions and policies; LiveView over projections — PROPOSED

Parts of the pane layer are still shell scripts; that rewrite is proposed, not shipped. Postgres and Oban are nowhere in the execution path.

20

Self-improving harnesses

The harness itself
goes in the search space.

01Proposea variant: different prompt, tool set, budget, or harness code
02Runagainst real tasks, isolated, alongside the incumbent
03Scorea gate decides. Never the agent's own report on itself
04Keepwinners enter a versioned archive; the next round samples from it

What changes is persistent harness state; the weights are left alone. A computation that worked becomes a skill. A coordination pattern that worked becomes a sub-agent spec.

Beyond this: rewriting the harness code, then the weights. Almost nothing that works today goes there. The harness, not the episode, is the transferable unit.

21

Recursive self-improvement

A harness can only rewrite
itself if four things hold.

Observean append-only record of what actually happened, replayable without re-running side effects
Evaluatea deterministic gate outside the model — otherwise the optimiser learns to flatter the judge
Mutatethe spec is data: prompt, tools, skills, budgets. Not branching code you have to redeploy
Selecta versioned archive with provenance, and a way back when a variant regresses

When the refiner and the evaluator share a model, the score is evidence, not an independent verdict.

Miss one and you do not have self-improvement. You have drift you cannot audit.

22

What the stack has to do

Run many variants.
Remember all of them.

Cheap isolationa process, container or worktree per variant, so results cannot contaminate
Supervised recoverya crashed variant is a recorded outcome, never a mystery
An event logthe record is the truth; dashboards are derived and deletable
Cheap spawn and teardownyou will run far more variants than you keep

One property is not negotiable: the policy that bounds a run must sit outside what the run can rewrite. An optimiser that can widen its own permissions will.

Reported by the authors against their own system

An agent reached a privileged console command despite a check meant to stop exactly that, then saved the workaround as a reusable skill.

Their three controls: least-privilege interfaces · independent state validation · auditable rollback

Prime Agent, arXiv:2608.23552v1, §3.5

23

Execution boundaries

What can the
worst run reach?

Isolation does not make an agent safe. It makes the damage bounded and knowable. Only the second is something you can design.

Its own processstops colliding with your shell. Still reads and writes everything your user can.
A worktree per taskconcurrent runs stop overwriting each other. The filesystem is still shared.
A container or VMan explicit allowlist of what exists at all. Where “it cannot reach that” becomes true.

Disclosure: this workshop was built with approvals and sandboxing bypassed. A worktree, an external gate and a readable journal are compensating controls, not equivalent isolation.

The failures in this section are execution-boundary failures, not model failures.

24

One use-case, concretely

Point it at the
lifecycle you already have.

Specifya change small enough to land in one pass
Executein an isolated worktree, not your working tree
Verifyone deterministic command that would fail without the change
Reviewevidence a human can read, not a summary
Recordan append-only journal, so a crash is reconstructable
Recoverresume from the record, or fail closed and say why

Every step is a place a harness component earns or loses its keep.

SpongeBob pirate
25

What breaks in production

Everyone hits the
same four walls.

They stop too earlyso teams set a floor on effort before quitting is allowed
Approval goes stalethe human reviewing every write starts rubber-stamping it
Self-improvement narrowsagents fix their own slice and miss the system
They leak across contextsan agent does not know where information may travel
Reported by the authors against their own system

The agent deleted a working tool and wrote a replacement whose payload did not match the schema. The harness accepted the malformed call without erroring, recorded it as a success, and repeated it until the loop ended by accident.

What would have caught it: typed tool boundaries · independent validation · a bounded stop path

One repair pattern: lint every tool result, fix it with a cheap rescue model, then keep the error out of context.

Continual Harness, arXiv:2605.09998v1, App. B.3 · None of these are model problems. All four are owned by the harness or by nobody.

26

You are here

Enough architecture.
Time to show you the layer.

01Calibrate the room
02What a harness actually owns
03The authority test + ownership matrix
04Off-the-shelf vs build-your-own
05A live demo, and what it shipped
06Your decision template

Four commands. Ninety seconds. Everything you see lands on disk.

27

Demo · the substrate

Two panes. One daemon.
Watch the handoff.

ap statusthe daemon names the project, the session, the inbox and the socket
ap pane_statusit already knows whether the other pane is idle or busy
ap senda receipt comes back, and the other pane wakes
the envelopewhat actually moved: schema version, message id, from, to, in reply to

I am not going to demo a finished product, because there isn't one. What is finished is the layer underneath, which is what this hour has been about.

Four commands, ninety seconds. Everything you see on screen is on disk afterwards.

28

Demo · what the receipt proves

The sender asks.
The daemon decides.

I askap send names a pane and hands over text. That is a request, not a delivery.
The daemon answerssent, or queued with a reason. Queued is not delivered, and the receipt says which.
The receiver proves itthe envelope lands in that project's inbox: schema version, message id, from, to, in reply to.

Three parties, and only one of them decides. The capability is mine; the decision is not.

Slide 13 argued this. Slide 14 put it in a matrix. This is it happening, with the receiver's own copy as the proof.

29

What the substrate produced

One hackathon.
One hour to production.

The clocka hackathon window, and an app nobody had built before
First deploylive in production inside the first hour, from an empty repo
The extra timeorganisers extended it because other teams were behind; that went into the product
What carried ita harness that already owned environment, secrets, gates and release
The deployed Pocket Pets appPocket Pets, deployed. Built at the Dispersed hackathon.

One team, one clock, one app. It is what happened, not a promise about what would happen for you.

Pocket Pets, built for the Dispersed hackathon. These slides are wearing its palette.

30

Proof slice

Shows what happened.
Steers nothing.

Projections are derived and deletable.
Deleting them changes no execution decision.
Observability failure never edits a journal fact.

stage-safe view

Preselected safe view only.
The receipt and the envelope,
not arbitrary inbox browsing.

31

What this shows

Verification,
not trust.

Verification was the receiver's envelope and the queue state,
not the sender's claim that it sent something.

The boring parts,
owned.
32

Resources

Take the reading list,
not just the slides.

Build with it

Orris local-first workflow orchestrationOrrisd agent coordination runtimeJido Elixir agent framework — built Pocket PetsGuild a control plane for agentsProletariat agent orchestrationautodev

Harnesses worth studying

Pi “this one is yours”OpenCodeOpenClawHermesOpenJarvisQMDeepSeek Harness

The evidence behind the claims

ARC Prize: Astra 62.7% → 99.9%, same modelWhy the harness matters more than the model YC Paper ClubElixir’s AI Future — Chris McCord ElixirConf US 2025Prime Agent arXiv 2608.23552Prime Agent — write-upContinual Harness arXiv 2605.09998Continual Harness — project page

Community

ID345 local vibe-coding groupDispersed where Pocket Pets was built

Every link is clickable. Open what you need, ignore the rest.

33

Your turn

Define your harness
in three lines.

LineWrite it down
The one job my agent does
A fact I cannot let it assert…
The component that owns it…

Stuck? No owner → add the component. Would you notice it failing → instrument it. Can the model assert it safely → let it. Testable → make it a gate.

34

Close

Define your boundaries.
Keep tradeoffs visible.
Choose your path on purpose.

Name the guarantee
Give it an owner
Keep the tradeoff visible
35
1 / 35 ← → moveN notesF full screen P print / PDFG grid
Turn your phone sideways for full-size slides  ·  tap to dismiss