MWMS MCR

MWMS AI Employee Handoff Package 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 AI Employee Handoff Package Template.

This template provides the practical structure for transferring work from one AI Employee, Brain, workflow, queue, dashboard, human reviewer, MCR page process, developer, or future client-facing system to another.

MWMS must not allow important work to move forward through vague handoffs.

A handoff must clearly explain:

  • what is being handed off
  • where it came from
  • who or what completed the previous stage
  • what has already been done
  • what still needs to happen
  • who owns the next step
  • what context must be preserved
  • what validation status applies
  • what risks exist
  • what the receiver must do next
  • what should be logged or learned

This template is the practical daily-use version of the MWMS AI Employee Handoff Protocol.

Scope

This template applies whenever MWMS transfers work between:

  • AI Employee to AI Employee
  • Brain to Brain
  • AI Employee to human
  • human to AI Employee
  • Brain Room to AI Manager
  • AI Manager to AI Employee Router
  • AI Employee Router to Task Executor
  • Newsletter Intelligence to Queue Review
  • Queue Review to Routed Actions
  • Course Absorption to MCR page creation
  • Affiliate Brain to Research Brain
  • Research Brain to Experimentation Brain
  • Experimentation Brain to Finance Brain
  • HeadOffice to M
  • Dev Console to developer workflow
  • MCR to operational Brain site
  • future AIBS workflow to client review

This template can be used manually first.

Later, parts of this template may become fields inside Supabase task records, Brain Room handoff screens, AI Manager routing logic, validation queues, dashboards, or future AIBS client workflow systems.

Core Definition

An AI Employee Handoff Package is the structured transfer record that allows the next role, Brain, person, or system to continue work safely without guessing.

A handoff is not just an output.

A handoff is the context package that travels with the output.

It preserves:

  • source
  • ownership
  • completed work
  • current status
  • validation state
  • risk
  • required next action
  • destination
  • unresolved issues
  • business outcome
  • logging or learning requirement

A task is not truly complete until its handoff is clear.

AI Employee Handoff Package Template

1. Handoff Title

Field:
Handoff Title:

Purpose:
Gives the handoff a clear name.

Good Examples:

  • Course Framework Handoff To MCR Page Creation
  • Newsletter Signal Handoff To Ads Brain
  • Affiliate Offer Handoff To Finance Brain
  • Brain Room Request Handoff To AI Manager
  • Developer Brief Handoff To M
  • Validation Failure Handoff To HeadOffice Review

Bad Examples:

  • Next
  • This One
  • Report
  • Task
  • Follow Up

Rule:
The title should make the transfer obvious at a glance.

2. Handoff Type

Field:
Handoff Type:

Recommended Values:

  • AI Employee To AI Employee
  • Brain To Brain
  • AI Employee To Human
  • Human To AI Employee
  • Queue To Workflow
  • Workflow To Dashboard
  • Workflow To MCR
  • Workflow To Developer
  • Workflow To Client
  • Validation To Revision
  • Failure To Escalation
  • Outcome To Learning Log

Rule:
The handoff type helps determine the required detail and risk controls.

3. Source

Field:
Source:

Purpose:
Identifies where the work originated.

Examples:

  • uploaded course file
  • course transcript
  • newsletter
  • Brain Room message
  • affiliate offer page
  • Supabase row
  • WordPress page list
  • dashboard item
  • validation report
  • developer note
  • user instruction
  • MCR page draft
  • experiment result
  • finance report
  • client document

Rule:
The receiver must know where the work came from.

4. Source Reference

Field:
Source Reference:

Purpose:
Records the exact source identifier where available.

Examples:

  • file name
  • course lesson title
  • newsletter subject
  • page title
  • dashboard row
  • task ID
  • Supabase record ID
  • screenshot reference
  • Brain Room thread
  • date received
  • report title

Rule:
If the source may need to be checked later, include a reference.

5. Originating Brain Or System

Field:
Originating Brain Or System:

Purpose:
Identifies where the work 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:
The origin tells the story of where the request entered MWMS.

6. Receiving Brain Or Role

Field:
Receiving Brain Or Role:

Purpose:
Identifies who or what receives the handoff.

Examples:

  • HeadOffice Review
  • MCR Page Creation
  • Research Brain
  • Finance Brain
  • Experimentation Brain
  • Ads Brain
  • Content Brain
  • AI Manager
  • Task Executor
  • Validation Agent
  • M
  • Martyn
  • Human Review Queue
  • Parking System
  • AIBS Client Review

Rule:
A handoff with no clear receiver is not valid.

7. Owner Of Next Action

Field:
Owner Of Next Action:

Purpose:
Identifies who is responsible for moving the work forward.

Examples:

  • Martyn
  • M
  • HeadOffice
  • Course Absorption Agent
  • HeadOffice Validation Agent
  • Research Brain
  • Finance Brain
  • AI Manager
  • Human Review Queue
  • Future Client Operator

Rule:
A handoff must not create orphaned work.

8. Reason For Handoff

Field:
Reason For Handoff:

Purpose:
Explains why the work is being transferred.

Examples:

  • needs validation
  • needs finance review
  • needs research evidence
  • ready for MCR save
  • ready for developer implementation
  • needs HeadOffice decision
  • needs dashboard review
  • needs human approval
  • failed validation
  • requires escalation
  • ready for client review
  • should be parked for later

Rule:
The receiver must understand why they are receiving it.

9. Work Completed

Field:
Work Completed:

Purpose:
Summarizes what has already been done.

Examples:

  • lesson reviewed
  • useful frameworks extracted
  • weak material ignored
  • offer reviewed at first pass
  • newsletter signal extracted
  • Brain ownership classified
  • page draft created
  • validation completed
  • failure identified
  • developer issue analyzed

Rule:
This prevents repeated work and confusion.

10. Output Produced

Field:
Output Produced:

Purpose:
Identifies the output being handed off.

Examples:

  • full page output
  • course absorption report
  • newsletter intelligence record
  • Agentic Work Unit draft
  • AI Employee Role Card
  • validation report
  • developer handoff brief
  • offer evaluation report
  • finance scenario report
  • dashboard card
  • failure log draft
  • outcome log draft

Rule:
The receiver must know what output they are expected to use or review.

11. Current Status

Field:
Current Status:

Recommended Values:

  • Draft
  • Ready For Review
  • Needs Validation
  • Validated
  • Failed Validation
  • Waiting For Human Review
  • Ready For Routing
  • Routed
  • Waiting For Input
  • Parked
  • Rejected
  • Escalated
  • Completed
  • Logged
  • Archived

Rule:
The handoff must show the current state of the work.

12. Validation Status

Field:
Validation Status:

Recommended Values:

  • Not Validated
  • Self Checked
  • Needs Validation
  • Validated
  • Failed Validation
  • Human Review Required
  • Source Verification Required
  • Developer Review Required
  • Compliance Review Required
  • Finance Review Required

Rule:
Validation status must travel with the handoff.

13. Risk Level

Field:
Risk Level:

Recommended Values:

  • Low
  • Medium
  • High
  • Critical

High-Risk Handoffs Include:

  • MCR canon
  • developer instructions
  • live system changes
  • Supabase writes
  • WordPress updates
  • paid traffic decisions
  • finance decisions
  • compliance-sensitive content
  • public-facing content
  • client-facing outputs
  • M’s active build areas

Rule:
Risk level determines review and escalation requirements.

14. Context To Preserve

Field:
Context To Preserve:

Purpose:
Lists important context the receiver must know.

Examples:

  • MCR is source of truth
  • this is draft only
  • current save point
  • developer boundary
  • what not to touch
  • previous decision
  • source limitation
  • missing input
  • related standards
  • user preference
  • active workflow stage
  • validation notes
  • known risk
  • reason for parking or escalation

Rule:
Context lost during handoff creates workflow failure.

15. Known Gaps Or Open Questions

Field:
Known Gaps Or Open Questions:

Purpose:
Identifies what is still uncertain.

Examples:

  • source file expired
  • screenshot does not show full context
  • page existence not confirmed
  • finance data missing
  • compliance needs review
  • offer metrics not verified
  • developer file path missing
  • current system state unknown
  • more research required
  • user decision required

Rule:
Do not hide uncertainty.

16. Required Next Action

Field:
Required Next Action:

Purpose:
Defines exactly what the receiver must do next.

Examples:

  • review and approve
  • revise output
  • validate source
  • create MCR page
  • update registry
  • route to Research Brain
  • run finance review
  • prepare developer brief
  • send to M
  • park for later
  • reject
  • escalate to HeadOffice
  • create task
  • add to dashboard after validation
  • log learning

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

17. Due Timing

Field:
Due Timing:

Recommended Values:

  • Immediate
  • Today
  • Tomorrow
  • Next Session
  • Before Build
  • Before Launch
  • After Validation
  • No Timing Required
  • Parked For Later

Rule:
Timing is optional for low-risk work but important for operational handoffs.

18. Human Review Required

Field:
Human Review Required: Yes / No

Purpose:
Defines whether a human must review before the work moves forward.

Human Review Required For:

  • MCR canon
  • developer implementation
  • live systems
  • paid traffic
  • finance
  • compliance
  • public content
  • client output
  • high-risk automation
  • unclear ownership

Rule:
When unsure, require human review.

19. Escalation Trigger

Field:
Escalation Trigger:

Purpose:
Defines what should stop the workflow and escalate the handoff.

Examples:

  • receiver cannot identify next action
  • source is incomplete
  • risk level increases
  • compliance issue found
  • finance issue found
  • developer ambiguity remains
  • live system impact found
  • M’s active build affected
  • validation fails
  • ownership unclear
  • tool permission unclear

Rule:
A handoff should know when not to continue.

20. Logging Required

Field:
Logging Required: Yes / No

Purpose:
Defines whether the handoff should be logged.

Logging Required For:

  • cross-Brain handoffs
  • MCR page handoffs
  • developer handoffs
  • high-risk handoffs
  • validation failures
  • escalations
  • outcome decisions
  • client handoffs
  • important HeadOffice decisions

Rule:
Important transfers should leave a trace.

21. Learning Capture Required

Field:
Learning Capture Required: Yes / No

Purpose:
Defines whether the handoff produced reusable learning.

Learning Examples:

  • new failure mode identified
  • new validation rule needed
  • new workflow pattern found
  • new AI Employee role clarified
  • new developer instruction rule
  • new course absorption insight
  • new offer rejection reason
  • new dashboard filter needed
  • new AIBS packaging idea

Rule:
Useful learning should not disappear during transfer.

Quick Use Version

Use this shorter handoff package when moving work quickly.

Handoff Title:
Handoff Type:
Source:
Source Reference:
Originating Brain Or System:
Receiving Brain Or Role:
Owner Of Next Action:
Reason For Handoff:
Work Completed:
Output Produced:
Current Status:
Validation Status:
Risk Level:
Context To Preserve:
Known Gaps Or Open Questions:
Required Next Action:
Due Timing:
Human Review Required:
Escalation Trigger:
Logging Required:
Learning Capture Required:

Example 1: Course Absorption To MCR Page Creation

Handoff Title:
Course Framework Handoff To MCR Page Creation

Handoff Type:
Workflow To MCR

Source:
Uploaded course transcript

Source Reference:
Mastering Claude Cowork And AI Agent Automation lesson block

Originating Brain Or System:
Course Absorption System

Receiving Brain Or Role:
MCR Page Creation

Owner Of Next Action:
Martyn / HeadOffice

Reason For Handoff:
Course lesson produced a reusable MWMS operating standard worth turning into a full MCR page.

Work Completed:
Lesson reviewed, MWMS system value extracted, duplicate risk considered, page topic identified.

Output Produced:
Full page output draft.

Current Status:
Ready For Review

Validation Status:
Human Review Required

Risk Level:
Medium

Context To Preserve:
MCR remains source of truth. Page must follow MWMS naming and document structure rules. Do not interfere with M’s active build.

Known Gaps Or Open Questions:
Confirm page does not already exist before saving.

Required Next Action:
Review page, save to MCR if approved, then update registry if needed.

Due Timing:
Next Session or When Saving Pages

Human Review Required:
Yes

Escalation Trigger:
If duplicate page exists or parent placement is unclear.

Logging Required:
Yes if saved.

Learning Capture Required:
Yes

Example 2: Newsletter Signal To Ads Brain

Handoff Title:
Newsletter Signal Handoff To Ads Brain

Handoff Type:
Brain To Brain

Source:
Newsletter Intelligence

Source Reference:
Newsletter subject and date

Originating Brain Or System:
HeadOffice Newsletter Intelligence

Receiving Brain Or Role:
Ads Brain

Owner Of Next Action:
HeadOffice / Ads Brain

Reason For Handoff:
Newsletter contains a platform or traffic signal that may affect paid traffic strategy.

Work Completed:
Signal extracted, primary Brain classified, action type assigned.

Output Produced:
Newsletter intelligence record.

Current Status:
Needs Review

Validation Status:
Needs Validation

Risk Level:
Medium

Context To Preserve:
Do not treat as rule change until validated. Dashboard item should remain specific and action-ready.

Known Gaps Or Open Questions:
May require current platform verification if action is significant.

Required Next Action:
Review signal, decide Monitor, Test, Park, Reject, or create Ads Brain update task.

Due Timing:
Next Review Cycle

Human Review Required:
Yes before downstream task.

Escalation Trigger:
If signal affects ad policy, budget, compliance, or campaign structure.

Logging Required:
Yes

Learning Capture Required:
Yes if repeated pattern appears.

Example 3: Affiliate Offer To Finance Brain

Handoff Title:
Affiliate Offer Handoff To Finance Brain

Handoff Type:
Brain To Brain

Source:
Affiliate offer evaluation

Source Reference:
Offer name, network, and evaluation report

Originating Brain Or System:
Affiliate Brain

Receiving Brain Or Role:
Finance Brain

Owner Of Next Action:
Finance Brain / Martyn

Reason For Handoff:
Offer appears potentially testable but requires break-even and safe test-budget review before any spend decision.

Work Completed:
Initial offer review completed. Market fit, funnel type, traffic fit, and early risk notes identified.

Output Produced:
Offer evaluation report with preliminary verdict.

Current Status:
Waiting For Finance Review

Validation Status:
Source Verification Required / Human Review Required

Risk Level:
High

Context To Preserve:
No ad spend approval yet. Vendor claims must not be treated as verified performance data. Finance assumptions must be explicit.

Known Gaps Or Open Questions:
Payout, EPC, refund risk, conversion assumptions, and traffic cost may require current verification.

Required Next Action:
Calculate break-even logic, safe test budget, loss exposure, and finance verdict.

Due Timing:
Before Any Test Planning

Human Review Required:
Yes

Escalation Trigger:
If finance data is missing, assumptions are weak, or test risk is high.

Logging Required:
Yes

Learning Capture Required:
Yes if offer is rejected, parked, or moved to test.

Example 4: Brain Room Message To AI Manager

Handoff Title:
Brain Room Request Handoff To AI Manager

Handoff Type:
Queue To Workflow

Source:
Brain Room message

Source Reference:
Brain Room thread and timestamp

Originating Brain Or System:
Brain Room

Receiving Brain Or Role:
AI Manager

Owner Of Next Action:
AI Manager / Human Review Queue

Reason For Handoff:
Message contains a request that should become structured AI work.

Work Completed:
Message captured and request classified.

Output Produced:
Agentic Work Unit draft.

Current Status:
Ready For Review

Validation Status:
Needs Validation

Risk Level:
Variable

Context To Preserve:
Do not execute live changes automatically. Respect current active build boundaries. Assign owning Brain before processing.

Known Gaps Or Open Questions:
May require clarification if request mixes multiple tasks.

Required Next Action:
Review Work Unit, approve route, assign AI Employee, or park.

Due Timing:
As Needed

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

Escalation Trigger:
If request touches M’s active build, live systems, money, compliance, or unclear ownership.

Logging Required:
Yes

Learning Capture Required:
If repeated request type appears.

Example 5: Developer Brief To M

Handoff Title:
Developer Brief Handoff To M

Handoff Type:
Workflow To Developer

Source:
Developer support analysis

Source Reference:
Screenshot, file, issue, or task reference

Originating Brain Or System:
HeadOffice / Dev Console / Brain Room

Receiving Brain Or Role:
M

Owner Of Next Action:
M

Reason For Handoff:
M needs exact implementation or review instructions.

Work Completed:
Issue analyzed, required change identified, implementation boundaries defined.

Output Produced:
Developer handoff brief.

Current Status:
Ready For M Review

Validation Status:
Human Review Required / Developer Review Required

Risk Level:
High

Context To Preserve:
Exact site, exact file path if available, current save point, what not to touch, test steps, expected result.

Known Gaps Or Open Questions:
Do not proceed if file contents, screenshot, or current state are missing.

Required Next Action:
M reviews, applies only the stated change, tests, reports result, and save point is updated if successful.

Due Timing:
When Assigned

Human Review Required:
Yes

Escalation Trigger:
If M must guess, if file path is unclear, if the change touches unrelated systems, or if live system risk appears.

Logging Required:
Yes

Learning Capture Required:
Yes if a new save point or dev rule is created.

Example 6: Validation Failure To Revision

Handoff Title:
Failed Validation Handoff To Revision

Handoff Type:
Validation To Revision

Source:
AI output validation

Source Reference:
Output title and validation report

Originating Brain Or System:
HeadOffice Validation

Receiving Brain Or Role:
Original AI Employee Or Human Reviewer

Owner Of Next Action:
Assigned reviser

Reason For Handoff:
Output failed validation and must be corrected before use.

Work Completed:
Validation checklist applied. Issues identified.

Output Produced:
Validation failure report.

Current Status:
Failed Validation

Validation Status:
Failed Validation

Risk Level:
Based on output type

Context To Preserve:
Do not use failed output operationally. Revise only the failed areas unless broader rewrite is required.

Known Gaps Or Open Questions:
List missing sections, unsupported claims, wrong routing, or format problems.

Required Next Action:
Revise output, revalidate, then accept, park, reject, or escalate.

Due Timing:
Before Any Use

Human Review Required:
Depends on risk level

Escalation Trigger:
If failure affects MCR, development, money, compliance, client output, or live systems.

Logging Required:
Yes for important outputs.

Learning Capture Required:
Yes if repeated failure pattern appears.

Handoff Quality Checklist

Before accepting or sending a handoff, check:

  1. Is the handoff title clear?
  2. Is the handoff type clear?
  3. Is the source identified?
  4. Is the source reference included where needed?
  5. Is the originating Brain or system clear?
  6. Is the receiving Brain or role clear?
  7. Is the owner of the next action clear?
  8. Is the reason for handoff stated?
  9. Is completed work summarized?
  10. Is the output produced identified?
  11. Is current status clear?
  12. Is validation status clear?
  13. Is risk level assigned?
  14. Is important context preserved?
  15. Are known gaps or open questions stated?
  16. Is the required next action specific?
  17. Is due timing stated where needed?
  18. Is human review requirement clear?
  19. Are escalation triggers defined?
  20. Is logging or learning required?

If several answers are unclear, the handoff is not ready.

Common Handoff Failure Modes

A handoff has failed if:

  1. The receiver is unclear.
  2. The next action is vague.
  3. The source is missing.
  4. Validation status is missing.
  5. Risk level is missing.
  6. Important context is lost.
  7. The handoff says “done” when review is still needed.
  8. M receives instructions that require guessing.
  9. A Brain receives work without reason for transfer.
  10. A dashboard item has no action.
  11. Course material moves to MCR without duplication check.
  12. Offer moves toward spend without Finance or Experimentation review.
  13. A failed output is reused without revision.
  14. Human review is skipped.
  15. Nothing is logged when it should be.

Manual Use Rule

This template should be used manually before it becomes a plugin feature, queue record, or task-transition system.

Manual use helps MWMS learn:

  • which handoff fields are essential
  • which workflows lose context
  • which Brains need better transfer rules
  • which AI Employees need stronger output standards
  • which handoffs should later become Supabase records
  • which dashboard handoffs create value
  • which developer handoffs protect M best

Manual proof comes before automation.

Future Plugin Or UI Relevance

This template may later become:

  • Brain-to-Brain handoff record
  • Brain Room to AI Manager handoff form
  • AI Employee task transition record
  • HeadOffice routed action card
  • validation queue transition
  • M developer handoff screen
  • MCR page approval handoff
  • AIBS client approval handoff
  • Supabase handoff table
  • handoff status dashboard

Possible future fields:

  • handoff_id
  • handoff_title
  • handoff_type
  • source
  • source_reference
  • originating_brain
  • receiving_brain_or_role
  • next_action_owner
  • reason_for_handoff
  • work_completed
  • output_reference
  • current_status
  • validation_status
  • risk_level
  • context_to_preserve
  • known_gaps
  • required_next_action
  • due_timing
  • human_review_required
  • escalation_trigger
  • logging_required
  • learning_required
  • created_at
  • updated_at

No technical build is authorized by this template alone.

Governance Role

HeadOffice owns the MWMS AI Employee Handoff Package Template.

HeadOffice is responsible for:

  • deciding when a handoff package is required
  • ensuring handoffs preserve context
  • ensuring cross-Brain transfers are controlled
  • ensuring high-risk handoffs require human review
  • protecting M from vague developer handoffs
  • protecting MCR from incomplete page handoffs
  • protecting dashboards from weak routed outputs
  • ensuring handoffs support business outcomes
  • deciding when handoff templates are ready for operational copy or plugin/UI transformation

Individual Brains may use simplified handoff versions for their own workflows, but they must not remove core handoff controls for high-risk work.

Relationship To Other MWMS Standards

This template supports and must align with:

  • MWMS AI Agent Operations Core
  • MWMS AI Employee Handoff Protocol
  • MWMS Agentic Work Unit Standard
  • MWMS Agentic Work Unit Template
  • MWMS AI Employee Role Card Standard
  • MWMS AI Employee Role Card Template
  • MWMS AI Output Validation Standard
  • MWMS AI Output Validation Checklist
  • MWMS AI Workflow Pipeline Standard
  • MWMS Agentic Reporting Standard
  • MWMS AI Agent Failure Handling And Escalation Protocol
  • MWMS AI Agent Outcome Measurement Framework
  • MWMS AI Tool Permission And Access Framework
  • MWMS AI Agent Memory And Context Framework
  • 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 MWMS AI Employee Handoff Protocol.

Drift Protection

This template protects MWMS from the following forms of drift:

  1. Passing work without ownership
  2. Losing context between stages
  3. Treating transfer as completion
  4. Routing work without validation status
  5. Sending vague instructions to M
  6. Moving course material into MCR without clear value
  7. Moving offers toward testing without Finance or Experimentation review
  8. Sending dashboard items with no action
  9. Creating cross-Brain confusion
  10. Skipping human review on high-risk work
  11. Failing to log important transfers
  12. Duplicating work because previous stage was not summarized
  13. Letting Brain Room discussion disappear without task conversion
  14. Creating client confusion through unclear handoffs
  15. Automating handoffs before manual handoff quality is proven

Any important transfer without a handoff package should be treated as incomplete.

Architectural Intent

The architectural intent of the MWMS AI Employee Handoff Package Template is to make AI workforce work transferable without losing meaning.

MWMS will increasingly depend on work moving between Brains, AI Employees, humans, queues, dashboards, MCR pages, developers, and future client systems.

This template ensures the work does not lose:

  • source
  • purpose
  • ownership
  • context
  • status
  • validation
  • risk
  • next action
  • outcome
  • learning

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

  • What is being transferred?
  • Where did it come from?
  • Who receives it?
  • Why is it being handed off?
  • What has already been done?
  • What output was produced?
  • What context matters?
  • What is still missing?
  • What is the validation state?
  • What is the risk?
  • What must happen next?
  • Who owns the next action?
  • Should it be logged?
  • Should MWMS learn from it?

When MWMS can answer those questions, the system can operate as a coordinated AI workforce rather than a collection of disconnected outputs.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Employee Handoff Package Template as the practical operational template for transferring work between AI Employees, Brains, humans, queues, dashboards, MCR, developers, and future AIBS client workflows.

This template operationalizes the MWMS AI Employee Handoff Protocol and supports Brain Room task conversion, AI Manager routing, cross-Brain handoffs, M developer handoffs, MCR page handoffs, validation failure routing, newsletter routing, offer evaluation routing, and future client approval handoffs.