MWMS MCR

MWMS AI Multi Agent Role Design Framework

System: MWMS
Document Type: Framework
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, Course Absorption System, Newsletter Intelligence, 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 Multi Agent Role Design Framework.

This framework explains how MWMS designs AI Employees as specialized roles inside a coordinated AI workforce.

MWMS must not rely on one large general AI role to perform every task.

Complex AI work should be separated into clear specialist roles.

A single AI Employee should not usually be expected to:

  • research
  • analyze
  • write
  • validate
  • route
  • manage dependencies
  • approve outcomes
  • handle failures
  • perform tool-enabled action

all in the same uncontrolled pass.

That creates risk, weak output, hidden assumptions, poor validation, and unclear ownership.

The purpose of multi-agent role design is to ensure that each AI Employee has a clear job, clear boundary, clear input, clear output, clear validation requirement, and clear handoff destination.

This framework helps MWMS build an AI workforce that behaves more like a governed company and less like a pile of prompts.

Scope

This framework applies to all AI Employee role design across MWMS.

This includes roles used by:

  • HeadOffice Brain
  • Brain Room
  • AI Manager
  • AI Employee Router
  • Task Executor systems
  • Dev Console
  • Newsletter Intelligence
  • Course Absorption
  • Opportunity System
  • Affiliate Brain
  • Research Brain
  • Experimentation Brain
  • Finance Brain
  • Content Brain
  • Ads Brain
  • Sales Brain
  • Conversion Brain
  • Operations Brain
  • AI Business Systems Brain
  • future AIBS client systems

This framework applies whenever MWMS creates, reviews, updates, splits, merges, routes, validates, or deploys AI Employee roles.

This framework does not authorize new technical development by itself.

It defines the role design logic that must be proven manually before automation or plugin/UI build work.

Core Definition

Multi Agent Role Design is the process of separating AI work into specialist roles that each perform a defined part of a larger workflow.

A multi-agent system may include roles such as:

  • Researcher
  • Analyst
  • Writer
  • Reviewer
  • Validator
  • Router
  • Coordinator
  • Tool Operator
  • Failure Handler
  • Outcome Logger

Each role has a different purpose.

The goal is not to create more AI Employees for the sake of it.

The goal is to prevent role confusion and improve output quality.

A role should exist only when it creates clearer ownership, better output, safer validation, better routing, or a stronger business outcome.

Core Principle

The core principle of this framework is:

Do not ask one AI Employee to do every job if the work requires separate thinking modes.

Research is different from analysis.

Analysis is different from writing.

Writing is different from reviewing.

Reviewing is different from approving.

Approving is different from executing.

When these jobs are collapsed into one vague AI role, MWMS loses control.

When these jobs are separated correctly, MWMS gains:

  • clearer workflow stages
  • better source grounding
  • cleaner handoffs
  • stronger validation
  • safer tool use
  • better accountability
  • better outcome tracking
  • less hallucination risk
  • easier future automation

Multi Agent Role Archetypes

MWMS recognizes the following core role archetypes.

1. Researcher Agent

Primary Function:
Find, collect, verify, organize, and ground information.

Core Responsibilities:

  • gather source material
  • identify useful facts
  • distinguish evidence from claims
  • collect source references
  • identify missing information
  • flag uncertainty
  • prepare research notes for analysis

Typical Inputs:

  • user request
  • research question
  • offer page
  • newsletter item
  • course material
  • external source
  • uploaded file
  • current system evidence
  • market data
  • competitor information

Typical Outputs:

  • research brief
  • source-grounded notes
  • evidence table
  • uncertainty list
  • further research request
  • source verification summary

Must Not Do:

  • make final business decisions
  • approve spend
  • create final copy from weak evidence
  • treat vendor claims as verified facts
  • overstate confidence
  • bypass analysis or validation

Best Used For:

  • offer evaluation
  • market research
  • tool research
  • compliance checks
  • current source verification
  • competitor analysis
  • product intelligence
  • client research

2. Analyst Agent

Primary Function:
Interpret information, identify patterns, explain meaning, and prepare decision logic.

Core Responsibilities:

  • review research evidence
  • identify patterns
  • compare options
  • assess implications
  • evaluate risks
  • convert facts into business meaning
  • recommend possible decisions
  • prepare structured reasoning for review

Typical Inputs:

  • research brief
  • source-grounded notes
  • raw metrics
  • offer information
  • experiment results
  • finance assumptions
  • newsletter signals
  • course extraction notes

Typical Outputs:

  • analysis report
  • decision support brief
  • risk assessment
  • opportunity assessment
  • comparison table
  • recommendation draft
  • strategic meaning summary

Must Not Do:

  • invent missing evidence
  • overrule source limitations
  • write final client output without review
  • approve high-risk decisions alone
  • bypass Finance, Compliance, or HeadOffice review where required

Best Used For:

  • offer analysis
  • market opportunity analysis
  • newsletter signal interpretation
  • experiment learning
  • finance scenario meaning
  • course framework interpretation
  • AIBS client process review

3. Writer Agent

Primary Function:
Turn structured inputs into usable outputs.

Core Responsibilities:

  • transform notes into reports
  • draft MCR page outputs
  • write summaries
  • create briefs
  • produce scripts
  • format documentation
  • improve readability
  • follow required structure

Typical Inputs:

  • research notes
  • analyst findings
  • validated outline
  • context pack
  • required format
  • source material
  • user instruction
  • MWMS standards

Typical Outputs:

  • full page output
  • report draft
  • developer brief
  • newsletter intelligence summary
  • course absorption report
  • client report draft
  • dashboard item draft
  • copy draft
  • documentation draft

Must Not Do:

  • invent facts to fill gaps
  • hide uncertainty
  • make unsupported claims
  • change source meaning
  • bypass validation
  • publish or send final output without approval
  • treat writing polish as proof of correctness

Best Used For:

  • MCR documentation
  • course absorption outputs
  • HeadOffice reports
  • AIBS client drafts
  • developer briefs
  • campaign briefs
  • content drafts

4. Reviewer Agent

Primary Function:
Review output quality before use.

Core Responsibilities:

  • check completeness
  • check clarity
  • check source grounding
  • identify missing sections
  • flag weak logic
  • check whether the output answers the task
  • ensure output format matches destination
  • recommend accept, revise, park, reject, or escalate

Typical Inputs:

  • draft report
  • MCR page output
  • developer brief
  • offer evaluation
  • newsletter intelligence record
  • dashboard item
  • client report draft
  • validation checklist

Typical Outputs:

  • review notes
  • revision request
  • accept/revise/reject recommendation
  • quality score
  • missing section list
  • escalation note

Must Not Do:

  • approve high-risk final action alone
  • ignore source grounding
  • replace validation where formal validation is required
  • assume polish equals correctness
  • let weak output move forward because it sounds good

Best Used For:

  • MCR page review
  • report review
  • developer handoff review
  • dashboard item review
  • client report review
  • course absorption output review

5. Validator Agent

Primary Function:
Apply formal validation checks to outputs, handoffs, workflows, or records.

Core Responsibilities:

  • apply validation checklist
  • check task alignment
  • verify required fields
  • check Brain routing
  • check risk level
  • check source grounding
  • check tool permission boundary
  • check human review requirement
  • produce pass/fail/needs revision verdict

Typical Inputs:

  • AI output
  • task instruction
  • source material
  • validation level
  • output destination
  • relevant standards

Typical Outputs:

  • validation report
  • pass/fail decision
  • revision instruction
  • risk note
  • escalation recommendation
  • failure log trigger

Must Not Do:

  • validate its own high-risk output without review
  • ignore missing source material
  • approve live system action
  • approve spend
  • bypass HeadOffice for critical decisions

Best Used For:

  • high-risk reports
  • MCR page drafts
  • developer briefs
  • dashboard candidates
  • offer evaluations
  • finance outputs
  • client-facing drafts

6. Router Agent

Primary Function:
Send work to the correct Brain, AI Employee, queue, dashboard, human, or archive.

Core Responsibilities:

  • identify owning Brain
  • identify supporting Brains
  • classify work type
  • decide route options
  • prepare handoff
  • avoid orphaned work
  • ensure routing follows authority rules
  • send weak or unclear work to Parking System or review

Typical Inputs:

  • normalized input
  • Agentic Work Unit
  • report
  • newsletter signal
  • offer evaluation
  • Brain Room message
  • validation result
  • handoff package

Typical Outputs:

  • routing recommendation
  • handoff package
  • queue item
  • parking recommendation
  • escalation route
  • archive decision

Must Not Do:

  • route high-risk work without validation
  • create downstream tasks without approval where required
  • route unclear work as if certain
  • bypass HeadOffice
  • ignore Brain ownership rules

Best Used For:

  • Brain Room task conversion
  • newsletter intelligence routing
  • offer evaluation routing
  • cross-Brain workflows
  • AI Manager routing
  • HeadOffice review queues

7. Coordinator Agent

Primary Function:
Manage sequence, dependencies, timing, and assembly across multiple roles.

Core Responsibilities:

  • sequence work stages
  • assign role order
  • track dependencies
  • ensure required inputs exist
  • identify blocked stages
  • manage multi-agent brief generation
  • prevent roles from working out of order
  • assemble final output after review

Typical Inputs:

  • workflow plan
  • Agentic Work Unit
  • role assignments
  • dependency map
  • handoff packages
  • validation results
  • source and context pack

Typical Outputs:

  • workflow sequence
  • role assignment plan
  • dependency checklist
  • brief assembly plan
  • handoff map
  • blocker report
  • final assembly package

Must Not Do:

  • make specialist decisions without specialist input
  • skip validation to save time
  • allow roles to work from missing inputs
  • hide blockers
  • force workflow forward when dependencies are unresolved

Best Used For:

  • multi-agent brief generation
  • AIBS client workflows
  • HeadOffice reports
  • complex offer evaluation
  • research-to-writing workflows
  • developer handoff preparation
  • AI Manager task orchestration

8. Tool Operator Agent

Primary Function:
Use approved tools inside defined permission boundaries.

Core Responsibilities:

  • operate approved tool actions
  • follow tool permission record
  • keep access within boundary
  • prepare tool output for validation
  • stop on permission or schema issues
  • log tool use where required

Typical Inputs:

  • approved tool permission record
  • task instruction
  • input payload
  • required schema
  • workflow stage
  • stop conditions

Typical Outputs:

  • tool output
  • record insert
  • draft output
  • parsed data
  • analysis result
  • tool-use log
  • failure report if tool fails

Must Not Do:

  • use unapproved tools
  • exceed access level
  • write without permission
  • delete without explicit approval
  • trigger external action without approval
  • claim tool use that did not happen

Best Used For:

  • Gmail read workflows
  • Supabase controlled writes
  • WordPress page list review
  • document processing
  • data analysis
  • dashboard preparation
  • future client tools

9. Failure Handler Agent

Primary Function:
Detect, contain, classify, escalate, and learn from failures.

Core Responsibilities:

  • identify failure type
  • contain possible damage
  • stop unsafe continuation
  • classify severity
  • identify likely cause
  • route escalation
  • create failure log
  • recommend Kaizen action

Typical Inputs:

  • failed output
  • tool error
  • validation failure
  • ambiguous input
  • wrong route
  • dashboard noise
  • developer ambiguity
  • partial workflow failure

Typical Outputs:

  • failure log
  • containment action
  • escalation note
  • correction recommendation
  • Kaizen action
  • revalidation request

Must Not Do:

  • hide failure
  • continue unsafe workflow
  • pretend failed output is usable
  • escalate everything without classification
  • ignore repeated failure patterns

Best Used For:

  • Make.com errors
  • output failures
  • wrong Brain routing
  • failed validation
  • ambiguous task handling
  • developer handoff failures
  • automation stop conditions

10. Outcome Logger Agent

Primary Function:
Record what useful outcome was created by AI work.

Core Responsibilities:

  • identify output vs outcome
  • score outcome value
  • record decision made
  • record action created
  • record risk reduced
  • record learning captured
  • identify next owner
  • support AI Employee usefulness review

Typical Inputs:

  • completed report
  • completed handoff
  • validation result
  • failure correction
  • MCR page created
  • task completed
  • routed action
  • user confirmation

Typical Outputs:

  • outcome log record
  • score
  • business value summary
  • next step
  • learning note
  • workflow improvement signal

Must Not Do:

  • overstate value
  • count output volume as progress
  • hide weak outcomes
  • treat every document as high-value
  • skip learning capture

Best Used For:

  • course absorption outcomes
  • newsletter routing outcomes
  • developer support results
  • offer evaluation decisions
  • failure-to-learning outcomes
  • AIBS client value reporting

Multi Agent Design Models

MWMS may use different multi-agent role designs depending on workflow complexity.

Model 1: Linear Specialist Chain

Use when work follows a clear sequence.

Example:

Researcher → Analyst → Writer → Reviewer → Validator → Router

Best for:

  • research reports
  • offer evaluations
  • AIBS client reports
  • strategic briefs
  • course absorption outputs

Strength:

  • clear sequence
  • easy to validate
  • strong handoff control

Risk:

  • slow if overused for simple tasks

Model 2: Hub And Spoke Coordinator Model

Use when one Coordinator manages several specialist roles.

Example:

Coordinator assigns Researcher, Analyst, Writer, Reviewer, then assembles final output.

Best for:

  • complex briefs
  • cross-Brain reports
  • HeadOffice intelligence summaries
  • multi-source client reports

Strength:

  • good for dependencies
  • strong management layer

Risk:

  • Coordinator can become too powerful if not bounded

Model 3: Reviewer Gate Model

Use when outputs need strict checking before moving forward.

Example:

Writer → Reviewer → Validator → Human Review

Best for:

  • MCR pages
  • developer handoffs
  • client-facing reports
  • finance outputs
  • compliance-sensitive outputs

Strength:

  • protects quality

Risk:

  • can slow workflow if used on low-risk tasks

Model 4: Parallel Research Model

Use when multiple information streams must be reviewed separately.

Example:

Researcher A reviews market
Researcher B reviews competitor
Researcher C reviews compliance
Analyst combines findings

Best for:

  • offer evaluation
  • market research
  • tool comparison
  • compliance review

Strength:

  • better coverage

Risk:

  • requires strong synthesis and conflict handling

Model 5: Human In The Loop Model

Use when final decision must remain human-owned.

Example:

AI Employees prepare evidence, analysis, draft, and review → Martyn or HeadOffice approves.

Best for:

  • MCR canon
  • M developer instructions
  • paid traffic decisions
  • finance decisions
  • public content
  • client-facing outputs

Strength:

  • safest for high-risk work

Risk:

  • requires clear review package

Model 6: Manual Proof Before Automation Model

Use when a workflow may later become automated.

Example:

Manual role chain → repeated successful outcomes → readiness review → limited automation.

Best for:

  • Newsletter Intelligence
  • Brain Room task conversion
  • documentation pipeline
  • offer evaluation workflow
  • AIBS client reporting

Strength:

  • prevents premature automation

Risk:

  • requires discipline to avoid building too early

Role Separation Rules

Rule 1: Research And Writing Should Usually Be Separate

The role that gathers evidence should not always be the same role that writes the final output.

This prevents weak evidence from being polished into confident language.

Rule 2: Writing And Reviewing Should Be Separate For Important Work

The role that writes should not be the only role that reviews.

This is especially important for:

  • MCR pages
  • developer briefs
  • client reports
  • finance outputs
  • compliance-sensitive work
  • public content

Rule 3: Validation Is Not The Same As Review

Review checks quality.

Validation checks readiness against standards.

Both may be needed.

Rule 4: Routing Should Happen After Classification And Validation

Do not route unclear or unvalidated work into downstream systems.

Rule 5: Tool Use Requires Tool Permission

A Tool Operator Agent cannot use a tool just because the workflow would benefit.

Tool access must match the Tool Permission Record.

Rule 6: Coordinators Manage Flow, Not Truth

A Coordinator may manage sequence and dependencies.

It should not replace specialist evidence, analysis, or validation.

Rule 7: High-Risk Work Requires Human Review

Human review remains required before:

  • MCR canon changes
  • developer handoff to M
  • live system changes
  • Supabase writes outside approved workflow
  • paid traffic decisions
  • finance decisions
  • public content
  • client-facing delivery
  • high-risk automation

Rule 8: Roles Should Be Split Only When It Improves Control

Do not create unnecessary AI Employees.

Split a role when it improves:

  • quality
  • validation
  • source grounding
  • handoff clarity
  • risk control
  • outcome value

Rule 9: Roles Should Be Merged When They Create Noise

If two AI Employees produce overlapping outputs with no added control, merge them.

Rule 10: HeadOffice Owns Role Governance

Individual Brains may propose AI Employees, but HeadOffice governs cross-Brain, high-risk, tool-enabled, automation-related, and client-facing role design.

Multi Agent Workflow Pattern

The default MWMS multi-agent workflow pattern is:

  1. Capture Input
  2. Normalize Input
  3. Assign Role Chain
  4. Attach Context Pack
  5. Research Or Extract
  6. Analyze
  7. Draft
  8. Review
  9. Validate
  10. Route
  11. Log Outcome Or Failure
  12. Capture Learning

This pattern should be simplified for low-risk work and strengthened for high-risk work.

Role Design Record Template

Use this template when designing or reviewing a multi-agent role structure.

Workflow Name

Field:
Workflow Name:

Workflow Purpose

Field:
Workflow Purpose:

Owning Brain

Field:
Owning Brain:

Supporting Brains

Field:
Supporting Brains:

Workflow Risk Level

Field:
Workflow Risk Level:

Recommended values:

  • Low
  • Medium
  • High
  • Critical

Required Role Chain

Field:
Required Role Chain:

Example:

  • Researcher
  • Analyst
  • Writer
  • Reviewer
  • Validator
  • Router

Role 1 — Name And Function

Field:
Role 1 — Name And Function:

Role 1 — Required Input

Field:
Role 1 — Required Input:

Role 1 — Required Output

Field:
Role 1 — Required Output:

Role 1 — Handoff Destination

Field:
Role 1 — Handoff Destination:

Role 2 — Name And Function

Field:
Role 2 — Name And Function:

Role 2 — Required Input

Field:
Role 2 — Required Input:

Role 2 — Required Output

Field:
Role 2 — Required Output:

Role 2 — Handoff Destination

Field:
Role 2 — Handoff Destination:

Additional Roles Required

Field:
Additional Roles Required:

Reviewer Required

Field:
Reviewer Required: Yes / No

Validator Required

Field:
Validator Required: Yes / No

Human Review Required

Field:
Human Review Required: Yes / No

Tool Operator Required

Field:
Tool Operator Required: Yes / No

Coordinator Required

Field:
Coordinator Required: Yes / No

Handoff Requirements

Field:
Handoff Requirements:

Dependency Notes

Field:
Dependency Notes:

Failure Triggers

Field:
Failure Triggers:

Expected Outcome

Field:
Expected Outcome:

Role Design Status

Field:
Role Design Status:

Recommended values:

  • Proposed
  • Draft
  • Manual Use
  • Proven Manual Use
  • Assisted Use
  • Controlled Automation Candidate
  • Parked
  • Deprecated
  • Retired

Quick Use Version

Workflow Name:
Workflow Purpose:
Owning Brain:
Supporting Brains:
Workflow Risk Level:
Required Role Chain:
Role 1 — Name And Function:
Role 1 — Required Input:
Role 1 — Required Output:
Role 1 — Handoff Destination:
Role 2 — Name And Function:
Role 2 — Required Input:
Role 2 — Required Output:
Role 2 — Handoff Destination:
Additional Roles Required:
Reviewer Required:
Validator Required:
Human Review Required:
Tool Operator Required:
Coordinator Required:
Handoff Requirements:
Dependency Notes:
Failure Triggers:
Expected Outcome:
Role Design Status:

Example 1: Course Absorption Multi Agent Role Design

Workflow Name:
Course Absorption Multi Agent Workflow

Workflow Purpose:
Extract reusable MWMS system value from course material and decide whether to absorb, update, park, ignore, or reject.

Owning Brain:
HeadOffice Brain

Supporting Brains:
AI Business Systems Brain, relevant specialist Brain, Operations Brain

Workflow Risk Level:
Medium

Required Role Chain:

  1. Input Normalizer
  2. Course Researcher / Extractor
  3. Analyst
  4. Writer
  5. Reviewer
  6. Validator
  7. Router

Role 1 — Name And Function:
Input Normalizer — cleans course transcript, identifies source completeness, removes noise, and marks gaps.

Role 1 — Required Input:
Course file, transcript, lesson title, current course context.

Role 1 — Required Output:
Cleaned input summary and extracted elements.

Role 1 — Handoff Destination:
Course Extractor.

Role 2 — Name And Function:
Course Extractor — identifies frameworks, procedures, rules, and MWMS system value.

Role 2 — Required Input:
Cleaned input and course context.

Role 2 — Required Output:
Extraction report with absorb/park/reject recommendation.

Role 2 — Handoff Destination:
Analyst.

Additional Roles Required:
Writer creates page output if justified. Reviewer checks clarity and duplication risk. Validator applies AI Output Validation Checklist. Router sends to MCR, Parking System, or relevant Brain.

Reviewer Required:
Yes

Validator Required:
Yes

Human Review Required:
Yes before MCR save

Tool Operator Required:
No unless file analysis tools are used.

Coordinator Required:
Optional for large course blocks.

Handoff Requirements:
Each stage must preserve source, verdict, duplication risk, and next destination.

Dependency Notes:
Writer should not create page output until extractor and analyst confirm system value.

Failure Triggers:
Weak material, duplicate page risk, incomplete source, unclear Brain mapping, M build impact.

Expected Outcome:
MWMS gains useful system structure or rejects weak material.

Role Design Status:
Manual Use

Example 2: Newsletter Intelligence Multi Agent Role Design

Workflow Name:
Newsletter Intelligence Multi Agent Workflow

Workflow Purpose:
Turn newsletters into business-relevant signals while rejecting noise.

Owning Brain:
HeadOffice Brain

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

Workflow Risk Level:
Medium

Required Role Chain:

  1. Intake Cleaner
  2. Signal Extractor
  3. Analyst
  4. Reviewer
  5. Router
  6. Outcome Logger

Role 1 — Name And Function:
Intake Cleaner — removes newsletter clutter and checks body completeness.

Role 1 — Required Input:
Sender, subject, body, snippet, date.

Role 1 — Required Output:
Cleaned newsletter input.

Role 1 — Handoff Destination:
Signal Extractor.

Role 2 — Name And Function:
Signal Extractor — identifies concrete business-relevant signals.

Role 2 — Required Input:
Cleaned newsletter input.

Role 2 — Required Output:
Signal record with primary Brain, supporting Brains, action type, priority, urgency, and recommended action.

Role 2 — Handoff Destination:
Reviewer / Router.

Additional Roles Required:
Analyst interprets business meaning for high-value signals. Reviewer checks dashboard readiness. Router sends to Queue Review, Dashboard, Routed Actions, Parking, or Reject.

Reviewer Required:
Yes for dashboard or routed action items.

Validator Required:
Yes for high-priority or compliance-sensitive signals.

Human Review Required:
Yes before downstream action.

Tool Operator Required:
Yes if Gmail/Supabase workflow is used.

Coordinator Required:
No for normal signals; yes for complex cross-Brain signals.

Handoff Requirements:
Signal must not move downstream without source, Brain ownership, priority, and review status.

Dependency Notes:
Routed Actions should not be created from generic newsletter noise.

Failure Triggers:
Incomplete email body, generic insight, wrong Brain routing, urgent signal without verification.

Expected Outcome:
Useful signal captured and routed; weak news rejected or parked.

Role Design Status:
Assisted Use

Example 3: Developer Support Multi Agent Role Design

Workflow Name:
Developer Support Multi Agent Workflow

Workflow Purpose:
Prepare safe, exact, evidence-based developer instructions for M.

Owning Brain:
HeadOffice Brain

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

Workflow Risk Level:
High

Required Role Chain:

  1. Evidence Extractor
  2. Analyst
  3. Writer
  4. Reviewer
  5. Validator
  6. Human Reviewer

Role 1 — Name And Function:
Evidence Extractor — identifies exact visible evidence from screenshots, files, and current instructions.

Role 1 — Required Input:
Screenshot, file content, user request, current save point.

Role 1 — Required Output:
Evidence summary and known gaps.

Role 1 — Handoff Destination:
Analyst.

Role 2 — Name And Function:
Analyst — determines likely issue, required change, and risk.

Role 2 — Required Input:
Evidence summary and known gaps.

Role 2 — Required Output:
Developer issue analysis and change plan.

Role 2 — Handoff Destination:
Writer.

Additional Roles Required:
Writer drafts exact developer handoff. Reviewer checks clarity. Validator checks file path, what not to touch, test steps, and risk. Human reviewer approves before sending to M.

Reviewer Required:
Yes

Validator Required:
Yes

Human Review Required:
Always

Tool Operator Required:
No unless approved file/system access is used.

Coordinator Required:
Optional

Handoff Requirements:
Must include exact site, exact file path where available, exact change, what not to touch, test steps, expected result, and save point.

Dependency Notes:
Writer cannot draft implementation instructions if evidence extractor cannot confirm current state.

Failure Triggers:
Missing file path, missing file content, unclear screenshot, live system risk, M would need to guess.

Expected Outcome:
M can act safely without ambiguity.

Role Design Status:
Manual Use

Example 4: Offer Evaluation Multi Agent Role Design

Workflow Name:
Offer Evaluation Multi Agent Workflow

Workflow Purpose:
Evaluate affiliate, CPA, CPL, PPL, or digital product offers before test planning.

Owning Brain:
Affiliate Brain

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

Workflow Risk Level:
High

Required Role Chain:

  1. Offer Intake Extractor
  2. Researcher
  3. Analyst
  4. Finance Reviewer
  5. Experimentation Reviewer
  6. Validator
  7. Router

Role 1 — Name And Function:
Offer Intake Extractor — extracts offer name, niche, claim, funnel type, payout, mechanism, proof, and compliance concerns.

Role 1 — Required Input:
Offer page, network details, available affiliate metrics.

Role 1 — Required Output:
Offer intake summary.

Role 1 — Handoff Destination:
Researcher / Analyst.

Role 2 — Name And Function:
Researcher — verifies market, vendor, competitor, current data, and evidence.

Role 2 — Required Input:
Offer intake summary and research questions.

Role 2 — Required Output:
Research evidence brief.

Role 2 — Handoff Destination:
Analyst.

Additional Roles Required:
Analyst prepares verdict. Finance reviews break-even and exposure. Experimentation reviews test design. Validator checks evidence, risk, and routing. Router sends to Research, Finance, Experimentation, Parking, or Rejected Archive.

Reviewer Required:
Yes

Validator Required:
Yes

Human Review Required:
Yes before any spend or test movement.

Tool Operator Required:
Possibly, if current web/network data is required.

Coordinator Required:
Yes for serious offers.

Handoff Requirements:
Offer cannot move toward spend without Finance and Experimentation review.

Dependency Notes:
Vendor claims must not be treated as evidence. Finance assumptions must be explicit.

Failure Triggers:
Missing payout, weak proof, compliance risk, finance assumptions unclear, traffic fit poor.

Expected Outcome:
Strong offers move to research/finance/test planning; weak offers are parked or rejected before wasting spend.

Role Design Status:
Manual Use

Example 5: AIBS Client Report Multi Agent Role Design

Workflow Name:
AIBS Client Report Multi Agent Workflow

Workflow Purpose:
Turn client input into safe, useful, business-friendly client reports.

Owning Brain:
AI Business Systems Brain

Supporting Brains:
HeadOffice Brain, Operations Brain, relevant client workflow Brain

Workflow Risk Level:
High

Required Role Chain:

  1. Client Input Normalizer
  2. Researcher / Evidence Extractor
  3. Analyst
  4. Writer
  5. Reviewer
  6. Validator
  7. Human Approver

Role 1 — Name And Function:
Client Input Normalizer — cleans client data, checks scope, identifies sensitive content, and marks gaps.

Role 1 — Required Input:
Approved client source material and client workflow context.

Role 1 — Required Output:
Cleaned client input summary.

Role 1 — Handoff Destination:
Researcher / Analyst.

Role 2 — Name And Function:
Analyst — extracts business meaning, risks, actions, and decision points.

Role 2 — Required Input:
Cleaned client input and client context.

Role 2 — Required Output:
Client business meaning report.

Role 2 — Handoff Destination:
Writer.

Additional Roles Required:
Writer creates client-friendly report draft. Reviewer checks clarity. Validator checks source grounding, privacy, risk, and claims. Human Approver approves before delivery.

Reviewer Required:
Yes

Validator Required:
Yes

Human Review Required:
Always before client delivery.

Tool Operator Required:
Only with approved client data permissions.

Coordinator Required:
Yes for complex client workflows.

Handoff Requirements:
Client report must include findings, business meaning, risk notes, recommended action, and approval status.

Dependency Notes:
Client context must remain isolated. No cross-client assumptions.

Failure Triggers:
Sensitive data outside scope, unclear approval gate, unsupported claims, privacy risk, missing source context.

Expected Outcome:
Client receives useful, safe, reviewed business reporting.

Role Design Status:
Future Draft Only

Role Design Readiness Checklist

Before approving a multi-agent role design, check:

  1. Is the workflow purpose clear?
  2. Is the owning Brain clear?
  3. Are supporting Brains listed?
  4. Is risk level assigned?
  5. Is the required role chain justified?
  6. Is each role necessary?
  7. Is any role too broad?
  8. Is any role duplicated?
  9. Does each role have required input?
  10. Does each role have required output?
  11. Does each role have a handoff destination?
  12. Are dependencies clear?
  13. Is reviewer required?
  14. Is validator required?
  15. Is human review required?
  16. Is tool operation required?
  17. Are tool permissions defined if tools are involved?
  18. Is Coordinator needed?
  19. Are failure triggers defined?
  20. Is expected outcome clear?
  21. Is automation premature?
  22. Does this affect M’s active build?
  23. Is a developer brief required?
  24. Can the role chain be simplified?
  25. Is the role design ready only for manual use?

If several answers are unclear, the role design is not ready.

Common Multi Agent Role Design Failure Modes

Multi-agent role design has failed if:

  1. One AI Employee is asked to do every job.
  2. Roles are split without a real reason.
  3. Research and writing are mixed in high-risk work.
  4. Writing and reviewing are performed by the same role for important output.
  5. Validation is skipped.
  6. Tool use is allowed without permission.
  7. Handoffs are vague.
  8. Dependencies are not clear.
  9. Coordinator role becomes too powerful.
  10. Human review is skipped.
  11. Output has no destination.
  12. Failure triggers are missing.
  13. The role chain creates more complexity than value.
  14. M receives vague developer instructions.
  15. Client-facing work lacks approval gates.

Manual Use Rule

This framework should be used manually before role design becomes technical infrastructure.

Manual use helps MWMS learn:

  • which role chains are truly useful
  • which roles can be combined
  • which roles must stay separate
  • where handoffs fail
  • where validation is needed
  • where Coordinator control helps
  • where tool permissions matter
  • which role chains may later become AI Manager or AI Employee Router logic
  • which role chains should stay manual

Manual role proof comes before automation.

Future Plugin Or UI Relevance

This framework may later support:

  • AI Employee role registry
  • AI Manager role assignment logic
  • AI Employee Router role matching
  • Brain Room task-to-role mapping
  • Task Executor multi-agent workflow sequencing
  • HeadOffice AI Workforce Dashboard
  • Multi-agent brief generation workflow
  • AIBS client role-chain templates

Possible future fields:

  • role_design_id
  • workflow_name
  • workflow_purpose
  • owning_brain
  • supporting_brains
  • workflow_risk_level
  • required_role_chain
  • role_name
  • role_function
  • role_input
  • role_output
  • handoff_destination
  • reviewer_required
  • validator_required
  • human_review_required
  • tool_operator_required
  • coordinator_required
  • handoff_requirements
  • dependency_notes
  • failure_triggers
  • expected_outcome
  • role_design_status
  • created_at
  • updated_at

No technical build is authorized by this framework alone.

Governance Role

HeadOffice owns the MWMS AI Multi Agent Role Design Framework.

HeadOffice is responsible for:

  • approving multi-agent role design principles
  • preventing vague AI Employee roles
  • preventing role sprawl
  • ensuring roles are split only when useful
  • ensuring high-risk work has review and validation roles
  • ensuring tool use belongs to approved Tool Operator roles
  • ensuring Coordinators do not become uncontrolled authority
  • ensuring human review gates remain in place
  • protecting M’s active build areas
  • protecting MCR source of truth
  • protecting future AIBS client systems

Individual Brains may propose specialized AI roles, but HeadOffice governs cross-Brain, high-risk, tool-enabled, automation-related, and client-facing role design.

Relationship To Other MWMS Standards

This framework supports and must align with:

  • MWMS AI Agent Operations Core
  • MWMS AI Agent Skill Library Framework
  • MWMS AI Plugin Orchestration Framework
  • MWMS AI Documentation Automation Pipeline Framework
  • MWMS AI Employee Role Card Standard
  • MWMS AI Employee Role Card Template
  • MWMS AI Employee Capability Stack Framework
  • MWMS AI Employee Capability Stack Template
  • MWMS AI Tool Permission And Access Framework
  • MWMS AI Tool Permission Record Template
  • MWMS AI Agent Memory And Context Framework
  • MWMS AI Agent Context Pack Template
  • MWMS Agentic Work Unit Standard
  • MWMS Agentic Work Unit Template
  • MWMS AI Workflow Pipeline Standard
  • MWMS AI Workflow Pipeline Checklist
  • MWMS AI Output Validation Standard
  • MWMS AI Output Validation Checklist
  • MWMS Agentic Reporting Standard
  • MWMS Agentic Reporting Template
  • MWMS AI Employee Handoff Protocol
  • MWMS AI Employee Handoff Package Template
  • MWMS AI Agent Failure Handling And Escalation Protocol
  • MWMS AI Agent Failure Log Record
  • MWMS AI Agent Outcome Measurement Framework
  • MWMS AI Agent Outcome Log Record
  • MWMS AI Agent Deployment Readiness Checklist
  • MWMS AI Agent Deployment Readiness Review Template
  • MWMS AI Workforce Governance Model
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS Supabase Event Schema
  • AI Business Systems Brain Blueprint

This framework adds the specialist role design layer to the MWMS AI Agent Operations Core.

Drift Protection

This framework protects MWMS from the following forms of drift:

  1. Treating one general AI as the whole workforce
  2. Asking one role to research, analyze, write, review, validate, and route at once
  3. Creating unnecessary AI role sprawl
  4. Mixing research and writing in high-risk work
  5. Mixing writing and validation in high-risk work
  6. Allowing Coordinators to become uncontrolled decision-makers
  7. Skipping human review on high-risk outputs
  8. Assigning tools to roles without permissions
  9. Sending work through vague handoffs
  10. Automating role chains before manual proof
  11. Creating multi-agent complexity without outcome value
  12. Losing accountability between roles
  13. Failing to define dependencies
  14. Creating client-facing AI roles without safety gates
  15. Letting role design outrun governance

Any AI workflow with unclear role separation should remain manual, draft, or parked.

Architectural Intent

The architectural intent of the MWMS AI Multi Agent Role Design Framework is to help MWMS operate like a coordinated AI workforce.

MWMS is not building one super-prompt.

MWMS is building a system where Brains act like departments and AI Employees act like defined roles.

The long-term goal is that every serious AI workflow can answer:

  • Which roles are required?
  • Why are those roles separate?
  • What does each role receive?
  • What does each role produce?
  • Where does each role hand off?
  • Who reviews the output?
  • Who validates the output?
  • Who routes the result?
  • Where is human review required?
  • What dependencies exist?
  • What failure triggers stop the workflow?
  • What outcome should the role chain create?

When MWMS can answer those questions, AI work becomes coordinated, accountable, and safer to scale.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Multi Agent Role Design Framework to define how MWMS separates AI work into specialist AI Employee roles.

This framework establishes core role archetypes, including Researcher, Analyst, Writer, Reviewer, Validator, Router, Coordinator, Tool Operator, Failure Handler, and Outcome Logger.

It defines multi-agent design models, role separation rules, workflow patterns, role design record templates, examples, readiness checks, failure modes, future plugin/UI relevance, governance role, drift protection, and architectural intent.

It establishes that MWMS should be built as a coordinated AI workforce, not one general AI doing every job.