Beyond Extraction: Rethinking Enterprise AI with Graphs, Jev, and Sentinel

The shape of the problem

Enterprise AI spend hit $37 billion in 2025 — up from $11.5 billion in 2024, a 3.2x jump in a single year (Menlo Ventures, 2025: The State of Generative AI in the Enterprise, surveying 495 U.S. enterprise AI decision-makers). This isn’t a market settling down. It’s one still compounding.

The chart below is older — a 2024 enterprise adoption breakdown — and in an industry moving this fast, we’d treat a year-old chart as illustrative of a pattern, not as current fact.

What’s held up, though, is the pattern itself. Support chatbots and data extraction alone account for 58% of the use cases shown here, and every survey we’ve looked at since — old or new, different methodology, different year — puts some combination of customer-support automation and document/data processing among the top two or three enterprise LLM use cases. Menlo’s 2025 numbers still show customer-success work as a real, growing line item within a $7.3B departmental-AI spend category, deployed through exactly the pattern this post is about.

So the question isn’t whether this category matters. It’s what these systems actually do once you look past the extraction step.

The default playbook — and where it quietly stops

The standard approach to this category of work looks the same almost everywhere: point a frontier model — GPT-5, or a privately hosted model if you care about cost and data residency — at the inbound email, document, or ticket, and have it extract the relevant fields as structured JSON. We tested this directly: GPT-5.5 hit 96% intent-classification accuracy on a 100-email crew-staffing benchmark; our own privately hosted Qwen3.8-27B hit 100% on the same corpus, at roughly 9x the speed.

Those are good numbers. They’re also measuring the easy half of the job.

A classified email and a cleanly extracted JSON blob are not the same thing as an updated system of record. Something still has to take that output and find the one real record — among dozens, hundreds, or thousands — that it actually refers to. The benchmark above never has to do that: it’s graded against ground truth that already has the right record ID baked in as the answer key. In production, that step doesn’t disappear. It just moves somewhere unmeasured:

• A person does it. The “AI” becomes a drafting aid; a human still does the lookup that was the expensive part of the job in the first place.
• A script does naive matching on the extracted text, and breaks exactly where people do too: two records named “DG Strategic Partner Summit,” one of them a literal copy with a different PO number.
• Nobody builds it, and the system quietly stays a classifier forever, one integration short of actually automating anything.

The label is real. It’s just not the finish line.

Reimagining the pipeline

We built a working alternative on a real 100-message crew-staffing email corpus, structured around four pieces instead of one model call:

• A graph as structural memory. Every event, shift, and skill the business already knows about lives in Neo4j, seeded upfront — because a CRM’s roster of known events is master data, not something each inbound email should have to re-derive.
• Jev for the actual decisions. TypeSafe’s Jev answers narrow, typed questions — does this message refer to this candidate event? which of these known skills does it request? — by selecting among graph-enumerated options. Zero free-text generation anywhere in the autonomous path: nothing to hallucinate, because nothing is generated.
• Sentinel for privacy. Every Jev call is redacted before it leaves the building — phone numbers, SSNs, emails, credit cards. We verified this doesn’t cost accuracy: routing the full pipeline through Sentinel produced results identical to the unprotected baseline.
• A privately hosted model, demoted to one job. When the evidence genuinely doesn’t support a confident answer, the pipeline escalates instead of guessing — and a privately hosted open-weight model drafts a plain-language suggestion for the human reviewer. It never touches the autonomous decision, and because it’s already private infrastructure, it never needs Sentinel in front of it either.

The structural near-duplicate check in the decision policy is worth calling out specifically: a message’s own confidence score can be high and still be wrong when two real records are near-identical. The fix isn’t a smarter per-message judgment — it’s checking whether the candidate record itself has a lookalike anywhere in the graph, independent of what any one message’s score says, and refusing to guess when it does.

What it actually gets you

Read the bottom row carefully, because the headline number is the wrong one to fixate on. 61% is lower than GPT-5.5’s 96% or Qwen’s 100% — and that’s not a regression. Those two numbers are graded on whether the extracted text looks right. They never have to find which of roughly 70 real existing records a message refers to, so they can’t get that part wrong, and nothing in their evaluation would catch it if they did.

Jev + Graph is graded on the harder, actually-automating-the-job question, and its answer when the evidence is thin is to ask a human rather than guess. That’s why its wrong rate is the only one of the three that is genuinely zero, not just low — confirmed across multiple full runs of the eval, including with Sentinel redacting every Jev call along the way.

And it’s faster: a median 5.1 seconds end-to-end (blocking plus however many Jev judgments one message needed), against 11.1 seconds for our own privately hosted extractor and 99 seconds for GPT-5.5. Put plainly: roughly two-thirds of messages need zero manual handling at all, and the other third gets a human-reviewed, AI-assisted decision instead of today’s fully manual process — with a wrong-record rate that isn’t low, it’s zero.

What review actually looks like

The 39% that escalate don’t land as a raw email and a shrug. Each one shows the reviewer exactly why it was flagged, the real candidate records it’s weighing, and a plain-language suggestion from a privately hosted open-weight model about what would settle it.

In the example above, the system found a moderate match to an existing event at the same venue and client, but a competing signal (a new event name, no PO on file yet) was strong enough that it declined to guess either way. The suggestion doesn’t decide anything — it just does the part of the lookup a human would otherwise do by hand, and names the one fact (the PO number) that would resolve it either direction. Whatever the reviewer picks gets written back into the same graph, in the same shape as an autonomous resolution — not logged somewhere and hoped for.

The actual lesson

Go back to that opening number: support automation and data extraction aren’t a niche slice of enterprise AI spend, they’re the biggest one, however you cut the survey. Almost all of that spend is being deployed as extraction — a model reads something and produces a label or a field. That’s a real, measurable improvement over doing it by hand. It is not the same thing as finishing the job.

The gap between “extracted the right fields” and “updated the right record” is exactly the gap a human still closes today, mostly invisibly, mostly manually. Closing it doesn’t require a bigger model. It requires treating the business’s own structural memory — who exists, what’s already on file — as a first-class part of the system, using a typed decision model for the narrow judgments that actually need one, protecting what leaves the building, and reserving the generative model for the one place a human was always going to be in the loop anyway.

We built this against one workflow. The pattern — graph, typed judgments, redaction, human-assisted escalation — isn’t specific to crew-staffing emails, or to Jev. It’s specific to any task shaped like this message needs to become the right update to the right record, which is to say: a very large share of that $37 billion.