In Why I’m Shutting Down Product Partner, I left out an important qualification. Claude and Codex did not solve my context problem out of the box. I had to build a system around them.
Neither tool starts a session knowing what I decided six weeks ago, why a ticket is still open, or what another agent discovered yesterday. A transcript might contain the answer, but that only helps if the next session knows where to look. Meanwhile, the backlog can keep describing a version of the project that is no longer true.
What I wanted from Product Partner was an always-informed colleague. I get much of that continuity now from a disciplined process for keeping the record current.
A new session can recover the state of the work without depending on the previous transcript. When the work produces new evidence, that evidence makes it back into the backlog instead of remaining in chat.
The backlog is one part of the context
I do not think of the backlog as the agent’s complete memory. I treat it as the durable record of work that may matter after the current session ends.
Other information belongs elsewhere:
CLAUDE.mdandAGENTS.mdcontain operating instructions. They tell the agent how I want it to work, which checks matter, and how to handle uncertainty.- Backlog tickets contain decisions and work state. They record why something matters, what evidence exists, what remains unresolved, and where the work stands.
- Handoffs contain the immediate stopping point. They explain what happened in the current session and what someone continuing the work should do next.
- Git and project documents contain the work itself. They show what changed, what shipped, and the deeper reasoning behind a project.
Built-in agent memory is still useful for stable preferences and recurring background. Project state needs different properties. I need to be able to inspect it, correct it, prioritize it, and share it with a different agent or person.
The layers can disagree, and sometimes they should. A handoff might say a fix is finished while the repository still contains uncommitted work. A ticket might say something is in progress after the feature has shipped. Stored context is a lead, not proof. Current code, deployed behavior, and newer evidence win.
What happens during a session
In practice, a session moves through four recurring steps:
Orient → Work → Reconcile → Handoff → Orient
When a session starts, a hook checks whether the project has a handoff. It gives the agent a pointer and a small amount of orientation, rather than dumping the whole file into every conversation. If the handoff is relevant, the agent reads it and checks its claims against the repository and backlog.
The agent can reach PGDash, the backlog tool I built for my projects, through an MCP server. MCP is the connector that lets Claude or Codex search and update the live board directly. The agent retrieves the tickets related to the current request instead of loading the entire backlog. The aim is to bring in enough context to do the work, not to fill the context window.
Then the agent works in the environment where my other tools already live. It can inspect the repository, follow a project-specific workflow, draft a PRD, run automated checks, verify a deployment, or research an open question.
The plan often changes during the work. A test resolves an uncertainty. A fix exposes a second problem. A decision makes an old ticket irrelevant. Unless the record changes too, the next session starts from stale information.
At the beginning of a coding session, another hook records the current Git commit. When the session tries to finish, it checks whether the session produced new commits. If it did, the agent gets a reminder to reconcile the work with PGDash.
The reminder does not decide what the commits mean. The agent looks for the corresponding ticket, adds the relevant evidence, links the work, and recommends any status change. If it uncovered a separate problem that should survive the session, it can file a new ticket. A mechanical change with no backlog consequence can be acknowledged and left there.
After every write, the agent reads the ticket back and reports the saved state. That check can catch a failed write, but it can also catch a bad decision made from incomplete evidence.
If the work will continue, the session ends with a handoff: what changed, what was verified, what remains uncertain, and the next action. The next session receives a pointer to that file and starts the loop again.
A real example from BookOwl
A recent BookOwl session began with an unresolved question about links that should open the app. The ticket said the behavior still needed to be tested with a fresh App Store installation.
The test passed. A link from Messages opened BookOwl, and the supporting configuration was being served correctly. That evidence resolved the question in the original ticket, so the agent added it and closed the item.
But the test exposed another problem. The link opened the app, then landed on the default screen because the in-app routing had never been implemented. That became a new high-priority ticket for the next iOS release.
It would have been easy to leave the first ticket open under a vague sense that “deep links are still broken.” That would have made the backlog less precise. The original question had been answered. The newly observed behavior was a different problem with different work attached to it.
The next session did not need the full conversation to reconstruct that distinction. One ticket held the completed test and its evidence. The other held the remaining problem and next action.
The parts I do not automate
Most of my automation remembers to ask. It does not make the product decision for me.
I do not load the entire backlog into every session. Large boards contain unrelated work, old assumptions, and enough detail to distract an agent from the request in front of it.
I do not turn every observation into a ticket either. Some findings are notes. Some uncertainty will disappear before the session ends. Sometimes an existing ticket already covers the work. Capturing everything would create a more complete record of the conversation and a worse backlog.
I also do not let old tickets or handoffs overrule current evidence. If the deployed product behaves differently, the stored context needs to change.
I stopped building the contract and replaced it with an interactive skill. The agent presents the evidence, its confidence, and a proposed change in the conversation. I approve specific changes. It applies only those changes, reads every ticket back, and reports what happened.
The first live review justified that restraint almost immediately. Short summaries made two tickets look complete, but the full notes showed that only one part of each ticket had shipped. The readback caught both mistakes, and the tickets were reopened with corrections. The problem was not a missing transaction protocol. The decision had been made from incomplete evidence.
Start with instructions, not infrastructure
You do not need PGDash, custom hooks, or your own MCP server to try this. You need a backlog the agent can read and update, plus a standing instruction for the beginning and end of a session.
For session start:
Before beginning, find the open backlog items, recent decisions, and unresolved questions related to this request. Check any handoff against the current project state. Summarize what is still true, what may be stale, and what appears to be the next action. Do not change the backlog yet.
For session end:
Before finishing, reconcile this session with the backlog. Update existing items with relevant decisions, evidence, status changes, and links to completed work. Create a new item only for genuinely new work that should survive this session. Read every changed item back and report the final state. If the work will continue, leave a handoff with the stopping point, known uncertainties, and next action.
Run those steps manually for a while. The repetition will tell you which parts are easy to forget and worth automating.
For me, direct MCP access removed the copying and pasting (in fact, I almost never use the UI I built, opting instead for direct conversation with the AI). The start hook made handoffs harder to overlook. The stop hook caught committed work that had not been reflected in the backlog. Each addition addressed a failure I had already observed.
Reviewing the backlog became its own workflow
Once the underlying record was more reliable, I could use an agent to review the backlog itself without spending half the session figuring out which tickets were still true.
The skill I use now starts with work that looks closest to resolution: items already in review, stale work in progress, and tickets with evidence that they shipped or were superseded. It reads the full ticket before proposing a change, checks current evidence when necessary, and tells me how confident it is and what could go wrong.
I still make the call. The skill applies the approved set, reads the results back, and ends with a short recommendation for what I should work on next. Weak evidence leaves an item unresolved.
That workflow depends on the same loop it helps maintain. Sessions return decisions and evidence to the backlog. Backlog reviews close finished work and correct stale assumptions. The next session starts with a better record.
My examples come from software projects, but the pattern is not limited to code. Research has open questions, prior evidence, and follow-ups. Consulting work has client decisions, deliverables, and unresolved dependencies. Product planning has bets and commitments that should change when the evidence changes. Each needs a shared record and a consistent way to return new information to it.
Start with the backlog you already use. Add an instruction for how the agent should orient itself and another for how it should reconcile the work before finishing. Run the process manually until you know what is actually worth automating.
I help founders and product leaders decide what to build around AI tools and what those tools have already made unnecessary. Reach out.