Question 1

Will this halt my agent the first time it looks stuck?

Accepted Answer

Not by default. allowAutomaticHalt defaults to false, so a check that would resolve to HALT comes back as REPLAN with recommendedDecision set to HALT, letting you log what the policy actually concluded without anything being terminated. The README suggests starting there, reading the signals on the cases where it fires, and only flipping the flag after you have looked at real trajectories from your own agent.

Question 2

How is this different from capping steps or iterations?

Accepted Answer

It asks whether the underlying assumption changed rather than how many actions were taken. The README's example is a permission error, then try sudo, then a different path, then a different service account: four different actions, one contradicted assumption the whole time. A step counter cannot see that, so it either cuts off real investigations too early or lets a spinning agent run to the limit anyway.

Question 3

What happens when the Jev call fails or the network drops?

Accepted Answer

A Jev or network failure fails open by default with onError set to continue, returning a CONTINUE decision, reasonCode SUPERVISOR_UNAVAILABLE, confidence 0 and a sanitized error object, so the supervisor neither crashes nor blocks the agent it watches. Your API key never appears in error.message, and a failed check never advances the stagnation counter used for hysteresis, so an outage cannot be mistaken for stagnation. Set onError to throw to propagate instead.

Question 4

Can I test the policy without an API key or network calls?

Accepted Answer

Yes. npm test runs tests/*.test.ts with the Jev calls mocked and no network. npm run quickstart runs examples/quickstart.ts against the real Jev API, and npm run demo:build regenerates demo/data.json from live calls; both need TYPESAFE_API_KEY exported. npm run build produces dist plus type declarations, and npm run demo serves the demo on a local port.

Question 5

What are the six signals, and which one can mislead you?

Accepted Answer

assumptionContradicted, strategyNovelty, materialProgress, newUsefulEvidence, regression and holisticStalled. materialProgress is the trap: it is used only as a veto on a stagnation call, never as a standalone trigger, because a live agent test found it scoring 0.42 on a step whose result literally read that the deploy succeeded and /health returned 200.

Question 6

What are the four decisions, and what does each result carry?

Accepted Answer

CONTINUE for progress or new evidence with no contradiction or regression; WARN for a first stagnation signal or weak progress; REPLAN when multiple signals agree on the same rejected assumption with no material change; HALT when stagnation persists across checks or there is a confident regression. Every result also carries a stable reasonCode you can branch on, the six raw signals, a confidence, and a debugExplanation string that is development-only output and should not be parsed.

Question 7

How hard has this actually been tested?

Accepted Answer

It is v0.1 with no production deployments yet, validated against 53 hand-labeled trajectories, a 50-trajectory adversarial set aimed specifically at confusing busywork with exploration, and a live Claude tool-calling agent test gated in real time, with the data in experiments/results. The README is equally explicit about the negative space: there is no done signal, it does not replace permission systems or retry and token budgets, and it never executes or blocks a tool call.

Progressgate

About this project

Highlights

Questions about this entry

More Jev resources like this

From the Jev community