Use case · Choice

Agent tool selection with Jev

Let Jev choose the tool and let an LLM fill in the arguments — the selection step stops scaling badly as your tool count grows.

The problem

The standard agent loop stuffs every tool schema into one prompt and asks the LLM to choose and call. Cost and latency grow with the tool count, and accuracy degrades once you are past a few dozen tools.

How Jev handles it

Separate the two jobs. Selection is a classification problem over a known option set — exactly Choice. Argument-writing genuinely needs generation, so keep an LLM for that step only.

python

# 1. Jev selects — criteria is a dict of option -> when to pick it,
#    so tool descriptions become the selection signal.
response = client.system_one(
    model="jev-latest",
    state=conversation,
    questions={
        "tool": Choice(
            instructions="Which tool should run next?",
            criteria={t.name: t.description for t in available_tools},
        ),
    },
)

# 2. An LLM writes arguments only for the winning tool
answer = response.answers["tool"]
if answer.confidence >= THRESHOLD:
    tool = registry[answer.choice]
    return tool.run(**llm.fill_arguments(tool.schema, conversation))
return llm.full_agent_step(conversation)

Does it actually work?

Independent evidence

An open benchmark with 100 mocked tools comparing how many steps the agent needs when the LLM picks the tool versus when Jev picks it, including confidence-gated routing with a configurable threshold.

vinilana/jev-eval-agent

Notes from the field

Build the options list fresh each turn from live state — a dynamic action space is the normal case, not an edge case.
Only the winning tool's schema goes into the LLM prompt, which shrinks that prompt dramatically.
Measure your confidence threshold against labelled traces; do not ship a guessed number.