MWMS MCR

MWMS AI Employee Handoff Protocol

System: MWMS
Document Type: Protocol
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.1
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, Automation Brain, AIBS Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-17
Source / Origin: MWMS AI Employee Handoff Protocol v1.0 + AI Automations by Jack — Multi-Model Orchestration, Persistent Agents, Rescue Routing, External Knowledge And Session Closure Block
MWMS Classification: AI Employee Handoff Protocol / Cross-Brain Transfer Standard / Workflow Continuity Protocol / Context Preservation Standard
Primary Brain: HeadOffice Brain
Supporting Brains: MWMS Brain, Automation Brain, AIBS Brain, Operations Brain, Data Brain, Risk Brain, Compliance Brain, SIT Brain
Related Pages: 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 AI Agent Failure Handling And Escalation Protocol, MWMS Independent Model Review And Rescue Routing Framework, MWMS AI Agent Memory And Context Framework, MWMS External Knowledge Engine And Reasoning Agent Separation Framework, MWMS AI Work Session Closure And Knowledge Commitment Protocol, MWMS AI Tool Permission And Access Framework, MWMS AI Observability Metadata Standard, MWMS Messy Input Normalization Framework, MWMS Agentic Reporting Standard, MWMS Brain Routing Rule, MWMS Brain To Brain Request Protocol, MWMS Supabase Event Schema
Source Evidence: The existing MWMS AI Employee Handoff Protocol defines how work moves between AI Employees, Brains, humans, queues, dashboards, MCR, developers and client workflows while preserving source, ownership, context, validation, risk and next action. The newly absorbed material strengthens the protocol with Work Unit identity, model-route transfers, independent-review handoffs, rescue packets, persistent-agent state, external-knowledge provenance, tool-execution evidence, acceptance confirmation, session closure and cross-interface continuity.

Purpose

The purpose of this document is to define the MWMS AI Employee Handoff Protocol.

This protocol establishes how work is passed from one AI Employee, Brain, workflow stage, model route, system, queue or human reviewer to another without losing:

  • context
  • ownership
  • task identity
  • source evidence
  • validation status
  • failure history
  • risk awareness
  • permission boundaries
  • business intent
  • current state
  • required next action

MWMS is being designed as a governed AI workforce system.

A workforce cannot operate properly if work is handed off vaguely.

A valid handoff must make clear:

  • what work was requested
  • what source material was used
  • what work has been completed
  • what output was produced
  • what was validated
  • what failed
  • what remains unresolved
  • which Brain owns the next step
  • which AI Employee, model or human acts next
  • what context must be preserved
  • what risks or restrictions apply
  • what tools or permissions are available
  • where the output should go
  • what outcome is expected
  • what must be logged
  • what knowledge should be committed

This protocol exists to prevent MWMS from losing value between workflow stages.

Scope

This protocol applies to all MWMS workflows where work moves between:

  • one AI Employee and another
  • one model route and another
  • one Brain and another
  • AI Employee and human reviewer
  • human reviewer and AI Employee
  • Brain Room and AI Manager
  • AI Manager and AI Employee Router
  • AI Employee Router and Task Executor
  • primary agent and independent reviewer
  • failed agent and Rescue Agent
  • Newsletter Intelligence and HeadOffice Queue
  • Course Absorption and MCR page creation
  • Affiliate Brain and Research Brain
  • Research Brain and Experimentation Brain
  • Experimentation Brain and Finance Brain
  • Finance Brain and HeadOffice
  • HeadOffice and M
  • Dev Console and development workflow
  • MCR and Brain sites
  • persistent agents and human operators
  • external knowledge systems and reasoning agents
  • remote command channels and operational workflows
  • future AIBS client systems

This protocol applies to:

  • manual handoffs
  • assisted handoffs
  • automated handoffs
  • multi-agent handoffs
  • cross-model handoffs
  • persistent-agent handoffs
  • remote handoffs
  • client-facing handoffs

Manual handoffs include:

  • Martyn to M
  • course absorption to MCR
  • page draft to human review
  • HeadOffice decision to another Brain
  • report to future work
  • end-of-session save point to the next session

Automated handoffs include:

  • task records
  • queue items
  • dashboard cards
  • routed actions
  • Supabase events
  • AI Employee workflow transitions
  • monitoring alerts
  • scheduled-agent outputs
  • external knowledge retrieval packets

Core Definition

An AI Employee Handoff is the controlled transfer of work from one role, Brain, stage, system, model route or reviewer to the next.

A handoff is not simply passing along an output.

A proper handoff includes everything the receiver needs to continue the work safely and correctly.

A complete handoff preserves:

  • Work Unit identity
  • source
  • task purpose
  • originating authority
  • current status
  • completed work
  • pending work
  • output produced
  • context
  • assumptions
  • evidence
  • risks
  • tool permissions
  • validation state
  • independent-review state
  • failure history
  • required next action
  • next owner
  • destination
  • expected outcome
  • logging requirement
  • closure requirement

A handoff is valid only when the receiver can continue without guessing.

Core Principle

The core principle of this protocol is:

AI work must not move between Brains, Employees, systems, models or humans without a complete and accepted handoff.

This protects MWMS from:

  • lost context
  • repeated work
  • poor routing
  • duplicated pages
  • broken workflows
  • unclear ownership
  • weak validation
  • unsafe automation
  • vague developer instructions
  • dashboard confusion
  • abandoned actions
  • false completion
  • repeated failure loops
  • model-route drift
  • missing source provenance
  • unverified tool claims
  • persistent-agent drift
  • session continuity loss

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

Handoff Completion Rule

A handoff is complete only when:

  • the package is prepared
  • the receiver is identified
  • the transfer is recorded
  • the receiver accepts or rejects it
  • the next action is clear
  • ownership changes are confirmed
  • unresolved issues remain visible

Rule

Sent does not mean received.

Received does not mean accepted.

Accepted does not mean completed.

Why Handoffs Matter

MWMS will increasingly depend on multi-step and multi-agent workflows.

A single piece of work may move through several stages.

A newsletter signal may move through:

  • Newsletter Intake Agent
  • Cleaning Agent
  • Signal Extraction Agent
  • Brain Routing Agent
  • Validation Agent
  • Newsletter Queue Review
  • HeadOffice Dashboard
  • Routed Actions
  • relevant Brain
  • Learning Log

An affiliate offer may move through:

  • Affiliate Brain
  • Research Brain
  • Ads Brain
  • Compliance Brain
  • Finance Brain
  • Experimentation Brain
  • HeadOffice
  • test planning
  • learning capture

A developer issue may move through:

  • Martyn
  • Brain Room
  • Dev Console
  • AI Support
  • M
  • testing
  • outcome verification
  • save point update

A failed workflow may move through:

  • primary AI Employee
  • validation failure
  • failure counter
  • Rescue Agent
  • independent review
  • human decision
  • restarted workflow

Without strong handoffs, these workflows break.

With strong handoffs, MWMS preserves continuity and control.

Handoff Types

MWMS recognises the following handoff types.

  1. AI Employee To AI Employee Handoff

This occurs when one AI Employee completes a stage and another continues the work.

Examples:

  • Course Intake Agent → Framework Extraction Agent
  • Signal Extraction Agent → Brain Routing Agent
  • Research Agent → Validation Agent
  • Offer Evaluation Agent → Finance Analysis Agent
  • Task Builder Agent → Orchestrator Agent

Required content:

  • Work Unit ID
  • completed stage
  • output produced
  • source used
  • context used
  • unresolved questions
  • validation status
  • next required task
  • risk notes
  • tool or permission limits

Rule

The receiving Employee must not be expected to reconstruct missing context.

  1. Brain To Brain Handoff

This occurs when work moves from one Brain to another.

Examples:

  • Affiliate Brain → Research Brain
  • Research Brain → Experimentation Brain
  • Experimentation Brain → Finance Brain
  • Content Brain → Ads Brain
  • HeadOffice Brain → Operations Brain

Required content:

  • Originating Brain
  • Receiving Brain
  • reason for transfer
  • task summary
  • source material
  • decision required
  • expected output
  • urgency
  • risk
  • validation requirement
  • final authority

Rule

Brain-to-Brain handoffs must preserve ownership and the reason for transfer.

  1. AI Employee To Human Handoff

This occurs when an AI Employee prepares work for human review, approval or action.

Examples:

  • MCR page draft for Martyn
  • developer brief for M
  • offer verdict for Martyn
  • validation report for HeadOffice
  • client report for business-owner approval

Required content:

  • clear verdict
  • work completed
  • evidence
  • decision required
  • risk
  • validation status
  • what not to touch
  • next action
  • expected outcome

Rule

A human should not need to reconstruct the work from scratch.

  1. Human To AI Employee Handoff

This occurs when Martyn, M or another authorised person transfers work to an AI Employee.

Examples:

  • course files uploaded
  • code status supplied
  • current screenshot supplied
  • save point provided
  • full page output requested
  • approval or rejection supplied

Required content:

  • task request
  • source material
  • current system state
  • known constraints
  • desired output
  • authority
  • urgency
  • forbidden areas

Rule

Human instructions should be converted into a structured Work Unit before serious execution.

  1. Model To Model Handoff

This occurs when work moves from one model or capability route to another.

Examples:

  • extraction model → reasoning model
  • primary reasoning model → independent reviewer
  • failed model → Rescue Agent
  • text model → multimodal model
  • hosted model → local private model

Required content:

  • original task
  • Work Unit ID
  • prior model role
  • output produced
  • evidence
  • assumptions
  • failure history
  • validation status
  • reason for model change
  • expected next contribution

Rule

The next model must receive the work state, not merely the last response.

  1. Primary Agent To Independent Reviewer Handoff

This occurs when output requires separate review.

Required content:

  • original task
  • source material
  • output produced
  • producing Employee and model
  • validation standard
  • risk level
  • disputed or high-impact claims
  • required review decision

The reviewer should return:

  • pass
  • pass with conditions
  • revise
  • reject
  • escalate

Rule

The independent reviewer must not simply agree with the producing route.

  1. Failed Agent To Rescue Agent Handoff

This occurs after the failure threshold is reached.

Required content:

  • original task
  • expected outcome
  • exact failure
  • failure count
  • chronological attempts
  • tools and models used
  • outputs
  • validation failures
  • current state
  • applicable Canon
  • inherited assumptions
  • risk
  • next verification gate

Rule

A Rescue Agent must diagnose independently and use a materially different approach.

  1. Queue To Workflow Handoff

This occurs when a queue item becomes active work.

Examples:

  • Newsletter Queue Review → Routed Action
  • Course Absorption item → MCR page draft
  • Offer Intake item → Research task
  • Brain Room message → AI Manager task

Required content:

  • queue item ID
  • status
  • priority
  • Owning Brain
  • Assigned Employee
  • next workflow
  • due timing
  • validation status

Rule

Queue items must not become action without ownership and next-step clarity.

  1. Workflow To Dashboard Handoff

This occurs when output becomes visible on a dashboard.

Required content:

  • signal
  • Brain
  • action type
  • priority
  • urgency
  • owner
  • status
  • reason
  • source
  • validation status
  • next step

Rule

Dashboard handoffs must be short, specific, current and action-ready.

  1. Workflow To MCR Handoff

This occurs when output is ready to become a canonical MCR page or update.

Required content:

  • exact page title
  • exact parent
  • document type
  • source and reason
  • full page output
  • related standards
  • duplication check
  • validation status
  • Change Impact Declaration
  • registry requirements
  • Change Log requirements

Rule

MCR handoffs must be complete and ready to save without structural guessing.

  1. Workflow To Developer Handoff

This occurs when work is handed to M or another developer.

Required content:

  • exact site
  • exact system area
  • exact file or screen
  • current visible state
  • current save point
  • exact required action
  • replacement or insertion location
  • complete file output where required
  • what not to touch
  • tests
  • expected result
  • rollback
  • verification method

Rule

If M has to guess, the handoff is invalid.

  1. Workflow To Client Handoff

This applies to future AIBS systems.

Required content:

  • plain-language summary
  • source
  • business meaning
  • recommended action
  • risk
  • approval requirement
  • next step
  • owner
  • expected outcome

Rule

Client handoffs must reduce confusion.

  1. Persistent Agent To Human Handoff

This occurs when a scheduled or background AI Employee surfaces an alert, decision or exception.

Required content:

  • agent identity
  • owner
  • Work Unit or monitoring ID
  • trigger or schedule
  • last run
  • current state
  • alert
  • source evidence
  • failure count
  • action required
  • urgency
  • shutdown status

Rule

Persistent agents must surface actionable exceptions, not unfiltered background noise.

  1. External Knowledge Engine To Reasoning Agent Handoff

This occurs when retrieved evidence is passed to a reasoning Employee.

Required content:

  • retrieval query
  • source collection
  • filters
  • source authority
  • freshness
  • provenance
  • retrieved evidence
  • conflicting sources
  • evidence gaps
  • client or Brain boundary

Rule

Retrieval output is evidence input.

It is not a final decision.

  1. Session To Session Handoff

This occurs when work continues across sessions, chats or interfaces.

Required content:

  • session objective
  • work completed
  • work attempted but incomplete
  • decisions
  • failures
  • current save point
  • current page or record
  • open issues
  • exact next action
  • durable knowledge committed

Rule

A new session must not be expected to reconstruct the operational state from raw conversation history.

Standard Handoff Package

Every important MWMS handoff should include the following fields.

Handoff ID:

Work Unit ID:

Handoff Title:

Handoff Type:

Source:

Source Authority:

Originating Brain:

Sending AI Employee Or Role:

Sending Model Or Capability Route:

Receiving Brain Or Role:

Receiving Model Or Capability Route:

Reason For Handoff:

Work Completed:

Output Produced:

Evidence And Source References:

Context To Preserve:

Assumptions:

Failure History:

Validation Status:

Independent Review Status:

Risk Level:

Tool Permission Status:

Required Next Action:

Owner Of Next Action:

Expected Output:

Expected Business Outcome:

Due Timing:

Logging Requirement:

Knowledge Commitment Requirement:

Acceptance Status:

Open Issues:

Closure Requirement:

This template may be shortened for low-risk work.

It must not be shortened for:

  • high-risk work
  • developer work
  • MCR work
  • finance
  • compliance
  • security
  • client-facing work
  • persistent-agent work
  • rescue handoffs
  • live-system work

Handoff Acceptance

The receiving party should assign one of the following acceptance states.

Accepted

The handoff is complete and work may continue.

Accepted With Conditions

The handoff may continue if stated conditions are met.

Needs Clarification

Important information is missing.

Rejected

The handoff is invalid, misrouted, unsafe or outside scope.

Escalated

Ownership, authority or risk requires higher review.

Parked

The handoff is valid but should not proceed now.

Rule

A receiver must not silently continue from an incomplete handoff.

Handoff Quality Checklist

Before a handoff is accepted, check:

  • Is the Handoff ID present?
  • Is the Work Unit ID present?
  • Is the Handoff Type clear?
  • Is the source identified?
  • Is source authority clear?
  • Is the Originating Brain clear?
  • Is the sender clear?
  • Is the receiver clear?
  • Is the reason for handoff stated?
  • Is completed work summarised?
  • Is the output included or referenced?
  • Is evidence preserved?
  • Is important context preserved?
  • Are assumptions visible?
  • Is failure history included where relevant?
  • Is validation status clear?
  • Is independent review status clear?
  • Is risk assigned?
  • Are tool permissions clear?
  • Is the next action specific?
  • Is the next owner clear?
  • Is the expected output clear?
  • Is the business outcome clear?
  • Is human review required?
  • Is logging required?
  • Is knowledge commitment required?
  • Are open issues visible?
  • Can the receiver continue without guessing?

A handoff that fails this checklist should be corrected before work continues.

Handoff Failure Modes

MWMS must watch for:

  • work passed with no owner
  • output passed without source
  • source authority missing
  • context lost between stages
  • validation status unclear
  • independent review omitted
  • failure history omitted
  • risk not stated
  • tool permission unclear
  • next action vague
  • human review skipped
  • wrong receiving Brain
  • wrong receiving Employee
  • wrong model route
  • completed work not stated
  • work duplicated
  • dashboard item has no action
  • M receives vague instructions
  • course output moves to MCR without duplication check
  • offer moves forward without required review
  • client receives unsafe output
  • handoff treated as completion
  • important learning not logged
  • persistent-agent alert has no owner
  • session handoff has no save point
  • external knowledge loses provenance
  • receiver does not confirm acceptance

Any handoff showing these failures should be paused and corrected.

Handoff Failure And Rescue Rule

A failed handoff includes:

  • receiver cannot act safely
  • critical context is missing
  • source cannot be verified
  • ownership is unclear
  • wrong Brain or Employee receives the work
  • validation status is misrepresented
  • task state is inconsistent
  • prior failure history is hidden
  • output and claimed completion do not match

At the first material handoff failure:

  • stop downstream action
  • identify missing or incorrect fields
  • return for correction
  • preserve the original handoff

At the second materially identical failure without verified improvement:

  • stop the originating route
  • create a rescue packet
  • route to a different Employee, model, Brain or human
  • define a new verification gate

Rule

Repeated handoff failure must trigger rescue, not endless transfer attempts.

Application To Newsletter Intelligence

A good newsletter handoff includes:

  • newsletter source
  • extracted signal
  • primary Brain
  • Supporting Brains
  • recommended action
  • confidence
  • urgency
  • priority
  • validation status
  • destination
  • human-review requirement

Newsletter handoff rule:

Signals must not be routed unless they are specific, useful and owned.

Application To Course Absorption

A good course handoff includes:

  • course name
  • lesson or block
  • source files
  • extracted principle
  • MWMS relevance
  • existing-page comparison
  • affected Brain
  • proposed update or new page
  • what to ignore
  • duplication status
  • validation status
  • current save point
  • exact next action

Course handoff rule:

Course material must not become MCR structure unless the handoff explains why it improves MWMS and how it fits current Canon.

Application To Offer Evaluation

A good offer handoff includes:

  • offer
  • network
  • verdict
  • source evidence
  • mechanism
  • traffic fit
  • compliance risk
  • finance notes
  • experimentation fit
  • next Brain
  • next decision
  • human authority

Offer handoff rule:

No offer should move toward spend without required Research, Finance, Compliance, Experimentation and HeadOffice handoffs.

Application To Brain Room

A good Brain Room handoff includes:

  • message summary
  • request source
  • request type
  • Owning Brain
  • Assigned AI Employee
  • Work Unit
  • required context
  • risk
  • next action
  • destination
  • status

Brain Room handoff rule:

Brain Room must not become a graveyard of useful but unstructured discussion.

Application To M Developer Work

A good developer handoff includes:

  • exact site
  • plugin or module
  • exact file or screen
  • current visible state
  • current save point
  • exact required change
  • complete output where required
  • what not to touch
  • test steps
  • rollback
  • expected result
  • verification

Developer handoff rule:

If M has to guess, the handoff is not valid.

Application To MCR Page Creation

A good MCR handoff includes:

  • exact page title
  • exact parent
  • document type
  • status
  • source of truth
  • full page output
  • related pages
  • duplication check
  • registry update need
  • Change Log
  • Change Impact Declaration

MCR handoff rule:

A page draft is not ready for MCR until placement, purpose, relationship, validation and change impact are clear.

Application To Persistent Agents

A good persistent-agent handoff includes:

  • agent
  • owner
  • trigger
  • current status
  • source evidence
  • failure count
  • last error
  • risk
  • recommended action
  • urgency
  • next owner
  • shutdown status

Persistent-agent handoff rule:

Background agents must hand off exceptions clearly and remain stoppable.

Application To External Knowledge Systems

A good external knowledge handoff includes:

  • retrieval query
  • source collection
  • filters
  • authority
  • freshness
  • provenance
  • evidence
  • conflicts
  • gaps
  • intended reasoning task

External knowledge handoff rule:

Evidence must remain traceable from retrieval through reasoning and reporting.

Application To AIBS Client Systems

A good client handoff includes:

  • plain-language finding
  • source
  • business meaning
  • recommended action
  • risk
  • approval
  • next step
  • owner
  • outcome

Client handoff rule:

Client-facing handoffs must reduce confusion and preserve human authority.

Application To Session Closure

A good session handoff includes:

  • session objective
  • completed work
  • incomplete work
  • pages or records changed
  • decisions
  • failures
  • current save point
  • open issues
  • exact next action
  • knowledge committed

Session handoff rule:

The next session should be able to resume without repeating completed work or reconstructing the state.

Handoff Validation

Every important handoff should be validated before transfer.

Validation checks:

  • source present
  • source authority clear
  • sender clear
  • receiver clear
  • ownership clear
  • reason clear
  • completed work clear
  • output attached
  • context preserved
  • risk stated
  • validation status accurate
  • failure history preserved
  • tool permissions clear
  • next action clear
  • expected outcome clear
  • human review identified
  • logging requirement known
  • receiver can act safely

A handoff should not proceed if the receiving party cannot act safely.

Handoff Logging

Important handoffs should be logged.

A Handoff Log should include:

Handoff ID:

Work Unit ID:

Created Date:

Source:

Originating Brain:

Sending Role:

Receiving Brain Or Role:

Handoff Type:

Status:

Risk Level:

Validation Status:

Failure Count:

Next Action:

Next Owner:

Due Timing:

Acceptance Status:

Outcome:

Completion Status:

Learning Captured:

Closure Date:

Handoff logs support:

  • auditability
  • task tracking
  • dashboard visibility
  • workflow debugging
  • cross-Brain coordination
  • rescue
  • future automation
  • session continuity

Handoff Statuses

Recommended handoff statuses:

  • Draft
  • Ready For Review
  • Sent
  • Received
  • Accepted
  • Accepted With Conditions
  • Needs Clarification
  • In Progress
  • Waiting For Input
  • Waiting For Human Review
  • Rescue Required
  • Completed
  • Parked
  • Rejected
  • Escalated
  • Logged
  • Closed
  • Archived

Rule

Status must describe actual handoff state.

Cross-Interface Continuity Rule

Where work moves between:

  • chat
  • Brain Room
  • dashboard
  • MCR
  • task system
  • email
  • remote command channel
  • local agent
  • hosted agent
  • client interface

the handoff must preserve:

  • Work Unit ID
  • current status
  • source
  • owner
  • context
  • validation
  • next action
  • failure history
  • output destination

Rule

A change of interface must not reset the task or erase its history.

Tool And Permission Handoff Rule

Where work moves to an Employee with tool access, the handoff must state:

  • approved tool
  • permission level
  • approved functions
  • approved data
  • prohibited actions
  • client boundary
  • human approval requirement
  • logging
  • revocation method

Rule

Task transfer does not automatically transfer tool authority.

Human Review Rule

Human review is required for handoffs involving:

  • MCR
  • Canon
  • developer implementation
  • paid traffic
  • finance
  • compliance
  • live systems
  • public content
  • client-facing output
  • Brain architecture
  • high-risk automation
  • unclear ownership
  • M’s active build
  • credentials
  • destructive actions
  • unresolved reviewer disagreement

Automation Readiness Rule

Handoffs should be automated only when:

  • sender is known
  • receiver is known
  • schema is stable
  • required fields are defined
  • validation status is available
  • risk is assigned
  • next action is predictable
  • failure cases are known
  • acceptance can be recorded
  • human-review rules exist
  • logging exists
  • rescue exists
  • the handoff adds operational value

Rule

Do not automate handoffs that humans cannot perform clearly.

Persistent Handoff Rule

Persistent and scheduled handoffs must define:

  • owner
  • trigger
  • source
  • duplicate prevention
  • failure threshold
  • alert destination
  • escalation
  • cost boundary
  • shutdown
  • expiry or review date

Rule

Persistent handoffs must not become uncontrolled alert streams.

Governance Role

HeadOffice owns the MWMS AI Employee Handoff Protocol.

HeadOffice is responsible for:

  • defining handoff standards
  • ensuring Brain-to-Brain transfers preserve context
  • ensuring AI Employee handoffs remain controlled
  • governing model-to-model transfers
  • governing rescue handoffs
  • ensuring high-risk handoffs require review
  • protecting M from vague developer handoffs
  • protecting MCR from incomplete page handoffs
  • protecting dashboards from weak routed outputs
  • governing persistent-agent handoffs
  • maintaining visibility over cross-Brain work
  • ensuring handoffs support business outcomes
  • ensuring session continuity

Individual Brains may define specialised handoff formats.

Those formats must align with this protocol.

Relationship To SIT Brain

SIT Brain may:

  • verify Handoff Package completeness
  • detect missing ownership
  • detect validation-state mismatch
  • detect missing failure history
  • verify reviewer independence
  • block unsafe transfers
  • verify tool-permission boundaries
  • enforce rescue after repeated failure
  • detect false completion
  • inspect persistent-agent handoffs
  • verify outcome and closure
  • require clarification before progression

Relationship To Data Brain

Data Brain supports:

  • Handoff IDs
  • Work Unit links
  • source provenance
  • context records
  • status history
  • validation records
  • acceptance records
  • failure history
  • owner changes
  • outcome records
  • closure records
  • archival and retention

Relationship To Other MWMS Standards

This protocol 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 AI Agent Failure Handling And Escalation Protocol
  • MWMS Independent Model Review And Rescue Routing Framework
  • MWMS AI Agent Memory And Context Framework
  • MWMS External Knowledge Engine And Reasoning Agent Separation Framework
  • MWMS AI Work Session Closure And Knowledge Commitment Protocol
  • MWMS AI Tool Permission And Access Framework
  • MWMS AI Observability Metadata Standard
  • MWMS Messy Input Normalization Framework
  • MWMS Agentic Reporting Standard
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS AI Output Standard Full File Delivery Rule
  • 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
  • MWMS Course Absorption Operating Rule
  • MWMS Opportunity System Operating Protocol
  • AIBS Brain Blueprint

Drift Protection

This protocol protects MWMS from:

  • losing context between stages
  • passing work without ownership
  • treating transfer as completion
  • routing output without validation status
  • sending vague developer instructions
  • moving course material into MCR without value or duplication checks
  • moving offers toward testing without review
  • sending dashboard items with no action
  • cross-Brain confusion
  • skipped human review
  • missing transfer logs
  • duplicated work
  • lost Brain Room value
  • client confusion
  • automation before manual clarity
  • model transfers without task state
  • rescue without failure history
  • persistent-agent alerts without owners
  • external knowledge without provenance
  • tool authority drifting during transfer
  • session changes erasing task continuity

Handoff Drift Signals

MWMS should watch for:

  • no Handoff ID
  • no Work Unit ID
  • source unclear
  • no source authority
  • sender unclear
  • receiver unclear
  • ownership unclear
  • no reason for transfer
  • completed work missing
  • output missing
  • context missing
  • assumptions hidden
  • failure history omitted
  • validation status unclear
  • risk missing
  • tool permissions missing
  • next action vague
  • next owner missing
  • expected outcome unclear
  • no acceptance status
  • no logging
  • no closure
  • same handoff repeatedly rejected
  • interface change resets the task
  • transfer is reported as completion

Rule

Handoff drift must be corrected before work progresses.

Minimum Compliance Standard

An important handoff is compliant only when it defines:

  • Handoff ID
  • Work Unit ID
  • Handoff Type
  • source
  • source authority
  • Originating Brain
  • sending role
  • receiving role
  • reason
  • completed work
  • output
  • evidence
  • context
  • assumptions
  • failure history where relevant
  • validation status
  • review status
  • risk
  • tool permissions
  • next action
  • next owner
  • expected output
  • expected outcome
  • logging
  • knowledge commitment
  • acceptance status
  • open issues
  • closure requirement

Architectural Intent

The architectural intent of the MWMS AI Employee Handoff Protocol is to make MWMS work transferable without losing control.

As MWMS grows, work will move between:

  • Brains
  • AI Employees
  • models
  • humans
  • dashboards
  • queues
  • task systems
  • MCR
  • persistent agents
  • external knowledge engines
  • client workflows
  • interfaces
  • sessions

The system must preserve meaning as work moves.

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

  • What is being handed off?
  • What Work Unit does it belong to?
  • Where did it come from?
  • Who completed the previous step?
  • Which model or tools were used?
  • What was completed?
  • What failed?
  • What still needs to happen?
  • Who owns the next step?
  • What context must be preserved?
  • What evidence supports the work?
  • What risks exist?
  • Has it been validated?
  • Was independent review required?
  • What permissions transfer?
  • Where does it go next?
  • Was it accepted?
  • What should be logged?
  • What should MWMS learn?
  • How will the handoff close?

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

Strategic Summary

The v1.1 upgrade expands the MWMS AI Employee Handoff Protocol from a context-preservation template into a complete transfer-control standard.

The upgraded protocol now governs:

  • Handoff IDs
  • Work Unit continuity
  • source authority
  • model-to-model transfer
  • independent-review handoffs
  • rescue packets
  • failure history
  • persistent-agent handoffs
  • external knowledge provenance
  • tool-permission transfer
  • acceptance confirmation
  • cross-interface continuity
  • session-to-session continuity
  • outcome and closure requirements

The key shift is:

A handoff is not complete when output is sent.

It is complete only when the receiver has the correct source, context, authority, risk, validation state, next action and ownership needed to continue safely.

Final Rule

AI work must not move between Brains, Employees, models, systems or humans without a complete and accepted handoff.

No source, no traceability.

No owner, no accountability.

No context, no continuity.

No validation state, no trust.

No failure history, no valid rescue.

No permission boundary, no tool transfer.

No next action, no operational movement.

No acceptance, no completed handoff.

No closure, no reliable continuity.

Change Log

Version: v1.1
Date: 2026-06-17
Author: HeadOffice

Change:

Updated the MWMS AI Employee Handoff Protocol using the AI Automations by Jack block covering multi-model orchestration, independent review, rescue routing, persistent agents, external knowledge systems, tool governance and session closure.

Added:

  • Handoff ID
  • Work Unit ID
  • Handoff Type
  • Source Authority
  • Sending AI Employee Or Role
  • Sending Model Or Capability Route
  • Receiving Model Or Capability Route
  • Evidence And Source References
  • Assumptions
  • Failure History
  • Independent Review Status
  • Tool Permission Status
  • Expected Output
  • Expected Business Outcome
  • Knowledge Commitment Requirement
  • Acceptance Status
  • Open Issues
  • Closure Requirement

Added handoff types for:

  • Model To Model Handoff
  • Primary Agent To Independent Reviewer Handoff
  • Failed Agent To Rescue Agent Handoff
  • Persistent Agent To Human Handoff
  • External Knowledge Engine To Reasoning Agent Handoff
  • Session To Session Handoff

Added:

  • Handoff Acceptance
  • Handoff Failure And Rescue Rule
  • Cross-Interface Continuity Rule
  • Tool And Permission Handoff Rule
  • Persistent Handoff Rule
  • Relationship To SIT Brain
  • Relationship To Data Brain
  • Handoff Drift Signals
  • Minimum Compliance Standard

Expanded:

  • Standard Handoff Package
  • Handoff Quality Checklist
  • Handoff Failure Modes
  • Handoff Logging
  • Handoff Statuses
  • Application To Course Absorption
  • Application To Developer Work
  • Application To MCR
  • Application To AIBS Client Systems
  • Governance Role
  • Drift Protection
  • Architectural Intent
  • Final Rule

Corrected canonical references from AI Business Systems Brain to AIBS Brain.

Purpose of update:

To evolve the MWMS AI Employee Handoff Protocol from a basic context-and-ownership transfer template into the complete continuity standard for cross-Brain, cross-model, rescue, persistent-agent, external-knowledge, developer, MCR and session-to-session handoffs across MWMS and future AIBS client systems.

Version: v1.0
Date: Initial Draft
Author: HeadOffice

Change:

Created the MWMS AI Employee Handoff Protocol as the standard for transferring work between AI Employees, Brains, humans, queues, dashboards, task systems, MCR, developers and future AIBS client workflows.

Change Impact Declaration

This v1.1 update expands the AI Employee Handoff Protocol from a basic transfer standard into a complete continuity, acceptance, rescue, model-routing, permission, provenance and closure framework.

Pages Created

None

Pages Updated

MWMS AI Employee Handoff Protocol

Pages Deprecated

None

Standalone Pages Not Created

MWMS Model To Model Handoff Standard

MWMS Rescue Agent Handoff Protocol

MWMS Persistent Agent Handoff Standard

MWMS Session To Session Handoff Protocol

MWMS External Knowledge Handoff Standard

MWMS Handoff Acceptance Standard

MWMS Tool Permission Transfer Protocol

Registries Requiring Update

HeadOffice Page Registry

MWMS Canon Index

MWMS Course Absorption Decision Registry

Canon Version Update Required

No

Change Log Entry Required

Yes

Strategic Absorption Result

MWMS gains a stronger handoff protocol that preserves Work Unit identity, source authority, model route, context, evidence, failure history, tool boundaries, validation state, ownership, expected outcome and closure across AI Employees, Brains, humans, persistent agents, knowledge systems and future AIBS client workflows.

END OF FULL FILE OUTPUT