System: MWMS
Document Type: Operating Standard
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
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 Agentic Work Unit Standard.
The MWMS Agentic Work Unit Standard establishes how any meaningful AI request, instruction, workflow, or automation inside MWMS is converted into a structured unit of work.
This standard exists because MWMS must not operate through vague AI conversations, random prompts, scattered outputs, or disconnected automation steps.
MWMS is being designed as a governed AI business ecosystem.
Inside that ecosystem, every important AI action must be treated as work.
That work must have structure.
That structure must make the task clear, assignable, trackable, validatable, routable, reportable, and improvable.
An Agentic Work Unit is the controlled container that makes this possible.
Scope
This standard applies to all MWMS workflows where AI performs, supports, reviews, routes, or reports on work.
This includes:
- Brain Room requests
- HeadOffice requests
- AI Manager tasks
- AI Employee tasks
- Dev Console requests
- Newsletter Intelligence workflows
- Course Absorption workflows
- Offer Evaluation workflows
- Affiliate Brain workflows
- Research Brain workflows
- Experimentation Brain workflows
- Finance Brain workflows
- Content Brain workflows
- Ads Brain workflows
- Opportunity System workflows
- Brain-to-Brain requests
- Supabase task records
- Supabase event logs
- future client-facing AIBS workflows
This standard applies to both manual and automated workflows.
Manual workflows include user-prompted analysis, MCR page creation, course absorption, strategy work, research requests, and decision support.
Automated workflows include newsletter processing, queue routing, task execution, AI Employee processing, dashboard updates, and future Brain Room automation.
Core Definition
An Agentic Work Unit is a structured unit of AI work.
It converts a vague request into a controlled operational task.
An Agentic Work Unit defines:
- what triggered the work
- what the work is about
- which Brain owns the work
- which AI Employee should perform the work
- what input is being used
- what output is required
- what tools may be used
- what validation is required
- where the output should go
- what business outcome is expected
- what must be logged
An Agentic Work Unit is not just a prompt.
It is not just a task title.
It is not just an AI response.
It is the complete operating container for AI work inside MWMS.
Core Principle
The core principle of this standard is:
Every important AI request inside MWMS must be converted into a governed work unit before it becomes operational work.
This protects MWMS from:
- vague AI execution
- inconsistent outputs
- poor Brain routing
- missing validation
- lost context
- duplicated work
- unmanaged AI actions
- untracked decisions
- outputs with no destination
- automation drift
The stronger MWMS becomes, the more important this principle becomes.
Why Agentic Work Units Matter
AI can produce outputs quickly.
That is not enough.
MWMS needs AI to produce useful business work.
Useful business work requires:
- clear intent
- defined ownership
- repeatable process
- structured output
- quality control
- destination
- decision value
- learning value
Without Agentic Work Units, MWMS risks becoming a pile of impressive but disconnected AI outputs.
With Agentic Work Units, MWMS can operate like a managed AI workforce.
Agentic Work Unit Structure
Every Agentic Work Unit should include the following fields.
1. Work Unit Title
The Work Unit Title names the task clearly.
It should describe the work being performed, not just the topic.
Weak title:
Newsletter analysis
Strong title:
Extract Business Relevant Signals From Newsletter And Route To Correct Brain
Weak title:
Check offer
Strong title:
Evaluate Affiliate Offer For Test Suitability And HeadOffice Decision
The title must make the purpose of the task clear.
2. Work Unit Type
The Work Unit Type defines the class of work being performed.
Examples include:
- Intake
- Extraction
- Cleaning
- Classification
- Research
- Analysis
- Validation
- Routing
- Reporting
- Forecasting
- Decision Support
- Page Creation
- Registry Update
- Course Absorption
- Offer Evaluation
- Compliance Review
- Brain-to-Brain Handoff
- Developer Support
- Dashboard Update
- Learning Log
The Work Unit Type helps MWMS route tasks to the correct Brain, Employee, workflow, and validation standard.
3. Source
The Source identifies where the work came from.
Possible sources include:
- Brain Room message
- HeadOffice request
- user instruction
- uploaded course file
- newsletter
- Gmail message
- Supabase row
- WordPress page
- Make.com scenario
- Google Sheet
- MCR page
- affiliate offer page
- research source
- dashboard item
- routed action
- developer note
- system event
The source must be clear enough that the work can be traced later.
4. Originating Brain
The Originating Brain is the Brain or system area where the request began.
Examples:
- HeadOffice Brain
- Affiliate Brain
- Research Brain
- Experimentation Brain
- Finance Brain
- Content Brain
- Ads Brain
- Brain Room
- Dev Console
- Newsletter Intelligence
- Course Absorption System
- Opportunity System
The Originating Brain does not always own the final work.
It only identifies where the request began.
5. Owning Brain
The Owning Brain is the Brain responsible for the work.
The Owning Brain must be clearly defined.
Examples:
- Affiliate Brain owns offer intake and affiliate opportunity evaluation.
- Research Brain owns market research and evidence gathering.
- Experimentation Brain owns test design and learning capture.
- Finance Brain owns budgets, break-even analysis, and capital control.
- HeadOffice Brain owns cross-Brain governance, final visibility, and strategic control.
- Content Brain owns content production, refresh, repurposing, and content operations.
- Ads Brain owns advertising strategy, campaign setup logic, and traffic intelligence.
The Owning Brain is responsible for ensuring the work has the correct process, output, and destination.
6. Assigned AI Employee
The Assigned AI Employee is the AI role responsible for completing the task.
Examples:
- Orchestrator Agent
- Task Builder Agent
- Intake Agent
- Signal Extraction Agent
- Research Agent
- Validation Agent
- Reporting Agent
- Handoff Agent
- Finance Analysis Agent
- Compliance Review Agent
- Course Absorption Agent
- Offer Evaluation Agent
- Dashboard Reporting Agent
No Agentic Work Unit should be assigned to a vague “AI” identity.
The work should be assigned to a role.
If no suitable AI Employee exists, the work should be assigned to a temporary role and flagged as a possible future Employee definition.
7. Input Payload
The Input Payload is the material the AI Employee uses to perform the task.
Examples:
- newsletter body
- uploaded transcript
- sales page text
- course lesson notes
- Supabase record
- Brain Room message
- WordPress page content
- screenshot description
- CSV data
- Google Sheet row
- research notes
- campaign data
- previous report
- user instruction
The Input Payload must be specific.
A task should not rely on hidden assumptions when the required input can be defined.
8. Context Pack
The Context Pack provides the extra information required to complete the work correctly.
A Context Pack may include:
- relevant Brain rules
- related MCR pages
- previous decisions
- project boundaries
- current system status
- page naming rules
- document structure rules
- developer boundary
- active save point
- related workflow state
- known risks
- user preferences
- compliance constraints
The Context Pack prevents the AI Employee from acting in isolation.
For MWMS, context is not optional.
Context is what keeps AI work aligned with the system.
9. Task Instruction
The Task Instruction states exactly what needs to be done.
It should include:
- the specific action required
- the expected depth
- the format needed
- any constraints
- anything that must be avoided
- the intended use of the result
Weak instruction:
Look at this and tell me what you think.
Strong instruction:
Evaluate this course lesson for reusable MWMS system value. Extract only concepts that improve AI Employee design, Brain workflows, validation, orchestration, reporting, or AIBS delivery. Ignore tool-specific fluff unless it affects MWMS architecture.
The Task Instruction must reduce ambiguity.
10. Tool Permission
Tool Permission defines what tools, systems, files, or integrations the AI Employee is allowed to use for this work.
Possible tool permissions include:
- no external tools
- uploaded files only
- MCR content only
- web research allowed
- Gmail allowed
- Supabase read allowed
- Supabase write allowed
- WordPress read allowed
- WordPress write allowed
- Make.com reference only
- Google Sheets allowed
- file generation allowed
- draft only
- human approval required before action
Tool permission must match the risk level of the task.
AI Employees must not assume they can use tools just because they are available.
11. Forbidden Actions
Forbidden Actions define what the AI Employee must not do.
Examples:
- do not create live tasks without approval
- do not change WordPress content
- do not alter Supabase records
- do not send emails
- do not update dashboards
- do not invent missing pages
- do not reference pages that have not been confirmed
- do not bypass HeadOffice governance
- do not interfere with M’s active build areas
- do not absorb weak course material
- do not create duplicate frameworks
- do not convert speculative ideas into canon
Forbidden Actions are essential for drift protection.
12. Required Output Format
The Required Output Format defines how the result must be delivered.
Examples:
- full page output
- structured summary
- verdict report
- JSON row
- dashboard card
- action list
- task record
- registry entry
- M developer brief
- Brain-to-Brain handoff
- validation checklist
- course absorption report
- offer evaluation report
- HeadOffice decision report
The Required Output Format must be known before the AI Employee completes the task.
If the output format is unclear, the work is likely to become inconsistent.
13. Validation Standard
The Validation Standard defines how the output will be checked.
Validation may include:
- completeness check
- accuracy check
- source grounding check
- usefulness check
- Brain routing check
- format check
- risk check
- compliance check
- duplication check
- naming check
- parent page check
- developer boundary check
- outcome check
The Validation Standard must match the importance of the work.
High-impact work requires stronger validation.
14. Handoff Destination
The Handoff Destination defines where the result goes next.
Possible destinations include:
- HeadOffice Dashboard
- Brain Room
- Newsletter Queue Review
- Routed Actions
- MCR page
- Brain site page
- Supabase task table
- Supabase event log
- Google Sheet
- Affiliate Brain
- Research Brain
- Experimentation Brain
- Finance Brain
- Content Brain
- Ads Brain
- human review queue
- Parking System
- archive
No Agentic Work Unit should end with an output floating in space.
The destination must be clear.
15. Business Outcome
The Business Outcome defines the practical result the work supports.
Examples:
- decision made
- task created
- opportunity rejected
- opportunity parked
- offer moved to research
- campaign approved for testing
- report created
- risk flagged
- dashboard updated
- page created
- registry updated
- course insight absorbed
- weak material ignored
- developer brief prepared
- client workflow improved
- learning logged
The Business Outcome proves whether the AI work mattered.
16. Status
The Status identifies the current state of the work unit.
Recommended statuses include:
- New
- Classified
- Assigned
- In Progress
- Waiting For Input
- Waiting For Human Review
- Validated
- Failed Validation
- Routed
- Parked
- Rejected
- Completed
- Logged
- Archived
Status is essential for system visibility.
Without status, MWMS cannot manage AI work at scale.
17. Priority
Priority defines how urgently the work should be handled.
Recommended priority levels include:
- Critical
- High
- Medium
- Low
- Parking Lot
Priority should be based on business value, urgency, risk, and system dependency.
High priority does not mean “interesting.”
High priority means the work affects current business progress, system stability, revenue potential, compliance, M’s build progress, or HeadOffice decision-making.
18. Risk Level
Risk Level defines the potential damage if the output is wrong.
Recommended risk levels include:
- Low
- Medium
- High
- Critical
Examples:
Low risk:
- rough brainstorm
- internal note
- non-canonical idea
Medium risk:
- internal report
- page draft
- research summary
High risk:
- offer decision
- financial recommendation
- compliance analysis
- developer instruction
- public content
Critical risk:
- live system change
- financial transaction
- legal/compliance-sensitive action
- automated external communication
- irreversible data change
The higher the risk, the stronger the validation and approval requirement.
19. Human Review Requirement
Some Agentic Work Units require human review before completion.
Human review is required when the work involves:
- live system changes
- public-facing content
- financial decisions
- compliance-sensitive outputs
- developer implementation instructions
- external email sending
- paid traffic decisions
- database writes
- canonical MCR updates
- major Brain architecture changes
- client-facing reports
Human review protects MWMS from automation drift and over-trusting AI outputs.
20. Event Log Requirement
Every important Agentic Work Unit should create or support an event log.
The event log should record:
- work unit created
- classification completed
- Brain assigned
- AI Employee assigned
- task started
- output generated
- validation completed
- handoff completed
- status changed
- human review completed
- final outcome recorded
Event logs are how MWMS becomes auditable.
They also allow the system to learn over time.
21. Learning Record
A completed Agentic Work Unit may produce a Learning Record.
A Learning Record captures what MWMS learned from the work.
Examples:
- recurring pattern discovered
- routing rule improved
- prompt improved
- validation issue found
- bad source rejected
- course module absorbed
- employee role clarified
- dashboard improvement identified
- workflow weakness exposed
- compliance risk detected
- business opportunity discovered
Learning Records should feed into the correct Brain, Blueprint section, Kaizen log, or registry.
Default Agentic Work Unit Template
The default template is:
Work Unit Title:
Work Unit Type:
Source:
Originating Brain:
Owning Brain:
Assigned AI Employee:
Input Payload:
Context Pack:
Task Instruction:
Tool Permission:
Forbidden Actions:
Required Output Format:
Validation Standard:
Handoff Destination:
Business Outcome:
Status:
Priority:
Risk Level:
Human Review Required:
Event Log Required:
Learning Record Required:
This template may be simplified for low-risk manual tasks.
It must not be ignored for high-impact workflows.
Example: Newsletter Intelligence Work Unit
Work Unit Title:
Extract Business Relevant Signals From Newsletter And Route To Correct Brain
Work Unit Type:
Extraction, Classification, Routing
Source:
Gmail newsletter
Originating Brain:
HeadOffice Newsletter Intelligence
Owning Brain:
HeadOffice Brain
Assigned AI Employee:
Newsletter Signal Extraction Agent
Input Payload:
Newsletter subject, sender, date, body, snippet, available metadata
Context Pack:
Newsletter Intelligence Operating Protocol, Brain Routing Rule, Output Validation Protocol
Task Instruction:
Extract business-relevant insights only. Ignore generic news. Identify useful patterns, tools, compliance risks, market signals, monetization opportunities, and Brain routing implications.
Tool Permission:
Gmail input, OpenAI processing, Supabase insert
Forbidden Actions:
Do not create downstream Brain tasks without review. Do not mark generic content as urgent. Do not invent unavailable source details.
Required Output Format:
Structured Supabase row and queue item
Validation Standard:
Specificity, usefulness, correct Brain routing, action type accuracy, confidence score
Handoff Destination:
Newsletter Queue Review and HeadOffice Dashboard
Business Outcome:
Useful intelligence routed for review, action, monitoring, testing, or parking
Status:
New → Processed → Reviewed → Routed/Parked/Rejected
Priority:
Based on urgency and business impact
Risk Level:
Medium
Human Review Required:
Yes, before downstream action
Event Log Required:
Yes
Learning Record Required:
If recurring pattern or major signal is identified
Example: Course Absorption Work Unit
Work Unit Title:
Evaluate Course Lesson For MWMS System Value
Work Unit Type:
Course Absorption, Framework Extraction, Blueprint Mapping
Source:
Uploaded course transcript or PDF
Originating Brain:
Course Absorption System
Owning Brain:
HeadOffice Brain
Assigned AI Employee:
Course Absorption Agent
Input Payload:
Course lesson transcript, description, outline, screenshots, or notes
Context Pack:
MWMS Course Absorption Operating Rule, Course Absorption System v2, current MWMS Blueprint, anti-duplication rules
Task Instruction:
Extract only material that improves MWMS Brain, Blueprint, AI Employees, workflows, governance, client systems, or future expansion. Ignore shallow, duplicated, or tool-specific content unless it creates a clear system upgrade.
Tool Permission:
Uploaded files only unless research is explicitly required
Forbidden Actions:
Do not absorb weak material. Do not create duplicate pages. Do not invent course content. Do not interfere with M’s active development areas.
Required Output Format:
Course absorption report or full MCR page output
Validation Standard:
Value test, duplication check, Brain mapping, practical usefulness, system fit
Handoff Destination:
MCR page, Blueprint background, Course Absorption Decision Registry, or Parking System
Business Outcome:
MWMS system improved or weak content rejected
Status:
New → Reviewed → Absorbed/Parked/Ignored
Priority:
Medium to High depending on system value
Risk Level:
Medium
Human Review Required:
Yes before permanent MCR page creation
Event Log Required:
Recommended
Learning Record Required:
Yes if absorbed
Example: Brain Room Work Unit
Work Unit Title:
Convert Brain Room Message Into Structured AI Task
Work Unit Type:
Intake, Classification, Task Creation
Source:
Brain Room message
Originating Brain:
Brain Room
Owning Brain:
Determined by classification
Assigned AI Employee:
Task Builder Agent
Input Payload:
Brain Room message, sender, timestamp, thread context
Context Pack:
Brain Routing Rule, Brain-to-Brain Request Protocol, current active build boundaries
Task Instruction:
Classify the request, identify the owning Brain, create a structured task, assign the appropriate AI Employee, and determine whether human review is required.
Tool Permission:
Brain Room read, task creation only if approved by current workflow
Forbidden Actions:
Do not execute live system changes directly. Do not bypass HeadOffice governance. Do not assign work to M’s active build areas unless explicitly intended.
Required Output Format:
Structured task record
Validation Standard:
Correct Brain classification, clear task instruction, valid handoff, safe boundary
Handoff Destination:
AI Manager, Task Executor, or human review queue
Business Outcome:
Brain Room message becomes trackable work
Status:
New → Classified → Assigned → In Progress
Priority:
Based on request type
Risk Level:
Variable
Human Review Required:
Depends on risk
Event Log Required:
Yes
Learning Record Required:
If task reveals a new system pattern or recurring request type
Example: Offer Evaluation Work Unit
Work Unit Title:
Evaluate Affiliate Offer For Test Suitability
Work Unit Type:
Offer Evaluation, Research, Decision Support
Source:
Affiliate offer, network listing, sales page, or newsletter signal
Originating Brain:
Affiliate Brain
Owning Brain:
Affiliate Brain
Assigned AI Employee:
Offer Evaluation Agent
Input Payload:
Offer name, network, payout, funnel details, sales page, available metrics, traffic platform, user goal
Context Pack:
Affiliate Product Intelligence Protocol, Opportunity System Operating Protocol, Experimentation Brain rules, Finance Brain budget rules, Ads Brain compliance rules
Task Instruction:
Evaluate whether the offer is worth testing. Include market fit, vendor quality, funnel strength, traffic fit, compliance risk, break-even logic, and recommended next action.
Tool Permission:
Web research allowed when current data is required
Forbidden Actions:
Do not approve testing without risk and budget review. Do not rely on hype claims. Do not ignore compliance issues. Do not invent performance metrics.
Required Output Format:
Green/Yellow/Red verdict report
Validation Standard:
Evidence quality, current data, financial logic, compliance risk, traffic fit, testability
Handoff Destination:
Research Brain, Experimentation Brain, Finance Brain, or HeadOffice decision queue
Business Outcome:
Offer rejected, parked, researched further, or moved toward test planning
Status:
New → Researching → Evaluated → Routed
Priority:
Based on revenue potential and urgency
Risk Level:
High
Human Review Required:
Yes
Event Log Required:
Yes
Learning Record Required:
Yes if tested or rejected for strategic reason
Governance Role
HeadOffice owns this standard.
HeadOffice is responsible for ensuring that Agentic Work Units are used for important AI work across MWMS.
Individual Brains may adapt the structure for their own workflows, but they must not remove the core requirements of:
- ownership
- task clarity
- output format
- validation
- handoff
- outcome
- logging
No Brain should create AI workflows that bypass this standard when the work affects business decisions, system structure, client outputs, public content, or live operations.
Relationship To Other MWMS Standards
This document supports and must align with:
- MWMS AI Agent Operations Core
- 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 Opportunity System Operating Protocol
- AI Business Systems Brain Blueprint
This standard operationalizes those governance rules by defining how AI work becomes structured, traceable, and outcome-based.
Drift Protection
This standard protects MWMS from the following forms of drift:
- Treating AI prompts as completed work
- Allowing vague requests into operational workflows
- Assigning AI work without Brain ownership
- Creating outputs with no validation
- Creating outputs with no destination
- Losing context between Brain handoffs
- Accepting AI results without business outcomes
- Allowing tools without permission boundaries
- Letting AI Employees perform undefined work
- Creating dashboards full of unvalidated intelligence
- Turning Brain Room into unmanaged chat
- Treating automation activity as business progress
- Allowing course material to enter MWMS without value testing
- Creating system changes without event logs
- Failing to learn from completed AI work
Any workflow that violates this standard should be paused, reviewed, simplified, or redesigned.
Architectural Intent
The architectural intent of the MWMS Agentic Work Unit Standard is to make AI work manageable at scale.
MWMS will eventually contain many Brains, AI Employees, workflows, dashboards, task systems, client systems, and automation layers.
Without a standard work unit, the system will become difficult to control.
With a standard work unit, MWMS can scale AI work while keeping:
- ownership clear
- tasks structured
- outputs consistent
- validation enforceable
- handoffs visible
- reports useful
- actions traceable
- learning reusable
The long-term goal is that every meaningful AI action inside MWMS can answer these questions:
- What triggered this work?
- What type of work is it?
- Which Brain owns it?
- Which AI Employee performed it?
- What input was used?
- What context was applied?
- What output was required?
- What validation was performed?
- Where did the result go?
- What business outcome did it support?
- What was logged?
- What did MWMS learn?
When MWMS can answer those questions consistently, it is no longer simply using AI.
It is operating a governed AI workforce.
Change Log
v1.0 — Initial Draft
Created the MWMS Agentic Work Unit Standard as the operating structure for converting AI requests into controlled, assignable, validatable, routable, reportable, and outcome-based work units.
This standard supports the MWMS AI Agent Operations Core and provides the foundation for future AI Employee workflows, Brain Room task conversion, AI Manager routing, Supabase task/event structures, HeadOffice reporting, Newsletter Intelligence, Course Absorption, Offer Evaluation, and AIBS client systems.