System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.2
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, AI Manager, AI Employee Router, Task Executor Systems, 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 Agent Orchestration Framework v1.1 + AI Automations by Jack — Claude Agent Teams, Claude Skills 2.0, AntiGravity Skills, Agent Manager, multi-model specialist routing, persistent project instructions, parallel execution, NotebookLM knowledge systems and controlled agentic operating systems block
Related Pages: MWMS AI Multi Agent Role Design 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 Work Session Closure And Knowledge Commitment Protocol, MWMS AI Observability Metadata Standard
MWMS AI Agent Outcome Measurement Framework, MWMS AI Agent Outcome Measurement Framework
MWMS AI Agent Orchestration Framework
Purpose
The purpose of this document is to define the MWMS AI Agent Orchestration Framework.
This framework explains how MWMS coordinates:
AI Employees
Brains
reasoning models
specialist reviewers
tools
workflows
task queues
validation stages
rescue routes
handoffs
reports
knowledge systems
business outcomes
MWMS must not operate as a loose collection of disconnected AI prompts, models or independent AI helpers.
MWMS must operate as a coordinated and governed AI workforce.
That requires orchestration.
Orchestration is the management layer that decides:
what work needs to happen
which Brain owns the work
which AI Employee should perform the work
which reasoning model or specialist capability should be used
what order the work should happen in
what context is required
what tools are permitted
what review and validation are needed
when failed work must be rescued
where the output goes
what business outcome the work supports
what should be logged for future review
what knowledge should be committed after completion
This framework exists to make AI work inside MWMS coordinated, repeatable, governable, measurable, auditable and safe.
Scope
This framework applies to all MWMS workflows where more than one step, Brain, AI Employee, model, tool, review stage, handoff or outcome is involved.
This includes:
Brain Room task conversion
AI Manager routing
AI Employee Router logic
Task Executor workflows
Newsletter Intelligence workflows
Course Absorption workflows
Offer Evaluation workflows
Research Brain workflows
Experimentation Brain workflows
Finance Brain workflows
Content Brain workflows
Ads Brain workflows
HeadOffice reporting workflows
Brain-to-Brain requests
Supabase task and event systems
future client-facing AIBS workflows
model review workflows
rescue routing
external knowledge retrieval
persistent background-agent workflows
scheduled routines
remote command channels
multimodal processing
session closure and knowledge commitment
This framework applies to both manual and automated orchestration.
Manual orchestration happens when Martyn, M or HeadOffice decides:
the next task
the next Brain
the next page
the next workflow
the next model
the next review step
whether work may proceed
Automated orchestration happens when approved MWMS systems classify, assign, route, validate, log and escalate AI work through governed technical workflows.
Core Definition
AI Agent Orchestration is the process of coordinating AI Employees, Brains, models, tasks, tools, validation gates, review routes, handoffs, knowledge systems and outcomes inside MWMS.
Orchestration is not the same as automation.
Automation executes steps.
Orchestration decides how steps should be:
arranged
assigned
governed
reviewed
routed
escalated
recovered
logged
connected to outcomes
Inside MWMS, orchestration answers:
What is this request?
Which Brain owns it?
What type of work is required?
Which AI Employee should perform it?
Which model or specialist capability is suitable?
What context does the AI Employee need?
What tools can be used?
What output is required?
Who independently checks the output?
What happens if the assigned route fails?
Where does the output go next?
What outcome does this support?
What gets logged?
What knowledge should be retained?
Without orchestration, AI work becomes scattered.
With orchestration, AI work becomes systemised.
Core Principle
The core principle of this framework is:
AI capability does not become MWMS business value until it is routed, sequenced, validated, handed off, connected to an outcome and preserved as organisational learning.
A powerful AI model is not enough.
A useful AI Employee is not enough.
A good prompt is not enough.
A connected tool is not enough.
MWMS value comes from how the whole system coordinates work.
The orchestration layer is what turns AI activity into governed business execution.
Orchestration Authority
HeadOffice owns system-wide orchestration authority.
Individual Brains own subject-matter workflows within their approved boundaries.
SIT Brain may block orchestration that violates:
Canon
authority
risk controls
tool permissions
review requirements
failure thresholds
data-integrity rules
compliance requirements
No AI Employee, model router or workflow may create authority merely because it can technically perform an action.
Technical capability does not equal operational permission.
Why Orchestration Matters
MWMS is a multi-Brain ecosystem.
Work will often cross several areas.
For example, an affiliate offer may require:
Affiliate Brain for intake
Research Brain for market evidence
Ads Brain for platform fit
Finance Brain for break-even logic
Experimentation Brain for test design
Compliance Brain for safety
SIT Brain for enforcement
HeadOffice for final visibility and decision
A newsletter signal may require:
HeadOffice Brain for intake
Signal Extraction Agent for insight
Brain Routing Agent for ownership
Validation Agent for quality
Queue Review for human decision
Routed Actions for follow-up
Learning Log for pattern tracking
A Brain Room request may require:
Task Builder Agent
Brain Classifier Agent
AI Manager
correct AI Employee
specialist model route
independent reviewer
Response Agent
event logging
knowledge commitment
Without orchestration, these flows become confusing and fragile.
With orchestration, MWMS can scale without losing control.
Orchestration Layers
MWMS orchestration operates across fourteen layers.
Request Orchestration
Brain Orchestration
Employee Orchestration
Skill Orchestration
Skill Orchestration
Skill Orchestration determines which approved reusable procedure should govern the assigned work.
A Skill may define:
task trigger
required input
required context
approved tools
step sequence
output format
validation
failure conditions
handoff
knowledge commitment
Skill Orchestration answers:
Does an approved skill already cover this task?
Which skill version is active?
Is the skill global, Brain-specific, workflow-specific, project-specific or client-specific?
Is the assigned AI Employee authorised to use it?
Does the skill require other skills or tools?
May the skill activate automatically?
Does the current Work Unit match the skill trigger and scope?
Does the skill preserve current Canon and role authority?
The Skill rule is:
A skill may structure execution, but it must not create new authority.
No skill may expand an AI Employee’s Role Card, Capability Stack, Tool Permissions or client boundary without separate approval.
Skill Discovery And Invocation
Skills may be selected through:
direct assignment
AI Manager routing
Work Unit metadata
workflow state
approved natural-language recognition
dependency activation
scheduled trigger
Automatic invocation is allowed only when:
the trigger is unambiguous
the active version is confirmed
the skill scope matches
required context exists
required dependencies are available
tool permissions are approved
human-review requirements remain intact
Where two skills conflict:
apply current Canon
apply the higher-authority standard
apply the more specific approved skill
compare active versions
escalate unresolved conflict
Model And Capability Orchestration
Context Orchestration
Tool And Permission Orchestration
Dependency And Environment Orchestration
Dependency And Environment Orchestration
Dependency And Environment Orchestration determines whether the assigned route can actually operate.
Dependencies may include:
approved Skills
current Context Packs
external knowledge systems
data sources
software
APIs
browser access
local runtime
client workspace
validated templates
model availability
reviewer availability
permission records
Environment checks should confirm:
required dependency exists
required version is active
the environment matches the Skill assumptions
credentials remain inside approved custody
client and project boundaries are preserved
failure and fallback routes are defined
Dependency Rule
A Work Unit must enter Blocked status when a required dependency or environment condition is unavailable.
The orchestration layer must not silently replace a missing specialist, reviewer, model, Skill or tool with an unsuitable substitute.
Workflow Orchestration
Parallel And Team Orchestration
Parallel And Team Orchestration
Parallel And Team Orchestration coordinates multiple AI Employees, Skills or model routes working on separable parts of one Work Unit.
Possible team roles include:
Orchestrator
Specialist Worker
Research Worker
Tool Operator
Independent Reviewer
Validator
Synthesis Owner
Rescue Worker
Parallel execution is suitable when:
tasks are independent
shared input is stable
responsibilities do not overlap materially
each output has a defined format
final synthesis authority is clear
cost is justified
conflict rules exist
Parallel execution is not suitable when:
one task depends on the previous result
multiple agents may alter the same live state
ownership is unresolved
independent reviewers may contaminate each other
the task is too simple to justify coordination overhead
Parallel Group Record
Parallel Group ID:
Work Unit ID:
Owning Brain:
Orchestrator:
Workers:
Assigned Skills:
Shared Input:
Separate Responsibilities:
Expected Outputs:
Synthesis Owner:
Conflict Rule:
Cost Limit:
Completion Gate:
Parallel Team Rule
No multi-agent team may begin without a final synthesis owner.
The number of agents should be proportionate to task complexity and expected business value.
More agents do not automatically create better reasoning.
Agent Team Communication
Agent-to-agent communication should be structured.
Each message should state:
sender role
receiver role
Work Unit ID
task objective
completed work
evidence
assumptions
open issues
required next action
authority required
Unstructured agent chatter should not become the source of truth.
Validation And Review Orchestration
Outcome And Handoff Orchestration
Cost And Quota Orchestration
Cost And Quota Orchestration
Cost And Quota Orchestration controls the resources consumed by AI work.
Resources may include:
model tokens
API calls
tool credits
browser actions
external searches
compute
storage
rendering
parallel workers
human review time
Each material Work Unit should define:
expected cost
maximum cost
maximum retries
maximum parallel workers
maximum source volume
execution time limit
stop threshold
escalation threshold
Cost routing should consider:
business value
risk
required quality
task complexity
frequency
privacy
available lower-cost routes
review cost
Cost Rule
Low-cost routing is useful only when required quality and safety remain intact.
High-cost orchestration is justified only where the expected decision value, risk reduction or business result supports it.
A workflow must stop or escalate when its approved quota is exhausted.
Learning And Knowledge Commitment Orchestration
Request Orchestration
Request Orchestration identifies what has entered the system.
A request may come from:
Martyn
M
Brain Room
HeadOffice
newsletter intake
uploaded course file
Supabase task
WordPress page update need
Google Ads data
affiliate offer
research source
dashboard item
system event
client request
scheduled routine
webhook
remote command channel
monitoring alert
The first orchestration question is:
What kind of request is this?
Possible request classes include:
question
analysis request
task creation request
page creation request
course absorption request
newsletter signal
offer evaluation
research request
validation request
independent review request
rescue request
developer support request
report generation
workflow handoff
system issue
escalation
monitoring alert
scheduled operation
external event
Request Orchestration protects MWMS from treating every input the same way.
Brain Orchestration
Brain Orchestration identifies which Brain owns the work.
Examples:
HeadOffice Brain owns cross-system governance, visibility, routing and final control.
Affiliate Brain owns affiliate opportunity intake and offer logic.
Research Brain owns evidence gathering, source analysis and market validation.
Experimentation Brain owns test design, test tracking and learning capture.
Finance Brain owns budget logic, break-even analysis and capital control.
Content Brain owns content production, refresh, repurposing and content workflows.
Ads Brain owns campaign logic, platform strategy, traffic rules and ad testing.
AIBS Brain owns client-facing AI workflow packaging and system design.
Data Brain owns data structure, source identity, storage and retrieval integrity.
SIT Brain owns integrity enforcement, review gates and drift detection.
Brain Orchestration answers:
Which Brain should own this?
Which Brain only supports it?
Does HeadOffice need visibility?
Is this cross-Brain work?
Does this need a Brain-to-Brain request?
Is this outside the scope of the current Brain?
Is there a conflict between subject ownership and execution capability?
The Brain rule is:
No material work should move forward until ownership is clear.
Employee Orchestration
Employee Orchestration assigns the correct AI Employee to the work.
This depends on:
task type
owning Brain
required output
risk level
available input
tool requirement
review requirement
authority
model capability
escalation path
Examples:
A newsletter may be assigned to:
Newsletter Intake Agent
Signal Extraction Agent
Brain Routing Agent
Validation Agent
Dashboard Reporting Agent
An offer may be assigned to:
Offer Intake Agent
Vendor Intelligence Agent
Market Demand Agent
Compliance Review Agent
Finance Break-Even Agent
HeadOffice Verdict Agent
A course lesson may be assigned to:
Course Intake Agent
Value Filter Agent
Framework Extraction Agent
MWMS Mapping Agent
Duplication Check Agent
Page Builder Agent
Employee Orchestration answers:
Which AI Employee is best suited?
Does the Employee have a role card?
Is this inside the Employee’s authority?
Does this require more than one Employee?
Should one Employee complete the task or should it be split?
Does the Employee require independent review?
Does the Employee have the correct tools and context?
The Employee rule is:
Work must be assigned to defined roles, not vague AI capability.
Model And Capability Orchestration
Model And Capability Orchestration selects the reasoning model, specialist model or computational system best suited to each work unit.
Model selection must be based on:
task complexity
reasoning depth
required modality
cost
speed
context length
tool compatibility
reliability
independence requirements
privacy requirements
local versus hosted execution
review needs
Possible model roles include:
primary reasoning model
execution model
independent reviewer
rescue model
multimodal specialist
long-context retrieval model
adversarial critic
low-cost high-volume processor
local private model
deterministic validator
Model Orchestration answers:
Which model should perform the first pass?
Does the task require vision, audio, video or code capability?
Is a lower-cost model suitable for routine work?
Does the output require an independent model review?
Has the assigned model already failed this task?
Does the task require a rescue route?
Is local execution required for privacy?
Is consensus useful or wasteful?
The Model rule is:
The best model for producing an output is not automatically the best model for reviewing it.
No-Self-Review Principle
The same model that created material work must not automatically be treated as the only reviewer of that work.
Self-checking may be used for:
formatting
completeness
obvious omissions
low-risk quality control
Independent review is required where:
governance is affected
risk is high
compliance is involved
capital is exposed
system integrity is affected
the model has failed repeatedly
evidence is disputed
a risky path is involved
the task explicitly requires independent checking
Context Orchestration
Context Orchestration determines what information the assigned AI Employee or model receives.
Context may include:
Brain Canon
ownership rules
role card
task objective
source material
prior decisions
current save point
user instructions
tool permissions
risk classification
prohibited actions
required output structure
validation criteria
failure history
relevant external knowledge retrieval
Context Orchestration must distinguish:
mandatory Canon
current operational context
supporting evidence
historical context
unverified external material
deprecated material
model-generated summaries
The Context rule is:
Every AI Employee must receive the minimum complete context required to perform the assigned work correctly.
Too little context creates errors.
Too much irrelevant context reduces focus, increases cost and can introduce stale instructions.
External Knowledge Retrieval
Where the required context is too large or distributed across many sources, the orchestration layer should use an external knowledge engine.
The external knowledge engine may:
locate relevant sources
return source-grounded evidence
preserve metadata
reduce context load
support several AI Employees
provide historical continuity
The reasoning agent remains responsible for interpreting the retrieved material.
Retrieval does not create authority.
Tool And Permission Orchestration
Tool And Permission Orchestration determines what tools may be used.
Tool access must be based on:
role
task
authority
risk
environment
data sensitivity
reversibility
human approval requirements
Tool classes may include:
read-only retrieval tools
search tools
document tools
communication tools
database tools
publishing tools
browser automation
execution tools
financial tools
deployment tools
destructive tools
Tool Orchestration answers:
What tool is required?
Is the AI Employee authorised to use it?
Is the action read-only or write-capable?
Does the action change external systems?
Is approval required before execution?
Are credentials protected?
Is the action observable?
Is rollback possible?
Does the tool expose restricted systems?
The Tool rule is:
Tool access must be granted by task and authority, not by convenience.
Credential Custody
Credentials must remain within approved execution environments.
Credentials must not be:
embedded in prompts
copied into portable skill files
exposed in knowledge records
transferred to unauthorised agents
included in logs without protection
Agents should access capabilities through governed tool interfaces rather than raw credentials.
Workflow Orchestration
Workflow Orchestration defines the sequence of work.
Complex AI work should not be handled as one large prompt.
It should be decomposed into stages.
The default MWMS workflow sequence is:
Intake
Cleaning
Classification
Ownership
Task Creation
Assignment
Context Assembly
Tool Check
Processing
Validation
Decision
Routing
Logging
Reporting
Learning
Knowledge Commitment
Not every task needs every step.
High-value or high-risk work must follow a clear sequence.
Workflow Orchestration answers:
What happens first?
What depends on what?
What must be completed before the next step?
Where are the review gates?
What happens if a step fails?
What can be automated?
What requires human review?
What can run in parallel?
What must remain sequential?
The Workflow rule is:
Complex work must be sequenced before it is executed.
Task Graph Standard
Complex Work Units should define a task graph.
Each task node should record:
Task Node ID
Purpose
Owner
Assigned AI Employee
Assigned Skill
Required Input
Dependencies
Allowed Tools
Required Output
Validation Gate
Failure Route
Completion Condition
Next Node
Task Graph Rule
No dependent node should begin until its required inputs and validation gates are complete.
A task graph may contain sequential and parallel branches, but all branches must converge into a governed synthesis, decision or handoff point.
Parallel Work Rules
Parallel work may be used where tasks are genuinely independent.
Examples include:
independent market and compliance research
separate financial and platform analysis
parallel specialist reviews
multiple source-ingestion tasks
separate creative concepts
Parallel work must not be used where:
one result depends on another
the same data may be changed concurrently
authority is unresolved
reviewers could contaminate independent assessment
outputs would conflict without a defined merge process
Parallel execution must define:
work boundaries
output format
merge authority
conflict resolution
completion conditions
Validation And Review Orchestration
Validation Orchestration decides how outputs are checked.
Validation may happen:
after each stage
before handoff
before dashboard display
before MCR update
before live system change
before client delivery
before external communication
before final HeadOffice decision
Validation may be performed by:
the same AI Employee using low-risk self-check rules
a separate Validation Agent
a different reasoning model
a specialist reviewer
HeadOffice
Martyn
M
a technical test
a data-integrity check
a schema check
a compliance gate
SIT Brain
Validation Orchestration answers:
What needs checking?
Who checks it?
What standard applies?
Is independent review required?
Is human review required?
What happens if validation fails?
Is the output accepted, revised, parked, rejected or escalated?
The Validation rule is:
AI output is not trusted simply because it was generated.
Independent Review Routing
Independent review must be triggered where:
Canon or authority may change
high-risk action is proposed
external publication is involved
regulated or sensitive claims are present
financial exposure is material
security permissions are affected
destructive action is proposed
evidence is incomplete or conflicting
the same agent has repeatedly failed
another reviewer identifies a severe risk
The review route should match the risk.
Examples:
compliance → Compliance Brain or Compliance Auditor
financial risk → Finance Brain
system integrity → SIT Brain
research quality → Research Brain
architecture → HeadOffice and SIT Brain
data integrity → Data Brain
experimentation → Experimentation Brain
repeated reasoning failure → different model family or specialist rescue model
Repeated-Failure Rescue Rule
A task must be routed for rescue when the same assigned model or AI Employee:
produces the same test failure twice
receives the same command or system error twice
repeats the same unsuccessful edit twice
repeats the same rejected recommendation twice
fails the same validation gate twice
makes no verified progress after two materially similar attempts
At the rescue threshold:
materially identical retries must stop
the failure history must be preserved
the task must be transferred to a different reasoning route
the rescue route must receive the full task context
a materially different recovery approach must be required
The same model must not be allowed to loop indefinitely.
Risk-Path Review
Independent review is mandatory for work involving:
authentication
billing
payments
production deployment
environment variables
secrets
migrations
policy
infrastructure
destructive database actions
OAuth
permission expansion
regulated claims
external communications at scale
Consensus Routing
Consensus mode may be used where multiple independent viewpoints add real value.
Consensus mode should not be the default.
Where used, each reviewer should initially provide:
conclusion
evidence
assumptions
risks
confidence
required conditions
Reviewers must not be instructed to agree.
Consensus does not override Canon or required human authority.
Outcome And Handoff Orchestration
Outcome Orchestration connects AI work to business results.
MWMS must avoid producing outputs that sound useful but go nowhere.
Outcome Orchestration answers:
What should happen because of this output?
Is this a decision?
Is this a task?
Is this a dashboard item?
Is this a report?
Is this a learning record?
Is this a rejected idea?
Is this a parked opportunity?
Is this an MCR page update?
Is this a Brain handoff?
Is this a client deliverable?
Does this trigger another workflow?
The Outcome rule is:
Every important AI output must support a next action, decision, report, routing event or learning record.
Handoff Requirements
Every material handoff must include:
task objective
owning Brain
completed work
current state
source material
applicable Canon
known risks
unresolved issues
required output
validation status
next action
authority required
prohibited actions
The receiving party should not need to rediscover basic context.
Learning And Knowledge Commitment Orchestration
Learning Orchestration decides what should become durable MWMS knowledge after work is completed.
Possible durable outcomes include:
decisions
approved frameworks
lessons learned
current save points
performance evidence
failure patterns
user corrections
new operating rules
reusable prompts
validated research
workflow improvements
Not every model output should be saved.
Knowledge commitment must determine:
what is durable
what is verified
who owns it
where it belongs
whether an existing record should be updated
whether approval is required
whether the information is temporary or authoritative
The Learning rule is:
MWMS should preserve verified organisational learning, not accumulate unfiltered AI output.
Orchestration State Model
Recommended orchestration states:
Requested
Classified
Owned
Planned
Dependency Check
Ready
Running
Waiting For Input
Waiting For Review
Blocked
Rescue Required
Rescue In Progress
Validated
Decision Required
Handoff Ready
Completed
Knowledge Commitment Pending
Closed
Cancelled
Failed
State Rule
Current state must remain visible.
A Work Unit marked Blocked, Waiting For Review, Rescue Required or Failed must not be reported as complete.
Standard Orchestration Flow
The standard MWMS orchestration flow is:
Request Received
Request Classified
Owning Brain Identified
Supporting Brains Identified
Risk Level Assigned
Work Unit Created
AI Employee Assigned
Approved Skill Selected Where Relevant
Model Or Capability Route Selected
Context Pack Attached
Dependencies And Environment Checked
Tool Permission Checked
Cost And Quota Boundary Set
Workflow Sequence Selected
AI Work Performed
Output Validated
Independent Review Performed Where Required
Decision Made
Output Routed
Event Logged
Knowledge Committed
HeadOffice Visibility Updated Where Required
This is the default orchestration pattern for serious AI work.
Orchestration Decision Tree
When a request enters MWMS, the orchestration layer should ask:
Step 1: Is this real work or casual support?
If casual support, answer directly.
If real work, create or follow an Agentic Work Unit.
Step 2: Is the request simple or complex?
If simple, assign it to one qualified AI Employee.
If complex, break it into a workflow.
Step 3: Which Brain owns it?
Assign the owning Brain.
If cross-Brain, identify supporting Brains.
Step 4: Which AI Employee should act first?
Assign the first defined role.
Do not assign work to generic AI.
Step 5: Which approved Skill governs the work?
Select the active Skill where repeated procedure exists.
Confirm scope, version, dependencies and invocation authority.
Step 7: Which model or specialist capability is required?
Select according to task type, risk, modality, cost, privacy and review requirements.
Step 6: What context is required?
Attach Brain rules, standards, source material, boundaries, previous decisions and failure history.
Step 8: What tools are allowed?
Check tool permission before execution.
Step 9: What output is required?
Define the output before work begins.
Step 10: What validation is required?
Set validation according to risk and business impact.
Step 11: What happens if the route fails?
Define retry limits, rescue route and escalation authority.
Step 12: Where does the result go?
Define the handoff destination.
Step 13: What outcome is expected?
Connect the output to a business result.
Step 14: What should be learned or retained?
Define the knowledge-commitment requirement.
Step 15: What cost and quota boundary applies?
Set the model, tool, retry, parallel-worker and execution limits.
Step 16: What closes the Work Unit?
Define completion, knowledge commitment, logging and closure requirements.
Orchestration Modes
MWMS supports five orchestration modes.
Manual Orchestration
Manual Orchestration is when Martyn or another human decides the flow.
Example:
Martyn uploads a course block.
The assistant evaluates it, extracts system value, creates MCR-ready page output and Martyn decides whether to save it.
Manual Orchestration is appropriate during:
early system design
course absorption
MCR page creation
high-risk decisions
structural changes
unclear workflows
new Brain development
Manual Orchestration must still follow MWMS standards.
Assisted Orchestration
Assisted Orchestration is when AI recommends the flow but a human approves it.
Example:
Brain Room receives a message.
The Task Builder Agent suggests:
owning Brain
task type
assigned AI Employee
model route
priority
risk level
validation requirement
Martyn or HeadOffice approves the route.
Assisted Orchestration is appropriate when workflows are not yet fully trusted.
Controlled Automated Orchestration
Controlled Automated Orchestration is when the system automatically routes work within approved boundaries.
Example:
A newsletter enters the system.
The workflow automatically extracts, classifies, stores and displays the item for review.
The system does not create downstream actions outside approved authority.
Controlled automation is appropriate for repeatable, medium-risk workflows.
Supervised Agentic Orchestration
Supervised Agentic Orchestration is when multiple AI Employees perform multiple steps, but review gates remain in place.
Example:
Offer Evaluation workflow:
Offer Intake Agent
Research Agent
Compliance Agent
Finance Agent
Experimentation Fit Agent
HeadOffice Verdict Agent
The system prepares a decision report, but human review is required before testing.
This mode is appropriate for high-value workflows.
Restricted Autonomous Orchestration
Restricted Autonomous Orchestration is when AI can complete low-risk workflows without immediate human review.
This should be limited to safe tasks such as:
formatting
categorising
duplicate detection
low-risk tagging
draft preparation
internal note cleanup
routine status updates
non-public report formatting
approved monitoring
read-only retrieval
This mode must not be used for high-risk work without explicit controls.
Persistent And Background Orchestration
MWMS may use persistent agents, scheduled routines and background workers.
These may support:
recurring monitoring
inbox intake
research collection
system health checks
data refresh
routine summaries
approved watchdog functions
scheduled report generation
Persistent orchestration must define:
trigger
schedule
owner
tool permissions
execution limit
notification rules
failure threshold
shutdown method
escalation path
logging
human interruption conditions
A persistent agent must not operate without bounded authority.
Remote Command Channels
MWMS may permit governed remote command channels for approved workflows.
Examples may include:
mobile command interfaces
secure chat-based triggers
webhook events
remote task submission
cloud-to-local execution bridges
Remote command orchestration must:
authenticate the source
validate the command
restrict tool access
log the request
define approval requirements
prevent unrestricted shell or system access
support revocation
preserve the initiating user or system identity
A remote command channel is an input route, not an authority source.
Orchestration Risk Levels
The orchestration mode must match the risk level.
Low Risk
Examples:
formatting notes
summarising internal content
preparing draft outlines
cleaning non-sensitive text
read-only retrieval
duplicate detection
Allowed modes:
manual
assisted
controlled automated
restricted autonomous if approved
Medium Risk
Examples:
newsletter intelligence
course absorption drafts
internal reports
Brain Room task drafts
dashboard queue items
non-public workflow recommendations
Allowed modes:
manual
assisted
controlled automated
supervised agentic
Human review may be required before final routing.
High Risk
Examples:
offer verdicts
finance analysis
compliance review
developer instructions
MCR source-of-truth updates
public content
paid traffic decisions
client recommendations
Allowed modes:
manual
assisted
supervised agentic
Human review required.
Critical Risk
Examples:
live system changes
production database writes
external email sending
client-facing final reports
financial transactions
legal or compliance-sensitive actions
irreversible automation
credential or permission changes
Allowed modes:
manual
supervised agentic
Human approval required before execution.
Orchestration Example: Newsletter Intelligence
A mature Newsletter Intelligence orchestration flow should be:
Gmail receives newsletter
Newsletter Intake Agent captures metadata and content
Cleaning Agent removes noise
Signal Extraction Agent identifies business-relevant signals
Brain Routing Agent assigns primary and supporting Brains
Action Classification Agent marks ACT NOW, TEST, MONITOR, PARK or REJECT
Validation Agent checks specificity and usefulness
Output stored in Supabase
Queue Review displays item
HeadOffice Dashboard displays priority intelligence
Human review routes, parks, rejects or converts to action
Learning Agent tracks recurring patterns
This turns newsletters into operational intelligence instead of passive reading.
Orchestration Example: Brain Room Request
A mature Brain Room orchestration flow should be:
Brain Room message received
Request type identified
Owning Brain classified
Agentic Work Unit created
Required context attached
AI Employee assigned
Model route selected
Risk level set
Task sent to AI Manager
AI Employee completes task
Output validated
Independent review performed where required
Response posted back to Brain Room
Important result logged
Follow-up action routed if required
Session outcome committed
This turns Brain Room into an operational command layer, not just a chat stream.
Orchestration Example: Course Absorption
A mature Course Absorption orchestration flow should be:
Course file uploaded
Course Intake Agent identifies lesson or module
Value Filter Agent judges system relevance
Framework Extraction Agent extracts reusable models
MWMS Mapping Agent maps material to Brains and Blueprint
Duplication Check Agent checks existing MCR pages
Upgrade Decision Agent decides absorb, update, park, ignore or replace
Page Builder Agent prepares MCR output if required
Registry Agent identifies registry update needs
Validation Agent checks fit, naming, ownership, parent and structure
Martyn reviews before saving
Learning and save point logged
This prevents weak course material from cluttering MWMS.
Orchestration Example: Offer Evaluation
A mature Offer Evaluation orchestration flow should be:
Offer enters Affiliate Brain
Offer Intake Agent records basic offer data
Vendor Intelligence Agent checks credibility
Market Demand Agent checks demand signals
Competitor Scan Agent checks market crowding
Funnel Analysis Agent checks sales mechanism
Ads Brain checks traffic and platform fit
Compliance Review Agent flags risks
Finance Brain estimates break-even and test budget
Experimentation Brain checks test suitability
HeadOffice Verdict Agent prepares decision
SIT verifies required gates
Martyn reviews YES or NO verdict
Result routed to test planning, research, parking or rejection
Learning logged
This protects MWMS from wasting money on weak or risky offers.
Orchestration Example: AIBS Client System
A mature AIBS client workflow may be:
Client business process identified
Process mapped into repeatable work units
AI Employee roles defined
Model and tool routes assigned
Tool permissions assigned
Workflow sequence designed
Validation gates added
Human review rules defined
Dashboard and reporting layer created
Client approval points defined
Logging and audit trail included
System deployed in controlled mode
Performance monitored
Kaizen improvement loop begins
This supports the future MWMS client-facing offer:
Governed AI workflow systems, not random automations.
Orchestrator Agent Role
The Orchestrator Agent is the AI Employee responsible for recommending or managing workflow coordination.
The Orchestrator Agent may:
classify requests
recommend owning Brain
identify supporting Brains
suggest AI Employee sequence
select approved Skills and active versions
select approved model routes
recommend validation gates
identify dependencies and environment requirements
identify tool permissions
set cost and quota boundaries
flag risk level
determine handoff path
prepare workflow plans
identify missing context
trigger rescue routing
identify knowledge-commitment requirements
The Orchestrator Agent must not:
bypass HeadOffice governance
approve high-risk actions alone
execute live system changes without authority
assign tasks into restricted developer areas without approval
remove human review from high-risk workflows
invent Brain ownership where standards are unclear
override SIT blocks
hide failure history
reset failure counters without verified progress
treat model consensus as final authority
invoke Skills outside approved scope
create parallel agent teams without a synthesis owner
silently replace missing dependencies
exceed approved cost or quota boundaries
The Orchestrator Agent is a coordination role, not a final authority role.
Human Orchestration Role
Human orchestration remains essential.
Martyn, HeadOffice, M and future operators may be required for:
strategic decisions
system architecture changes
MCR source-of-truth updates
developer implementation
paid traffic decisions
compliance-sensitive decisions
client-facing approvals
high-risk automation approval
escalation resolution
unresolved model disagreement
destructive or irreversible action
AI can support orchestration.
AI must not replace governance.
The human role is especially important while MWMS is still being built.
Orchestration Failure Modes
MWMS must watch for orchestration failure.
Common failure modes include:
wrong Brain ownership
wrong AI Employee assignment
wrong model assignment
missing context
over-automation of high-risk work
no validation gate
no independent review where required
output has no destination
task is too vague
too many agents for a simple task
one AI Employee doing too many jobs
human review skipped
dashboard filled with low-value items
event logs missing
workflow creates duplicate records
agent loops endlessly without decision
repeated failure is not escalated
credentials are exposed
tools exceed role authority
context includes stale or deprecated rules
system mistakes activity for progress
completed work is not committed to durable knowledge
Skill selected outside approved scope
inactive or outdated Skill version used
required dependency or environment assumption ignored
parallel agents duplicate work or create conflicting outputs
no synthesis owner exists
multi-agent cost exceeds expected value
Work Unit state is hidden or falsely marked complete
These failure modes must be used when reviewing future workflows.
Orchestration Quality Checklist
Before an orchestrated AI workflow is approved, check:
Is the request type clear?
Is the owning Brain clear?
Are supporting Brains identified?
Is the task broken into sensible stages?
Is each stage assigned to the correct AI Employee?
Is the approved Skill selected where relevant?
Is the Skill version and scope correct?
Is the model route appropriate?
Is required context attached?
Are dependencies and environment assumptions verified?
Are tool permissions defined?
Are forbidden actions defined?
Is the output format defined?
Is validation required?
Is independent review required?
Is human review required?
Is the failure threshold defined?
Is a rescue route defined?
Is the handoff destination clear?
Is the business outcome clear?
Is logging required?
Is knowledge commitment required?
Is a synthesis owner defined for parallel work?
Are cost and quota boundaries defined?
Is the current orchestration state visible?
Is the workflow too complex for the value of the task?
Is the workflow safe for the current build stage?
Does it interfere with M’s active work?
Does HeadOffice need visibility?
Does the result improve MWMS?
Can the workflow be repeated?
Can the workflow be stopped or revoked safely?
A workflow should not be automated until it passes this checklist.
Logging And Observability Requirements
Material orchestration events should record:
request ID
task ID
request source
owning Brain
supporting Brains
assigned AI Employee
assigned Skill and version
selected model route
tools used
dependencies checked
environment status
risk level
context source
validation route
reviewer
failure count
parallel group ID where relevant
synthesis owner where relevant
cost and quota state
rescue route
final decision
output destination
execution status
handoff status
knowledge-commitment status
human approval where required
MWMS must be able to reconstruct how important work moved through the system.
Cost-Aware Orchestration
Model and tool cost should be considered during routing.
Routine high-volume work may be assigned to lower-cost models where:
quality remains acceptable
risk is low
output can be validated
privacy and security requirements are met
Premium reasoning models should be reserved for work requiring:
complex judgement
high reliability
difficult synthesis
governance interpretation
high-risk review
unresolved ambiguity
Cost savings must not weaken required review or authority.
Local And Hosted Model Routing
MWMS may route work to local or hosted models.
Local models may be preferred where:
privacy is important
offline execution is useful
recurring cost reduction matters
the task is low or medium risk
capability is sufficient
Hosted models may be preferred where:
advanced reasoning is required
specialist capability is needed
context requirements exceed local capacity
reliability is higher
independent review is required
Local execution must not be described as equivalent to premium hosted reasoning unless verified for the specific task.
Governance Role
HeadOffice owns the MWMS AI Agent Orchestration Framework.
HeadOffice is responsible for:
defining orchestration standards
approving cross-Brain orchestration patterns
setting validation requirements
setting human review requirements
preventing unsafe automation
preventing AI Employee role drift
protecting M’s active build areas
ensuring outputs connect to business outcomes
maintaining visibility over critical workflows
approving Skill-routing policy
approving model-routing policy
approving rescue and escalation policy
governing persistent and remote agents
governing dependency and environment requirements
governing parallel-agent team patterns
governing cost and quota limits
governing orchestration state visibility
Individual Brains may design their own orchestration flows, but those flows must align with this framework.
No Brain should create autonomous workflows that bypass HeadOffice oversight for high-risk or cross-system work.
Relationship To SIT Brain
SIT Brain may:
inspect orchestration routes
verify Brain ownership
verify model-review independence
enforce failure thresholds
block unsafe execution
detect role drift
detect missing validation
detect missing authority
inspect tool-permission violations
require rescue routing
log orchestration failures
escalate unresolved risk
Relationship To Data Brain
Data Brain supports orchestration through:
source identity
metadata
retrieval
context assembly
task records
event records
knowledge commitment
historical reconstruction
Relationship To Other MWMS Standards
This framework supports and must align with:
MWMS AI Agent Operations Core
MWMS Agentic Work Unit Standard
MWMS AI Employee Role Card Standard
MWMS AI Employee Capability Stack Framework
MWMS AI Agent Skill Library Framework
MWMS AI Skill Builder And Audit Protocol
MWMS AI Multi Agent Role Design Framework
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
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 Failure Handling And Escalation Protocol
MWMS AI Tool Permission And Access Framework
MWMS AI Observability Metadata Standard
MWMS AI Output Standard Full File Delivery Rule
MWMS Brain Header Schema Standard
MWMS Page Naming Standard
MWMS Document Structure Standard
MWMS Architecture Registry
MWMS Brain Interaction Map
MWMS System Data Flow Map
MWMS Supabase Event Schema
HeadOffice Newsletter Intelligence Operating Protocol
HeadOffice Newsletter Intelligence Output Validation Protocol
MWMS Course Absorption Operating Rule
MWMS Opportunity System Operating Protocol
AIBS Brain Blueprint
This framework explains how those standards are coordinated during real AI work.
Drift Protection
This framework protects MWMS from:
treating AI automation as orchestration
allowing workflows to run without Brain ownership
assigning tasks to vague AI roles
assigning models without capability checks
using one prompt for complex work
skipping validation gates
skipping independent review
routing outputs to nowhere
automating high-risk actions too early
creating AI Employees without role cards
allowing Brains to operate outside HeadOffice visibility
creating dashboards full of unvalidated noise
letting Brain Room become unmanaged chat
letting course absorption create duplicate systems
giving tool access without permission boundaries
hiding repeated failures
allowing the same model to loop indefinitely
exposing credentials through portable skills
losing business outcome visibility
failing to preserve durable learning
mistaking speed for system maturity
allowing Skills to create authority
using outdated Skill versions
hiding missing dependencies
creating parallel agent teams without synthesis control
using multi-agent orchestration where one qualified route is enough
allowing cost and quota use to continue without limits
hiding blocked or waiting workflow states
Any workflow showing these drift signs must be paused and reviewed.
Prohibited Patterns
MWMS prohibits:
generic-agent assignment for material work
self-approval of high-risk outputs
unlimited retries by the same failing model
assigning a rescue task without failure history
using consensus to bypass authority
allowing an unavailable reviewer to be silently replaced by an incapable one
granting broad tool access by default
embedding active credentials in skill files
allowing remote command channels to execute unrestricted actions
persistent agents without shutdown or escalation controls
routing deprecated context as current instruction
committing unverified model output as organisational truth
using expensive multi-agent workflows where one qualified route is sufficient
using cheap models where capability is insufficient
creating orchestration that produces activity without an outcome
invoking a Skill outside its approved scope
using unverified Skill installations
starting parallel work without a synthesis owner
silently replacing a missing specialist, reviewer, model or dependency
allowing a Work Unit to exceed approved cost, retry or execution limits
reporting Blocked, Waiting For Review or Rescue Required work as complete
Minimum Compliance Standard
An orchestrated workflow is compliant only when:
the request is classified
Brain ownership is assigned
the correct AI Employee is selected
an approved Skill is selected where relevant
the Skill scope and version are correct
the model or capability route is appropriate
required context is attached
dependencies and environment conditions are verified
tool permissions are defined
cost and quota boundaries are defined
workflow stages are sequenced
validation requirements are defined
independent review is used where required
repeated failure triggers rescue
the output destination is defined
human authority is preserved
parallel work has a synthesis owner where relevant
current orchestration state is visible
material events are logged
durable learning is committed where appropriate
Architectural Intent
The architectural intent of the MWMS AI Agent Orchestration Framework is to turn MWMS into a managed AI operating ecosystem.
MWMS should not depend on a single AI model, tool, platform or prompt style.
The durable value of MWMS should come from:
how work is classified
how Brains own work
how AI Employees are assigned
how models are selected
how context is assembled
how tools are governed
how workflows are sequenced
how outputs are validated
how failures are rescued
how handoffs are controlled
how decisions are reported
how learning is captured
how HeadOffice governs the system
A mature MWMS orchestration system should be able to answer:
What entered the system?
What type of work is it?
Which Brain owns it?
Which AI Employees are involved?
Which approved Skills and versions govern the work?
Which models or specialist capabilities are involved?
What dependencies and environment conditions are required?
What sequence or task graph is required?
What may run in parallel, and who owns synthesis?
What context is needed?
What tools are allowed?
What validation is required?
What happens if the route fails?
Where does the output go?
What business outcome does it support?
What cost and quota boundaries apply?
What is the current orchestration state?
What was logged?
What did MWMS learn?
When MWMS can answer those questions consistently, it has the foundation of a real AI business operating system.
Final Rule
No material AI work should begin until MWMS knows:
who owns it
who performs it
what capability is required
what approved Skill applies
what context is needed
what dependencies must exist
what tools are allowed
how it will be checked
what happens if it fails
what cost and quota boundaries apply
who owns synthesis if work is parallel
where it goes next
what outcome it supports
No material AI work should end until MWMS knows:
what was completed
what was validated
what was decided
what was routed
what was logged
what was learned
Source Absorption Basis
This v1.2 update absorbs the strongest operational material from the AI Automations by Jack course block covering:
specialist AI Agent Teams
Skill-aware orchestration
controlled Skill discovery and invocation
active Skill version and scope control
multi-model specialist routing
parallel execution
synthesis ownership
task-graph coordination
dependency and environment checks
persistent project instructions
external knowledge retrieval
controlled agentic operating systems
cost and quota limits
visible orchestration states
independent model review
deterministic repeated-failure rescue
persistent cloud and background agents
scheduled routines
remote command channels
governed tool exposure
credential custody
session closure
durable knowledge commitment
Tool-specific promotional claims and transient product combinations were not absorbed as permanent MWMS architecture.
Change Log
Version: v1.2
Date: 2026-06-20
Author: HeadOffice
Change:
Updated the MWMS AI Agent Orchestration Framework using the AI Automations by Jack block covering Claude Agent Teams, Claude Skills 2.0, AntiGravity Skills, Agent Manager, parallel specialist execution, model routing, persistent project instructions, knowledge systems and controlled agentic operating systems.
Added:
Skill Orchestration
Skill Discovery And Invocation
Dependency And Environment Orchestration
Parallel And Team Orchestration
Parallel Group Record
Agent Team Communication
Task Graph Standard
Cost And Quota Orchestration
Orchestration State Model
expanded Standard Orchestration Flow
expanded Orchestration Decision Tree
expanded Orchestrator Agent Role
expanded Failure Modes
expanded Quality Checklist
expanded Logging And Observability Requirements
expanded Governance Role
expanded Minimum Compliance Standard
Purpose of update:
To evolve the framework from a model, tool and workflow coordination system into a complete Skill-aware, dependency-aware, parallel-team, task-graph, state-controlled and cost-governed orchestration architecture for MWMS and future AIBS systems.
Version: v1.1
Date: 2026-06-17
Author: HeadOffice
Change:
Expanded the MWMS AI Agent Orchestration Framework to include model and capability routing, independent review, deterministic rescue routing, context orchestration, tool-permission orchestration, persistent-agent controls, remote command governance, external knowledge retrieval and knowledge commitment.
Change Impact Declaration
This v1.2 update expands orchestration from Brain, Employee, model, context, tool, review, rescue and knowledge coordination into a complete governed layer that also selects approved Skills, verifies dependencies, coordinates parallel AI Agent Teams, manages task graphs, controls resource usage and preserves visible Work Unit state.
Pages Created
None
Pages Updated
MWMS AI Agent Orchestration Framework
Pages Deprecated
None
Standalone Pages Not Created
MWMS AI Agent Team Orchestration Framework
MWMS Skill-Aware Orchestration Framework
MWMS Parallel Agent Execution Framework
MWMS Agent Task Graph Standard
MWMS Agent Dependency And Environment Framework
MWMS Agent Cost And Quota Orchestration Standard
MWMS Orchestration State Model
MWMS Agent Manager Framework
These concepts were absorbed into the unified MWMS AI Agent Orchestration 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 orchestration architecture that can select the correct Brain, AI Employee, approved Skill, model route, context, dependency, tool, reviewer, parallel team, synthesis owner, rescue path, quota and knowledge-commitment route while preserving human authority, visible workflow state and measurable business outcomes.
END OF FULL FILE OUTPUT