Jev Agent: Routing Inside a Decision Job

By William Zhu & the InfiniSynapse Data Team · Published: 2026-09-23 · Last updated: 2026-09-26 · Last verified: 2026-09-26 · Next review: 2026-12-23 · Editorial standards · Corrections

Author credentials: William Zhu, Cofounder of InfiniSynapse, and the InfiniSynapse Data Team. This article presents an architecture proposal and a reviewable contract. It does not report a production integration, customer result, or independent benchmark.

Table of Contents

• TL;DR
• What a Jev agent is
• Why routing needs its own layer
• The decision loop
• The six-object Decision Job
• Closed decisions inside the job
• Typed output and JSON mode
• The routing contract
• When the routing call is unavailable
• Audit fields and observability
• What the route must not own
• Deployment review checklist
• Frequently Asked Questions
• Conclusion

TL;DR

Direct answer: A Jev agent is the runtime step that sends one closed question about job state and receives a typed Choice, Score, or Noul probability. Code validates that answer, applies policy, and then continues, falls back, or asks a human. A Jev agent proposes the route. It does not open the job, grant access, run SQL, or publish the artifact.

This is a proposed architecture, not a claim that InfiniSynapse currently integrates Jev. The design preserves one job identity across input, sources, named views, evidence, gates, and artifacts. A downloadable routing-contract JSON template makes the proposal inspectable and includes a worked example.

We evaluated the published Jev agent interface and architecture examples as a desk review; we did not run a production integration or benchmark.

What you will be able to do:

• place a Jev agent at bounded judgments while application code keeps execution authority;
• map every decision to the existing six-object Decision Job;
• define confidence, timeout, and service-unavailable behavior before deployment;
• record enough context to replay why a route was taken.

What a Jev agent is

A Jev agent is one step in an agent runtime, not a second orchestrator. The caller passes a versioned slice of state and a question whose answers are already listed. The model returns a choice from that list, a score on a rubric, or a yes-or-no probability. The program that called it decides what the result is allowed to do.

TypeSafe describes Jev as a System One model for typed decisions rather than free-form prose in its announcement of System One models and Jev. The model definition, including Choice, Score, and Noul, stays on Jev AI. This page owns the placement: which branch a Jev agent may advise, and which controls stay in the Decision Job.

A typed result removes a failure mode that shows up when a generative step invents a tool name or returns a shape the next function cannot parse. OWASP’s Agentic Action controls state that access control must be enforced by application logic or a policy engine, not by the AI model, in AISVS C09. If a Jev agent selects human_review, code may enqueue that review. If it selects publish, the answer still passes through the publish gate. The route is advice, not a capability token.

A valid type still does not prove the business judgment. Thresholds, evaluation labels, and deterministic checks remain outside the model call.

Why routing needs its own layer

An agent loop often asks one generative model to interpret the request, choose a source, pick a tool, judge evidence, write prose, and decide whether to act. That joins unlike responsibilities. Open-ended generation and bounded classification have different output contracts, failure modes, and review needs.

A Jev agent is useful at the narrow branch, where the answer set is already known and the same decision repeats. The architecture therefore separates four roles:

The AWS Machine Learning Lens likewise treats the surrounding workload—security, reliability, operations, and cost—as an architecture concern. A typed route does not remove those responsibilities.

The decision loop

The proposed path for a Jev agent is short enough to review before anyone writes an adapter:

1. the runtime opens one Decision Job;
2. deterministic code constructs a minimal state projection;
3. a Jev agent adapter sends one bounded question;
4. a validator checks type, model version, and probability fields;
5. threshold logic produces a candidate route;
6. the policy engine checks authorization and risk;
7. the runtime performs the allowed transition or pauses;
8. the job stores the event, evidence, gate result, and eventual artifact.

Figure. Illustrative routing shares for teaching; production thresholds require representative local labels.

LangChain’s discussion of building a harness with Jev places model behavior inside a broader harness. That distinction belongs in the loop: a Jev agent may recommend the lane, while the harness controls retries, state, and execution.

This design complements data ops, where resume, quota, and audit keep the same job alive. Implementation of the adapter belongs on the Jev API guide. Token and choice ceilings belong on the Jev limits page.

The six-object Decision Job

The existing Decision Job model defines one identity carrying six objects:

1. Input — the question, constraints, and acceptable artifact.
2. Sources — authorized grants and source descriptors.
3. Named intermediate views — reopenable results produced during analysis.
4. Evidence — counts, plans, lineage, and observations supporting a claim.
5. Gates — deterministic checks and human vetoes.
6. Artifacts — approved outputs or inputs to a later job.

A Jev agent does not add a seventh object. A routing decision is an event attached to the relevant object and the single job ID. This keeps the judgment from becoming a second, untraceable timeline.

The data infrastructure hub explains the runtime around these objects. The route remains subordinate to that runtime.

Closed decisions inside the job

The following placements are architectural candidates, not measured recommendations. Each requires an evaluation set, thresholds, and a deterministic fallback before a Jev agent can handle live traffic.

Model routing

A Choice question can select among fast_model, deliberate_model, or human_review from a closed set. The state should contain task characteristics and evidence availability, not secrets or an entire transcript by default. The runtime validates the selected key and budget, then dispatches.

Source routing

Given authorized source descriptors, a Choice can propose which candidate is most relevant. It must not expand the user’s grants. The source adapter rechecks authorization before reading anything. “Likely relevant” and “permitted” are independent facts.

This Jev agent placement works only when candidates are enumerated. If the task is to discover unknown sources across the organization, use retrieval and catalog search first; then present the bounded candidate set.

William Zhu’s public six-system retrieval test illustrates that split. Across 25 year-anchored Apple 10-K questions, vector similarity placed the gold document first for 16/25 questions but within the top three for 25/25. The proposed pattern is therefore retrieval for a small candidate set, followed by a typed relevance decision and a declared fallback. This is founder-reported first-party evidence on one corpus, not a general retrieval theorem.

Evidence routing

A Noul-style probability can estimate whether the current evidence supports continuing, while a Choice can select collect_more, reconcile, or ready_for_gate. Deterministic completeness checks still run. Missing row counts or a failed reconciliation cannot be repaired by high confidence.

The point of a Jev agent here is to prioritize the next move. Evidence remains an explicit Decision Job object, and the model does not certify that the claim is true.

Tool-risk routing

A Score can estimate operational risk from an already-defined rubric. The runtime translates that score into a policy lane: auto-run read-only work, request approval, or deny. The score never grants permission.

NIST’s NCCoE concept paper on software and AI agent identity and authorization treats authorization, delegation, and accountability as system concerns. A model result may inform risk triage. Identity and entitlement checks stay in the authorization layer.

Confidence bands

Confidence needs a route-specific threshold and a named destination for every band. “Below threshold” is a branch in the job, not an exception the loop swallows.

A practical order is: validate the response shape, compare probability and confidence with versioned thresholds, apply deterministic policy, then continue, escalate, or stop. Append the complete routing event to the job timeline.

A Jev agent does not choose the band. The route owner publishes the thresholds, and runtime code applies them. Thresholds come from evaluation on representative labeled decisions. This article provides no accuracy number and makes no calibration claim on InfiniSynapse workloads. For a Jev agent, threshold ownership belongs to the route owner, not to a generic global setting. Score the labels with the Jev benchmark protocol before production traffic.

Typed output and JSON mode

A caller can make a generative model return JSON that names one of a few keys. That interface looks similar to a Jev agent result, and the two workloads are different. The fuller split between decision models and generative models is on Jev vs LLM.

Keep a Jev agent on decisions whose options were listed before the call. Structured output constrains generation. A Jev agent is the step whose job is the closed decision itself. Either way, application code validates the key and runs policy afterward. A schema-shaped answer is not authorization, and a high probability is not a publish approval.

The routing contract

The contract is the information-gain asset for this article. It is a vendor-neutral JSON template with a Jev agent adapter section. Reviewers can verify every required field and follow the included source-routing example without an API key.

Each decision declares:

• job_id and decision_id;
• the Decision Job object being read;
• a versioned state projection, excluding credentials;
• a closed answer space;
• model and question versions;
• minimum confidence and selected-probability rules;
• timeout, invalid-response, and unavailable-service fallbacks;
• policy checks that run after model output;
• the exact audit fields to persist.

Download and inspect the complete routing contract. The file distinguishes reusable template fields from the worked example so a team can validate it with ordinary JSON tooling.

Worked source-routing example

The example asks which already-authorized source should answer a weekly net-revenue question. The allowed choices are warehouse_revenue_view, billing_export, and human_review. It does not ask a Jev agent to discover credentials, run SQL, or calculate revenue.

An illustrative response selects warehouse_revenue_view with probability 0.82 and confidence 0.77. Those numbers are explicitly marked illustrative, not measured output. Because the example thresholds are 0.75 and 0.70, the proposed route proceeds to runtime checks. The runtime must still confirm that the source grant is active and that the view’s freshness meets policy.

If either check fails, the contract routes to human_review. It never silently selects the second-best source.

When the routing call is unavailable

Routing only becomes operational when failure behavior is more specific than “retry.”

Set one deadline for the routing call and a bounded retry budget. After that budget, choose a declared fallback. Low-risk model routing may use a deterministic default; source or tool-risk routing should usually fail closed or ask a human. The Jev agent failure path must be valid before the success path receives traffic.

Temporal’s documentation on Workflow Execution illustrates why durable execution state is separate from a model call. Whether or not a team uses Temporal, the Decision Job should persist the pre-call state and resume from the same job ID after a transient failure.

Invalid or unavailable response

Reject unknown choice keys, missing probability fields, non-finite numbers, and model versions outside the allowlist. Do not coerce them into a valid branch. Service unavailable is also a routing outcome:

This is where a Jev agent stays separate from classification inline with an action. The route can fail without losing the job.

Audit fields and observability

A useful Jev agent event records inputs and outcomes without logging sensitive raw state. At minimum, retain the job and decision IDs, state-projection hash, question version, resolved model version, candidate keys, selected key, probabilities, confidence, thresholds, policy results, final runtime route, fallback reason, latency, and timestamps.

OpenTelemetry defines a trace as the path of a request through an application in its traces documentation. Add the routing decision as a span or event correlated with the Decision Job ID, while storing the reviewable business record in the job itself. Telemetry helps operations; it does not replace the audit object.

What not to log.

Do not copy bearer tokens, raw credentials, unrestricted customer records, or hidden authorization rules into the state or event. Store references and hashes where possible. Log enough to reconstruct the route, not enough to create a second data leak.

What the route must not own

A Jev agent must not own:

• job identity or orchestration;
• source credentials or user entitlements;
• SQL generation and execution;
• arithmetic, reconciliation, or causal inference;
• irreversible tool execution;
• the final publish gate;
• factual explanations unsupported by stored evidence.

The proposed architecture is intentionally narrow. The value is a typed routing signal inside a governed job, not a model promoted into a control plane.

Deployment review checklist

Before routing production traffic, require affirmative answers:

• Is the answer space closed and versioned?
• Is there a representative labeled evaluation set?
• Are confidence rules specific to this decision?
• Does every failure mode have a safe destination?
• Does authorization run after the route?
• Can a reviewer replay the event from one job ID?
• Can operators disable the Jev agent call without losing the job?
• Are high-impact actions blocked pending exact approval?
• Are model and question changes separately versioned?

If any answer is no, keep the Jev agent in shadow evaluation. A valid JSON response is not deployment evidence.

Frequently Asked Questions

What is a Jev agent?

Bottom line: A Jev agent sends one closed question about job state and receives a typed Choice, Score, or Noul probability. Application code validates the answer and then continues, falls back, or asks a human.

How does this step differ from an LLM agent?

Bottom line: An LLM agent generates the next text or tool call. A Jev agent returns one allowed decision and a probability. Open-ended writing and multi-step planning stay with the generative model.

Is Jev the orchestrator in this design?

Bottom line: No. A Jev agent returns a bounded judgment. The Decision Job runtime owns state transitions, retries, policy, and execution.

Can confidence authorize a tool call?

Bottom line: No. Confidence can select a review lane. Authorization must be enforced independently by application code or a policy engine.

Does this mean InfiniSynapse currently integrates Jev?

Bottom line: No. This article presents a proposed architecture and downloadable contract. It does not claim a current InfiniSynapse integration or production result.

Why keep one Decision Job ID?

Bottom line: One ID binds the route to its input, sources, named views, evidence, gates, and artifacts. A second chat creates a competing timeline.

What should happen when Jev is unavailable?

Bottom line: Follow the declared Jev agent fallback. Reversible suggestions may use a deterministic default; publish and high-impact routes should hold or require review.

Is a typed answer necessarily correct?

Bottom line: No. Type correctness prevents malformed output, not semantic error. Evaluate each route and preserve deterministic gates.

Conclusion

A Jev agent is most defensible as a narrow decision step inside a Decision Job. It proposes a typed route; validators, thresholds, policy, and humans decide whether that route may advance. The six-object job remains the system of record, and the downloadable contract makes the boundary reviewable before anyone writes integration code.