Minimalism Needs an Extension Boundary

Agent tooling changes fast. A new model needs a new adapter. A useful protocol appears. Teams want longer-running work, a different interface, or a specialized routing rule. Every request can be reasonable on its own. Put all of them in the main harness and the supposedly minimal tool becomes the place where every experiment demands permanent support.

Saying no helps, but refusal is not an architecture. If the core is the only place where capability can live, users will either keep pushing features into it or fork the whole system. One path produces a swollen center. The other produces incompatible copies that stop receiving the fixes and controls the original was meant to preserve.

The durable answer is an extension boundary. Keep the execution loop, tool contract, state transitions, and essential controls narrow. Give everything more experimental a defined way to attach without rewriting those foundations. Minimalism then becomes a property the system can defend, not a preference somebody has to win again in every issue thread.

An extension system is only useful when both sides know what they owe each other. The harness should define what an extension may observe, which actions it may request, how it stores state, how failures surface, and which decisions remain outside its authority. Without that contract, extensibility is just shared memory with better branding.

This matters more when agents can modify their own working environment. A worker that can load tools, change prompts, switch models, or install new behavior mid-run has gained leverage. It has also gained more ways to route around the assumptions that made the original task safe. Every extension point is therefore an authority boundary. Treating it as convenience code is how a flexible harness becomes an unreviewed control plane.

Make the seam visible. Version the interface. Validate configuration before execution. Give extensions narrow capabilities instead of the harness's entire account. Record which extension changed the route and what evidence the result produced. Flexibility is valuable when the factory can still explain what ran. If it cannot, flexibility has become ambiguity with write access.

A dependable core should move more slowly than the experiments around it. That is not timidity. The core sits underneath every route, so a small change there has a wide consequence. An extension can fail inside one bounded job. A core regression can change how every job interprets tools, state, or completion.

Run the edges quickly. Try new models, interaction surfaces, context strategies, and routing logic where they can be replaced without moving the floor. Promote a capability only after repeated use shows that it belongs in the common contract. The question is not whether the feature looked useful in one session. It is whether the whole factory is better off owning that behavior on every future upgrade.

That promotion needs evidence. Track which routes depend on the extension, what failures it creates, how often operators override it, and whether another implementation can satisfy the same contract. A feature earns its way inward by becoming boring, predictable infrastructure. Until then, it should stay at the edge where discovery is cheap and removal is possible.

A hardened harness is a strong build input. It is not a complete operating system for software delivery. It can run an agent, expose tools, preserve a conversation, and support extensions while still knowing nothing about which work matters, what evidence permits release, or which production consequence should stop the line.

Those decisions belong in the factory. The specification sets the destination. Permissions bound the action. Independent checks decide whether the result holds. Release controls connect evidence to consequence. Production observation sends reality back into the next plan. The harness carries the worker through that route, but it should not quietly invent the route itself.

Our position is simple: choose a harness whose core can remain stable while your factory keeps learning. Push local experiments behind explicit interfaces. Turn proven behavior into governed machinery only when the evidence justifies the larger contract. Models and tools will keep changing. The organizations that win will be able to absorb that change without rebuilding the floor every worker stands on.