# Context Budget Orchestration

> Use when work is multi-step, context-heavy, research-heavy, or delegated. Contains bulky context, phases work, bounds retries, delegates independent reasoning, and reserves capacity for verification.

- **Type:** Skill
- **Install:** `agentstack add skill-saikaaco-saika-hermes-skills-context-budget-orchestration`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [SaikaAco](https://agentstack.voostack.com/s/saikaaco)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [SaikaAco](https://github.com/SaikaAco)
- **Source:** https://github.com/SaikaAco/saika-hermes-skills/tree/main/skills/context-budget-orchestration

## Install

```sh
agentstack add skill-saikaaco-saika-hermes-skills-context-budget-orchestration
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Context Budget Orchestration

## Overview

Keep the parent Hermes session effective when a task can expand through tool output, long files, research trails, implementation loops, or multi-agent reasoning.

The method has three layers:

1. **Contain:** keep bulky deterministic material out of the parent context.
2. **Orchestrate:** delegate bounded, independent reasoning with explicit contracts.
3. **Reserve:** stop expanding early enough to verify artifacts and deliver a grounded result.

This skill defines methodology, not permission. It does not authorize paid providers, external side effects, persistent changes, or broader delegation than the user and runtime permit.

## When to use

Use when one or more conditions hold:

- the task has three or more meaningful phases;
- many files, long logs, PDFs, webpages, or past sessions may be involved;
- research, implementation, review, and verification must be coordinated;
- independent subproblems can run in parallel;
- raw tool output would crowd out synthesis;
- the work may continue across sessions;
- the user explicitly requests delegation or subagents.

Use lightly or skip for a quick lookup, a small local edit, one short file, or a deterministic operation whose orchestration overhead exceeds the work. Respect an explicit request not to delegate.

## Context-budget preflight

Before heavy work, state a compact budget:

```markdown
## Context budget
- Task size: small | medium | large | huge
- Parent role: execute | orchestrate | synthesize | verify
- Bulk-output strategy: direct tools | deterministic reduction | subagent summaries | external ledger
- Delegation: none | one bounded child | parallel children | map-reduce
- Verification reserve: what must remain possible before finalization
```

### Size heuristic

| Size | Typical shape | Default response |
|---|---|---|
| Small | no more than two sources/files and a few calls | direct work |
| Medium | several files/sources or commands | batch reads; consider one bounded child |
| Large | broad research, test/build loops, many files | delegate independent reasoning early |
| Huge | repository-wide, multi-phase, or multi-session | external ledger plus map-reduce |

Task shape matters more than raw file count. One enormous log may need containment more than ten tiny files.

## Proportional phase gates

Treat the available interaction/call budget as a phase budget, not a target to consume.

| Budget point | Phase | Required behavior |
|---:|---|---|
| first 10% | Scope and route | Lock endpoint, success criteria, source/tool matrix, delegation choice, and stop conditions. |
| 10–60% | Collect or implement | Batch independent calls, dispatch required children early, and write artifacts incrementally. |
| 60–67% | Close collection | Finish required collection only; start no optional source, feature, or diagnostic branch. |
| 67–75% | Freeze and reconcile | Join required results, resolve contradictions, persist compact state, and stop creating work. |
| final 25% | Verify and deliver | Run acceptance checks, bounded repair, and final synthesis. |

If the runtime exposes no explicit budget, estimate from task size and expected output. Preserve enough capacity to rerun failed checks and report honestly.

### Phase contracts

- One phase should have one dominant contract: discovery, test design, implementation, rollout, visual QA, or final verification.
- If the request materially expands, finish the current phase and record state before absorbing adjacent work.
- Dispatch required children during planning or early collection, never as a last-minute substitute for verification.
- Do not synthesize a conclusion that depends on a child until its result arrives and the parent verifies its evidence handles.
- If required work cannot fit inside the reserve, stop optional branches and continue in a fresh phase rather than claiming completion.

## Choose the cheapest correct surface

| Work type | Preferred surface |
|---|---|
| one lookup, edit, command, or API call | direct tool |
| deterministic filtering, counting, parsing, or aggregation | programmatic reduction |
| independent evidence collection or judgment-heavy analysis | bounded subagent |
| durable waiting, retries, or scheduled work | background process, scheduler, or task system |
| user decision with material trade-offs | concise decision brief and clarification |

Do not spawn agents merely to move mechanical output elsewhere. Do not read large raw outputs into the parent when line-limited reads, search, or reduction can answer the question.

## Delegation decision rules

Delegate when a subtask is independent, bulky, or benefits from fresh context. Keep it in the parent when tight coordination, user interaction, or a small local change makes delegation slower or less reliable.

Good targets:

- codebase reconnaissance with file/line handles;
- parallel evidence collection across distinct source classes;
- independent design alternatives under identical constraints;
- diff or plan review after an artifact exists;
- isolated failure triage;
- long-document synthesis;
- adversarial verification of a material claim.

Poor targets:

- one command or simple lookup;
- tiny edits;
- tasks requiring user clarification;
- durable work that must survive the current session;
- external side effects the parent cannot independently verify.

### Reasoning effort

Use the lowest effort that can reliably satisfy the contract. Escalate after failed verification, material uncertainty, conflicting evidence, missed constraints, or substantial repair—not merely because a higher tier exists. Respect runtime floors, ceilings, and provider policy.

Mechanical work belongs in tools, not a low-effort reasoning child. High effort is never a substitute for a clear endpoint, lean context, or verification.

## Standard subagent contract

Every delegated task should include:

- **Goal:** exact deliverable.
- **Context:** only necessary facts, paths, constraints, and acceptance criteria.
- **Boundaries:** what not to modify, assume, or contact.
- **Output schema:** concise result with verifiable handles.
- **Budget:** no raw logs or transcript unless essential.

Recommended response:

```markdown
## Result

## Evidence / handles
- 

## Key details
- 

## Risks / uncertainty
- 

## Suggested next step
- 
```

For implementations and reviews, require files touched or inspected, tests run or recommended, exact blockers, and no success claim without a handle the parent can verify.

## Parent verification gate

A subagent summary is a lead, not proof. Before reporting completion, the parent must verify material claims and external side effects against the original surface:

- read back changed files;
- inspect diffs;
- run tests/builds/validators;
- fetch published URLs;
- compare identifiers or bytes where appropriate;
- distinguish “reported by child” from “verified by parent.”

The parent owns the final synthesis and decision.

## Circuit breakers

- Retry the same failed GUI, API, browser, or command surface at most once unless the second attempt uses new evidence and a materially different hypothesis.
- After that, switch surface: DOM/accessibility/direct file/API before more coordinate clicking; deterministic probes before visual guesses; exported data before private-history pagination.
- For bounded background processes, use completion notification rather than repeated polling when available.
- Batch screenshots, viewport checks, and console inspection into one verification pass per implemented state.
- Stop broad collection when outputs repeat, contradict without new evidence, or no longer change the decision.

## Fan-out / fan-in patterns

### Scout → implement → verify

1. Parent locks endpoint and acceptance criteria.
2. Scout finds relevant files, APIs, tests, and pitfalls.
3. Parent or bounded implementer makes the smallest correct change.
4. Independent reviewer checks the artifact.
5. Parent runs real verification and reports grounded results.

### Map-reduce research

1. Parent defines question, source hierarchy, and freshness rule.
2. Children collect evidence from separate source classes or subtopics.
3. Parent deduplicates, checks contradictions, and labels confidence.
4. Parent writes the synthesis and preserves durable evidence when required.

### Candidate alternatives

Give independent children identical constraints. Compare options by correctness, simplicity, risk, testability, and operational cost. Prefer the smallest design that satisfies the endpoint.

### Independent verifier

Provide only the claim, artifact handles, and success criteria. Ask the verifier to find missing evidence, tests, or constraints. The parent checks every decisive handle.

## External state ledger

For huge or multi-session work, keep a compact factual ledger under the active workspace, for example:

```text
.hermes/state/.md
```

Suggested shape:

```markdown
# 

## Endpoint

## Current state
- 

## Decisions
- 

## Artifacts / evidence
- 

## Verification
- 

## Open blockers
- 

## Next action
- 
```

Keep the ledger short. It is recovery state, not a transcript or log dump.

## Context-pressure recovery

When the parent starts repeating calls, losing constraints, or depending on memory of a long transcript:

1. stop broad reading and optional branches;
2. finish or safely pause the current phase;
3. update the state ledger;
4. delegate only isolated missing facts;
5. resume from the ledger in a fresh phase or allow compression as a backstop;
6. never turn a fallback summary into an unverified completion claim.

## Common pitfalls

1. **Over-delegation:** children add latency and noise to tiny tasks.
2. **Under-delegation:** broad raw reading destroys parent context quality.
3. **Late delegation:** required results arrive after the verification window.
4. **Raw-summary bloat:** bounded tasks still need concise output contracts.
5. **Unverified side effects:** child reports do not prove publication or mutation.
6. **Transcript as database:** durable projects need external recovery state.
7. **Maximal effort everywhere:** expensive reasoning does not repair unclear scope.
8. **Retry loops:** repeated use of a failed surface without new evidence is not progress.
9. **Optional-branch creep:** collection expands until no verification reserve remains.
10. **Permission drift:** methodology does not grant provider, payment, or external-action authority.

## Verification checklist

- [ ] Endpoint, success criteria, stop conditions, and reserve were stated before heavy work.
- [ ] Deterministic bulk output was reduced to decision-relevant summaries before parent synthesis.
- [ ] Required independent reasoning was delegated early with bounded contracts.
- [ ] User and runtime delegation/provider limits were respected.
- [ ] Same-surface retries were capped and switched after failure.
- [ ] Required child results arrived before synthesis.
- [ ] Material claims and side effects were verified by the parent.
- [ ] New branches froze before the final verification phase.
- [ ] Huge or multi-session work has a compact state ledger.
- [ ] Final claims cite tool output, files, URLs, tests, or user-provided evidence.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [SaikaAco](https://github.com/SaikaAco)
- **Source:** [SaikaAco/saika-hermes-skills](https://github.com/SaikaAco/saika-hermes-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-saikaaco-saika-hermes-skills-context-budget-orchestration
- Seller: https://agentstack.voostack.com/s/saikaaco
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.