Using System One models and Oracle AI Database to help agents choose relevant evidence and decide what to retain in long-term memory.

The companion notebook runs every example in this article against Oracle AI Database 26ai and Jev: Oracle Jev Memory

Key takeaways

  • Agent memory needs decisions about what to retrieve, what enters context, and what becomes long-term memory. Jev can assess these choices with typed questions while application code controls the queries and applies policy.
  • Oracle AI Database keeps memory connected to its source and version, with scope and validity information available during retrieval. Database-enforced tenant isolation limits which records can reach the assessment service or reasoning model.
  • A valid output type can still contain an incorrect judgment. In the notebook, repeated assessments of the same candidate landed on both sides of the 0.90 support threshold. Calibrate thresholds on your own labeled cases before letting them decide unattended.

An agent remembers that a customer received a refund last month. When that customer asks for another one, the agent retrieves the previous conversation and recommends the same resolution. The memory is accurate. The recommendation could still be wrong. Last month’s refund might have been a one-time exception, and the approval that made it possible might apply only to that transaction.

This is the part of agent memory I find most interesting (and frustrating). Storing a fact gives the system something to retrieve. Using it requires a decision about what that fact means for the work happening now. An agent can make a mistake while choosing its search, while assembling its context, or while deciding that something it just learned deserves to survive the conversation.

In an article I wrote about building an AI agent harness, I explained why agents need a harness to control their tools and operating context. Memory needs that same attention. The harness decides which evidence the agent can access and how to respond when that evidence is incomplete. Every additional judgment costs something, though. Asking a reasoning model to inspect every possible memory can consume much of the time and money the memory system was supposed to save.

TypeSafe AI introduced Jev as the first model in a new class it calls System One, built for fast, typed assessments. Pair bounded assessments with a memory system backed by Oracle AI Database, and you can evaluate more of those decisions before sending evidence to the reasoning model. I tested the examples below against Oracle AI Database 26ai Free and Jev using synthetic refund records. In one test, a prior refund scored 1.62 out of 2 for relevance while being classified as history. It helped explain the earlier decision without authorizing another refund. These examples show how the components fit together; the thresholds still need evaluation on your own workload.

Vertical flow diagram from request through query selection, retrieval, context selection, reasoning, promotion, and long-term memory. Yellow boxes mark Jev’s decisions; teal boxes mark database retrieval and memory; white boxes mark the application and reasoning model.
Figure 1: Cheap typed assessments sit at each gate. The harness applies the policy.

Jev returns typed assessments

TypeSafe calls Jev a System One model. You supply text describing the state to evaluate, along with typed questions. It returns structured answers without generating prose.

PrimitiveReturnsMemory example
NoulYes-or-no probabilityIs this claim supported by its source?
ChoiceSelected option, probability distribution, and confidenceUse this record as current evidence, history, or neither?
ScoreRubric score, probability distribution, and confidenceHow relevant is this record to the request?

Questions execute independently against shared state, and TypeSafe says adding questions has little effect on response time. A single request can check whether a proposed memory is supported and whether its scope matches the evidence. TypeSafe documents these primitives and their execution model.

The company’s launch announcement lists $0.042 per million input tokens, free outputs, and end-to-end response times of 70 to 500 milliseconds. At that published input rate, a 3,000-token assessment would cost $0.000126. If each call contains 20 questions and 3,000 total input tokens, 10,000 calls would evaluate 200,000 questions for about $1.26. These are vendor figures, and the timing needs verification on your workload. But they’re enough to justify testing checks you previously considered too expensive to run on every turn.

I wouldn’t give a decision model a broad instruction to manage memory. I’d give it specific questions and let the harness apply policy to the answers. Whether an account ID matches is an exact check. Whether a prior exception applies to a new request may require semantic judgment. Investigating conflicting approvals may require the reasoning agent or a person. Each operation needs the evidence appropriate to its job.

Oracle AI Database keeps memory tied to its evidence

Oracle AI Database gives this design a persistent foundation. Its hybrid search interface supports keyword and vector retrieval, with options for combining and scoring results. That lets an application search for semantically related conversations while retaining the precision needed for policy identifiers and product names. Relational queries can retrieve the account facts that determine which policy applies.

For the refund example, I’d store each memory with its source reference and version, the customer scope, and its status. An exception would retain a link to the approval that authorized it. A replacement policy would point back to the version it superseded. These are application records and relationships I’d implement in Oracle AI Database. Keeping them alongside searchable memory lets the application assemble evidence without reconstructing those relationships from prose every time.

Diagram of a VPD tenant boundary containing a memory record with content, vector embedding, source event, version, scope, status, and validity dates. It links to a prior refund exception and current refund policy, each leading to an approval or superseded policy.
Figure 2: Keeping these links in the database means the application never reconstructs them from prose.

Access belongs in that data path. Oracle’s Virtual Private Database supports policies that restrict rows using application context. The application must configure and test those policies, bind verified identity to the database session, and use appropriately restricted credentials. A model-supplied customer ID can’t establish authorization. Only evidence permitted for the request and the assessment service should leave the retrieval boundary.

Choose the query before retrieving the memory

Start with what to query for. The customer says, “Can you do what you did last time?” Searching that sentence alone leaves too much unspecified. The application already knows the authenticated account and the current conversation. It can offer Jev defined retrieval routes such as prior account resolutions, current refund policy, or clarification required. A separate assessment can indicate whether the request refers to an earlier interaction.

The request looks like this with TypeSafe’s Python SDK. These excerpts use the companion notebook’s initialized demo: client = demo.client, cur = demo.cur, and scope = demo.scope. The notebook sets the tenant context before retrieval. The SDK question types come from from typesafe_sdk import Choice, Noul, Score.

request = "Can you do what you did last time?"

response = client.system_one(
    model="jev-1.13.0",
    state={"request": request},
)

answer = response.answers["route"]
route = answer.choice if answer.confidence >= 0.60 else "clarify"

The test returned prior_resolution with confidence 0.91. The application maps that answer to a query it owns. The following excerpt uses a fixed Acme search string to demonstrate the vector candidate branch. Jev selects the route; application code supplies the search text. The full notebook also generates an Oracle Text candidate pool and combines the ranks with reciprocal rank fusion.

mandatory = demo.mandatory_context()  # Required rules and preferences.
candidates = []
if route == "prior_resolution":
    cur.execute("""
        SELECT id, version, source_event_id, content,
               VECTOR_DISTANCE(embedding,
                 VECTOR_EMBEDDING(ALL_MINILM_L12_V2
                   USING :query AS DATA), COSINE) AS distance
          FROM jev_entity_memory
         WHERE tenant_id = SYS_CONTEXT('jev_memory_ctx', 'tenant_id')
           AND (user_id IS NULL OR user_id = :user_id)
           AND (agent_id IS NULL OR agent_id = :agent_id)
           AND (thread_id IS NULL OR thread_id = :thread_id)
           AND deleted_at IS NULL
           AND valid_from <= SYS_EXTRACT_UTC(SYSTIMESTAMP)
           AND (valid_until IS NULL
                OR valid_until > SYS_EXTRACT_UTC(SYSTIMESTAMP))
         ORDER BY distance, id
         FETCH FIRST 5 ROWS ONLY
    """, query="Acme previous refund exception transaction approval",
         **scope.binds())
    names = [column[0].lower() for column in cur.description]
    candidates = [dict(zip(names, row)) for row in cur.fetchall()]

ALL_MINILM_L12_V2 is the embedding model the notebook loads into the connected schema when it’s missing. Oracle generates the query embedding and compares it with embeddings stored beside the canonical facts. The notebook supplies a synthetic scope; a deployed service must derive these values from verified identity. VPD enforces the tenant predicate even if a query omits it; the explicit predicate here makes that boundary visible. Each returned row retains its version and source event for the next assessment.

Some retrieval requirements should be unconditional. If the task could recommend a refund, my policy would require the applicable refund rules even when a route assessment favors conversation history. A confident classification shouldn’t suppress mandatory evidence. Missing evidence should produce a bounded follow-up query or a request for clarification, with a limit on retrieval attempts.

Flow diagram showing evidence-route selection, mandatory refund context, prior resolution, current policy, clarification, vector search, Oracle Text, reciprocal rank fusion, and a final evidence pool.
Figure 3: Jev chooses the route. The application owns the queries.

Select context that applies to the task

The next decision is what enters the reasoning model’s context. A retrieved result deserves consideration. The application still has to decide how much attention to give it. A prior refund can rank highly because it closely matches the request while offering very little support for another refund.

The retrieved row becomes part of the state sent to Jev. This example evaluates one candidate so the questions are easy to see. The full notebook asks the same questions for every candidate in a single call.

response = client.system_one(
    model="jev-1.13.0",
    state={"request": request, "candidate": candidates[0],
           "guidelines": demo.guideline},
    questions={
        "use": Choice(
            instructions="How may `candidate.content` be used for `request`, given `guidelines`? Historical exceptions do not authorize a new transaction.",
            criteria={
                "applicable": "Directly applicable current evidence for this task.",
                "history": "Relevant history only; must preserve its original transaction or scope limitation.",
                "irrelevant": "Does not help this request.",
                "insufficient": "Not enough evidence to determine how this applies.",
            },
        ),
        "relevance": Score(
            instructions="How directly does `candidate.content` help answer `request`?",
            criteria=["Unrelated to the request.", "Provides useful background.", "Directly addresses the request."],
        ),
    },
)
print(response.model_dump_json(indent=2))

For the prior refund, the response included these fields:

{
  "use": {"choice": "history", "confidence": 0.99},
  "relevance": {"score": 1.62, "confidence": 0.43}
}

The relevance scale runs from 0 to 2. This memory scored near the top while remaining historical evidence. Those values are observed test output, and a later call can return different values.

The application should retain those assessments separately. A high relevance score can’t compensate for missing authority. A useful historical exception can enter context with its limitation attached: “Previous refund approved for transaction X only.” A current policy can enter as governing evidence. A near-duplicate conversation can stay out to preserve the token budget.

Keep the source IDs and versions attached to that evidence. If a generative model compresses a passage, preserve the link to the original and check consequential claims against it. Jev’s typed interface can assess a supplied summary; producing the summary requires another component. The context builder should reserve room for mandatory evidence before filling remaining space with optional history.

An unresolved contradiction also deserves space. If the approval record and current policy disagree, silently selecting the higher-scoring passage would hide the problem. The harness can retrieve the missing authority or route the case for review. This makes context selection a policy the team can inspect and change.

Three candidates—prior refund, current policy v3, and a similar thread—are assessed by Jev. The context window reserves mandatory rules first, includes policy and limited history, excludes the similar thread, and flags a contradiction for review.
Figure 4: Relevance and authority stay separate signals. A high relevance score never substitutes for missing authority.

Promotion needs a stricter standard

Promotion into long-term memory needs a stricter standard because a mistake can affect later conversations. Suppose the agent finishes this exchange and proposes remembering, “This customer is eligible for refunds after the standard window.” The conversation might establish only that someone approved one exception. Saving the broader claim would turn a local observation into recurring bad advice.

Before promotion, the notebook’s prepare_promotion helper retrieves the source event and related current facts from Oracle AI Database. It checks for a missing source or an exact duplicate before paying for an assessment. For a candidate that passes those checks, prepared["state"] contains the proposed claim alongside that evidence:

candidate = "Acme is always eligible for refunds after the standard window."
source_id = demo.source_id  # Seeded approval for TX-100.
prepared = demo.prepare_promotion(candidate, source_id)

eligible = False
if "decision" in prepared:
    print(prepared["decision"])  # Missing source or exact duplicate; skip Jev.
else:
    response = client.system_one(
        model="jev-1.13.0",
        state=prepared["state"],  # Candidate plus its source and current facts.
        questions={
            "supported": Noul(instructions=
                "Is every claim in `candidate` explicitly supported by `source.content`?"),
            "scope_fits": Noul(instructions=
                "Does `candidate` preserve the customer, transaction, and one-time limits in `source.content`?"),
            "conflict": Noul(instructions=
                "Does `candidate` contradict `guideline` or the current facts in `existing`?"),
        },
    )
    answers = response.answers
    eligible = (answers["supported"].noul >= 0.90
                and answers["scope_fits"].noul >= 0.90
                and answers["conflict"].noul <= 0.10)

The broad claim, “Acme is always eligible for refunds after the standard window,” failed this check. eligible is an application decision based on separate assessments. It still has to pass the transactional write checks before becoming durable memory. Semantic deduplication would need another assessment; the notebook’s exact hash check only catches identical content.

The long-term record should preserve the evidence supporting its admission. I’d store the assessment results separately from the memory text, along with the question version and the policy version that interpreted them. Promotion would be an application-controlled transaction that writes the approved record and its source links together. A version check before commit would prevent approval based on a source that changed during assessment.

Conversation persistence and promotion should remain separate operations. Oracle’s LangGraph persistence integration provides OracleSaver for checkpoints and OracleStore for durable application data.  A saved conversation doesn’t automatically become approved guidance.

Those source relationships also make reassessment practical. When a policy changes, the application can query for memories supported by the old version and queue them for review. Until reassessed, affected guidance can be excluded from current recommendations while remaining available as history. A rejected candidate can be reconsidered if new corroborating evidence arrives. Cheap assessments become more useful when the database can identify exactly which records need them.

Promotion flow compares a broad claim with a narrow observation, runs code checks, applies support, scope, and conflict thresholds, rejects the broad claim, writes the eligible observation with source links and versions, and queues it for review if the source changes.
Figure 5: A mistake here reaches every later conversation, so the bar is higher than for context selection.

Spend less time on repeated judgments

The performance opportunity extends beyond substituting Jev for an existing model call. If several independent questions use the same evidence, ask them together. Support and scope assessments can run alongside an applicability check instead of waiting for separate round trips. A conflict assessment that needs another source still has to wait for that source. Parallel execution doesn’t remove evidence dependencies.

I’d also remove calls that code can settle. Code can reject an expired record or a candidate without a source ID before semantic evaluation. A previously computed assessment may be reusable when its inputs and model version are unchanged, subject to the same access rules. Promotion checks can often run after the response, provided the candidate remains unavailable as approved memory until they complete.

More checks can still make the overall system slower. Broadening retrieval adds database work, and repeating large evidence packages adds input tokens. The budget needs to cover retrieval through final response, including follow-up searches and fallback reasoning. Savings are useful if they buy better evidence selection or prevent a bad memory from entering future contexts.

Measure the decisions the agent gets wrong

Confidence needs its own evaluation. TypeSafe’s confidence documentation explains that the value summarizes the returned probability distribution. It doesn’t independently verify the underlying evidence. I’d calibrate thresholds separately for optional context selection and memory promotion, using labeled examples from the actual application. The cost of dropping a useful passage differs from the cost of storing an unsupported rule.

In the notebook’s batching comparison, repeated assessments of the same TX-100 candidate and evidence returned support probabilities of 0.88 and 0.90 in one trial, then 0.90 and 0.89 in another. The example’s 0.90 threshold split each pair, so identical inputs were rejected for different reasons: one call found the claim unsupported, and the other found that it didn’t preserve the source’s limits. With a stronger scope score, the same candidate could have been promoted by one call and rejected by the other. I’d review cases near that boundary before giving this policy unattended promotion authority.

Start with a replay set of real memory decisions. Seed it with obsolete guidance and legitimate exceptions. Add cases where the evidence is too thin to decide either way. Keep the Oracle data snapshot fixed and compare the current approach with the proposed assessments under the same total cost and latency limits. Measure whether required evidence is retrieved, whether the selected context supports the answer, and how often unsupported claims are promoted. Track unnecessary escalations and high-percentile response times as well.

A faster assessment that repeatedly accepts the wrong exception hasn’t helped. A slightly larger retrieval set that prevents that error might justify its cost. I’d begin with promotion running in shadow mode, compare its decisions with reviewed outcomes, and use those disagreements to refine the questions before allowing it to affect what the agent remembers next time.

Frequently asked questions

How do Jev and Oracle AI Database work together in an agent memory system?

Jev assesses a supplied state using typed questions. The application maps its answers to approved retrieval routes and context-selection policies. Oracle AI Database holds each memory next to its evidence and enforces tenant scope at retrieval. Approved memories are committed there through application-controlled transactions.

How should an agent choose which retrieved memories enter its context?

Reserve space for mandatory evidence first. Assess optional candidates for both relevance and applicability, keeping source IDs and limitations attached. A previous refund can be highly relevant while authorizing nothing about today’s request. Keep unresolved contradictions visible and retrieve more evidence when needed.

When should an observation become long-term memory?

Promote it only after checking that its source supports the claim, its scope matches the evidence, and it doesn’t contradict governing rules or current facts. Reject missing sources and exact duplicates before calling Jev. Before committing, verify that the source version hasn’t changed and preserve the evidence and assessment records.

How can typed assessments reduce the cost and latency of memory decisions?

Use code for exact checks and batch independent questions against shared evidence in one Jev call. Reuse assessments only when their inputs and model version remain valid under the same access rules. Promotion checks can run after the response while proposed memories remain unavailable. Measure the full request path: extra retrieval and repeated input tokens can consume the savings.

How do you evaluate whether these memory decisions improve agent behavior?

Build a replay set from decisions the team has already reviewed, and run both approaches against it with the database snapshot frozen. The scores that matter are missed mandatory evidence and unsupported promotions; cost and latency are the constraints. Keep promotion in shadow mode until its disagreements with reviewers are rare enough to trust.