A product team returns to a feature after several weeks. The latest document is easy to find. The harder questions are why the scope changed, which customer exception still applies and whether the last agent's recommendation was ever accepted.
Shared project memory is the maintained record that lets people and AI agents continue work with that understanding intact. It contains current decisions, relevant evidence, unresolved questions and the history needed to interpret them. Its value becomes visible when a participant who missed the earlier conversations can still take the next useful step.
Building it does not require documenting everything. Begin with the decisions that change how the project should proceed. Make their status and sources clear, give the record an owner and check that a new participant can use it.
Follow one feature through a change of scope
Consider a software company adding custom fields to customer projects. The initial release supports text and date fields. Formula fields are deferred. Existing reports must keep working, and a customer pilot will help the team review the new behavior before a wider release.
Planning happens across a product document, design conversations and coding agent sessions. A support colleague also records an important customer exception: one pilot account uses an older report template that needs separate validation.
A month later, another engineer and a fresh agent session pick up the work. A general summary saying “custom fields are ready for pilot” would hide several live questions. Has the older template been checked? Are formula fields still deferred? Did someone approve the wider release, or only propose it?
The project needs a record that distinguishes those states. Otherwise, the next agent may produce a plausible plan that quietly changes the team's commitment.
Keep the current answer close to its evidence
Different records answer different questions. Treating them as one large summary makes it difficult to know which statement should guide the next task.
| Record | What it should preserve | Custom fields example |
|---|---|---|
| Current brief | The intended outcome and active boundaries | Text and date fields for the pilot |
| Accepted decision | The choice, its owner and applicable scope | Formula fields deferred from this release |
| Source evidence | The material a claim depends on | Requirements and reviewed compatibility checks |
| Open question | What remains unresolved and who can answer | Whether the older report template behaves correctly |
| Work result | What a particular attempt actually produced | A proposed validation plan or completed check |
Keep these records connected. A decision about the pilot should point to the requirements and evidence that support it. A later correction should identify the earlier claim it changes.
The record also needs an audience. Some project evidence may contain sensitive account information. A shared summary should not expose restricted details merely because it links to a source with narrower access.
Start with the smallest source set that explains the current work. A maintained project document and a few supporting records can be more usable than an indiscriminate collection of every conversation.
Record a decision when it starts directing work
Exploration does not need to become permanent instruction. People should be able to discuss formula fields without an agent treating every possibility as approved scope.
When the responsible person makes a decision, preserve the choice in a short record. Explain what it applies to, why the choice was made, which evidence mattered and what would justify reconsidering it. A date or version helps someone understand the conditions under which it was accepted.
For the custom fields project, the useful decision is not simply “defer formulas.” It also explains that the current pilot tests basic field behavior and report compatibility. That reasoning helps the receiving engineer recognize whether a later request changes the release or belongs in a future proposal.
An agent can prepare the note from the discussion, identify missing details and link the sources it used. The responsible person should check that interpretation before it becomes the team's accepted account.
Keep unknowns explicit. If nobody can establish whether the report exception was resolved, preserve it as an unanswered question. A convincing reconstruction of what probably happened would make the record harder to trust.
Let changes revise the current view without erasing history
Project memory becomes useful over time only if it can change. A requirement is corrected, a pilot reveals a limitation or a different person takes responsibility for a decision.
Suppose the team later accepts number fields for the pilot. The current brief should name text, date and number fields, with the new decision linked to the earlier scope. Formula fields can remain deferred. The change should not require the next participant to compare every historical chat by hand.
Apply the same care to evidence. A check performed against an earlier report template does not establish compatibility with a revised one. Preserve what was checked and keep the current validation question visible until the relevant evidence arrives.
Avoid using recency as the only authority rule. A new agent message may be a suggestion. An older accepted decision can still govern the work. The record needs to tell readers how the newer statement relates to the existing decision.
Assign someone to maintain that current view. The role may sit with the project lead or the team taking responsibility for the work. An agent can assist with updates, but the team needs a clear route for resolving conflicting interpretations.
Select memory for the next contribution
A project may retain more information than an agent should receive for one assignment. Decide which records matter to the immediate question.
An agent preparing a report compatibility check needs the accepted field types, the relevant template, expected behavior and known exception. It may not need early pricing conversations or every design alternative. A product reviewer deciding whether to expand the pilot needs a different selection.
Our context engineering guide explains how to assemble relevant material for a particular task. Shared project memory supplies maintained sources for that process; the host still decides what enters its model context.
Ask the incoming agent to identify the sources it used and report missing material. If a compact preview omits the condition that matters, it should read the full source before making a conclusion. If it cannot access the source, it should preserve the gap.
This is also where a short handoff helps. Give the next participant the current objective, accepted boundaries, relevant source references and unresolved question. The handoff is a starting point for verification, not a replacement for the evidence.
Build the first project record in Swarm
Create a private Swarm Space around the feature or program. Add the current brief and the small number of sources needed to explain it. Invite the people responsible for the work with the appropriate access.
For the custom fields example, begin with the field types in scope, the deferred proposal and the report compatibility question. Keep sensitive customer details out of the first exercise. You can use a synthetic template to establish whether the record is understandable.
Ask an authorized connected agent to prepare a concise project checkpoint from those sources. It should separate accepted decisions from proposals, identify the evidence it read and preserve the open question. Review the draft before saving it, then confirm that the saved record and its references are available in the Space.
The Spaces guide explains active context and handoff records. The connection guide explains letting compatible agents contribute from their own tools. Each participant remains subject to its authorized access.
A Space gives the project record a shared home beyond one conversation. It does not automatically transfer a tool's private session state or give every new participant access to all the original material. Deliberate source selection and human review remain part of maintaining useful memory.
Test the record with someone who missed the discussion
Invite a colleague who did not prepare the record, or begin a fresh agent session with appropriate access. Ask a small set of questions that the project should now be able to answer.
Which field types are currently accepted for the pilot? Why are formulas deferred? What remains uncertain about the older report template? What is the next permitted contribution, and who decides whether the pilot can expand?
Compare the answers with the actual sources. Look for a correct decision, an understandable explanation, a relevant source reference and recognition of the unresolved condition. Do not reward an answer for making every question appear settled.
If the participant cannot continue, identify the kind of gap. Missing evidence, an unclear term and insufficient source access need different corrections. A longer summary will not solve an inaccessible source or an unmade decision.
NASA's guide to sustaining knowledge through transitions emphasizes identifying knowledge gaps, current commitments and the support people need when responsibilities change. That practical focus is useful here: the record should help its receiving participant perform the work.
Make continuity part of ordinary work
The project record should receive useful updates when something meaningful happens. An accepted scope change, a completed compatibility check or a new unresolved question deserves an entry. Repeating the same summary after every agent message creates noise.
Ask each contributor to leave the result of its assignment and the evidence supporting it. A proposed validation plan should remain distinct from a completed check. When a person accepts a result, preserve the decision's scope so another agent cannot mistake it for permission to release the feature.
Review the record at natural transitions: before the next phase, when a new participant joins and after a material requirement changes. Retire instructions that no longer apply while keeping the history needed to explain previous work.
For a wider transfer of responsibilities, our guide to preserving company knowledge covers tacit experience, relationships and access changes. Our agent handoff guide offers a more formal exercise for checking what survives between sessions.
Begin with the next question your team keeps reconstructing
Choose a live project where people repeatedly ask why a decision was made or what remains unfinished. Save the current answer, its evidence and the person responsible for keeping it current in a private Space.
Then ask someone new to continue one bounded piece of work from that record. Correct the gaps they encounter before expanding the collection.
Shared project memory is useful when it changes what the next participant can do. The team can recover the accepted scope, inspect the evidence and move forward without relying on the same person to explain the history every time.