Introducing JevAgent

JevAgent borrows the System 1 and System 2 framing from psychology, then applies it literally. System 1 is your model. You pick the provider, the model, the system prompt, the tools, and the loop limits, exactly as you would for any Vidbyte SDK agent. Every reply, tool call, and piece of planning comes from it.

System 2 is Jev. Jev is a decision model: it answers yes/no and choice questions with probabilities, quickly and cheaply, and it cannot write prose. JevAgent sends it a small number of fixed, well-specified questions at fixed points in the run, then code decides what to do with the answers. Thresholds, vetoes, and caps live in the SDK, not in a prompt the model might talk itself out of.

Because the questions are fixed, the behavior is inspectable. Every check you turn on leaves its scores, its answers, and its usage on agent.response, so you can see why a run stopped to ask, why it went back to work, or why it brought in help.

A human contractor who gets a vague brief asks a question. An agent usually guesses, and it guesses at full price: a long loop, tool calls, and a confident answer to the wrong question. The clarity check moves that question to the front of the run, where it costs the least.

When it is on, Jev reads the request against 14 fixed questions before your model sees anything. Does the request name its target? Does it supply the material the work needs? Does every “this” point at something? The check fails if the average confidence drops below 0.75, or if any single answer falls below 0.2, so one glaring gap is never averaged away by thirteen clean ones.

If the check fails, JevAgent does not start the main loop. Your model, running with no tools and a fixed prompt, turns the weakest gaps into one to six questions, each with two to four recommended answers. The run returns those questions as its reply and records them on the response. Jev reads only the new message, so your app re-runs the agent with the original request and the user's answers together.

An agent can only do good work with the right instructions and the right tools in front of it. Most teams handle this by growing one system prompt and one tool list until both are too long for the model to use well. JevAgent aligns the agent to the request before the loop starts instead.

Two alignment checks are on SDK main today. Specialist routing hands the whole task to the agent whose job covers it. Tool selection narrows a large tool catalog to the tools that could help with this request. Both ride in the same preflight request as the clarity check, so turning all three on still costs one Jev call before work begins.

A third layer, aligning the system prompt, tools, and skills to each request at run time, is in open pull requests. It is described in its own tab with its status.

The most expensive agent failure is the one you do not notice: a polished answer that skipped one of the three things you asked for. Agents finish early because the model decides when it is finished, and a model that has produced something reasonable is ready to stop.

Continuation takes that decision away from the model. Before work starts, your model writes a run state: the goal, what not to do, the hardest requirement, and the named deliverables. Each time the agent tries to finish, a handoff compiles the evidence for each item from a numbered log of what actually happened. A deliverable counts when the log shows it was made, not when the final answer promises it.

Jev then judges every enabled check in one request. Most checks use their threshold as a per-item veto as well as a bar for the average, so one clear “no” sends the agent back even when everything else looks finished. The agent returns to the same loop, with its history and tools intact, carrying a message that lists the original request, the run state, the evidence, the failed checks, and what to focus on. The cap is three continuations by default. After that, the current answer stands and every verdict stays on the response.

Long runs bury their own important facts. The decision made at iteration 4 is forty tool results deep by iteration 40. The usual fix is to ask a model to summarize the history, and summaries drift: they paraphrase, merge, and sometimes invent.

JevAgent keeps a run brief that cannot drift that way. Starting at iteration 3, and then every few iterations (ten by default), a separate writer with no tools reads only the events since its last pass and proposes new notes. Each note must be a verbatim passage of up to 500 characters with the id of the event it came from. Code checks every note against the full event text and rejects anything that does not match or that repeats an earlier note. The writer gets one retry with the error. The original request stays the brief's goal, so the goal itself never gets rewritten, and the newest 50 notes are kept.

The writer can run on a cheaper model from the same provider. The brief is what the mid-run compute checkpoint reads, and it is what clones start from, so a fresh agent inherits the facts of the run without inheriting its whole transcript.

Some runs need more than one agent's attempt. Most do not. Spending extra compute on every run wastes money, and never spending it leaves stuck runs stuck. JevAgent decides during the run, from evidence, instead of at configuration time.

On every iteration that continues the loop, JevAgent reads exact facts from the loop itself: the iteration, the number of tool calls, the current streak of failed tool calls, and the tokens used. No model is involved. Each time the run brief updates, Jev gets one request holding twelve evidence questions for each compute option you enabled. The questions ask about what has happened, such as whether the same failure persists or whether the plan keeps changing, rather than asking Jev to forecast whether help would work.

The option with the highest average confidence wins, but only at 0.8 or above. Today the option that acts is CLONE. It runs two to four copies of your agent in parallel, each starting from the request and the verified brief with an empty history, then hands their replies back to the main agent as one message. The other options are recognized and recorded, so you can see when Jev would have reached for them.

Each example below pairs a real failure pattern with the configuration that addresses it. The code uses settings on SDK main. The traces show what a run looks like, but their numbers are illustrative and not recorded Jev output.

preflight · clarity          mean P(yes) = 0.41  → stop and ask
  weakest  target 0.06 · information 0.09 · time_context 0.12 · scope_size 0.18

1. Which migration should the report cover?
   - The Postgres 15 to 16 upgrade on the orders cluster
   - The billing service move to the new event bus
   - Every migration shipped this quarter
2. Who will read the report?
   - The on-call engineers: steps, checks, and rollback
   - Leadership: outcome, risk, and timeline
3. Where is the migration's record?
   - The #db-migrations Slack channel
   - MIGRATIONS.md in the infra repository

main model tokens spent: 0

run state
  signature_fix     The webhook verifies signatures against the raw request body.
  regression_test   A test that fails on the old parsing and passes on the fix.
  runbook_update    The on-call runbook explains the new failure mode.

finish attempt 1                       evidence E2-E31
  signature_fix     P(yes)=0.95        E14 edit webhooks/verify.py · E19 pytest: 1 passed
  regression_test   P(yes)=0.91        E18 add tests/test_verify.py
  runbook_update    P(yes)=0.08        no tool call touched docs/runbook.md
  self_review       1 objection        an empty request body is not covered
  → continuation 1, same loop: failed checks + focus

finish attempt 2                       evidence E32-E41
  runbook_update    P(yes)=0.93        E36 edit docs/runbook.md
  self_review       resolved           E34 test_empty_body passed
  → every check passed: the answer stands

iteration  3   facts  tool_calls=6   error_streak=0   brief +5 notes (E2, E4, E5, E7, E9)
iteration 11   facts  tool_calls=24  error_streak=0   brief +4 notes
               compute  fresh_agent 0.31 · clone 0.22            → no change
iteration 19   facts  tool_calls=41  error_streak=3   brief +3 notes
               compute  fresh_agent 0.52 · clone 0.61            → no change
iteration 27   facts  tool_calls=63  error_streak=6   brief +2 notes (E88, E91)
               compute  fresh_agent 0.71 · clone 0.86            → CLONE
               3 clones start from the request + verified brief → replies join the loop
iteration 31   E104 test_nested_tables passed
finish         faithful_scope P(yes)=0.89                        → the answer stands

"I was charged twice for October."
  specialist     billing 0.81 · none 0.19                → billing runs its own loop

"Which enterprise customers opened the most tickets last week?"
  specialist     none 0.88 · billing 0.12                → main agent keeps the task
  tool selector  30 candidates → 4 kept (P >= 0.20)
                 sql_query 0.97 · ticket_search 0.93 · crm_lookup 0.88 · chart 0.34

JevAgent records every decision it makes. After a run, agent.response holds the preflight results, any clarification, the specialist that ran, the run state, the latest evidence and review, every done verdict, the number of continuations, the run facts, the brief and its updates, every compute decision, and any clone replies.

Usage is held to the same standard. Every model call in the run, from the question writer to the clones, goes to one usage ledger. If a call cannot be priced or its usage was not reported, the run raises instead of handing you an incomplete bill. That means your model must be in the SDK's price list. In exchange, the total on the response is the whole run, not just the main loop.

You do not need every capability on day one. Turn on the one that matches the failure you see most: the clarity check if your agent starts on bad briefs, multi-part continuation if it finishes early, or the compute checkpoint if long runs stall. Each one is independent and costs nothing until it runs.