Selecting AI Agent Teams for Each Task Without Expanding Permissions

A simple document lookup and a spreadsheet repair may not need the same agent team. Choosing a setup for each task could avoid unnecessary work, but that choice should stay within approved access and outcome requirements.

Imagine a finance assistant asked first to retrieve a reported total, then to reconcile a workbook and return a corrected file. The lookup may need one reader. The repair may benefit from a planner, a coding agent and a verifier. These are hypothetical examples of different work requirements, not reasons to give the second team unrestricted access.

Predicting which setup to run

Dynamic Harness Search, by Som Sagar and colleagues at Google and Arizona State University, introduces SHIFT. It constructs a harness, the arrangement of agent roles, instructions, tools and handoffs used to execute a task, separately for each query.

During training, the system executes alternative arrangements and learns to predict their usefulness from task success and resource use. At inference time, a small local model guides a tree search through combinations from a specified component library. The search scores alternatives without running them; only the selected arrangement executes.

That distinction matters. The selector estimates which arrangement will work well. It does not collect execution evidence for every arrangement it considers.

Reported gains have different costs

The October 2, 2026 preprint compares six benchmarks using a shared Gemini 3.5 Flash executor. Its accuracy-oriented variant reports a 79.9% equally weighted benchmark mean, compared with 72.7% for the strongest baseline, Trace. It also consumes more executor tokens than Trace.

A different variant selects by predicted utility, which balances success against resource use. It reports 74.5% mean accuracy with approximately 32% fewer executor tokens than Trace. These are two operating points, not one method that achieves the highest accuracy and the lower cost simultaneously.

The largest gains occur on document and general-assistant benchmarks with 41 and 51 held-out tasks. Token comparisons exclude selector computation and training. Training itself requires many candidate executions, so savings depend on how often the resulting selector can be reused.

The results support investigating task-specific arrangements, not assuming that more agents help every task. They also do not establish permission enforcement or safe deployment. The paper's component library and feasibility checks constrain construction; they do not evaluate security enforcement in production.

What this raises for WTK

WTK describes agents and teams through catalog packages and connects those descriptions to a target runtime through compilation. Here, the useful question is whether selection or composition could vary within an approved set, rather than inventing a new deployment arrangement without review.

A possible design would separate the choices available to the selector from the authority governing the run. It could select a supported reader or a permitted verification step without changing the accessible files, total budget, required result or authority to publish changes. If a task needs access outside that boundary, choosing a larger team would not resolve the missing authorization.

This extends our discussion of controls for generated workflows. That note asks which restrictions follow delegated work. This paper adds a selection question before execution: which permitted arrangement is worth running?

Our routing cost note supplies another constraint. Selection should be assessed using its own computation, training and maintenance costs, along with retries and completed goals. Fewer executor tokens alone would not establish a cheaper WTK workflow.

What we need to understand next

Before defining a WTK experiment, we would need to identify the catalog components eligible for composition, the combinations a target runtime supports, and the evidence that remains valid when an arrangement changes. Individual component qualification, evaluation of a specific version in a specific environment, would not automatically qualify every resulting team.

We have not tested this selection approach in WTK. A model, component-library or runtime change could alter both its predictions and execution outcomes. The research sharpens a useful question: can task-specific selection improve completion while leaving permissions, acceptance criteria and promotion decisions independently controlled?

Source

Som Sagar, Shasha Li, Hejie Cui, Ransalu Senanayake and Sercan Ö. Arık, Dynamic Harness Search: Building Multi-Agent Systems Per-Query via Prediction, arXiv:2610.04137v1, October 2, 2026. The reported experiments are the authors'. Catalog selection and permission boundaries are WTK's interpretation, following our research method.