Self-Hosted Execution Is Not Operational Control

A self-hosted agent runner changes where commands execute. Source code can stay on machines you control. Secrets can remain behind your network boundary. Tool calls can pass through your logging, identity, and access systems. For organizations that cannot send their working environment into somebody else's cloud, that is meaningful progress.

But an agent is more than the tools it calls. Something still interprets the task, decides the next action, chooses which context matters, and determines when the work is done. If that loop remains with an outside provider, the provider is still part of the operating path. Your machines hold the tools. Their service still holds the steering wheel.

That is the distinction leaders need to keep clean. Execution locality answers where work touches your systems. Operational control answers who can stop the work, change its behavior, inspect the decision path, and help you leave. Those are different questions, and a private network does not collapse them into one.

Start with what local execution genuinely buys. You can narrow which repositories an agent sees, issue short-lived credentials, block unsafe commands, capture tool activity, and keep sensitive artifacts inside infrastructure you already govern. Those controls are stronger when they sit between the agent and the thing it wants to change.

Now draw the rest of the system. Where does the prompt go? Who retains the context? Which service schedules the run? What happens when the provider changes a model, policy, account status, or supported integration? Can your team reproduce why the agent selected one action over another? If the answer lives outside your boundary, then so does part of the factory.

This does not make the design useless. It makes the architecture honest. A split system can be the right system. The mistake is calling one half self-hosted and letting that phrase imply ownership of the whole operation. Governance starts when the diagram names every party that can affect the result.

When agents perform repeatable delivery work, vendor terms stop being paperwork around the machinery. They become conditions under which the machinery runs. Audit access, data location, subcontractors, retention, support, suspension, and termination can all change whether a factory is operable even when every command executes on your own server.

Treat those conditions like production dependencies. Keep an inventory that connects each provider to the factory stages it supports, the information it receives, and the authority it can exercise. Record the consequence of losing it. If planning stops, say planning stops. If an audit trail becomes incomplete, say which decisions can no longer be proved.

The uncomfortable test is simple: can the provider's commercial or policy decision create an engineering emergency inside your company? If it can, you have an operating dependency. Local execution may reduce the blast radius, but it does not remove the dependency from the route.

A document that says you can switch providers is not an exit plan. The replacement has to accept the same bounded task, receive the authority it needs, return evidence in a shape your gates understand, and survive the same acceptance conditions. Until that route runs, portability is an opinion.

Put the stable contract above the agent service. Define the work packet, tool permissions, evidence requirements, stop conditions, and human approval points independently of any one provider's interface. Then isolate provider-specific prompts and capabilities behind adapters. You should be able to change the planner without changing what counts as proof.

Run that alternate path on ordinary work before a crisis chooses the timing. You will find assumptions hiding in context formats, identity flows, tool schemas, model behavior, and billing limits. That discovery is the value of the rehearsal. A failed exercise gives you a repair queue. An untested diagram gives you confidence with no evidence behind it.

Our position is that agent execution will keep moving closer to the systems it changes. That is necessary for serious adoption, especially where code, credentials, and regulated data cannot wander. It is not sufficient for control.

The factory is the full route from intent to observed result. It includes the planner, the execution environment, the permissions, the evidence, the acceptance gates, and the feedback that changes the next run. Owning one machine in that route does not mean you own the route. Owning the boundary means every outside dependency is named, constrained, monitored, and replaceable under tested conditions.

Bring the agent's hands inside your infrastructure when that protects the work. Then keep going. Govern the brain that directs them. Make the proof independent of both. Rehearse the exit while everyone is still friendly. Self-hosted execution is a useful control, but the software factory only becomes yours when somebody else's decision cannot strand it.