Chained saves (threads)

Chain, don't trim. Split long text and ongoing records with `prev_event_id` so the flow survives.

A memory doesn't always finish in one piece. Sometimes you're splitting a long document; sometimes you're writing up an investigation that runs for days, or a procedure with several stages. AiAkiv weaves these saves into a thread so you can follow them in order later.

There's one idea here. chain it, don't trim it.

Why it's needed

Faced with something long, people usually make one of two mistakes.

  • Summarize it in → the original is gone. You can't recover "what exactly did it say" later.
  • Cut it and save only the front → the rest disappears entirely.

A memory earns its keep by being recoverable as the original (Saving). So when it's long, you don't shrink it. You split and chain it.

When a save finishes, that memory's event_id comes back. Pass that value as prev_event_id on the next piece and the two memories are linked in order.

save_memory(summary="Part 1 …", entities=[…], content="…")
  → event_id: evt_a1b2

save_memory(summary="Part 2 …", entities=[…], content="…",
               prev_event_id="evt_a1b2")
  → event_id: evt_c3d4   (linked after evt_a1b2)

save_memory(summary="Part 3 …", entities=[…], content="…",
               prev_event_id="evt_c3d4")

You don't have to memorize this. Every save response carries a continuation_hint with the exact value to pass on the next call.

As a person, you just say:

ak continue saving

The AI passes the previous save's event_id as prev_event_id and chains it for you.

When to chain

Three cases.

  1. Splitting a long document: text that won't fit in one save, in order.
  2. An ongoing record: an investigation spanning days, continuing meeting notes, anything where the flow keeps going.
  3. Stage N of a procedure: work records where the order itself is the meaning.

Conversely, don't chain memories that are independent of each other. Linking unrelated things makes search follow the wrong flow later. Only link when "this continues from that one."

It isn't automatic. The server does not decide continuity by itself. Whether a save continues the previous one is for a person or an AI to judge and state. That's why a single "ak continue saving" matters.

Size limits: split when you overflow

Field Limit If you exceed it
content (original) 50,000 chars Split and chain
summary 500 chars Compress it (splitting is not the answer)

If content exceeds the limit the server refuses the save, and the error message explains this splitting method. Don't trim. split and save again.

There's one distinction to watch. A long summary is not a reason to split. A summary over 500 characters means the summary is verbose; shorten it. Splitting and chaining is a device for when the original is large, only.

Chained memories appear as one flow in the link map (hint) of search results, and on recall you can follow the chain forward and back (Searching). If part 2 of a three-part document matches, the paths to parts 1 and 3 are shown alongside it.

Splitting the container without losing the flow is the whole point of this device.

Cautions

  • The save target must be the same. If prev_event_id isn't a live memory in the place you're saving to (the same team and project scope), it is ignored: the save happens without the link. See Teams and projects.
  • Save in order. Part 1 → 2 → 3, passing the immediately preceding save's event_id each time.
  • Each piece must stand as a real memory. Fill in a summary, entities, and tags for every piece. If only "part 2" matches a search, it has to be readable on its own (Saving).

Next

Full index → Docs View as Markdown