Search the web with typed intent judgments

01 · Role in the system

What Jev does here

Jev answers typed intent questions about a plain-language request, and the application uses those judgments to select a query, vertical sources, and a time window, with chips the user can override. After concurrent engine calls, Jev scores each result for relevance; code merges by URL, orders by relevance, engine agreement, and original rank, and streams each lane as it finishes. A failed engine degrades one lane instead of the whole search.

From plain-language request to an executable search plan

The front end never asks the model to search. It asks typed intent questions about a plain-language request, and the application turns the answers into an executable plan: a concrete query, a set of vertical sources, and a time window. The chosen parameters appear as chips the user can override, which keeps a human in charge of exactly the judgments that shaped the search. The interesting decision, working out what the request actually wants, becomes a bounded classification instead of an open-ended generation task.

That division has a practical consequence for reliability. Query construction, source selection, and time filtering are the parts of search where one small mistake quietly ruins every downstream step. Making those judgments typed and inspectable, while fan-out, caching, and rate limits stay in code, means the failure-prone step is visible and overridable before any engine is called.

It is also worth naming the alternative this pattern avoids: the common design where a chat model is asked to search, read, and summarize in one open-ended prompt. There the judgments are coupled, so a wrong early inference about what the user wanted poisons retrieval and the summary together, and nothing in the interface shows which step went wrong. Splitting intent from execution makes each step independently observable, which is what allows the chips, the per-lane streaming, and the relevance percentages to be criticized and improved on their own terms.

Scoring results is separate from fetching them

After the concurrent engine calls return, Jev scores every result for relevance while code does the merging: deduplication by URL, then ordering by relevance score, engine agreement, and original rank. Each lane streams as it finishes, so a slow engine delays only its own column. If an engine fails outright, one lane degrades instead of the whole search, which is the difference between a degraded answer and an error page.

Two limitations deserve reading before copying the pattern. Relevance percentages are model judgments, not verified accuracy, and the ranking quality has not been independently evaluated. And the privacy surface moves with the architecture: search text, inferred queries, and result snippets go to TypeSafe and Search1API, and the project's analytics events are not anonymous query data.

Why the override chips carry the design

The override chips look like a small interface detail, but they hold the design's working philosophy. Intent judgments are shown as editable parameters before any engine fires, so a user who knows the right query syntax or vertical can correct the model in one click, and that correction lands before time and API budget are spent rather than after results disappoint. Recovery from a bad judgment is therefore cheap on both sides of the interface.

It also makes the system legible in both directions. Users can see what the model inferred about their request, which builds calibrated trust instead of blind reliance, and the project can observe which chips get overridden, which is the raw material for improving the intent questions themselves. This is why the directory treats the integration pattern as a first-class field: identical judgment quality lands very differently depending on whether the human can see and fix it.

02 · Control boundary

Where Jev sits

Plain-language request to typed intent judgments plus per-result relevance scores; deterministic code owns fan-out, merging, caching, and rate limits.

Code owns the loop, permissions, thresholds, validation, and side effects. Jev owns only the bounded judgments described above.

03 · Known limits

What this evidence does not prove

• Relevance percentages are model judgments, not verified accuracy, and model choices and provider coverage can vary.
• Search text, inferred queries, and result snippets go to TypeSafe and Search1API, and the analytics events are not anonymous query data.

04 · Attribution

Public sources

This is a Community record: the project was published by a third-party community author.

• superagents-lab ↗Community · github · public · checked 2026-09-18