Consider an API change that begins in one coding agent, continues with another developer and ends with an external integration partner. The repository contains the implementation. The specification describes the intended contract. The first agent's conversation contains the rejected approach, the test evidence and a warning that one part of the rollout is still provisional.
The next participant needs all of that project knowledge, but not as a transcript and not without access limits. SPM keeps the work as persistent project memory and produces the specific view each authorized person or agent should use.
A project changes hands
One workstream produces three useful views.
The views come from the same project memory, but they are not copies of one another. Each has a purpose, an audience and an explicit boundary.
The next coding agent
Receives
The approved contract, work already completed, failed approaches, required tests, open risks and the sources behind each decision.
Does not receive
Unrelated projects, private commercial discussion and material outside the agent task.
The external partner
Receives
Endpoint behavior, retry semantics, migration steps, known integration constraints and a time-limited checklist.
Does not receive
Pricing, internal security discussion, roadmap notes and customer-sensitive material.
The support lead
Receives
Customer impact, rollout status, known limitations and the wording approved for external communication.
Does not receive
Implementation detail and internal discussions that do not help resolve the customer issue.
Why another memory layer
Files and retrieval answer part of the question, not the whole handoff.
SPM does not replace repositories, specifications, documentation or retrieval. It connects those sources to the decisions and work that give them operational meaning.
Repository
Shows the implementation that exists now.
It does not reliably explain which discussion authorized the change, what remains provisional or what another agent already tried.
Specification
Defines intended behavior and constraints.
It can lag behind implementation, omit later decisions or say nothing about completed work and current operational state.
Chat or agent history
Preserves decisions and working detail.
It is fragmented by thread, tool and user. Sharing the transcript also shares irrelevant or sensitive material.
RAG over documents
Retrieves passages related to a query.
Similarity alone does not determine which decision still applies, whose instruction carries authority or what the recipient may see.
How SPM works
Keep the evidence. Interpret the project state. Compose the view.
- 01
Capture the work
SPM records project contributions with their actor, source, time and project. Depending on the capture policy, that can include prompts and final responses or the fuller work record and referenced resources.
- 02
Interpret what changed
The memory service identifies decisions, completed work, requirements, evidence, open questions and changes in project state. Raw evidence remains available when a compact summary is not enough.
- 03
Resolve what still applies
A recent observation is not automatically more authoritative than an approved requirement. SPM keeps original intent, working state, current decisions and history distinct so the receiving agent can see tensions instead of flattening them.
- 04
Deliver the right project view
For each task, SPM composes an authorized view from relevant memory and source evidence. The view can be queried, expanded to detail, shared, expired and revoked without copying the entire project.
Time and authority
The newest statement does not automatically become project truth.
Suppose the product owner approved idempotent retries in May. In July, an agent observes that disabling retries would make one failing test pass. Both statements matter, but they do not have the same status. SPM can retain the observation as working evidence while keeping the approved decision current and surfacing the tension to the next agent.
- Contribution
- Retries must remain idempotent.
- Source and authority
- Approved product decision
- Temporal state
- Current
- Agent view
- Active project constraint
- Contribution
- Disabling retries makes one test pass.
- Source and authority
- Agent observation with test evidence
- Temporal state
- Working
- Agent view
- Relevant tension, not a replacement decision
Inspect the result
A receiving agent gets a compact view and a path back to evidence.
The first response should not contain every retained event. It should contain the current requirements, decisions, completed work, open risks and relevant messages for that task. When the user asks about a detail the compact view does not contain, the agent can query deeper history and retained raw evidence through the same project boundary.
Project view for the next agent
- Current decision
- Keep idempotent retries and preserve the approved API contract.
- Completed work
- Endpoint updated; migration path and retry tests added.
- Open risk
- One timeout case remains under investigation.
- Evidence
- Source specification, implementation change, test run and approving actor retained.
- Boundary
- Internal pricing and partner negotiation are excluded.
Evaluate it on real work
Test one project across two agents and one restricted collaborator.
Let the first agent complete meaningful work. Continue in a second agent, then create a restricted partner view. A useful evaluation should answer concrete questions rather than count memory features.
- Can a second agent identify what was completed without reading the first conversation?
- Can it distinguish an approved decision from a newer but provisional suggestion?
- Can it trace an important claim to a source or retained event?
- Can a partner receive the integration contract without private pricing or internal discussion?
- Can the project owner revoke that partner view without deleting the project memory?
- Can work performed by another authorized user appear with its authorship intact?