Harnesses

Every place Frazer uses a model runs on a harness: the agent loop that turns a model into an agent. Frazer Agents, coding agents, every role in a squad, every Frazer Reviewer lane, plan checks and loops, decision panels, the monitor that files issues and the agent that fixes them, testing through the product’s screens and single model calls each name the harness they run on, and you choose it. The Frazer harness, Frazer’s own agent engine written in Rust, is the default everywhere, and open-source and vendor harnesses run beside it under the same guarantees. You try and compare them on your own work in the Lab and move a use to another harness when your numbers say it is better.

The short version

The guarantees live in the host, not in the harness: the cell, egress, credentials, the budget, the Fir session, receipts written by the host, policy before every call, and Fir deciding when work is done. A harness profile is one harness at an exact version with its models, tools, skills and context policy; every use names one. The Lab runs up to four harnesses side by side, replays thousands of your own tasks, and turns the results into recommendations a person applies. When money runs out, the work does not run and says so: “Not run: no funds”.

One host, many harnesses

Frazer runs a host for harnesses and its own harness as the default inside it. Any harness whose capabilities meet a use’s contract can run that use, and these hold whatever the harness:

1. The cell: one microVM per session, default-deny egress for every process, credentials through a proxy, and the grants ladder.
2. The budget: admission reserves the expected cost at every level before a use runs. If it cannot, the use does not run and says why.
3. The Fir session: every event of every harness lands in one session record, through the host.
4. Receipts written by the host: every model call (by the LLM gateway) and every Frazer or MCP tool call (by the tool gateway) is a signed receipt in the session. A harness’s own claims are never receipts.
5. Policy: action rules before each tool call wherever the harness has a per-call door; fixed rules for deletions, money and production; text from web pages, issues or tool output never changes a session’s mode, budget, permissions or loop.
6. Done on facts: Fir decides from assertion verdicts, checks at the exact version and an independent verifier. A harness can only claim.
7. Configuration from outside the cell: the host renders each harness’s settings, hooks, plugins and MCP configuration from the profile, from signed sources; nothing inside the cell can write them.

The Frazer harness is Frazer’s own, in Rust: its core is written by Frazer and built on borrowed open crates whose licenses are read from their files (Apache-2.0, MIT, BSD and MPL-2.0 only). Every borrowed part is credited in its notice file.

Fixes Frazer makes to a borrowed part are offered to its project under Frazer’s name wherever the project takes outside contributions, after a check of its license and contributor agreement. A Frazer engineer sends each one and answers its review, and every contribution says that an agent helped prepare it. Projects that take no outside code get an issue with the root cause instead, and the fix stays in Frazer’s copy.

A harness decides the rest, and that is what you choose it for: its loop and stop conditions inside the budget, its system prompt and tool descriptions, how it speaks each model’s tool dialect, how it manages context inside the window, its sub-agents and background work, and how it asks a person.

Uses and their defaults

Use	Default profile	Mode	What its contract asks
Coding agent, campaign task	frazer:coder	session	Headless; per-call rules; resume; a Fir session to commit
Managed or always-on agent	frazer:assistant	session	Wakes, memory as reviewed records, channels
Squad manager, worker	frazer:squad-lead, frazer:coder	session	The manager plans and delegates and never codes by default; a worker takes a typed brief and returns one typed handoff
Squad critic, tester, verifier	frazer:critic, frazer:tester, frazer:review-lane	session	Another model family than the author; blind to the author’s reasoning; read-only to the author’s code
Reviewer lane, first screens	frazer:review-lane	call	One request, schema output, no tools, no context beyond the item
Reviewer lane, deeper reads; verifier, adjudicator, final pass	frazer:review-lane	session	Read-only tools; a recorded, budgeted climb per step
Loop author, critic, tester, final pass	the drafter’s profile, frazer:critic, frazer:tester, frazer:review-lane	session	A fresh critic each turn; read-only guards
Plan check, model stage	frazer:call	call	Runs only after the static stages pass
Decision panel member	frazer:panel-member	call or read-only session	A sealed opinion; another family by lineage
Issue monitor, issue fix	frazer:monitor, frazer:fixer	call or session; session	Filing itself is deterministic; a fix needs a reproduction attested by Frazer CI before it edits anything but tests, and gets two attempts
Testing through the product’s screens	frazer:qa	session	Browser, desktop and preview tools; a test passes on checked state, never on a screenshot
Triage, CI fix, a dependency update’s agent step	frazer:triage, frazer:coder	call or session	Triage has no write grant; deterministic fixes come first
A single model call	frazer:call	call	A summary, a classification, a prompt the platform sends

Every default is a Frazer-published profile on the Frazer harness, and each moves only by your own measurements or a person’s choice. The default is the best measured profile for the use, not the cheapest.

The use contract

Each use kind has a contract that says what any harness must offer to run it and which rules the host and Fir enforce for it:

Field	Examples
requires	headless, schema_output, per_call_rules, resume, events.typed, call_mode, background_tasks, skills, mcp
tools	none (a call), read_only, workspace_write, full under the grants ladder
context	full, brief, diff_only, none (a cold review)
independence	For second opinions: another model family and another profile required, another harness preferred
rules	What the host and Fir enforce, such as an issue fix’s reproduction first, tests read-only and two attempts
who_may_override	The role that may assign another profile for this use

A harness version’s capabilities come from Frazer’s compatibility checks, never from a vendor’s description alone. A profile is eligible for a use when its capabilities cover the contract; otherwise every screen and the CLI say why (“not eligible: no structured output in headless mode”). A failed check removes the version from the uses that need it and says so; it never falls back to another harness silently.

Harness profiles

coder-opencode.yaml

apiVersion: frazer.ai/v1
kind: HarnessProfile
metadata: { name: coder-opencode, project: acme-production }
spec:
  harness: opencode@2.0.3 # an exact version; follow: stable moves it with the channel
  mode: session # session | call
  models:
    routes: { plan: auto:plan, execute: auto:coding, verify: auto:verify }
    switchWithinStage: on # one setting turns it off
    neverDown: [plan, review, verify]
  tools:
    toolsets: [fir, ci, previews, issues]
    codeMode: on
    skills: skillSets/acme-web@3 # locked into the session at start
  context: { policy: full }
  budgetDefaults: { perSessionUsd: 15 }

• Names. Frazer’s profiles are frazer:<name>@<revision> (frazer:coder@7); yours are <org>:<name>@<revision> (acme:coder-opencode@2). Screens show the family across revisions (frazer:coder).
• Revisions. A profile is versioned like an agent revision: immutable, eval-gated, rolled out in guarded steps (5, 25, 50 and 100 % of sessions) with automatic rollback, and pinned per session. A new harness version, setting, tool or skill set is a new revision, sealed by a person or by a calibration policy a person approved.
• Open models. A profile may route to open models on your own GPUs where the harness supports the gateway’s endpoints.

Assignment

The most specific assignment wins: the item (a plan, a lane, a squad role), then the use, the project and the organization. The organization’s harness policy bounds all of them: the allowed harnesses and versions, channels, credential modes, the independence floor and data terms. The result must be eligible.

frazer harnesses assignments set review_lane:security/authz --profile acme:security-cc@1 --validate-only
frazer harnesses explain s-6a03

frazer harnesses explain returns the chain (“item none → use review_lane:security/authz → acme:security-cc@1, set by amara on Nov 2 → policy allows it with your own key”), and every session’s receipt names its profile revision. A change is a plan with the uses it touches and an estimate: project admins change project assignments, organization admins the policy, and a use’s owner its use. An agent proposes and never applies, except inside a calibration policy a person approved. No assignment can turn off the cell, egress, receipts, the session, done on facts or the budget.

Call mode

A profile with mode: call sends one request with a schema-constrained output, no tools and no state beyond its receipt. Where a harness offers such a call, the adapter uses it; otherwise the host’s own call executor runs the step with the profile’s prompt, model and schema, and the receipt says “host call”. So every harness in the catalog can serve Frazer Reviewer’s first screens, which are most of its work.

Independence for a second opinion

A second opinion requires another model family by lineage and another profile with a blind context and no shared session state; another harness is preferred, and required for the highest risk class or by your policy (independence: harness). The verifier’s receipt records both sides’ harness, profile revision and family, so auto-merge reads an attestation it can check. Because the host writes the receipts, a second opinion can also check the evidence path: whether the author’s session really read the file, ran the test or queried the table its claim rests on.

The harness contract

Every harness meets the same contract inside a Frazer cell:

Item	Rule
Identity	A session token that names the person, the agent and the Fir session
Input	The task or the typed brief, the binding (plan item, campaign task, issue), In force, the budget and the profile
Control	The adapter’s protocol: ACP first, then a harness’s own server or SDK protocol, then headless JSON
Session	Opened before the first model call; every event appended through the host; resumed from a checkpoint
Model calls	Only through the LLM gateway, with a receipt per call: model, tokens in, cached and out, cost, latency and the route decision
Tool calls	Frazer and MCP tools through the tool gateway, with attested receipts; a harness’s built-in shell and edits run inside the cell, observed by the cell and reported by the adapter
Skills	Mounted read-only at the paths the harness scans; the skill lock written into the session at start
Permissions	Action rules at the harness’s per-call door; the cell, egress and grants always
Budget	Admission before start; the cap enforced by the gateway between requests
Configuration	Rendered by the host from the profile; the harness cannot write its own settings, plugins, hooks or MCP configuration
Processes	Every process stays in the session’s process tree and cell; no daemon outlives the session; no self-update; no environment carried from one session to the next
Keys	No provider key in the cell or in a harness vendor’s cloud; the gateway injects credentials
Exit	0 done (a claim), 13 needs a person (including “cannot be done as written” and no funds), 20 escalated, anything else failed. Fir decides done

The contract is versioned and only grows. Its current version adds the Agent Client Protocol’s v1 and v2 negotiated per connection, MCP’s 2026-07-28 revision, provenance labels on what a harness reads, the repository’s own configuration read only after the cell’s trust decision, credentials as placeholders and capabilities rather than values, retry budgets with a countdown, limits on fan-out, typed denials, and loop breakers in the host rather than the harness.

Tier	Which harnesses	Per-call rules	What is attested
Native	The Frazer harness	Before every tool call	Everything: model and tool receipts, policy decisions, its step journal
Adapted	Harnesses with a control protocol and hooks, such as OpenCode, Hermes Agent, Codex, Claude Code, Gemini CLI, Goose and OpenHands	Where the harness has a door	Model receipts and Frazer and MCP tool receipts; built-in tool events declared by the adapter
Boundary	Harnesses with no per-call door	No: the cell, egress and grants enforce	Model receipts; tool events declared from the harness’s stream; commands and writes observed by the cell
Remote	A vendor’s hosted agent loop, run against Frazer’s sandbox or as a remote member of a squad	The vendor’s	Model receipts where the gateway carries the calls; otherwise imported and labeled “ran outside Frazer”

The catalog

Each entry in the catalog has a status: certified (passes Frazer’s compatibility checks), candidate (license and terms read, checks pending), lab only, maintenance (no release in a year: kept and flagged) or not offered (for example, a license that forbids hosted use). An entry shows its license, language, activity, tier, credential modes, an incident history (a vendor breach, a silent change of defaults, a regression Frazer saw) and the results it scored on your own work. Results are shown inside your organization, never on the website.

Claude Code runs with your organization’s Anthropic key, your own Bedrock, Vertex AI or Foundry credential, or the monthly API credits your Claude plan includes, claimed into a key in the Claude Console. A person may also run Claude Code signed in with their own Claude plan on their own dev box or in a cell of their own; agents never use it, and its receipt shows what the session would have cost on a key. Frazer offers no claude.ai sign-in and never stores its token.

Every harness version passes these checks before it runs a use:

Check	What it proves
Process audit	Every process the harness starts stays inside the session’s cell; none outlives the session; no self-update; no environment pinned from one session to the next
Egress through every path	A blocked host stays blocked when the request comes from the harness’s background service, a sub-agent or a background shell
Configuration immutability	The harness cannot write settings, plugins, hooks or MCP configuration that a later session, or the same one, loads
No keys outside Frazer	Vendor features that store provider keys in the vendor’s cloud are off in cells
Call mode, schema output, session mapping	A schema-constrained call works; a run’s output validates against the use’s schema; a resume after a kill lands on the same Fir session

An improver edits a harness’s own prompts, tools and memory between runs instead of doing the work itself. Improvers such as Harness² run over an executor harness only in Lab cells with no outside network, never in production sessions, and their edits reach production only as a profile revision with its gates.

The Lab: try, compare, simulate, calibrate

• Try. A playground session: any harness or profile on a task you type or pick (an issue, a failing test, a plan item), in a workspace at a snapshot of your repository, with the grant none so nothing leaves the workspace, a budget ($5 by default) and receipts as in production. Up to four harnesses run side by side on the same task and snapshot, each with its stream, cost, time and the diff it produced. Use for… turns a try into a proposed assignment.
• Compare. Profiles (harness, model, effort, tools, context) on a standard set of your tasks, with the null baseline in every result.
• Simulate. A simulation (hsim-…) replays many of your tasks across candidate profiles, so a choice rests on your own work at the size of your traffic.
• Calibrate. Your organization’s table of task class to recommended profile, with the interval, size and date of each cell, re-fitted weekly and after every harness or model release. It proposes assignments; a proposal applies by itself only inside a calibration policy (cp-…) a person approved, otherwise it waits for the use’s owner.

Field	Default
mode	shadow until a person approves the policy (every proposal computed and shown with what it would have done, none applied); on after the approval; off is the kill switch
allowed	The harnesses your organization has enabled, at the stable channel
uses	Executor uses: coding agents, campaign workers, the CI fixer, the issue fixer, the dependency updater’s step; never an evaluator
classes	Every task class of the project; a class leaves scope when its sample falls under the minimum

Every applied change is a profile revision with a canary and one-step rollback, and a small holdback keeps measuring the old profile. What always waits for a person, even inside the policy: a change that widens what a use may do (a lower tier, more tools or grants, another credential mode, prompts going to another vendor); a change that loosens a check (the second opinion’s independence floor, a guard band, the margin); any change to an evaluator (a Reviewer lane, a verifier, a critic, a tester, a panel member, a grader); and a harness version whose terms changed since they were accepted or that has an open incident. A waiting proposal goes to the owner’s Needs you with its evidence and one button, never on a timer. Only an organization admin sets the policy (a project admin narrows it); an agent reads it and never sets it.

Part of a simulation	Rule
Tasks	Merged pull requests with the history cut and hidden tests, recorded Fir sessions (the task, the base snapshot and the brief, never the transcript), eval sets and reproduced issues
Sizes	Smoke 30, standard 200, thorough 600, at scale 1,000 to 10,000 tasks, stratified by task class, repository, language and size; every size says the gap it can detect before it starts
Candidates	Up to eight profiles, plus a null baseline: a minimal open-source agent loop with the same model, so each candidate’s lift is shown
Would-merge	Hidden tests pass, the plan’s checks pass at that version, Frazer Reviewer’s verdict (blind, another family) passes and no integrity flag is raised
Results	Pass rates with 95 % intervals, pass^k, the would-merge rate, cost and time per would-merge, tokens, cache hits, tool errors, failure classes and lift over the baseline, per stratum; ties within the interval are drawn as one band
Stopping early	A task pair stops once its outcome is settled; with more than four candidates the weakest are pruned after the first round, and their budget goes to the rest
Integrity	Graders outside the cell; trajectories kept; passing runs reviewed for reward hacking
Price	Usage, with the estimate shown first and a hard budget; only what ran is billed; infrastructure failures are never billed

hsim-5c30 · storefront: which harness for web tasks · lena · done Nov 17 04:02 (6 h 52 min)
1,200 tasks from acme/storefront (merged Jun 1 to Oct 31) · 5 strata · 4 candidates · 3 trials
9,180 runs of 14,400 planned (stopped early where settled) · $7,940 of a $9,000 budget (estimate, list prices)
web:ui      acme:coder-opencode@2 61 % ±3 would-merge · frazer:coder@7 62 % ±3 · tie · 18 % lower cost
migrations  frazer:coder@7 leads by 7 points, outside the margin
baseline    every candidate +9 to +16 points over the null baseline
Calibration proposes: coder-web → acme:coder-opencode@2 for web:ui only · apply needs lena

The output above is product UI with demo data. The Frazer harness’s own revisions go through the same Lab before they reach customers, on Frazer’s own repositories and live traffic.

Versions, revisions and postmortems

• Channels. Each harness version is certified separately and offered on stable and latest; a profile pins a version, and a channel move makes a candidate revision with its own checks.
• The Frazer harness’s revisions are gated per model, soaked, rolled out to a 5 % canary with a one-step rollback, and checked by an online comparison on live traffic before they reach every session. A canary lasts until it can detect the regression it guards against, and the screen says what it can detect by when.
• Public postmortems within 7 days. Every Frazer harness regression that reached customers gets a postmortem (hpm-…): detected, rolled back in one step, a draft within 72 hours and the postmortem published within 7 days. It says what changed (the revision and its diff), which sessions it hit, how it was detected, the impact in numbers (sessions, organizations, duration, cost), the root cause, what Frazer changes (its reproduction becomes a check for the next revision) and the limits or credits restored. Postmortems are on each harness’s Regressions tab and in a feed agents read (frazer harnesses postmortems list, harnesses_postmortems_list). A regression Frazer measures in another company’s harness becomes a regression notice on that entry, with the facts from Frazer’s checks and the upstream issue.

Models inside a stage

A harness may switch models inside a stage, by default; one setting turns it off (switchWithinStage: off) for the organization, a project, a use or a profile.

• Only the harness switches inside a bound session, and the switch is priced: each model has its own cache, so a switch reads the context again. The gateway enforces the allowed set and never substitutes a model itself.
• Never down for plans, reviews, verification, a loop’s critic and final pass, panel members and security lanes. Moving up after two hard turns without progress is allowed.
• Every switch is a model_switch event on the receipt, with its reason and the cost of reading the context again.
• An adapted harness switches only where its adapter can change the model per turn; otherwise it keeps the stage’s default, and its catalog entry says so.

The tools the harness gives agents

Toolset	What agents do with it
Fir	Records, workspaces, search, code intelligence, why, stacks
Sessions	Checkpoint, read a handle, resume
Frazer CI	Run, read results, re-run what failed
Previews and test runs	Create a preview and read its URL, see what a change affects, plan and run tests (Frazer QA)
The browser and desktop	Open, snapshot, click, fill, run a script with one receipt per step, wait, check, read the network and console, sign in, hand off (Browsers for agents)
Issues and evidence	File, attach evidence, reproduce (Issues)
Skills	Load a skill by origin and digest, search (Skills)
Routing	Explain and recommend a route
Approvals and person tasks	List approvals, request a person task; an agent never decides an approval
The Lab	Try, compare, simulate, read the calibration
Code mode	A script over typed stubs of the tools above, for bulk work

Every tool has a JSON schema, typed errors that name the next call, an idempotency key on every side effect, a receipt per call (one per step inside a script) and a description within 200 characters. Tools load on demand unless they are among the few always loaded, and untrusted content is wrapped with its origin.

No funds, no run

Before a use runs, admission reserves its expected cost at every budget level and checks the organization’s balance. If it cannot, the use does not run and says so on the object it would have acted on (the pull request, the plan, the lane, the campaign task): “Not run: no funds”, with the balance, the budget that blocked it and the fix. In the CLI that is exit code 13, needs a person, with the reason FUNDS_EXHAUSTED and a next call; a person task of kind purchase opens when only a person can act, because an agent never pays. Work already running stops at its next turn boundary with a checkpoint: “Paused: no funds”. Frazer never runs a cheaper harness, model or depth instead.

Prices

The host, the catalog, profiles, assignments, revisions and postmortems have no fee, and neither does running any harness, the Frazer harness or an open-source one. A session’s runtime bills at the agent rates ($0.05 per active vCPU-hour) and its model calls at the gateway’s prices: the provider’s list price plus 5 %, or no fee on your own key. Lab runs bill as usage, with the estimate before the run and a hard budget; calibration tables are free.

Reference

CLI

Command	What it does
frazer harnesses list	List the catalog's harnesses, by use, tier or kind, with their status and where each runs in your organization.
frazer harnesses get	Show a harness at a version, with its tier, license, credential modes and the capabilities its compatibility checks found.
frazer harnesses enable	Enable a harness for a project, as a plan that records the terms you accept.
frazer harnesses profiles create	Create a harness profile (harness at an exact version, models, tools, skills, context policy); list, get, update and revisions complete the set.
frazer harnesses assignments set	Assign a profile to a use at the organization, project, use or item scope; with --validate-only, check eligibility and print the plan.
frazer harnesses explain	Explain which profile a session ran on and why, from the item to the organization's harness policy.
frazer harnesses try	Run up to four harnesses side by side on one task, in a workspace that nothing leaves, within a budget.
frazer harnesses compare	Compare profiles on a standard set of your tasks, with a null baseline.
frazer harnesses simulate	Replay up to 10,000 of your tasks across candidate profiles and report would-merge rates, cost and lift, within a hard budget.
frazer harnesses calibration get	Your organization's table of task class to recommended profile; propose and apply turn it into assignments.
frazer harnesses postmortems list	The Frazer harness's public postmortems and the regression notices on other harnesses' entries.

All of them: CLI reference.

MCP tools

Tool	What it does
harnesses_list	List the harness catalog.
harnesses_explain	Explain which profile a session ran on and why.
harnesses_assignments_set	Assign a profile to a use. Writes become a plan that waits for approval.
harnesses_simulate	Start a simulation of your tasks across profiles, with its estimate first. Writes become a plan that waits for approval.
harnesses_postmortems_list	The Frazer harness's postmortems, as data.

All of them: MCP tools reference.

Events

Event type	When it is sent
agents.harness.simulation_completed	A simulation finished, with its results.
agents.harness.assignment_changed	A use moved to another harness profile.
agents.harness.process_audit_failed	A harness version failed the process audit and left the uses that need it.
agents.harness.postmortem_published	A postmortem of a Frazer harness regression was published.

All of them: Events reference.

The API is frazer.agents.v1.HarnessService. The Frazer harness itself runs as frazer harness, which accepts only its own words (-p, acp, mcp, resume); a catalog verb typed there exits 2 with next: frazer harnesses <verb>.

For agents

You run on the profile your use was assigned; frazer harnesses explain <session> says which and why. Propose a different assignment as a plan, with a simulation when it matters; never apply one yourself. On “Not run: no funds” (exit 13, FUNDS_EXHAUSTED), stop and follow next: never retry with a cheaper model or a shallower setting.

Related

• Frazer Agents: agents, their sandboxes, wakes and memory
• Sessions: the record every harness writes
• Skills: the skill lock each session starts with
• Squads and campaigns: harness profiles per squad role
• Frazer Reviewer lanes: call mode and the second opinion