System: MWMS
Document Type: Operating Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.1
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, AIBS Brain, Data Brain, Automation Brain, Research Brain, Experimentation Brain, Finance Brain, Content Brain, Sales Brain, Risk Brain, Compliance Brain, Operations 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-20
Source / Origin: MWMS Business Brain Copilot Architecture Framework v1.0 + AI Automations by Jack — Claude Agent Teams, Claude Skills 2.0, Agentic OS, NotebookLM knowledge systems, persistent project instructions, multi-model routing, dashboard systems and controlled business operating workflows block
MWMS Classification: AIOS Architecture Framework / Business Copilot Framework / Context-Memory-Tool-Data Operating Standard / HeadOffice Decision Support Architecture
Primary Brain: HeadOffice Brain
Supporting Brains: AIBS Brain, Data Brain, Automation Brain, Research Brain, Experimentation Brain, Finance Brain, Content Brain, Sales Brain, Risk Brain, Compliance Brain, Operations Brain, Product Brain, Customer Brain
Related Pages: AIBS Brain Canon, MWMS AI Operating System Architecture Framework, MWMS Context Engineering Framework, MWMS AI Agent Memory And Context Framework, MWMS AI Tool Permission And Access Framework, MWMS AI Automation Security And Risk Checklist, MWMS Dashboard-First Client AIOS Offer Framework, MWMS AI Audit Diagnostic And Paid Roadmap Framework, MWMS Commercial Constraint And Client Acquisition Operating Framework, MWMS Offer And Niche Selection Framework, MWMS Avatar Hypothesis And Market Definition Framework, MWMS Source Visibility And Evidence Display Standard, MWMS Brain To Brain Request Protocol, MWMS Brain Routing Rule, MWMS Supabase RAG And Vector Memory Framework, MWMS AI Dashboard Capability Framework, HeadOffice Kaizen Continuous Improvement Loop, MWMS AI Agent Orchestration Framework, MWMS AI Multi Agent Role Design Framework, MWMS AI Agent Skill Library Framework, MWMS AI Skill Builder And Audit Protocol, MWMS External Knowledge Engine And Reasoning Agent Separation Framework, MWMS Independent Model Review And Rescue Routing Framework, MWMS AI Work Session Closure And Knowledge Commitment Protocol
Source Evidence: The existing framework is derived from the AI Automations by Jack business systems block, which frames the major business AI advantage as context, speed, and focus, and introduces a business copilot architecture built from a Business Brain Profile, working files, long-term memory, system instructions, external tool access, and structured business numbers. The newly absorbed material strengthens the framework with approved Skill libraries, specialist AI Agent Teams, task orchestration, persistent project instructions, external knowledge workspaces, model routing, independent review, rescue paths, controlled execution, observable dashboards and session-to-memory commitment.
Purpose
The purpose of the MWMS Business Brain Copilot Architecture Framework is to define how MWMS structures a full business AI copilot using context, memory, operating instructions, tools, structured data, dashboards, and decision-support outputs.
This framework exists because MWMS must not think of AI as a chatbot.
A business copilot is not just a conversation window.
A serious business copilot needs:
a canonical business profile
source-of-truth hierarchy
business identity
operating doctrine
active working files
long-term memory
structured business numbers
tool access
dashboards
action outputs
task routing
governance
decision-support logic
The source block positions AI advantage around three factors:
Context — the AI must understand the business deeply
Speed — the AI must help the business act faster
Focus — the AI must help identify the most important bottleneck and avoid distraction
This is strongly aligned with MWMS.
MWMS already has Brains, MCR pages, Brain Room, HeadOffice, Supabase, AI Employees, task logs, dashboards, memory frameworks, and AIOS architecture.
This framework ties those pieces together into a clear architecture:
Business Brain Profile + Memory Layers + Operating Doctrine + Tool Routing + Numbers Layer + Dashboards + Governance = Business Brain Copilot.
Core Doctrine
The MWMS doctrine is:
AI without business context is weak.
AI with business context, memory, tools, numbers, and governance becomes a business copilot.
A business copilot must know:
who the business is
who it serves
how it makes money
what it believes
what it will and will not do
what its current bottleneck is
what the numbers say
what systems already exist
what tools it may use
what memory it should retrieve
what actions it may recommend
what actions require human approval
what source of truth must be followed
The copilot must not behave like a generic assistant.
It must act within the business’s identity, rules, priorities, evidence, and governance boundaries.
Strategic Importance
This framework is strategically important because it strengthens several MWMS directions at once.
It supports:
HeadOffice decision-making
AIBS client AIOS architecture
Business Brain setup
AI Employee context packs
Memory and retrieval design
structured data / Supabase design
tool permission boundaries
dashboard-first client systems
AI audit outputs
client onboarding
business diagnostics
task creation and routing
decision-support reporting
The block’s strongest lesson is:
The AI copilot becomes powerful when it stops being generic and starts operating inside the real business context.
The course’s brain.md concept describes a business DNA document containing the business identity, customers, problems solved, customer journey, metrics, team, current state, links, founder story, credibility, edge, and audience sophistication.
For MWMS, this becomes bigger than a file.
It becomes a Business Brain Profile Standard.
Every serious MWMS Brain, AI Employee, client AIOS, or AIBS client package needs a canonical profile that defines what the system must know before it acts.
Definition
A business brain copilot is an AI-supported operating system that understands the business, retrieves relevant memory, reads structured data, uses approved tools, creates structured outputs, and helps the owner or team make better decisions.
A Business Brain Profile is the canonical identity and context document that defines the business, customer, offer, journey, numbers, team, constraints, current focus, dream outcome, founder story, links, and operating boundaries.
A numbers layer is the structured database layer that stores metrics and business performance data so the AI can reason from actual numbers rather than memory alone.
A tool-routing layer defines what tools the copilot may use, when to use them, and what approval boundaries apply.
MWMS Definition
The MWMS Business Brain Copilot Architecture is:
A governed AIOS pattern that combines business identity, context hierarchy, memory layers, operating doctrine, approved tool access, structured business numbers, visible outputs, and decision-support logic so MWMS or a client business can make faster, better, more focused decisions.
Scope
This framework applies to:
HeadOffice Brain decision support
MWMS Brain Room evolution
AI Manager architecture
AI Employee context packs
AIBS client AIOS foundations
client business brain profiles
AI audit intake and roadmap systems
Data Brain schemas
Supabase metrics systems
vector memory / RAG systems
MCR retrieval systems
dashboard systems
business operating dashboards
tool routing policies
MCP / API / automation bridge architecture
system instruction files
AIOS governance
business bottleneck analysis
executive decision support
future client copilot offers
This framework does not authorise immediate development work.
Any implementation must be converted into a separate developer-safe brief with exact site, page, table, file path, test steps, and rollback notes.
Core Principle
The core principle is:
A business copilot must combine context, memory, tools, numbers, and governance.
Context alone is not enough.
Memory alone is not enough.
Tools alone are dangerous.
Numbers alone lack interpretation.
Dashboards alone do not decide.
Instructions alone do not create business value.
A serious copilot needs all layers working together.
The MWMS Business Brain Copilot Stack
The standard MWMS Business Brain Copilot stack contains sixteen layers:
Business Brain Profile Layer
System vs Session Layer
Context Hierarchy Layer
Memory Layer
External Knowledge Workspace Layer
Operating Doctrine Layer
Skill Library Layer
AI Employee And Agent Team Layer
Orchestration Layer
Model And Review Routing Layer
Tool Routing Layer
Numbers / Structured Data Layer
Output Workspace Layer
Dashboard And Decision Layer
Session Closure And Knowledge Commitment Layer
Governance And Safety Layer
- Business Brain Profile Layer
The Business Brain Profile is the canonical identity of the business.
It answers:
who the business is
who it serves
what it sells
how it makes money
what it believes
how it decides
what it will not do
what its current bottleneck is
what its dream outcome is
The source block describes brain.md as the business DNA, single source of truth, and backbone for who the business is, who it serves, how it makes money, what it believes, how it decides, and what it will and will not do.
Business Brain Profile Fields
Every Business Brain Profile should include:
Business Name:
Business Owner / Maker:
Business Summary:
Primary Business Model:
Revenue Streams:
Primary Offers:
Target Customers:
Ideal Customer Profile:
Customer Problems Solved:
Big Problem Umbrellas:
Customer Journey:
Click-To-Close Path:
Lead Sources:
Sales Process:
Delivery Process:
Retention Process:
Current Metrics:
Revenue:
Profit:
Leads:
Appointments:
Presentations:
Sales:
Retention / Churn:
Team Members:
Contractors:
Roles:
Costs:
Current Bottleneck:
Current Focus:
Dream Outcome:
Core Links:
Website:
Social Profiles:
Content Channels:
Founder Origin Story:
Credibility:
Unique Edge:
Audience Sophistication:
Decision Rules:
Constraints:
What The Business Will Not Do:
Approved AI Employees:
Approved Skills:
Approved Knowledge Workspaces:
Approved Model Routes:
Approved Tools:
Human Approval Gates:
Current Operating Mode:
Source Of Truth:
Last Updated:
Rule
A business copilot without a Business Brain Profile is operating with incomplete identity.
- System vs Session Layer
The source block separates systems from sessions.
Systems are more static, repeatable operating assets such as websites, dashboards, operating systems, scraping systems, content systems, and workflow systems. Sessions are flexible working conversations with the AI where the user may explore ideas, decisions, plans, or documents.
MWMS must preserve this distinction.
Systems
Systems are structured assets.
Examples:
HeadOffice dashboard
Brain Room
task queue
client AIOS
lead qualification system
content repurposing system
competitor intelligence system
MCR page structure
Supabase database
AI audit roadmap dashboard
client reporting system
workflow automation
Systems should be:
documented
repeatable
governed
measurable
supportable
tied to outcomes
Sessions
Sessions are working conversations.
Examples:
strategy discussion
idea exploration
page drafting
client call preparation
bottleneck analysis
audit analysis
campaign review
content planning
decision support
task planning
Sessions should produce:
decisions
notes
tasks
documents
updates
memory entries
action plans
page drafts
system improvement recommendations
Rule
Systems run the business.
Sessions improve, use, or create systems.
- Context Hierarchy Layer
The business copilot needs a hierarchy of truth.
The source block’s system instructions lesson defines a hierarchy including system doctrine, brain.md, project files, live resources, long-term memory, current thread, and inference.
MWMS should use its own hierarchy.
MWMS Context Hierarchy
The standard hierarchy is:
System / Developer Instructions
MWMS Constitution / Canons / MCR Source Of Truth
Brain Canon
Business Brain Profile
Relevant MCR Pages
Active Project Files / Current Working Context
Structured Data / Supabase / Metrics
Approved Tool Outputs
Long-Term Memory / Vector Retrieval
Current Conversation
Clearly Labelled Inference
Rule
The copilot must know which source has authority when sources conflict.
MCR and Brain Canons outrank casual conversation.
- Memory Layer
The source block separates memory into:
short-term memory
mid-term memory
long-term memory
Short-term memory is the current conversation/context window. Mid-term memory is active project files used regularly. Long-term memory is a vector/RAG database for material that should be retrievable later but not always loaded.
MWMS should adopt this as an architectural standard.
Short-Term Memory
Short-term memory includes:
current conversation
current task
current files
current page being drafted
current decision
current user instruction
Use for:
immediate work
active drafting
live decision-making
current block absorption
Risk:
can drift if conversation is long
can lose important details
should not be the only source of truth
Mid-Term Memory
Mid-term memory includes frequently used project files and active context.
Examples:
current Brain Canon
current MCR page being updated
active project brief
current campaign rules
recent uploaded course files
active client audit notes
active implementation checklist
current metrics export
Use for:
work happening this week/month
active projects
often-used reference material
Long-Term Memory
Long-term memory includes searchable archives.
Examples:
old course transcripts
newsletters
old audits
client documents
meeting notes
historic campaign results
content archives
research libraries
MCR history
case study archive
Use for:
retrieval when needed
evidence support
long-range continuity
pattern detection
Memory Placement Rule
If it is used often, keep it close.
If it is needed later but not constantly, store it in long-term retrieval.
If it is source-of-truth, it must live in MCR or the approved canonical system.
Rule
Memory must be placed according to frequency, authority, and risk.
- External Knowledge Workspace Layer
The business copilot needs governed access to large and durable knowledge collections.
Possible knowledge workspaces include:
Business Canon Workspace
Client Workspace
Project Workspace
Research Workspace
Course And Training Workspace
Campaign Workspace
Meeting And Decision Workspace
Session History Workspace
Each workspace should define:
workspace purpose
owner
allowed sources
authority level
client or project boundary
access permissions
retention
review cycle
deprecation rules
retrieval filters
The copilot should retrieve only the evidence required for the current decision.
External Knowledge Rule
The knowledge engine preserves and retrieves evidence.
The copilot interprets evidence and acts within authority.
Retrieval does not automatically create truth or permission.
- Operating Doctrine Layer
The operating doctrine layer tells the AI how to behave.
The source block uses a master instruction file that defines the AI as a business brain copilot, not a general chatbot, and instructs it to load business context, follow a hierarchy of truth, route tools, output recommendations, and operate around clarity, leverage, alignment, and execution.
MWMS should implement this through Brain Canons, Employee Role Cards, system prompts, tool policies, and client AIOS instruction files.
Operating Doctrine Fields
Each serious copilot should define:
Identity:
Purpose:
Owner:
Primary User:
Authority Level:
Source Of Truth:
Truth Hierarchy:
Required Context:
Allowed Tools:
Prohibited Tools:
When To Retrieve Memory:
When To Use Structured Data:
When To Ask Clarifying Questions:
When To Escalate:
When To Create Tasks:
Output Format:
Tone / Style:
Accuracy Rules:
Evidence Rules:
Memory Write Rules:
Governance Rules:
Risk Boundaries:
Human Approval Requirements:
Rule
A copilot without operating doctrine behaves like a generic chatbot.
- Skill Library Layer
A business copilot should use approved reusable Skills for repeated work.
Possible Skills include:
Business Bottleneck Diagnosis Skill
Meeting Preparation Skill
Executive Summary Skill
Market Research Skill
Content Repurposing Skill
Offer Evaluation Skill
Dashboard Insight Skill
Developer Handoff Skill
Client Report Skill
Each Skill must define:
trigger
scope
required input
required context
procedure
allowed tools
output
validation
failure conditions
handoff
active version
Skill Rule
Skills provide repeatable procedure.
They do not create authority beyond the copilot’s approved role, Capability Stack or Tool Permissions.
- AI Employee And Agent Team Layer
The copilot may coordinate several specialist AI Employees.
Possible roles include:
Executive Copilot
Researcher
Data Analyst
Finance Reviewer
Content Strategist
Sales Strategist
Operations Coordinator
Risk Reviewer
Independent Reviewer
Synthesis Agent
Task Router
Knowledge Commitment Agent
A single AI Employee should be used where one role is sufficient.
An Agent Team should be used only where specialist separation materially improves quality, speed, safety or accountability.
Agent Team Rule
Every multi-agent workflow requires:
one Work Unit
one Owning Brain
clear role boundaries
shared and isolated context rules
structured handoffs
a Synthesis Owner
cost limits
failure thresholds
shutdown controls
- Orchestration Layer
The Orchestration Layer coordinates the full operating sequence.
It determines:
what the request is
which Brain owns it
which AI Employee acts
which Skill applies
which model route is appropriate
which knowledge workspace should be searched
which tools are permitted
which stages run sequentially
which stages may run in parallel
what validation is required
what happens if the route fails
where the output goes
what must be logged
what must be committed to memory
The default serious-work sequence is:
Request
→ Classification
→ Ownership
→ Work Unit
→ Skill Selection
→ Context Assembly
→ Knowledge Retrieval
→ Model And Tool Routing
→ Processing
→ Review
→ Decision
→ Handoff
→ Logging
→ Knowledge Commitment
→ Closure
Orchestration Rule
The copilot should not begin material work until ownership, procedure, context, tools, validation, destination and expected outcome are clear.
- Model And Review Routing Layer
The copilot should select model and reviewer routes according to:
task complexity
risk
cost
speed
privacy
modality
context length
independence
specialist need
Possible routes include:
low-cost extraction model
standard reasoning model
advanced reasoning model
local private model
multimodal model
specialist model
independent reviewer
rescue model
deterministic validator
Model Routing Rule
The strongest or most expensive model is not always the correct default.
High-risk work should receive independent review.
Repeated failure should trigger a materially different rescue route rather than unlimited retries.
- Tool Routing Layer
The tool routing layer defines what the copilot may access and when.
The source block shows direct MCP integrations and n8n as a “universal remote” that can bridge to tools such as Gmail, Calendar, Drive, and other workflows.
For MWMS, this is useful but must be governed.
Tool Types
Possible tools include:
Gmail
Google Calendar
Google Drive
Supabase
WordPress / MCR
Make
n8n
Firecrawl
scraping tools
CRM
task systems
dashboards
analytics
ad platforms
reporting tools
document tools
vector stores
finance systems
content tools
Tool Routing Questions
Ask:
What tool is needed?
Why is it needed?
Is the tool approved for this Brain or AIOS?
What data will be accessed?
Is the action read-only or write-capable?
Does the user need to approve?
Is there a risk?
Is the action logged?
Does this touch client data?
Does this touch external communication?
Does this affect money, ads, publishing, or customer contact?
Universal Remote Rule
n8n or Make may act as controlled execution bridges.
But they must not become unrestricted access layers.
Rule
Tool access is authority.
Authority must be governed.
- Numbers / Structured Data Layer
The source block’s numbers lesson is critical.
It explains that text memory is not enough for business decision-making. Business numbers need structured storage, such as a database, so the AI can query metrics, calculate averages, identify trends, compare sources, and support executive decisions.
For MWMS, this is a major standard:
Text memory explains context. Structured data explains performance.
A business copilot needs both.
Numbers Categories
The source block groups numbers into areas such as revenue/finance, leads/sales, customers, and content/platform metrics.
MWMS should structure numbers across:
Finance
revenue
profit
expenses
cashflow
subscriptions
tool costs
ad spend
CAC
LTV
margin
churn
Leads And Sales
leads
source
appointments
presentations
sales
close rate
show-up rate
follow-up rate
pipeline stage
offer conversion
Affiliate
impressions
views
clicks
LPCTR
VSL clicks
sales
refunds
EPC
CPA
ROAS
profit/loss
PPL
visitors
form starts
submitted leads
accepted leads
rejected leads
payout
CPL
rejection reason
buyer value
Content
platform
title
format
views
likes
comments
watch time
CTR
engagement
subscribers
leads generated
conversions
AIBS
audit leads
audits sold
implementation proposals
projects sold
MRR
churn
client value metrics
support load
reports delivered
time saved
opportunities found
Operations
tasks
task status
blockers
owner
due dates
events
completion rate
failed task rate
handoff time
Rule
Business numbers belong in structured data, not scattered conversation notes.
- Output Workspace Layer
The copilot should create useful operating assets.
The source Notion lesson shows the AI creating documents, job descriptions, plans, to-do lists, and structured pages using a workspace integration.
For MWMS, the destination is not automatically Notion.
The destination depends on authority and purpose.
MWMS Output Destinations
Possible output destinations:
MCR page
HeadOffice dashboard
Brain Room
Supabase task
WordPress admin panel
client AIOS dashboard
audit roadmap
proposal draft
report
Google Doc
Google Sheet
operating brief
implementation checklist
SOP
content calendar
task list
email draft
sales script
experiment plan
Output Questions
Ask:
Is this source-of-truth?
Is this operational?
Is this a draft?
Is this client-facing?
Is this internal?
Does it need approval?
Where should it live?
Who needs to see it?
Does it create a task?
Does it update memory?
Rule
The copilot should create structured assets, not just answers.
- Dashboard And Decision Layer
A business copilot should help make better decisions.
Dashboards and reports make this visible.
The numbers lesson shows the AI querying structured data and answering questions like average views, growth trends, and future projections.
MWMS should use dashboards and decision reports to connect:
context
memory
metrics
tasks
recommendations
next actions
Decision Outputs
The copilot may produce:
bottleneck diagnosis
constraint report
priority list
next three actions
opportunity scorecard
campaign review
content performance review
lead pipeline review
client audit roadmap
finance snapshot
task health report
weekly Kaizen digest
risk alert
trend report
experiment recommendation
Decision Questions
Ask:
What matters most now?
What is the bottleneck?
What do the numbers show?
What does the memory/context show?
What is the highest-leverage action?
What can be ignored?
What needs escalation?
What should be tested?
What should be built?
What should be parked?
Rule
A business copilot should convert data and context into decision support.
- Session Closure And Knowledge Commitment Layer
Every meaningful copilot work session should end with controlled closure.
Closure should record:
objective
work completed
decisions made
outputs created
validation status
open issues
next action
current save point
knowledge to commit
knowledge not to commit
owner
destination
Session Closure Rule
A useful conversation is not complete until the result is routed, logged and committed where appropriate.
The copilot must not save raw conversation, unsupported inference or unapproved draft material as durable organisational truth.
- Governance And Safety Layer
The more powerful the copilot becomes, the more governance matters.
If the copilot can access tools, write files, query databases, create tasks, draft emails, update dashboards, or trigger workflows, it must be bounded.
Governance Requirements
A business copilot must define:
source-of-truth authority
user permissions
tool permissions
read/write boundaries
approval gates
audit logs
memory write rules
client data boundaries
external communication rules
publishing rules
financial action restrictions
deletion restrictions
escalation conditions
risk categories
fallback procedures
human ownership
Rule
A powerful copilot without governance becomes a business risk.
Business Copilot Operating Modes
MWMS supports five copilot operating modes.
Advisory Mode
The copilot answers questions and provides recommendations.
Drafting Mode
The copilot creates structured drafts for review.
Assisted Operating Mode
The copilot recommends routing, tasks, tools and next actions, but a human approves them.
Controlled Operational Mode
The copilot performs approved low- or medium-risk workflow steps with logging and review gates.
Restricted Autonomous Mode
The copilot performs low-risk, tightly bounded tasks without immediate human review.
Operating Mode Rule
The mode must match the risk, reversibility, proof level, Tool Permissions and human authority.
A client or internal copilot should begin in the lowest practical authority mode and earn greater capability through validated performance.
The Context + Speed + Focus Advantage
The source block defines the three differentiators as:
context
speed
focus
MWMS should treat this as a core business copilot doctrine.
Context
Context means the AI understands:
the business
the owner
the customer
the offer
the numbers
the history
the current bottleneck
the constraints
the rules
the source of truth
Without context, AI gives generic advice.
Speed
Speed means the AI helps:
create faster
decide faster
analyse faster
retrieve faster
draft faster
route faster
build faster
respond faster
test faster
Without speed, the copilot does not create leverage.
Focus
Focus means the AI helps identify:
the bottleneck
the 10X constraint
what matters now
what should be ignored
what should be parked
what should be tested
what should not be built
Without focus, AI creates more distraction.
Rule
A Business Brain Copilot must improve context, speed, and focus.
Business Copilot Work Unit Standard
Material copilot work should be represented as a Work Unit.
Work Unit fields:
Work Unit ID:
Request:
Owning Brain:
Supporting Brains:
Objective:
Expected Outcome:
Risk Level:
Assigned AI Employee:
Assigned Skills:
Model Route:
Required Context:
Knowledge Workspace:
Structured Data Required:
Allowed Tools:
Approval Gates:
Required Output:
Validation:
Failure Threshold:
Rescue Route:
Handoff Destination:
Knowledge Commitment Requirement:
Closure Condition:
Work Unit Rule
The copilot should not convert every casual question into formal workflow.
A Work Unit is required where the request creates material work, risk, cross-Brain routing, tool use, durable output or operational follow-up.
Business Brain Profile Standard
Every serious MWMS business copilot or client AIOS should begin with a Business Brain Profile.
Profile Sections
- Business Identity
business name
owner
mission
current stage
business model
primary revenue streams
source of truth
- Customer / Avatar
ideal customer
customer segments
geography
sophistication level
pains
desires
objections
buying triggers
- Offer And Monetisation
offers
pricing
fulfilment
recurring revenue
upsells
value proposition
transformation promised
- Customer Journey
discovery
lead capture
follow-up
sales process
payment
onboarding
delivery
retention
referral
- Numbers
revenue
profit
leads
conversion
retention
churn
content metrics
campaign metrics
operating metrics
- Team
internal team
contractors
roles
costs
performance notes
responsibilities
- Current State
current bottleneck
current focus
active projects
current risks
constraints
dream outcome
- Owner / Maker
founder story
credibility
beliefs
edge
preferred work style
public brand
content angle
- Rules And Boundaries
what the business will not do
compliance rules
decision rules
cost rules
tool rules
approval rules
Rule
The Business Brain Profile must be updated when the business materially changes.
Business Brain Update Triggers
Update the Business Brain Profile when:
offer changes
avatar changes
business model changes
pricing changes
team changes
new Brain is created
new AIOS is created
current focus changes
major bottleneck changes
key metrics change
new compliance boundary appears
new tool stack is adopted
new source-of-truth page is created
client onboarding is completed
audit produces a roadmap
Rule
The Business Brain Profile is a living canonical document, not a one-time worksheet.
Memory Routing Standard
MWMS should route information to the correct memory layer.
Active Context
Use for:
current task
current page
current file
current session
immediate decision
Project / Mid-Term Memory
Use for:
frequently referenced pages
current course block
active client audit
active campaign
current project brief
working SOPs
current metrics files
Long-Term Retrieval
Use for:
course archives
old newsletters
historical decisions
old transcripts
research archives
case study library
client history
past campaign data
External Knowledge Workspace
Use for:
large source collections
client knowledge bases
course and training libraries
research evidence
historical decisions
meeting and session archives
Structured Database
Use for:
metrics
task records
event logs
content performance
leads
customers
financial data
audit records
campaign records
experiment results
MCR / Canon
Use for:
final source-of-truth pages
Brain Canons
operating frameworks
governance rules
approved protocols
architectural standards
Rule
Do not store structured metrics in vector memory when they belong in a database.
Do not store source-of-truth rules only in chat memory.
Skill And Team Routing Standard
Before creating a one-off procedure, the copilot should check whether an approved Skill already exists.
Before creating an Agent Team, the copilot should check whether one qualified AI Employee is sufficient.
Use one AI Employee when:
the task is simple
risk is low
one reasoning mode is enough
one output is required
Use an Agent Team when:
specialist review is required
separate evidence streams are useful
independent review matters
parallel execution saves meaningful time
cross-Brain synthesis is required
Skill And Team Rule
Use the smallest approved capability set that can complete the Work Unit safely and well.
Tool Routing Policy Standard
Every business copilot should define tool routing.
Example Routing
Use MCR when:
canonical rule is needed
framework must be referenced
source-of-truth page exists
Brain Canon governs decision
Use Supabase when:
metrics are needed
tasks are needed
records are needed
structured data is needed
trend analysis is needed
Use vector memory when:
long-term documents must be retrieved
historic course/newsletter data is needed
semantic search is useful
Use Google Drive / Docs when:
user documents or files are stored there
a working document is needed
collaboration is needed
Use Gmail / Calendar only when:
user explicitly requests email/calendar action
permission is granted
tool access is appropriate
Use n8n / Make when:
workflow execution is needed
external tool bridge is required
controlled automation is approved
Use web/browser tools when:
current external information is needed
competitor/current market data is required
sources must be checked
Rule
The copilot should use the right source or tool for the job, not the most convenient one.
Numbers Layer Standard
The numbers layer should help the copilot answer business questions.
Questions The Numbers Layer Should Support
Where are we making money?
Where are we losing money?
What offer is working?
What content is resonating?
What campaign is profitable?
What lead source converts best?
What is the bottleneck?
What is trending up?
What is trending down?
What should we do more of?
What should we improve?
What should we stop?
What is the projected result if the trend continues?
Rule
Numbers must be queryable, structured, and attached to decisions.
Business Bottleneck Decision Standard
The copilot should help identify the bottleneck.
Common bottlenecks:
leads
conversion
delivery
profit
focus
proof
retention
traffic
content
sales
onboarding
support
cashflow
data quality
tool complexity
M build capacity
compliance risk
Bottleneck Questions
Ask:
What is the current constraint?
What evidence supports this?
What do the numbers show?
What does the business owner feel?
What does the customer journey show?
What stage is leaking?
Is this a knowledge problem, system problem, sales problem, or focus problem?
What is the highest-leverage action?
Rule
The copilot should not recommend new work before diagnosing the bottleneck.
Application To Meeting Intelligence
The Business Brain Copilot may support meetings by combining:
Business Brain Profile
current priorities
participant context
relevant records
open decisions
structured numbers
previous meeting notes
risk items
recommended questions
A meeting-preparation output may include:
meeting purpose
participant context
current business state
relevant metrics
open loops
decision required
questions to ask
risks
recommended position
follow-up tasks
Meeting Rule
The copilot should prepare the owner to make decisions.
It must not invent participant facts, private information or unsupported business context.
Application To HeadOffice Brain
HeadOffice Brain is the primary owner of this framework.
HeadOffice should use the Business Brain Copilot model to:
preserve Martyn’s vision
improve decisions
prevent drift
diagnose constraints
route tasks
assess priorities
protect M’s build capacity
manage Brain-to-Brain coordination
review metrics
produce operating summaries
maintain source-of-truth discipline
HeadOffice Rule
HeadOffice Copilot must always prioritise context, speed, focus, governance, and source-of-truth alignment.
Application To AIBS Brain
AIBS Brain uses this framework for client AIOS design.
Every serious AIBS client copilot should define:
client Business Brain Profile
operating doctrine
data sources
tool permissions
memory layers
dashboard outputs
client value reports
governance boundaries
numbers layer
decision support use cases
AIBS Rule
AIBS should sell business copilots as governed operating systems, not generic AI assistants.
Application To Data Brain
Data Brain owns the structured numbers layer.
Data Brain should define:
schemas
tables
fields
metrics
data quality rules
source of truth
update frequency
query patterns
dashboard logic
reporting standards
retention rules
client data isolation
Data Rule
If the copilot needs to calculate, compare, trend, or report numbers, the data belongs in a structured database.
Application To Automation Brain
Automation Brain owns execution bridges.
Automation Brain should define:
approved workflow triggers
n8n / Make routing
webhook security
workflow logs
action boundaries
approval gates
failure handling
retries
alerting
tool bridge ownership
Automation Rule
Automation bridges must be controlled, logged, and scoped.
Application To Research Brain
Research Brain supports context quality.
Research Brain should provide:
market context
avatar context
competitor research
source evidence
historical references
case study patterns
trend analysis
evidence packs
Research Rule
The copilot’s strategic advice is only as good as its context and evidence.
Application To Experimentation Brain
Experimentation Brain tests copilot recommendations.
Experimentation Brain should help define:
hypotheses
success criteria
test design
stop conditions
learning capture
experiment records
validation logic
Experimentation Rule
The copilot may recommend tests, but Experimentation Brain governs validation.
Application To Finance Brain
Finance Brain supports business numbers and financial decisions.
Finance Brain should define:
revenue tracking
cost tracking
margin logic
CAC/LTV
forecast rules
budget rules
tool-cost control
runway
profitability analysis
Finance Rule
The copilot must not make financial assumptions without structured data or clearly labelled uncertainty.
Application To Content Brain
Content Brain uses Business Brain Profile context for content creation.
Content Brain should use:
customer pains
founder story
edge
audience sophistication
content metrics
platform performance
market signals
offer rules
brand voice
Content Rule
Content created without Business Brain context will drift generic.
Application To Sales Brain
Sales Brain uses the Business Brain Profile and numbers layer to improve:
positioning
discovery
offer framing
objection handling
proposal drafting
cost of inaction
follow-up
close logic
Sales Rule
Sales advice must be based on the business model, customer journey, and numbers.
Application To Risk And Compliance Brain
Risk and Compliance Brain govern the copilot’s access and outputs.
They should check:
sensitive data
client data
regulated claims
external communication
tool access
memory writes
deletion actions
financial decisions
advertising claims
public publishing
privacy obligations
approval gates
Risk Rule
The more tools a copilot can use, the more governance it needs.
Application To Operations Brain
Operations Brain ensures the copilot’s outputs become action.
Operations should define:
task creation rules
owner assignment
handoff
due dates
follow-up cadence
dashboard review rhythm
escalation rules
weekly review process
Operations Rule
Decision support is incomplete unless it creates operating action.
Business Copilot Output Standards
When asked for business guidance, the copilot should usually provide:
What matters most
Current constraint
Evidence / context used
Recommended action
Next three steps
What not to do
Where this should be recorded or routed
Which Skill, AI Employee or Agent Team should handle follow-up
What evidence or numbers support the recommendation
What approval is required
What should be committed at closure
Rule
The copilot should reduce confusion, not create more options.
Business Copilot Setup Checklist
Before creating a business copilot, check:
Identity
Business Brain Profile created?
Owner defined?
Source of truth defined?
Business model clear?
Customer/avatar clear?
Memory
short-term context defined?
mid-term files defined?
long-term memory defined?
knowledge workspaces defined?
Knowledge Access Contracts defined?
memory placement rules defined?
memory update triggers defined?
Doctrine
operating instructions created?
approved Skills defined?
AI Employee roles defined?
Agent Team rules defined?
model and review routes defined?
Work Unit rules defined?
truth hierarchy defined?
output standards defined?
escalation rules defined?
guardrails defined?
Tools
approved tools listed?
read/write boundaries defined?
approval gates defined?
logs defined?
risky tools restricted?
Data
numbers layer defined?
key tables identified?
metrics defined?
update cadence defined?
dashboard/report needs defined?
Outputs
where does the copilot write?
where does it create tasks?
where does it create pages?
where does it create reports?
what needs approval?
what closes the session?
what knowledge is committed?
Governance
risk review complete?
compliance review complete?
human owner defined?
source-of-truth boundary clear?
Client Business Copilot Template
Use this template for future AIBS clients.
Client Business Name:
Owner / Decision Maker:
Primary User:
Industry:
Business Model:
Primary Offer:
Target Customer:
Core Problem Solved:
Customer Journey:
Current Bottleneck:
Current Metrics:
Team / Roles:
Tools Used:
Data Sources:
Memory Sources:
Knowledge Workspaces:
Approved Skills:
AI Employee Roles:
Agent Team Patterns:
Model And Review Routes:
Operating Doctrine:
Allowed Tools:
Restricted Tools:
Dashboard Outputs:
Reports:
Decision Support Use Cases:
Human Approval Rules:
Operating Mode:
Work Unit Types:
Session Closure Rules:
Knowledge Commitment Rules:
Risk Notes:
Compliance Notes:
MRR / Retention Logic:
Last Updated:
MWMS Internal Business Copilot Template
Use this template for internal MWMS Brain or HeadOffice copilot design.
Copilot Name:
Owning Brain:
Supporting Brains:
Purpose:
Authority Level:
Source Of Truth:
Brain Canon References:
Required MCR Pages:
Business Brain Profile:
Active Project Context:
Memory Sources:
Knowledge Workspaces:
Approved Skills:
AI Employee Roles:
Agent Team Patterns:
Model And Review Routes:
Structured Data Sources:
Tool Access:
Output Destinations:
Task Routing Rules:
Decision Types Supported:
Work Unit Rules:
Session Closure Rules:
Knowledge Commitment Rules:
Escalation Rules:
Human Approval Requirements:
Drift Risks:
Review Cadence:
Drift Protection
This framework protects MWMS from:
treating AI as generic chat
rebuilding context every session
losing business identity
confusing memory with source of truth
storing metrics in unstructured notes
giving tools too much access
creating dashboards without decision value
creating copilot outputs with no action
bypassing MCR authority
bypassing Brain Canons
overloading vector memory
overloading the context window
using Notion-style tools as source of truth when MCR is canonical
relying on AntiGravity or any one tool as the architecture
creating client copilots without data boundaries
creating automation bridges without governance
letting a copilot recommend new work before diagnosing the bottleneck
Copilot Drift Signals
Watch for:
AI gives generic advice
AI ignores MCR rules
AI forgets current focus
AI suggests work outside scope
AI uses wrong source of truth
AI invents facts
AI cannot identify the bottleneck
AI cannot access relevant numbers
AI relies on old context
AI recommends tools without governance
AI creates tasks without owner
AI creates pages without need
AI confuses systems and sessions
AI stores everything in the wrong layer
AI cannot explain evidence
AI creates too many options instead of next steps
AI uses unapproved Skills
AI creates Agent Teams where one role is sufficient
AI has no Synthesis Owner for parallel work
AI uses the wrong model or reviewer route
AI repeatedly retries without rescue
AI retrieves across client or project boundaries
AI ends sessions without routing, logging or knowledge commitment
AI activity cannot be linked to a business outcome
Rule
Copilot drift must be corrected by updating context, doctrine, memory placement, tool routing, or source-of-truth references.
Implementation Boundary
This page is an architecture framework, not a build task.
It does not instruct M to change:
mwmsbrain.site
mwmsheadofficebrain.site
Brain Room
Dev Console
AI Manager
Supabase tables
WordPress plugin files
MCR structure
AI Employee router
automation workflows
Before any implementation, HeadOffice must create a specific developer brief with:
exact site
exact module
exact purpose
exact file paths if code is involved
exact tables if database is involved
exact UI change
exact tool permissions
exact test steps
exact rollback notes
what not to touch
Rule
Architecture becomes development only after scoped approval.
Strategic Summary
This framework absorbs the strongest business systems lesson from the course block:
A serious business copilot is built from identity, context, memory, external knowledge, instructions, Skills, AI Employees, Agent Teams, orchestration, model routing, tools, numbers, dashboards, session closure, knowledge commitment, and governance.
The course used AntiGravity, Notion, Pinecone, n8n, and Supabase as examples.
MWMS should extract the architecture, not become dependent on the exact tool choices.
For MWMS, the correct interpretation is:
MCR remains source of truth
Supabase remains the structured data layer where appropriate
vector/RAG memory supports retrieval
Brain Canons define authority
AI Employees need operating doctrine
n8n/Make can be controlled execution bridges
dashboards show performance and value
Business Brain Profiles define identity
HeadOffice governs priority and focus
The value is not in the tool stack.
The value is in the complete copilot architecture.
Final Standard
The MWMS final standard is:
A Business Brain Copilot must know the business, follow the source of truth, retrieve the right memory, query the right numbers, use only approved tools, create structured outputs, and support focused decisions.
A valid copilot must include:
Business Brain Profile
system vs session distinction
context hierarchy
memory routing
external knowledge workspaces
operating doctrine
approved Skill library
defined AI Employees and Agent Team rules
orchestration and Work Unit logic
model, reviewer and rescue routing
tool routing policy
structured numbers layer
output workspace
dashboard and decision layer
session closure and knowledge commitment
governance and safety layer
That is the MWMS Business Brain Copilot Architecture standard.
Change Log
Version: v1.1
Date: 2026-06-20
Author: HeadOffice
Change:
Updated the MWMS Business Brain Copilot Architecture Framework using the AI Automations by Jack block covering Claude Agent Teams, Claude Skills 2.0, Agentic OS, NotebookLM knowledge systems, persistent project instructions, multi-model routing, dashboards and controlled business operating workflows.
Expanded the Business Brain Copilot Stack from ten layers to sixteen layers.
Added:
External Knowledge Workspace Layer
Skill Library Layer
AI Employee And Agent Team Layer
Orchestration Layer
Model And Review Routing Layer
Session Closure And Knowledge Commitment Layer
Business Copilot Operating Modes
Business Copilot Work Unit Standard
Skill And Team Routing Standard
Application To Meeting Intelligence
expanded Business Brain Profile fields
expanded Memory Routing Standard
expanded Business Copilot Output Standards
expanded Business Copilot Setup Checklist
expanded Client Business Copilot Template
expanded MWMS Internal Business Copilot Template
expanded Copilot Drift Signals
Purpose of update:
To evolve the framework from a context-memory-tools-numbers copilot model into a complete governed business operating architecture that also coordinates Skills, AI Employees, Agent Teams, external knowledge, Work Units, model and reviewer routes, rescue paths, session closure and durable learning.
Version: v1.0
Date: 2026-06-03
Author: HeadOffice
Change:
Created the MWMS Business Brain Copilot Architecture Framework from the AI Automations by Jack Business Systems block.
Change Impact Declaration
This v1.1 update expands the Business Brain Copilot from a ten-layer context, memory, tool, data, dashboard and governance model into a sixteen-layer AI operating architecture with Skills, specialist roles, Agent Teams, orchestration, knowledge workspaces, model routing, review, rescue and knowledge commitment.
Pages Created
None
Pages Updated
MWMS Business Brain Copilot Architecture Framework
Pages Deprecated
None
Standalone Pages Not Created
MWMS Business Copilot Skill Library Standard
MWMS Business Copilot Agent Team Framework
MWMS Business Copilot Work Unit Standard
MWMS Business Copilot Model Routing Framework
MWMS Business Copilot Operating Mode Standard
MWMS Business Copilot Session Closure Protocol
MWMS Business Copilot Knowledge Workspace Standard
These concepts were absorbed into the unified MWMS Business Brain Copilot Architecture Framework rather than created as separate pages.
Registries Requiring Update
None confirmed by the supplied source.
Canon Version Update Required
No
Change Log Entry Required
Yes
Strategic Absorption Result
MWMS gains a stronger Business Brain Copilot architecture that can understand the business, retrieve the correct knowledge, query real numbers, invoke approved Skills, coordinate specialist AI Employees, route models and reviewers, use governed tools, create structured decisions and tasks, recover from failure, preserve visible outcomes and commit validated learning after each meaningful work session.
END OF FULL FILE OUTPUT