Mountaineering
The mountaineering skill teaches agents how to climb hills. For any hill that can be identified, set up guardrails and climb it.
This is autoresearch applied as a discipline: assess the mountain, choose the route, pack the right gear, know when to turn back.
The Five Laws
Every successful climb requires five conditions to hold. See laws.md for the full treatment with examples and failure modes.
- Orderable Outcomes — The optimizer must be able to say "this is better than that"
- Measurement Consistency — The metric must score the same way twice
- Safe Exploration — Failed experiments must be fully reversible
- Scope Separation — The optimizer must not control the evaluation
- Informed Search — The optimizer needs domain knowledge to generate targeted hypotheses
If any law is violated, the loop will fail — often expensively.
Four-Phase Architecture
Phase 0: Climb Design
The hardest part of mountaineering is figuring out WHAT to climb. This phase turns "I want to improve X" into a fully specified climb. See climb-design.md for the complete protocol.
Six steps:
- Name the objective in plain language — the S5 anchor
- Instrument — inventory what data and signals you already have
- Candidate metrics — list 2-3 options, evaluate each against Laws 1-2
- Mutable surface — define what the climber can change and the blast radius
- Mutation types — enumerate edit types for YOUR understanding (not the climber's constraint)
- Candidate pipeline — rank what to try first; this becomes program.md's Context section
Without Phase 0, you arrive at pre-flight with a vague objective and no metric. Pre-flight correctly rejects it, but doesn't help you get ready. Climb design is where you get ready.
Phase 1: Pre-Flight
Run the pre-flight protocol (preflight.md) before starting any climb. Pre-flight is a collaboration between the agent and the operator — the agent runs mechanical checks, the operator provides judgment. A failed pre-flight saves tokens.
Phase 0 outputs map directly to pre-flight inputs — the selected metric feeds Law 1-2 checks, the mutable surface feeds Law 3-4 checks, the mutation inventory feeds Law 5 checks.
Phase 2: Harness Setup
The harness is the structural scaffolding that enforces the five laws during a climb. See harness.md for directory structure templates, config schemas, program.md templates, and evaluation script patterns.
Phase 3: Climbing (The Loop)
The iteration loop: propose change → test → score → keep or revert → repeat. One change at a time for interpretability. The climber reads failing cases and hypothesizes fixes — Law 5 in action.
Fast feedback: Use proxy metrics (binary pass/fail, immediate signals) for the first 10 iterations to confirm the climb is producing movement. Switch to the full metric for trend analysis after stabilization. Any signal that it's working or not is critical early on — don't wait for statistical significance before checking whether the climb is alive.
The Climber Subagent
The climber is a fundamentally different kind of subagent from identity agents:
| Identity Agent | Climber | |
|---|---|---|
| Loop | Event-driven | Infinite loop |
| Memory | Blocks + files + journal | Files only (sliding window) |
| Identity | Rich persona | None (goal + constraints) |
| S5 | Scaffolding (blocks, prompts) | Code + program.md (frozen) |
| Context per turn | Variable | Fixed budget |
| Lifespan | Persistent | Scoped to a climb |
Climber Memory (Three Layers)
- program.md — Frozen S5. Goal, constraints, scope. The climber cannot edit this.
- Workspace + evaluation — The harness. Evaluation logic is held in supervisor memory (not on disk). The climber operates within the workspace scope.
- Results log — Sliding window of recent results (last N entries via ring buffer). This prevents context growth while maintaining enough history for informed search (Law 5).
Skill Inheritance
The climber inherits whatever skills and tools the parent agent has configured. If the operator has set up a coding agent (e.g., acpx), the climber gets it automatically — no separate configuration needed. If not, the climber still works with built-in file tools.
This means the first test climb from an agent without a coding agent gets lightweight tools (file read/write/edit). A code-optimization climb launched from an agent WITH a coding agent gets the full toolset. Zero config, correct by default.
Fixed Context Constraint
This is load-bearing. Every iteration must wake up with roughly the same sized context. No accumulated conversational history. Each iteration is a fresh agent invocation that reads: program.md + current workspace files + last N log entries. That's it.
The results log is the climber's only memory between iterations. After each iteration, the climber should read the last N entries to understand what has been tried and what worked. The log is not a record for the operator — it is the climber's operational memory.
Supervision Protocol
The climber has minimal autonomy by design. It cannot flag that it's stuck or incorporate new ideas on its own. The supervising agent must monitor actively.
Intervention decisions:
- Keep running — trend positive, still improving
- Investigate — plateau detected, consider scope expansion or metric pivot
- Inject information — make git commits that change the workspace; the climber picks up changes next iteration
- Kill — stuck, budget exceeded, or hill no longer relevant
Peak detection → ridgeline traversal: When the hill is peaked, the supervising agent declares the peak, selects the next hill, and either reconfigures the current climb or starts a new one. See philosophy.md for the full framework.
Background Reading
For the theoretical framework behind mountaineering — VSM mapping, anti-gaming philosophy, recursive nesting, metric over-adherence — see philosophy.md. Understanding this background helps the supervising agent make better judgment calls, but it is not required for basic operation.
