Agent Self-Improvement Harness (2/12) — Manager/Runner Inversion and Four Self-Improve Triggers
Why workspace-runner was split into executor and decider
ํต์ฌ ์์ฝ
- The Manager / Runner hierarchy inverts under operational data. Because Runner determines the next action inside the loop more than 70% of the time, splitting Runner into executor (pure execution) + decider (branch selection) reduces both token cost and latency.
- Self-Improve must not run continuously. It fires only on four explicit triggers (daily / failure-pattern / user-feedback / external-update), each owned by a distinct initiator to eliminate a single point of failure.
- The dominant cost of sub-agent delegation is context backflow. Seven rules lock down authority, context passing, and result handoff — without them, token expenditure explodes on the second call.
Technique 1 — Manager / Runner Inversion
The initial design follows a conventional hierarchy:
- Manager (mir): decides what to do.
- Runner (workspace-runner): executes what was decided.
The assumption is "decisions at the top, execution at the bottom." Operational logs contradict this: Runner had to determine the next action mid-execution in over 70% of cases. Representative branches:
- No file found → switch to creation branch
- Empty result → retry with fallback option
- Output mismatches schema → insert validation step
When Manager mediates every branch, call count and attached context size grow super-linearly, driving token cost to runaway levels.
Mechanism — executor + decider split
Runner is divided into two roles:
- executor: input → side effects → output. No decision authority. Idempotent for safe re-execution.
- decider: receives executor output and state, selects the next step. A small model is sufficient in most cases.
Manager owns only the flow of the overall pipeline; the decisions inside the loop are owned by decider. The core of this split is redistributing "who holds decision authority" to align with the data flow direction — not simply adding another layer.
Measured effects and limitations
- Manager calls reduced by approximately 70%
- Perceived response latency reduced (per-loop Manager round-trips eliminated)
- If decider selects the wrong branch, the loop can silently derail internally — a 3-failure circuit breaker and observability logs are mandatory
Limitation: when the context supplied to decider (executor output alone) is insufficient — for example, when upper-task intent is required — a summarized context must be injected separately. As that summary grows, the benefit of the split diminishes.
Technique 2 — Four Self-Improve Triggers
Running the self-improvement loop continuously increases noise; disabling it allows regressions to accumulate. Firing only on four explicit triggers is the practical approach.
- daily — self-review-scan at 22:05 each day
- failure-pattern — same error repeated 3 times
- user-feedback — user signals a correction ("don't do that")
- external-update — dependency library or model update detected
Separate initiators per trigger
Each trigger is intentionally owned by a different initiator:
| Trigger | Initiator |
|---|---|
| daily | cron |
| failure-pattern | error handler |
| user-feedback | conversation analyzer |
| external-update | daily-audit Phase A |
If one path fails, the remaining three remain operational. Meta-loops like self-improvement are inherently failure amplifiers; placing them behind a single entry point degrades operational safety.
Technique 3 — Seven Rules for Sub-agent Delegation
The dominant cost of sub-agent delegation is not tokens — it is context isolation failure. The following seven rules structurally prevent that failure.
- NEVER pass session history. Extract and pass only the required context.
- 1 sub-agent = 1 task — single responsibility.
- Start read-only when read-only is sufficient — minimize authority.
- Write authority requires Tier gate clearance (see Part 7).
- Receive results only; discard internal process.
- Sub-agent results are passed to Manager as summaries, not raw output.
- Three consecutive failures → immediate user escalation.
Without these rules, sub-agent internal context backflows into Manager, inflating attached context size multiplicatively on subsequent calls and driving token cost to runaway levels. Rule 6 is the most common failure point: passing raw results up the chain causes cumulative context to grow exponentially as chain depth increases.
Mapping to Hermes
The same design maps to Hermes as follows:
- executor / decider split → two Hermes profiles (
worker-exec,worker-decide) - Self-Improve 4 triggers → daily=cron, failure=hook, user-feedback=memory record, external-update=daily-audit cron
- Sub-agent delegation 7 rules → serialized as the authority matrix in profile definitions
The key point of this mapping: concepts must be lowered into runtime-enforceable forms (profiles, hooks, authority matrices). Rules that exist only in documentation erode over extended operation.
Applicability and Open Questions
These three techniques are directly portable to:
- Loop-based agent orchestrators (Manager/Worker, Planner/Executor, or any equivalent structure)
- Systems with self-improvement or periodic retrospective loops
- Architectures with sub-agent or tool-call chains two or more levels deep
Open questions:
- How small can the "upper-task intent summary" injected into decider be compressed? Where is the break-even point at which compression cost consumes the executor/decider split benefit?
- Should memory saturation or rule conflict be added as independent Self-Improve triggers beyond the current four?
- If sub-agent result summaries (Rule 6) are forced into a deterministic format, where does the balance between summary quality degradation and context accumulation suppression land?
In summary: the starting point for division of labor is not role hierarchy — it is the direction of data flow. When hierarchy misaligns with flow, token cost, latency, and debugging cost all rise together. When structure is realigned to match flow, all three fall together.
Series overview: Series index
๋๊ธ
๋๊ธ ์ฐ๊ธฐ