Splitting a support agent's decisions from its writing with Jev
An article uses a support-agent trace to show that 37 of 44 model calls are decisions and 7 are writes, and suggests returning typed judgments from Jev while leaving the writing to another model.
YOUR AI AGENT IS PAYING A WRITER TO RUN A F*CKING SWITCHBOARD. Route the ticket. Check urgency. Pick the next handler. Decide whether a human should look. Then, finally, write the reply. The earlier steps need a judgment your code can use. The last one needs a writer. Sending all of them to the same model hides that split. The article below makes it visible with an illustrative support-agent trace: 44 model calls, 37 decisions, 7 writes. It's an accounting example, not production telemetry or a benchmark for your agent. But it gives you a useful first move: log one complete run and tag every call WRITE or DECIDE before changing the stack. Jev is built for the DECIDE side. Give it the current state and define the answer shape: → Choice: billing / technical / sales / shipping → Noul: how likely is “this is urgent” to be true? → Score: where does the tone sit on your ordered rubric? It returns typed judgments and probabilities instead of generating a reply. The writing model keeps the explanation, plan or draft. Code keeps the arithmetic, state, permissions and actions. https://docs.typesafe.ai/introduction Here's a concrete place to try it: jev-demo-router. The community demo asks three questions about each support ticket in one call: department, urgency and customer tone. Code handles dispatch. A department result below its configured confidence cutoff goes to a human queue. https://github.com/Zafer-Liu/jev-demo-router Python 3.10+ and a TypeSafe API key required: git clone https://github.com/Zafer-Liu/jev-demo-router.git cd jev-demo-router pip install flask typesafe-sdk requests Copy .env.example to .env and set TYPESAFE_API_KEY. python http://app.py Open http://127.0.0.1:8765. API calls are billed; the repo's sample tickets are synthetic. The part worth copying is the boundary. Ask the independent questions about the same ticket together, let code combine the answers, and keep an explicit review path. A probability is a signal to evaluate, not permission to do anything. The demo's cutoff is a starting point; test on your own labeled cases, including the awkward ones. Don't migrate the whole agent in one evening. Count the calls, find one repeated judgment, replay old cases and inspect the mistakes. Keep the writing with the writer and the effects in code. The attached animation illustrates that architecture; it isn't a live API run.
This post quotes another post: x.com/0xcodio/status/2104195432209387524