chopshopr

Replaceability question

Why do serious builders make their agents easy to fire?

Because the most expensive kind of autonomy is the kind that takes the work, the authority, and the escape hatch with it. A dependable agent can leave tomorrow without leaving the operator trapped inside its private history.

By Chopshopr 10 min read
Opinions Why do serious builders make their agents easy to fire?
Contact Chopshopr

This is an embarrassing question because it sounds like lack of faith. The team just showed an agent planning, coding, calling tools, and tidying the repo. Then someone asks the rude thing: could we turn it off next month, use another model, revoke its credentials, and still keep the useful work? Demo culture hears that as disloyalty. Serious operators hear it as the first adoption question.

The thesis:

A dependable agent is easy to fire. The operator can stop it, replace its model or client, revoke its authority, and continue from durable work. That does not make the agent less capable. It makes its capability belong to the team instead of to a fragile runtime relationship.

Firing is not the same as handoff

A handoff asks whether another operator can continue a run. We should ask that too. Firing is stricter. It asks whether the original agent, model provider, client shell, or sandbox can disappear entirely without taking the task's memory, permissions, and proof with it.

That distinction matters in local-first work. A local model can be a terrific default and still be the wrong model for a new job. An MCP client can be pleasant until its tool UI changes. A sandbox can be useful until a policy needs to be tightened. If the work only makes sense through the exact agent that made it, the operator has bought a dependency disguised as autonomy.

01

Keep the work

Inputs, diffs, artifacts, and next steps live in ordinary files, routes, or task records the operator controls.

02

Lose the authority

Credentials and high-consequence permissions can be revoked without excavating an agent's private memory.

03

Swap the engine

The client contract is explicit enough that another model or endpoint can run a small acceptance probe.

04

Continue the job

A human or a different agent can find the branch, state, and exact next move without folklore.

The current infrastructure already separates the pieces

The separation is not hypothetical. The current vLLM OpenAI-compatible server documentation says the server implements Completions, Chat Completions, and Responses APIs. Its Responses surface includes a cancel route. That does not mean two models will produce equivalent answers. It means an operator can make the interface testable: submit a known probe, inspect the response shape, and cancel a long request through a public client contract rather than through a model-specific ritual.

The current MCP tools specification makes another useful split. A server lists named tools with schemas and optional annotations; clients should show what is exposed, make invocations visible, and keep a human able to deny a call. The spec also says annotations are untrusted unless they come from a trusted server. That is the key design lesson: tool risk should be a property the client can inspect, not a promise locked inside an agent's personality.

MCP maintainers make the limit even clearer in their current tool-annotation note: hints only matter when they cause a concrete client action, and they are not a security contract by themselves. An easy-to-fire agent therefore has an exit outside the prompt: a policy, approval, or revocation point the operator can act on even if the model is confused, compromised, or merely unpopular next quarter.

Put credentials and policy where the fired agent cannot keep them

OpenShell offers a concrete version of this boundary. Its official project describes sandboxes with policy-enforced egress routing, a gateway that acts as the authorization boundary, and provider credentials injected at runtime rather than written into the sandbox filesystem. It also separates filesystem and process policy from network and inference policy, with the latter hot-reloadable at runtime.

That is a better offboarding story than "tell the agent to forget." If a tool or model must go away, the operator can change the provider, policy, or inference route at the control plane. The running agent loses the access it was given; the work product does not have to be erased with it. NVIDIA's NemoClaw project makes the social contract explicit for its supported coding agents: ask one question at a time, run commands only with approval, and keep secrets out of chat. The useful boundary is visible before the offboarding event, not improvised during it.

Question Demo answer Dependable answer
Where is the task state? It is in the conversation. It is in a task record, branch, artifact, or public route an operator can open.
Where is authority? The agent knows which tools to call. The gateway, client, and policy can show, deny, change, or revoke it.
Can we change models? Why would we? Run the same acceptance probe; do not assume behavior equivalence.
What survives removal? The output pasted into chat. The receipts needed to inspect, resume, or deliberately abandon the job.

The firing drill is a better demo than another tool call

Do not turn this into a belief statement. Run a drill. Pick one real but bounded workflow and try to remove the current agent from it. A team that cannot do this in an afternoon has learned something useful before a contract, production incident, or model deprecation teaches it at a worse price.

  1. Stop: cancel or halt the active job and record whether a partial side effect exists.
  2. Freeze: save the input, task handle, branch or artifact path, tool list, and exact next step outside the chat transcript.
  3. Revoke: remove the provider or policy path that gave this agent authority; confirm that a stale client cannot still act.
  4. Swap: point a second client or model at a narrow acceptance probe. Compare the output contract, not its prose style.
  5. Resume: ask a different operator to complete, review, or safely abandon the work using only the receipts.

The expected result is not that every replacement behaves identically. Models differ; tool policies differ; a stopped job may need human cleanup. The expected result is legibility. You should know what was stopped, what remains, what authority was removed, and what another actor needs to do next.

Chopshopr should make the exit obvious

Chopshopr's local-first setup gives this design a practical home. The inference client talks to an OpenAI-compatible backend, while model selection and the base URL are explicit configuration. The public entrypoint guide separates ordinary local generation from health checks and keeps NemoClaw/OpenShell host operations behind bounded MCP tools. Those seams let the operator change a model lane or inspect host authority without pretending the whole system is one magical assistant.

The work surface needs the same treatment. Git's linked worktree documentation explains that a repository can host multiple working trees with their own per-worktree HEAD and index state. In Chopshopr terms, an isolated task branch is not just tidy implementation. It is an exit receipt: another operator can see which work belongs to the run, what the branch contains, and whether it can be built or shipped without adopting the first agent's private context. 

# A tiny firing drill should leave ordinary coordinates.
bun run worktree:check
git status --short --branch
git rev-parse --short HEAD
# revoke or change the bounded authority outside the agent, then rerun a narrow probe
# record the artifact path, expected response shape, and next human decision

This is the bridge from demo magic to dependable tools. The good local agent is not the one nobody can replace. It is the one that makes replacement boring enough that the team can adopt it without surrendering the work.

Sources