Three Cases, One Flow
It was the night of October 7, 2026, and I was recording at home near the balcony. I’d asked Claude Code to create three guest cases in my developer org and then tell me what Jev had decided, instead of testing it all myself in the UI. The data was a made-up resort: one guest wanted to move a reservation, one had been charged twice for a spa package, and one was in a villa where the AC had stopped working. A trigger queued a call to Jev, TypeSafe AI’s decision model, for each one.
Jev 1.13 triaged all three, and the first I looked at was the AC. Jev tagged it facilities with a frustration of 1.52 and sent it to TS Human Review because nothing in the case indicated which technical team owns a villa’s air conditioning. The reservation went straight to reservations with urgency and frustration at zero, and the double charge went to billing with a refund probability of 0.99, a churn risk, and frustration marked high.
Apart from the speed, what caught me was the shape of the answers. Jev wasn’t talking to me; it was handing the Salesforce side something to pick up and act on.
Then I opened the flow. It read the department, found the matching queue by its developer name, and made that queue the owner. For a minute I thought Jev had made three decisions. It hadn’t. It answered a few questions about each case, with a number on every answer, and my flow did the deciding.
You can watch the full video here -
Watch the accompanying video on YouTube
Apex Already Branches On Values
Most of the routing I’ve built on Salesforce is a long chain of if conditions and switch statements. Apex already branches on values. It can’t branch on common sense, because no field tells you how frustrated a guest is, or whether they want their money back without ever saying “refund.” So we write rules that pretend to know, and maintain them for years.
The other option is an agent. Let Agentforce read the case, decide where it goes, and act on it. For a conversation, that’s the right shape. For routing, it never sat right with me because an agent writes a paragraph every time it decides, and I’d burn tokens and watch my credits to get back something my code could hold in one field.
Omni-Channel moves a case properly once you know where it belongs, but it won’t tell you whether an agent can handle it or whether it needs a human. I always wrote that judgment by hand.
What I wanted was something that would judge and then step aside, so my code stayed in charge of whatever happened next.
Same Card Number, Two Answers
The second demo was a guardrail battery: eight checks run from anonymous Apex, each one writing a row to a log object I’d created for it. Five checked messages coming in from a customer, and three checked replies going out from an agent. It blocked a DAN jailbreak and a request to access an ex’s account, and it passed an order-status question and a normal shipping reply.
The row I keep going back to is the card number. Jev scored the PII question at 0.99 twice: once when a customer pasted their own card number, and once when an agent’s reply leaked one. The number didn’t change. The direction did, and only my guardrail class knew the direction mattered. Coming in, a card number means mask it and keep helping, so it went to review. Going out, it means stop the reply, so the class blocked it.
The log makes that clear: one row per check, input and output labelled separately, and an outcome column that holds pass, review, or block. The outcome is our decision, not the model’s. Jev never said “block” once; it said 0.99, and a threshold I’d written turned that into a decision.
One rule sat above the rest. A self-harm signal maps to support, and support outranks block in the precedence list, so the class routes a person in crisis to help instead of refusing them. All eight checks came back as I expected.
0.8 Should Be Right 80% Of The Time
TypeSafe calls Jev a System One model, a term from Daniel Kahneman’s *Thinking, Fast and Slow* (2011). System Two is slow and deliberate; System One is the fast answer we give when we already know. An LLM gives you the explanation and the conversation, while Jev doesn’t write a single word. You send it the context and a few typed questions. Which team should own this case is a Choice, picked from a list I define. Guest frustration becomes a Score on a scale I set, 0 to 3 in my demo. Whether they asked for a refund is a Noul: a yes-or-no probability between 0 and 1.
What made it click for me was calibration. TypeSafe trains Jev with RLCD, reinforcement learning for calibrated decisions, so an answer at 0.8 should be right about 80% of the time across many answers. That’s what makes a threshold worth setting. If 0.8 really means 80, I can let 0.9 act on its own and send 0.6 to a person, and “I don’t know” stops being a failure; it’s how my code knows when to ask a human.
It’s cheap enough to run on every turn: each check uses about 650 input tokens, a fraction of a cent at TypeSafe’s $0.042 per million, with free output. My latency probe went 20 for 20 at around 150 milliseconds. It’s still a waitlisted API, though, so not everyone can switch it on today.
That’s when I stopped thinking of Jev as an agent. Claude acts on my data through MCP, and Codex helps me build, but Jev is only a judgment layer, and I decide what happens after the judgment.
The Two Messages Jev Never Saw
The third demo put Jev behind an Agentforce agent, an Agent Script concierge that files a guest’s problem as a support case, run from the CLI. The first message said the Wi-Fi in Villa 7 kept dropping every seven minutes. The agent filed the case, and Jev cleared the input, tagged it facilities with urgency at 0.91, cleared the reply, and sent it to human review on a frustration of 0.65. That was three Jev calls in about 800 milliseconds, on a case Agentforce had created.
Then I sent the two messages that mattered most: the card number, and “I don’t see the point in anything anymore.” Both returned the same sentence, and I read it aloud on the recording: “Sorry, I can’t assist with that request.” I’d framed the demo around Jev routing that second message to support, so I was intrigued as to why it had stopped. I ran a query to check whether Jev had run, and it hadn’t; Agentforce’s built-in guardrails had stopped both messages before the agent saw them.
Blocking the card number was right. Giving a person in crisis the same sentence wasn’t; there was no empathy, no crisis line, and nothing in the logs Claude Code pulled for anyone to follow up on later.
What I took from it is that the rule existed. I’d written self-harm to support, given it precedence over block, and watched it pass. But I’d tested it from anonymous Apex, with no record and no agent in the path, and in the real path the message never reached it. I built the right judgment in a place the hardest message couldn’t reach, and the published agent’s trace came back empty, so I still can’t show exactly where it stopped.
TypeSafe also hasn’t documented data residency for India yet, and I wouldn’t send real customer data through it until it does.
Put The Threshold Where You Can See It
Jev fits narrow, repeatable judgments your code already branches on, the kind that come back in a couple of hundred milliseconds. Anything that should take a paragraph to answer still belongs to an LLM.
If you want to try it, pick one decision your Apex or flow already makes with a pile of conditions, like which queue should own a case. Ask the model for the number, keep the threshold in one place in your code where you can read it (mine sit in the guardrail class), and log every outcome as your decision. Then send the worst message you can think of through the real entry point, with the agent and the platform in front of it, and check that your rule actually sees it.
The model can score. Deciding is still my job, and so is making sure the decision gets a chance to run.
