Frontier promotion

Status: target state. No code in @open-matrix/agents implements frontier promotion today. This page describes the design intent so present-state pages can correctly say "the promotion mechanism for X is target state."

A frontier, in the meta-harness sense, is the set of candidate mutations (prompts, tool sets, skills) that have passed evaluation thresholds and are eligible to be made live. Promotion is the act of moving a candidate from the staging directory (<host-home>/prompts/staging/, etc.) into the live directory (<host-home>/prompts/).

The proposer-evaluator-promoter pattern

proposer agent ──► writes candidate to staging
                       │
                       ▼
evaluation harness ──► runs N iterations, scores them
                       │
                       │  if score ≥ threshold and constraints all green
                       ▼
promoter ──────────────► copies candidate to live, archives prior live to history
                       │
                       ▼
next session pickups   ─► PromptTemplateLoader sees the new live template

What's wired today

The mechanical pickup: PromptTemplateLoader will read whatever is currently in promptsUserDir (live).
The recording infrastructure: HarnessIteration records score and constraintResults.
Skills: SkillDescriptor already carries a version field, so versioned promotion is naturally expressible.

What's NOT wired

A staging directory convention (no <host-home>/prompts/staging/ is treated specially).
A promotion CLI (hivecast harness promote <candidate-id> does not exist).
A history directory or rollback path.
A frontier.list actor op that returns the eligible candidate set.
Any automation that decides which candidate to promote — promotion would be operator-initiated until a policy emerges.

Why no automated promotion yet

The honest reason: there is no canonical evaluation score yet (see evaluation harness — score is a free-form number). Until the score schema is concrete, "auto-promote when score ≥ 0.8" is a number without a unit.

WORKSTREAMS/stanford-harness/EVOLUTION-ARCHITECTURE-v3.md is the design doc for closing this gap. The user's memory note (MEMORY.md § Evolution Architecture (CRITICAL)) tracks it as the supersedes-all current redesign target. No code yet.

Operator playbook for the manual workflow

If you want to evolve a prompt by hand today:

Copy the live prompt to a working copy: cp <host-home>/prompts/foo.md <host-home>/prompts/foo.staged.md.
Edit the staged version.
Spawn an evaluation session through agencyInvoke({ profileKey: 'evaluate', … }) with the staged prompt path.
Score the result by hand or by parsing constraint results.
If acceptable, replace foo.md with the staged version (atomically — write a temp file then rename).
Restart any AgentActor children that have a stale prompt cached.

This is a manual process. The frontier-promotion machinery would automate steps 3-6.

Frontier promotion ​

The proposer-evaluator-promoter pattern ​

What's wired today ​

What's NOT wired ​

Why no automated promotion yet ​

Operator playbook for the manual workflow ​