Jev for AI Agents: Route the Decision Job

By William Zhu & the InfiniSynapse Data Team · Published: 2026-09-23 · Last updated: 2026-09-23 · Last verified: 2026-09-23 · 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
• Why routing needs its own layer
• The six-object Decision Job
• Five routing points for Jev
• The routing contract
• State transitions and fallbacks
• Audit fields and observability
• Reference architecture
• Deployment review checklist
• Frequently Asked Questions
• Conclusion

TL;DR

Direct answer: Jev for AI agents belongs at bounded routing points inside a Decision Job. Jev for AI agents can return a typed Choice, Score, or Noul probability; deterministic runtime code must validate the response, apply policy, and choose whether to continue, fall back, or ask a human. Jev for AI agents is not the orchestrator, authorization service, SQL engine, or action executor.

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 for AI agents 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 Jev for AI agents at bounded judgments without handing a model 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.

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 is convenient, but it joins unlike responsibilities. Open-ended generation and bounded classification have different output contracts, failure modes, and review needs.

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. That makes Jev for AI agents interesting at narrow branch points. A typed result can remove response parsing, but a valid type does not prove the business judgment is correct.

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.

Typed output is not execution authority

If Jev for AI agents chooses human_review, application code may enqueue a review. If it chooses publish, the answer still cannot bypass a publish gate. 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. The route is advice to the runtime, not a capability token.

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.

Jev for AI agents 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.

Map every route to an object

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

Five routing points for Jev

The following placements are architectural candidates, not measured recommendations. Each requires an evaluation set, thresholds, and a deterministic fallback before Jev for AI agents 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.

LangChain’s discussion of building a harness with Jev places model behavior inside a broader harness. That distinction matters: Jev for AI agents may recommend the lane, while the harness controls retries, state, and execution.

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 for AI agents 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 agent 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. For example, missing row counts or a failed reconciliation cannot be repaired by high confidence.

The point is not to let Jev for AI agents certify truth. It is to prioritize the next move while evidence remains an explicit Decision Job object.

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. That supports a hard boundary: a model result may inform risk triage, but identity and entitlement checks stay in the authorization layer.

Confidence-based escalation

Confidence needs two controls: a route-specific threshold and a low-confidence destination. “Below threshold” must be a named branch, not an exception swallowed by the agent loop. A typical order is:

1. validate response shape and allowed values;
2. compare selected probability and confidence with versioned thresholds;
3. apply deterministic policy constraints;
4. continue, use a stronger model, or request human review;
5. append the complete routing event to the job timeline.

Thresholds must come from evaluation on representative labeled decisions. This article provides no Jev accuracy threshold and makes no calibration claim on InfiniSynapse workloads.

For Jev for AI agents, threshold ownership belongs to the route owner, not to a generic global setting.

The routing contract

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

Required inputs

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 Jev for AI agents 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.

State transitions and fallbacks

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

Timeout and rate-limit behavior

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 for AI agents 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 Jev for AI agents differs from putting classification inline with an action. The route can fail without losing the job.

Audit fields and observability

A useful Jev for AI agents 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.

Reference architecture

The proposed request path is:

1. the runtime opens one Decision Job;
2. deterministic code constructs a minimal state projection;
3. a Jev for AI agents 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.

This design complements data ops, where resume, quota, and audit keep the same job alive. It also prepares for the future implementation-focused Jev API guide and the boundary-focused Jev data analysis guide.

What Jev must not own

Jev for AI agents 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 Jev 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 Jev for AI agents in shadow evaluation. A valid JSON response is not deployment evidence.

Frequently Asked Questions

Is Jev the orchestrator in this design?

Bottom line: No. Jev for AI agents 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 for AI agents 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

Jev for AI agents is most defensible as a narrow decision layer inside a Decision Job. Jev 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.