10 Levels of Jev For Agentic Engineers

An agent fixing a checkout bug does more than write code. It sorts through tickets, chooses files to inspect, interprets test output and decides when it needs help. Those small judgments can fill its context window before it reaches the change.

Jev, TypeSafe AI's decision model, gives developers another place to run that work. A harness can send a bounded question to Jev and return a compact result to the main agent. The useful question is which decisions deserve that extra call.

IndyDevDan's 10 Levels of Jev for Agentic Engineers demonstrates the progression from classification to agent-selected questions. Here we examine those ten patterns through a cloud-agent workflow, including where the approach needs limits. These are implementation patterns to evaluate, not features we have shipped in SpineOS or benchmarks we have reproduced.

What is Jev, and how does it fit an AI agent?

Jev evaluates supplied context against typed questions and returns decisions that code can consume. TypeSafe calls this a System One model. Its three primitives cover yes/no propositions, fixed choices and ordered scoring rubrics. See the official introduction.

The developer supplies the context and decides what each result permits. Jev does not discover your repository, execute a command or preserve a session by itself. Those capabilities belong to the harness around it.

1. Detect suspicious instructions before they reach an agent

Use a yes/no question to flag content that appears to redirect the agent beyond its assigned task. For example, a support ticket might contain a request to ignore existing instructions and disclose credentials.

Provide the assigned task, the source of the text and the suspicious content as separate fields. Otherwise, a legitimate user request to update an account can resemble an instruction injected into a retrieved page.

The result can send content to review or restrict how it enters context. Treat it as a detection signal. Access controls must still prevent credential disclosure when detection fails.

2. Classify support tickets with explicit priority rules

Use Choice questions to assign a category and a priority before a coding agent opens the ticket. Ask both questions against the same ticket, with separate criteria.

An export failure in one browser with a documented workaround differs from a checkout failure blocking all customers. Define those distinctions in the rubric. Include an insufficient_information option so a vague report has somewhere to go.

This is a useful first experiment because the output is easy to review and a wrong label can be corrected before anyone changes code.

3. Score review risk across separate dimensions

Use several narrow scores when a single risk label hides different reasons for concern. A patch can be small while touching authorization, or large while changing only generated documentation.

For a review queue, useful dimensions include exposure to untrusted input, reach of the changed behavior and strength of verification. Combine their scores in application code with documented weights. TypeSafe's Score primitive supports an ordered rubric for each question.

A weighted total can rank reviews. Keep hard requirements separate: a change to authorization can require specialist review regardless of its average score. A low total cannot establish that a patch is secure.

4. Route uncertain decisions to review

Use uncertainty to choose the next step: act, gather more evidence or escalate. That makes the classifier useful even when it cannot choose confidently.

For a nonbinding ticket label, automatic classification may be acceptable. For a destructive action, require authorization independently of the model's answer. Select thresholds from labeled examples and the consequences of a mistake.

One detail matters: TypeSafe's Choice and Score confidence summarizes their probability distribution. It is not a statistical confidence interval or a universal probability of correctness. Noul returns its yes-probability without a separate confidence field. The confidence documentation explains the distinction.

5. Route tasks to the right model or agent

Use a routing decision to select a capable worker before starting expensive work. The route should reflect required capabilities as well as task difficulty.

Check capabilities deterministically before routing. A classifier cannot give a worker browser access or permission to use an account. Evaluate successful task completion and rerouting cost, rather than choosing the cheapest first call in isolation.

6. Add semantic checks before tool execution

Use Jev to flag risky intent in proposed commands or file writes, alongside enforceable tool permissions. This adds a semantic review step to a harness that already controls execution.

For a shell command, include its working directory and relevant resource context. Deleting a reproducible dependency directory differs from deleting the only copy of session history. A command string alone may not establish which case applies.

A classifier is not a security boundary. Shell expansion, scripts, symlinks and changing filesystem state can make an apparently harmless command destructive. Enforce access restrictions at execution time, preserve approval requirements and route uncertain or unavailable classifications to review. Do not let the agent bypass the check through another execution tool.

The same principle applies to writes: protect sensitive paths with filesystem permissions and tool policy. Model judgment can flag an unexpected edit; permissions must still hold if it misses one.

7. Choose better moments to compact context

Use a decision model to identify a suitable compaction boundary after deterministic context thresholds have been reached. A completed investigation followed by a new task can be a better boundary than the middle of an unresolved failure.

Send a small state summary: context usage, active objective, unfinished steps and recent task transitions. Ask whether the current work has reached a stable stopping point. The harness can then invoke its own summarization mechanism.

Retain a hard context ceiling. A mistaken recommendation to keep going must not exhaust the window. Compaction must preserve the objective, evidence, pending decisions and references needed to resume. Our separate Jev memory-cleanup article covers stale knowledge across sessions.

8. Ask questions about files before loading them into context

Use file-level classification to shortlist what the main agent should read. A tool can read a candidate file, send its content to Jev and return a small answer to the agent.

For example: “Does this file calculate invoice rounding?” or “Which application layer does this file implement?” The main agent then reads the shortlisted files before editing them.

This keeps file content out of the main agent's context, but the file is still read and sent to another model provider. Apply data-handling rules before transmission. Do not upload a suspected credential file to determine whether it contains credentials. Use local controls and approved scanners first.

Keep a file reference and content hash with the result. A classification of yesterday's file is weak evidence for today's edit.

9. Triage many files with bounded parallelism

Apply the same question across a candidate set when semantic relevance is hard to express as a text search. For a rounding failure, first use filenames, search results and dependency information to narrow the repository, then classify the remaining candidates.

Use a queue with concurrency, file-size and total-token limits. Cache by content hash, question version and model version. Report files that were skipped, truncated or failed; they are unknowns, not negative answers.

Measure recall: how often did the shortlist include the file the engineer ultimately needed? A fast filter that hides the relevant file can increase total debugging time. Obvious TODO markers still belong to ordinary text search.

10. Let agents ask bounded questions about tool output

Expose a constrained ask_jev tool when the agent needs to classify test output or challenge a hypothesis. The tool accepts approved source references and bounded questions; the harness resolves the content.

After a failed test, an agent might ask whether the output indicates an assertion mismatch, unavailable dependency or timeout. It can then inspect the relevant evidence before proposing a fix. Keep the raw output available for that inspection.

The test runner's exit status remains the execution result. A classifier saying “tests passed” cannot override a failing process or establish that the test covered the behavior. Agreement between two models on the same incomplete input is also weak verification. Prefer an independently observed outcome.

Cap calls per task so self-checking does not become an unbounded loop.

What does a Jev JSON request look like?

A request contains the state to evaluate and named questions with explicit answer criteria. This illustrative routing payload follows TypeSafe's documented Choice request format; it is not a live result.

{
  "model": "jev-1.13.0",
  "state": {
    "task": "Download last month's invoice from the supplier portal.",
    "available_capabilities": ["repository", "browser"],
    "account_access": "Must be checked before execution"
  },
  "questions": {
    "worker": {
      "type": "choice",
      "instructions": "Which worker capability does this task require?",
      "criteria": {
        "coding": "Inspect or modify repository files without using a website.",
        "browser": "Interact with a website to complete the task.",
        "clarify": "The task lacks enough information to select a worker."
      }
    },
    "needs_account": {
      "type": "noul",
      "instructions": "Does completing this task require access to a user account?"
    }
  }
}

Each answer belongs under its question identifier. The route chooses a candidate worker; application code still checks account access. Pin the evaluated model version so a moving alias does not silently change routing behavior. Verify available versions in the model reference.

How much do a million Jev calls cost?

At the published direct API price of $0.042 per million input tokens, one million requests with 500 billable input tokens each cost $21. Output tokens are free under that pricing, checked on 15 October 2026. See TypeSafe's model pricing.

input cost = requests × billable input tokens per request
             ÷ 1,000,000 × price per million input tokens

Include the state and question definitions in token estimates. Large file scans, retries, fallback models and any gateway charges change the total. “A million calls for $20” describes a small payload, not a flat request price.

Measure end-to-end latency under your own concurrency and network conditions. A short model call can still slow a task if it adds a sequential dependency before every tool action.

How do you use these patterns in SpineOS?

Run the Jev client from the agent's cloud desktop and use its results inside your task workflow. SpineOS provides the computer, files and task interface; you supply the Jev account and custom integration. There is no Jev switch to enable for the patterns described here.

Start with a report-producing helper. Add routing or enforcement only after you have evaluated the reports.

Set up a read-only Jev helper on one desktop

A small helper is enough to test ticket classification and file selection without changing the agent runtime.

1. Open a SpineOS desktop with your project available. Use its terminal to build a helper that accepts approved file references or a ticket, calls the TypeSafe API and saves structured answers. This is custom code you create, not a bundled SpineOS command.
2. Configure a TypeSafe API key for that helper. Keep it out of task prompts, source control and reports. Limit the data the helper may transmit, and review the provider's data terms before using private files.
3. Give the helper a fixed set of questions, file and token limits, a timeout, and an explicit unknown result on failure. Initially allow it to write reports only.
4. Create a Prompt task in Mission Control targeting that desktop. Ask the agent to use the helper for a shortlist, then inspect the selected files itself. Create and run the task as described in Creating tasks.
5. Keep raw JSON and test logs on the desktop. Save a short report in the workspace knowledge base when other agents need the findings. Include source references, content hashes, question and model versions, and failures.

The helper should read the file internally and return only its classification and reference to the main agent. Asking the agent to paste the entire file into a Jev request would already spend the context you intended to save.

Map each Jev pattern to a SpineOS task

Each pattern needs a specific integration point. A task prompt can guide tool use, while pre-execution enforcement requires changes to the agent's actual tool boundary.

Task review and tool approval serve different purposes. SpineOS's documented approval workflow moves a task to Review after it runs. It does not undo commands already executed. For a potentially destructive follow-up, make the first task produce a plan only, review it, then authorize a separate execution task under enforceable tool permissions.

Example: investigate an invoice-rounding failure

Use one desktop to run tests and a read-only helper to select candidate files. Once the helper exists, a task prompt could read:

Investigate the invoice-rounding failure in this project. Run the relevant tests and keep the original output and exit status. Use our installed Jev helper to classify the failure and rank candidate files after ordinary code search. Do not send credential files or unrelated customer data. Read the shortlisted source before proposing a fix. Save a report with file references, uncertainties and test evidence. Stop after the report; do not edit files or deploy.

Review whether the shortlist contained the right file and whether it saved time. A follow-up task can implement the reviewed fix and rerun the tests. The agent still has to understand the source it changes; Jev reduces the preliminary sorting work.

Where should a SpineOS workflow start?

Start with a read-only file shortlist or ticket classifier, in shadow mode. Record what Jev recommends while the existing workflow continues making decisions. Compare those recommendations with the files engineers needed or the labels reviewers chose.

SpineOS provides persistent cloud desktops for AI agents. That gives an agent a place to keep the repository, tools and reports needed for work across sessions. A Jev-enabled harness could keep classification artifacts there too, with the source reference and model version attached. This article proposes that workflow; it does not announce a built-in Jev integration.

Before enabling automatic routing, measure errors, abstentions, shortlist recall, latency and total task cost. Define what happens when the provider times out. Increase autonomy only where the evidence supports it.

If your agent spends most of its time deciding what to read, this is a concrete experiment to run. Explore SpineOS cloud desktops and choose one bounded decision to evaluate in your harness.

Related reading and source material

• Jev for AI agent memory cleanup
• Persistent environments for AI agents
• AI agent isolation boundaries
• IndyDevDan's Ten Levels of Jev repository, companion to the walkthrough that inspired this article
• TypeSafe's Noul reference

Examples are design proposals. Cost figures are arithmetic at published pricing, not measured SpineOS usage.