How much context survives compaction?

Whatever your budget allows, in relevance order. If topic says "both active", hold budget for both threads — dropping the original bug to make room is how agents "forget" what they were doing.

Can I score whole turns instead of facts?

Fact-level candidates keep the decision sharp: one turn often raises two facts with very different futures. If you only have turn boundaries, your wrapper proposes the candidate facts.

What if every fact ranks high?

Compaction cannot make room from nothing — summarize the lowest tier. The typed call tells you what was load-bearing before you summarize anything.

Use case

Context compaction

Decide which facts still matter when an agent conversation is compressed.

The problem

Naive truncation drops the bug that started the thread.

What your code does with the answer

Keep a fact only when `still_relevant` is high.

Compression that keeps the launch-blocking fact

The state carries the conversation so far and one candidate fact to keep or drop. Two questions: still_relevant (should this candidate stay in the compressed context) and topic (which thread is the conversation actually on — the original outage, the new feature, or both active). In the sample, the 500-caused-by-null-guest-carts fact scores still-relevant and topic reads both-active — the naive truncator that evicts the bug summary loses, and this call keeps it.

Decide per fact, not per turn

When a conversation has to shrink, evaluate candidate facts in one request — up to eight per call, which typically stays a single credit. Keep facts above your relevance line until the budget fills; keep both threads when topic says so. Compaction runs periodically between turns, not in the hot path, so the 400–600 ms round trip is never on the user's clock.

Pitfalls specific to compaction

Candidate facts need provenance in state ("found by the log search tool") or relevance scores will favor vivid single-line facts over the agent's earned inference chains. Do not compact mid-turn — run it between turns, when nothing is in flight. And budget for both-threads cases explicitly: a compactor that always keeps one thread's budget starves when the conversation legitimately has two active lines.

The request shape

This is the full request the playground sends for this preset — the same JSON your server sends to /v1/systemone with a Bearer key.

curl

curl https://jevai.website/api/v1/systemone \
  -H "Authorization: Bearer $JEV_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "state": {
    "conversation_so_far": "User asked to debug a 500 on /checkout. We found a null customer_id. User then asked about adding Apple Pay.",
    "candidate_to_keep": "The /checkout 500 is caused by a null customer_id on guest carts."
  },
  "questions": {
    "still_relevant": {
      "type": "noul",
      "instructions": "Should `candidate_to_keep` stay in the compressed context?"
    },
    "topic": {
      "type": "choice",
      "instructions": "Which topic is the conversation on now?",
      "criteria": {
        "debug": "The original outage",
        "feature": "A new feature request",
        "both": "Both are still active"
      }
    }
  }
}'

FAQ about this use case

How much context survives compaction?: Whatever your budget allows, in relevance order. If topic says "both active", hold budget for both threads — dropping the original bug to make room is how agents "forget" what they were doing.
Can I score whole turns instead of facts?: Fact-level candidates keep the decision sharp: one turn often raises two facts with very different futures. If you only have turn boundaries, your wrapper proposes the candidate facts.
What if every fact ranks high?: Compaction cannot make room from nothing — summarize the lowest tier. The typed call tells you what was load-bearing before you summarize anything.

Run this in the playground