Improving shared understanding for agents using Jev
Giving every agent the same data does not mean they will reach the same conclusion. I built a shared a shared state using GPT-5.6 Sol and Jev, then tested whether it improved the agent system
AI disclaimer: I worked with codex and GPT-sol 5.6 (high) on this(through Bedrock!). The problem statement, research, design and post are all me.
There is one thing any agent needs to be truly useful, data. Documents, chat messages, tickets, source code, and business systems are indexed so an agent can search them when it needs context. That solves access, but I wanted to look into a different angle of the data: what happens when several agents find the same evidence and interpret it differently?(spoiler: happens a lot!)
Retrieval gives an agent context, but the agent still has to work out what that context means. In this post and sample repo I used an incident-response agent example to explore if Jev can benefit this use case.
Jev is a recently released AI decision model by TypeSafe AI, that evaluates input data and returns fast, probabilistic structured answers, it's meant to make decision evaluation faster and easier but mostly talks "computer" not "human".
Sample code in this repo: Agent-with-Jev aws-samples
Sample code in this repo: Agent-with-Jev aws-samples
What I set out to build was: a general-purpose model extracts what new evidence says, Jev judges how that evidence changes a small shared state, and application code decides whether to accept the change. I also wanted to test whether this hybrid design improved my system at all(latency, cost, consistency)
What I built and how it works
The specific incident response agent system has a goal to provide a consistent, evidence-based view of an incident as new information arrives. Alarms, messages, and tickets flow through GPT-5.6 Sol, Jev, and Python rules to update shared state, which the agent uses to explain the current status, confirmed cause, investigation history, and remaining uncertainty. The full PoC flow is shown in figure 1.
I built two versions so that I could test whether Jev improved the system rather than assuming it would automatically improve it.
The first version used GPT-5.6 Sol on Amazon Bedrock for the whole run. It read one record, the current incident state, extracted the relevant facts, and returned a structured assessment.
The second version divided that work. GPT-5.6 Sol still read the open-ended text, but it only extracted grounded facts such as the affected service, related deployment, short summary, likely cause, and any explicit root-cause option. I then passed those facts, the original evidence, and the current incident state to Jev.
How I used Jev
Before I could test either version, I defined five specific judgments for Jev to make about each new piece of incident evidence:
| Judgment | Allowed outputs |
|---|---|
| What kind of update is this? | observation, hypothesis, confirmed cause, mitigation, resolution |
| What is the current incident status? | open, investigating, mitigating, resolved |
| How does this relate to the current possible cause? | supports, contradicts, unrelated, insufficient |
| What is the root-cause status? | unknown, candidate, confirmed, rejected |
| Does this replace the current state? | true, false |
To use Jev, I used TypeSafe's
Choice primitive for questions with one allowed category and Noul for a yes-or-no probability. The following shortened example shows the pattern:1
2
3
4
5
6
7
8
9
10
11
12
13
14
questions = {
"update_type": Choice(
criteria={
"observation": "A symptom without a causal claim.",
"hypothesis": "A possible but unconfirmed cause.",
"confirmed_cause": "Evidence confirms or rejects a cause.",
"mitigation": "An action intended to reduce impact.",
"resolution": "Evidence says the incident has recovered.",
}
),
"supersedes_previous": Noul(
instructions="Does this evidence replace the active claim?"
),
}After Jev returned those judgments, ordinary Python code decided whether and how to update the stored state. DynamoDB stored the information, and the current incident record. A Strands agent accessed that state through tools.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
state = current.model_copy(deep=True)
if assessment.needs_review:
state.pending_review_ids.append(claim_id)
return Resolution(
state=state,
resolution="pending_review",
applied=False,
)
state.incident_status = assessment.incident_status
if assessment.root_cause_status is RootCauseStatus.CONFIRMED:
confirmed = (
assessment.root_cause_claim
or assessment.candidate_hypothesis
or state.confirmed_root_cause
)
state.confirmed_root_cause = confirmed
state.current_hypothesis = confirmed
return Resolution(state=state, resolution="active", applied=True)
Figure 2 separates the flow that updates shared state from the flow that answers an agent question.
Figure 2 – Jev runs when new evidence may change the shared state. Normal agent questions reuse the accepted state.
Jev runs when new evidence may change the shared understanding. During a normal agent question, the agent reads the accepted state without judging it again. If the agent discovers new evidence during its work, that evidence returns to the update path, Jev evaluates it, and the agent can then read the revised state.
Did Jev improve the system?
With the shared layer in place, the agent spent less of each run rebuilding understanding from raw messages. Different agents can read the same current state, while people can still inspect the evidence behind it. The architecture worked with and without Jev, so the remaining question was whether the hybrid version could provide improvements.
To see whether Jev improved the system, I ran each incident example five times using both versions, the results are in the table 2 below.
| Version | Repeated runs agreed | Average time | Estimated cost per run |
|---|---|---|---|
| GPT-5.6 Sol on Bedrock | 77% | 3.25 seconds | $0.00656 |
| GPT-5.6 Sol + Jev | 93% | 2.66 seconds | $0.00428 |
In this small test, adding Jev made the results more consistent, reduced response time by 18%, and lowered estimated cost by 35%. GPT-5.6 Sol only had to extract the facts, while Jev handled the fixed classification choices.
Jev improved the step before the agent had to reason: turning raw evidence into clear, repeatable categories. It also made those decisions easier to inspect because each classification had a name and a fixed set of choices. If I wanted to change what counted as a confirmed cause or a resolution, I could update that specific judgment instead of expanding one large prompt or skill that handled the whole incident.
The metrics measured repeatability(consistency), not correctness. A system can consistently return the wrong answer, and these six examples were not an evaluation set. The results were enough to justify testing the approach further, but not to make a general assessment about Jev’s accuracy or suitability for all agent use cases.
What this means for your agents
This pattern gives agents a simpler job. Instead of repeatedly interpreting raw messages, they reason over a clear, current view of what is known, what has changed, and what remains uncertain.
It works best when information changes over time or several agents need the same answer. Start with one question, such as “What is the likely cause of this incident?” or “Has this customer commitment been approved?”, and define the few states needed to answer it.
Keep the original evidence, route uncertain evidence for review, and use application code to control which judgements become accepted state. If this produces more consistent and verifiable agent answers, consider expanding the shared state components one concept at a time.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article