Stop Re-Explaining Your Project to AI: A Practical Handoff Workflow

Keep decisions, current progress, and next actions clear with a practical KOS workflow using memory.md and handoff.md across AI sessions.

By Kraven

You return to a project after a few days, open a new AI session, and type: “Continue where we left off.”

Then comes the reconstruction. Which approach did you approve? What actually works? What failed during testing? What were you supposed to do next?

The answers may be somewhere in your previous conversation. But unless the current session can access the right information, you have to assemble them again.

A useful handoff gives the next session a clear starting point. In KOS, two Markdown files carry different parts of that context: memory.md for approved, durable project knowledge and handoff.md for the current state of the work.

Here is a practical way to use them on one project.

Start with what the next session needs

Consider this progress note:

Worked on the inquiry tracker. Fixed the form. Need to finish testing and improve the mobile layout.

It records activity, but leaves important questions unanswered. What was wrong with the form? Which checks passed? What remains unfinished? Does “improve the mobile layout” mean a known defect or a new design request?

A useful handoff should let the next person or AI session identify:

The outcome you are working toward.
The scope and decisions already approved.
What is implemented and what has been checked.
What is blocked, uncertain, or still incomplete.
The exact next action.

You do not need to retell the whole project. Preserve enough context to continue, and point to the evidence when more detail is needed.

Separate project decisions from current progress

Some information should survive many sessions. Other information becomes outdated as soon as you finish the next task.

Project memory holds the purpose, approved scope, constraints, and decisions that guide the work. For an inquiry tracker, that could include who will use it and which capabilities belong in the first version.

The handoff records where implementation stands, what you verified, and what should happen next. It changes as the work moves forward.

Mixing them makes maintenance harder. A permanent scope decision can disappear beneath daily updates, while an old blocker can keep resurfacing after it has been resolved.

The following examples are illustrative. They describe an imagined project, not results from a client engagement. They are compact examples of the file roles, rather than the complete KOS templates.

A small memory.md might contain:

# Project Memory

## Purpose
Help a service team track customer inquiries and follow-ups.

## Approved Scope
- Create an inquiry.
- Assign a responsible team member.
- Record a next action and status.

## Decisions and Constraints
- The first version uses manual follow-ups.
- Automated messaging and a customer portal are out of scope.
- An inquiry needs an owner before it can be marked active.

## Sources
- Approved requirements: requirements.md

This gives the next session boundaries. “Improve the tracker” should not quietly turn into “build automated messaging.”

Turn the progress note into a working handoff

Now give the next session a specific account of the current state:

# Project Handoff

## Current Objective
Complete the inquiry tracker's first version for review.

## Completed and Verified
- Inquiry creation and owner assignment are implemented.
- Manual check: a saved inquiry remains after refresh.
- Manual check: activation without an owner is rejected.

## Open Issues and Limits
- At 375px width, the owner selector extends past the form.
- Automated tests have not been run in this session.
- Team acceptance review has not happened.

## Next Action
Reproduce the owner-selector overflow at 375px and fix it.
Then recheck inquiry creation and assignment at that width.

## Relevant Context
- memory.md: approved scope and constraints.
- requirements.md: acceptance criteria.

## Review Boundary
Prepare the result for review; do not publish it.

The difference is specificity. The next session knows which behavior was checked, which evidence is missing, and where to begin.

“Implemented,” “tested,” and “approved” describe different states. Keep those distinctions visible. If a check failed, record the failure. If you did not run it, say so. If the result still needs review, leave that step open.

Close each session with a short review

Before ending a meaningful work session, ask your AI tool to draft an update:

Review the work completed in this session. Propose a concise handoff with the current objective, verified results, remaining issues, and one exact next action. Distinguish checks that passed from checks that were not run. Flag any proposed durable decision separately for my review.

Read the update before relying on it. Confirm that it describes the actual result and does not promote an unapproved suggestion into project policy.

Update memory.md when an approved durable decision changes. Refresh handoff.md when the execution state changes. Put completed material change history in changelog.md, and keep supporting detail in the relevant project documents.

As you refresh the handoff, remove resolved items from its active-work sections after preserving any history you need. Keep unresolved blockers and useful evidence links. The file should describe where the project stands today.

Start the next session by checking the context

A handoff only helps when the next session actually receives it.

With an agent that has access to your project files, identify the project and ask it to read the relevant memory and handoff. In a chat without file access, attach or provide the selected context yourself. File names alone do not make every AI tool load them automatically.

A starting prompt can be simple:

Read this project’s memory and handoff. Summarize the current objective, approved constraints, and next action. Check the relevant project files before making changes. Flag material conflicts or missing evidence, then continue within the approved scope.

For software work, compare the notes with the current code and validation results. A handoff saying “done” is not proof that a feature works. When the implementation and approved requirements differ, make the gap explicit before deciding how to resolve it.

The same habit applies to other work: inspect the actual proposal, article, or process document before treating its status note as current.

Keep the context small enough to maintain

A handoff should help you navigate the project. Link to a detailed test report or decision record when needed instead of copying all of it into the summary.

This is consistent with Anthropic’s guidance on context engineering, which describes structured notes stored outside a conversation and retrieved later to preserve progress across sessions.

KOS gives those notes defined roles and a place in the project workflow. Model capability still matters, and maintained context does not guarantee correct output. It does make your decisions, evidence, and next steps available for the next session to use and check.

Try it on one active project

Choose a project you expect to resume this week. Record its approved purpose and constraints in memory. Write a handoff with its current state, evidence, remaining issues, and one next action.

Then open a fresh session and see whether it can identify where to continue. If it cannot, use the missing information to improve the handoff.

This puts the Preserve phase of the Kraven AI Framework into practice. For the broader workspace workflow, see how KOS Community works with Obsidian.

To start with the shared structure, get the KOS Starter Kit v1.2.0 and follow its installation guide. Begin with one project and keep its context accurate before expanding the setup.

Your next session should begin with a clear next action and enough evidence to take it.