Ontology and Memory Systems (7/13) — Handoff Design Comes Before Memory

The most common failure in long-running work is not that the model forgets everything. It is that the work stops being resumable. Sessions change, people intervene, context gets trimmed, and the next execution no longer knows what it should read first. That is why the center of long-running agent operations is not memory in the abstract, but how you structure handoff.

ํ•ต์‹ฌ ์š”์•ฝ

  • The main problem in long-running work is not forgetting, but interruption without a clear resume path.
  • A good handoff is not a summary paragraph. It is a resume structure that lets the next step start immediately.
  • progress file, session note, and handoff note should not be treated as the same document.
  • Managed Agents can help keep work running longer, but they do not decide how work should resume.

1. The real problem in long-running work is not forgetting, but disconnection

When teams talk about long-running agent work, they often say we need better memory. That can be true, but operationally a more common failure looks like this:

  • nobody knows how far the work got
  • confirmed and unconfirmed status are mixed together
  • the next session does not know what to read first
  • human intervention destroys the resume point

In other words, the deeper problem is not memory volume. It is where work can restart cleanly.

2. Why handoff comes before memory

Memory is a broad concept. It can include long-term knowledge, user preferences, project rules, or past facts.

Handoff is narrower and more operational.

A good handoff answers questions like:

  • what is the current goal
  • where did the last completed step end
  • what should happen next
  • what remains unverified

That is why handoff should usually be treated as a resume structure before memory is treated as a storage feature.

3. Good handoff is not a summary. It is a resume structure.

Many handoffs stop at the level of recap:

  • what happened today
  • what might happen later

That is not useless, but it is not enough.

A stronger handoff usually includes:

Item Why it matters
current goal preserves the main work axis
last completed step anchors the restart position
next action removes ambiguity
unverified items separates fact from assumption
key files or paths reduces search cost

So handoff should be designed less like reflection and more like execution prep for the next session.

4. What the next session needs to know first

A good handoff does not try to preserve everything. It preserves what the next worker needs first.

A practical order is often:

  1. current goal
  2. why the work stopped
  3. next concrete action
  4. remaining unverified risks
  5. must-read files

If that order becomes blurry, the next session usually starts by rewarming context instead of progressing the work.

5. Why progress file, session note, and handoff note should be separate

These documents often get mixed together. That usually increases reading cost.

Document Main role
progress file current state and remaining work
session note what actually happened in one session
handoff note what the next executor needs to continue immediately

Even if some content overlaps, the reading purpose is different. That is why separation usually helps.

6. How to keep resumption stable even when humans intervene

Human intervention is one of the main reasons long-running systems become messy.

People may:

  • change priorities
  • approve or reject partial work
  • revise the plan
  • narrow or widen scope

When that happens, simple logs are not enough. The handoff has to preserve:

  • what changed
  • what decision a human made
  • how that decision changes the next action

Without that, the next executor often resumes from the wrong branch.

7. What long-running Managed Agents still do not solve automatically

Managed runtimes can help keep sessions alive longer and preserve some state. They still do not automatically answer:

  • which information matters most to the next actor
  • what is fact versus still-unverified status
  • which files should be read first
  • which risks must be rechecked before continuing

So longer execution time and better state persistence are useful, but they do not eliminate the need for explicit resume structure.

8. A better test for handoff quality

The best test for a handoff is not did we write a long enough note.

A better test is:

  • can the next session start the first action without extra clarification
  • are verified and unverified states clearly separated
  • are must-read files explicit
  • are human-made changes recorded clearly

If not, the system preserved notes but did not create a usable resume structure.

9. Conclusion: what keeps long-running work alive is the structure of handoff, not just the volume of memory

Long-running operations do not mainly fail because too little was stored. They fail because the next actor cannot re-enter the work confidently.

The core questions are:

  • where did the work stop
  • what is confirmed
  • what happens next
  • what risk remains

If the next session can pick those up immediately, the system is resilient. That is why in practical operations, handoff design comes before memory design.

Related Internal Links

References

Series overview: Series index

๋Œ“๊ธ€

๋Œ“๊ธ€ ์“ฐ๊ธฐ