Jev and AI Checkpoints: Using Decision Models to Wrangle Agent Work
AI is reaching an awkward point. We barely trust our agents today, and yet models are getting capable enough that we increasingly want to let them just do the work. If they are smarter than us, who are we to tell them how to work, right? Let them solve the problem and figure out what it takes to get there.
But that should leave you uneasy. We can’t just hand over the work and hope for the best. Is it too much to ask that we can still check their work and, just as importantly, learn something about what happened along the way?
There are signs that a gap is forming between model reasoning capabilities and us mere humans. OpenAI recently reported that GPT-6 Astra’s written reasoning was harder to monitor than GPT-5.6 Sol’s, including a greater ability to accomplish work without verbalizing all of its reasoning. It’s one example of a broader problem. As models get better, watching their execution step by step becomes a weaker way to understand and govern their work.
We’ve been building ThruWire in anticipation of this exact challenge. Instead of prescribing everything an agent does, ThruWire defines checkpoints in the work: durable states the work needs to reach, along with the artifacts, provenance, evidence, and other receipts it has to leave behind. Between checkpoints, the agent can "cook". At the checkpoint, it has to show its work.
Then Jev showed up, and it fit this architecture almost perfectly. Checkpoints already give us a place to inspect the work before it moves forward. Jev lets us add fast semantic processing right at that boundary. It’s quick enough to understand something about the work, make decisions about it, record what we learn, and feed those observations back into what happens next without slowing down the agent.
This is a look at how we got here, what Jev changes about the checkpoint, and what becomes possible once the checkpoint can understand the work.
How We Try to Keep Agents on Track Today
We already have a growing toolbox for keeping agents under control. Before production, evals and simulations test whether they behave correctly across known and adversarial tasks. During execution, sandboxes, permissions, approval gates, and deterministic checks constrain what they can do. Anthropic’s Claude Code sandbox is a good example of giving an agent freedom inside a deliberately constrained environment.
We can also watch and evaluate the execution. Tracing systems like LangSmith record what happened inside the run, while deterministic evaluators, LLM-as-a-judge, and human review decide whether particular behavior or output looks right. These checks can happen offline or against production traces.
Or we can reduce the problem by giving the agent less freedom in the first place. Workflows and orchestration encode more of the path ourselves: chains, routers, approval nodes, evaluator loops, and other predefined transitions. Anthropic draws this line explicitly between workflows that follow predefined code paths and agents that dynamically direct their own process.
All of these approaches have a place, and most serious systems will combine them. But we’re usually either watching the execution, checking it, or constraining it. Give the agent too much unchecked freedom and important decisions can disappear inside the run. Encode too much ourselves and we start giving up the capability we wanted from the agent in the first place.
Checkpoint But Don’t Smother
ThruWire is built around a separation between the work and whatever happens to be executing it. It’s a simple proposition to the agent: do whatever you want, however you want, as long as you can prove these X number of things happened along the way.
The execution can be Claude or Codex, a custom agent, several agents working together in a software factory, a deterministic process, a human, or some combination of them. ThruWire doesn’t need to own the agent loop or prescribe every tool call. Instead, it models the breadcrumbs that need to exist and the checkpoints through which the work progresses, giving the human enough visibility to stay comfortable and the process enough structure to stay on the rails.
A checkpoint defines a state the work needs to reach without defining exactly how the worker gets there. A research checkpoint might require a set of claims grounded in evidence. A software checkpoint might require an implementation tied back to its requirements with verification attached. A customer workflow might require an extracted requirement connected to the exact conversation from which it was derived.
Between those checkpoints, the agent can cook. The requirement is to present ThruWire with the right-shaped artifacts at the right time, in a form it can validate and trust. ThruWire does this with a combination of goal-defining blocks, provable relationships between artifacts with attestation, and server-side schema enforcement and validation. Put together, it’s not only a receipt system but a self-describing obstacle course for the agent.
When a worker reaches a checkpoint, it publishes a candidate artifact with stable identity and relationships to the exact upstream artifacts it used. ThruWire validates the artifact and those relationships before accepting it, returning validation feedback to the worker when something is wrong and preserving the history of what happened along the way.
The result is a different kind of control. We don’t need to micromanage the agent or tell it how to clear every obstacle. Instead, ThruWire lets us define a clear contract for the work and leave the execution up to the agent.
Jev Adds Semantic Processing to the Checkpoint
Jev arrived at just the right time for this architecture. ThruWire checkpoints already gave us a strong contract around the work. We knew what artifact was supposed to exist, which upstream work produced it, what evidence came with it, and whether the worker had satisfied the structural requirements for moving forward.
What we didn’t have was a true decision model that couldco evaluate every artifact against the fuzzier parts of that contract without turning the checkpoint into another expensive LLM step.
Jev fits naturally into that job. Now we can establish that an artifact comes from the right upstream work and carries the required evidence, while also asking to what degree that evidence supports the claim, whether an implementation satisfies its requirement, or whether something extracted from a conversation really represents a requirement.
Importantly, this lets the checkpoint model express gray areas without giving up the contract. Before, the semantics around advancing the work were mostly absolute: this artifact exists, this relationship is valid, this evidence is present. Now the model can also say that an artifact should advance only if there is sufficient probability that the evidence supports the claim, or that an implementation satisfies its requirement.
Jev is particularly well suited to this because it returns typed semantic decisions that ThruWire can attach policy to. And that policy doesn’t have to be limited to whether the artifact passes or fails.
Checkpoints Generate Useful Data
Validation and interpretation are close cousins. Once a checkpoint can semantically validate work and reject it when necessary, it can just as easily ask what else is true about that work without making the answer part of the gate.
That makes checkpoints useful for much more than validation. Jev can characterize the work as it passes through, such as whether a customer sounds confused, whether an objection is unresolved, whether an implementation appears to be drifting, or whether something deserves human attention. Some of those results can become policy, some can steer the agent, and others can simply become useful data attached to the model of work.
ThruWire already had a powerful way to expose that data to humans. ThruWire “renderers” can turn the underlying artifacts, relationships, and evidence into purpose-built applications that users can interact with like apps rather than forcing them to inspect a pile of JSON. Jev gives those applications a whole new source of data.
Every checkpoint can now generate new data about the work while the work is passing through. The same semantic processing we use to govern whether work moves forward can also help a human, or another agent, understand what is happening. The more work that passes through checkpoints, the richer that data becomes.
Instead of reconstructing what happened from agent traces after the fact, we can accumulate a semantic picture of the work as it happens. As models get smarter and their execution gets harder for us to follow, I think that becomes increasingly valuable.
We Tried It on a Granola Meeting
A Granola meeting turned out to be a surprisingly good way to put this architecture together.
We were already using Granola and ThruWire to automate work coming out of our meetings. We took one meeting and represented it as a series of three checkpoints: the source meeting, conversational sections derived from it, and individual conversation moments derived from those sections.
For this first experiment, we used a Jev-enabled classifier in ThruWire to explore what happens when those moments also accumulate semantic observations. Does this moment express a positive reaction? Is there material friction? Does it show confusion or a breakdown in shared understanding?
Each moment gives us a few observations about one small piece of the conversation. Across hundreds of moments, we now have a new dataset about how the entire conversation unfolded. ThruWire can render that data as an interactive app where we can explore positivity, negativity, and confusion, then jump all the way back to the source behind any signal.
And this is just the starting point. There are a lot more things to try now that checkpoints can generate this kind of semantic data as the work moves through them.
The Real Work Is the Connective Tissue
The more I work with Jev, the more convinced I am that the interesting architecture isn’t System 1 or System 2 on its own. It’s everything we build between them. We now have frontier models capable of doing increasingly open-ended work and decision models capable of making fast semantic judgments around that work. Neither tells us how to put the whole system together.
The checkpoints, contracts, artifacts, context, policies, feedback loops, and other deterministic connective tissue are what let System 1 and System 2 work together. I suspect a lot of the hard engineering in the next generation of AI systems happens right there.