The previous article left me with a practical problem.
If I deliberately keep Chat as a separate thinking partner, somebody has to keep it aligned with a project that may continue for months.
Chat can be extremely useful for reasoning.
But I cannot expect one conversation to become the permanent memory of a long-running project.
And every time I begin another Chat session, it needs enough of the current project state to think with me intelligently.
For a long time, I supplied that context manually.
Eventually, maintaining Chat became part of maintaining the project.
One project, many conversations
My website was not built from one complete specification.
We built one part, tested it, learned something and continued.
Later requirements sometimes forced us to revisit decisions made many sessions earlier.
Over time, the project existed across several places:
- the actual files;
- Codex sessions;
- ChatGPT sessions;
- build notes and handover documents;
- and my own understanding of why decisions had been made.
Codex could inspect the current project.
ChatGPT depended much more heavily on the context I brought into the conversation.
Sometimes the latest Codex response was enough.
Sometimes the question depended on something decided weeks earlier.
Sometimes a fresh Chat session needed to understand several phases of work before it could sensibly advise me.
The problem was not Chat's ability to reason.
The problem was that good reasoning requires the right context at the right time.
If Chat receives too little, it may give a perfectly sensible answer to the wrong version of the problem.
Let the project remember the project
I eventually stopped treating individual Chat sessions as the place where durable project knowledge should live.
Important information needed to exist outside the conversation.
For my website, that meant maintaining records of things such as:
- what had been built;
- important decisions and constraints;
- unresolved work;
- recent changes;
- what the next phase was supposed to achieve.
The coding agent could update those records as the build progressed.
I could then make the appropriate documents available at the ChatGPT Project level for future sessions.
This created a cleaner separation.
The project files recorded what actually existed.
The build notes and handovers recorded what had happened and why.
Chat remained the place where I could question, interpret and decide.
Chat also needs to hand over to itself
Up-to-date project documents solved only part of the problem.
A new Chat session still would not automatically know which documents mattered, where our thinking had reached or exactly what it should do next.
So before leaving a long Chat session, I began asking the current Chat to write the kickoff prompt for the next Chat.
That became a second kind of handover.
The build agent's handover says:
Here is what changed in the project.
The outgoing Chat's handover says:
Here is where our thinking has reached, what you need to understand, and which project documents you must read before doing anything else.
The kickoff can identify:
- the purpose of the current phase;
- what has already been agreed;
- what remains unresolved;
- the role Chat should play;
- which documents are authoritative;
- what the new session must read in full;
- and what it should not start doing until that reading is complete.
Having the documents available is not enough.
The kickoff tells the new thinking partner how to reconstruct the project before it starts advising me.
Not every piece of context should cross into Chat
There is another boundary that becomes important when the project contains client information.
The objective cannot simply be:
Give Chat everything it might need.
Some material should remain inside the working environment where I have decided it is appropriate to use it.
This was one reason I chose Cowork for Project X. I needed AI to work repeatedly across substantial client material, and I did not want my process to depend on copying raw client information into a succession of separate Chat conversations.
If I still want Chat's independent help, the solution is not necessarily to give it the raw material.
Work can instead create a sanitised handoff.
Suppose Work has examined customer-level transactions.
Chat may not need the names, invoices or complete transaction history.
It may need only a conclusion such as:
One customer segment tends to reorder after a similar interval, although the pattern varies significantly by product group.
That creates a simple rule:
Raw evidence stays in the approved working environment.
Patterns, conclusions and decisions can move into Chat when needed.
Identifiers and sensitive details that add nothing to the reasoning stay out.
If the reasoning genuinely requires information that I do not want to move into Chat, then that part of the reasoning stays in Work.
The goal is not maximum context.
It is minimum sufficient context.
A practical context bridge
The method I now use can be reduced to six steps.
1. Keep durable project knowledge outside Chat
If a decision will matter several sessions from now, record it.
The project should preserve its current state, important constraints, unresolved issues and significant decisions.
2. End meaningful build or work sessions with an updated record
The agent doing the work should record:
- what changed;
- why;
- what was tested;
- important decisions;
- unresolved issues;
- and what should happen next.
This becomes the factual handover from the work itself.
3. Decide what Chat actually needs
Before transferring context, ask:
- What decision am I asking Chat to help with?
- Which facts are necessary?
- Does Chat need the raw evidence or only the conclusion?
- Can sensitive information be aggregated or abstracted?
Then give Chat only that.
4. Before leaving Chat, make it brief its successor
The outgoing Chat has something the project files may not fully contain: the path of our reasoning.
So I ask it to create the next session's kickoff and identify the documents that session must read.
5. Make the new Chat reconstruct its understanding before advising
Before asking for recommendations, I want the new session to tell me:
- what has already been built;
- which decisions are settled;
- where the current work stands;
- and what question we are now trying to answer.
If that understanding is wrong, I correct it before we proceed.
6. Return important Chat decisions to the project
The bridge works in both directions.
If Chat and I make an important decision, that decision cannot remain trapped inside the conversation.
It must return to the project record and, where appropriate, become part of the next instruction to Work or the coding agent.
Two handovers, one data boundary
I now think of a long-running project as needing two different handovers.
Build or Work agent → project
What changed? What is now true? What remains unresolved?
And:
Chat → next Chat
Where has our thinking reached? What does the next thinking session need to understand?
Around both sits another rule:
Sensitive information moves according to need, not convenience.
The overall cycle becomes:
work
↓
update the project record
↓
prepare the minimum necessary context
↓
Chat reviews and helps decide
↓
record the decision
↓
outgoing Chat prepares the next kickoff
↓
new Chat reconstructs the current state
↓
continue
This still involves handoffs.
If I want an independent thinking partner, I do not think they can disappear completely.
The objective is to make them deliberate rather than improvised.
Chat is working memory, not project memory
That is the distinction I now find most useful.
Chat is working memory.
It is where I explore, question, reconsider and try to understand.
The project needs durable memory.
It needs to preserve what was built, what was decided and why after individual conversations have ended.
And sensitive evidence needs its own boundary.
I no longer need every Chat session to know everything that has happened since the project began.
I need the project to preserve what matters, the outgoing session to prepare the next one, and the new session to receive the right context before it starts advising me.
For work that lasts months and crosses tens of AI sessions, that is no longer administrative housekeeping.
It is part of the infrastructure.
The previous article left me with a practical problem.
If I deliberately keep Chat as a separate thinking partner, somebody has to keep it aligned with a project that may continue for months.
Chat can be extremely useful for reasoning.
But I cannot expect one conversation to become the permanent memory of a long-running project.
And every time I begin another Chat session, it needs enough of the current project state to think with me intelligently.
For a long time, I supplied that context manually.
Eventually, maintaining Chat became part of maintaining the project.
One project, many conversations
My website was not built from one complete specification.
We built one part, tested it, learned something and continued.
Later requirements sometimes forced us to revisit decisions made many sessions earlier.
Over time, the project existed across several places:
- the actual files;
- Codex sessions;
- ChatGPT sessions;
- build notes and handover documents;
- and my own understanding of why decisions had been made.
Codex could inspect the current project.
ChatGPT depended much more heavily on the context I brought into the conversation.
Sometimes the latest Codex response was enough.
Sometimes the question depended on something decided weeks earlier.
Sometimes a fresh Chat session needed to understand several phases of work before it could sensibly advise me.
The problem was not Chat's ability to reason.
The problem was that good reasoning requires the right context at the right time.
If Chat receives too little, it may give a perfectly sensible answer to the wrong version of the problem.
Let the project remember the project
I eventually stopped treating individual Chat sessions as the place where durable project knowledge should live.
Important information needed to exist outside the conversation.
For my website, that meant maintaining records of things such as:
- what had been built;
- important decisions and constraints;
- unresolved work;
- recent changes;
- what the next phase was supposed to achieve.
The coding agent could update those records as the build progressed.
I could then make the appropriate documents available at the ChatGPT Project level for future sessions.
This created a cleaner separation.
The project files recorded what actually existed.
The build notes and handovers recorded what had happened and why.
Chat remained the place where I could question, interpret and decide.
Chat also needs to hand over to itself
Up-to-date project documents solved only part of the problem.
A new Chat session still would not automatically know which documents mattered, where our thinking had reached or exactly what it should do next.
So before leaving a long Chat session, I began asking the current Chat to write the kickoff prompt for the next Chat.
That became a second kind of handover.
The build agent's handover says:
Here is what changed in the project.
The outgoing Chat's handover says:
Here is where our thinking has reached, what you need to understand, and which project documents you must read before doing anything else.
The kickoff can identify:
- the purpose of the current phase;
- what has already been agreed;
- what remains unresolved;
- the role Chat should play;
- which documents are authoritative;
- what the new session must read in full;
- and what it should not start doing until that reading is complete.
Having the documents available is not enough.
The kickoff tells the new thinking partner how to reconstruct the project before it starts advising me.
Not every piece of context should cross into Chat
There is another boundary that becomes important when the project contains client information.
The objective cannot simply be:
Give Chat everything it might need.
Some material should remain inside the working environment where I have decided it is appropriate to use it.
This was one reason I chose Cowork for Project X. I needed AI to work repeatedly across substantial client material, and I did not want my process to depend on copying raw client information into a succession of separate Chat conversations.
If I still want Chat's independent help, the solution is not necessarily to give it the raw material.
Work can instead create a sanitised handoff.
Suppose Work has examined customer-level transactions.
Chat may not need the names, invoices or complete transaction history.
It may need only a conclusion such as:
One customer segment tends to reorder after a similar interval, although the pattern varies significantly by product group.
That creates a simple rule:
Raw evidence stays in the approved working environment.
Patterns, conclusions and decisions can move into Chat when needed.
Identifiers and sensitive details that add nothing to the reasoning stay out.
If the reasoning genuinely requires information that I do not want to move into Chat, then that part of the reasoning stays in Work.
The goal is not maximum context.
It is minimum sufficient context.
A practical context bridge
The method I now use can be reduced to six steps.
1. Keep durable project knowledge outside Chat
If a decision will matter several sessions from now, record it.
The project should preserve its current state, important constraints, unresolved issues and significant decisions.
2. End meaningful build or work sessions with an updated record
The agent doing the work should record:
- what changed;
- why;
- what was tested;
- important decisions;
- unresolved issues;
- and what should happen next.
This becomes the factual handover from the work itself.
3. Decide what Chat actually needs
Before transferring context, ask:
- What decision am I asking Chat to help with?
- Which facts are necessary?
- Does Chat need the raw evidence or only the conclusion?
- Can sensitive information be aggregated or abstracted?
Then give Chat only that.
4. Before leaving Chat, make it brief its successor
The outgoing Chat has something the project files may not fully contain: the path of our reasoning.
So I ask it to create the next session's kickoff and identify the documents that session must read.
5. Make the new Chat reconstruct its understanding before advising
Before asking for recommendations, I want the new session to tell me:
- what has already been built;
- which decisions are settled;
- where the current work stands;
- and what question we are now trying to answer.
If that understanding is wrong, I correct it before we proceed.
6. Return important Chat decisions to the project
The bridge works in both directions.
If Chat and I make an important decision, that decision cannot remain trapped inside the conversation.
It must return to the project record and, where appropriate, become part of the next instruction to Work or the coding agent.
Two handovers, one data boundary
I now think of a long-running project as needing two different handovers.
Build or Work agent → project
What changed? What is now true? What remains unresolved?
And:
Chat → next Chat
Where has our thinking reached? What does the next thinking session need to understand?
Around both sits another rule:
Sensitive information moves according to need, not convenience.
The overall cycle becomes:
work
↓
update the project record
↓
prepare the minimum necessary context
↓
Chat reviews and helps decide
↓
record the decision
↓
outgoing Chat prepares the next kickoff
↓
new Chat reconstructs the current state
↓
continue
This still involves handoffs.
If I want an independent thinking partner, I do not think they can disappear completely.
The objective is to make them deliberate rather than improvised.
Chat is working memory, not project memory
That is the distinction I now find most useful.
Chat is working memory.
It is where I explore, question, reconsider and try to understand.
The project needs durable memory.
It needs to preserve what was built, what was decided and why after individual conversations have ended.
And sensitive evidence needs its own boundary.
I no longer need every Chat session to know everything that has happened since the project began.
I need the project to preserve what matters, the outgoing session to prepare the next one, and the new session to receive the right context before it starts advising me.
For work that lasts months and crosses tens of AI sessions, that is no longer administrative housekeeping.
It is part of the infrastructure.
Continue reading