AI agents are no longer blank tools that wake up with no context. A serious coding agent can inspect files, read issue history, use tools, follow repository instructions and carry some local conversation state. The useful question is no longer whether an agent can use context. It can.
The harder question is which project memory an agent should actually use, who is allowed to receive it, how current it is, and how the team can verify what the agent saw before it acted.
The memory questions
More context is not the same as better project memory.
Context is not project memory
Context is assembled for one interaction. Project memory has to survive interactions, preserve source and age, and remain usable when a different agent or teammate returns later.
Time is part of truth
A recent note often matters, but it should not automatically override an older requirement, security constraint or architecture decision with stronger authority.
Authority and relevance differ
A security rule may be authoritative but only relevant to certain changes. A debugging note may be relevant today but should not become project truth without confirmation.
Sharing is a memory problem
Partners, support teams and agents need different views of the same project. A useful memory layer should make safe scoped sharing easier than raw context dumping.
Example
One project, several safe memory views.
A backend agent, an external partner and a support lead can work from the same underlying project memory without receiving the same memory dump.
Backend coding agent
- Receives
- current endpoint behavior, source references, failure modes, required tests and active security constraints
- Does not receive
- support wording, partner negotiation notes and unrelated customer material
External partner
- Receives
- endpoint behavior, retry semantics, idempotency expectations, migration notes, expiry and provenance
- Does not receive
- private pricing, internal roadmap tradeoffs, raw security notes and customer-sensitive data
Support lead
- Receives
- customer impact, approved wording, rollout status and known limitations
- Does not receive
- raw backend debate, internal risk notes and implementation-only traces
SPM model
Durable, shareable, governed and internally smart memory.
SPM preserves requirements, decisions, completed work and source evidence across agent tools, then evaluates what matters, what still holds and what each authorized audience may receive through MCP, API or CLI.
- durable project memory with source-linked summaries, decisions, policies and completed work
- LLM-assisted memory triage that structures, summarizes, tags, relates and prioritizes mixed input
- temporal memory across original intent, working state, current truth and history
- authority-aware prioritization by source, role, confidence, relevance and temporal validity
- queryable context graphs across requirements, decisions, sources, policies, actions and shares
- scoped context packs for agents, teams, partners and support flows
- governed sharing with permissions, expiry, revocation, entitlement logs and audience boundaries
- provenance, hashes and pack verification before agent use
- agent hardening with preflight checks, required tests, approvals and post-action reports
What to try first
Start with one project and one concrete handoff.
Closing thought
Agents will keep getting better at reading context. That does not remove the need for project memory. It raises the bar for it. As agents do more consequential work, the memory they use should know what matters, what is still valid, what came from a stronger source, what can be shared, what must be hidden and what can be verified.