MWMS MCR

MWMS AI Agent Context Pack Template

System: MWMS
Document Type: Operational Template
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 Context Pack Template.

This template is used to package the correct context before an AI Employee performs meaningful work.

MWMS must not expect AI Employees to perform serious work from isolated prompts, incomplete memory, vague task instructions, or old assumptions.

An AI Employee needs the right context to know:

  • what the task is
  • where the task came from
  • which Brain owns it
  • which standards apply
  • what source material must be used
  • what must be ignored
  • what workflow stage the task is in
  • what output is required
  • what risk level applies
  • what tool permissions apply
  • whether human review is required
  • what current save point matters
  • what previous decisions matter
  • where the output should go next

This is the practical daily-use version of the MWMS AI Agent Memory And Context Framework.

Scope

This template applies whenever MWMS needs to prepare context for:

  • AI Employee work
  • Agentic Work Units
  • Brain Room task conversion
  • AI Manager routing
  • task executor processing
  • course absorption
  • newsletter intelligence
  • offer evaluation
  • research tasks
  • finance review
  • experimentation review
  • developer support
  • MCR page creation
  • validation tasks
  • handoff packages
  • HeadOffice dashboard items
  • future AIBS client workflows

This template can be used manually first.

Later, parts of this template may become fields inside Brain Room, AI Manager, Supabase task records, AI Employee Router, Task Executor systems, validation queues, dashboards, and future AIBS client systems.

Core Definition

An AI Agent Context Pack is the selected set of relevant context an AI Employee needs to complete a specific task correctly.

A Context Pack is not all available memory.

It is the right memory, source material, rules, task details, risk notes, and workflow context for the current task.

A Context Pack answers:

  • What is happening now?
  • What source should be used?
  • What source of truth applies?
  • What rules must be followed?
  • What has already been decided?
  • What risk exists?
  • What output is expected?
  • What must the AI Employee avoid?
  • Where does the result go?

Core Principle

The core principle of this template is:

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

Too little context creates weak output.

Too much context creates confusion.

Wrong context creates drift.

Old context creates false confidence.

The Context Pack exists to give AI Employees enough information to work correctly without drowning them in irrelevant history.

AI Agent Context Pack Template

1. Context Pack Title

Field:
Context Pack Title:

Purpose:
Gives the context pack a clear name.

Good Examples:

  • Course Absorption Context Pack For AI Agent Workflow Lesson
  • Newsletter Signal Context Pack For Ads Brain Routing
  • Developer Support Context Pack For HeadOffice Dashboard Issue
  • Offer Evaluation Context Pack For New Affiliate Product
  • Brain Room Task Context Pack For AI Manager Routing
  • MCR Page Creation Context Pack For New Template

Bad Examples:

  • Context
  • Notes
  • This
  • Background
  • Info

Rule:
The title should make the task context obvious.

2. Current Request

Field:
Current Request:

Purpose:
States what is being asked right now.

Examples:

  • Evaluate this course lesson for MWMS system value.
  • Convert this Brain Room message into an Agentic Work Unit.
  • Review this newsletter for business-relevant signals.
  • Prepare exact developer instructions for M.
  • Validate this MCR page output before saving.
  • Evaluate this affiliate offer for test suitability.

Rule:
The current request must be clear before the AI Employee begins work.

3. Task Type

Field:
Task Type:

Recommended Values:

  • Course Absorption
  • Newsletter Intelligence
  • Brain Room Task Creation
  • Offer Evaluation
  • Research
  • Finance Review
  • Experimentation Review
  • Developer Support
  • MCR Page Creation
  • Validation
  • Handoff
  • Reporting
  • Dashboard Review
  • Failure Handling
  • Outcome Logging
  • Client Workflow

Rule:
Task type determines what context is needed.

4. Source Material

Field:
Source Material:

Purpose:
Identifies the material the AI Employee must use.

Examples:

  • uploaded file
  • pasted text
  • course transcript
  • newsletter body
  • screenshot
  • WordPress page list
  • Supabase row
  • Brain Room message
  • affiliate offer page
  • research source
  • finance data
  • experiment result
  • developer file
  • client document

Rule:
The AI Employee must know what source material is active.

5. Source Reference

Field:
Source Reference:

Purpose:
Records the exact source where available.

Examples:

  • file name
  • lesson title
  • email subject
  • screenshot filename
  • page title
  • Supabase record ID
  • Brain Room thread
  • dashboard row
  • offer name
  • task ID
  • date received

Rule:
If the source may need to be checked later, include a reference.

6. Source Completeness

Field:
Source Completeness:

Recommended Values:

  • Complete
  • Mostly Complete
  • Partial
  • Incomplete
  • Unknown
  • Source Expired
  • Needs Reupload

Rule:
Do not treat incomplete source material as complete.

If the source is partial, the AI Employee must mark assumptions and lower confidence.

7. Source Of Truth

Field:
Source Of Truth:

Purpose:
Identifies the authority for the task.

Examples:

  • MCR page
  • uploaded course file
  • current screenshot
  • current user instruction
  • Supabase row
  • WordPress page list
  • current save point
  • approved framework
  • confirmed workflow state
  • human decision

Rule:
Memory can guide, but source of truth decides.

8. Owning Brain

Field:
Owning Brain:

Purpose:
Identifies the Brain responsible for the task.

Examples:

  • HeadOffice Brain
  • Affiliate Brain
  • Research Brain
  • Finance Brain
  • Experimentation Brain
  • Content Brain
  • Ads Brain
  • Sales Brain
  • Conversion Brain
  • Operations Brain
  • AI Business Systems Brain

Rule:
No important AI work should proceed without a clear owning Brain.

9. Supporting Brains

Field:
Supporting Brains:

Purpose:
Lists other Brains affected by or supporting the work.

Examples:

For offer evaluation:

  • Research Brain
  • Ads Brain
  • Finance Brain
  • Experimentation Brain
  • HeadOffice Brain

For course absorption:

  • HeadOffice Brain
  • AI Business Systems Brain
  • Operations Brain
  • relevant specialist Brain

For newsletter intelligence:

  • Ads Brain
  • Content Brain
  • Affiliate Brain
  • Research Brain
  • Finance Brain

Rule:
Cross-Brain impact should be visible early.

10. Assigned AI Employee

Field:
Assigned AI Employee:

Purpose:
Identifies the AI Employee performing the task.

Examples:

  • Course Absorption Agent
  • Newsletter Signal Extraction Agent
  • Brain Room Task Builder Agent
  • Offer Evaluation Agent
  • Research Evidence Collection Agent
  • Finance Break Even Analysis Agent
  • HeadOffice Validation Agent
  • Developer Support Agent
  • Handoff Agent
  • Reporting Agent

Rule:
Context should match the Employee role.

11. Related Role Card

Field:
Related Role Card:

Purpose:
Identifies the role definition governing the assigned AI Employee.

Examples:

  • Course Absorption Agent Role Card
  • Newsletter Signal Extraction Agent Role Card
  • Developer Support Agent Role Card
  • HeadOffice Validation Agent Role Card

Rule:
If no Role Card exists, the AI Employee should be treated as draft or manual-use only.

12. Related Capability Stack

Field:
Related Capability Stack:

Purpose:
Identifies the Employee’s approved capabilities.

Examples:

  • Course Absorption Agent Capability Stack
  • Developer Support Agent Capability Stack
  • Newsletter Signal Extraction Agent Capability Stack
  • Offer Evaluation Agent Capability Stack

Rule:
The task must not exceed the Employee’s capability stack.

13. Relevant MWMS Standards

Field:
Relevant MWMS Standards:

Purpose:
Lists the standards, templates, protocols, or frameworks that apply.

Examples:

  • MWMS AI Agent Operations Core
  • MWMS Agentic Work Unit Standard
  • MWMS Agentic Work Unit Template
  • MWMS AI Employee Role Card Template
  • MWMS AI Workflow Pipeline Checklist
  • MWMS AI Output Validation Checklist
  • MWMS Messy Input Normalization Record
  • MWMS Agentic Reporting Template
  • MWMS AI Employee Handoff Package Template
  • MWMS AI Agent Failure Log Record
  • MWMS AI Agent Outcome Log Record
  • MWMS AI Tool Permission Record Template
  • MWMS Page Naming Standard
  • MWMS Document Structure Standard
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • Course Absorption Operating Rule
  • Newsletter Intelligence Operating Protocol

Rule:
Only include standards relevant to the task. Do not overload the Employee unnecessarily.

14. Current Workflow Stage

Field:
Current Workflow Stage:

Recommended Values:

  • Input Capture
  • Input Cleaning
  • Classification
  • Task Creation
  • AI Employee Assignment
  • Context Attachment
  • Processing
  • Validation
  • Decision
  • Routing
  • Logging
  • Learning Update
  • Waiting For Human Review
  • Waiting For Input
  • Parked
  • Completed

Rule:
The AI Employee must know where the task sits in the pipeline.

15. Previous Work Completed

Field:
Previous Work Completed:

Purpose:
Summarizes what has already been done.

Examples:

  • input normalized
  • duplicate pages checked
  • course lesson reviewed
  • signal extracted
  • offer intake completed
  • validation failed once
  • page draft created
  • handoff package prepared
  • MCR page saved
  • source reuploaded
  • user approved direction

Rule:
This prevents repeated work and confusion.

16. Current Save Point

Field:
Current Save Point:

Purpose:
Captures the current state where relevant.

Examples:

  • latest M development save point
  • current WordPress page state
  • current Supabase schema state
  • current Make.com workflow state
  • current HeadOffice dashboard state
  • current course absorption pause point
  • current duplicate cleanup status

Rule:
For developer or system-state work, current save point matters.

Do not rely on old memory if current evidence is needed.

17. Developer Boundary

Field:
Developer Boundary:

Purpose:
Defines what must not be touched if the task is development-sensitive.

Examples:

  • do not touch M’s active build
  • do not touch Brain Room backend
  • do not touch executor hooks
  • do not touch Opportunity System wiring
  • do not touch live plugin files
  • do not touch Supabase schema
  • do not change HeadOffice reporting
  • do not give M vague instructions
  • do not assume file paths

Rule:
Developer boundary must be explicit when relevant.

18. Tool Permission Boundary

Field:
Tool Permission Boundary:

Purpose:
Defines what tools the AI Employee may use for this task.

Recommended Values:

  • No Tool Access
  • Provided Input Only
  • Read Only Reference Access
  • Draft Creation Access
  • Controlled Write Access
  • Supervised External Action Access
  • Restricted Autonomous Access

Rule:
Context must include the tool boundary so the Employee does not overreach.

19. Approved Tools

Field:
Approved Tools:

Purpose:
Lists the tools or sources allowed for this task.

Examples:

  • uploaded files only
  • current conversation only
  • MCR page list provided by user
  • web research allowed
  • Gmail read only
  • Supabase read only
  • Supabase controlled write
  • WordPress read only
  • provided screenshots
  • provided plugin files
  • approved client data

Rule:
Approved tools must match the Tool Permission Record.

20. Forbidden Actions

Field:
Forbidden Actions:

Purpose:
Lists what the AI Employee must not do.

Examples:

  • do not create live tasks without review
  • do not change WordPress pages
  • do not alter Supabase records
  • do not send emails
  • do not approve spend
  • do not invent missing data
  • do not bypass HeadOffice
  • do not interfere with M’s active build
  • do not treat draft as saved canon
  • do not create duplicate MCR pages
  • do not absorb weak course material
  • do not make unsupported claims

Rule:
Forbidden actions prevent context-based overreach.

21. Output Required

Field:
Output Required:

Purpose:
Defines what the AI Employee must produce.

Examples:

  • full page output
  • course absorption report
  • Agentic Work Unit
  • Role Card
  • Capability Stack
  • Tool Permission Record
  • Context Pack
  • validation report
  • handoff package
  • failure log
  • outcome log
  • developer brief
  • newsletter intelligence record
  • offer evaluation report
  • dashboard card
  • client report draft

Rule:
The output must be defined before processing begins.

22. Output Format Requirements

Field:
Output Format Requirements:

Purpose:
Defines formatting rules the AI Employee must follow.

Examples:

  • full page output
  • MWMS header block
  • Purpose, Scope, Governance Role, Relationship, Drift Protection, Architectural Intent, Change Log
  • quick use version included
  • examples included
  • no partial snippets
  • exact developer instructions
  • short dashboard-ready item
  • Green/Yellow/Red verdict
  • decision-ready report format

Rule:
Output should match destination.

23. Human Review Required

Field:
Human Review Required: Yes / No

Purpose:
Defines whether human review is required before the output is accepted or acted on.

Required For:

  • MCR canon
  • developer handoff
  • live systems
  • Supabase writes
  • WordPress changes
  • paid traffic
  • finance
  • compliance
  • public content
  • client-facing output
  • high-risk automation
  • uncertain source grounding

Rule:
When in doubt, require human review.

24. Validation Requirement

Field:
Validation Requirement:

Recommended Values:

  • Light Validation
  • Structured Validation
  • Operational Validation
  • High Risk Validation
  • Critical Validation

Rule:
Validation level must match risk and destination.

25. Risk Level

Field:
Risk Level:

Recommended Values:

  • Low
  • Medium
  • High
  • Critical

Rule:
Risk level determines review, validation, and escalation.

26. Priority

Field:
Priority:

Recommended Values:

  • Critical
  • High
  • Medium
  • Low
  • Parking Lot

Rule:
Priority should reflect business value, not excitement.

27. Known Constraints

Field:
Known Constraints:

Purpose:
Lists limits or restrictions affecting the task.

Examples:

  • source file expired
  • source may be incomplete
  • do not duplicate existing MCR page
  • do not create development work yet
  • do not interfere with M
  • no current web verification
  • no tool access
  • no live system action
  • no public claim
  • client approval required
  • current screenshot only shows partial state

Rule:
Constraints must be visible before output is created.

28. Known Gaps

Field:
Known Gaps:

Purpose:
Identifies missing information.

Examples:

  • exact file path missing
  • page parent not confirmed
  • source transcript missing
  • offer payout unknown
  • finance data missing
  • web data not verified
  • source date unknown
  • current system state unknown
  • duplicate comparison incomplete
  • client approval rules missing

Rule:
Known gaps must not be hidden.

29. Assumptions Allowed

Field:
Assumptions Allowed: Yes / No / Limited

Purpose:
Defines whether the AI Employee may make assumptions.

If assumptions are allowed, define:

  • what assumptions are allowed
  • how they must be marked
  • whether the output must include uncertainty

Rule:
Assumptions must never be presented as confirmed fact.

30. Do Not Use Or Ignore

Field:
Do Not Use Or Ignore:

Purpose:
Lists content, memory, or signals that should not influence the task.

Examples:

  • old page version
  • generic course fluff
  • newsletter sponsor content
  • vendor hype
  • unverified claims
  • outdated save point
  • unrelated Brain rules
  • unrelated client data
  • assumptions from expired files
  • memory not confirmed by current evidence

Rule:
Explicitly stating what to ignore prevents drift.

31. Relevant Past Decisions

Field:
Relevant Past Decisions:

Purpose:
Captures decisions that matter for the current task.

Examples:

  • MCR is source of truth
  • correct parent wins first in duplicate cleanup
  • course absorption must only absorb valuable content
  • M’s active build should not be interrupted
  • Newsletter Intelligence must focus on business relevance
  • Google Ads is critical to MWMS
  • AIBS client systems require approval gates

Rule:
Only include past decisions that affect the current task.

32. Current Evidence

Field:
Current Evidence:

Purpose:
Lists the current evidence supporting the task.

Examples:

  • uploaded file
  • screenshot
  • WordPress page list
  • pasted page content
  • current Supabase query
  • current user confirmation
  • current Make.com run
  • current file contents
  • current dashboard view

Rule:
Current evidence beats old memory.

33. Context Freshness

Field:
Context Freshness:

Recommended Values:

  • Fresh
  • Recent
  • Stable
  • Stale
  • Deprecated
  • Unknown

Rule:
Fresh context has more weight than stale memory.

Stale context must be confirmed before high-risk action.

34. Confidence Level

Field:
Confidence Level:

Recommended Values:

  • High
  • Medium
  • Low
  • Unknown

Purpose:
States confidence in the context pack.

Rule:
Low confidence should trigger caution, validation, or more input.

35. Handoff Destination

Field:
Handoff Destination:

Purpose:
Defines where the output should go next.

Examples:

  • MCR
  • HeadOffice review
  • Brain Room
  • AI Manager
  • Newsletter Queue Review
  • Routed Actions
  • HeadOffice Dashboard
  • Research Brain
  • Finance Brain
  • Experimentation Brain
  • Ads Brain
  • Content Brain
  • M developer handoff
  • Parking System
  • Archive
  • Human Review Queue
  • AIBS Client Review

Rule:
Context should include destination so output is shaped correctly.

36. Expected Business Outcome

Field:
Expected Business Outcome:

Purpose:
Defines what useful outcome the task should create.

Examples:

  • decision made
  • page created
  • duplicate avoided
  • weak material rejected
  • signal routed
  • task created
  • risk reduced
  • M can act without guessing
  • offer rejected or moved to research
  • dashboard improved
  • future AIBS asset created
  • learning captured

Rule:
Context should connect task to outcome.

37. Escalation Trigger

Field:
Escalation Trigger:

Purpose:
Defines when the AI Employee must stop and escalate.

Examples:

  • source incomplete
  • ownership unclear
  • risk increases
  • tool permission unclear
  • compliance issue appears
  • finance issue appears
  • developer ambiguity remains
  • live system impact detected
  • M’s active build affected
  • validation fails
  • output exceeds role authority

Rule:
A Context Pack should tell the AI Employee when not to continue.

38. Logging Required

Field:
Logging Required: Yes / No

Purpose:
Defines whether the task or output should be logged.

Logging Required For:

  • MCR updates
  • developer handoffs
  • cross-Brain tasks
  • high-risk work
  • failures
  • outcomes
  • offer evaluations
  • finance reviews
  • client-facing workflows
  • important HeadOffice decisions

Rule:
Important work should leave a trace.

39. Learning Capture Required

Field:
Learning Capture Required: Yes / No

Purpose:
Defines whether reusable learning should be captured.

Learning Examples:

  • new framework
  • new validation rule
  • new failure mode
  • new routing rule
  • new AI Employee role
  • new dashboard rule
  • new developer instruction rule
  • new AIBS packaging idea
  • new course absorption insight

Rule:
Useful learning should not disappear inside the task.

Quick Use Version

Use this shorter version for daily work.

Context Pack Title:
Current Request:
Task Type:
Source Material:
Source Reference:
Source Completeness:
Source Of Truth:
Owning Brain:
Supporting Brains:
Assigned AI Employee:
Relevant MWMS Standards:
Current Workflow Stage:
Previous Work Completed:
Current Save Point:
Developer Boundary:
Tool Permission Boundary:
Approved Tools:
Forbidden Actions:
Output Required:
Output Format Requirements:
Human Review Required:
Validation Requirement:
Risk Level:
Priority:
Known Constraints:
Known Gaps:
Assumptions Allowed:
Do Not Use Or Ignore:
Relevant Past Decisions:
Current Evidence:
Context Freshness:
Confidence Level:
Handoff Destination:
Expected Business Outcome:
Escalation Trigger:
Logging Required:
Learning Capture Required:

Context Pack Types

1. Course Absorption Context Pack

Use when processing course material.

Must Include:

  • course file or lesson source
  • course/module/lesson name
  • source completeness
  • Course Absorption System v2
  • existing similar MWMS pages
  • anti-duplication rule
  • full page output rule
  • MCR source-of-truth rule
  • Brain/Blueprint mapping
  • content to ignore
  • expected output
  • absorb/park/reject outcome

Rule:
Course context must push the AI Employee toward system extraction, not general summary.

2. Newsletter Intelligence Context Pack

Use when processing newsletters.

Must Include:

  • newsletter subject
  • sender
  • date
  • body/source completeness
  • HeadOffice Newsletter Intelligence Operating Protocol
  • Brain Routing Rule
  • business relevance filter
  • action categories
  • dashboard readiness rules
  • source grounding
  • validation requirement

Rule:
Newsletter context must separate signal from noise.

3. Brain Room Context Pack

Use when converting Brain Room messages into structured work.

Must Include:

  • message text
  • sender
  • thread context
  • current workflow state
  • Brain Routing Rule
  • task type
  • owning Brain
  • risk level
  • AI Manager destination
  • human review requirement

Rule:
Brain Room context must preserve discussion meaning while converting it into trackable work.

4. Developer Support Context Pack

Use when preparing work for M or technical review.

Must Include:

  • exact site/domain
  • screenshot or file contents
  • current save point
  • exact issue
  • exact file path where available
  • full file output rule
  • what not to touch
  • test requirement
  • developer boundary
  • live system risk
  • current evidence
  • known gaps

Rule:
For developer work, current evidence beats memory every time.

5. Offer Evaluation Context Pack

Use when evaluating affiliate, CPA, CPL, PPL, or digital product offers.

Must Include:

  • offer name
  • network
  • niche
  • payout/metrics if available
  • traffic platform
  • current data need
  • vendor claims separated from evidence
  • Affiliate Product Intelligence Protocol
  • Ads Brain compliance rules
  • Finance Brain budget rules
  • Experimentation Brain test rules
  • verdict format
  • human review requirement

Rule:
Offer context must not let vendor hype become evidence.

6. Validation Context Pack

Use when validating an output.

Must Include:

  • output being reviewed
  • source
  • task instruction
  • output type
  • owning Brain
  • validation level
  • required checks
  • risk level
  • human review requirement
  • destination
  • pass/fail decision format

Rule:
Validation context must include what the output was supposed to do.

7. Handoff Context Pack

Use when work is moving between Brains, AI Employees, humans, queues, or systems.

Must Include:

  • source
  • work completed
  • output produced
  • current status
  • validation status
  • receiving Brain or role
  • owner of next action
  • context to preserve
  • known gaps
  • risk level
  • required next action

Rule:
Handoff context must travel with the output.

8. AIBS Client Context Pack

Use for future client-facing AI workflows.

Must Include:

  • client workflow
  • client data source
  • client approval rules
  • client tool permissions
  • client report standard
  • client risk boundary
  • source completeness
  • human review requirement
  • privacy and isolation rule
  • client-facing output destination

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

Example 1: Course Absorption Context Pack

Context Pack Title:
Course Absorption Context Pack For AI Agent Operations Lesson

Current Request:
Extract reusable MWMS system value from the uploaded course lesson and create a full page output if justified.

Task Type:
Course Absorption

Source Material:
Uploaded course transcript / lesson text

Source Reference:
Mastering Claude Cowork And AI Agent Automation lesson block

Source Completeness:
Mostly Complete

Source Of Truth:
Uploaded course source for course content; MCR for MWMS governance.

Owning Brain:
HeadOffice Brain

Supporting Brains:
AI Business Systems Brain, Operations Brain, Brain Room

Assigned AI Employee:
Course Absorption Agent

Relevant MWMS Standards:
Course Absorption System v2, MWMS AI Agent Operations Core, MWMS AI Output Validation Checklist, MWMS Document Structure Standard

Current Workflow Stage:
Processing / Page Drafting

Previous Work Completed:
Course block reviewed and judged valuable.

Current Save Point:
AI Agent Operations Core practical template layer is being created.

Developer Boundary:
Do not create M build tasks yet.

Tool Permission Boundary:
Provided Input Only

Approved Tools:
Uploaded course files and current conversation context.

Forbidden Actions:
Do not absorb weak content, do not duplicate existing pages, do not interfere with M.

Output Required:
Full MCR page output.

Output Format Requirements:
MWMS header block, Purpose, Scope, Governance Role, Relationship, Drift Protection, Architectural Intent, Change Log.

Human Review Required:
Yes

Validation Requirement:
Operational Validation

Risk Level:
Medium

Priority:
High

Known Constraints:
Some uploaded source files may expire later, so source-checking may require reupload.

Known Gaps:
Exact transcript verification may require reupload if questioned later.

Assumptions Allowed:
Limited, must be marked.

Do Not Use Or Ignore:
Tool hype, casual filler, repeated intro material.

Relevant Past Decisions:
Only absorb material that improves MWMS Brain, Blueprint, ecosystem, or future expansion.

Current Evidence:
Current lesson block and created AI Agent Operations pages.

Context Freshness:
Fresh

Confidence Level:
High

Handoff Destination:
MCR

Expected Business Outcome:
Reusable AI operations standard added to MWMS.

Escalation Trigger:
Duplicate page found, content conflicts with existing standard, or M build impact appears.

Logging Required:
Yes if saved

Learning Capture Required:
Yes

Example 2: Developer Support Context Pack

Context Pack Title:
Developer Support Context Pack For WordPress Plugin Issue

Current Request:
Prepare exact instructions for M based on provided screenshot and file contents.

Task Type:
Developer Support

Source Material:
Screenshot and uploaded plugin file.

Source Reference:
Screenshot filename and plugin file path.

Source Completeness:
Partial / Complete depending on provided files.

Source Of Truth:
Current screenshot and current file contents.

Owning Brain:
HeadOffice Brain

Supporting Brains:
Operations Brain, Dev Console

Assigned AI Employee:
Developer Support Agent

Relevant MWMS Standards:
Full File Output Rule, MWMS AI Output Validation Checklist, MWMS AI Employee Handoff Package Template

Current Workflow Stage:
Developer Instruction Drafting

Previous Work Completed:
Issue identified by user.

Current Save Point:
Must be confirmed from current conversation or user-provided save point.

Developer Boundary:
Do not touch unrelated systems. Do not assume file paths. Do not interfere with M’s active build.

Tool Permission Boundary:
Provided Input Only

Approved Tools:
Provided screenshot and uploaded file only.

Forbidden Actions:
Do not alter live code, do not guess, do not give vague search instructions.

Output Required:
Developer handoff brief or full file output.

Output Format Requirements:
Exact site, exact file path, exact replacement/insertion location, what not to touch, test steps, expected result.

Human Review Required:
Yes

Validation Requirement:
High Risk Validation

Risk Level:
High

Priority:
Based on build dependency

Known Constraints:
If file path or current state is missing, stop and ask for evidence.

Known Gaps:
Any file not provided is unknown.

Assumptions Allowed:
No, unless clearly marked as assumption.

Do Not Use Or Ignore:
Old memory that conflicts with current screenshot or file.

Relevant Past Decisions:
Developer instructions must be exact and anchored to visible evidence.

Current Evidence:
Screenshot and file contents.

Context Freshness:
Fresh

Confidence Level:
Medium to High depending on evidence completeness.

Handoff Destination:
M

Expected Business Outcome:
M can act safely without guessing.

Escalation Trigger:
Missing file path, unclear current state, live risk, or M would need to guess.

Logging Required:
Yes for meaningful dev work

Learning Capture Required:
Yes if new save point or rule is created

Example 3: Newsletter Intelligence Context Pack

Context Pack Title:
Newsletter Intelligence Context Pack For Business Signal Extraction

Current Request:
Extract only business-relevant signals from the newsletter and route them correctly.

Task Type:
Newsletter Intelligence

Source Material:
Newsletter email body.

Source Reference:
Email subject, sender, date.

Source Completeness:
Complete / Mostly Complete / Partial

Source Of Truth:
Newsletter source for content; HeadOffice Newsletter Intelligence rules for routing.

Owning Brain:
HeadOffice Brain

Supporting Brains:
Depends on signal: Ads Brain, Affiliate Brain, Content Brain, Research Brain, Finance Brain, AI Business Systems Brain

Assigned AI Employee:
Newsletter Signal Extraction Agent

Relevant MWMS Standards:
HeadOffice Newsletter Intelligence Operating Protocol, MWMS Brain Routing Rule, MWMS Agentic Reporting Template, MWMS AI Output Validation Checklist

Current Workflow Stage:
Signal Extraction / Classification

Previous Work Completed:
Email captured from Gmail workflow.

Current Save Point:
Newsletter Intelligence system is under HeadOffice operational stabilization.

Developer Boundary:
Do not touch M’s active build.

Tool Permission Boundary:
Read Only / Controlled Write only if existing workflow approved.

Approved Tools:
Newsletter source email and approved Supabase review table where applicable.

Forbidden Actions:
Do not create downstream tasks without review. Do not mark generic content as urgent.

Output Required:
Newsletter intelligence report or record.

Output Format Requirements:
Signal, underlying pattern, primary Brain, supporting Brains, action type, priority, urgency, recommended action.

Human Review Required:
Yes before downstream action.

Validation Requirement:
Operational Validation

Risk Level:
Medium

Priority:
Based on signal value.

Known Constraints:
Email body extraction may be incomplete.

Known Gaps:
Current verification may be needed for tools, policy, compliance, or pricing.

Assumptions Allowed:
Limited and marked.

Do Not Use Or Ignore:
Sponsor fluff, generic news, weak hype, repeated footer content.

Relevant Past Decisions:
Newsletter analysis must focus on business-relevant insights only.

Current Evidence:
Current newsletter body.

Context Freshness:
Fresh

Confidence Level:
Based on body completeness.

Handoff Destination:
Newsletter Queue Review / HeadOffice Dashboard candidate.

Expected Business Outcome:
Useful signal routed; noise rejected or parked.

Escalation Trigger:
Compliance issue, paid traffic impact, finance risk, or urgent platform change.

Logging Required:
Yes

Learning Capture Required:
Yes if repeated pattern appears

Context Pack Quality Checklist

Before using a Context Pack, check:

  1. Is the current request clear?
  2. Is the task type identified?
  3. Is source material listed?
  4. Is source completeness known?
  5. Is source of truth clear?
  6. Is owning Brain clear?
  7. Are supporting Brains listed where relevant?
  8. Is the assigned AI Employee clear?
  9. Are relevant standards included?
  10. Is current workflow stage known?
  11. Is previous work completed summarized?
  12. Is current save point included where relevant?
  13. Is developer boundary stated if relevant?
  14. Is tool permission boundary clear?
  15. Are approved tools listed?
  16. Are forbidden actions listed?
  17. Is output required defined?
  18. Are output format requirements clear?
  19. Is human review requirement clear?
  20. Is validation requirement assigned?
  21. Is risk level assigned?
  22. Are known constraints listed?
  23. Are known gaps listed?
  24. Are assumptions controlled?
  25. Is current evidence listed?
  26. Is context freshness marked?
  27. Is confidence level stated?
  28. Is handoff destination clear?
  29. Is expected business outcome clear?
  30. Are escalation triggers defined?

If several answers are unclear, the Context Pack is not ready.

Common Context Pack Failure Modes

A Context Pack has failed if:

  1. It uses old memory as current fact.
  2. It does not identify source of truth.
  3. It gives too much irrelevant context.
  4. It misses a critical rule.
  5. It lacks Brain ownership.
  6. It lacks output requirements.
  7. It does not state risk.
  8. It omits human review.
  9. It ignores developer boundaries.
  10. It allows tool access without permission.
  11. It hides source gaps.
  12. It treats assumptions as facts.
  13. It does not preserve current evidence.
  14. It loses context during handoff.
  15. It does not define expected outcome.

Manual Use Rule

This template should be used manually before it becomes technical infrastructure.

Manual use helps MWMS learn:

  • which context fields matter most
  • which tasks need full context packs
  • which simple tasks do not need heavy context
  • which AI Employees need stronger context
  • where stale memory creates errors
  • which workflow contexts repeat
  • which fields may later become Supabase task context fields
  • how Brain Room should pass context to AI Manager

Manual context discipline comes before automated context loading.

Future Plugin Or UI Relevance

This template may later become:

  • Brain Room context panel
  • AI Manager context injection structure
  • Task Executor context field
  • Supabase task context pack
  • AI Employee Router context selector
  • Developer support context record
  • Newsletter context record
  • Course absorption context record
  • Offer evaluation context record
  • AIBS client context pack

Possible future fields:

  • context_pack_id
  • context_pack_title
  • current_request
  • task_type
  • source_material
  • source_reference
  • source_completeness
  • source_of_truth
  • owning_brain
  • supporting_brains
  • assigned_ai_employee
  • related_role_card
  • related_capability_stack
  • relevant_standards
  • current_workflow_stage
  • previous_work_completed
  • current_save_point
  • developer_boundary
  • tool_permission_boundary
  • approved_tools
  • forbidden_actions
  • output_required
  • output_format_requirements
  • human_review_required
  • validation_requirement
  • risk_level
  • priority
  • known_constraints
  • known_gaps
  • assumptions_allowed
  • do_not_use_or_ignore
  • relevant_past_decisions
  • current_evidence
  • context_freshness
  • confidence_level
  • handoff_destination
  • expected_business_outcome
  • escalation_trigger
  • logging_required
  • learning_capture_required
  • created_at
  • updated_at

No technical build is authorized by this template alone.

Governance Role

HeadOffice owns the MWMS AI Agent Context Pack Template.

HeadOffice is responsible for:

  • deciding when Context Packs are required
  • ensuring important AI work has enough context
  • preventing stale memory drift
  • preventing context overload
  • ensuring source of truth is clear
  • ensuring developer context is evidence-based
  • ensuring tool boundaries are clear
  • ensuring human review requirements are visible
  • protecting MCR from memory-based assumptions
  • protecting M’s active build areas
  • protecting future AIBS client systems through isolated context

Individual Brains may use specialized context packs, but they must align with HeadOffice context rules for high-risk, cross-Brain, client-facing, or developer-sensitive work.

Relationship To Other MWMS Standards

This template supports and must align with:

  • MWMS AI Agent Memory And Context Framework
  • MWMS AI Agent Operations Core
  • MWMS Agentic Work Unit Standard
  • MWMS Agentic Work Unit Template
  • MWMS AI Employee Role Card Standard
  • MWMS AI Employee Role Card Template
  • MWMS AI Employee Capability Stack Framework
  • MWMS AI Employee Capability Stack Template
  • MWMS AI Tool Permission And Access Framework
  • MWMS AI Tool Permission Record Template
  • MWMS AI Workflow Pipeline Standard
  • MWMS AI Workflow Pipeline Checklist
  • MWMS AI Output Validation Standard
  • MWMS AI Output Validation Checklist
  • MWMS Messy Input Normalization Framework
  • MWMS Messy Input Normalization Record
  • MWMS Agentic Reporting Standard
  • MWMS Agentic Reporting Template
  • MWMS AI Employee Handoff Protocol
  • MWMS AI Employee Handoff Package Template
  • MWMS AI Agent Failure Handling And Escalation Protocol
  • MWMS AI Agent Failure Log Record
  • MWMS AI Agent Outcome Measurement Framework
  • MWMS AI Agent Outcome Log Record
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS Supabase Event Schema
  • AI Business Systems Brain Blueprint

This template is the practical application of the MWMS AI Agent Memory And Context Framework.

Drift Protection

This template protects MWMS from the following forms of drift:

  1. Acting from vague prompts
  2. Using memory as current fact
  3. Missing source of truth
  4. Ignoring current evidence
  5. Forgetting Brain ownership
  6. Applying the wrong standards
  7. Missing developer boundaries
  8. Overloading AI Employees with irrelevant history
  9. Missing tool permission limits
  10. Treating assumptions as facts
  11. Losing context during handoffs
  12. Processing incomplete source material as complete
  13. Creating outputs without destination
  14. Skipping human review on high-risk work
  15. Mixing future client contexts

Any important AI task without a sufficient Context Pack should be treated as under-contextualized.

Architectural Intent

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

MWMS is building a governed AI workforce.

That workforce needs the right context at the right time.

The long-term goal is that every meaningful AI task can answer:

  • What is the current request?
  • What source material is active?
  • What is the source of truth?
  • Which Brain owns the work?
  • Which AI Employee is assigned?
  • What standards apply?
  • What stage is the workflow in?
  • What output is required?
  • What risk exists?
  • What tools are allowed?
  • What must not be done?
  • What evidence is current?
  • What assumptions are allowed?
  • Where does the output go?
  • What outcome should be created?

When MWMS can package context this way, AI Employees can work with precision, continuity, and control.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Agent Context Pack Template as the practical operational template for packaging task context, source material, source of truth, Brain ownership, relevant standards, workflow stage, tool boundaries, risk level, output requirements, evidence, assumptions, handoff destination, and expected outcome before AI Employees perform meaningful work.

This template operationalizes the MWMS AI Agent Memory And Context Framework and supports Agentic Work Units, AI Employee workflows, Brain Room, AI Manager, Task Executor systems, Course Absorption, Newsletter Intelligence, Offer Evaluation, Developer Support, Validation, Handoffs, and future AIBS client workflows.