Bounded autonomy beats bigger prompts

There is a tempting story in AI-assisted software work: give the agent a bigger context window, a smarter model, and a longer system prompt, and engineering quality will follow.

That story is incomplete.

In practice, the expensive failures look different. The worker edits the wrong files. It invents identifiers that “sound right.” It refactors adjacent code because cleanup felt productive. It reports success because a file was written. The owner discovers later that the acceptance test was never run, the dirty tree was disturbed, or the public contract quietly changed.

The bottleneck is not only model IQ. It is task shape, ownership, and evidence.

This post describes an idea we have been pressure-testing under the working name Luna framework: not a generic agent harness, and not a claim that one model tier always wins, but a supporting discipline for routing engineering work to the least expensive model that can finish a slice safely — then proving that it did.

The design thesis

The original spark was a practical model-fit split, not a desire to invent another chatbot wrapper:

Luna-class routes for narrow, file-scoped changes with a fast test-and-feedback loop.
Terra-class routes for larger codebases, cross-module dependencies, architecture, and harder refactors.
Break-glass routes for stagnation, system resets, or deep architectural diagnosis — used sparingly, on evidence.

That is a cost-per-diff and context-management strategy. Spend deep reasoning where blast radius and ambiguity justify it. Do not burn a frontier model on a one-file normalization that a smaller worker can complete under a tight packet.

But model choice alone is not a framework. Without structure, “use the cheap model” just means “fail faster with less context.”

What has to exist around the model

A usable routing workflow needs durable artifacts that survive a single chat session:

A system spine — major subsystems, boundaries, data flow, ownership.
A glossary — domain terms, identifiers, events, contracts, known hazards.
Component briefs / task packets — one objective, owned paths, acceptance criteria, required reading, verification commands.
Source-anchored links — architecture concepts tied to files, symbols, tests, and decisions.
A routing policy — Luna / Terra / break-glass chosen from scope and failure evidence, not vibes.
Feedback loops — real tests, typechecks, structural checks, and owner review.

The point is to turn a vague objective into slices a smaller worker can safely understand and edit, while the whole system stays coherent.

This sits next to — and should interoperate with — the emerging category of repository-intelligence tooling: indexing, symbol navigation, dependency graphs, impact preflight, semantic search, Git history, and source-anchored memory exposed over interfaces such as MCP. The framework should not depend on one indexer. It should remain useful with maintained docs and native repo tools when fancy integrations are offline.

The workflow in one line

intake → classify → map context → create bounded packet → route model → execute → verify → owner review → retain lesson

That loop is the product idea more than any particular CLI.

Bounded ownership

Every task gets an explicit owned path set. Adjacent cleanup is not authorization. Silent scope expansion is a failed run even if tests pass.

Source-first reasoning

Current code, tests, and contracts beat planning prose. Generated metadata is labeled generated. When documents conflict with executable behavior, the executable truth wins unless the task is explicitly changing the contract.

Minimal mutation

Preserve dirty trees. Do not reset, stash, clean, commit, merge, push, or delete unless the packet authorizes it. Unrelated screenshots, generated maps, and half-finished work are sacred until someone owns them.

Evidence before completion

A successful write is not a successful task. The changed behavior must be exercised with real commands and real exit codes. Missing checks are recorded as missing — not filled in with confident narrative.

Independent acceptance

Worker self-report is evidence, not the gate. An owner or adversarial pass inspects the diff and reruns the checks. For UI and live systems, automated green is not the same as interaction plus visible state readback.

Honest uncertainty

If the environment blocked a test, say so. Do not launder an infrastructure failure into “the model failed the task,” and do not launder a skipped check into “verified.”

What evaluations are actually for

Evaluations in this framing are not marketing demos. They are bounded trials of a worker under controls:

Did it read the required source of truth before editing?
Did it use real types and identifiers instead of plausible substitutes?
Did it stay inside owned paths?
Did it preserve unrelated work?
Did the acceptance criteria get proven by execution?
Can an owner reproduce the claim from commands and output?
Was anything durable learned without storing secrets or raw noise?

A mature record distinguishes three layers:

Layer	Meaning
Worker evidence	What the agent said it did
Execution evidence	What tools actually returned
Owner acceptance	Independent review against the packet

If those three disagree, the honest status is incomplete — not “basically done.”

Early signals (and the claims we refuse)

We ran this discipline in two modes.

Exploratory pilot on a mature multi-package game/server codebase (diplomacy and turn-resolution boundary). Tight packets, explicit routes, independent verification. Useful for protocol design. Not a matched model comparison: tasks were not equivalent across arms, so no superiority claim is justified.

Controlled TypeScript fixtures with committed failing/incomplete baselines, isolated worktrees, identical packets, explicit route capture, and parent-side verification. Across small boundary tasks (single-file behavior, revoked-access propagation, expiry-time presentation), both routed arms could complete correctly with bounded diffs when the harness was stable.

What that supports:

Task packets, spines, glossaries, baseline tags, isolated worktrees, and independent verification are a correctness and scope-control mechanism.
Matched routing experiments are buildable if you treat launcher and sandbox behavior as part of the science.

What that does not support yet:

“Luna beats Terra” (or the reverse) on quality, speed, or cost.
Leaderboard rankings from small n, order-entangled runs, or revised scoring rules.
Treating timing/cost as trustworthy before dispatch harness and child-process environments are stabilized and sampled properly.

Later confirmation-style tracks on a harder architecture-audit ladder reinforced the same meta-lesson: you can freeze protocols, blind graders, hash manifests, and still owe the reader an honest label — exploratory confirmation is not independent confirmatory science, and artifact-completeness gaps are not the same thing as general model rankings.

If a blog post needs one sentence of epistemic hygiene, use this one:

We are measuring whether a workflow produces inspectable engineering outcomes — not crowning a permanent winner among model SKUs.

Why this is a different product category than “better prompts”

Prompt libraries optimize the monologue.

This framework optimizes the factory floor:

Prompt-only habit	Framework habit
“Here’s the whole repo, be careful.”	Task-scoped context + owned paths
“Use best judgment.”	Glossary and contracts as constraints
“Done when it looks right.”	Done when independent checks pass
One mega-agent forever	Route up only on failure evidence
Chat log as memory	Selective durable lessons tied to source

The long-term goal is not maximum autonomy without oversight. It is bounded autonomy with strong repository awareness, minimal mutation, reproducible evidence, and a steadily improving body of engineering knowledge.

What a mature version could look like

Still speculative, but concrete enough to build toward:

Schema-validated task briefs and acceptance criteria.
Repository reconnaissance adapters (native tools first; optional indexers later).
Blast-radius preflight before multi-file work.
Owned-path and dirty-tree guards.
Command execution with captured exit codes and bounded output.
Verification ladders for test-only, backend, UI, and deployment slices.
Structured handoff reports.
Owner/adversarial review prompts and records.
Benchmarks for success, recovery, scope drift, and preservation.
Source-anchored project memory that refuses secrets and unverified claims.
Comparative measurement against grep-only and prompt-only baselines.

Success is boring and owner-shaped. After a run, without reconstructing the whole session, you should be able to answer:

What was asked?
What actually changed?
Why was that in scope?
Which contracts informed it?
Which commands exercised it?
What passed, failed, or stayed unverified?
What risks remain?
What reusable knowledge was kept?

Practical takeaways you can use this week

Even without a polished product, the operating rules transfer:

Write the packet before the agent runs. Objective, owned paths, forbidden paths, acceptance tests, required reading.
Prefer thin vertical slices over “fix the architecture while you’re in there.”
Route by blast radius, not by brand loyalty to a model name.
Rerun the checks yourself (or with an independent agent) before you merge the story.
Separate environment failures from implementation failures. A sandbox that blocks test runners is not a reasoning defect.
Keep memory selective. Procedures and contracts yes; credentials, raw dumps, and unsupported rankings no.
Label exploratory work exploratory. Your future self — and your readers — will thank you.

Closing

The industry conversation still over-weights “which model” and under-weights “what was the worker allowed to touch, and how do we know it finished?”

The Luna framework idea is a bet that decomposition, contracts, routing, and evidence compound better than ever-longer prompts. Early work supports the discipline as a way to keep small workers honest on bounded tasks. It does not yet justify myth-making about permanent model hierarchies.

If Happy Monkey’s agent stack is about useful autonomy in the real world, this is the engineering counterpart: autonomy that can show its work.