Apixly’s Jev Harness turns Jev into a next-step selector inside a Python-owned workflow. The useful part is not another promise of cheap agents: it is the boundary between choosing an action, authorizing it and proving that it worked.

I inspected the README, native inference adapter, tool/parameter binding, execution loop, verifier and evidence ledger at commit a01e000cee72b784f006137b2e47ea1a5652b270. I did not run this repository or reproduce its live Jev experiments. This is implementation review, not a security audit.

Tools and arguments are menus, not generated code

  • The host supplies observations, tool contracts and admissible parameter values; Jev selects IDs that Python binds to real values.
  • Dependent arguments are selected after their parents; a single available value binds without another inference call.
  • The native adapter actually dispatches typed decision requests through Jev Filter—not merely a chat prompt mentioning Jev.
  • Missing facts, unresolved selections and context-budget overflow stop for review rather than silently guessing or dropping constraints.

Completion belongs to the program

  • An independent callback checks observed state before accepting completion, including when the model chooses the “done” exit.
  • Irreversible actions require explicit host authorization; the runtime reobserves state before executing to catch stale choices.
  • The same observation, action and bound parameters cannot execute twice in one run.
  • Intent is journaled before effects; an execution exception becomes uncertain, not an invitation to repeat the action.

Read the evidence narrowly

  • Apixly reports a historical synthetic browser-form success in four tool executions, using Jev 1.13.0; I did not reproduce it.
  • Its reported live next-tool comparison admitted the expected tool in 12 of 12 probes in each arm, but deliberately stopped before execution. That is not full-task acceptance or a measured correctness gain.
  • Later offline regression reports test protocol behavior with scripted answers or HTTP mocks—not Jev’s semantic accuracy.
  • Native desktop completion remains unverified, and the project makes no universal savings or success claim.

The host still owns the hard parts

Python callbacks are trusted code, not sandboxed. Time budgets are checked between callbacks, so tools must bound their own I/O. Authorization also depends on correctly marking effects as irreversible; a typed menu cannot repair a bad tool contract.

There is no cross-run resume or exactly-once guarantee, and provider retries are distinct from repeating task actions. Typed output is not a correct decision; a verified final state is only as meaningful as the verifier the application supplies.