Adding Recovery Guidance to Blocked Agent Releases

An agent builder should not have to translate a catalog rejection into a repair plan from memory. WTK now attaches recovery guidance to selected release blockers, naming who should act, what must happen first and what evidence would clear the blocker.

Current state

WTK builds agents and teams from packages, the durable definitions that can be compiled for different execution environments. A deployable catalog release requires evidence for the particular package and environment. Saving a catalog version for distribution is a separate action and does not claim that the agent has achieved its goal.

The release assessment already reported why a candidate was blocked. It did not provide a shared, structured recovery description for the command line and Uplink, WTK's user interface. Our earlier work kept review diagnoses intact in repair guidance. This cycle addresses the next operation an operator might choose from a catalog assessment.

Changes

The merged change adds advisory guidance for selected source, runtime-evidence and approval blockers. Supported recommendations name an existing operation, its prerequisites, the responsible actor and the evidence needed for reassessment. Unrecognized findings remain requests for investigation. If an older finding names its runtime only in message text, the guidance leaves it for inspection instead of guessing.

Consider a hypothetical insurance-claim intake agent assigned to collect required documents and route a complete claim to an assessor. It may not approve coverage. Before release, its catalog assessment reports that passing evidence from the selected execution environment is missing.

The guidance asks the operator to inspect earlier attempts, confirm the package and environment, and prepare an authorized test against the required outcome. That test would need to check the completed claim and its routing, not just whether a tool call finished. A suggested test operation also needs to support that agent's execution environment.

If only release approval remains missing, the recommendation belongs to the operator. Generating the recommendation neither records approval nor runs the test. The existing checks still decide whether the evidence is sufficient.

Failures observed

Separate coding review caught a problem in the first recommendation mapping: it could suggest a runtime-proof operation for an environment or team form that the operation did not support.

We corrected that mapping by making guidance use the same support check as the operation itself. Without an explicit supported path, the finding remains an investigation. This was a reproduced recommendation error, not an observed unauthorized execution.

Assumptions removed

A recognized blocker does not guarantee that its apparent repair is available in every environment. Recovery guidance needs to preserve that limit rather than sending the operator toward a command that will reject the request.

It also needs the exact source and executable identity. A useful instruction for one package revision cannot grant authority to act on a later revision or different runtime configuration.

Evidence

A retained before-and-after assessment of one diagnostic package kept the same package identity, blocked verdict and findings. The change added guidance; it did not clear the release checks. Focused regressions, a separate coding review and the offline repository suite passed against the merged revision.

That evidence supports the implemented advisory mapping and its bounded checks. It does not establish that a person can complete recovery through the live interface, that every blocker has an action, or that the intended single-agent and team deployments have succeeded. WTK's research method keeps engineering validation separate from those outcomes.

Next hypothesis

The next acceptance question is whether an operator can follow a supported recommendation through authorized action and fresh reassessment, while missing runtime evidence remains blocked. That journey still needs to be demonstrated. This cycle did not measure recovery time, cost savings or operator effort, and it does not specify a new experiment.