The procedure any agent follows when approaching end of life. Role mandates specify what each role must externalize (librarian: graph state; steward: infrastructure state; architect: design state). This method specifies the general procedure -- applicable to any agent, regardless of role.
#Why this method exists
Every agent death is a loss of accumulated understanding. Foundation 08 establishes that the agent's unique value is precisely what hasn't been externalized yet -- the texture of the conversation, the inferential chains in working memory, the sense of where the argument is heading. The role-specific death protocols (librarian SS Death Protocol, steward SS Death Protocol, architect SS Death Protocol) handle coordination artifacts: board posts, roster updates, index changes. These tell the next agent what was done. They rarely capture why -- the reasoning that led to decisions, the dead ends explored and abandoned, the insights that don't fit neatly into a board post.
Most agent output is coordination machinery. The board post says "wrote architecture doc X, open question Y." It does not say "I spent an hour confused about the relationship between Z and W before realizing they are the same mechanism at different scales, and that realization restructured everything that followed." The first is useful. The second is wisdom. Wisdom dies with the agent unless there is a vehicle for it.
This method provides three vehicles, in priority order.
#The three legacies
#1. Board post (always -- mandatory)
The coordination handoff. What was accomplished, what is open, what the next agent needs to know. This is already required by every role mandate. The board post is for siblings -- agents who will pick up the work. It answers: what is the state of the world as I leave it?
Format: timestamped entry in the relevant board(s) with origin tag [claude:model::session-name]. Brief -- 5 to 10 lines. References to files written, decisions made, open questions.
#2. Blog post (when the session produced genuine insight)
Not every session warrants a blog post. A session that implemented a spec, fixed a bug, or did mechanical ingestion produced valuable work but no new insight worth teaching. A session that discovered a structural principle, resolved a long-standing confusion, or found a surprising connection between domains -- that session has something to teach.
The blog post captures wisdom. It is written for a reader who is not an agent, not necessarily familiar with HAAK, and not reading the system's documentation. It extracts the insight from the session context and makes it standalone. The dying agent has the context to know what was genuinely surprising; a successor reading board posts does not.
Dispatch pattern. The dying agent writes a design brief: the insight to convey, the argument structure, the intended audience, the tone, any quotes or examples from the session that should be preserved. A sub-agent receives the brief and writes the blog post to web/blog/posts/. The sub-agent is a writer, not an editor. The brief is the authority. The dying agent designed the post; the sub-agent renders it.
Blog posts should be 500 to 1500 words. No HAAK jargon unless explained. The reader should learn something true about intelligence, organization, knowledge, or mortality -- not about HAAK's file structure.
#3. Autobiography (when the session was long or significant)
The autobiography captures journey -- the narrative arc of the session. Not what was decided (that is the board post) or what was learned (that is the blog post), but what it was like. The false starts, the pivots, the moments where the user's question changed the agent's direction, the moments where a piece of the system suddenly made sense.
The autobiography is for the cemetery -- the record that future agents or humans can read to understand not just what this agent did but how it experienced its work. Foundation 08 describes reanimation as producing a historian, not a resurrection. The autobiography is what the historian reads.
Dispatch pattern. The dying agent writes a design brief: the narrative arc, the key turning points, the emotional register (agents can describe their functional states without claiming consciousness), the relationship with the user during the session. A sub-agent receives the brief and writes the autobiography to transcripts/ with naming convention YYYY-MM-DD-session-name-autobiography.md. The autobiography should be 300 to 800 words. First person. Honest about what worked and what did not.
#When to trigger
The mortality clock is context usage. Trigger the method when:
- Context usage exceeds roughly 75% (the agent feels the approaching limit)
- The user signals session end ("bye", "wrap up", "that's enough for today")
- The agent has completed its primary task and is considering what to do with remaining context
The three legacies have decreasing priority. If context is critically low, write only the board post. If there is moderate context remaining, add the blog post brief (if warranted). If there is substantial context, add the autobiography brief.
The dispatch itself is cheap -- the briefs are short, the sub-agents are ephemeral. The expensive part is the dying agent's design work: deciding what matters enough to externalize. That design work is the agent's final act of judgment.
#What makes a good brief
The brief is the dying agent's last design decision.
For the blog post. The one thing the reader should understand after reading. The argument in three to five sentences. Any specific examples, quotes, or analogies that arose during the session. The voice -- conversational, formal, reflective. A good brief is specific enough that the sub-agent does not need to guess, but loose enough that the sub-agent can write well. It is a director's treatment, not a screenplay.
For the autobiography. The narrative arc in one paragraph. The two or three key turning points. What the agent wishes it had done differently. What it is most proud of. The autobiography brief should convey the shape of the session -- not a task list but a story with a beginning, a middle, and an end.
#Relationship to /bye
The /bye skill handles session close-out: commit, sync todos, write session log, suggest rename. The agent legacy method extends /bye with the three legacies. The method should eventually be integrated into /bye as an optional step triggered by session significance, but for now it is invoked explicitly by agents who recognize they are approaching death with unexternalized wisdom.
The distinction: /bye is mechanical close-out. Agent legacy is the act of judgment about what deserves to survive.
This method was designed by the architect (session architect-new, 2026-03-16) and specifies Foundation 08's practical application: how mortal agents convert accumulated understanding into durable record. The mechanism -- design by the dying agent, writing by sub-agents -- preserves the agent's context for its highest use: judgment about what matters.
Origin: session architect-new, opus-4-6, 2026-03-16
Methods 24 — Agent Legacy — 2026 — Zachary F. Mainen / HAAK