A human example
A user needs a compact desk lamp with warm light and no subscription-dependent controls.
What the caller supplies
The app filters availability and exact constraints, then supplies IDs and descriptions for eligible items.
What happens next
Jev chooses an item ID or no match. The agent checks the listed facts before recommending it.
Illustrative example, not a recorded result.
Potential value: high
This selection pattern can serve asset libraries, templates, product catalogs and saved tools. One reusable contract covers several frequent tasks.
Evidence confidence: low
The decision shape appears in demos and official examples. We have no representative item-selection study for the Engine.
The rating describes support for this claim. It is separate from Jev's returned probability. How we assign ratings.
Evidence, including disagreement
- A personal app routes two recipe requests. anecdotal. Descriptions can distinguish two plausible routes; reliability remains untested.
- Choose a card design from a page description. anecdotal. A concrete design-selection integration exists; preference quality is unmeasured.
- TypeSafe examples for decisions over supplied text. reference. Official examples show how to frame the question; each adaptation needs testing.
The next test
60 authored requests over fixed catalogs, including similar descriptions, missing facts and no-match cases.
Compare against
- Exact filters and keyword ranking
- Direct agent selection
Measure
- Human-labeled acceptable set
- Unsupported attribute claims
- No-match recall
- Total task cost
Decision after the test
Require no invented attributes and at least the baseline acceptable-choice rate before making it a default.
The report will retain inputs, question versions, every attempt and failure examples. We will update the confidence rating after reviewing the result.
Use a related Engine recipe
Recipes are implementation starting points. Their presence does not mean the protocol above has passed.