Decisions beside the LLM¶

A decision model answers typed questions about supplied information. Main, Coder and generated apps can use the configured connection for decisions, alongside optional candidate ranking. It does not control the browser.

Two models, one client¶

The Fast decisions cards select Jev by TypeSafe, directly or through OpenRouter, or Laya, served from the configured machine or fleet. One is active at a time; the section switch controls availability without deleting the saved connections.

Both use a state and typed questions: a choice among options, an ordinal score, or a yes/no probability. The shared client in server/decisions.js preserves provider responses, identity, usage, input-completeness metadata and errors. Calls produce timing and usage records. Chat tool exchanges use the existing evidence store; app calls return the exchange to the app. If chat evidence storage fails, the exchange stays inline with the storage error.

Where a decision is asked¶

Main and Coder have ask_decision_model while a decision connection is enabled and configured. They supply arbitrary content as state and a questions object. Each question uses noul (yes/true probability), choice (named options mapped to descriptions), or score (an ordered rubric array). Several questions can share one request. The model chooses the questions and how to use the answers; Nawa does not substitute its own judgment when the provider fails.

With a decision model enabled, these existing tools accept an optional intent:

web_search ranks the returned search candidates.
use_skill ranks the skill catalogue without loading instructions.
load_plugin_tools ranks plugin catalogue entries, or a selected plugin's tools, without loading or executing them.

The same semantic ranker asks an independent question for each candidate, batching by its token allowance. Returned indexes refer to the original list. Every candidate stays available; unknown scores and failed requests stay explicit. Rankings are advisory, and the main model chooses what to use. The selected decision model's identity is available to the lead and workers.

Browser actions¶

The main model controls browser plugins through their native tools. The coder uses the existing workspace browser tools for application checks. Neither path adds decision-model ranking, target selection or expectation checks. A decision-enabled app may make its own requests during a browser check when the Coder has outbound access. Browser schemas are unchanged by the decision-model switch. Native permissions, observations, errors and external-content screening remain authoritative.

Generated apps¶

Ask Nawa to create an app that uses the configured decision model. The app declares "capabilities": {"decisions": true, "network": "outbound"} in nawa.app.json and loads /__nawa/client.js. Its code can then call:

const result = await nawa.decisions.ask({
  state: { description: "The supplied facts to assess" },
  questions: {
    ready: { type: "noul", instructions: "Do the supplied facts establish readiness?" },
    action: { type: "choice", criteria: { proceed: "Ready to proceed", wait: "Needs more information" } },
    fit: { type: "score", criteria: ["poor", "fair", "good"] }
  }
});
// result.ok; result.response.body.answers; result.response.body.usage

The app receives the provider's answers and failure details. It should show unavailable or failed requests honestly. Probabilities and scores are judgments, not verified facts. An optional second argument {signal} allows cancellation.

Nawa keeps provider keys on its server. Only an owned, launched app receives a grant for its runtime. Saved apps keep working after the chat ends, using the owner's current saved decision connection; switching it off takes effect on the next app request. Previewing through Coder also requires outbound network authority. Apps exported to a separate host need their own backend connection; Nawa's private credentials are never exported.

Practical limits¶

Probabilities express model judgments, not proof. A ranking does not authorize an operation or verify task completion. Enabling a decision model allows the configured endpoint to receive supplied decision inputs; saved credentials retain their separate protection. Provider limits and charges apply. Total speed and quality must be measured for each use, including any correction work.

The earlier browser experiments did not demonstrate a reliable overall speed benefit. Their task loop and per-action integrations were removed rather than retained as disabled fallbacks. Historical measurements remain in the dated engineering reports.