System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
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, AI Business Systems Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR

Purpose

The purpose of this document is to define the MWMS AI Agent Memory And Context Framework.

This framework establishes how MWMS governs the information, history, rules, decisions, preferences, task states, workflow states, Brain rules, source material, and operational context that AI Employees are allowed to use when performing work.

MWMS is not a simple chat system.

MWMS is a governed AI business ecosystem made up of Brains, AI Employees, workflows, task systems, dashboards, MCR pages, operational sites, developer work, future client systems, and long-term learning.

For AI Employees to work correctly, they must understand the right context.

But too much context can create confusion.

Wrong context can create bad decisions.

Missing context can create weak output.

Old context can create outdated instructions.

Sensitive context can create risk.

Therefore, context and memory must be controlled.

This framework exists to define how MWMS decides:

what context an AI Employee needs
where that context comes from
how context is packaged
what memory may be reused
what memory must not be reused
what context must be current
what context must be human-confirmed
what context should be logged
what context should be forgotten, archived, parked, or updated

Scope

This framework applies to all MWMS AI Employees, Brains, workflows, task systems, reports, handoffs, dashboards, automations, and future AIBS client systems that rely on context or memory.

This includes:

HeadOffice Brain
Brain Room
AI Manager
AI Employee Router
Task Executor systems
Dev Console
Newsletter Intelligence
Course Absorption
Opportunity System
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
Data Brain
Strategy Brain
Operations Brain
AI Business Systems Brain
Supabase task and event systems
MCR pages
Brain site pages
future client-facing AIBS systems

This framework applies to both human-provided context and system-provided context.

It also applies to persistent memory, temporary session context, task context, source context, workflow context, and learned system context.

Core Definition

AI Agent Memory And Context refers to the information an AI Employee uses to understand what it is doing, why it is doing it, what rules apply, what history matters, what source material is relevant, and what output is expected.

In MWMS, context may include:

current user instruction
uploaded files
source documents
MCR standards
Brain rules
active workflow state
task record
event log
page registry
current save point
developer boundary
prior decisions
current business goal
user preferences
role card
capability stack
tool permission boundary
validation standard
handoff protocol
outcome requirement
known risks
current system status

Memory is not automatically the same as context.

Memory is stored information.

Context is the selected information needed for the current task.

The key MWMS rule is:

Use the right context for the current task, not all available memory.

Core Principle

The core principle of this framework is:

AI Employees must receive enough context to act correctly, but not so much or such wrong context that they drift, confuse systems, or act on outdated assumptions.

This protects MWMS from:

missing important rules
using outdated save points
inventing page structure
confusing MCR with Brain sites
touching M’s active build areas
applying the wrong Brain rules
using old course absorption decisions incorrectly
treating draft pages as live pages
treating memory as source of truth
acting on stale system state
overloading AI Employees with irrelevant history
exposing future client systems to poor context design

Context must be curated.

Memory must be governed.

Context Versus Memory

MWMS must clearly separate context and memory.

Context

Context is the information needed for the current task.

Examples:

current request
relevant uploaded file
relevant MCR page
current Brain ownership
current save point
exact task boundary
relevant workflow standard
required output format
current screenshot
relevant Supabase row

Context is active.

It should be selected deliberately.

Memory

Memory is information preserved from previous work.

Examples:

user preferences
past build save points
completed course absorption modules
established MWMS standards
known tool preferences
M’s current build area
previously approved page structures
long-term business goals
accepted protocols

Memory is background.

It may support work, but it should not override current evidence.

Source Of Truth

Source of truth is the confirmed authority for a specific matter.

Examples:

MCR page for governance standard
current screenshot for visible WordPress state
uploaded file for course content
Supabase row for database state
current user instruction for today’s task
confirmed save point for development status

The source of truth is stronger than memory.

The rule is:

Memory can guide. Source of truth decides.

Context Types

MWMS should recognize different types of context.

1. Task Context

Task Context defines what is being done right now.

Includes:

task title
task type
source
user instruction
required output
deadline or urgency
risk level
human review requirement

Example:

The task context for course absorption is not “summarize this lesson.”

It is:

Extract only reusable MWMS system value, ignore weak material, map to Brain and Blueprint, and produce full page output only when justified.

2. Brain Context

Brain Context defines which Brain owns or supports the work.

Includes:

owning Brain
supporting Brains
Brain scope
Brain rules
Brain registry
Brain Canon
Brain workflow state
Brain destination

Example:

An offer evaluation task needs Affiliate Brain context, but may also need Research Brain, Ads Brain, Finance Brain, Experimentation Brain, and HeadOffice context.

3. Governance Context

Governance Context defines the rules that must be followed.

Includes:

MWMS Page Naming Standard
MWMS Document Structure Standard
MWMS Brain Routing Rule
MWMS AI Output Standard Full File Delivery Rule
MWMS Agentic Work Unit Standard
MWMS AI Output Validation Standard
MCR source of truth rule
developer boundary rules

Governance Context prevents drift.

4. Source Context

Source Context is the material being analyzed.

Includes:

course file
transcript
newsletter
screenshot
sales page
email
Supabase record
Google Sheet row
WordPress page list
code file
research source

Source Context must be preserved and not confused with assumptions.

5. Workflow Context

Workflow Context defines where the task sits inside a process.

Includes:

current workflow stage
previous stage
next stage
handoff destination
validation requirement
status
queue position
active blocker
related task or event

Example:

A newsletter item may be at “extracted but not reviewed,” while a course page may be at “drafted but not saved to MCR.”

6. Developer Context

Developer Context defines technical state and boundaries.

Includes:

site/domain
plugin/module
file path
current save point
screenshot evidence
exact issue
exact change required
what not to touch
testing steps
rollback or safety notes

Developer Context must be current and evidence-based.

Memory alone is not enough for developer instructions.

7. Business Context

Business Context defines the strategic purpose of the work.

Includes:

revenue goal
current priority
budget constraints
business model
target market
active offer
current campaign
user’s long-term goal
future client packaging relevance

Business Context keeps AI work connected to real value.

8. Risk Context

Risk Context defines what could go wrong.

Includes:

compliance risk
financial risk
live system risk
public content risk
client-facing risk
developer risk
privacy risk
platform policy risk
reputational risk
MCR duplication risk

Risk Context determines validation and review levels.

9. Historical Context

Historical Context includes previous decisions and past work.

Examples:

course module already absorbed
page already created
previous save point
prior rejected tool
prior approved standard
previous campaign rule
prior M instruction

Historical Context is useful but must be checked for freshness.

10. User Preference Context

User Preference Context includes stable user preferences.

Examples:

full page output preference
precise developer instructions
avoid vague instructions
absorb only valuable course material
do not block M’s work
keep costs low
evaluate courses honestly
protect MCR structure
use VEO3 format where relevant

User Preference Context helps maintain consistency.

Memory Types

MWMS should classify memory into different types.

1. 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 file output rule
course absorption rules
established Brain structures
current saved build points

Use:

background guidance
governance consistency

Risk:

may become outdated if not updated.

2. Project Memory

Memory specific to a project or workflow.

Examples:

current course absorption position
current newsletter intelligence setup
current HeadOffice dashboard state
current WordPress plugin save point
current Content Brain task progress

Use:

continuity across sessions

Risk:

stale if current state changes.

3. Task Memory

Memory specific to a single task or thread.

Examples:

files uploaded in current block
current page being drafted
current checklist being followed
current requested output

Use:

active work continuity

Risk:

should not be treated as permanent unless saved.

4. Decision Memory

Memory of approved decisions.

Examples:

course absorbed
tool rejected
page created
module parked
workflow approved
standard created
campaign rule accepted

Use:

avoid repeated decisions
prevent duplication

Risk:

must preserve reason, not just decision.

5. Failure Memory

Memory of errors, drift, and failure modes.

Examples:

Make.com body field issue
vague developer instructions problem
duplicated page risks
over-absorption risk
tool permission failure
newsletter dashboard noise

Use:

Kaizen improvement
future prevention

Risk:

should not create fear of progress; it should improve process.

6. Client Memory

Future AIBS-specific memory about a client system.

Examples:

client workflow rules
client approval boundaries
client report preferences
client tool access
client risk rules

Use:

consistent client delivery

Risk:

privacy, sensitivity, wrong-client leakage.

Client memory must be strongly isolated.

Context Pack Standard

Every important Agentic Work Unit should include a Context Pack.

A Context Pack is the selected context needed for the task.

A Context Pack may include:

Task Context:
What is being done now.

Brain Context:
Which Brain owns/supports the work.

Governance Context:
Which MWMS standards apply.

Source Context:
What material is being analyzed.

Workflow Context:
Where the task sits in the process.

Risk Context:
What could go wrong.

Developer Context:
Only if the task affects M or technical systems.

Business Context:
Why the task matters.

Historical Context:
Relevant previous decisions.

Output Context:
Expected output format and destination.

Default Context Pack Template

Task Name:
Current Request:
Owning Brain:
Supporting Brains:
Relevant Standards:
Source Material:
Current Workflow Stage:
Required Output:
Destination:
Known Constraints:
Developer Boundary:
Risk Level:
Human Review Required:
Relevant Past Decisions:
Do Not Use / Ignore:
Validation Requirement:
Outcome Expected:

This template may be simplified for low-risk work.

It should not be skipped for high-value, high-risk, cross-Brain, MCR, developer, finance, compliance, or client-facing work.

Context Selection Rules

AI Employees should not receive all available memory automatically.

Context should be selected by relevance.

Rule 1: Current Evidence Beats Old Memory

If a current screenshot, file, database row, or user instruction conflicts with memory, current evidence must be treated as stronger.

Example:

If memory says a page exists but today’s WordPress page list does not show it, do not assume it exists.

Rule 2: MCR Beats Operational Copy

If a governance question conflicts between MCR and a Brain site copy, MCR wins.

MCR is the source of truth.

Rule 3: User Instruction Beats Routine

If the user gives a specific instruction for the current session, follow that unless it violates safety, governance, or known boundaries.

Example:

If user says “wait until I say finished,” do not analyze early.

Rule 4: Confirm Before Developer Action

For developer instructions, context must be current, exact, and preferably visible in files/screenshots.

Memory is not enough.

Rule 5: Do Not Overload Simple Tasks

Low-risk simple tasks should not receive excessive system context.

Too much context can slow work and create irrelevant output.

Rule 6: High-Risk Tasks Need Full Context

High-risk tasks require full context packs.

Examples:

MCR canon updates
developer implementation
paid traffic decisions
financial analysis
compliance review
client-facing outputs
live system changes

Rule 7: Memory Must Not Invent Current State

Memory can say “last known state,” but it cannot prove current state.

Current state must come from current evidence.

Rule 8: Context Must Travel Through Handoffs

When work moves between Employees or Brains, the important context must move with it.

Do not rely on the receiving role to rediscover context.

Rule 9: Sensitive Context Must Be Limited

Future client context, personal data, credentials, financial data, and private business information should only be provided to AI Employees that need it.

Rule 10: Context Should Be Updated After Decisions

When Martyn approves, rejects, parks, saves, or changes direction, that decision should update relevant memory, registry, or workflow state.

Context Freshness Levels

MWMS should classify context by freshness.

Fresh Context

Provided in the current session, current file, current screenshot, current database query, or current user instruction.

Use as highest confidence.

Recent Context

Known from recent sessions or recent save points.

Use with confidence but confirm if high-risk.

Stable Context

Long-term rules or preferences unlikely to change.

Examples:

MCR source of truth
full page output rule
course absorption value filter
developer boundary preference

Use broadly.

Stale Context

Old information that may have changed.

Examples:

current site state
plugin file contents
Google Ads interface state
dashboard status
M’s exact build progress
available pages

Use carefully.

Confirm before acting.

Deprecated Context

Information that has been replaced by newer decisions.

Do not use unless reviewing history.

Memory Update Rules

Memory should be updated when the user makes a decision that affects future work.

Examples:

a course module is absorbed
a page is created
a tool is rejected
a workflow is parked
a save point is established
M’s task state changes
a new standard is approved
a new user preference is stated
a repeated failure pattern is identified
a future priority is added

Memory should not be updated for every minor thought.

Memory should capture stable, useful, future-relevant decisions.

Context And Source Of Truth Rules

MWMS must distinguish between:

memory
source material
source of truth
assumptions
current evidence
draft output

Memory

Helpful background.

Not automatically authoritative.

Source Material

The content being analyzed.

May or may not be authoritative.

Example:

A course transcript is source material for course content, but not MWMS canon.

Source Of Truth

Confirmed authority for a system rule or current state.

Example:

MCR page for governance.

Assumption

A reasoned guess.

Must be marked if important.

Current Evidence

Current file, screenshot, query, or user confirmation.

Strong for current-state decisions.

Draft Output

AI-generated proposal.

Not final until reviewed.

Application To Course Absorption

Course absorption requires careful context control.

Required context:

course file
lesson/module name
Course Absorption System v2
current MWMS Blueprint
existing similar standards
anti-duplication rule
output style preference
M development boundary

Memory use:

previous course modules absorbed
existing Brain frameworks
user preference for verdicts
user preference for hardcore extraction

Risk:

absorbing duplicate or weak material
treating course content as canon too quickly
missing source limitations

Rule:

Course memory should guide absorption, but uploaded course content must drive extraction.

Application To Newsletter Intelligence

Newsletter Intelligence requires context about:

source newsletter
sender
date
body
HeadOffice newsletter protocol
Brain routing rules
action categories
dashboard rules
validation rules

Memory use:

repeated signal patterns
previously rejected noise types
known tool evaluations
global compliance coverage
user preference for business relevance only

Risk:

old trend memory influencing current signal too strongly
generic AI news entering dashboard
wrong urgency

Rule:

Newsletter context must separate current signal from past trend memory.

Application To Brain Room

Brain Room requires context about:

current thread
message intent
sender
owning Brain
active workflow
task status
previous messages in same thread
current save point
developer boundary

Memory use:

past Brain Room structure
Brain Room purpose
current task executor state
known active build areas

Risk:

treating chat as task without classification
losing important decisions
creating tasks from incomplete context

Rule:

Brain Room context must convert useful discussion into structured work without losing thread meaning.

Application To Developer Support

Developer support requires the strictest context control.

Required context:

exact site/domain
exact file/path if code-related
exact screenshot or file contents
current save point
what not to touch
expected result
testing steps
M’s active boundary

Memory use:

previous save points
user preference for exact instructions
established plugin architecture
known active systems

Risk:

stale memory causing wrong code advice
vague instructions
touching unrelated systems
inventing file structure

Rule:

For developer work, current evidence beats memory every time.

Application To Offer Evaluation

Offer evaluation requires current context.

Required context:

offer name
network
payout
traffic platform
user goal
current market data where needed
vendor details
compliance constraints
finance assumptions
experimentation rules

Memory use:

user’s preferred traffic strategy
prohibited verticals
known affiliate protocols
previous offer decisions

Risk:

outdated metrics
vendor hype
false performance assumptions

Rule:

Offer memory can guide the process, but current offer data must support the verdict.

Application To AIBS Client Systems

Future client systems require strict context isolation.

Required context:

client process
client data source
client approval rules
client tool permissions
client report standard
client risk boundaries

Memory use:

client-specific preferences
workflow history
past approvals
recurring issues

Risk:

mixing clients
exposing sensitive context
using old client process data
automating without approval

Rule:

Client context must be isolated, permissioned, and purpose-limited.

Context Failure Modes

MWMS must watch for context failure.

Common failure modes include:

Using old memory as current fact
Missing the current user instruction
Ignoring uploaded source material
Treating draft pages as saved pages
Confusing MCR with Brain site copies
Forgetting developer boundary
Applying wrong Brain rules
Overloading task with irrelevant history
Missing current save point
Assuming page exists without confirmation
Using course content as canon before review
Mixing client contexts
Forgetting validation requirement
Failing to carry context through handoff
Letting memory override current evidence

Any workflow showing these failure modes should be paused and corrected.

Context Validation Checklist

Before an AI Employee begins important work, check:

What is the current request?
What is the source material?
Which Brain owns the work?
Which standards apply?
What context is current?
What context is memory only?
Is any context stale?
Is the source of truth known?
Are assumptions marked?
Is the developer boundary relevant?
Is MCR involved?
Is human review required?
Is the output format known?
Is destination known?
Is risk level known?
Does the AI Employee have too much irrelevant context?
Does the AI Employee lack critical context?
Does this require current verification?
Does context need to travel with a handoff?
Should any new learning update memory?

Context Pack Failure Handling

When context is insufficient:

pause the workflow
identify missing context
request or retrieve the missing source where appropriate
mark assumptions clearly
downgrade confidence
route to human review if high-risk
park the task if needed

When context is outdated:

mark it as stale
seek current confirmation
avoid acting on it
update memory after confirmation

When context conflicts:

identify the conflict
prioritize source of truth
escalate if the conflict affects governance, development, money, compliance, or client work

Memory Governance Rules

HeadOffice governs system memory.

Memory should support MWMS but not control it blindly.

Memory governance includes:

deciding what should be remembered
updating outdated memory
rejecting trivial memory
preventing memory overload
isolating client memory
distinguishing stable rules from temporary state
confirming current state before high-risk work
logging important decisions
removing deprecated context from active use

The memory rule is:

Memory is useful only when it improves future work without creating false certainty.

Memory And M Build Relevance

This framework is highly relevant to M’s future build work.

Later, it may inform:

context pack fields in task records
Brain Room thread context handling
AI Manager context retrieval
AI Employee Router context selection
task executor context injection
save point handling
Supabase memory tables
event log context summaries
client context isolation
role-specific context loading
validation of stale context

For now, this remains MCR governance.

No immediate development change is authorized by this page.

Memory And AIBS Client Systems

For future AIBS systems, context and memory will be a major selling point and risk point.

Client systems will need:

client-specific memory
workflow history
approval history
business rules
client preferences
reporting standards
permission boundaries
context isolation
audit trails

AIBS rule:

Client AI systems must remember enough to be useful, but not so broadly that they become risky, confusing, or privacy-sensitive.

Governance Role

HeadOffice owns the MWMS AI Agent Memory And Context Framework.

HeadOffice is responsible for:

defining memory and context rules
deciding source of truth priority
preventing stale context drift
ensuring AI Employees receive relevant context
preventing context overload
ensuring client context isolation
ensuring developer context is current and evidence-based
updating memory after approved decisions
protecting MCR from memory-based assumptions
protecting M’s active build areas from stale context
ensuring future AIBS systems use safe memory boundaries

Individual Brains may define specialized context requirements, but those must align with this framework.

Relationship To Other MWMS Standards

This framework supports and must align with:

MWMS AI Agent Operations Core
MWMS Agentic Work Unit Standard
MWMS AI Employee Role Card Standard
MWMS AI Agent Orchestration Framework
MWMS AI Workflow Pipeline Standard
MWMS AI Output Validation Standard
MWMS Messy Input Normalization Framework
MWMS Agentic Reporting Standard
MWMS AI Employee Handoff Protocol
MWMS AI Agent Failure Handling And Escalation Protocol
MWMS AI Agent Outcome Measurement Framework
MWMS AI Agent Operations Core Page Registry
MWMS AI Agent Deployment Readiness Checklist
MWMS AI Employee Capability Stack Framework
MWMS AI Tool Permission And Access Framework
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
MWMS AI Output Standard Full File Delivery Rule
MWMS Brain Header Schema Standard
MWMS Page Naming Standard
MWMS Document Structure Standard
MWMS Architecture Registry
MWMS Supabase Event Schema
AI Business Systems Brain Blueprint

This framework defines how the correct context is selected and used when those standards are applied.

Drift Protection

This framework protects MWMS from the following forms of drift:

Treating memory as current fact
Ignoring current source material
Using stale save points
Confusing MCR source of truth with operational copies
Applying wrong Brain context
Forgetting developer boundaries
Acting on unconfirmed page structures
Overloading AI Employees with irrelevant context
Missing critical context for high-risk tasks
Mixing client contexts
Letting old course absorption decisions override new evidence
Forgetting task destination
Losing context during handoffs
Failing to update memory after approved decisions
Creating false confidence from partial memory

Any workflow that relies on memory without checking source of truth should be reviewed before action.

Architectural Intent

The architectural intent of the MWMS AI Agent Memory And Context Framework is to make AI work context-aware without becoming context-confused.

MWMS depends on continuity.

It must remember what matters.

It must also know when memory is not enough.

The long-term goal is that every important AI workflow can answer:

What context is required?
Where did the context come from?
Is it current?
Is it source of truth or memory?
Is any context stale?
What rules apply?
What source material is being used?
What must be ignored?
What must travel with the handoff?
What should be saved as learning?
What should be updated after the decision?

When MWMS can answer those questions consistently, AI Employees can operate with continuity, precision, and governance.

Change Log

v1.0 — Initial Draft

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.

This framework extends the MWMS AI Agent Operations Core by defining context types, memory types, context packs, context selection rules, freshness levels, memory update rules, source of truth rules, workflow applications, failure modes, validation checklists, and governance responsibilities.