No Tools Has to Survive the Factory

A user can ask for an agent that needs no tools and still end up with a plan that requests them. Our fresh WTK trials exposed that mismatch while building a team to turn supplied release text into structured notes.

The failure happened during capability selection. It was not evidence that the team actually read files or accessed an external service.

The requested work

The team had three roles: extract bug fixes, extract features, and combine the results. Its input was the text already supplied by the user. The request explicitly excluded tools, files, web research, and external integrations.

Fallback planning nevertheless selected filesystem and release-fetch capabilities. Research then stopped on unavailable write capability and missing file receipts. The factory had introduced dependencies that the task did not need.

This is different from an agent refusing a legitimate task because a genuinely required tool is missing. Here the question was whether the tool requirement belonged in the plan at all.

The correction

The integration changes removed a generic location word as evidence that filesystem access was needed. They also distinguished transforming supplied release text from fetching a current release.

A narrow correction is important. Removing release or filesystem detection altogether would make this example pass while breaking tasks that genuinely need those capabilities.

An inspectable regression boundary

The regression rerun on September 5 includes both the reported task shape and positive controls:

The single test containing all three cases passed using the development checkout's capability registry. No agent team or external tool was executed. The editorial packet retains the command, transcript, and selected source/registry hashes, checked before and after the run. These results establish tested selection behavior, not runtime permission enforcement or a measured security improvement.

The checkout contains uncommitted integration work, and the full fresh-team journey was still incomplete in the reviewed trial record. A changed registry, capability matcher, or goal representation requires retesting; the result cannot be generalized to all paraphrases.

Why this matters beyond one phrase

When a Required Tool Is Missing, Stop Guessing addresses missing evidence capabilities. This case comes one step earlier: establish that the capability is actually required.

A File Tool Has to Stop at the Boundary addresses where an authorized tool may reach. Avoiding an unnecessary capability declaration does not replace runtime enforcement when a tool is legitimately present.

The general research question is whether a factory preserves negative constraints while translating a user's request through planning, research, package generation, and repair. Passing one capability-selection fixture cannot answer that for all language or all stages.

A stronger follow-up would vary supplied versus live inputs, paraphrase the prohibitions, and retain positive controls for tasks that truly require access. It should distinguish a proposed capability, a granted permission, and an actual action. Those are different outcomes.

For now, this is a bounded engineering observation with a concrete regression target. Under our research method, a broader security or instruction-following claim needs its own complete evidence.