A powerful primary developer spends scarce reasoning capacity and model context on deterministic operations or narrowly bounded work that software or a less expensive model could perform without taking over end-to-end project ownership.
A strict transmission boundary can preserve the primary developer's ownership while moving only admitted work into a cheaper execution gear and returning one compact, evidence-addressable result.
One gearbox_run operation:
- binds exact authority and immutable policy identity;
- validates the requested gear, task type, model, effort, context, output, and literal budgets;
- chooses deterministic execution when cognition is unnecessary;
- stages only content-addressed context for a cognitive helper;
- invokes at most one authorized execution transport;
- waits outside primary model turns;
- retains raw evidence outside the compact result;
- validates a typed terminal result and helper cleanup;
- performs no autonomous retry or fallback;
- emits visible, evidence-bounded telemetry.
The primary developer retains project understanding, architectural judgment, safety decisions, ambiguity resolution, integration responsibility, and the final determination of completion. Gearbox owns one bounded call, never the project objective.
The theory would be weakened or rejected if controlled evidence shows that:
- bounded delegation cannot preserve correctness under its declared scope;
- admission, context, or result contracts routinely require the full project context they are intended to avoid;
- deterministic gears produce more escalation or operator burden than direct execution;
- helper termination, authority, or evidence completeness cannot be verified;
- the primary developer must reconstruct substantial hidden work before safely continuing; or
- the mechanism's overhead dominates its measured value across the intended task classes.
The current prototype establishes feasibility only. It does not establish any correctness, token, latency, cost, or causal benefit.