If we challenge the assumption that agent accessibility should always increase—more CLI tools, more MCP surfaces, more flows—and instead cap accessible surfaces based on a team’s current verification layer and apprenticeship capacity, how does that change which systems get exposed to agents at all, where we allow designer-owned harnesses, and which parts of the ambition frontier we consciously leave manual to protect the craft bar and avoid apprenticeship decay?

Answer

Capping agent accessibility by verification and apprenticeship capacity shifts exposure toward well-tested, well-owned systems; keeps fragile, high-craft areas manual; and forces designer-owned harnesses into narrow, high-leverage domains.

1. Which systems get exposed

• Prefer systems with:
  • strong verification layer (tests, observability, rollbacks)
  • clear ownership and on-call
  • token-efficient, stable interfaces (monolith façades, blessed CLIs)
• Keep agent access limited or read-only for:
  • core domain boundaries with weak tests
  • infra with expensive failures (billing, auth)
  • areas used for teaching core patterns

2. Where designer-owned harnesses are allowed

• Allow when:
  • surfaces are low-to-medium risk (read, reporting, coordination flows)
  • verification scripts are simple and auto-runnable
  • an engineer custodian signs off on tools and capability tiers
• Restrict when:
  • flows can cross many boundaries or mutate core data
  • the team can’t review harness changes without starving code review

3. Parts of the ambition frontier left manual

• Keep manual (human-implemented first):
  • new architectures and core patterns
  • schema and boundary changes
  • subtle performance, concurrency, and security work
  • apprenticeship lanes where juniors need to feel the constraints
• Let agents expand ambition mainly in:
  • reversible hunch probes and spikes
  • glue, migrations, and optimizations behind strong tests

4. Effects on craft and apprenticeship

• Craft bar: more stable because risky surfaces are gated and agent flows live mostly behind good verification.
• Apprenticeship: healthier if juniors own manual lanes in core areas and use agents mainly as helpers, not default executors.
• Tradeoff: slower expansion of agent-accessible footprint, but fewer hidden safety debts and less skill atrophy.

5. Practical policy sketch

• Classify each system: {verification strength, risk, teaching value}.
• Only expose agents to systems above a verification threshold, with caps on:
  • number of writable tools per system
  • number of new flows per quarter
• Reserve a fixed slice of work (e.g., core refactors, key features) as “manual-first” for learning and taste.
• Require joint designer–engineer review for any new harness that adds cross-boundary writes or changes verification logic.