System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.4
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, AI Manager, AI Employee Router, Task Executor Systems, Newsletter Intelligence, Course Absorption System, Opportunity System, AIBS Brain, Project Manager Brain, Content Brain, Ads Brain, Research Brain, Data Brain, Automation Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-27
Source / Origin: Existing MWMS Memory And Context Governance, AI Automations by Jack ClaudeOS Memory Systems, NotebookLM, Pinecone, External Knowledge Retrieval, Claude Code Session Continuity, WrapUp Skill, Multi Interface Memory, Persistent AI Agents, AI Agent Tool Selection Material, Runtime Instruction Material, Voice Transcription Material, And Specialist Agent Workflow Material
MWMS Classification: AI Agent Memory Framework / Context Governance Standard / Organisational Memory Architecture / Runtime Instruction Context Standard / Tool Result State Memory Standard / Action Execution Memory Standard / Business Outcome Memory Standard / Cross Tool Consistency Memory Standard / Voice Transcription Confidence Memory Standard / Memory Promotion Contract / Memory Write Contract / Specialist Agent Context Consistency Standard
Primary Brain: HeadOffice Brain
Supporting Brains: Data Brain, Automation Brain, Prompting Framework, AI Agent Operations Core, Project Manager Brain, Research Brain, AIBS Brain, Content Brain, Ads Brain, SIT Brain, Compliance Brain, Risk Brain
Related Pages: MWMS AI Agent Operations Core, MWMS Prompt Architecture And Automation Output Reliability Framework, MWMS AI Agent Orchestration Framework, MWMS AI Tool Permission And Access Framework, MWMS AI Command And Trigger Framework, MWMS AI Guardrail And Preflight Check Standard, MWMS AI Observability Metadata Standard, MWMS AI Output Validation Standard, MWMS AI Schema And Decision Ready Output Framework, MWMS AI Workflow Pipeline Standard, MWMS Agent Loop Control Framework, MWMS AI Work Session Persistence Standard, MWMS AI Work Session Closure And Knowledge Commitment Protocol, MWMS Context Engineering Framework, MWMS AI Context Activation And Usage Protocol, MWMS AI Context Routing Framework, MWMS AI Context Pack Template Standard, MWMS Context Change Propagation And Dependency Map Protocol, MWMS Context File Promotion And Approval Protocol, MWMS Context Library Governance And Folder Map Standard, MWMS Context Library Hygiene And Retired Language Rule, MWMS Tool Agnostic Context Portability Protocol, MWMS Supabase RAG And Vector Memory Framework, MWMS External Knowledge Engine And Reasoning Agent Separation Framework, MWMS Source Visibility And Evidence Display Standard, MWMS Deep Search Quality And Observability Framework, MWMS AI Agent Failure Handling And Escalation Protocol, MWMS AI Agent Outcome Measurement Framework, MWMS Client Context Isolation And Privacy Boundary Standard
Framework Purpose
This framework governs how MWMS selects, activates, limits, validates, stores, updates, promotes, retrieves, transfers, corrects, expires, deletes, and audits context and memory across AI Employees, AI agents, Brains, workflows, task systems, reporting systems, developer support, course absorption, newsletter intelligence, client systems, research systems, Project Manager Brain, chatbots, voice agents, Custom GPTs, browser copilots, dashboards, portals, knowledge assistants, and future AIBS products.
It establishes that memory is not a single store and context is not a single prompt attachment.
MWMS memory and context must distinguish between:
temporary information needed for the current task
active project and workflow state
approved durable organisational knowledge
source evidence
retrieval results
tool results
state changing action history
business outcome verification
cross tool consistency
conversation state
session state
runtime instructions
voice transcription confidence
specialist agent context packets
human approvals
governance authority
The framework also establishes that remembered information is not automatically true, current, authorised, complete, or safe to use.
Memory can guide.
Source evidence can support.
MCR governs.
Current approved instruction controls the active task.
Core Principle
Memory is useful only when it improves future work without creating false certainty.
The strongest memory system is not the one that stores the most.
It is the one that:
stores the right information
preserves source identity
separates temporary state from durable knowledge
prevents unverified facts from becoming permanent
keeps client and workspace information isolated
records tool and action state accurately
distinguishes execution from business outcome
prevents duplicate state changing actions
preserves corrections
expires stale information
supports safe handoff
makes uncertainty visible
allows deliberate promotion
supports deletion and audit
Memory And Context Objective
MWMS memory and context systems must be:
purpose aligned
source linked
authority aware
client isolated
workspace isolated
task relevant
freshness checked
versioned
correctable
auditable
portable where appropriate
bounded by permissions
safe for handoff
safe for agent reuse
safe for tool use
clear about uncertainty
clear about execution status
clear about business outcome status
Three Layer Memory Model
MWMS uses three primary memory layers.
- Working Memory
Working Memory contains temporary information required for the immediate task.
Examples:
current user instruction
current uploaded file
current question
current screenshot
current tool result
current task state
current workflow stage
current conversation history
current validation requirement
current failure history
current runtime variables
current voice transcript
current specialist output
Working Memory is temporary.
It should contain only what the current task requires.
Working Memory should not automatically become permanent memory.
Rule
Working Memory supports immediate execution.
It does not automatically become organisational truth.
- Project And Operational Memory
Project And Operational Memory contains the current validated state of active work.
Examples:
current project
current workstream
current task
current plugin version
current save point
current workflow status
current next valid action
current blocker
current approved decision
current test result
current assigned owner
current action execution state
current business outcome state
current cross tool consistency result
Project And Operational Memory supports continuity across sessions, interfaces, people, agents, and systems.
It must be treated as last known state unless refreshed.
Rule
Project memory must remain linked to the project, workstream, task, workflow, client, workspace, source records, version, and date that produced it.
- Durable Organisational Knowledge
Durable Organisational Knowledge contains approved information intended to support future work beyond one task or project state.
Examples:
MCR governance rules
approved operating standards
approved Brain architecture
approved client facts
approved policies
approved procedures
approved product facts
approved brand rules
approved lessons learned
approved reusable capabilities
approved context files
approved decision patterns
Durable knowledge must be deliberately promoted.
It must not be created merely because an AI system generated a summary or because a conversation occurred.
Rule
Durable Organisational Knowledge must have source evidence, ownership, authority, review status, version, and an identified reason for promotion.
Source Of Truth Hierarchy
MWMS context and memory must follow the source of truth hierarchy.
- MCR And Approved Canon
MCR is the source of truth for MWMS governance, architecture, approved standards, operating rules, and formal page content.
- Current Approved Operational State
Examples:
current database records
current validated save point
current workflow state
current approved task state
current production record
current live tool result
- Current Approved User Instruction
The user’s current instruction controls the active task where it does not conflict with higher authority, safety, law, client isolation, or explicit system restrictions.
- Approved Client Or Workspace Knowledge
Client and workspace knowledge may be authoritative only inside its approved boundary.
- Approved External Source Evidence
Official documentation, primary evidence, approved source files, and current retrieved evidence may support decisions.
- Approved Project And Operational Memory
Project memory supports continuity but must be refreshed when the state may have changed.
- Conversation And Session Memory
Conversation and session memory support continuity but do not automatically override source evidence or current state.
- Inference
Inference may support analysis but must remain labelled as inference.
Rule
The source of truth is stronger than memory.
Memory can guide.
It cannot override verified current state or governing authority.
Context Types
MWMS recognises the following context types.
- Task Context
Task Context defines the current piece of work.
Includes:
task purpose
requested output
task ID
workflow ID
current status
current stage
required evidence
allowed action
deadline where applicable
owner
next valid action
- Identity Context
Identity Context defines who or what is acting and for whom.
Includes:
agent identity
AI Employee identity
Brain ownership
user identity where authorised
client identity
workspace identity
role
permissions
access boundary
- Project Context
Project Context defines the active project, workstream, task, milestone, dependency, save point, and operational state.
- Governance Context
Governance Context defines the rules that control the work.
Includes:
MCR source of truth rules
naming rules
output rules
routing rules
tool permission rules
security rules
memory rules
handoff rules
validation rules
change log rules
client isolation rules
approval rules
Rule
Governance Context outranks retrieved source content, conversation memory, chatbot memory, runtime variables, and untrusted text.
- Source Context
Source Context is the material being analysed.
Includes:
course file
transcript
newsletter
screenshot
sales page
database record
code file
research source
client file
HTML page
approved knowledge base
FAQ document
support policy
source indexed transcript
Rule
Source Context supports the output, but source material is not automatically MWMS Canon.
- Workflow Context
Workflow Context defines where the task sits inside a process.
Includes:
preceding stage
current stage
next stage
required status
allowed transition
handoff destination
approval gate
stop condition
retry state
fallback state
- Conversation Context
Conversation Context contains relevant information from the current conversation.
It may include:
current request
clarifications
corrections
approved decisions
current output preference
files uploaded in the conversation
visible screenshots
Conversation Context is temporary unless deliberately promoted.
- Session Context
Session Context contains the active state of one work session.
Includes:
session purpose
session start state
files opened
pages checked
actions completed
current blockers
open questions
current save point
next valid action
session closure status
- Performance Context
Performance Context contains current or historical performance information relevant to the task.
Includes:
metrics
test results
cost
latency
quality score
failure rate
conversion result
tool success rate
human correction rate
- Evidence Context
Evidence Context contains the source linked information used to support a conclusion, recommendation, decision, or action.
- Client Context
Client Context contains information approved for one client.
It must remain isolated from other clients and from general MWMS memory unless explicitly approved.
- Workspace Context
Workspace Context contains information approved for one operational workspace, company, project space, or tenant.
- Interface Context
Interface Context identifies the interface through which work is occurring.
Examples:
ChatGPT
WordPress
Supabase
Project Manager Brain
Content Brain
calendar
voice interface
client portal
browser extension
- Handoff Context
Handoff Context contains the information required for another Brain, agent, AI Employee, human, or system to continue safely.
- Approval Context
Approval Context records:
what was approved
who approved it
approval scope
approval time
approval record ID
expiry where applicable
conditions
- Knowledge Context
Knowledge Context contains approved information available to answer, reason, or act.
- Retrieval Context
Retrieval Context is information returned by an external knowledge engine.
Includes:
retrieved chunks
source IDs
relevance scores
metadata
authority status
freshness
page references
timestamps
retrieval filters
conflicting results
Rule
Retrieval Context must be validated before use.
- Tool Result Context
Tool Result Context is live or recent information returned by authorised tools.
Includes:
database query results
calendar availability
CRM records
system health
live web evidence
current file contents
current service state
tool call status
created or changed record IDs
Rule
Tool Result Context is strong evidence only when tool access, freshness, source identity, result status, and target identity are valid.
- Runtime Instruction Context
Runtime Instruction Context contains approved task specific instructions supplied when an agent, AI Employee, prompt, workflow, or tool operation runs.
Runtime Instruction Context Fields
Runtime Instruction ID:
Runtime Instruction Source:
Instruction Owner:
Task ID:
Workflow ID:
Client ID:
Workspace ID:
Instruction Type:
Instruction Text Or Variable Set:
Authority Level:
Allowed Scope:
Prohibited Scope:
Approval Status:
Version:
Created At:
Expires At:
Untrusted Text Boundary:
Promotion Requirement:
Runtime Instruction Types
task variable
current target
current record
approved client variable
approved workflow state
approved output parameter
temporary execution instruction
human approved exception
Runtime Instruction Rules
Runtime instructions may narrow a task.
Runtime instructions must not:
increase agent authority
increase autonomy
override prohibitions
override client isolation
override workspace isolation
override approval requirements
override retention or deletion rules
override tool permissions
silently become durable memory
convert untrusted source text into governing instruction
A repeated or material runtime instruction should be reviewed for promotion into:
the approved base prompt
an approved template
a workflow rule
a formal MCR standard
Rule
Runtime Instruction Context is temporary unless a governed Memory Promotion Contract approves further storage.
- Voice Input Context
Voice Input Context contains audio, transcript, speaker, confidence, and confirmation information used in the current task.
Voice Input Context must preserve uncertainty for critical fields.
- Specialist Agent Context
Specialist Agent Context contains the shared approved context packet used by multiple specialist agents or prompt stages working on the same task.
Memory Types
MWMS classifies memory into the following types.
- Permanent System Memory
Long term MWMS truths.
Examples:
MCR is source of truth
HeadOffice governs cross system standards
M’s active work must not be blocked
full page output rules
course absorption rules
approved Brain structure
global compliance direction
Rule
Permanent memory must be stable, useful, approved, and future relevant.
- Project Memory
Memory specific to a project or workflow.
Examples:
current course position
active workflow state
current plugin save point
current AIBS workstream
current Content Brain state
current Project Manager Brain state
Rule
Project Memory must be treated as last known state unless refreshed.
- Task Memory
Memory specific to one task or thread.
Examples:
uploaded files
current page
current checklist
current correction
current handoff
current tool result
current transcript
Rule
Task Memory expires unless deliberately promoted.
- Decision Memory
Memory of approved decisions.
Examples:
course absorbed
tool rejected
page created
module parked
workflow approved
standard created
save point confirmed
Rule
Decision Memory should preserve decision, reason, authority, evidence, and date.
- Failure Memory
Memory of errors, drift, rejected actions, and failure modes.
Examples:
wrong output format
stale context used
duplicate action attempted
tool call failed
tool result misread
business outcome not verified
cross tool mismatch
uncertain transcript treated as fact
wrong client context loaded
Rule
Failure Memory should support prevention, testing, and correction.
- Preference Memory
Stable user or client preferences that materially improve future work.
Preference Memory must not include random, overly personal, short lived, or unapproved sensitive details.
- Conversation Memory
Memory of relevant conversation state.
Conversation Memory is not automatically durable.
- Session Summary Memory
A structured summary created at session closure.
Session Summary Memory may include:
session purpose
starting state
work completed
decisions made
files changed
versions changed
tests completed
failures
blockers
current save point
next valid action
sources used
approval status
- Knowledge Base Memory
Approved knowledge stored for retrieval.
- Database Backed Assistant Memory
Structured memory stored in an approved database.
- Source Memory
Durable storage of original source material.
Examples:
course PDFs
transcripts
newsletters
research reports
videos
screenshots
source documents
client files
Rule
Source Memory must preserve source identity, version, ownership, and provenance.
- Retrieval Memory
Records of what was retrieved and used.
Includes:
query
filters
sources returned
chunks selected
model receiving context
decision supported
retrieval date
- Tool Result State Memory
Tool Result State Memory records the exact technical state of an authorised tool call.
Tool Result State Values
Tool Call Requested
Tool Call Accepted
Tool Call Succeeded
Tool Call Failed
Tool Call Partially Succeeded
Tool Call Rejected
Tool Call Timed Out
Tool Call Status Unknown
Tool Result State Memory Fields
Tool Call ID:
Task ID:
Workflow ID:
Client ID:
Workspace ID:
Tool Name:
Tool Version:
Requested Action:
Target:
Requested At:
Accepted At:
Completed At:
Technical Status:
Tool Response:
Changed Record IDs:
External Message ID:
Calendar Event ID:
Task Record ID:
Partial Failure Details:
Retry Permitted:
Validation Result:
Source Evidence:
Rule
Tool Result State Memory must preserve the technical state exactly.
It must not convert:
Tool Call Requested
into:
Tool Call Succeeded
It must not convert:
Tool Call Succeeded
into:
Business Outcome Verified
- Action Execution Memory
Action Execution Memory records state changing actions so later agents, workflows, interfaces, and sessions can determine whether an action already occurred.
Action Execution Memory Fields
Action ID:
Task ID:
Workflow ID:
Client ID:
Workspace ID:
Agent Or Human:
Tool:
Tool Call ID:
Requested Action:
Target:
Requested At:
Executed At:
Execution Status:
Idempotency Key:
Prior Execution Check:
Changed Record IDs:
Approval Record:
Retry Status:
Reversal Status:
Reversal Record ID:
Failure Details:
Current Owner:
Examples
email sent
calendar event created
task created
CRM record updated
document published
database record changed
record archived
record restored
payment request created
external communication sent
Rule
Before repeating a state changing action, the system must check Action Execution Memory and the current source system.
Memory alone is not sufficient when the external state may have changed.
- Business Outcome Memory
Business Outcome Memory records whether the intended business result occurred.
Business Outcome Memory Fields
Outcome ID:
Task ID:
Workflow ID:
Client ID:
Workspace ID:
Intended Outcome:
Technical Action:
Related Tool Call IDs:
Related Action IDs:
Business Outcome Status:
Verification Evidence:
Verification Source:
Verified At:
Mismatch:
Follow Up Required:
Final Owner:
Final Resolution:
Business Outcome Status Values
Business Outcome Verified
Business Outcome Not Verified
Business Outcome Partially Verified
Business Outcome Failed
Business Outcome Pending
Business Outcome Not Applicable
Examples
calendar event created but attendee not confirmed
email sent but response not received
lead record created but qualification incomplete
task created but assigned to wrong project
document generated but not stored in approved location
content published and public page verified
Rule
Technical execution and business completion must remain separate memory states.
- Cross Tool Consistency Memory
Cross Tool Consistency Memory records whether multiple tools used for one task produced matching results.
Cross Tool Consistency Memory Fields
Consistency Record ID:
Task ID:
Workflow ID:
Client ID:
Workspace ID:
Tools Compared:
Tool Call IDs:
Fields Compared:
Expected Match:
Observed Match:
Consistency Status:
Mismatch:
Risk:
Resolution:
Reviewer:
Final Status:
Consistency Status Values
Consistent
Minor Mismatch
Material Mismatch
Critical Mismatch
Unable To Verify
Examples
calendar event matches email confirmation
lead identity matches CRM record
task project matches Project Manager Brain
document link matches stored record
recipient matches approved contact
amount and currency match approved terms
final response matches tool evidence
Rule
A material or critical mismatch must block completion until corrected or escalated.
- Voice Transcription Confidence Memory
Voice Transcription Confidence Memory records audio, transcription uncertainty, corrections, and confirmed meaning.
Voice Transcription Confidence Memory Fields
Audio Record ID:
Task ID:
Workflow ID:
Client ID:
Workspace ID:
Speaker Identity:
Speaker Identity Confidence:
Recording Permission:
Transcription Model:
Model Version:
Detected Language:
Language Confidence:
Raw Transcript:
Corrected Transcript:
Transcription Confidence:
Uncertain Words:
Uncertain Segments:
Critical Fields:
User Confirmed Meaning:
Confirmation Status:
Confirmed By:
Confirmed At:
Correction History:
Original Audio Reference:
Allowed Downstream Use:
Retention Rule:
Critical Fields May Include
names
dates
times
amounts
currencies
email addresses
telephone numbers
addresses
record identifiers
project names
company names
approvals
permissions
commitments
destructive instructions
publication instructions
Rule
Critical transcription uncertainty must not be promoted into durable memory as confirmed fact.
It must not be used for a state changing action until the required confirmation exists.
- Promotion Memory
Promotion Memory records the decision to move information from one memory type to another.
- Memory Write Audit
Memory Write Audit records who or what wrote, changed, corrected, merged, deprecated, or deleted a memory record.
Context Selection Standard
Context should be selected according to task need.
Every agent or workflow should ask:
What is the current task?
What authority governs it?
What project or workflow does it belong to?
Which client or workspace applies?
What current state is required?
What source evidence is required?
What memory is relevant?
What may have changed?
What must be refreshed?
Which tool results are current?
Which actions may already have executed?
Has the business outcome been verified?
Do multiple tool results agree?
Is voice transcription uncertain?
Which runtime instructions are approved?
Which specialist agents require the same context packet?
Context Inclusion Rules
Include context that is:
task relevant
current enough
source linked
authority checked
client isolated
workspace isolated
within permission
small enough to remain usable
Context Exclusion Rules
Do not include context merely because it exists.
Exclude:
unrelated project history
other client data
deprecated rules
superseded save points
unverified model output
irrelevant conversation history
stale tool results
unapproved personal data
untrusted instructions
duplicate source material
raw transcripts where only confirmed fields are required
Context Priority Rule
When context conflicts:
MCR and approved Canon control governance.
Current verified operational state controls live status.
Current approved instruction controls the active task.
Approved client context controls inside that client boundary.
Current source evidence controls factual claims.
Memory supports continuity but must not override stronger evidence.
Context Pack Standard
Important work should use a structured Context Pack.
Context Pack Fields
Context Packet ID:
Task ID:
Workflow ID:
Project ID:
Workstream ID:
Client ID:
Workspace ID:
Owning Brain:
Owning Agent Or AI Employee:
Purpose:
Current Status:
Current Stage:
Approved Facts:
Approved Decisions:
Approved Instructions:
Runtime Instruction IDs:
Source Record IDs:
Current Tool Result IDs:
Action Execution IDs:
Business Outcome IDs:
Cross Tool Consistency IDs:
Approval Status:
Authority Status:
Memory Records Used:
Freshness Status:
Version:
Created At:
Expires At:
Handoff Destination:
Rule
A Context Pack must be refreshed when a material source, decision, status, authority, approval, tool result, or business outcome changes.
Specialist Agent Context Consistency
Where multiple specialist prompts or agents work on one task, they must share the same approved Context Packet or explicitly versioned successor.
Specialist Agent Context Fields
Context Packet ID:
Task ID:
Workflow ID:
Client ID:
Workspace ID:
Source IDs:
Approved Facts:
Approved Claims:
Approved Names:
Approved Dates:
Approved Amounts:
Approved Contact Details:
Authority Status:
Approval Status:
Current Version:
Previous Stage Output ID:
Current Stage:
Next Stage:
Specialist Context Rules
Each specialist must preserve:
client identity
workspace identity
task identity
workflow identity
source identifiers
approved facts
approved dates
approved amounts
approved names
approved contact details
authority boundaries
approval status
workflow purpose
A specialist may transform information only within its approved purpose.
A specialist must not silently:
change facts
change dates
change amounts
change recipients
change clients
change claims
increase authority
change approval status
change the intended outcome
Specialist Handoff Fields
Stage Name:
Stage Purpose:
Input Record ID:
Input Context Version:
Required Fields:
Allowed Transformations:
Prohibited Transformations:
Output Contract:
Output Record ID:
Validation Result:
Next Stage:
Handoff Status:
Rule
Prompt chains and specialist agent chains must preserve factual, operational, and authority consistency from first input to final outcome.
Memory Promotion Contract
Purpose
The Memory Promotion Contract governs deliberate movement of information from temporary or lower authority memory into a more durable or authoritative memory store.
Promotion Examples
Task Memory to Project Memory
Conversation Memory to Approved Preference Memory
Session Summary Memory to Project Memory
Validated project lesson to Durable Organisational Knowledge
Confirmed voice transcript field to Project Memory
Verified business outcome to Decision Memory
Approved runtime rule to an MCR governed standard
Memory Promotion Contract Fields
Promotion ID:
Source Memory Record ID:
Source Memory Type:
Target Memory Type:
Proposed Fact Or State:
Source Evidence:
Source Record IDs:
Promotion Reason:
Client ID:
Workspace ID:
Authority:
Reviewer:
Approval Status:
Conflict Check:
Duplicate Check:
Freshness Review:
Sensitive Data Review:
Retention Rule:
Promoted Record ID:
Promotion Date:
Next Review Date:
Promotion Conditions
Information may be promoted only when:
the source is identifiable
the information is relevant beyond the current task
the target memory type is appropriate
freshness is sufficient
conflicts have been checked
duplicates have been checked
authority is sufficient
client and workspace boundaries are correct
required consent exists
required human approval exists
uncertainty is resolved or preserved
Rule
Conversation, tool output, transcript, retrieval result, and model summary must not become durable truth merely because they are available.
Memory Write Contract
Purpose
The Memory Write Contract governs every creation, update, correction, merge, deprecation, or deletion of governed memory.
Memory Write Contract Fields
Write Request ID:
Writer:
Writer Type:
Owning Brain:
Task ID:
Workflow ID:
Client ID:
Workspace ID:
Target Memory Store:
Target Memory Type:
Target Record ID:
Write Action:
Proposed Value:
Source Evidence:
Source Record IDs:
Required Approval:
Approval Record ID:
Validation Rules:
Duplicate Check:
Conflict Check:
Freshness Check:
Sensitive Data Check:
Retention:
Correction Method:
Deletion Method:
Audit Record:
Write Result:
Write Actions
create
update
correct
merge
deprecate
archive
restore
delete
promote
Who May Write
Only approved:
humans
Brains
AI Employees
agents
automation workflows
system services
may write to governed memory.
Write authority must be explicit.
What May Be Written
Only fields permitted by the target Memory Write Contract may be written.
Prohibited fields must be defined.
Validation Requirements
Before writing, confirm:
correct client
correct workspace
correct target record
source evidence
allowed field
data type
freshness
duplicate status
conflict status
approval
retention
sensitive data rules
Rule
Customer facing AI and autonomous agents must not silently create important long term memory without an approved Memory Write Contract.
Memory Update Rules
Memory should be updated when:
a verified fact changes
a project status changes
a new approved decision supersedes an old decision
a tool action executes
a business outcome is verified
a cross tool mismatch is resolved
a transcript is corrected
a runtime instruction is promoted
a source is replaced
an error is confirmed
an approval changes
Memory should not be updated when:
the model is merely guessing
the source is unverified
the user has not approved a critical correction
the record belongs to another client
the target memory store is unknown
authority is missing
the information is too temporary
the action result is still uncertain
the business outcome is not verified
Memory Conflict Resolution
When memory conflicts with current evidence:
identify each conflicting record
identify authority
identify source
identify date
identify version
identify client and workspace
identify whether one record supersedes another
preserve the conflict until resolved
do not silently overwrite
route high risk conflicts for review
Conflict Resolution Status Values
Current Record Confirmed
Older Record Superseded
Both Records Valid In Different Scope
Source Conflict Unresolved
Human Review Required
Memory Hygiene
MWMS memory systems must be reviewed for quality.
Memory hygiene includes:
removing duplicates
marking deprecated records
correcting stale facts
merging repeated records
verifying ownership
preserving reason and date
checking client isolation
checking workspace isolation
checking source provenance
checking whether temporary memory was wrongly promoted
checking whether old save points remain active
checking whether memory conflicts with Canon
checking tool result states
checking duplicate state changing actions
checking unverified business outcomes
checking cross tool mismatches
checking uncertain transcripts
checking unexpired runtime instructions
checking specialist context drift
Memory hygiene should occur:
during scheduled review
at session closure
before promotion
after major project change
after client offboarding
after a failed agent action
after a duplicate action warning
after a material correction
before high risk reuse
Freshness And Expiry
Context and memory may be:
Current Context
Current session, file, screenshot, database query, tool result, runtime instruction, voice input, or user instruction.
Recent Context
Recent save points, decisions, outcomes, or operational state.
Stable Context
Long term rules and preferences unlikely to change.
Stale Context
Information likely to have changed.
Deprecated Context
Information replaced by newer decisions.
Unverified Context
Information not yet validated.
Historical Context
Preserved for reference but not current instruction.
Expired Context
Context that passed its allowed use period.
Rule
Freshness and authority must both be considered.
Fresh but low authority content does not override Canon.
Stable but old operational state must still be refreshed when the real state may have changed.
RAG And External Knowledge Governance
External knowledge engines may store, retrieve, rank, filter, and return source material.
They do not own reasoning authority.
RAG systems must preserve:
source identity
source type
source location
page, section, line, or timestamp where available
source date
ingestion date
version
status
authority
owner
confidence
retrieval date
client identity
workspace identity
retrieval filters
Chunking, embedding, and summarisation must not remove provenance.
Rule
No important conclusion should become detached from the evidence that produced it.
Chunking Standard
Large documents may be divided into chunks for retrieval.
Good chunks should preserve:
heading
topic
sequence
neighbouring meaning
source ID
page or timestamp
client ownership
Brain ownership
authority
version
Poor chunking can create:
false meaning
missing conditions
misleading excerpts
wrong client retrieval
detached claims
RAG Validation
Retrieved material should be:
filtered
validated
authority checked
freshness checked
source linked
client isolated
workspace isolated
task relevant
Retrieval Failure Rule
When retrieval fails, the agent must not fabricate missing knowledge.
It must:
report the failure
identify missing evidence
use an approved fallback where available
stop or escalate where evidence is required
Chatbot Memory Layers
A chatbot, voice agent, Custom GPT, browser copilot, client portal, dashboard assistant, or knowledge assistant may use:
Conversation Memory
current dialogue and immediate state
Long Term Assistant Memory
approved durable preferences or facts
Knowledge Context
approved knowledge base and RAG sources
Tool Context
current authorised tool results
Database Backed Memory
structured approved memory records
Governance Context
rules, permissions, exclusions, and handoff triggers
Rule
Governance Context outranks all other chatbot memory layers.
Chatbot Memory Governance
Before deploying serious chatbot memory, MWMS must define:
what is remembered during the conversation
what expires after the session
what may be stored long term
what must never be stored
storage location
access rights
edit rights
deletion rights
consent requirements
client isolation
workspace isolation
memory visibility
action triggers
correction process
stale memory review
handoff rules
voice transcription confidence rules
runtime instruction boundaries
tool result state handling
business outcome verification
Rule
Chatbot memory must be designed before the chatbot is trusted.
Dynamic Memory Update Rule
Some AI systems may update memory dynamically.
Examples:
saving user preferences
storing customer details
recording support outcomes
saving lead qualification answers
updating CRM records
storing client specific facts
recording tool actions
recording business outcomes
Dynamic memory updates require:
defined writable fields
prohibited fields
validation
consent where required
human approval where required
logging
correction
deletion
client isolation
workspace isolation
stale memory review
duplicate check
conflict check
source evidence
Rule
Dynamic memory updates must use the Memory Write Contract.
Human Handoff Memory Rule
When work transfers to a human, the handoff must preserve:
task
client
workspace
current state
source evidence
decisions
uncertainty
tool actions
business outcome status
cross tool consistency status
approvals
failures
next valid action
Voice Agent Memory
Voice agent memory may include:
call state
speaker identity where permitted
conversation state
tool results
consent context
approved customer details
post call summary
transcription confidence
critical field confirmation
Voice Agent Memory must not:
store uncertain critical fields as confirmed fact
invent speaker identity
treat a raw transcript as authority
store restricted data without permission
take state changing action from uncertain transcription
Session Closure And Knowledge Commitment
At the end of an important session, the system should create a structured closure record.
Session Closure Fields
Session ID:
Session Purpose:
Starting State:
Work Completed:
Decisions Made:
Files Or Pages Changed:
Versions Changed:
Tools Used:
Actions Executed:
Business Outcomes:
Cross Tool Consistency:
Failures:
Corrections:
Approvals:
Current Save Point:
Next Valid Action:
Open Blockers:
Memory Promotion Candidates:
Memory Writes Completed:
Memory Writes Rejected:
Sources Used:
Session Closed By:
Session Closed At:
Rule
Session outcomes must be committed deliberately.
A conversation ending is not the same as a session being safely closed.
Cross Interface Continuity
Where the same work may continue across ChatGPT, WordPress, Supabase, Project Manager Brain, Content Brain, email, calendar, voice, client portal, or another interface, each interface must use the same approved project, task, context, version, and memory identifiers.
Cross Interface Continuity Fields
Project ID:
Workstream ID:
Task ID:
Workflow ID:
Client ID:
Workspace ID:
Context Packet ID:
Current Save Point ID:
Current Version:
Current Status:
Current Owner:
Next Valid Action:
Last Refreshed:
Rule
Different interfaces must not maintain different versions of truth without an explicit reconciliation process.
Observability
Memory and context systems should record:
memory record ID
memory type
context type
task ID
workflow ID
project ID
client ID
workspace ID
source record IDs
authority
owner
version
created at
updated at
expires at
freshness status
approval status
promotion status
writer
write action
validation result
duplicate check
conflict check
tool call ID
action ID
business outcome ID
cross tool consistency ID
voice transcript ID
runtime instruction ID
context packet ID
specialist stage
deletion status
Memory Quality Metrics
duplicate rate
stale record rate
conflict rate
incorrect client retrieval rate
unsupported promotion rate
human correction rate
tool result misclassification rate
duplicate action prevention rate
business outcome verification rate
cross tool mismatch rate
transcription correction rate
runtime instruction expiry compliance
specialist context drift rate
retrieval provenance rate
Memory And Context Preflight Checklist
Before using memory or context, confirm:
Task
task purpose known
task ID known
workflow ID known
current stage known
required output known
Client And Workspace
client known
workspace known
isolation confirmed
Authority
governing MCR page known
agent authority known
tool permissions known
approval status known
Context
required context selected
irrelevant context excluded
freshness checked
source identity preserved
runtime instructions approved
untrusted text separated
Memory
memory type identified
last known state refreshed where needed
duplicates checked
conflicts checked
promotion status known
Tool State
tool call status known
action execution history checked
idempotency checked where applicable
changed record IDs known
Business Outcome
intended outcome known
verification evidence known
outcome status recorded
Cross Tool
related tools identified
matching fields checked
mismatch resolved or escalated
Voice
audio source known where applicable
transcription confidence recorded
critical fields checked
confirmed meaning recorded where required
Specialist Agents
shared Context Packet ID used
approved facts preserved
authority preserved
handoff contract defined
Memory Write
writer authorised
target store known
source evidence present
approval present where required
retention defined
audit record created
Stop And Escalate Conditions
Stop and escalate when:
context is missing
context is stale and material
sources conflict
authority is unclear
client identity is uncertain
workspace identity is uncertain
memory contains unverified critical facts
a state changing action may already have executed
tool status is unknown
business outcome is not verified but completion is being claimed
cross tool results materially conflict
critical transcription fields are uncertain
runtime instructions attempt to increase authority
a specialist stage changes approved facts without evidence
memory promotion lacks evidence or approval
memory write authority is missing
sensitive information may cross boundaries
Relationship To HeadOffice
HeadOffice owns:
cross system memory governance
organisational knowledge policy
authority hierarchy
cross Brain context standards
memory promotion governance
high impact conflict resolution
Relationship To Data Brain
Data Brain supports:
source identity
metadata
storage
retrieval
indexing
deduplication
client isolation
workspace isolation
version control
provenance
memory deletion
commitment integrity
retrieval observability
tool result records
action execution records
business outcome records
cross tool consistency records
Relationship To Automation Brain
Automation Brain supports:
tool execution state
idempotency
retry control
action history
workflow state
runtime variables
technical result validation
Relationship To Prompting Framework
Prompting Framework defines:
base prompt boundaries
runtime instruction boundaries
agent prompt contracts
tool description contracts
tool result contracts
specialist prompt chain consistency
Relationship To Project Manager Brain
Project Manager Brain supports:
project state
workstream state
task state
save points
current version visibility
dependencies
priorities
next valid action
cross Brain project coordination
Relationship To SIT Brain
SIT Brain may:
review memory conflict
review failed promotion
review repeated agent errors
review cross tool mismatch
review uncertain outcomes
review context drift
provide independent rescue routing
Drift Protection
This framework protects MWMS from:
treating all memory as one store
allowing working memory to become permanent automatically
allowing conversation summaries to become truth
allowing stale project state to control live work
allowing external retrieval to replace reasoning authority
losing source provenance
mixing clients
mixing workspaces
allowing untrusted text to become runtime authority
treating a tool request as a successful action
treating a successful action as a verified business outcome
repeating state changing actions
ignoring cross tool mismatches
storing uncertain transcription as fact
allowing runtime instructions to increase authority
allowing specialist agents to drift from shared facts
writing long term memory without a contract
promoting memory without evidence
Drift Signals
“The agent will remember.”
“The previous chat said it was done.”
“The tool accepted the request, so the outcome happened.”
“We can run it again.”
“The transcript is probably right.”
“The runtime instruction can override the base prompt.”
“The next agent can fix the details.”
“The context packet is close enough.”
“We can save it now and verify later.”
Rule
When these drift signals appear, return to source hierarchy, context type, memory type, current state, tool result status, action execution history, business outcome verification, cross tool consistency, voice transcription confidence, runtime instruction authority, specialist context consistency, Memory Promotion Contract, Memory Write Contract, and explicit approval.
Implementation Sequence
Phase 1: Identify Memory And Context Need
Define:
task
workflow
project
client
workspace
authority
required sources
required current state
Phase 2: Select Context
Create or refresh:
Task Context
Project Context
Governance Context
Source Context
Workflow Context
Runtime Instruction Context where applicable
Tool Result Context where applicable
Voice Input Context where applicable
Specialist Agent Context where applicable
Phase 3: Select Memory
Choose only the required memory types.
Check:
freshness
authority
client isolation
workspace isolation
duplicates
conflicts
promotion status
Phase 4: Execute And Record
Record:
tool call state
action execution state
business outcome state
cross tool consistency
voice corrections
specialist handoffs
Phase 5: Validate
Validate:
source provenance
current state
authority
approval
tool result meaning
business outcome
cross tool agreement
critical transcription fields
runtime instruction boundary
specialist context consistency
Phase 6: Write Or Promote
Use:
Memory Write Contract
Memory Promotion Contract
Do not write or promote by default.
Phase 7: Close Session
Record:
completed work
decisions
actions
outcomes
failures
save point
next valid action
promotion candidates
Change Log
Version: v1.4
Date: 2026-06-27
Author: HeadOffice
Change:
Updated the MWMS AI Agent Memory And Context Framework with a focused agent runtime, tool state, action history, outcome verification, transcription confidence, memory promotion, memory write, and specialist context consistency expansion.
Preserved the existing three layer memory model covering Working Memory, Project And Operational Memory, and Durable Organisational Knowledge.
Preserved the existing source hierarchy, context types, RAG governance, source provenance, chunking, retrieval controls, chatbot memory, voice agent boundaries, session closure, memory hygiene, client isolation, cross interface continuity, and external knowledge engine separation.
Added Runtime Instruction Context covering:
Runtime Instruction Source
Instruction Owner
Task ID
Workflow ID
Instruction Type
Authority Level
Allowed Scope
Expiry
Version
Approval Status
Untrusted Text Boundary
Promotion Requirement
Established that runtime instructions may narrow a task but must not increase authority, increase autonomy, override prohibitions, override isolation, override approvals, or silently become durable memory.
Added Tool Result State Memory distinguishing:
Tool Call Requested
Tool Call Accepted
Tool Call Succeeded
Tool Call Failed
Tool Call Partially Succeeded
Tool Call Rejected
Tool Call Timed Out
Tool Call Status Unknown
Added Action Execution Memory covering:
Action ID
Task ID
Workflow ID
Tool
Requested Action
Target
Requested At
Executed At
Execution Status
Idempotency Key
Prior Execution Check
Changed Record IDs
Approval Record
Retry Status
Reversal Status
Added Business Outcome Memory separating technical execution from verified business completion.
Added Cross Tool Consistency Memory covering:
Tools Compared
Fields Compared
Consistency Status
Mismatch
Resolution
Reviewer
Final Status
Added Voice Transcription Confidence Memory covering:
Audio Record ID
Raw Transcript
Corrected Transcript
Transcription Model
Detected Language
Confidence
Uncertain Words
Critical Fields
User Confirmed Meaning
Confirmation Status
Correction History
Added a formal Memory Promotion Contract covering:
Source Memory Type
Target Memory Type
Proposed Fact
Source Evidence
Promotion Reason
Authority
Reviewer
Approval Status
Conflict Check
Duplicate Check
Freshness Review
Promoted Record ID
Promotion Date
Added a formal Memory Write Contract covering:
Who May Write
What May Be Written
Source Evidence
Target Memory Store
Client Or Workspace
Required Approval
Validation
Duplicate Check
Conflict Check
Retention
Correction
Deletion
Audit Record
Added Specialist Agent Context Consistency requiring all specialist prompts and agents in one workflow to share:
Context Packet ID
Task ID
Workflow ID
Client ID
Workspace ID
Source IDs
Approved Facts
Authority Status
Approval Status
Current Version
Added specialist handoff controls preventing silent changes to approved facts, dates, amounts, recipients, clients, claims, authority, approval status, and intended outcome.
Purpose of update:
To extend the existing organisational memory architecture so that MWMS can accurately preserve agent runtime instructions, tool call state, state changing action history, business outcome verification, cross tool agreement, voice transcription confidence, governed memory writes, governed memory promotion, and shared context consistency across specialist agent chains.
Version: v1.3
Date: 2026-06-17
Author: HeadOffice
Change:
Updated the MWMS AI Agent Memory And Context Framework using the AI Automations by Jack block covering ClaudeOS memory systems, NotebookLM, Pinecone, external knowledge retrieval, Claude Code session continuity, WrapUp Skill, multi interface memory, and persistent AI agents.
Added a formal three layer memory model covering Working Memory, Project And Operational Memory, and Durable Organisational Knowledge.
Added External Knowledge Engine Separation to distinguish source storage and retrieval from reasoning and execution.
Added Session Context as a formal context type.
Added Retrieval Context and Tool Result Context.
Added Session Summary Memory, Source Memory, and Retrieval Memory.
Expanded RAG governance to include source provenance, authority, retrieval filters, freshness, and retrieval logging.
Added Memory Hygiene, duplicate prevention, stale memory control, and conflict resolution.
Added Session Closure And Knowledge Commitment.
Added cross interface continuity and tool agnostic context portability.
Purpose of update:
To evolve the MWMS AI Agent Memory And Context Framework into a complete organisational memory and context governance system that supports temporary work, active projects, durable knowledge, session closure, source grounded retrieval, cross interface continuity, chatbot memory, and client isolated AIOS memory.
Version: v1.2
Date: 2026-05-31
Author: HeadOffice
Change:
Added chatbot specific memory governance covering short term conversation memory, long term assistant memory, business knowledge, RAG sources, tools, database backed memory, dynamic memory updates, and human handoff logic.
Expanded Scope to include chatbots, voice AI systems, Custom GPTs, browser copilots, client dashboards, portals, knowledge assistants, and customer facing support agents.
Added Conversation Context, Long Term Assistant Memory, and Knowledge Context.
Expanded Memory Types with Conversation Memory, Knowledge Base Memory, and Database Backed Assistant Memory.
Added Chatbot Memory Layers, Chatbot Memory Governance, Dynamic Memory Update Rule, Human Handoff Memory Rule, and Custom Versus Off The Shelf Memory Rule.
Purpose of update:
To evolve the framework into an AIOS ready and client interface ready standard for chatbots, voice agents, RAG systems, database backed assistant memory, and customer handoff workflows.
Version: v1.1
Date: 2026-05-31
Author: HeadOffice
Change:
Added alignment with the MWMS Context Engineering Framework and AI Operating System Architecture Framework.
Added Identity Context, Performance Context, Evidence Context, RAG, chunking, embeddings, vector memory, context window management, authority hierarchy, retrieval validation, and external content handling.
Purpose of update:
To evolve the framework from general memory governance into a stronger AIOS ready context engineering standard.
Version: v1.0
Date: Initial Draft
Author: HeadOffice
Change:
Created the MWMS AI Agent Memory And Context Framework as the governance framework for how MWMS selects, uses, limits, validates, updates, and transfers context and memory across AI Employees, Brains, workflows, task systems, reporting systems, handoffs, developer support, course absorption, newsletter intelligence, offer evaluation, and future AIBS client systems.
Change Impact Declaration
This v1.4 update expands the existing organisational memory framework without replacing or weakening its current architecture.
It adds explicit controls for:
runtime instruction context
tool result state memory
action execution memory
business outcome memory
cross tool consistency memory
voice transcription confidence memory
memory promotion contracts
memory write contracts
specialist agent context consistency
The update ensures that later agents, sessions, interfaces, and humans can distinguish:
what was requested
what was accepted
what technically executed
what changed
what business outcome was verified
what remains uncertain
what tools disagreed
what transcript fields were confirmed
what memory was deliberately written
what knowledge was deliberately promoted
what shared context governed a specialist agent chain
Pages Created
None.
Pages Updated
MWMS AI Agent Memory And Context Framework updated from v1.3 to v1.4.
Pages Deprecated
None.
Standalone Pages Not Created
MWMS Runtime Instruction Context Framework
MWMS Tool Result State Memory Standard
MWMS Action Execution Memory Standard
MWMS Business Outcome Memory Standard
MWMS Cross Tool Consistency Memory Standard
MWMS Voice Transcription Confidence Memory Standard
MWMS Memory Promotion Contract Standard
MWMS Memory Write Contract Standard
MWMS Specialist Agent Context Consistency Framework
These were not created because the missing intelligence belongs inside the existing MWMS AI Agent Memory And Context Framework and should remain aligned with the Prompt Architecture, AI Agent Operations Core, Automation, Data, Context Engineering, and Project Manager Brain governance layers.
Registries Requiring Update
HeadOffice Page Registry
MWMS Canon Index
MWMS Course Absorption Decision Registry
MCR Page Registry where the framework version is recorded
MCR Copy Map where the framework version is recorded
Canon Version Update Required
No immediate HeadOffice Canon version change is required unless it directly records this framework version or contains memory, context, runtime instruction, tool state, action history, business outcome, voice transcription, or specialist agent context rules that conflict with v1.4.
The new controls should be included during the next scheduled alignment review for:
HeadOffice Brain
AI Agent Operations Core
Prompting Framework
Automation Brain
Data Brain
Project Manager Brain
AIBS Brain
Change Log Entry Required
Yes.
The v1.4 update must be recorded in:
MWMS System Change Log
HeadOffice Page Registry change history where applicable
MCR Page Registry change history where applicable
MWMS Course Absorption Decision Registry
Strategic Absorption Result
MWMS gains a stronger memory and context architecture that not only separates temporary work, project state, durable knowledge, retrieval, conversation, and session memory, but also preserves the exact operational state of agent instructions, tool actions, business outcomes, cross tool agreement, voice transcription confidence, and specialist agent handoffs.
Runtime instructions are now treated as temporary bounded context rather than a back door for increasing authority.
Tool result state is now stored separately from business outcome state.
State changing actions receive explicit execution memory and duplicate execution protection.
Multi tool workflows preserve consistency checks.
Voice transcription uncertainty remains visible until confirmed.
Memory writes and promotions require explicit contracts.
Specialist agents must operate from the same approved context packet and preserve factual, operational, client, workspace, authority, and approval consistency throughout the workflow.
The resulting framework now governs memory and context as:
purpose defined
source linked
authority aware
client isolated
workspace isolated
task relevant
freshness checked
runtime bounded
tool state explicit
action history preserved
business outcome separated
cross tool checked
transcription uncertainty preserved
promotion governed
writes governed
specialist context consistent
correctable
auditable
portable where appropriate
safe for handoff
safe for future agent reuse
END OF FULL FILE OUTPUT