The Plugin Is Part of the Factory

A new class of agent harness is moving beyond the coding window. It can organize files, work with documents and data, build software, run research, and keep background tasks moving. The same system can appear as a desktop application or a web interface. That matters because the agent is no longer visiting one tool to produce one answer. It is operating across the ordinary surfaces where work begins and ends.

The practical shift is from assistant to environment. A chat box waits for a person to carry the result somewhere else. A harness can hold the workspace, call the tool, show the artifact, keep the task alive, and expose the execution trace when something goes wrong. Each removed handoff gives the agent more useful reach. It also gives the harness more responsibility for what the work becomes.

Our position is that this is where the assistant market is headed. The durable product will not be the window that talks to a model. It will be the operating layer that connects models to work, governs their actions, and preserves enough state for the next run. Once the harness owns that loop, the interface is only one entrance to the factory.

A composable plugin system makes that operating layer expand quickly. A plugin can add a tool, a skill, a scheduled job, a different interface, or coordination between agents. It can even be created through the same conversational surface the agent uses for ordinary work. That makes extension feel lightweight. The consequence is not lightweight at all.

Every plugin changes at least one boundary. It may introduce a new dependency, expose a file, open a network path, add a recurring trigger, or let the agent change what a person sees. A timer floating over the interface sounds harmless. A scheduled task that reads project notes and writes a weekly report has access, timing, output, and failure behavior to define. The mechanism is the same even when the stakes are different.

Treat plugins as factory components, not downloadable tricks. Name what each one may read, what it may change, how it starts, where its output lands, and what evidence proves it worked. Decide how it is disabled and what happens to unfinished work when it disappears. If the answers live only in the plugin author's assumptions, the factory has accepted an invisible operating contract.

Letting an agent create its own extensions is powerful because a missing capability can become machinery instead of another manual workaround. The agent can inspect the runtime, write the package, install it, and verify that the new behavior is live. That is a real compression of software delivery. It turns a request into an operating feature without forcing a person through every implementation step.

But a successful installation is not proof that the extension belongs in the system. The builder can still misunderstand the request, choose a dangerous permission, or verify only the happy path it just created. Generated plugins need the same release path as any other production change: a specification, narrow authority, deterministic checks, independent evidence, and a rollback that works after the demonstration is over.

The agent should be able to propose and build the capability. It should not inherit the authority to decide every consequence of installing it. People still choose which data may move, which recurring actions are acceptable, and what failures deserve a stop. The harness should turn those decisions into gates the builder cannot edit on its way through.

As the harness takes on broader work, the transcript stops being enough. You need to see the turns, tool calls, inputs, outputs, timing, and hierarchy behind a result. A polished final message can hide an unnecessary command, a missing read, or a tool call that succeeded under the wrong conditions. Execution traces make the path inspectable instead of asking you to trust the summary.

Inspection is only the first use. The factory should turn trace evidence into future behavior. A failed tool call can sharpen a precondition. An unnecessary permission can disappear from the route. A repeated sequence can become a tested plugin. A plugin that creates more review work than it removes can be demoted or deleted. Without that write-back loop, tracing becomes a nicer way to watch the same mistakes recur.

This is the real promise of an open, extensible harness: not an endless shelf of capabilities, but a system that can absorb useful work into governed machinery. Models will change. Interfaces will multiply. Plugins will appear faster than any team can review by instinct. The organizations that win will make extension routine without making authority casual. The plugin expands what the factory can do. The contract decides whether it should.