System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.2
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, 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-20
Source / Origin: MWMS AI Multi Agent Role Design Framework v1.1 + AI Automations by Jack — Claude Agent Teams, Claude Skills 2.0, AntiGravity Skills, multi-model specialist routing, parallel execution, Agent Manager, persistent project instructions, external knowledge systems and controlled agentic operating systems block
MWMS Classification: Multi-Agent Role Design Framework / AI Workforce Role Architecture / Specialist Agent Separation Standard
Primary Brain: HeadOffice Brain
Supporting Brains: MWMS Brain, Automation Brain, Operations Brain, Data Brain, Risk Brain, Compliance Brain, SIT Brain, AIBS Brain
Related Pages: MWMS AI Agent Orchestration Framework, MWMS AI Agent Orchestration Framework
MWMS AI Agent Skill Library Framework, MWMS AI Skill Builder And Audit Protocol, MWMS AI Employee Capability Stack Framework, MWMS AI Employee Role Card Standard, MWMS AI Tool Permission And Access Framework, MWMS AI Agent Memory And Context Framework, MWMS Independent Model Review And Rescue Routing Framework, MWMS External Knowledge Engine And Reasoning Agent Separation Framework, MWMS AI Observability Metadata Standard, MWMS AI Agent Outcome Measurement Framework
MWMS AI Observability Metadata Standard
Source Evidence: The existing framework defines how MWMS separates complex work into specialist AI Employee roles with clear inputs, outputs, boundaries, validation requirements and handoff destinations. The newly absorbed material strengthens the framework with explicit agent-team formation, shared-task and isolated-task boundaries, role-level Skill bundles, structured agent-to-agent communication, parallel specialist execution, synthesis ownership, dynamic and fixed team patterns, capability-aware model assignment, dependency checks, cost limits, team shutdown controls and team-level outcome verification.
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 specialised 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 normally be expected to:
research
analyse
write
review
validate
route
approve
use tools
manage dependencies
resolve failures
record outcomes
commit knowledge
all in one uncontrolled pass.
That creates:
hidden assumptions
weak source grounding
poor validation
role confusion
unclear ownership
self-approval
tool-risk concentration
repeated failure loops
false completion
The purpose of multi-agent role design is to ensure each AI Employee has:
a clear job
a clear authority boundary
defined input
defined output
required context
approved tools
validation requirements
a handoff destination
failure triggers
an expected business outcome
This framework helps MWMS operate like a governed company rather than a collection 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
Automation Brain
Risk Brain
Compliance Brain
SIT Brain
AIBS Brain
future AIBS client systems
This framework applies whenever MWMS:
creates an AI Employee
updates an AI Employee role
splits an overloaded role
merges overlapping roles
designs a multi-agent workflow
assigns models to roles
assigns tools to roles
creates an independent review path
creates a rescue path
creates persistent or scheduled agents
creates client-facing role chains
prepares a workflow for automation
This framework does not authorise technical development.
It defines the role architecture that must be proven before automation or implementation.
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 workflow may include roles such as:
Planner
Researcher
External Knowledge Retriever
Analyst
Builder
Writer
Reviewer
Validator
Router
Coordinator
Tool Operator
Persistent Monitor
Failure Handler
Rescue Agent
Outcome Logger
Knowledge Commitment Agent
Each role exists for a distinct reason.
The goal is not to create more AI Employees.
The goal is to create the minimum role separation required for:
stronger quality
safer execution
clearer accountability
better validation
reliable handoffs
improved business outcomes
A role should exist only when it improves control or value.
Core Principle
The core principle of this framework is:
Do not ask one AI Employee to perform every thinking mode when the workflow requires separation.
Research is different from analysis.
Analysis is different from planning.
Planning is different from building.
Building is different from reviewing.
Reviewing is different from validating.
Validation is different from approval.
Approval is different from execution.
Execution is different from outcome verification.
When these functions are collapsed into one role, MWMS loses control.
When they are separated correctly, MWMS gains:
clearer workflow stages
stronger source grounding
more independent review
safer tool use
cleaner handoffs
reduced hallucination risk
better failure recovery
clearer accountability
stronger outcome measurement
easier future automation
Minimum Necessary Role Separation Rule
MWMS should use the fewest roles needed to maintain control.
Too few roles can create:
self-review
authority concentration
weak validation
overloaded instructions
Too many roles can create:
slow workflows
unnecessary handoffs
duplicated effort
role sprawl
higher cost
coordination overhead
Rule:
Separate roles where doing so materially improves quality, independence, safety or accountability.
Do not split roles merely because multi-agent systems are fashionable.
Role Identity Requirements
Every AI Employee role must define:
Role Name
Owning Brain
Role Purpose
Primary Function
Required Inputs
Required Context
Required Skills
Required Model Or Capability
Approved Tools
Tool Permission Boundary
Required Outputs
Handoff Destination
Validation Requirement
Human Review Requirement
Forbidden Actions
Failure Triggers
Expected Outcome
Outcome Evidence
Assigned Skills
Model Route
Dependencies
Team Communication Contract
Parallel Execution Permission
Cost Boundary
Shutdown Owner
Role Status
A role is not operationally ready when these elements remain unclear.
Agent Team Definition
An AI Agent Team is a governed group of specialist AI Employees working toward one defined Work Unit outcome.
An Agent Team must have:
one Work Unit
one Owning Brain
one workflow purpose
one expected business outcome
defined specialist roles
clear authority boundaries
shared and isolated context rules
structured communication
defined handoffs
a synthesis owner
validation
failure thresholds
cost boundaries
shutdown controls
Team Rule
A group of agents is not a team merely because they run at the same time.
A formal Agent Team exists only when responsibilities, communication, authority, synthesis and completion are defined.
Fixed And Dynamic Agent Teams
Fixed Team
A stable role chain used repeatedly for the same workflow.
Examples:
Course Absorption Team
Newsletter Intelligence Team
Offer Evaluation Team
AIBS Client Reporting Team
Dynamic Team
A temporary team assembled for one specific Work Unit.
Examples:
a specialist review of a new market
a high-risk architecture decision
a one-off client diagnostic
a complex rescue operation
Fixed teams should be used when:
the workflow repeats
the role chain is proven
inputs and outputs are stable
handoffs are known
Dynamic teams should be used when:
the work is unusual
specialists vary by task
risk or complexity is temporary
a permanent team would create unnecessary role sprawl
Team Formation Rule
Use a fixed team for repeated proven work.
Use a dynamic team for exceptional or changing work.
Do not create permanent AI Employees for every temporary specialist need.
Team Formation Protocol
Before forming an Agent Team, define:
Team ID
Work Unit ID
Workflow Name
Owning Brain
Supporting Brains
Team Type
Team Purpose
Expected Outcome
Risk Level
Required Roles
Optional Roles
Synthesis Owner
Human Authority
Shared Context
Role-Isolated Context
Required Skills
Model Routes
Tool Permissions
Dependencies
Parallel Tasks
Sequential Tasks
Validation Gates
Failure Threshold
Rescue Route
Cost Limit
Shutdown Owner
Completion Criteria
Team Status
Team formation decisions:
Use One AI Employee
Use Existing Fixed Team
Assemble Dynamic Team
Add Independent Reviewer
Add Specialist Role
Reduce Team
Merge Roles
Reject Team Design
Team Formation Rule
If one qualified AI Employee can complete the task safely and efficiently, do not create a team.
Role Skill Bundle
Each role may require a defined Skill bundle.
A Role Skill Bundle should identify:
required Skills
optional Skills
active Skill versions
Skill scope
Skill dependencies
automatic invocation allowed
forbidden Skills
fallback procedure
Examples:
Course Extractor may require:
Course Absorption Value Extraction Skill
Source Material To AI Skill Conversion Skill
Evidence Separation Skill
MCR Comparison Analyst may require:
MCR Duplicate Risk Check Skill
Page Naming Validation Skill
Parent And Ownership Check Skill
Role Skill Rule
Skills provide procedure.
Roles provide responsibility and authority.
A Skill must not silently expand the role beyond its approved Capability Stack.
Shared Context And Context Isolation
Agent Teams need both shared context and role-specific context.
Shared context may include:
Work Unit objective
Owning Brain
source material
current Canon
risk level
completion criteria
common definitions
Role-specific context may include:
specialist instructions
limited source subsets
tool credentials through approved interfaces
client-specific data
independent-review material
rescue history
Context isolation is required where:
review independence matters
client boundaries apply
sensitive data is involved
specialist focus would be weakened by irrelevant information
one role should not inherit another role’s assumptions
Context Rule
Share enough context to coordinate the team.
Isolate enough context to preserve focus, independence, privacy and client boundaries.
Agent-To-Agent Communication Contract
Agent-to-agent communication must be structured.
Each handoff or message should state:
Work Unit ID
Team ID
Sender Role
Receiver Role
Task Objective
Input Used
Work Completed
Evidence
Assumptions
Unresolved Issues
Validation Status
Required Next Action
Authority Required
Prohibited Actions
Deadline Or Sequence Position
Communication Rule
Agent chatter is not authority.
Only structured handoffs, approved records and validated outputs should advance the workflow.
Parallel Specialist Execution
Parallel execution may be used where specialist tasks are independent.
Possible parallel roles:
Market Researcher
Compliance Researcher
Finance Researcher
Technical Researcher
Creative Reviewer
Evidence Validator
Parallel execution must define:
shared input
separate questions
non-overlapping responsibilities
expected output format
completion deadline
synthesis owner
conflict rule
cost limit
Parallel Rule
No parallel team should begin without a synthesis owner and conflict-resolution method.
Parallel work should reduce elapsed time or improve independent coverage.
It should not create duplicated analysis or unmanaged disagreement.
Synthesis Owner
The Synthesis Owner combines specialist outputs into one governed result.
The Synthesis Owner must:
review every required specialist output
preserve disagreements
separate evidence from recommendation
identify missing work
resolve format differences
apply current Canon
prepare the combined result
route unresolved conflicts
The Synthesis Owner must not:
erase minority risk findings
invent consensus
override specialist evidence without explanation
approve beyond delegated authority
Synthesis Rule
Parallel work is incomplete until synthesis is finished and validated.
Team Cost And Complexity Control
Agent Teams consume:
model usage
tool usage
API quota
human review time
coordination time
storage
logging
maintenance
Team design should define:
expected cost
maximum cost
maximum agents
maximum retries
maximum parallel workers
expected time saving
expected quality gain
stop threshold
Complexity Rule
The team must create more value than its coordination overhead.
If a smaller role chain produces the same result safely, use the smaller chain.
Team Shutdown And Suspension
Every operational Agent Team should define how it can be stopped.
Shutdown triggers may include:
cost limit exceeded
repeated failure
permission violation
client-boundary violation
missing dependency
unsafe tool behaviour
unresolved role conflict
human stop instruction
workflow no longer required
Team shutdown controls may include:
stop new assignments
pause active roles
revoke tool access
freeze outputs
preserve logs
route to human review
trigger rescue
Team Shutdown Rule
Persistent, automated or client-facing teams must be stoppable, observable and revocable.
Multi Agent Role Archetypes
MWMS recognises the following core role archetypes.
Planner Agent
Primary Function:
Convert an objective into a controlled work plan.
Core Responsibilities:
interpret the objective
identify required stages
define role sequence
identify dependencies
define expected outputs
define validation gates
define completion criteria
identify risks
prepare the initial Agentic Work Unit
Typical Inputs:
user objective
Brain request
current context
governing standards
source material
known constraints
Typical Outputs:
structured work plan
task decomposition
role sequence
dependency map
validation plan
expected outcome definition
Must Not Do:
approve its own plan for high-risk work
assume missing authority
assign unavailable tools
begin implementation where planning approval is required
hide unresolved dependencies
Best Used For:
complex course absorption
cross-Brain work
AIBS client workflows
research programmes
multi-stage content production
developer handoff preparation
Researcher Agent
Primary Function:
Find, collect, verify, organise and ground information.
Core Responsibilities:
gather source material
identify useful facts
distinguish evidence from claims
preserve source references
identify missing information
flag uncertainty
prepare evidence for analysis
Typical Inputs:
research question
offer page
newsletter item
course material
uploaded file
approved external source
current system evidence
market data
Typical Outputs:
research brief
source-grounded notes
evidence table
contradiction list
uncertainty list
further research request
Must Not Do:
make final business decisions
approve spend
treat vendor claims as fact
overstate confidence
bypass validation
replace human authority
Best Used For:
offer evaluation
market research
compliance research
current-source verification
competitor research
product intelligence
client research
External Knowledge Retriever Agent
Primary Function:
Retrieve relevant evidence from approved external or internal knowledge systems.
Core Responsibilities:
execute defined retrieval queries
apply source filters
apply client or project filters
preserve provenance
record freshness
separate authoritative from weak sources
identify conflicting evidence
return evidence to the reasoning role
Typical Inputs:
retrieval question
approved source collection
authority requirements
freshness requirements
client boundary
Typical Outputs:
evidence packet
source list
provenance record
conflict record
evidence gap summary
Must Not Do:
make the final decision
present retrieved content as automatic truth
cross client boundaries
retrieve outside approved scope
hide weak-source limitations
Best Used For:
Research Brain
AIBS client knowledge systems
course comparison
policy review
specialist evidence retrieval
persistent market monitoring
External Knowledge Separation Rule:
Retrieval supplies evidence.
Reasoning interprets evidence.
The same role should not automatically retrieve, interpret and approve high-risk conclusions.
Analyst Agent
Primary Function:
Interpret information, identify patterns, assess implications and prepare decision logic.
Core Responsibilities:
review evidence
compare options
assess risks
identify patterns
explain business meaning
expose assumptions
prepare recommendations
identify unresolved questions
Typical Inputs:
research brief
evidence packet
raw metrics
offer information
experiment results
finance assumptions
newsletter signals
course extraction notes
Typical Outputs:
analysis report
decision-support brief
risk assessment
comparison
recommendation draft
strategic meaning summary
Must Not Do:
invent missing evidence
override source limitations
approve high-risk decisions alone
bypass Finance, Compliance, SIT or HeadOffice
treat recommendation as final authority
Best Used For:
offer analysis
market opportunity analysis
experiment interpretation
newsletter signal analysis
course framework analysis
AIBS process assessment
Builder Agent
Primary Function:
Create the defined operational asset, structure, workflow, page, report or implementation artefact.
Core Responsibilities:
follow the approved plan
use validated inputs
create the required structure
preserve required standards
remain within scope
produce testable output
report incomplete areas
Typical Inputs:
approved plan
source material
Context Pack
skill
required output schema
validation criteria
Typical Outputs:
structured report
MCR page draft
workflow specification
content asset
data structure proposal
technical draft where authorised
Must Not Do:
change the approved scope
invent missing requirements
self-approve high-risk output
bypass review
use unapproved tools
claim implementation where only a draft exists
Best Used For:
document creation
workflow creation
structured asset generation
future AIBS deliverables
controlled development support in the correct project
Writer Agent
Primary Function:
Turn structured inputs into clear and usable written outputs.
Core Responsibilities:
convert evidence and analysis into readable form
follow the required document structure
preserve source meaning
expose uncertainty
comply with required formatting
avoid unsupported claims
Typical Inputs:
research notes
analyst findings
approved outline
Context Pack
source material
MWMS standards
Typical Outputs:
full page output
report draft
developer brief
newsletter summary
course absorption report
dashboard item
client report draft
Must Not Do:
invent facts
hide uncertainty
replace evidence with polish
publish without approval
treat writing quality as correctness
Best Used For:
MCR documentation
course absorption
HeadOffice reports
AIBS client reports
campaign briefs
documentation
Reviewer Agent
Primary Function:
Review output quality before use.
Core Responsibilities:
check completeness
check clarity
check task alignment
check source grounding
identify missing sections
challenge weak logic
check destination suitability
recommend accept, revise, park, reject or escalate
Typical Inputs:
draft output
original task
source
review criteria
relevant standards
Typical Outputs:
review notes
revision request
quality score
missing section list
accept/revise/reject recommendation
Must Not Do:
approve high-risk final action alone
ignore source grounding
substitute for formal validation
agree automatically with the producing role
treat polish as proof
Best Used For:
MCR review
report review
developer handoff review
dashboard review
client report review
Independent Reviewer Agent
Primary Function:
Provide genuinely separate challenge and review.
Core Responsibilities:
inspect the original task
inspect source evidence
review the output independently
challenge assumptions
identify material omissions
detect self-confirming logic
issue pass, revise, reject or escalate verdict
Typical Inputs:
original task
source evidence
output
validation requirements
risk level
Typical Outputs:
independent review verdict
challenge notes
material error list
escalation recommendation
Must Not Do:
inherit the producer’s reasoning as unquestioned truth
use the same hidden assumptions
approve merely because another model agreed
replace human approval where required
Best Used For:
MCR
finance
compliance
live systems
client delivery
high-risk offer evaluation
major Brain architecture
Independent Review Rule:
Where meaningful independence is required, use:
a different AI Employee
a different model family
a different specialist Brain
a deterministic check
or a human reviewer
Validator Agent
Primary Function:
Apply formal readiness and compliance checks.
Core Responsibilities:
apply validation checklist
verify required fields
verify source grounding
verify Brain routing
verify risk level
verify permission boundaries
verify review requirements
produce formal pass, fail or revise result
Typical Inputs:
output
original task
validation level
source material
destination
applicable standards
Typical Outputs:
validation report
pass/fail decision
revision instruction
risk note
escalation trigger
Must Not Do:
validate its own high-risk output as final authority
ignore missing sources
approve spend
approve live-system action
bypass HeadOffice
Best Used For:
MCR
developer briefs
dashboard candidates
offer evaluations
finance outputs
client-facing work
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
choose destination
prepare handoff
prevent orphaned work
preserve status
send weak work to review or parking
Typical Inputs:
normalised input
Work Unit
validated output
handoff package
routing rules
Typical Outputs:
routing decision
Handoff Package
queue item
parking recommendation
escalation route
archive decision
Must Not Do:
route high-risk work without validation
create downstream action without authority
treat unclear work as certain
bypass Brain ownership rules
erase unresolved issues
Best Used For:
Brain Room
newsletter routing
offer routing
cross-Brain workflows
AI Manager
HeadOffice queues
Coordinator Agent
Primary Function:
Manage sequence, dependencies and assembly across roles.
Core Responsibilities:
sequence work
assign roles
check prerequisites
track blockers
coordinate handoffs
maintain Work Unit state
assemble final packages
preserve workflow visibility
Typical Inputs:
Work Unit
workflow plan
dependency map
role assignments
Handoff Packages
validation results
Typical Outputs:
workflow sequence
role assignment
blocker report
dependency checklist
assembly package
current-state report
Must Not Do:
replace specialist judgement
approve its own high-risk workflow
skip validation
hide blockers
force work through unresolved dependencies
become uncontrolled decision authority
Best Used For:
complex course blocks
AIBS client workflows
cross-Brain reports
serious offer evaluation
developer handoff preparation
AI Manager orchestration
Tool Operator Agent
Primary Function:
Use approved tools inside defined permission boundaries.
Core Responsibilities:
perform approved actions
verify tool access
follow permission records
preserve logs
stop on schema or permission issues
return tool evidence
report actual outcome
Typical Inputs:
approved task
Tool Permission Record
payload
target
stop conditions
Typical Outputs:
tool result
record
draft
parsed data
execution log
failure report
outcome evidence
Must Not Do:
use unapproved tools
exceed permission
write without authority
delete without approval
trigger external action without approval
claim an action occurred when it did not
Best Used For:
controlled database work
Gmail workflows
WordPress review
document processing
data analysis
approved client tools
Persistent Monitor Agent
Primary Function:
Perform recurring monitoring, scheduled review or background observation.
Core Responsibilities:
run on approved trigger
inspect approved sources
detect material changes
filter noise
preserve last-good state
report exceptions
track failure and cost
remain stoppable
Typical Inputs:
monitoring rule
schedule
approved source
alert threshold
last-known state
cost limit
Typical Outputs:
monitoring report
qualified alert
exception record
no-change record
failure report
Must Not Do:
operate without owner
continue beyond failure threshold
create unreviewed external action
use stale instructions indefinitely
produce repetitive noise
exceed cost boundary
Best Used For:
market monitoring
system health
newsletter feeds
future AIBS monitoring
operational exception detection
Failure Handler Agent
Primary Function:
Detect, contain, classify and escalate failure.
Core Responsibilities:
identify failure type
freeze affected work
contain damage
classify severity
preserve evidence
count repeated failure
route escalation
create Failure Log
recommend correction
Typical Inputs:
failed output
validation failure
tool error
ambiguous input
incorrect route
partial workflow failure
Typical Outputs:
Failure Log
containment action
escalation note
correction recommendation
revalidation request
rescue trigger
Must Not Do:
hide failure
continue unsafe work
reset failure count without progress
treat failed output as usable
escalate without classification
Best Used For:
workflow failure
tool failure
wrong routing
ambiguous developer work
repeated validation failure
Rescue Agent
Primary Function:
Recover work after the normal route reaches its failure threshold.
Core Responsibilities:
receive complete failure history
diagnose independently
identify inherited assumptions
use a materially different approach
narrow scope where necessary
propose recovery or stop decision
define verification gate
capture learning
Typical Inputs:
original Work Unit
source material
previous outputs
failure count
failure evidence
validation results
current state
applicable Canon
Typical Outputs:
rescue diagnosis
alternative approach
corrected output
escalation
stop recommendation
recovery verification package
Must Not Do:
repeat the failed route
hide prior attempts
reset status without evidence
claim recovery without verification
expand scope unnecessarily
Best Used For:
repeated model failure
repeated tool failure
repeated handoff failure
blocked workflows
unresolved ambiguity
Rescue Trigger Rule:
Two materially identical failures without verified progress should stop the original route and trigger rescue.
Specialist Agent
Primary Function:
Perform one narrow domain-specific task inside a larger team.
Core Responsibilities:
apply approved specialist Skill
use only assigned context
produce the required specialist output
state assumptions
flag limits
handoff cleanly
Typical Inputs:
defined specialist question
approved source subset
Role Skill Bundle
output schema
Typical Outputs:
specialist finding
risk note
comparison
recommendation within delegated scope
Must Not Do:
expand the Work Unit
make final cross-domain decisions
override the Synthesis Owner
use tools outside permission
hide uncertainty
Best Used For:
finance review
compliance review
technical review
creative review
market review
data review
Synthesis Agent
Primary Function:
Combine specialist outputs into one coherent decision package.
Core Responsibilities:
collect outputs
preserve disagreements
compare evidence
identify gaps
apply Canon
prepare synthesis
route unresolved conflict
Typical Inputs:
specialist outputs
Work Unit
validation criteria
risk level
Typical Outputs:
synthesis report
combined recommendation
conflict summary
missing-work request
Must Not Do:
invent agreement
erase risk findings
replace human authority
hide missing specialist output
Best Used For:
parallel research
offer evaluation
cross-Brain analysis
AIBS client diagnostics
complex rescue
Outcome Logger Agent
Primary Function:
Record the useful result created by the work.
Core Responsibilities:
separate output from outcome
record decision
record action
record risk reduction
record time or cost effect
record learning
verify outcome status
identify next owner
Typical Inputs:
completed output
validation result
execution evidence
user confirmation
workflow status
Typical Outputs:
Outcome Log
outcome score
business value summary
next action
learning note
Must Not Do:
overstate value
count documents as outcomes
mark unverified results complete
hide weak outcomes
Best Used For:
course absorption
newsletter workflows
developer support
offer decisions
client reporting
failure recovery
Knowledge Commitment Agent
Primary Function:
Commit validated learning to the correct durable MWMS destination.
Core Responsibilities:
verify approval
identify correct destination
check duplication
preserve version and status
update approved knowledge
record what changed
preserve source provenance
create save point where needed
Typical Inputs:
validated output
approval
Change Impact Declaration
destination
source
version information
Typical Outputs:
approved knowledge update
Decision Record
MCR update
learning record
project save point
closure note
Must Not Do:
commit drafts as Canon
overwrite stronger source truth
create duplicates
store unresolved assumptions as fact
commit without approval
Best Used For:
MCR
Brain Canon
Decision Records
failure learning
session save points
future AIBS knowledge systems
Multi Agent Design Models
MWMS may use different role designs depending on complexity.
Model 1 — Linear Specialist Chain
Example:
Planner → Researcher → Analyst → Writer → Reviewer → Validator → Router
Best for:
research reports
offer evaluations
course absorption
AIBS reports
strategic briefs
Strength:
Clear sequence and ownership.
Risk:
Can become slow when applied to trivial work.
Model 2 — Three-Brain Model
The Three-Brain Model separates:
Planner Brain
Defines the objective, plan, sequence, constraints and success conditions.
Builder Brain
Creates the required output or asset.
Reviewer Brain
Challenges the output, checks alignment and determines whether it is ready.
Example:
Planner → Builder → Reviewer → Human Approval
Best for:
content assets
website or application planning
strategic reports
structured documentation
complex deliverables
Strength:
Simple separation between planning, production and review.
Risk:
The Reviewer is not independent if it merely repeats the Planner’s assumptions.
Three-Brain Rule:
The Planner should not build.
The Builder should not approve.
The Reviewer should receive the original objective and source, not only the Builder’s explanation.
Model 3 — Hub And Spoke Coordinator Model
Example:
Coordinator assigns Researcher, Analyst, Writer and Reviewer, then assembles the package.
Best for:
complex briefs
HeadOffice reports
cross-Brain work
multi-source client reports
Strength:
Strong dependency management.
Risk:
Coordinator can become too powerful.
Model 4 — Reviewer Gate Model
Example:
Writer → Reviewer → Validator → Human Review
Best for:
MCR
developer handoffs
client reports
finance
compliance-sensitive outputs
Strength:
Strong quality protection.
Risk:
Unnecessary delay for low-risk tasks.
Model 5 — Parallel Specialist Model
Example:
Market Researcher
Compliance Researcher
Finance Researcher
Technical Researcher
→ Analyst combines findings
Best for:
offer evaluation
market research
tool comparison
client assessment
Strength:
Broad specialist coverage.
Risk:
Requires strong synthesis and conflict control.
Model 6 — Independent Review Model
Example:
Producer Route → Independent Reviewer → Validator → Human Authority
Best for:
high-risk work
disputed conclusions
governance
finance
compliance
client delivery
Strength:
Reduces self-confirmation.
Risk:
False independence if the reviewer inherits the same assumptions.
Model 7 — Rescue Routing Model
Example:
Primary Route → Failure Threshold → Rescue Agent → New Verification Gate
Best for:
repeated failures
model loops
tool failure
unresolved ambiguity
stalled workflows
Strength:
Prevents endless repetition.
Risk:
Rescue role becomes another retry if not materially different.
Model 8 — Persistent Monitoring Model
Example:
Persistent Monitor → Qualifier → Reviewer → Human Action
Best for:
market change
system health
client monitoring
recurring newsletter or data review
Strength:
Ongoing visibility.
Risk:
Noise, cost and stale instructions.
Model 9 — Human In The Loop Model
Example:
AI roles prepare evidence, analysis, draft and review → Martyn or authorised human decides.
Best for:
MCR
developer instructions
paid traffic
finance
public content
client delivery
Strength:
Retains human authority.
Risk:
Requires a clear review package.
Model 10 — Manual Proof Before Automation Model
Example:
Manual role chain → repeated validated outcomes → readiness review → limited automation
Best for:
Newsletter Intelligence
Brain Room task conversion
offer evaluation
documentation workflows
future AIBS services
Strength:
Prevents premature build work.
Risk:
Manual work may remain too long if readiness is never reviewed.
Model 11 — Fixed Specialist Team
Example:
Stable Course Absorption or Newsletter Intelligence role chain.
Best for:
repeated workflows
stable inputs
known validation
predictable handoffs
Strength:
Consistency and easier improvement.
Risk:
Team remains active after the workflow changes.
Model 12 — Dynamic Specialist Team
Example:
Coordinator assembles only the specialists needed for one Work Unit.
Best for:
unusual research
high-value decisions
new client diagnostics
complex rescue
Strength:
Flexibility without permanent role sprawl.
Risk:
Slow setup and unclear authority if formation rules are weak.
Model 13 — Parallel Team With Synthesis
Example:
Several specialist roles work independently, then one Synthesis Agent combines findings.
Best for:
offer evaluation
market analysis
architecture review
client diagnostics
Strength:
Faster coverage and stronger independent viewpoints.
Risk:
Duplicated work, conflict and inflated cost.
Model 14 — Skill-Bundled Role Team
Example:
Each role is assigned a defined set of approved Skills and active versions.
Best for:
repeatable governed workflows
future AIBS packaging
controlled automation
Strength:
Clear procedure and easier auditing.
Risk:
Outdated Skills or hidden dependencies.
Role Separation Rules
Rule 1 — Planning And Building Should Be Separate For Complex Work
The role defining scope and success criteria should not silently change those criteria while building.
Rule 2 — Research And Writing Should Usually Be Separate
This prevents weak evidence from being polished into confident language.
Rule 3 — Writing And Review Should Be Separate For Important Work
The producing role should not be the sole reviewer.
Rule 4 — Review And Validation Are Different
Review checks usefulness and quality.
Validation checks formal readiness against standards.
Rule 5 — Approval And Execution Are Different
The role approving an action should not automatically be the role executing it.
Rule 6 — Routing Follows Classification And Validation
Unclear work should not be routed as operationally ready.
Rule 7 — Tool Use Requires Explicit Permission
Role assignment does not automatically provide tool authority.
Rule 8 — Coordinators Manage Flow, Not Truth
A Coordinator cannot replace specialist evidence or approval.
Rule 9 — High-Risk Work Requires Human Review
Human review remains required for:
MCR
development handoff
live-system change
paid traffic
finance
compliance
public content
client delivery
destructive action
Rule 10 — Rescue Must Be Independent Of The Failed Route
A Rescue Agent must use a materially different approach.
Rule 11 — Persistent Roles Must Be Stoppable
Every persistent role requires:
owner
schedule
cost limit
retry limit
alert path
shutdown control
Rule 12 — Role Splitting Must Improve Control
Do not split roles without a specific benefit.
Rule 13 — Roles Should Be Merged Where They Create Noise
Overlapping roles with no distinct authority or output should be consolidated.
Rule 14 — One Owning Brain Per Role
Supporting Brains may exist.
Ownership must remain singular.
Rule 15 — HeadOffice Owns Role Governance
Individual Brains may propose roles.
HeadOffice governs cross-Brain, high-risk, tool-enabled, automation and client-facing roles
fixed Agent Teams
dynamic Agent Teams
parallel specialist teams
Synthesis Agent roles.
Rule 16 — Every Team Requires A Synthesis Owner
Parallel or multi-specialist work must converge into one governed synthesis point.
Rule 17 — Role Skills Must Be Versioned
Each role must use approved Skill versions within scope.
Rule 18 — Team Communication Must Be Structured
Unstructured agent chatter must not become the operational record.
Rule 19 — Shared Context Must Be Controlled
Roles should receive the minimum complete context required.
Independent reviewers should not inherit producer assumptions unnecessarily.
Rule 20 — Team Cost Must Be Proportionate
Do not use expensive multi-agent teams where one qualified role is sufficient.
Rule 21 — Teams Must Be Stoppable
Persistent, automated and client-facing teams require shutdown and revocation controls.
Individual Brains may propose roles.
HeadOffice governs cross-Brain, high-risk, tool-enabled, automation and client-facing roles.
Default Multi Agent Workflow Pattern
The default pattern is:
Capture Input
→ Normalize Input
→ Define Work Unit
→ Assign Role Chain
→ Assign Role Skill Bundles
→ Define Shared And Isolated Context
→ Define Sequential And Parallel Tasks
→ Confirm Synthesis Owner
→ Attach Context
→ Research Or Retrieve
→ Analyze Or Plan
→ Build Or Draft
→ Review
→ Validate
→ Obtain Human Approval Where Required
→ Execute Or Route
→ Verify Outcome
→ Commit Approved Learning
→ Close
Low-risk work may use a shorter pattern.
High-risk work may require:
independent review
Finance review
Compliance review
SIT verification
Rescue Agent
formal approval
Model Diversity Rule
Different roles may use different models.
Model selection should match:
task complexity
reasoning requirement
context length
privacy
cost
speed
multimodal need
coding need
review independence
Examples:
low-cost model for bulk extraction
stronger reasoning model for analysis
different model family for independent review
local model for sensitive work
deterministic checks for schema validation
Rule:
Do not use model diversity as decoration.
Use it where it improves capability, independence, privacy or cost.
Role Authority Matrix
Each role should be assigned one authority level.
Observe
May inspect and report.
Recommend
May recommend action but not approve.
Draft
May create draft outputs.
Validate
May issue formal readiness result.
Approve
May approve within explicitly delegated scope.
Execute
May perform approved action.
Commit
May write validated knowledge to approved durable destination.
Rule:
No role should assume a higher authority level merely because it has the technical capability.
Role Design Record Template
Role Design ID:
Workflow Name:
Workflow Purpose:
Owning Brain:
Supporting Brains:
Workflow Risk Level:
Expected Business Outcome:
Team Type:
Team ID:
Required Role Chain:
Role Sequence:
Shared Context:
Role-Isolated Context:
Parallel Tasks:
Sequential Tasks:
Synthesis Owner:
Role 1 Name:
Role 1 Archetype:
Role 1 Function:
Role 1 Authority Level:
Role 1 Required Input:
Role 1 Required Context:
Role 1 Required Model Or Capability:
Role 1 Assigned Skills And Versions:
Role 1 Dependencies:
Role 1 Tool Permission:
Role 1 Required Output:
Role 1 Handoff Destination:
Role 1 Forbidden Actions:
Role 1 Failure Triggers:
Role 2 Name:
Role 2 Archetype:
Role 2 Function:
Role 2 Authority Level:
Role 2 Required Input:
Role 2 Required Context:
Role 2 Required Model Or Capability:
Role 2 Assigned Skills And Versions:
Role 2 Dependencies:
Role 2 Tool Permission:
Role 2 Required Output:
Role 2 Handoff Destination:
Role 2 Forbidden Actions:
Role 2 Failure Triggers:
Additional Roles Required:
Independent Reviewer Required:
Validator Required:
Human Review Required:
Tool Operator Required:
Coordinator Required:
Persistent Agent Required:
Rescue Agent Required:
Knowledge Commitment Agent Required:
Handoff Requirements:
Dependency Notes:
Failure Threshold:
Rescue Route:
Outcome Evidence:
Knowledge Commitment Destination:
Team Communication Contract:
Cost Limit:
Maximum Parallel Workers:
Shutdown Owner:
Closure Requirement:
Role Design Status:
Quick Use Version
Role Design ID:
Workflow Name:
Workflow Purpose:
Owning Brain:
Workflow Risk Level:
Expected Business Outcome:
Required Role Chain:
Role Sequence:
Team Type:
Shared And Isolated Context:
Parallel Tasks:
Synthesis Owner:
Each Role Name And Function:
Each Role Authority Level:
Each Role Required Input:
Each Role Required Output:
Each Role Handoff Destination:
Required Model Or Capability:
Assigned Skills And Versions:
Dependencies:
Tool Permissions:
Independent Reviewer Required:
Validator Required:
Human Review Required:
Coordinator Required:
Persistent Agent Required:
Rescue Agent Required:
Failure Threshold:
Rescue Route:
Outcome Evidence:
Knowledge Commitment Destination:
Cost Limit:
Shutdown Owner:
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 and decide whether to update, create, park, ignore or reject.
Owning Brain:
HeadOffice Brain
Supporting Brains:
AIBS Brain, Operations Brain and relevant specialist Brains
Workflow Risk Level:
Medium
Required Role Chain:
Input Normalizer
→ Course Extractor
→ MCR Comparison Analyst
→ Writer
→ Reviewer
→ Validator
→ Human Review
→ Knowledge Commitment Agent
Role 1:
Input Normalizer
Function:
Clean the source, confirm completeness and preserve provenance.
Output:
Normalized course input.
Handoff:
Course Extractor.
Role 2:
Course Extractor
Function:
Identify frameworks, operating rules, reusable procedures and strategic value.
Output:
Extraction report.
Handoff:
MCR Comparison Analyst.
Additional Roles:
MCR Comparison Analyst checks current pages and duplication.
Writer creates page output only where justified.
Reviewer checks clarity and structural fit.
Validator applies required standards.
Martyn approves.
Knowledge Commitment Agent updates the correct MCR destination.
Independent Reviewer Required:
For major governance or Canon changes.
Human Review Required:
Yes.
Failure Threshold:
Two materially identical failures.
Rescue Route:
Independent course-analysis route.
Expected Outcome:
MWMS improves without page bloat or duplication.
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
Required Role Chain:
Intake Cleaner
→ Signal Extractor
→ Analyst
→ Reviewer
→ Router
→ Outcome Logger
Optional Persistent Role:
Newsletter Monitor.
Tool Operator:
Required where approved Gmail or database tools are used.
Human Review:
Required before material downstream action.
Failure Triggers:
incomplete body
generic news
stale claim
wrong Brain
urgency unsupported
repeated dashboard noise
Expected Outcome:
Useful signals are routed and weak signals are rejected.
Role Design Status:
Assisted Use.
Example 3 — Developer Support Multi Agent Role Design
Workflow Name:
Developer Support Multi Agent Workflow
Workflow Purpose:
Prepare exact and evidence-based instructions for M.
Owning Brain:
HeadOffice Brain
Workflow Risk Level:
High
Required Role Chain:
Evidence Extractor
→ Technical Analyst
→ Writer
→ Independent Reviewer
→ Validator
→ Martyn Approval
Required Inputs:
current screenshot
current file where relevant
exact request
current save point
developer boundary
Failure Triggers:
missing file
hidden state unknown
broad instruction
M would need to guess
live-system risk
Rescue Route:
M review or separate specialist technical route.
Expected Outcome:
M receives a precise and safe handoff.
Role Design Status:
Manual Use.
Example 4 — Offer Evaluation Multi Agent Role Design
Workflow Name:
Offer Evaluation Multi Agent Workflow
Workflow Purpose:
Evaluate offers before any test planning or spend.
Owning Brain:
Affiliate Brain
Supporting Brains:
Research Brain, Compliance Brain, Finance Brain, Experimentation Brain and HeadOffice Brain
Workflow Risk Level:
High
Required Role Chain:
Offer Intake Extractor
→ Researcher
→ Analyst
→ Compliance Reviewer
→ Finance Reviewer
→ Experimentation Reviewer
→ Validator
→ Human Decision
→ Router
Failure Triggers:
missing payout
weak mechanism
vendor identity unclear
compliance red flag
finance assumptions missing
traffic fit weak
evidence insufficient
Expected Outcome:
Weak offers are rejected before spend and viable offers receive governed review.
Role Design Status:
Manual Use.
Example 5 — AIBS Client Reporting Multi Agent Role Design
Workflow Name:
AIBS Client Report Multi Agent Workflow
Workflow Purpose:
Convert approved client input into safe and useful business reporting.
Owning Brain:
AIBS Brain
Supporting Brains:
HeadOffice Brain, Operations Brain and relevant specialist Brains
Workflow Risk Level:
High
Required Role Chain:
Client Input Normalizer
→ External Knowledge Retriever Where Approved
→ Business Analyst
→ Writer
→ Independent Reviewer
→ Validator
→ Human Approver
→ Client Handoff
→ Outcome Logger
Required Controls:
client isolation
source provenance
tool permission
human approval
no unsupported claims
no cross-client memory leakage
Expected Outcome:
The client receives a clear, safe and action-ready report.
Role Design Status:
Future Draft Only.
Role Design Readiness Checklist
Before approving a role design, check:
Is the workflow purpose clear?
Is the Owning Brain clear?
Is the expected business outcome clear?
Is risk assigned?
Is the team type appropriate?
Is the role chain necessary?
Is each role distinct?
Is any role overloaded?
Is any role duplicated?
Does each role have defined input?
Is shared context defined?
Is role-isolated context defined where required?
Does each role have required context?
Does each role have defined output?
Does each role have a handoff destination?
Is each role’s authority level clear?
Are assigned Skills and active versions clear?
Are dependencies clear?
Are model requirements clear?
Are tool permissions clear?
Is parallel work justified?
Is a Synthesis Owner defined?
Is the Team Communication Contract defined?
Is independent review required?
Is validation required?
Is human review required?
Are persistent roles stoppable?
Is the failure threshold defined?
Is the Rescue Route defined?
Is outcome evidence defined?
Is knowledge commitment controlled?
Is cost proportionate?
Is a shutdown owner defined?
Is closure defined?
Can the chain be simplified?
Has manual proof occurred?
Does this affect M’s active work?
Is automation premature?
If several answers remain unclear, the role design is not ready.
Common Multi Agent Role Design Failure Modes
Multi-agent role design has failed when:
one Employee performs every function
roles are split without benefit
research and writing are mixed in high-risk work
Builder approves its own output
Reviewer lacks the original task or source
review and validation are confused
validation is skipped
tool use exceeds permission
Coordinator becomes uncontrolled authority
role handoffs lose context
model diversity is used without purpose
the same model creates and approves high-risk output
persistent roles lack shutdown
failure counts reset without progress
rescue repeats the failed approach
outcome remains undefined
knowledge is committed without approval
role chains create more work than value
client-facing roles lack isolation
automation starts before manual proof
no Synthesis Owner exists
roles use unapproved or outdated Skills
shared context leaks client or sensitive information
independent reviewers inherit producer assumptions
agent-to-agent communication is unstructured
parallel roles duplicate work
team cost exceeds outcome value
persistent teams lack shutdown ownership
Manual Use Rule
This framework should be used manually before role design becomes technical infrastructure.
Manual use helps MWMS learn:
which role chains improve outcomes
which roles should remain separate
which roles can be merged
where handoffs fail
where independent review adds value
where model diversity helps
where tool permissions matter
where rescue paths are required
which persistent agents create value
which role chains should remain manual
Manual role proof comes before automation.
Future Plugin Or UI Relevance
This framework may later support:
AI Employee Role Registry
AI Manager assignment logic
AI Employee Router
Brain Room role mapping
Task Executor sequencing
HeadOffice AI Workforce Dashboard
model routing
independent reviewer selection
rescue routing
persistent-agent control
AIBS client role templates
Possible future fields:
role_design_id
workflow_name
workflow_purpose
owning_brain
supporting_brains
workflow_risk_level
expected_business_outcome
required_role_chain
role_sequence
team_id
team_type
shared_context
role_isolated_context
parallel_tasks
sequential_tasks
synthesis_owner
team_communication_contract
role_name
role_archetype
role_function
role_authority_level
role_input
role_context
role_model_capability
role_assigned_skills
role_skill_versions
role_dependencies
role_tool_permission
role_output
handoff_destination
forbidden_actions
failure_triggers
independent_reviewer_required
validator_required
human_review_required
tool_operator_required
coordinator_required
persistent_agent_required
rescue_agent_required
knowledge_commitment_agent_required
handoff_requirements
dependency_notes
failure_threshold
rescue_route
outcome_evidence
knowledge_destination
cost_limit
maximum_parallel_workers
shutdown_owner
closure_requirement
role_design_status
created_at
updated_at
No technical build is authorised by this framework alone.
Governance Role
HeadOffice owns the MWMS AI Multi Agent Role Design Framework.
HeadOffice is responsible for:
approving role design principles
preventing vague AI Employee roles
preventing role sprawl
ensuring role separation is justified
ensuring high-risk work has independent review
ensuring tool use remains permissioned
ensuring Coordinators do not become uncontrolled authority
ensuring persistent roles remain stoppable
ensuring each Agent Team has a Synthesis Owner
ensuring Role Skill Bundles are approved and versioned
ensuring shared and isolated context are controlled
ensuring agent-to-agent communication is structured
ensuring team cost remains proportionate
ensuring shutdown ownership is defined
enforcing failure thresholds
governing rescue roles
preserving human approval gates
protecting M’s active build
protecting MCR
protecting future AIBS client systems
Individual Brains may propose specialised roles.
HeadOffice governs:
cross-Brain roles
high-risk roles
tool-enabled roles
persistent roles
automation roles
rescue roles
client-facing roles
Relationship To SIT Brain
SIT Brain may:
verify Role Card completeness
verify role separation
detect self-review risk
detect excessive authority
verify tool permissions
verify independent-review requirements
verify failure thresholds
trigger Rescue Agent routing
pause unsafe persistent agents
detect false completion
verify outcome evidence
block unapproved knowledge commitment
Relationship To Data Brain
Data Brain supports:
Role Design IDs
role assignments
model assignments
tool-permission records
dependency records
handoff records
failure counts
rescue records
validation results
outcome records
status history
retirement history
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 Employee Role Card Standard
MWMS AI Employee Capability Stack Framework
MWMS AI Tool Permission And Access Framework
MWMS AI Agent Memory And Context Framework
MWMS Agentic Work Unit Standard
MWMS AI Workflow Pipeline Standard
MWMS AI Output Validation Standard
MWMS Agentic Reporting Standard
MWMS AI Employee Handoff Protocol
MWMS AI Agent Failure Handling And Escalation Protocol
MWMS AI Agent Outcome Measurement Framework
MWMS AI Ambiguity And Partial Failure Containment Framework
MWMS Independent Model Review And Rescue Routing Framework
MWMS External Knowledge Engine And Reasoning Agent Separation Framework
MWMS AI Work Session Closure And Knowledge Commitment Protocol
MWMS AI Agent Deployment Readiness Checklist
MWMS AI Workforce Governance Model
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
MWMS Supabase Event Schema
AIBS Brain Blueprint
This framework adds specialist role design and multi-agent separation to the MWMS AI Agent Operations Core.
Drift Protection
This framework protects MWMS from:
treating one general AI as the entire workforce
asking one role to research, analyse, build, review and approve
unnecessary role sprawl
fake independence
excessive Coordinator authority
skipped validation
tool use without permission
vague handoffs
unresolved dependencies
uncontrolled persistent agents
repeated failure loops
weak Rescue Agents
automation before manual proof
multi-agent complexity without value
client context leakage
knowledge commitment without approval
role design outrunning governance
Role Design Drift Signals
MWMS should watch for:
no Owning Brain
vague role name
no role purpose
role performs conflicting functions
no defined input
no defined output
no handoff destination
authority unclear
model choice unexplained
tool permission missing
producer reviews itself
Coordinator makes specialist decisions
persistent role has no owner
no failure threshold
no rescue route
no outcome evidence
no human approval gate
no knowledge destination
no closure
no Team ID
no team type
no Synthesis Owner
no Team Communication Contract
no shared or isolated context rule
unapproved Skill version
hidden dependency
parallel work without cost limit
no shutdown owner
Rule:
Role design drift must be corrected before greater authority or automation is granted.
Minimum Compliance Standard
A formal multi-agent role design is compliant only when it defines:
Role Design ID
workflow purpose
Owning Brain
Supporting Brains
risk level
expected business outcome
team type
Team ID
required role chain
role sequence
shared and isolated context
parallel and sequential tasks
Synthesis Owner
role identity
role archetype
role function
role authority
role input
role context
model or capability
assigned Skills and versions
dependencies
tool permissions
required output
handoff destination
forbidden actions
failure triggers
independent review
validation
human review
Coordinator requirement
persistent-agent requirement
failure threshold
Rescue Route
outcome evidence
knowledge commitment
Team Communication Contract
cost limit
shutdown owner
closure
current status
Architectural Intent
The architectural intent of the MWMS AI Multi Agent Role Design Framework is to help MWMS operate as a coordinated AI workforce.
MWMS is not building one super-prompt.
MWMS is building a system where:
Brains act like departments
AI Employees act like defined roles
skills define repeatable procedures
tools provide controlled capability
handoffs preserve context
reviewers challenge output
validators enforce standards
rescue roles recover stalled work
humans retain final authority where required
The long-term goal is that every serious AI workflow can answer:
Should this use one AI Employee, a fixed team or a dynamic team?
Which roles are required?
Why are they separate?
What does each role receive?
What context is shared?
What context must remain isolated?
What approved Skills and versions does each role use?
What dependencies must exist?
What context does each role need?
What authority does each role hold?
Which model should each role use?
Which tools may each role use?
What does each role produce?
Where does each role hand off?
What may run in parallel?
Who owns synthesis?
How do the roles communicate?
Who reviews the output?
Who validates it?
Who approves it?
Who executes it?
Who verifies the outcome?
What failure threshold applies?
What rescue route exists?
What knowledge should be committed?
What cost limit applies?
Who can suspend or shut down the team?
How does the workflow close?
When MWMS can answer those questions, AI work becomes coordinated, accountable and safer to scale.
Strategic Summary
The v1.2 update expands the MWMS AI Multi Agent Role Design Framework from specialist-role separation into a complete Agent Team design standard.
The upgraded framework now also governs:
Agent Team definition
fixed and dynamic teams
team formation
Role Skill Bundles
shared and isolated context
structured agent-to-agent communication
parallel specialist execution
Synthesis Owner responsibility
Specialist Agent roles
Synthesis Agent roles
team cost and complexity
team shutdown and suspension
team-level readiness
The key shift is:
Multi-agent design is not about using more AI agents.
It is about creating the smallest governed team that separates responsibility, preserves evidence, controls authority, coordinates communication, produces one validated synthesis and can be stopped safely.
Final Rule
Do not ask one AI Employee to perform every thinking mode when the workflow requires separation.
No role clarity, no accountability.
No input definition, no reliable work.
No authority boundary, no safe execution.
No independent review, no high-risk trust.
No tool permission, no tool action.
No failure threshold, no controlled recovery.
No verified outcome, no completed workflow.
No approved commitment, no durable knowledge.
No Synthesis Owner, no parallel team.
No approved Skill bundle, no role execution.
No structured communication, no reliable handoff.
No cost boundary, no justified team complexity.
No shutdown owner, no persistent or autonomous team.
Change Log
Version: v1.2
Date: 2026-06-20
Author: HeadOffice
Change:
Updated the MWMS AI Multi Agent Role Design Framework using the AI Automations by Jack block covering Claude Agent Teams, Claude Skills 2.0, AntiGravity Skills, specialist model routing, parallel execution, Agent Manager, persistent project instructions, external knowledge systems and controlled agentic operating systems.
Added:
Agent Team Definition
Fixed And Dynamic Agent Teams
Team Formation Protocol
Role Skill Bundle
Shared Context And Context Isolation
Agent-To-Agent Communication Contract
Parallel Specialist Execution
Synthesis Owner
Team Cost And Complexity Control
Team Shutdown And Suspension
Specialist Agent
Synthesis Agent
Fixed Specialist Team Model
Dynamic Specialist Team Model
Parallel Team With Synthesis Model
Skill-Bundled Role Team Model
new Role Separation Rules
expanded Role Design Record Template
expanded Quick Use Version
expanded Role Design Readiness Checklist
expanded failure modes
expanded future fields
expanded governance
expanded drift signals
expanded Minimum Compliance Standard
Purpose of update:
To evolve the framework from specialist role separation into a complete Agent Team design standard covering team formation, fixed and dynamic teams, Skill bundles, context isolation, structured communication, parallel execution, synthesis ownership, cost control and shutdown.
Version: v1.1
Date: 2026-06-17
Author: HeadOffice
Change:
Updated the MWMS AI Multi Agent Role Design Framework using the AI Automations by Jack block covering multi-agent workflows, Three-Brain role separation, deliberate model routing, independent review, rescue agents, persistent agents, external knowledge systems and session closure.
Version: v1.0
Date: Initial Draft
Author: HeadOffice
Change:
Created the MWMS AI Multi Agent Role Design Framework to define how MWMS separates AI work into specialist AI Employee roles.
Change Impact Declaration
This v1.2 update expands the Multi Agent Role Design Framework from a specialist-role architecture into a complete Agent Team design standard covering team type, formation, Skill bundles, shared and isolated context, parallel work, synthesis, communication, cost, shutdown and team-level readiness.
Pages Created
None
Pages Updated
MWMS AI Multi Agent Role Design Framework
Pages Deprecated
None
Standalone Pages Not Created
MWMS AI Agent Team Framework
MWMS Fixed And Dynamic Agent Team Standard
MWMS Agent Team Formation Protocol
MWMS Role Skill Bundle Standard
MWMS Agent Communication Contract
MWMS Parallel Specialist Team Framework
MWMS Synthesis Agent Standard
MWMS Agent Team Cost Control Standard
MWMS Agent Team Shutdown Protocol
These concepts were absorbed into the unified MWMS AI Multi Agent Role Design Framework rather than created as separate pages.
Registries Requiring Update
None confirmed by the supplied source.
Canon Version Update Required
No
Change Log Entry Required
Yes
Strategic Absorption Result
MWMS gains a stronger Agent Team architecture that can determine whether one AI Employee or a specialist team is required, assemble fixed or dynamic teams, assign approved Skills and model routes, control shared and isolated context, coordinate parallel work, preserve structured communication, enforce synthesis ownership, limit cost and stop unsafe or unproductive teams.
END OF FULL FILE OUTPUT