MWMS Tool-Agnostic Context Portability Protocol

System: MWMS
Document Type: Protocol
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, AI Business Systems Brain, AI Manager, AI Employee Router, Brain Room, Course Absorption System, Content Brain, Offer Brain, Sales Brain, Creative Brain, Research Brain, Future AIBS Client Systems
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: No Development Action Authorized By This Page
Source Of Truth: MCR

Purpose

The purpose of this document is to define the MWMS Tool-Agnostic Context Portability Protocol.

This protocol establishes how MWMS prepares, adapts, loads, transfers, and uses context libraries across different AI tools, workspaces, agents, projects, Brains, and future client systems without becoming dependent on any single AI platform.

MWMS must not build its intelligence around one tool.

Tools change.

Interfaces change.

Memory systems change.

Pricing changes.

Capabilities change.

AI platforms may rename features, limit context windows, remove functionality, change file handling, alter project memory, or introduce new agentic workflows.

MWMS must be able to carry its intelligence across tools.

This protocol exists to ensure that context libraries, offer files, skill files, voice files, methodology files, proof files, and client libraries remain portable, reusable, and understandable across:

ChatGPT

Claude

Gemini

NotebookLM

Perplexity

OpenAI API

Claude Projects

agentic systems

internal MWMS AI Employees

future AI Manager workflows

future AIBS client systems

The goal is to make MWMS context independent of the tool currently being used.

Scope

This protocol applies to all MWMS context libraries, offer libraries, client libraries, skill libraries, project folders, and AI workflow contexts that may be used across multiple AI tools or systems.

This includes:

HeadOffice Brain

AI Business Systems Brain

AI Manager

AI Employee Router

Brain Room

Course Absorption System

Newsletter Intelligence

Opportunity System

Offer Brain

Content Brain

Creative Brain

Sales Brain

Conversion Brain

Customer Brain

Research Brain

Affiliate Brain

Ads Brain

future AIBS client systems

This protocol applies when MWMS needs to:

load context into an AI tool

move context between tools

prepare files for AI use

summarize a context library for limited context windows

create context packs

mount files into a project

prepare tool-specific usage instructions

preserve source-of-truth structure

prevent context loss during tool switching

support future client AI systems

This protocol does not authorize technical development, plugin changes, Supabase changes, WordPress changes, automation wiring, API implementation, or M developer action.

Core Definition

Tool-Agnostic Context Portability means that MWMS context is structured so it can be reused across multiple AI tools without losing meaning, authority, file boundaries, source-of-truth status, or operational rules.

A portable context system is not trapped inside:

one chat thread

one AI project

one vendor memory feature

one tool-specific file format

one model’s behaviour

one platform’s folder structure

one prompt library

one temporary upload

A portable context system can be moved, summarized, reloaded, validated, and used by different AI environments while preserving the same underlying business intelligence.

Core Principle

The core principle of this protocol is:

MWMS intelligence belongs to MWMS, not to the AI tool currently reading it.

AI tools are execution surfaces.

MWMS context libraries are the source intelligence.

A tool may help read, generate, analyze, or apply context.

But the tool must not become the only place where the context lives.

If a platform loses memory, changes behaviour, or becomes unsuitable, MWMS must still retain its intelligence in governed source files.

Context Portability Layers

MWMS uses five context portability layers.

Source Library Layer

This is the approved source-of-truth context library.

Examples:

Offer Context Library

Client Context Library

MWMS Brain Context Library

AI Employee Context Pack

Skill Library

This layer is controlled by MWMS.

It is not dependent on one AI tool.

Tool Loading Layer

This is how the source library is made available to an AI tool.

Examples:

file upload

project knowledge

copy-and-paste context pack

retrieval system

NotebookLM source set

Claude project files

ChatGPT project files

custom API retrieval

manual context injection

This layer may change by tool.

Working Session Layer

This is the active session where AI performs the task.

Examples:

chat thread

project chat

agent run

Brain Room task

workflow execution

manual build session

This layer is temporary unless saved.

Output Layer

This is the generated output.

Examples:

draft page

ad script

email sequence

report

lead magnet

webinar outline

analysis

asset brief

Output is not automatically source truth.

It may be promoted only after review.

Learning Return Layer

This is how useful new learning is returned to the source library.

Examples:

new objection

new customer phrase

new proof

new retired language

new methodology clarification

new skill improvement

new audit finding

This layer prevents learning from being trapped inside a tool or chat session.

Tool-Agnostic File Requirements

Context files should be written so any strong AI tool can understand them.

A portable context file should have:

clear title

clear purpose

clear scope

plain language

consistent section headings

defined status

source-of-truth statement where needed

date or version where relevant

clear rules

clear examples

clear exclusions

clear update notes

A portable context file should avoid:

unclear shorthand

tool-specific commands unless necessary

hidden assumptions

unexplained abbreviations

confusing file names

mixed topics

unmarked draft material

unmarked old context

platform-only instructions

If a file only makes sense inside one tool, it is not portable enough for MWMS.

Portable Context Pack Standard

When moving context into an AI tool, MWMS may create a Context Pack.

A Context Pack is a compact, task-specific bundle of selected context.

A Context Pack may include:

task objective

owning Brain

relevant standards

selected context files

offer or client summary

voice rules

buyer summary

methodology summary

proof limits

retired language

compliance notes

required output

forbidden actions

review requirement

handoff destination

A Context Pack is not a replacement for the full library.

It is a selected working subset for the current task.

Context Pack Rule

Use the smallest complete context pack needed for the task.

Too little context creates weak output.

Too much context creates confusion, cost, and drift.

Tool Loading Workflow

MWMS uses the following workflow when loading context into any AI tool.

Step 1: Define The Task

Identify what the AI tool is being asked to do.

Examples:

draft landing page

review sales email

generate ad hooks

summarize course block

build client report

check voice alignment

create webinar outline

Step 2: Identify Required Context

Select the minimum context needed.

Examples:

Offer Profile

Right-Fit Client Profile

Voice Architecture

Objection Library

Proof Library

Retired Language

Compliance Notes

Step 3: Check File Authority

Confirm whether the files are:

Approved

Draft

Under Review

Archived

Retired

Only approved files should guide final output.

Step 4: Prepare Tool-Friendly Format

Depending on the tool, prepare the context as:

uploaded files

pasted context pack

project knowledge

structured prompt

source bundle

briefing note

retrieval reference

Step 5: State Usage Rules

Tell the tool how to use the context.

Example rules:

Use the attached context as source truth.

Do not invent missing proof.

Do not use retired language.

Ask if required context is missing.

Preserve the approved voice.

Treat output as draft until reviewed.

Step 6: Perform The Task

Generate or review the required output.

Step 7: Validate Against Context

Check the output against the active context files.

Step 8: Capture Useful Learning

If the task reveals new approved learning, route it back to the source library.

Tool-Specific Context Risk

Different AI tools create different risks.

MWMS must understand these risks before relying on a tool.

Chat Thread Risk

Risk:

Context may be trapped in one long conversation.

Failure Mode:

AI appears to remember but loses important details later.

Protection:

Use source files and context packs, not just chat memory.

Project Memory Risk

Risk:

Project knowledge may become cluttered or stale.

Failure Mode:

Old files remain active after being replaced.

Protection:

Audit project files and use clear active/draft/archive status.

File Upload Risk

Risk:

Uploaded files may be temporary or not available later.

Failure Mode:

AI output relies on a file that is not preserved in source truth.

Protection:

Keep original files in MWMS-controlled storage.

Tool Memory Risk

Risk:

Vendor memory may store useful preferences but not full source truth.

Failure Mode:

Memory guides output incorrectly or incompletely.

Protection:

Treat tool memory as support, not authority.

Agentic Tool Risk

Risk:

Agent may take actions from incomplete or wrong context.

Failure Mode:

Wrong files used, wrong client context loaded, or output generated too early.

Protection:

Use permission boundaries, context packs, and human review.

Retrieval Risk

Risk:

Retrieval may pull the wrong file or partial section.

Failure Mode:

AI acts on incomplete context.

Protection:

Validate retrieved context and require source visibility where needed.

Context Window Risk

Risk:

Large libraries may exceed tool limits.

Failure Mode:

Important rules are dropped or ignored.

Protection:

Use compact context packs and task-specific summaries.

Tool Lock-In Risk

Risk:

MWMS process becomes dependent on a feature from one AI tool.

Failure Mode:

Workflow breaks when the tool changes.

Protection:

Keep source files tool-agnostic and maintain manual fallback workflows.

Context Loading Rules

Rule 1: Source Files Stay Outside The Tool

The approved source files must remain in MWMS-controlled storage.

AI tool uploads are working copies.

Rule 2: Tool Memory Is Not Source Truth

Tool memory may help, but it does not replace approved context files.

Rule 3: Use Task-Specific Context

Do not load full libraries when a smaller context pack is enough.

Rule 4: Mark Draft Context

If draft context is used, the output must be treated as draft.

Rule 5: Preserve File Boundaries

Do not merge multiple unrelated files into one unclear context dump.

Rule 6: Include Forbidden Actions

Every important context loading prompt should tell the AI what not to do.

Rule 7: Use Retired Language Where Relevant

If the task involves messaging, load Retired Language when available.

Rule 8: Validate Output Before Promotion

Output created in an AI tool must be reviewed before becoming MCR, active context, or client-facing material.

Rule 9: Return Learning To Source Library

Useful learning should not remain trapped in the AI tool.

Rule 10: Keep Client Context Isolated

Do not load multiple clients into the same working context unless the task explicitly requires comparison and has permission.

Portable Context Pack Template

Use this template when preparing a task-specific context pack.

Task:

Owning Brain:

Supporting Brains:

Offer Or Client:

Context Status:

Source Files Used:

Task Objective:

Buyer Summary:

Offer Summary:

Voice Rules:

Differentiation Notes:

Objections To Address:

Proof Available:

Retired Language:

Compliance Notes:

Required Output:

Forbidden Actions:

Human Review Required:

Handoff Destination:

Missing Context:

Notes:

This template may be shortened for low-risk work.

It should be used more fully for high-value, public-facing, client-facing, or cross-Brain outputs.

Tool Usage Instruction Template

When loading context into an AI tool, use instructions like:

Use the provided context as working source material for this task.

Do not treat memory or assumptions as stronger than the supplied context.

Do not invent missing proof, testimonials, statistics, buyer language, founder beliefs, or offer details.

If required context is missing, flag it clearly.

Preserve approved voice and offer truth.

Avoid any retired language provided.

Treat the output as draft until reviewed.

Follow the requested output format exactly.

This instruction may be adapted by task.

Manual Fallback Rule

Every important MWMS context workflow should have a manual fallback.

If a tool cannot load files, remember context, or manage project knowledge safely, MWMS should still be able to work by using:

pasted context packs

short summaries

source excerpts

manual file references

structured prompts

review checklists

Do not design MWMS workflows that only work inside one AI tool.

Context Compression Rule

When a context library is too large for a tool, compress it into a task-specific summary.

Compression should preserve:

buyer

offer

voice

methodology

differentiation

objections

proof limits

retired language

compliance constraints

Compression should remove:

irrelevant history

unused examples

duplicate wording

project clutter

old drafts

unrelated Brains

Compression must not remove critical risk rules.

Output Promotion Rule

Output generated inside an AI tool is not automatically approved.

Possible output statuses:

Draft

Needs Review

Approved For Use

Promote To MCR

Promote To Context Library

Park