An agent loop is a sequence of small commitments: which tool to call, which model to wake, whether a result is good enough, and when to stop. Most of those commitments are made by the same general-purpose model that is already doing the work. A decision model belongs only where that arrangement is wasteful or unsafe, and the placement matters more than the model.
The loop has four decision seams
A useful way to read an agent trace is to mark every point where control could go somewhere else. In practice those points cluster into four seams.
| Seam | Typical question | What the answer controls | Cost of a wrong answer |
|---|---|---|---|
| Routing | Which handler, model, or skill should take this? | The next branch | Wasted work or a misrouted request |
| Gating | May this action run? | Execution | Damage, data loss, or a leaked secret |
| Selection | Which tool or candidate fits? | The action space | A plausible but wrong call |
| Verification | Is the work actually done? | Loop exit | Premature completion |
The distinction matters because each seam has a different tolerance for latency, a different answer shape, and a different failure mode. A router that is wrong 5% of the time is a quality problem. A gate that is wrong 5% of the time is a security problem.
Put routing where the branch is
The cleanest placement is a branch that already exists in code. Intent routing sends one request containing a Choice over four intents (order status, product question, return, complaint) plus a Score for complexity. Intent confidence below 0.5 goes to a human. order_status goes to deterministic code with no model call at all, while complaints escalate when complexity exceeds level 1 or confidence falls below 0.5. The model does not handle the ticket; it decides which handler does.
Confidence-gated routing makes the second axis explicit. In its voice-banking example, any intent below 0.6 confidence routes to a support agent before an action is considered. check_balance is allowed at 0.6 because the worst case is a wrong read-out. approve_transfer needs more than 0.85, or the user confirms first. The caveat is the important part: confidence is not permission. A high-confidence answer can still be wrong, so irreversible actions keep hard limits in code beside the model.
That is the placement rule in one sentence: put the decision where the consequences change, not at the top of the loop where everything looks like planning.
Gate actions at the last responsible moment
A gate should see the concrete call, not a summary of the plan. jev-guard checks shell commands, file writes, and reads before they run and returns ALLOW, ASK, or DENY. Credential files, workspace escapes, and trusted read-only commands are decided by local fast-path rules in under a millisecond; ambiguous or destructive calls go to TypeSafe's System One model. It works with Claude Code, Codex CLI, and Antigravity, fails safe by asking when the API is unreachable, and has an audit mode that logs what would have been blocked. The README publishes no independent latency or accuracy benchmarks, so the sub-millisecond figure is the project's own framing of its fast path, not a measured guarantee.
The transport deserves the same scrutiny. Jev Agent Tools exposes one ask() call that picks a carrier from the environment (TypeSafe, OpenRouter, Cloudflare, then Vercel AI Gateway) and validates the response before returning it. Failures arrive as typed codes such as answer_id_mismatch, invalid_distribution, or unavailable; verdicts are never thrown. It retries 408, 409, 429, and 5xx up to three attempts, honors Retry-After, and requires exactly the requested answer and criterion IDs with finite probabilities in [0,1]. That is what a gate needs: a typed rejection it can turn into a conservative action, not an exception it has to interpret.
A gate is also not a sandbox. It decides whether a call may proceed; it does not contain the process that makes it. Keep OS-level isolation, filesystem permissions, and network policy underneath.
Batch speculative questions, but pay for them
Once a branch is chosen, some questions are reusable across branches. Speculative fan-out puts a category Choice plus four speculative Score and Noul judgments in one request. The questions run in parallel, so adding them usually has little effect on response time. The ticket example escalates bugs when severity is above 1.5 and reproducibility above 0.6, and flags refunds above 0.7; answers the taken branch does not need are simply ignored.
The cost is input tokens on every call. Fan out on questions several branches can reuse, not on everything a workflow might someday ask. A follow-up request is cheaper than a speculative question that never matters; a reused question is cheaper than a round trip.
Measure at the level you deploy
Placement decisions are easy to demo and hard to validate. AgentDecisionBench is useful because it separates three levels: L1 isolated questions (3,991 items from BFCL v4 and When2Call), L2 open-loop questions over recorded states (3,939 distinct questions, an answer key of 5,314 trajectory occurrences, and 153,621 answers from 39 models), and L3 closed-loop runs where the choice actually drives the agent. The third level is the one that matches production, and it is the one that requires running research code with an agent LLM.
Fast Models, Slow Evidence is the cautionary companion. Across 11 agent decision points and 7,283 base cases plus 6,640 robustness variants, Jev was significantly more accurate on 9 of 11 points, by 10.8 to 46.0 percentage points. But neither model beat chance on zero-shot model routing, the two tied on RAG relevance gating, and Laya changed 30% of its answers when option order was reversed. The paper's self-audit also found that an omitted pre-screen cost turned a reported 23.9% saving into an actual 4.3%, and that gate accuracy had been reported as end-to-end quality (58% versus 98%). The lesson is not that decision models fail; it is that an offline decision score is not the same as a loop-level outcome.
A placement checklist
- Put the decision where the branch is, and let code own the branch.
- Gate the concrete call, not the plan, and decide the failure posture before rollout.
- Use one request for questions that share state; do not fan out on speculation.
- Keep policy (thresholds, permissions, budgets) in code, not in the question text.
- Measure at the level you deploy, and keep an escalation path for the cases the model marks uncertain.
The coding-agent page is blunt about the first mistake: there is no model: jev-latest setting for Claude Code or Cursor, because Jev is not a drop-in agent model. Jev with Coding Agents instead routes readers to routing, rubric scoring, and truth checks, and recommends the agent skill for API context. If your integration needs a different planner, you are not placing a decision layer; you are replacing the agent.
The same pattern shows up across the catalog: a small typed question at a seam, policy in code, and a deliberate answer to what happens when the call fails. The agent loop does not need another model in the middle. It needs fewer places where a general-purpose model has to improvise. For the broader integration picture, see Jev in Coding Agents and Decision Gates in Agent Frameworks; for threshold design, Confidence Gates in Production is the next read.
