Propose support decisions a guard can check

01 · Role in the system

What Jev does here

Deterministic intake checks decide first what a person must handle - anger, repeat contact, topics with no written policy. Everything else goes to a tool-using agent that can answer only from the sender's own records, the product catalog, and written policy, with tools scoped to the sender's inbox identity in code. Jev proposes through typed questions - intent over thirteen written criteria from order status to financing, plus caution-weighted decision proposals - via the AI SDK's evaluate interface through the Vercel AI Gateway, and a mechanical guard checks each proposal before it becomes a reply. Replies pass deterministic output checks. The repository documents the full architecture and ships tests over challenge messages, stress mode, the Jev integration, privacy, the validator, and tool access.

02 · Control boundary

Where Jev sits

Deterministic intake and access scoping first; Jev proposes intent and decisions via typed criteria; a mechanical guard and output checks own what actually ships.

Code owns the loop, permissions, thresholds, validation, and side effects. Jev owns only the bounded judgments described above.

03 · Known limits

What this evidence does not prove

• Built for one shop's catalog and policy; the intent criteria and guard rules are that shop's, not a general framework.
• Calls run through the Vercel AI Gateway rather than the native endpoint.
• Escalation thresholds are the author's policy choices; no accuracy numbers are published in the README.

04 · Attribution

Public sources

This is a Community record: the project was published by a third-party community author.

• Dielldev ↗Community · github · public · checked 2026-09-25