Exploring Bounded Semantic Decisions in WTK Agents and Teams

We are exploring whether small, well-defined model judgments could help WTK build and operate agents and agent teams. Our work with Jev started with reviewing answers, but the question is broader: where could a narrow decision help an agent focus its effort?

By a semantic decision, we mean a judgment about meaning or relevance, such as which document addresses a question. By bounded, we mean that the available choices and the consequences of selecting them are defined outside the model. This limits the decision's scope; it does not guarantee a correct answer.

A reviewer is the starting point

Our current development work includes a bounded-choice adapter and an optional shadow reviewer. A shadow reviewer assesses evidence alongside the existing reviewer without replacing its effective verdict. That gives us a way to inspect agreement, disagreement and uncertainty before considering a larger role.

This is development work, not a claim that Jev improves WTK's accuracy or total cost. We are not presenting the early comparisons as qualification evidence or a production-readiness result. The broader uses below are directions we intend to examine, not capabilities already demonstrated.

Jev is one model we are exploring. The architectural question is whether a bounded decision role belongs in a particular workflow, and what evidence would justify it. WTK should not require that one model to remain useful.

Where we want to explore next

The Jev demo gallery is one source of inspiration for this broader exploration. We reviewed relevant gallery descriptions, not every implementation. They suggest possibilities to examine in WTK; they do not establish performance, safety or savings in our environment.

Inside the factory, a research agent could use a narrow relevance judgment to prioritize documents for a full read. A build agent could use one to narrow the tool definitions it considers. In both cases, an excluded source or tool needs a recovery path. A relevance judgment cannot establish that a source is credible or that the required tool was included.

Inside a deployed agent, context selection is another possibility. Consider a support agent receiving a long diagnostic result. A selector could recommend which sections to inspect first while preserving the original output and references to omitted sections. Losing an error, constraint or contradictory observation could make the apparent saving harmful.

Across a team, a coordinator could ask which already eligible role is best suited to a request. For example, a researcher might recommend handing a claim to a reviewer rather than collecting more material. The team contract would still define responsibilities, handoff conditions and who may act. The recommendation would not create a new role or grant access.

These are different decisions. A component that helps review a claim has not thereby shown that it can screen sources, choose tools or route team work.

How this fits the catalog and compiler

WTK's catalog describes agent and team packages; it is not a catalog of interchangeable model names. The package remains the source definition, while model bindings and target compilation determine how its behavior can be supported in a particular environment.

If one of these decision roles proves useful, we would want its intended purpose, permitted outputs, fallback behavior and evaluated conditions represented explicitly. The target runtime would need to support the chosen setup and enforce its restrictions. A tool-selection shortlist would not establish that an entire agent or team is suitable for deployment.

Our note on evaluating runtime configurations explains why evidence belongs to a specific setup. Changing the model, available choices or execution environment may change the outcome.

Recommendation is not authorization

The separation we want is straightforward: code establishes eligible choices, a model recommends among them, and code validates the recommendation and checks authority before any resulting action.

For a document-ranking step, that may mean selecting what to read next. For a browser action or team handoff, it may require checking the destination, data access and current permissions. Those consequences should not be hidden behind the same generic “decision” label.

This follows our discussion of automated reviewer authority. A recommendation cannot expand the rules governing the workflow.

What would make this worthwhile?

We want to judge the complete workflow, not the price of an individual call. Fewer tokens would not be an improvement if they caused missed evidence, repeated attempts or worse completed work. Simple rules may be sufficient for some decisions.

The open questions are where semantic judgment adds value, when it should abstain, and whether recovery from a wrong selection is reliable. Our research method requires evidence before turning those expectations into findings.

This Field Note records our direction, not an experiment protocol or authorization to run one. We will choose particular uses for separate review rather than add a decision model to every agent by default.