MWMS MCR

MWMS Agentic Work Unit Template

System: MWMS
Document Type: Operational Template
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, AI Manager, AI Employee Router, Task Executor Systems, Newsletter Intelligence, Course Absorption System, Opportunity System, AI Business Systems Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR

Purpose

The purpose of this document is to define the MWMS Agentic Work Unit Template.

This template converts a request, message, file, newsletter, course lesson, offer, report, developer issue, or system event into a structured unit of AI work.

MWMS must not allow important AI work to begin as vague chat.

Before AI work becomes operational, the system must know:

  • what the work is
  • where it came from
  • which Brain owns it
  • which AI Employee should perform it
  • what input is being used
  • what context is required
  • what output is expected
  • what validation is needed
  • where the output goes
  • what business outcome is expected
  • what must be logged or learned

This template is the practical daily-use version of the MWMS Agentic Work Unit Standard.

Scope

This template applies whenever MWMS needs to convert information into structured AI work.

This includes:

  • Brain Room messages
  • HeadOffice requests
  • course absorption tasks
  • newsletter intelligence items
  • offer evaluation tasks
  • research requests
  • developer support tasks
  • MCR page creation tasks
  • validation tasks
  • finance review tasks
  • experimentation review tasks
  • content workflow tasks
  • dashboard actions
  • routed actions
  • future AIBS client workflow tasks

This template may be used manually at first.

Later, parts of this template may become fields inside Brain Room, AI Manager, Supabase task records, HeadOffice dashboards, AI Employee Router, or future AIBS client systems.

Core Definition

An Agentic Work Unit is a controlled unit of AI work.

It defines the task before the AI Employee performs it.

It prevents MWMS from relying on unclear prompts, scattered outputs, missing context, wrong routing, weak validation, or outputs with no destination.

The template below is designed to be copied and filled in whenever MWMS needs a structured work item.

Agentic Work Unit Template

1. Work Unit Title

Field:
Work Unit Title:

Purpose:
A clear title that describes the work being performed.

Use:
The title should describe the action, not just the topic.

Good Examples:

  • Extract Business Relevant Signals From Newsletter
  • Evaluate Affiliate Offer For Test Suitability
  • Convert Brain Room Message Into Structured Task
  • Review Course Lesson For MWMS System Value
  • Prepare Developer Handoff For M
  • Validate MCR Page Output Before Saving

Bad Examples:

  • Newsletter
  • Offer
  • Course Notes
  • Brain Room
  • Check This

Rule:
The title must make the work understandable at a glance.

2. Work Unit Type

Field:
Work Unit Type:

Purpose:
Defines the category of work.

Common Types:

  • Intake
  • Extraction
  • Cleaning
  • Classification
  • Course Absorption
  • Newsletter Intelligence
  • Offer Evaluation
  • Research
  • Validation
  • Reporting
  • Handoff
  • Developer Support
  • Finance Review
  • Experimentation Review
  • Content Workflow
  • Dashboard Review
  • Task Creation
  • MCR Page Creation
  • Registry Update
  • Failure Handling
  • Outcome Review

Rule:
The type should determine which workflow, Brain, and AI Employee are likely needed.

3. Source

Field:
Source:

Purpose:
Identifies where the work came from.

Examples:

  • Brain Room message
  • Uploaded course transcript
  • Course PDF
  • Newsletter email
  • Supabase row
  • WordPress page list
  • Affiliate offer page
  • Google Ads report
  • M developer note
  • Screenshot
  • User instruction
  • HeadOffice dashboard item
  • Routed action

Rule:
MWMS must be able to trace the work back to its origin.

4. Source Reference

Field:
Source Reference:

Purpose:
Records the exact reference if available.

Examples:

  • file name
  • page title
  • email subject
  • dashboard row
  • Supabase record ID
  • screenshot name
  • Brain Room thread
  • course lesson title
  • URL if approved
  • date received

Rule:
Use this field when the source may need to be checked later.

5. Originating Brain Or System

Field:
Originating Brain Or System:

Purpose:
Identifies where the request began.

Examples:

  • HeadOffice Brain
  • Brain Room
  • Course Absorption System
  • Newsletter Intelligence
  • Affiliate Brain
  • Research Brain
  • Experimentation Brain
  • Finance Brain
  • Content Brain
  • Ads Brain
  • Dev Console
  • Opportunity System
  • AI Business Systems Brain

Rule:
Origin does not always mean ownership. It only shows where the work started.

6. Owning Brain

Field:
Owning Brain:

Purpose:
Identifies the Brain responsible for the work.

Examples:

  • HeadOffice Brain owns governance and cross-system control.
  • Affiliate Brain owns offer evaluation.
  • Research Brain owns evidence gathering.
  • Finance Brain owns budget and break-even logic.
  • Experimentation Brain owns test design and test learning.
  • Content Brain owns content workflow.
  • Ads Brain owns ad strategy and traffic logic.
  • AI Business Systems Brain owns client-facing AI system packaging.

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

7. Supporting Brains

Field:
Supporting Brains:

Purpose:
Lists other Brains that may need to contribute.

Examples:

For offer evaluation:

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

For newsletter intelligence:

  • HeadOffice Brain
  • Ads Brain
  • Content Brain
  • Affiliate Brain
  • Research Brain

Rule:
If the task crosses multiple domains, supporting Brains must be identified early.

8. Assigned AI Employee

Field:
Assigned AI Employee:

Purpose:
Identifies which AI Employee should perform the work.

Examples:

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

Rule:
Assign work to a role, not to vague AI.

9. Authority Level

Field:
Authority Level:

Purpose:
Defines how much power the AI Employee has for this task.

Recommended Values:

  • Advisory
  • Operational Drafting
  • Controlled Execution
  • Supervised Automation
  • Restricted Autonomous

Default:
Most new work should begin as Advisory or Operational Drafting.

Rule:
Authority must match risk.

10. Input Payload

Field:
Input Payload:

Purpose:
Defines the actual material being processed.

Examples:

  • uploaded file content
  • pasted newsletter
  • offer page data
  • course transcript
  • screenshot details
  • Supabase row
  • Brain Room message
  • WordPress page list
  • Google Ads numbers
  • developer issue description

Rule:
The input must be clear enough that the AI Employee does not need to guess.

11. Context Pack

Field:
Context Pack:

Purpose:
Lists the background context required for the AI Employee to perform correctly.

Possible Context:

  • relevant MWMS standards
  • Brain rules
  • current save point
  • developer boundary
  • source of truth
  • output format
  • current workflow stage
  • user preference
  • known risks
  • previous decisions
  • page naming rules
  • document structure rules
  • tool permissions
  • validation rules

Rule:
High-risk work needs a stronger Context Pack.

12. Task Instruction

Field:
Task Instruction:

Purpose:
States exactly what the AI Employee must do.

Good Example:

Evaluate this course lesson for reusable MWMS system value. Extract only principles that improve AI Employees, workflow pipelines, validation, orchestration, reporting, handoffs, failure handling, outcome measurement, or future AIBS delivery. Ignore tool-specific fluff unless it creates a clear system upgrade.

Bad Example:

Look at this and tell me what you think.

Rule:
The task instruction must reduce ambiguity.

13. Required Output Format

Field:
Required Output Format:

Purpose:
Defines the expected output.

Examples:

  • full page output
  • course absorption report
  • newsletter intelligence record
  • validation report
  • Green Yellow Red offer verdict
  • developer handoff
  • Agentic Work Unit draft
  • MCR page update
  • dashboard card
  • routed action
  • outcome log
  • failure log
  • handoff package

Rule:
The AI Employee must know the output format before processing begins.

14. Tool Permission

Field:
Tool Permission:

Purpose:
Defines what tools or sources the AI Employee may use.

Recommended Values:

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

Examples:

  • uploaded files only
  • current conversation only
  • web research allowed
  • Gmail read only
  • Supabase read only
  • Supabase controlled write
  • WordPress read only
  • WordPress draft only
  • no external tools

Rule:
Grant the lowest permission level required to complete the work safely.

15. Forbidden Actions

Field:
Forbidden Actions:

Purpose:
Defines what the AI Employee must not do.

Examples:

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

Rule:
Forbidden actions protect MWMS from role drift and automation risk.

16. Validation Level

Field:
Validation Level:

Purpose:
Defines how strongly the output must be checked.

Recommended Values:

  • Level 1 — Light Validation
  • Level 2 — Structured Validation
  • Level 3 — Operational Validation
  • Level 4 — High Risk Validation
  • Level 5 — Critical Validation

Rule:
Higher risk requires stronger validation.

17. Validation Standard

Field:
Validation Standard:

Purpose:
Defines what checks are required.

Possible Checks:

  • completeness
  • source grounding
  • specificity
  • correct Brain routing
  • correct output format
  • duplication check
  • business outcome check
  • risk check
  • compliance check
  • developer boundary check
  • naming and structure check
  • handoff clarity
  • human review requirement

Rule:
Validation must match the task’s destination and risk.

18. Human Review Required

Field:
Human Review Required: Yes / No

Purpose:
Defines whether Martyn, M, HeadOffice, or another human must review before the result is accepted or acted upon.

Human Review Required For:

  • MCR canon updates
  • developer instructions
  • live system changes
  • Supabase writes
  • WordPress changes
  • paid traffic decisions
  • finance decisions
  • compliance-sensitive outputs
  • public content
  • client-facing outputs
  • high-risk automation

Rule:
When unsure, require human review.

19. Risk Level

Field:
Risk Level:

Recommended Values:

  • Low
  • Medium
  • High
  • Critical

Examples:

Low:

  • internal brainstorm
  • rough draft

Medium:

  • course absorption report
  • newsletter queue item

High:

  • developer brief
  • offer verdict
  • MCR page output
  • finance analysis

Critical:

  • live system change
  • database write
  • external email send
  • ad launch
  • client-facing final delivery

Rule:
Risk level controls validation, review, and permission.

20. Priority

Field:
Priority:

Recommended Values:

  • Critical
  • High
  • Medium
  • Low
  • Parking Lot

Rule:
Priority must be based on business importance, not excitement.

21. Handoff Destination

Field:
Handoff Destination:

Purpose:
Defines where the output goes next.

Examples:

  • HeadOffice review
  • Brain Room
  • MCR page
  • HeadOffice Dashboard
  • Newsletter Queue Review
  • Routed Actions
  • Research Brain
  • Finance Brain
  • Experimentation Brain
  • Content Brain
  • Ads Brain
  • M developer handoff
  • Supabase task record
  • Parking System
  • Archive
  • AIBS client review

Rule:
Every important output must have a destination.

22. Required Next Action

Field:
Required Next Action:

Purpose:
Defines what should happen after the output is produced.

Examples:

  • save to MCR after review
  • revise output
  • route to Research Brain
  • send to Finance Brain
  • create developer brief
  • add to dashboard
  • park for later
  • reject
  • create task
  • update registry
  • log learning
  • request more input

Rule:
The next action must be specific enough to act on.

23. Expected Business Outcome

Field:
Expected Business Outcome:

Purpose:
Defines why this work matters.

Outcome Examples:

  • decision made
  • risk reduced
  • weak material rejected
  • page created
  • task created
  • signal routed
  • offer parked
  • offer rejected
  • test candidate improved
  • developer instruction clarified
  • dashboard quality improved
  • learning captured
  • client workflow improved

Rule:
AI work should produce outcomes, not just output.

24. Status

Field:
Status:

Recommended Values:

  • New
  • Classified
  • Assigned
  • In Progress
  • Waiting For Input
  • Waiting For Human Review
  • Draft Complete
  • Validation Required
  • Validated
  • Failed Validation
  • Routed
  • Parked
  • Rejected
  • Completed
  • Logged
  • Archived

Rule:
Status makes AI work trackable.

25. Failure Or Escalation Trigger

Field:
Failure Or Escalation Trigger:

Purpose:
Defines what should stop the work or trigger escalation.

Examples:

  • input incomplete
  • source unclear
  • Brain ownership unclear
  • tool permission unclear
  • output confidence low
  • compliance risk found
  • finance risk found
  • developer risk found
  • live system impact detected
  • M’s active build may be affected
  • validation fails
  • task exceeds AI Employee authority

Rule:
A good Work Unit knows when to stop.

26. Logging Required

Field:
Logging Required: Yes / No

Purpose:
Defines whether the work should create an event, task log, outcome log, failure log, or learning record.

Logging Required For:

  • MCR updates
  • developer handoffs
  • high-risk tasks
  • offer evaluations
  • finance decisions
  • validation failures
  • workflow failures
  • AI Employee performance
  • client-facing workflows
  • important HeadOffice decisions

Rule:
Important AI work should leave a trace.

27. Learning Capture Required

Field:
Learning Capture Required: Yes / No

Purpose:
Defines whether this work may improve MWMS long term.

Learning Examples:

  • new framework found
  • repeated failure mode identified
  • role card improved
  • workflow improved
  • validation rule improved
  • offer rejection reason learned
  • newsletter pattern detected
  • course insight absorbed
  • developer instruction rule improved
  • AIBS client module idea discovered

Rule:
Useful learning should not be lost inside the task.

Quick Use Version

For fast manual use, use this shorter version.

Work Unit Title:
Work Unit Type:
Source:
Owning Brain:
Supporting Brains:
Assigned AI Employee:
Input Payload:
Context Pack:
Task Instruction:
Required Output Format:
Tool Permission:
Forbidden Actions:
Validation Level:
Human Review Required:
Risk Level:
Priority:
Handoff Destination:
Required Next Action:
Expected Business Outcome:
Status:
Logging Required:
Learning Capture Required:

Example 1: Course Absorption Work Unit

Work Unit Title:
Extract AI Agent Operations Value From Course Lesson

Work Unit Type:
Course Absorption

Source:
Uploaded course transcript and lesson description

Owning Brain:
HeadOffice Brain

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

Assigned AI Employee:
Course Absorption Agent

Input Payload:
Course lesson file, SRT transcript, description file, current thread context

Context Pack:
Course Absorption System v2, MWMS AI Agent Operations Core, anti-duplication rule, full page output rule, M development boundary

Task Instruction:
Extract only reusable MWMS system value. Identify principles, frameworks, workflows, AI Employee implications, validation rules, handoff rules, and future AIBS relevance. Ignore tool-specific fluff unless it improves MWMS architecture.

Required Output Format:
Course absorption report or full MCR page output if strong enough

Tool Permission:
Provided input only

Forbidden Actions:
Do not absorb weak material. Do not create duplicate standards. Do not claim unsupported content. Do not interfere with M’s active build.

Validation Level:
Level 3 — Operational Validation

Human Review Required:
Yes

Risk Level:
Medium

Priority:
High if the lesson improves MWMS structure

Handoff Destination:
MCR page draft, Blueprint background, or Parking System

Required Next Action:
Absorb, park, ignore, or create full page output

Expected Business Outcome:
MWMS Blueprint improves or weak content is rejected

Status:
New

Logging Required:
Yes if absorbed

Learning Capture Required:
Yes

Example 2: Newsletter Intelligence Work Unit

Work Unit Title:
Extract Business Signal From Newsletter And Route To Correct Brain

Work Unit Type:
Newsletter Intelligence

Source:
Gmail newsletter

Owning Brain:
HeadOffice Brain

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

Assigned AI Employee:
Newsletter Signal Extraction Agent

Input Payload:
Subject, sender, body, date, snippet, metadata

Context Pack:
HeadOffice Newsletter Intelligence Operating Protocol, Brain Routing Rule, Output Validation Standard, dashboard action rules

Task Instruction:
Extract only business-relevant signals. Ignore generic news. Identify pattern, Brain impact, action type, urgency, priority, and recommended route.

Required Output Format:
Newsletter intelligence record and review queue item

Tool Permission:
Gmail read, OpenAI processing, controlled Supabase write into approved table

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

Validation Level:
Level 3 — Operational Validation

Human Review Required:
Yes before downstream action

Risk Level:
Medium

Priority:
Based on signal value

Handoff Destination:
Newsletter Queue Review and HeadOffice Dashboard candidate

Required Next Action:
Review, route, park, reject, monitor, or create action

Expected Business Outcome:
Useful intelligence becomes visible and actionable

Status:
New

Logging Required:
Yes

Learning Capture Required:
Yes if repeated pattern appears

Example 3: Brain Room Work Unit

Work Unit Title:
Convert Brain Room Message Into Structured AI Task

Work Unit Type:
Brain Room Task Creation

Source:
Brain Room message

Owning Brain:
Determined by classification

Supporting Brains:
HeadOffice Brain if cross-system or governance-related

Assigned AI Employee:
Brain Room Task Builder Agent

Input Payload:
Message, sender, timestamp, thread context

Context Pack:
Brain Routing Rule, AI Agent Operations Core, Agentic Work Unit Standard, current active build boundary

Task Instruction:
Classify the message, identify the owning Brain, create a structured task, assign the correct AI Employee, set risk level, and define next action.

Required Output Format:
Agentic Work Unit draft

Tool Permission:
Brain Room read and draft task creation only

Forbidden Actions:
Do not execute live changes. Do not bypass AI Manager. Do not assign M’s active build unless requested.

Validation Level:
Level 3 — Operational Validation

Human Review Required:
Yes for medium or high-risk tasks

Risk Level:
Variable

Priority:
Based on task importance

Handoff Destination:
AI Manager, human review, or Parking System

Required Next Action:
Approve, revise, route, park, or reject task

Expected Business Outcome:
Brain Room discussion becomes trackable work

Status:
New

Logging Required:
Yes

Learning Capture Required:
If repeated request pattern appears

Example 4: Offer Evaluation Work Unit

Work Unit Title:
Evaluate Affiliate Offer For Test Suitability

Work Unit Type:
Offer Evaluation

Source:
Affiliate offer page, network data, or newsletter signal

Owning Brain:
Affiliate Brain

Supporting Brains:
Research Brain, Ads Brain, Finance Brain, Experimentation Brain, HeadOffice Brain

Assigned AI Employee:
Offer Evaluation Agent

Input Payload:
Offer name, network, payout, niche, funnel, claims, traffic platform, user goal, available metrics

Context Pack:
Affiliate Product Intelligence Protocol, Opportunity System Operating Protocol, Ads Brain compliance rules, Finance Brain budget rules, Experimentation Brain test rules

Task Instruction:
Evaluate the offer for test suitability. Separate vendor claims from evidence. Review market fit, funnel strength, traffic fit, compliance risk, financial logic, and experimentation suitability. Produce a clear Green, Yellow, or Red verdict.

Required Output Format:
Offer Evaluation Report

Tool Permission:
Web research allowed when current data is required

Forbidden Actions:
Do not approve ad spend. Do not launch campaigns. Do not invent metrics. Do not ignore compliance risks.

Validation Level:
Level 4 — High Risk Validation

Human Review Required:
Yes

Risk Level:
High

Priority:
Based on revenue potential and timing

Handoff Destination:
Research Brain, Finance Brain, Experimentation Brain, Parking System, or HeadOffice decision queue

Required Next Action:
Reject, park, request research, send to Finance, send to Experimentation, or prepare test plan

Expected Business Outcome:
MWMS avoids weak offers and identifies better test candidates

Status:
New

Logging Required:
Yes

Learning Capture Required:
Yes

Example 5: Developer Support Work Unit

Work Unit Title:
Prepare Exact Developer Handoff For M

Work Unit Type:
Developer Support

Source:
Screenshot, file content, error message, or user instruction

Owning Brain:
HeadOffice Brain

Supporting Brains:
Operations Brain, Dev Console, relevant technical system

Assigned AI Employee:
Developer Support Agent

Input Payload:
Exact screenshot, file path, plugin file, site name, issue description, current save point

Context Pack:
Full File Output Rule, exact instruction requirement, current safe save point, what not to touch, developer boundary

Task Instruction:
Prepare precise developer instructions anchored to visible evidence or file contents. Include exact site, exact file path, exact replacement/insertion location, full file output where required, what not to touch, and test steps.

Required Output Format:
Developer Handoff Brief

Tool Permission:
Provided input only unless file search or uploaded file review is required

Forbidden Actions:
Do not guess file paths. Do not give vague search instructions. Do not alter live code. Do not touch unrelated systems.

Validation Level:
Level 4 — High Risk Validation

Human Review Required:
Yes

Risk Level:
High

Priority:
Based on M’s build dependency

Handoff Destination:
M developer handoff or Dev Console

Required Next Action:
Send to M, revise, request file, request screenshot, or park

Expected Business Outcome:
M can act safely without guessing

Status:
New

Logging Required:
Yes for meaningful build work

Learning Capture Required:
If new dev rule or save point is created

Agentic Work Unit Validation Checklist

Before using a Work Unit, check:

  1. Is the title clear?
  2. Is the type correct?
  3. Is the source identified?
  4. Is the owning Brain clear?
  5. Are supporting Brains listed where needed?
  6. Is the assigned AI Employee appropriate?
  7. Is the input payload specific?
  8. Is the context pack sufficient?
  9. Is the task instruction clear?
  10. Is the output format defined?
  11. Are tool permissions clear?
  12. Are forbidden actions listed?
  13. Is validation level appropriate?
  14. Is human review required?
  15. Is risk level correct?
  16. Is priority based on business value?
  17. Is handoff destination clear?
  18. Is next action specific?
  19. Is expected outcome defined?
  20. Is logging or learning required?

If the answer to several of these is unclear, the Work Unit is not ready.

Common Failure Modes

The Agentic Work Unit has failed if:

  1. The AI Employee has to guess the task.
  2. The owning Brain is unclear.
  3. The input payload is vague.
  4. The output format is not defined.
  5. The Work Unit has no handoff destination.
  6. Risk level is missing.
  7. Human review is skipped for high-risk work.
  8. Tool permissions are unclear.
  9. Forbidden actions are missing.
  10. The task produces output but no outcome.
  11. The work interferes with M’s active build.
  12. The source cannot be traced.
  13. The task is too broad for one AI Employee.
  14. The result cannot be validated.
  15. Nothing is logged when it should be.

Manual Use Rule

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

Manual use helps MWMS learn:

  • which fields are truly needed
  • which fields are too heavy
  • which workflows repeat
  • which Brains need support
  • which AI Employees are useful
  • which outputs need validation
  • which parts are ready for future plugin/UI build

Manual proof comes before automation.

Future Plugin Or UI Relevance

This template may later become:

  • Brain Room task creation form
  • AI Manager task record
  • Supabase task schema
  • AI Employee Router input structure
  • HeadOffice task review card
  • Workflow queue item
  • AIBS client workflow record

Possible future fields:

  • work_unit_id
  • title
  • type
  • source
  • source_reference
  • originating_brain
  • owning_brain
  • supporting_brains
  • assigned_employee
  • authority_level
  • input_payload
  • context_pack
  • task_instruction
  • output_format
  • tool_permission
  • forbidden_actions
  • validation_level
  • human_review_required
  • risk_level
  • priority
  • handoff_destination
  • next_action
  • expected_outcome
  • status
  • logging_required
  • learning_required
  • created_at
  • updated_at

No technical build is authorized by this template alone.

Governance Role

HeadOffice owns the MWMS Agentic Work Unit Template.

HeadOffice is responsible for:

  • deciding when this template is required
  • ensuring high-risk tasks use structured work units
  • preventing vague AI execution
  • ensuring Brain ownership is clear
  • ensuring AI Employee assignment is role-based
  • ensuring validation and handoff rules are included
  • protecting M’s active build areas
  • deciding when the template is ready for operational copy or plugin/UI transformation

Individual Brains may use this template for their own workflows, but they must not remove core fields for high-risk work.

Relationship To Other MWMS Standards

This template supports and must align with:

  • MWMS AI Agent Operations Core
  • MWMS Agentic Work Unit Standard
  • MWMS AI Employee Role Card Standard
  • MWMS AI Agent Orchestration Framework
  • MWMS AI Workflow Pipeline Standard
  • MWMS AI Output Validation Standard
  • MWMS Messy Input Normalization Framework
  • MWMS Agentic Reporting Standard
  • MWMS AI Employee Handoff Protocol
  • MWMS AI Agent Failure Handling And Escalation Protocol
  • MWMS AI Agent Outcome Measurement Framework
  • MWMS AI Agent Deployment Readiness Checklist
  • MWMS AI Employee Capability Stack Framework
  • MWMS AI Tool Permission And Access Framework
  • MWMS AI Agent Memory And Context Framework
  • MWMS AI Workforce Governance Model
  • MWMS AI Agent Operations Core Copy Map
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS Supabase Event Schema
  • MWMS System Data Flow Map
  • AI Business Systems Brain Blueprint

This template is the practical application of the Agentic Work Unit Standard.

Drift Protection

This template protects MWMS from the following forms of drift:

  1. Starting important AI work from vague prompts
  2. Losing source context
  3. Assigning work without Brain ownership
  4. Assigning work to generic AI instead of role-based Employees
  5. Skipping tool permission checks
  6. Producing outputs with no validation
  7. Producing outputs with no handoff destination
  8. Treating AI output as business outcome
  9. Letting high-risk tasks skip human review
  10. Creating developer tasks that make M guess
  11. Allowing Brain Room messages to become lost chat
  12. Absorbing weak course material without value checks
  13. Routing offers without Research, Finance, or Experimentation review
  14. Creating dashboard noise
  15. Automating work before the work unit is stable

Any important AI task without a Work Unit should be considered less reliable.

Architectural Intent

The architectural intent of the MWMS Agentic Work Unit Template is to make AI work structured from the beginning.

MWMS is building a governed AI workforce.

A workforce needs clear work orders.

This template is the AI work order.

The long-term goal is that every important AI action can answer:

  • What is the task?
  • Where did it come from?
  • Which Brain owns it?
  • Which AI Employee performs it?
  • What input is used?
  • What context is required?
  • What output is expected?
  • What tools are allowed?
  • What is forbidden?
  • How is it validated?
  • Where does it go next?
  • What outcome should it create?
  • What should be logged?
  • What should MWMS learn?

When MWMS can answer those questions before work begins, the system becomes easier to manage, automate, validate, and improve.

Change Log

v1.0 — Initial Draft

Created the MWMS Agentic Work Unit Template as the practical operating template for converting requests, messages, files, newsletters, course lessons, offers, developer issues, dashboard items, and system events into structured AI work.

This template operationalizes the MWMS Agentic Work Unit Standard and supports future Brain Room, AI Manager, AI Employee Router, Task Executor, Newsletter Intelligence, Course Absorption, Offer Evaluation, HeadOffice reporting, and AIBS client workflow systems.