System: MWMS
Document Type: Core Operating Standard
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, 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 Operations Core.
The MWMS AI Agent Operations Core establishes the operating model for how MWMS designs, governs, manages, validates, and improves AI Employees, AI workflows, Brain-to-Brain handoffs, automated tasks, and business execution systems.
This standard exists because MWMS is not being built as a simple chatbot system, prompt library, or collection of disconnected automations.
MWMS is being built as a governed AI business operating ecosystem.
Inside MWMS, AI must function as a structured workforce.
That means every AI interaction must be converted into a controlled operational unit with:
- a defined purpose
- a defined role
- a clear input
- a clear task
- a permitted scope
- a required output
- a validation standard
- a handoff destination
- a business outcome
- a learning or reporting loop where required
This document defines the foundation for that operating model.
Scope
This standard applies to all MWMS systems where AI performs work, supports decisions, creates outputs, processes data, routes intelligence, or participates in business execution.
This includes:
- HeadOffice Brain
- MWMS Brain
- AI Business Systems Brain
- Affiliate Brain
- Research Brain
- Experimentation Brain
- Finance Brain
- Content Brain
- Ads Brain
- Offer Brain
- Data Brain
- Strategy Brain
- Operations Brain
- Brain Room
- Dev Console
- AI Manager
- AI Employee Router
- Task Executor systems
- Supabase task and event systems
- Newsletter Intelligence systems
- Course Absorption systems
- future AIBS client systems
This standard applies to both manual and automated AI workflows.
Manual workflows include AI-assisted research, course absorption, report creation, strategy analysis, page generation, and user-guided decision support.
Automated workflows include task queues, newsletter ingestion, Brain Room requests, AI Employee execution, routed actions, reporting systems, and future client-facing AI business systems.
Core Definition
The MWMS AI Agent Operations Core defines AI work as a structured operational process.
In MWMS, AI is not treated as a general chat assistant.
AI is treated as a governed operational worker operating inside a larger business system.
An AI agent inside MWMS is defined as:
A role-bound AI worker that performs a defined task inside a controlled workflow, using approved inputs, permitted tools, required output formats, validation rules, handoff rules, and measurable business outcomes.
An AI Employee inside MWMS is a more formal version of an AI agent.
An AI Employee must belong to a Brain, have a defined role, operate within a task boundary, produce structured outputs, and follow the governance rules assigned by HeadOffice and the relevant Brain.
Core Principle
MWMS must not rely on one-shot prompting for important business work.
Complex work must be decomposed into structured stages.
Each stage must be assigned to the correct role, processed through the correct workflow, validated against the correct standard, and routed to the correct destination.
The core principle is:
MWMS AI systems must convert requests into governed work units, not casual AI conversations.
This principle applies to all serious MWMS workflows, including research, offer evaluation, newsletter intelligence, course absorption, reporting, finance forecasting, content production, experimentation, and future AIBS client delivery.
The MWMS Agentic Work Model
The MWMS Agentic Work Model is built on four foundations:
- Agent
- Orchestration
- Task
- Outcome
These four foundations define how AI becomes useful inside MWMS.
1. Agent
An agent is a role-bound AI worker.
An agent must not be treated as a vague intelligence source.
Each agent must have a defined responsibility.
Inside MWMS, an agent requires:
- name
- Brain owner
- purpose
- role boundary
- allowed inputs
- allowed outputs
- permitted tools
- forbidden actions
- validation requirements
- handoff destination
- escalation rules
- success metric
An agent may support one Brain or multiple Brains, but ownership must be clear.
For example, a Newsletter Signal Extraction Agent may operate under HeadOffice Brain but provide routed intelligence to Affiliate Brain, Ads Brain, Research Brain, Content Brain, or Finance Brain.
The Agent rule is:
No AI Employee should perform undefined work.
Every AI Employee must know what it is allowed to do, what it must not do, and where its output goes.
2. Orchestration
Orchestration is the management layer that coordinates AI Employees, tasks, tools, workflows, validations, and handoffs.
Orchestration decides:
- which Brain owns the request
- which AI Employee should act
- what task should be created
- what context is required
- what sequence the work follows
- what validation is required
- where the result goes
- whether human review is needed
- whether the output becomes a task, report, dashboard item, Brain page, or archive item
Orchestration is one of the most important layers in MWMS.
Without orchestration, AI outputs become scattered, inconsistent, and difficult to trust.
With orchestration, AI work becomes repeatable, trackable, governable, and improvable.
The Orchestration rule is:
AI capability does not become business value until it is routed, sequenced, validated, and connected to an outcome.
3. Task
A task is the smallest controlled unit of AI work inside MWMS.
Every important AI action should become a structured task.
A MWMS AI task should include:
- task title
- task type
- source
- originating Brain
- assigned Brain
- assigned AI Employee
- input payload
- required output
- priority
- status
- validation requirement
- handoff destination
- event log
- final outcome
A task must be specific enough that an AI Employee can complete it without guessing the business purpose.
The Task rule is:
A vague request must be converted into a structured task before it becomes operational work.
This rule is especially important for Brain Room, Dev Console, Newsletter Intelligence, Course Absorption, Offer Evaluation, and future AIBS client workflows.
4. Outcome
An outcome is the business result produced by AI work.
MWMS does not value AI outputs simply because they exist.
MWMS values AI outputs when they support:
- a decision
- a rejected opportunity
- a parked opportunity
- a test candidate
- a campaign action
- a report
- a dashboard update
- a compliance warning
- a research finding
- a validated task
- a routed action
- a saved learning
- a system improvement
The Outcome rule is:
AI output is not complete until its business outcome is known.
This protects MWMS from producing endless summaries, notes, and ideas without practical execution value.
MWMS Agentic Work Unit Standard
Every AI task inside MWMS should be treated as an Agentic Work Unit.
An Agentic Work Unit is a controlled unit of AI work that contains:
- Request
- Classification
- Assigned Brain
- Assigned AI Employee
- Input
- Task instruction
- Tool permission
- Output format
- Validation rule
- Handoff destination
- Business outcome
- Event or learning log
This standard ensures AI work is not lost, duplicated, misrouted, or accepted without review.
Default MWMS AI Workflow Pattern
The default MWMS AI workflow pattern is:
- Input Capture
- Input Cleaning
- Classification
- Task Creation
- AI Employee Assignment
- Processing
- Validation
- Decision
- Routing
- Logging
- Reporting
- Learning Update
This pattern should be reused across MWMS wherever AI performs important work.
It may be simplified for small tasks, but it must not be ignored for high-impact workflows.
Single Prompt Restriction
Single prompts may be used for low-risk support tasks.
Single prompts must not be used as the final operating model for complex MWMS workflows.
Complex workflows include:
- offer evaluation
- affiliate campaign decisions
- newsletter intelligence routing
- financial forecasting
- compliance review
- research synthesis
- Brain-to-Brain handoffs
- client-facing reports
- automation execution
- task creation
- public content creation
- business decision recommendations
For these workflows, MWMS must use structured pipelines, not one-shot prompts.
Pipeline Requirement
A MWMS AI pipeline must define:
- what enters the workflow
- how the input is cleaned
- how the request is classified
- which AI Employee performs the work
- what format the output must follow
- how the output is validated
- where the result goes
- what business decision or action it supports
- what is logged for future review
A pipeline is valid only if it produces a usable business output.
AI Employee Role Card Requirement
Every formal MWMS AI Employee should eventually have a role card.
The role card should include:
- Employee Name
- Brain
- Purpose
- Primary Responsibilities
- Input Types
- Output Types
- Approved Tools
- Forbidden Actions
- Validation Rules
- Escalation Rules
- Handoff Destinations
- Success Metrics
- Related Workflows
- Related Standards
- Change Log
This role card becomes the source of truth for how that AI Employee operates.
No AI Employee should be expanded beyond its role card without updating the relevant governance page.
Tool Permission Rule
AI Employees may only use tools, files, APIs, databases, or external systems that are approved for their role.
Tool access must be governed.
Examples of tool access include:
- Gmail
- Supabase
- WordPress
- Make.com
- n8n
- Google Sheets
- Google Drive
- OpenAI
- Claude
- Gemini
- browser/search tools
- reporting dashboards
- internal MWMS databases
- client system integrations
The Tool Permission rule is:
Tool access must match role, task, risk level, and approval boundary.
AI Employees must not perform external actions, send messages, change live systems, create public content, alter databases, or trigger business workflows unless the permission boundary allows it.
Validation Requirement
No important AI output becomes operational truth until it passes validation.
Validation may be automated, human-reviewed, or both.
Validation checks should include:
- completeness
- specificity
- source grounding
- correct Brain routing
- correct output format
- action usefulness
- risk level
- compliance risk
- hallucinated structure
- duplicate logic
- handoff clarity
- logging readiness
The Validation rule is:
AI output must be checked before it is trusted.
This rule applies especially to:
- HeadOffice dashboard items
- routed actions
- offer verdicts
- finance analysis
- compliance warnings
- client reports
- task executor outputs
- Brain Room responses
- course absorption outputs
- MCR page updates
Quality Assurance And Quality Control
MWMS must separate Quality Assurance from Quality Control.
Quality Assurance prevents bad output before it happens.
Quality Assurance includes:
- clear prompts
- structured schemas
- role definitions
- page standards
- naming standards
- document standards
- workflow rules
- tool permission rules
- task boundaries
- SOPs
Quality Control catches bad output after it is produced.
Quality Control includes:
- review screens
- confidence scores
- validation checks
- rejection reasons
- human approval
- status tabs
- event logs
- action history
- source comparison
- rerun rules
Both are required.
Quality Assurance without Quality Control creates blind trust.
Quality Control without Quality Assurance creates constant cleanup.
MWMS needs both.
Handoff Requirement
AI work must not end in a dead output.
Every important AI output must have a handoff destination.
Possible handoff destinations include:
- HeadOffice Dashboard
- Brain Room
- Newsletter Queue Review
- Routed Actions
- Affiliate Brain
- Research Brain
- Experimentation Brain
- Finance Brain
- Content Brain
- Ads Brain
- MCR page
- Brain site page
- Supabase task record
- Supabase event log
- Google Sheet
- human review queue
- archive
- parking system
The Handoff rule is:
Every AI output must know where it goes next.
If no destination exists, the output should be parked, rejected, or converted into a defined task.
Reporting Requirement
AI work should produce reporting value where appropriate.
A MWMS AI report should include:
- source
- context
- key findings
- business meaning
- impacted Brain
- recommended action
- risk notes
- urgency
- priority
- owner
- next step
- validation result
- final status
A report must be decision-ready.
A summary is not enough.
The Reporting rule is:
MWMS reports must explain what happened, why it matters, what should happen next, and who or what system should act.
Learning Requirement
MWMS must learn from completed AI work.
Learning may include:
- repeated patterns
- failed outputs
- routing mistakes
- useful frameworks
- rejected ideas
- validated opportunities
- compliance warnings
- market shifts
- workflow improvements
- prompt improvements
- Brain updates
- Employee improvements
Learning should be routed into the correct place.
Possible destinations include:
- MWMS Blueprint
- Brain-specific Canon pages
- Kaizen logs
- System Change Log
- Course Absorption Decision Registry
- Newsletter Intelligence Signal Log
- Experimentation Brain learning records
- Research Brain signal records
The Learning rule is:
AI work should improve the system over time, not reset to zero each session.
Application To Brain Room
Brain Room should not be treated as a simple chat area.
Brain Room should become a structured intake and collaboration environment.
A future Brain Room workflow should follow this pattern:
- Message received
- Request classified
- Brain owner identified
- Task created
- AI Employee assigned
- Work processed
- Output validated
- Response returned
- Important result logged
- Required action routed
Brain Room becomes more powerful when messages are converted into structured work units.
Application To Newsletter Intelligence
Newsletter Intelligence should not rely on one AI extraction prompt forever.
The future agentic model may include:
- Newsletter Intake Agent
- Content Cleaning Agent
- Signal Extraction Agent
- Brain Routing Agent
- Action Classification Agent
- Validation Agent
- Queue Agent
- Dashboard Reporting Agent
- Learning Agent
This allows newsletter intelligence to become more accurate, more useful, and more operational over time.
Application To Course Absorption
Course absorption should follow the MWMS Agentic Work Unit Standard.
A course absorption workflow may include:
- Course Intake Agent
- Value Filter Agent
- Framework Extraction Agent
- MWMS Mapping Agent
- Duplication Check Agent
- Upgrade Decision Agent
- Page Builder Agent
- Registry Agent
- Kaizen Agent
This protects MWMS from absorbing weak material while allowing strong course content to upgrade the Blueprint.
Application To Offer Evaluation
Offer evaluation should become a multi-agent workflow.
A mature MWMS offer evaluation process may include:
- Offer Intake Agent
- Vendor Intelligence Agent
- Market Demand Agent
- Competitor Scan Agent
- Compliance Risk Agent
- Funnel Analysis Agent
- Traffic Fit Agent
- Finance Break-Even Agent
- Experimentation Fit Agent
- HeadOffice Verdict Agent
This creates stronger decisions than asking one AI whether an offer is good.
Application To AIBS Client Systems
This standard is also foundational for future AI Business Systems delivery.
MWMS client-facing systems should not be sold as generic automations.
They should be positioned as governed AI workflow systems that can help businesses with:
- reporting
- document cleanup
- internal knowledge workflows
- customer inquiry processing
- sales support
- operational decision-making
- finance summaries
- compliance review
- task routing
- management visibility
The client-facing promise should be:
MWMS installs governed AI workflows into a business, not random AI tools.
This creates a stronger, more defensible offer.
Governance Role
HeadOffice owns the MWMS AI Agent Operations Core.
HeadOffice is responsible for:
- defining AI operating standards
- approving AI Employee structures
- governing cross-Brain workflows
- managing validation expectations
- setting tool permission boundaries
- ensuring outputs connect to business outcomes
- preventing AI drift
- reviewing system-level learning
- maintaining the MCR source of truth
Individual Brains may define their own AI Employees and workflows, but those must align with this standard.
No Brain may create autonomous AI operations that bypass HeadOffice governance.
Developer Boundary
This document is a governance and operating standard.
It does not authorize immediate changes to M’s active development areas.
Any implementation into live systems must follow the current MWMS build order and must not interfere with:
- M’s active build tasks
- Brain Room systems
- executor hooks
- Affiliate workflow systems
- Opportunity system
- HeadOffice reporting build
- active Supabase integrations
- live plugin work
When this standard becomes relevant to development, it should be translated into a controlled developer brief.
Relationship To Other MWMS Standards
This document supports and must align with:
- MWMS Canon Session Protocol
- MWMS AI Session Context Lock Rule
- MWMS AI Output Standard Full File Delivery Rule
- MWMS Brain Routing Rule
- MWMS Brain To Brain Request Protocol
- MWMS Brain Header Schema Standard
- MWMS Page Naming Standard
- MWMS Document Structure Standard
- MWMS Architecture Registry
- MWMS Brain Interaction Map
- MWMS System Data Flow Map
- MWMS Supabase Event Schema
- HeadOffice Newsletter Intelligence Operating Protocol
- HeadOffice Newsletter Intelligence Output Validation Protocol
- MWMS Course Absorption Operating Rule
- MWMS Course Absorption Handoff Standard
- MWMS Opportunity System Operating Protocol
- Experimentation Brain Canon
- AI Business Systems Brain Blueprint
This standard strengthens those documents by defining how AI work should operate inside them.
Drift Protection
This standard protects MWMS from the following forms of drift:
- Treating AI as casual chat instead of structured work
- Creating AI Employees without role boundaries
- Running complex business workflows through one-shot prompts
- Accepting AI outputs without validation
- Producing summaries with no destination
- Routing tasks without ownership
- Allowing tools without permission boundaries
- Creating reports without business actions
- Letting Brains operate outside HeadOffice governance
- Building automations that cannot be audited
- Absorbing course material without mapping it to MWMS value
- Mistaking AI activity for business progress
Any future AI workflow that violates this standard should be reviewed before becoming part of MWMS operations.
Architectural Intent
The architectural intent of the MWMS AI Agent Operations Core is to make MWMS a true AI business operating ecosystem.
The long-term goal is not to use AI more often.
The goal is to make AI work:
- structured
- repeatable
- governed
- validated
- measurable
- routed
- reportable
- improvable
- business-aligned
MWMS must be able to answer the following questions for every serious AI workflow:
- What triggered this work?
- Which Brain owns it?
- Which AI Employee performed it?
- What input was used?
- What output was produced?
- Was it validated?
- Where did it go?
- What decision did it support?
- What was logged?
- What did MWMS learn?
If MWMS can answer those questions, then the system is not just using AI.
It is operating an AI workforce.
Change Log
v1.0 — Initial Draft
Created the MWMS AI Agent Operations Core as the foundational operating standard for role-based AI Employees, agentic work units, orchestration, task workflows, validation, handoffs, reporting, and business outcomes.
This draft was created after absorbing the foundational lessons from the Mastering Claude Cowork & AI Agent Automation course, especially the concepts of agents, orchestration, tasks, outcomes, multi-step pipelines, quality control, consistency, validation, and agent-driven reporting.