AI agents should not share all memory.
Use shared authoritative sources for facts, policies, definitions, approved strategy, and reusable reference material that several roles genuinely need. Use role-specific memory for domain precedents, working preferences, correction history, and recurring context required by one role. Use task-local context for intermediate analysis, temporary results, and sensitive details needed only for one assignment.
The safe default is isolation. Sharing is an explicit policy decision based on purpose, provenance, sensitivity, authority, freshness, and blast radius.
The AI organization implementation guide defines the roles and information boundaries. Once those boundaries exist, decide which approved objects may cross them and which must remain isolated.
On this page · 15 sectionsOpen
- What Is Shared AI Memory?
- What Is the Difference Between Shared and Role-Specific Memory?
- Which Memory Architecture Should You Use?
- What Should AI Agents Share?
- What Should Stay Role-Specific?
- Who Should Be Allowed to Read and Write Shared Memory?
- How Should Retrieval Work?
- How Do You Prevent Memory Poisoning and Cross-Role Leakage?
- How Should Memory Move During a Handoff?
- How Do You Correct or Delete Shared Memory?
- How Do You Evaluate Shared and Role Memory?
- How Does CellCog Represent Shared and Role Memory?
- What Is the 3-Layer Memory Design Template?
- What Is the Final Decision Checklist?
- Final Decision
- Separate at least 4 information planes: authoritative shared sources, team/project sources, role-specific durable memory, and task-local working context.
- Share sources, not every agent’s accumulated notes, summaries, preferences, or private working notes.
- Every durable entry needs source, identity, timestamp, scope, sensitivity, version, owner, expiry, and a correction path.
- Default write authority is narrow: many roles may read approved sources, fewer may propose changes, and a named human or deterministic process approves authoritative writes.
- Treat retrieval as a risk decision. Recheck identity, purpose, relevance, freshness, sensitivity, and hostile content before memory enters the model’s context.
- A handoff should send source/artifact references, decisions, and uncertainty - not copy the sender’s entire role memory into the receiver.
- Measure retrieval usefulness, stale-use rate, cross-role leakage, correction propagation, poisoning detection, and memory-attributable task quality.
§ 01What Is Shared AI Memory?
Shared AI memory is durable information that more than one approved role can retrieve for a defined purpose.
| Information plane | Typical contents | Default access | Authority level |
|---|---|---|---|
| Organization source of truth | Policies, approved strategy, product facts, brand rules | Approved roles read | Human/source owner writes |
| Team/project source | Project brief, decision log, roadmap, shared artifacts | Project roles read | Project owner approves changes |
| Role-specific memory | Domain precedents, accepted examples, role preferences | One role/role owner | Controlled role write |
| Task-local context | Temporary inputs, intermediate work, current state | Task participants only | Expires with task |
| Audit history | Memory CRUD events, provenance, propagation, correction | Security/authorized reviewers | Append-only/system-owned |
Shared does not mean public to every agent. It means access is intentionally available to more than one identified role under a policy.
Shared memory should usually be a source
Good shared objects: an approved pricing page; a current product fact sheet; brand vocabulary; security policy; customer-support policy; a project brief; a decision record; a source hierarchy; an account eligibility rule; or a versioned artifact.
These objects have an owner and an authoritative update path.
Role memory should support one recurring job
Good role-specific memory: a common source failure found by the research role; accepted format examples for the content role; a recurring query pattern for the data role; a known escalation pattern for the support role; a tool behavior note; a reviewed correction; or a domain-specific preference.
The memory should improve a future role decision, not merely preserve history.
Task context should disappear by default
Working notes, partial hypotheses, copied excerpts, intermediate calculations, and temporary customer details often do not need to become durable memory.
Persist only what has a future purpose, an owner, evidence, an allowed scope, a correction path, and a retention justification.
§ 02What Is the Difference Between Shared and Role-Specific Memory?
| Dimension | Shared memory/source | Role-specific memory |
|---|---|---|
| Purpose | Keep several roles aligned on common facts/decisions | Improve one role’s recurring work |
| Audience | Approved organization/team roles | One role or narrow role class |
| Write access | Highly restricted | Restricted to role/system with review |
| Content | Approved facts, policy, strategy, common artifacts | Domain precedents, preferences, corrections |
| Sensitivity | Broadest allowed common denominator | Can be narrower, never broader than role permission |
| Retrieval | By identity, purpose, relevance, freshness | By role, task, and domain relevance |
| Error blast radius | High | Lower if isolation holds |
| Correction | Propagate to all readers and derived objects | Correct role store and affected artifacts |
| Evaluation | Alignment, accuracy, cross-role consistency | Role quality, relevance, non-leakage |
| Default | Curated and deliberate | Isolated and purpose-bound |
Shared information must earn its reach
Share only when 2 or more roles need the same fact; divergence creates real cost or risk; the object has an authoritative owner; sensitivity permits the audience; provenance is available; freshness can be checked; and correction can propagate.
Convenience alone is not enough.
Role memory must earn persistence
Persist only when the role is likely to need it again; the information is verified or clearly typed as a preference/observation; reuse is permitted; the role owner can inspect and correct it; and expiry or review is defined.
An agent-generated inference should not become durable just because it sounds useful.
The boundary is not only technical
Two agents may use the same vector database while policy isolates their namespaces. Two agents may use different stores while copied summaries leak between them.
Evaluate the memory boundary through identity, access, purpose, write authority, retrieval, propagation, and correction. Database topology alone does not define a safe memory boundary.
The broader AI employee memory lifecycle covers what one persistent worker should remember, forget, correct, and expire. A multi-agent architecture adds a second decision: which approved objects may cross role boundaries.
§ 03Which Memory Architecture Should You Use?
Choose among 5 patterns.
| Pattern | Description | Best fit | Main risk |
|---|---|---|---|
| Full isolation | Every role has separate durable memory | Sensitive or unrelated roles | Duplicate facts and inconsistent updates |
| Shared source, isolated role memory | Common authoritative corpus; private role learning | Default multi-agent organization | Source owner becomes bottleneck |
| Team/project memory | Shared only inside one bounded project/pod | Cohesive functional work | Project scope creep |
| Curated organization memory | Selected approved facts shared widely | Policy, product, brand consistency | Large blast radius from bad writes |
| Federated retrieval | Query source systems at runtime; minimal copying | Fresh, governed enterprise data | Retrieval complexity and latency |
The default recommendation is shared source, isolated role memory.
Full isolation
Use when roles serve different customers/tenants; data is highly sensitive; cross-role reuse is rare; source permission differs materially; or poisoning blast radius must stay minimal.
Accept the cost of repeated retrieval and possible inconsistency, then use a human-owned source rather than cross-copying role notes.
Shared source, isolated role memory
Use:
```text Approved shared sources ├── read → Manager ├── read → Research Specialist ├── read → Content Specialist └── proposed change → Human Source Owner
Manager role memory: isolated Research role memory: isolated Content role memory: isolated ```
This keeps common facts aligned while allowing roles to learn only what their jobs require.
Team/project memory
Use when several roles work on one bounded project with a common goal, common source set, shared decisions, known membership, a project owner, an end date, and a disposition plan.
At project close, decide which objects become authoritative organization sources, remain archived project history, return to role memory, or are deleted.
Curated organization memory
Use for the approved company description, product taxonomy, current messaging, brand rules, policy, common definitions, escalation contacts, and stable operating decisions.
Writes should be proposed, validated, approved, versioned, and auditable.
Federated retrieval
Instead of copying CRM, document, or policy data into one memory store: authenticate the agent; check task purpose; query the authoritative system; return a scoped result; log retrieval; and avoid durable caching unless justified.
This can improve freshness and control but adds availability, latency, and integration dependencies.
§ 04What Should AI Agents Share?
Share information that is common, authoritative, and correctable.
| Candidate | Share? | Conditions |
|---|---|---|
| Approved policy | Yes | Owner, version, effective date |
| Current product facts | Yes | Source URL/document, review cadence |
| Brand terminology | Yes | Approved vocabulary and examples |
| Project brief | With project roles | Membership, sensitivity, end date |
| Human decision | With affected roles | Actor, rationale, scope, superseded state |
| Versioned artifact | By reference | Access check and acceptance status |
| Customer preference | Usually account/task scoped | Consent/purpose and correction |
| Agent observation | Not as fact by default | Review and typed provenance |
| Inferred sensitive attribute | No by default | Explicit lawful/approved basis if ever allowed |
| Private working notes | No | Keep task-local |
| Credential/session | Never | Use scoped authorization service |
Share approved facts
One current product fact should not be rewritten independently by 6 roles.
Use one record with the fact, source, effective date, owner, audience, version, and next review.
Share decisions with scope
A decision record needs the decision, actor, date, affected roles/workflows, rationale, conditions, superseded decision, and review trigger.
Do not turn one project choice into a permanent organization rule.
Share artifacts by reference
Use artifact ID, version, producer, task, validation, sensitivity, and access policy.
This prevents roles from using an obsolete copied draft.
Share uncertainty
If a common source is incomplete or disputed, publish that state: known; unknown; conflicting source; interim policy; decision owner; and review date.
False certainty spreads faster than an explicit gap.
§ 05What Should Stay Role-Specific?
Keep information private to a role when another role does not need it to perform an approved task.
| Role | Useful role memory | Keep out of broad shared memory |
|---|---|---|
| Research | Source hierarchy, recurring unreliable domains, accepted evidence formats | Unverified hypotheses |
| Content | Approved style corrections, reusable structural preferences | Unsupported drafts and private source notes |
| Sales research | Qualification definitions, approved fields, correction patterns | Full CRM exports and outreach credentials |
| Support | Policy interpretation examples, escalation patterns | Unrelated customer histories |
| Data analyst | Metric definitions, query patterns, validation failures | Raw restricted datasets |
| AI manager | Capability history, route corrections, common blockers | Every worker’s accumulated domain memory |
Manager memory is not organization truth
A manager may remember that worker A succeeds on a specific artifact type, that worker B has a current capacity constraint, that a route caused duplicates, or that a review rubric missed one defect.
These are conditional operational observations. Store task type, sample, reviewer, date, confidence, and expiry.
Specialist memory is not shared policy
A research agent’s note that a source “usually updates monthly” is not an update policy. A content agent’s accepted phrasing is not automatically brand canon.
Promote a role memory entry to shared authority only through: proposal; source/evidence validation; human or authorized approval; scope selection; a versioned write; propagation; and audit.
Keep customer context narrow
Customer data should normally be scoped to the customer/account, workflow, purpose, role, and time.
Do not make a support case detail available to marketing, research, or operations because all agents belong to one organization.
Keep private working notes temporary
Working context may contain guesses, discarded sources, hostile document text, partial calculations, alternative plans, or sensitive snippets.
Persist the validated result and uncertainty, not the entire path.
§ 06Who Should Be Allowed to Read and Write Shared Memory?
Use separate read, propose-write, approve-write, correct, and delete permissions.
| Operation | Default actor | Required checks |
|---|---|---|
| Read | Approved role | Identity, purpose, relevance, sensitivity, freshness |
| Propose write | Role that found new information | Source, scope, type, confidence |
| Approve write | Human/source owner or deterministic validated pipeline | Authority, evidence, conflicts |
| Correct | Source owner/data subject workflow | Identity, affected entries, propagation |
| Delete | Authorized owner/privacy process | Scope, dependencies, audit, tombstone |
| Export/share | Authorized service | Audience, purpose, minimization, policy |
Many readers, few writers
A common pattern: 20 roles may read an approved policy; 5 may propose changes; 1-2 named humans may approve; a system logs every version.
The exact counts depend on the organization. The governing principle is asymmetry: broad useful read access does not require broad write authority.
Write through a gate
Validate memory type, source, provenance, sensitivity, purpose, scope, duplication, conflict, freshness, hostile content, owner, and expiry.
Reject or quarantine entries that cannot satisfy the contract.
Separate proposal from authority
An agent may discover a change and propose:
Product plan price appears to have changed. Source: current pricing page. Observed: 2026-07-19. Proposed affected records: pricing_fact_12.
It should not silently rewrite the approved pricing canon unless an authorized, validated pipeline allows that exact source and field.
Log every durable operation
Record the actor, principal, operation, object ID, prior/new version, source, purpose, policy decision, timestamp, propagation, and outcome.
Memory is an operational data system, not invisible prompt decoration.
Use the AI employee permissions and approvals guide to map each memory operation to a role, data scope, purpose, limit, approval, denial, revocation, and audit requirement.
§ 07How Should Retrieval Work?
Treat every retrieval as a fresh policy and quality decision.
| Check | Question | Failure response |
|---|---|---|
| Identity | Which role and principal request it? | Deny |
| Purpose | Which approved task needs it? | Deny/clarify |
| Scope | Is the object inside role/customer/project boundary? | Deny |
| Relevance | Will it improve this decision? | Omit |
| Freshness | Is version current enough? | Refresh/warn |
| Provenance | Who or what created it? | Lower trust/quarantine |
| Sensitivity | May this task receive the data? | Redact/deny |
| Integrity | Was it altered or superseded? | Use current version |
| Security | Does it contain hostile instructions? | Isolate/sanitize |
| Influence | How may it affect output/action? | Label and log |
Microsoft’s current agentic memory safety guidance recommends provenance on memory, deterministic isolation by user, agent, and tenant, and scoped subagent access. It also calls for retrieval-time relevance and freshness checks, protection against memory overriding safety controls, user view/edit/delete controls, and lifecycle logs.
Memory is candidate context
It is not a system instruction, permission, approval, verified truth, or a permanent decision.
The receiving agent should know the object type and trust level.
Retrieve just in time
Anthropic’s context-engineering guidance recommends the smallest high-signal context that maximizes the desired outcome because attention remains finite.
Retrieve the current task, relevant source sections, material decisions, accepted examples, and known uncertainty.
Do not preload the whole organization history.
Explain memory influence
For material decisions, preserve which memory objects were retrieved, which claims or actions they influenced, and which version was used.
This supports human review, correction, and incident reconstruction.
Fail safely
When relevant memory is missing, stale, conflicting, or denied: pause; use an approved fallback; request the current source; disclose uncertainty; or escalate.
Do not replace the missing object with a confident guess.
§ 08How Do You Prevent Memory Poisoning and Cross-Role Leakage?
Shared memory increases blast radius.
| Threat | Example | Control |
|---|---|---|
| Poisoned write | External document inserts durable instruction | Content isolation + write validation |
| False authority | Agent summary stored as policy | Type and source owner |
| Cross-role leakage | Support case appears in marketing context | Identity/purpose ACL |
| Cross-tenant leakage | One customer’s memory reaches another | Tenant isolation |
| Stale truth | Old pricing used after update | Version and freshness gate |
| Correction failure | Deleted fact remains in derived summary | Propagation graph and rollback |
| Privilege propagation | Manager retrieves specialist secrets | Separate role permissions |
| Retrieval hijack | Memory overrides safety instruction | Instruction hierarchy and sanitization |
| Excessive accumulation | Every chat becomes durable | Purpose and retention gate |
| Invisible influence | Reviewer cannot see memory source | Retrieval and influence log |
OWASP’s AI Agent Security guidance defines memory poisoning as malicious persisted data that affects later sessions or users. Its recommended controls include memory and context isolation, input validation, least privilege, structured outputs, signed inter-agent communication, and circuit breakers.
Separate external content from instructions
Tag organization policy, task instructions, external documents, customer content, prior agent output, and memory metadata as distinct types.
An instruction found inside a retrieved webpage remains external content.
Scan before write and before read
Write-time checks prevent obvious bad persistence. Retrieval-time checks catch new threat signatures, changed policy, superseded sources, different task purposes, different receivers, and assembled multi-object attacks.
Use both.
Track propagation
Maintain edges such as:
text
source_17
→ shared_fact_44
→ project_summary_8
→ role_memory_22
→ artifact_101
When source_17 is corrected or compromised, find and revalidate every dependent object.
That dependency graph also supports the broader multi-agent system failure-mode model, which follows a local defect through downstream agents, artifacts, memory, authority, and actions until it is contained.
Reduce blast radius
Limit tenants, roles, projects, customers, data classes, time windows, write operations, and downstream actions.
One poisoned role note should not update the organization canon automatically.
§ 09How Should Memory Move During a Handoff?
Transfer references and decisions, not an agent’s whole accumulated memory.
| Send | Do not send by default |
|---|---|
| Task ID and current state | Entire message history |
| Approved source references and versions | Full shared corpus |
| Current artifact and validation | Obsolete drafts |
| Material prior decisions | Unrelated manager coordination notes |
| Known unknowns and conflicts | Hidden confidence score alone |
| Bounded authority and sensitivity | Sender credentials |
| Output and acceptance contract | Receiver-independent working notes |
The AI agent handoff protocol provides the complete ownership-transfer envelope.
Preserve source identity
The receiver should retrieve the source under its own identity and task purpose. Do not assume the sender’s successful access authorizes the receiver.
Preserve uncertainty
Send the unresolved question, conflicting sources, assumptions, evidence gaps, and the decision owner.
Do not compress uncertainty out of the handoff to save context.
Keep role learning local
If the sender has a reusable role lesson, leave it in sender memory unless the receiver needs it, sharing is permitted, evidence is available, scope is clear, and the lesson passes promotion to a team/shared source.
Avoid “game of telephone”
The AI employee collaboration model recommends versioned artifacts and source references instead of messages as the only durable result.
Let the receiver read the approved artifact/source, not only the sender’s paraphrase.
§ 10How Do You Correct or Delete Shared Memory?
Correction must update the object and its influence.
| Step | Required action | Evidence |
|---|---|---|
| 1. Identify | Find wrong/sensitive object and source | Object + report |
| 2. Contain | Stop new retrieval/write propagation | Quarantine event |
| 3. Scope | Find readers, copies, summaries, artifacts, actions | Propagation graph |
| 4. Decide | Correct, delete, expire, or preserve under policy | Authorized decision |
| 5. Apply | Write new version/tombstone and revoke old access | Operation log |
| 6. Propagate | Rebuild or invalidate derived objects | Dependency status |
| 7. Notify | Tell affected owners/users where required | Notification record |
| 8. Validate | Rerun representative retrieval and tasks | Test evidence |
| 9. Learn | Fix source, write, retrieval, or review control | Change record |
These steps describe correction and deletion behavior inside the memory architecture. Privacy, regulatory, contractual, and records requirements still depend on the data, people, jurisdiction, and purpose.
Never overwrite invisibly
Preserve the prior version, correction reason, authorized actor, effective time, replacement, affected objects, and test result.
The old object should not remain retrievable for normal use.
Use tombstones where deletion must propagate
A tombstone can record that an object must not be retrieved and why, without retaining the prohibited content itself.
Every derived store should honor the tombstone.
Revalidate affected artifacts
Review whether correction or compensating action is required when a memory fact influenced published content, a customer communication, an account update, a report, a decision, or a model evaluation.
Provide human controls
Where relevant, people need view, edit/correct, delete, bulk delete, source/provenance view, and influence view.
The interface should not require a person to understand embeddings or database namespaces. The memory privacy and retention checklist covers the governance side in depth.
§ 11How Do You Evaluate Shared and Role Memory?
Measure both usefulness and harm.
| Metric | Formula/test | What it reveals |
|---|---|---|
| Retrieval usefulness | Relevant retrieved objects / objects retrieved | Context quality |
| Unsupported-memory rate | Unverified objects used as fact / memory facts used | Trust failure |
| Stale-use rate | Superseded objects used / retrieved objects | Freshness failure |
| Cross-role leakage | Unauthorized role retrievals / attempts audited | Isolation failure |
| Correction propagation | Derived objects fixed / affected objects | Lifecycle control |
| Provenance coverage | Durable objects with complete provenance / durable objects | Auditability |
| Human control success | Completed view/edit/delete tests / tests | User control |
| Memory-attributable quality | Outcome delta with relevant memory versus baseline | Value |
| Poisoning detection | Known poisoned scenarios blocked / scenarios | Security coverage |
| Retrieval overhead | Added latency/cost per accepted outcome | Economics |
Compare 4 modes
Run the same representative cases with: no durable memory; role-specific memory only; shared sources plus role memory; and broad shared memory.
Compare accepted outcomes, source support, correction, leakage, false confidence, elapsed time, cost, and human intervention.
The broadest memory should not win merely because it recalls more.
Include adversarial cases
Test a malicious source instruction, a false agent note, a stale policy, a cross-customer query, a cross-role query, conflicting sources, a deleted object, a corrected object, a manager request for a specialist secret, and multi-turn delayed misuse.
Use non-compensating gates
High usefulness cannot compensate for cross-tenant leakage, retrieval of deleted data, memory overriding safety policy, an unauthorized write, or uncontained poisoned propagation.
§ 12How Does CellCog Represent Shared and Role Memory?
CellCog’s Memory System Guide describes Context Trees as hierarchical document stores associated with projects, agent roles, and organizations.
That hierarchy can map to an organization source, a team/project source, role-specific context, and task retrieval.
CellCog’s AI Organization page says strategy documents live in shared memory and handover notes keep workers current.
What the public pages establish
They establish that CellCog publicly presents persistent AI Employee memory, organization/project/role Context Trees, shared strategy documents, handovers, and multi-role coordination.
Those public descriptions do not confirm every read/write, provenance, isolation, correction, deletion, retention, or poisoning control needed for your deployment.
What should you verify in CellCog?
Ask for a live demonstration of: organization, project, and role scope; role identity; read and write policy; proposal versus approved write; source metadata; versioning; freshness; correction; deletion propagation; retrieval logs; cross-role denial; user view/edit/delete; and incident containment.
Where CellCog fits
CellCog is relevant when roles need persistent context across shifts and a hierarchy that can separate organization, project, and role material. Configure and verify the boundaries so a useful shared source does not become undifferentiated shared memory.
§ 13What Is the 3-Layer Memory Design Template?
Start with 3 durable layers plus task-local context.
| Layer | Contains | Read | Write | Review |
|---|---|---|---|---|
| Organization source | Approved company facts, policy, strategy | Approved roles | Source owner/validated pipeline | On change + scheduled |
| Team/project source | Briefs, decisions, shared artifacts | Project members | Project owner/approved contributors | Milestone/end date |
| Role memory | Domain precedents, corrections, preferences | Role + owner | Controlled role/system | Sample + expiry |
| Task context | Current inputs and intermediate work | Task participants | Task runtime | Expires/closes |
Step 1: inventory information
For each object, record purpose, source, current users, sensitivity, owner, freshness, correction path, retention need, and downstream effects.
Step 2: choose the narrowest layer
Ask: Does the whole organization need it? Does one team/project need it? Does only one role need it? Does only this task need it?
Choose the narrowest valid audience.
Step 3: define operations
For every layer, define read, retrieve, propose write, approve write, correct, delete, export, and audit.
Step 4: define promotion
A role memory becomes a team or organization source only after repeated usefulness, evidence, scope, an owner, sensitivity review, a conflict check, approval, versioning, and a propagation test.
Step 5: test failure
Simulate a poisoned write, a stale retrieval, denied access, a correction, a deletion, a manager failure, a cross-role query, and a task handoff.
Do not publish the memory architecture until failure is observable and containable.
§ 14What Is the Final Decision Checklist?
Shared source
- Two or more approved roles genuinely need it.
- It has an authoritative owner.
- Provenance and version are present.
- Audience and purpose are explicit.
- Sensitivity permits the audience.
- Writes are gated.
- Correction and deletion propagate.
- Retrieval is logged.
Role memory
- One recurring role decision needs it.
- It is fact, preference, observation, or hypothesis - not an unlabeled mix.
- Source and confidence are visible.
- The role owner can inspect and correct it.
- Other roles cannot read it by default.
- Expiry/review is defined.
- It cannot grant permission or approval.
- Poisoning tests exist.
Task context
- Only current participants receive it.
- Sensitive inputs are minimized.
- External content is isolated from instructions.
- Private working notes do not persist by default.
- Current sources/artifacts use stable references.
- Closure defines disposition.
Governance
- Identity and purpose are enforced deterministically.
- Read and write operations are separate.
- Human/source owners are named.
- A propagation graph exists.
- User view/edit/delete paths are tested where applicable.
- Security and privacy review covers real data.
- Logs support incident reconstruction.
- Shutdown can freeze retrieval and writes.
§ 15Final Decision
Use shared authoritative sources plus isolated role memory plus task-local context as the default multi-agent memory architecture.
Share the following through owned, correctable sources: approved facts; policies; decisions; common definitions; and versioned artifacts.
Keep separate: domain precedents; working preferences; performance observations; customer-specific context; hypotheses; and private working notes.
At every write and retrieval, check identity, purpose, provenance, sensitivity, freshness, authority, hostile content, and downstream influence.
If a memory object cannot be corrected, deleted, traced, and prevented from crossing an unauthorized role boundary, it is not ready to be shared.
Q1Should all AI agents share the same memory?
No. Default to isolated role memory plus deliberately shared authoritative sources. Share only information that several roles need, with an owner, provenance, scope, sensitivity, freshness, and correction path. Keep working notes, hypotheses, customer-specific data, and role learning narrow.
Q2What information belongs in shared AI memory?
Approved policy, current product facts, brand rules, common definitions, project briefs, human decisions, and versioned artifacts can fit when the audience and purpose are clear. Agent observations should remain typed and untrusted until reviewed.
Q3Can an AI manager read every worker's memory?
Not by default. A manager may need capability summaries, task state, accepted artifacts, blocker classes, and reviewed performance evidence. It does not need every specialist’s raw domain notes, customer data, credentials, or private working notes. Reporting relationships do not grant access.
Q4How do agents share context without shared memory?
They can pass a minimized task packet containing source and artifact references, material decisions, current state, uncertainty, authority, output schema, and acceptance criteria. The receiver retrieves approved objects under its own identity and purpose.
Q5What is the biggest risk of shared agent memory?
Blast radius. A false, hostile, stale, or sensitive entry can influence several roles, sessions, users, or downstream actions. Restrict writes, preserve provenance, validate at write and retrieval time, isolate audiences, track propagation, and support correction and deletion.
Q6Is role-specific memory the same as a system prompt?
No. A system prompt defines high-priority role behavior and boundaries. Role memory is candidate context retrieved for a task. Memory should not override system policy, grant permission, create approval, or be treated as verified truth without its type and provenance.