MWMS Agentic Work Unit Standard

System: MWMS
Document Type: Operating Standard
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.1
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, AI Manager, AI Employee Router, Task Executor Systems, Automation Brain, AIBS Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-17
Source / Origin: MWMS Agentic Work Unit Standard v1.0 + AI Automations by Jack — ClaudeOS, Multi-Model Routing, Persistent Agent, Independent Review, Rescue Routing, External Knowledge And Session Closure Block
MWMS Classification: AI Work Unit Governance Standard / Agentic Task Schema / AI Employee Execution Control Standard / Cross-Brain Work Routing Standard
Primary Brain: HeadOffice Brain
Supporting Brains: MWMS Brain, Automation Brain, AIBS Brain, Operations Brain, Data Brain, Risk Brain, Compliance Brain, SIT Brain
Related Pages: MWMS AI Agent Operations Core, MWMS AI Employee Role Card Standard, MWMS AI Agent Orchestration Framework, MWMS AI Agent Failure Handling And Escalation Protocol, MWMS Independent Model Review And Rescue Routing Framework, MWMS AI Agent Memory And Context Framework, MWMS External Knowledge Engine And Reasoning Agent Separation Framework, MWMS AI Work Session Closure And Knowledge Commitment Protocol, MWMS AI Tool Permission And Access Framework, MWMS AI Observability Metadata Standard, MWMS AI Usage And Cost Visibility Standard, MWMS Brain Routing Rule, MWMS Brain To Brain Request Protocol, MWMS Supabase Event Schema
Source Evidence: The existing standard defines the Agentic Work Unit as the controlled container for converting vague AI requests into assignable, trackable, validatable, routable, reportable and improvable work. It already includes ownership, AI Employee assignment, input, context, task instructions, permissions, forbidden actions, output, validation, handoff, outcome, status, priority, risk, review, logging and learning. The newly absorbed course material strengthens the standard with model and capability routing, structured agent patterns, independent review, deterministic failure counting, rescue routing, persistent and scheduled execution, remote-command control, external knowledge retrieval, cost boundaries, observability and formal knowledge commitment.

Purpose

The purpose of this document is to define the MWMS Agentic Work Unit Standard.

The MWMS Agentic Work Unit Standard establishes how any meaningful AI request, instruction, workflow, monitoring activity, automation or operational action inside MWMS is converted into a structured unit of work.

This standard exists because MWMS must not operate through:

vague AI conversations
random prompts
scattered outputs
disconnected automation steps
unowned background agents
undocumented model routing
uncontrolled retries
tasks with no validation
work with no destination
sessions with no durable outcome

MWMS is being designed as a governed AI business ecosystem.

Inside that ecosystem, every important AI action must be treated as work.

That work must have structure.

That structure must make the task:

clear
assignable
permissioned
measurable
trackable
validatable
recoverable
routable
reportable
auditable
stoppable
improvable

An Agentic Work Unit is the controlled operating container that makes this possible.

Scope

This standard applies to all MWMS workflows where AI:

performs work
supports work
validates work
routes work
retrieves evidence
monitors systems
reports outcomes
triggers automation
prepares external action
creates durable knowledge

This includes:

Brain Room requests
HeadOffice requests
AI Manager tasks
AI Employee tasks
Dev Console requests
Newsletter Intelligence workflows
Course Absorption workflows
Offer Evaluation workflows
Affiliate Brain workflows
Research Brain workflows
Experimentation Brain workflows
Finance Brain workflows
Content Brain workflows
Ads Brain workflows
Automation Brain workflows
Risk Brain workflows
Compliance Brain workflows
SIT Brain workflows
Opportunity System workflows
Brain-to-Brain requests
Supabase task records
Supabase event logs
persistent-agent tasks
scheduled routines
remote command requests
external knowledge retrieval
future client-facing AIBS workflows

This standard applies to:

manual workflows
AI-assisted workflows
controlled automated workflows
multi-agent workflows
persistent workflows
remotely triggered workflows
client-facing workflows

Manual workflows include:

user-prompted analysis
MCR page creation
course absorption
strategy work
research requests
developer support
decision support

Automated workflows include:

newsletter processing
queue routing
task execution
AI Employee processing
dashboard updates
scheduled monitoring
knowledge ingestion
post-deployment checks
future Brain Room automation
future AIBS client workflows

Core Definition

An Agentic Work Unit is a structured unit of AI work.

It converts a request, trigger, signal or system event into a governed operational task.

An Agentic Work Unit defines:

what triggered the work
who requested it
what type of work it is
which Brain owns it
which AI Employee performs it
which agent pattern applies
which model or capability route is required
what input is being used
what context is required
what source evidence applies
what tools may be used
what actions are forbidden
what output is required
what validation must occur
whether independent review is required
what happens after failure
where the output goes
what business outcome is expected
what must be logged
what knowledge should be committed
how the work is stopped or closed

An Agentic Work Unit is not merely:

a prompt
a task title
an AI reply
a database row
a workflow step
a chatbot message

It is the complete operating container for AI work inside MWMS.

Core Principle

The core principle of this standard is:

Every important AI request inside MWMS must be converted into a governed work unit before it becomes operational work.

This protects MWMS from:

vague AI execution
inconsistent outputs
poor Brain routing
missing validation
lost context
duplicated work
unmanaged AI actions
untracked decisions
unsuitable model routing
uncontrolled tool access
endless retry loops
outputs with no destination
automation drift
persistent-agent drift
silent cost growth
knowledge loss
false completion

The stronger MWMS becomes, the more important this principle becomes.

Why Agentic Work Units Matter

AI can produce output quickly.

That is not enough.

MWMS needs AI to produce useful business work.

Useful business work requires:

clear intent
defined ownership
selected context
suitable capability
repeatable process
controlled permissions
structured output
quality assurance
quality control
destination
business value
learning value
recovery logic
closure

Without Agentic Work Units, MWMS risks becoming a collection of impressive but disconnected AI outputs.

With Agentic Work Units, MWMS can operate like a managed AI workforce.

Agentic Work Unit Lifecycle

The standard lifecycle is:

Work Triggered
Request Captured
Work Classified
Brain Ownership Assigned
Risk Classified
Context Selected
Agent Pattern Selected
AI Employee Assigned
Model Or Capability Routed
Tool Permission Activated
Work Started
Output Produced
Validation Performed
Independent Review Performed Where Required
Decision Made
Output Routed
Outcome Recorded
Knowledge Committed Where Required
Work Unit Closed
Learning Captured

A work unit may move backward where:

context is missing
validation fails
ownership is wrong
permission is insufficient
review finds material problems
rescue routing is triggered

Agentic Work Unit Structure

Every important Agentic Work Unit should include the following fields.

Work Unit ID

The Work Unit ID uniquely identifies the task.

It may be:

system-generated
database-generated
project-generated
manually assigned for early workflows

The ID should remain stable through:

handoffs
retries
reviews
rescue routes
sub-workflows
completion
learning capture

Rule

A new conversation, agent or model must not create a new identity for the same continuing task unless the work has materially changed.

Work Unit Title

The Work Unit Title names the task clearly.

It should describe the work being performed, not merely the topic.

Weak title:

Newsletter Analysis

Strong title:

Extract Business-Relevant Signals From Newsletter And Route Them To The Correct Brain

Weak title:

Check Offer

Strong title:

Evaluate Affiliate Offer For Controlled-Test Suitability And HeadOffice Decision

Rule

The title must make the work purpose clear.

Work Unit Type

The Work Unit Type defines the class of work.

Examples:

Intake
Extraction
Cleaning
Classification
Retrieval
Research
Analysis
Drafting
Validation
Independent Review
Rescue
Routing
Reporting
Forecasting
Decision Support
Page Creation
Registry Update
Course Absorption
Offer Evaluation
Compliance Review
Security Review
Brain-to-Brain Handoff
Developer Support
Dashboard Update
Monitoring
Scheduled Routine
Knowledge Commitment
Learning Log
Session Closure

Rule

Work Unit Type helps MWMS route work to the correct Brain, Employee, validation path and destination.

Trigger Type

Trigger Type identifies how the work began.

Possible triggers:

user instruction
Brain Room message
HeadOffice request
scheduled event
webhook
system event
monitoring alert
failed validation
repeated failure
incoming email
uploaded file
database record
external knowledge signal
client request
remote command

Rule

Trigger Type must not be confused with approval.

A trigger starts classification.

It does not automatically authorise action.

Request Source

Request Source identifies who or what initiated the work.

Possible sources:

Martyn
HeadOffice
M
Brain Room participant
AI Manager
another Brain
AI Employee
client
scheduled system
external system
automation
monitoring agent

The request source should preserve:

identity
timestamp
channel
source system
related thread or record

Rule

Remote and automated requests must preserve the identity of the initiating source.

Source Material

Source Material identifies the evidence or content being processed.

Possible source material:

Brain Room message
course file
newsletter
email
Supabase row
WordPress page
MCR page
sales page
research source
screenshot
code file
dashboard item
system log
client record
transcript
external knowledge result

Source records should preserve:

title
location
version
date
authority
client ownership
source identity
provenance

Rule

Work must remain traceable to its source.

Originating Brain

The Originating Brain identifies where the request began.

Examples:

HeadOffice Brain
Affiliate Brain
Research Brain
Finance Brain
Content Brain
Brain Room
Course Absorption System
Opportunity System
Automation Brain
SIT Brain

The Originating Brain is not always the Owning Brain.

Rule

Origin identifies where the work came from.

Ownership identifies who is responsible for completing it.

Owning Brain

The Owning Brain is responsible for the work.

The Owning Brain must ensure:

correct workflow
correct Employee
correct standards
correct validation
correct destination
correct outcome
correct closure

An Agentic Work Unit must have one primary Owning Brain.

Supporting Brains may contribute.

Rule

Shared support is allowed.

Unclear ownership is not.

Supporting Brains

Supporting Brains contribute specialist knowledge or review.

Examples:

Research Brain
Finance Brain
Compliance Brain
Risk Brain
Experimentation Brain
Data Brain
SIT Brain

Supporting Brains must have defined responsibilities.

Rule

Adding a Supporting Brain must improve the work rather than create unnecessary orchestration.

Assigned AI Employee

The Assigned AI Employee is the role responsible for performing the task.

Examples:

Orchestrator Agent
Task Builder Agent
Signal Extraction Agent
Research Agent
Validation Agent
Finance Analysis Agent
Compliance Review Agent
Course Absorption Agent
Offer Evaluation Agent
Independent Model Review Agent
Workflow Rescue Agent
Monitoring Agent
Knowledge Retrieval Agent

The Employee must have:

a valid Role Card
suitable authority
required capability
required tools
defined output
defined escalation
defined failure handling

Rule

No Agentic Work Unit should be assigned to a vague “AI” identity.

Agent Pattern

Agent Pattern defines how many roles participate and how they are organised.

Approved patterns include:

Single Agent
Agent Plus Checker
Router Plus Specialist
Research Plus Synthesis
Multi-Specialist Plus Synthesis Plus Checker
Master Agent Plus Sub-Workflows
Primary Agent Plus Independent Reviewer
Primary Agent Plus Rescue Route

The selected pattern should be justified by:

task complexity
risk
need for specialist input
need for independent review
workflow scale
expected business value

Rule

Use the simplest agent pattern that reliably produces the required outcome.

Model Or Capability Route

Model Or Capability Route defines the reasoning or processing capability required.

Possible routes include:

advanced reasoning model
long-context model
multimodal model
coding model
research model
local private model
low-cost bulk-processing model
independent reviewer
rescue model
deterministic validator
external knowledge engine

The route must consider:

capability
risk
privacy
cost
modality
context length
tool compatibility
reviewer independence

Rule

Model selection must be based on task requirements, not convenience alone.

Authority Level

Authority Level defines how much operational power the work unit allows.

Possible authority levels:

Advisory
Operational Drafting
Controlled Execution
Supervised Automation
Restricted Autonomous Action

Authority must match:

AI Employee Role Card
risk
tool permission
approval state
workflow stage

Rule

A task cannot grant authority beyond the Employee’s approved Role Card.

Input Payload

Input Payload contains the direct material supplied to the Employee.

Examples:

newsletter body
transcript
offer details
user request
task record
source files
campaign data
error log
failed output
client intake
monitoring result

The Input Payload should be:

complete
structured where practical
traceable
validated where required
separated from system instructions

Rule

The work unit must not rely on hidden assumptions where required input can be defined.

Context Pack

The Context Pack contains the selected background needed for correct work.

It may include:

relevant Brain rules
related MCR pages
previous decisions
active save points
current system state
user preferences
developer boundaries
role card
tool permissions
known risks
workflow stage
failure history
client context
source-of-truth hierarchy
related standards

The Context Pack should identify:

what is current
what is memory
what is source of truth
what is retrieved
what must be ignored
what is sensitive

Rule

Use the right context for the task, not all available memory.

External Knowledge Requirement

This field defines whether the task requires an external knowledge engine.

Possible values:

Not Required
Optional
Required
Required With Human Review

Where required, define:

knowledge source
retrieval query
source filters
client boundary
authority filters
freshness requirements
provenance requirements
fallback
retrieval failure behaviour

Rule

Retrieval supports reasoning.

It does not replace authority or source validation.

Task Instruction

Task Instruction states exactly what must be done.

It should define:

action
depth
expected output
constraints
prohibited behaviour
intended use
decision required
stopping condition

Weak instruction:

Look at this and tell me what you think.

Strong instruction:

Evaluate this course block for reusable MWMS operational value. Compare it against current MCR pages, absorb only superior material, identify updates before new pages, preserve existing governance, and produce full file output only when a justified page action is approved.

Rule

Task instructions must reduce ambiguity.

Tool Permission

Tool Permission defines what tools may be used.

Possible permissions include:

no external tools
uploaded files only
MCR read access
web research
database read
database controlled write
WordPress read
WordPress controlled write
Gmail draft
Gmail send with approval
MCP function access
local CLI access
browser automation
file generation
external knowledge retrieval

Tool permission must define:

permission level
permitted systems
approved endpoints
approved data
prohibited data
client boundary
approval
logging
revocation

Rule

AI Employees must not assume tool access merely because a tool is available.

Forbidden Actions

Forbidden Actions define what must not occur.

Examples:

do not change live systems
do not send external communication
do not create public content
do not alter MCR without approval
do not access another client’s data
do not invent missing evidence
do not expose credentials
do not bypass validation
do not interfere with M’s active work
do not absorb weak material
do not create duplicate pages
do not reset the failure count without verified progress
do not expand permissions during rescue
do not commit unverified knowledge
do not continue after emergency shutdown

Rule

Forbidden Actions are mandatory drift protection.

Required Output Format

Required Output Format defines how the result must be delivered.

Examples:

full page output
structured summary
verdict report
JSON record
dashboard card
task record
registry entry
developer brief
Brain-to-Brain handoff
validation report
review report
rescue plan
monitoring alert
knowledge commitment record
session closure record

The format should define:

required fields
structure
level of detail
destination
status label

Rule

The output format must be known before work begins.

Output Destination

Output Destination identifies where the produced work is first delivered.

Examples:

HeadOffice review
Brain Room
AI Manager
MCR draft
task queue
dashboard queue
another Agent
Independent Review Agent
client draft area
developer handoff
external knowledge engine

Output Destination differs from final Handoff Destination.

The first destination may be validation.

The final destination may be operational use.

Validation Standard

Validation Standard defines how the output is checked.

Validation may include:

completeness
accuracy
source grounding
usefulness
Brain routing
format
risk
compliance
security
duplication
naming
parent page
developer boundary
outcome
context sufficiency
model suitability
tool permission
cost
handoff
knowledge commitment

Rule

Validation strength must match the importance and risk of the work.

Independent Review Requirement

This field defines whether the producing route may validate its own work.

Possible values:

Not Required
Recommended
Mandatory
Mandatory Plus Human Review

Independent review is normally mandatory where the work affects:

MCR
Canon
governance
finance
compliance
security
live systems
external communication
public content
client delivery
irreversible action
high-risk decisions

The review route should define:

reviewer
model independence
specialist requirement
evidence available
disagreement handling
final authority

Rule

The producing route must not be the sole final reviewer of high-risk work.

Failure Threshold

Failure Threshold defines when the current route must stop.

The standard MWMS threshold is:

Two materially identical failures without verified progress.

A failure may include:

same test failure
same command error
same validation rejection
same user correction ignored
same output defect
same unsuccessful edit
same unresolved tool failure

The failure count does not reset because:

wording changed
a new chat started
the same model claims better understanding
the command was reformatted
confidence increased

Rule

Repeated failure triggers rescue.

It does not authorise endless retry.

Rescue Route

Rescue Route defines where failed work goes after the threshold.

Possible routes:

different model family
specialist AI Employee
deterministic validator
SIT Brain
HeadOffice
M
Martyn
human review

The rescue packet should include:

original task
expected outcome
input
context
source material
attempts
errors
outputs
tools used
validation failures
current state
applicable Canon
next verification gate

Rule

The rescue route must use a materially different approach.

Risk Level

Risk Level defines possible damage if the work is wrong.

Recommended levels:

Low

Examples:

brainstorming
internal notes
non-canonical drafts

Moderate

Examples:

internal reports
page drafts
research summaries
internal task creation

High

Examples:

offer decisions
financial recommendations
compliance analysis
developer instructions
client-facing drafts
public content

Critical

Examples:

live system change
financial transaction
production deployment
irreversible data action
external legal or regulated communication
destructive administration

Rule

Higher risk requires stronger validation, review, logging and human authority.

Priority

Priority defines urgency and business importance.

Recommended levels:

Critical
High
Medium
Low
Parking Lot

Priority should consider:

revenue effect
system stability
compliance
M’s build progress
current blocker
client impact
strategic dependency
time sensitivity

Rule

Interesting does not automatically mean high priority.

Human Review Requirement

Human review is required where work involves:

MCR updates
Canon changes
live systems
paid traffic
financial decisions
compliance-sensitive output
public content
client delivery
external sending
destructive database action
production deployment
permission expansion
unresolved reviewer disagreement

Possible settings:

Not Required
Required Before Finalisation
Required Before External Action
Required Before Write
Required Before Canon Change
Required Before Client Delivery

Rule

Human review protects MWMS from over-trusting AI output.

Approval Status

Approval Status identifies whether the task or action is authorised.

Possible states:

Not Required
Pending
Approved
Approved With Conditions
Rejected
Expired
Revoked

Approval should record:

approver
date
scope
conditions
expiry
action authorised

Rule

Approval for one action does not automatically approve later actions.

Status

Recommended Work Unit statuses:

New
Awaiting Classification
Classified
Awaiting Context
Ready
Assigned
In Progress
Awaiting Tool Access
Awaiting Review
Failed Validation
Rescue Required
Rescued
Waiting For Human Review
Approved
Routed
Parked
Rejected
Completed
Knowledge Pending
Closed
Archived

Rule

Status must describe current reality.

Drafted is not published.

Prepared is not executed.

Executed is not verified.

Persistent Operation Status

Persistent Operation Status defines whether the Work Unit is:

Session-Bound
On-Demand
Scheduled
Background
Persistent
Remotely Triggered

Persistent work must define:

environment
owner
schedule or trigger
maximum runtime
maximum execution count
cost limit
notification
monitoring
failure threshold
shutdown
review date

Rule

Persistent work requires stronger control than session-bound work.

Trigger Or Schedule

Where relevant, define:

Trigger:

Schedule:

Frequency:

Start Date:

Expiry Date:

Maximum Executions:

Allowed Source:

Duplicate Protection:

Failure Notification:

Rule

Scheduled work must not remain active indefinitely without review.

Remote Command Boundary

Where a work unit may be created remotely, define:

approved channel
authenticated sender
permitted task types
prohibited task types
risk limit
approval rules
tool limits
external-action limits
logging
revocation

Rule

Remote input does not bypass normal authority.

Cost Boundary

Cost Boundary defines acceptable resource use.

It may include:

preferred model tier
maximum task cost
maximum number of agent calls
maximum tool calls
maximum runtime
daily limit
monthly limit
escalation threshold

Cost must be proportional to:

business value
risk
complexity
required quality

Rule

A more complex workflow must justify its added cost.

Event Log Requirement

Every important Agentic Work Unit should create an event trail.

Events may include:

work unit created
classification completed
owner assigned
Employee assigned
context loaded
model selected
tools activated
work started
output generated
validation completed
review completed
failure recorded
rescue triggered
human approval recorded
handoff completed
outcome recorded
knowledge committed
work closed
access revoked

Rule

Event logs make AI work auditable and improvable.

Observability Requirement

Observability defines what HeadOffice, SIT or the Owning Brain must be able to see.

Possible fields:

current status
current stage
assigned Employee
model route
tools used
runtime
token or cost estimate
failure count
last error
validation status
review status
approval status
destination
final outcome
knowledge-commitment status
shutdown state

Rule

High-risk or persistent work must not operate invisibly.

Handoff Destination

Handoff Destination defines where the validated result goes.

Possible destinations:

HeadOffice Dashboard
Brain Room
Newsletter Queue Review
Routed Actions
MCR page
Brain page
Supabase task table
event log
Google Sheet
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
Automation Brain
Risk Brain
Compliance Brain
SIT Brain
human review queue
Parking System
archive
client delivery
developer handoff
external knowledge engine

Rule

No important work unit should end with an output floating in space.

Business Outcome

Business Outcome defines the practical result supported.

Examples:

decision made
task created
opportunity rejected
opportunity parked
offer moved to research
campaign candidate approved
report created
risk flagged
page updated
course insight absorbed
weak content ignored
developer brief prepared
monitoring alert created
client workflow improved
failure recovered
knowledge committed

Rule

The outcome proves whether the AI work mattered.

Outcome Verification

Outcome Verification confirms that the intended result actually occurred.

Possible verification:

user confirmation
database record
published page
completed task
passing test
validated file
approved report
successful handoff
system state check
client acceptance

Rule

Claimed completion must be supported by evidence.

Knowledge Commitment Requirement

This field defines whether the work creates durable knowledge.

Possible values:

None
Session Summary Only
Project Memory Update
Decision Record
Failure Record
Learning Record
Brain Page Update
MCR Update
External Knowledge Engine Update

Knowledge commitment should define:

destination
owner
source
authority
validation
duplicate check
approval
version
status

Rule

Producing an output and committing durable knowledge are separate actions.

Learning Record

A Learning Record captures reusable insight from completed work.

Examples:

recurring pattern
routing improvement
prompt improvement
validation problem
bad source pattern
employee role improvement
tool-permission issue
workflow weakness
compliance risk
business opportunity
rescue lesson
cost inefficiency
persistent-agent issue

Possible destinations:

Kaizen Log
Brain Canon
System Change Log
Course Absorption Decision Registry
Experimentation records
Research records
AI Employee Role Card
Failure Log
Tool Permission Record

Rule

Learning must be routed to the correct durable destination.

Closure Record

A Work Unit Closure Record should include:

Final Status:

Outcome:

Outcome Verification:

Validation Status:

Independent Review Status:

Human Approval Status:

Handoff Completed:

Knowledge Committed:

Learning Captured:

Open Issues:

Next Action:

Closed By:

Closure Date:

Rule

A work unit is not closed merely because an AI response was produced.

Default Agentic Work Unit Template

Work Unit ID:

Work Unit Title:

Work Unit Type:

Trigger Type:

Request Source:

Source Material:

Originating Brain:

Owning Brain:

Supporting Brains:

Assigned AI Employee:

Agent Pattern:

Model Or Capability Route:

Authority Level:

Input Payload:

Context Pack:

External Knowledge Requirement:

Task Instruction:

Tool Permission:

Forbidden Actions:

Required Output Format:

Output Destination:

Validation Standard:

Independent Review Requirement:

Failure Threshold:

Rescue Route:

Risk Level:

Priority:

Human Review Requirement:

Approval Status:

Status:

Persistent Operation Status:

Trigger Or Schedule:

Remote Command Boundary:

Cost Boundary:

Event Log Requirement:

Observability Requirement:

Handoff Destination:

Business Outcome:

Outcome Verification:

Knowledge Commitment Requirement:

Learning Record Requirement:

Closure Requirement:

This template may be simplified for low-risk manual tasks.

It must not be reduced for:

high-risk work
MCR work
developer work
financial work
compliance work
client-facing work
tool-enabled work
persistent work
remote work
multi-agent work
production activity

Example: Newsletter Intelligence Work Unit

Work Unit ID:

System Generated

Work Unit Title:

Extract Business-Relevant Signals From Newsletter And Route To Correct Brain

Work Unit Type:

Extraction / Classification / Routing

Trigger Type:

Incoming Newsletter

Request Source:

Newsletter Intelligence Workflow

Source Material:

Newsletter subject, sender, date, body and metadata

Originating Brain:

HeadOffice Newsletter Intelligence

Owning Brain:

HeadOffice Brain

Supporting Brains:

Determined by signal category

Assigned AI Employee:

Newsletter Signal Extraction Agent

Agent Pattern:

Router Plus Specialist

Model Or Capability Route:

Low-cost extraction model with stronger validation model for high-impact signals

Authority Level:

Operational Drafting

Context Pack:

Newsletter Intelligence Operating Protocol, Brain Routing Rule, Output Validation Protocol, current trend context

Task Instruction:

Extract specific business-relevant intelligence only. Ignore generic news. Identify useful tools, market signals, compliance concerns, monetisation opportunities and Brain-routing implications.

Tool Permission:

Newsletter input, approved AI processing and controlled internal record creation

Forbidden Actions:

Do not create downstream action without review. Do not mark generic content urgent. Do not invent unavailable details.

Required Output Format:

Structured queue record

Validation Standard:

Specificity, usefulness, source grounding, correct Brain route, action classification and confidence

Independent Review Requirement:

Required for high-priority signals

Failure Threshold:

Two materially identical extraction failures

Rescue Route:

Alternative model or human review

Risk Level:

Moderate

Priority:

Based on urgency and business impact

Human Review Requirement:

Required before downstream action

Status:

New

Event Log Requirement:

Required

Handoff Destination:

Newsletter Queue Review and HeadOffice Dashboard

Business Outcome:

Useful intelligence routed for review, action, monitoring, testing or parking

Knowledge Commitment Requirement:

Required only for durable recurring patterns or strategic signals

Example: Course Absorption Work Unit

Work Unit ID:

System Or Session Generated

Work Unit Title:

Evaluate Course Block For Reusable MWMS System Value

Work Unit Type:

Course Absorption / Framework Extraction / MCR Mapping

Trigger Type:

Uploaded Course Block

Request Source:

Martyn

Source Material:

Uploaded transcript, PDF, lesson page, skill file or support document

Originating Brain:

Course Absorption System

Owning Brain:

HeadOffice Brain

Supporting Brains:

Relevant Brain based on absorbed subject

Assigned AI Employee:

Course Absorption Agent

Agent Pattern:

Research Plus Synthesis or Agent Plus Checker depending on complexity

Model Or Capability Route:

Long-context reasoning model with independent review for MCR updates

Authority Level:

Operational Drafting

Context Pack:

Course Absorption Operating Rule, current MCR inventory, existing related pages, anti-duplication rules, active course save point, full file output rules

External Knowledge Requirement:

Only where current external verification is required

Task Instruction:

Extract only superior, reusable MWMS operational value. Compare material against existing MCR pages. Update before creating new pages. Ignore hype and weak tool-specific material. Verify parent pages before final output.

Tool Permission:

Uploaded files, MCR search and approved external verification where needed

Forbidden Actions:

Do not invent pages. Do not assume parents. Do not duplicate frameworks. Do not absorb weak content. Do not interfere with M’s active development.

Required Output Format:

Absorption verdict, page-update decision or complete full file output

Validation Standard:

Source grounding, non-duplication, Brain mapping, parent verification, practical value and correct format

Independent Review Requirement:

Required for major governance or MCR updates

Failure Threshold:

Two materially identical source, structure or validation failures

Rescue Route:

Different reasoning route, direct source review or HeadOffice review

Risk Level:

Moderate to High

Human Review Requirement:

Required before permanent MCR publication

Event Log Requirement:

Required for absorbed material

Handoff Destination:

MCR, Brain Blueprint, Course Absorption Decision Registry or Parking System

Business Outcome:

MWMS improves through superior material or weak material is rejected

Knowledge Commitment Requirement:

Required where material is absorbed

Closure Requirement:

Exact course save point and next action must be recorded

Example: Brain Room Work Unit

Work Unit ID:

System Generated

Work Unit Title:

Convert Brain Room Message Into Structured AI Work

Work Unit Type:

Intake / Classification / Task Creation

Trigger Type:

Brain Room Message

Request Source:

Authenticated Brain Room Participant

Originating Brain:

Brain Room

Owning Brain:

Determined by classification

Assigned AI Employee:

Brain Room Task Builder Agent

Agent Pattern:

Router Plus Specialist

Authority Level:

Operational Drafting

Input Payload:

Message, sender, timestamp and thread context

Context Pack:

Brain Routing Rule, Brain-to-Brain Request Protocol, current priorities, active development boundaries

Task Instruction:

Classify the request, assign ownership, identify missing context, define the work unit, select the appropriate Employee and determine review requirements.

Tool Permission:

Brain Room read and controlled task creation only

Forbidden Actions:

Do not execute live changes. Do not bypass HeadOffice. Do not assign work into M’s active build unless explicitly authorised.

Required Output Format:

Structured Agentic Work Unit

Validation Standard:

Ownership, clarity, context, risk, permissions and handoff

Human Review Requirement:

Based on risk

Event Log Requirement:

Required

Handoff Destination:

AI Manager, Task Executor or human review queue

Business Outcome:

Brain Room discussion becomes trackable work

Example: Offer Evaluation Work Unit

Work Unit ID:

System Generated

Work Unit Title:

Evaluate Affiliate Offer For Controlled-Test Suitability

Work Unit Type:

Offer Evaluation / Research / Decision Support

Trigger Type:

Offer Intake

Request Source:

Martyn or Affiliate Brain

Originating Brain:

Affiliate Brain

Owning Brain:

Affiliate Brain

Supporting Brains:

Research Brain, Finance Brain, Compliance Brain, Ads Brain, Experimentation Brain

Assigned AI Employee:

Offer Evaluation Agent

Agent Pattern:

Multi-Specialist Plus Synthesis Plus Checker

Model Or Capability Route:

Research-capable primary route, specialist review and HeadOffice decision

Authority Level:

Operational Drafting

Input Payload:

Offer, network, payout, funnel, traffic source, vendor data and available metrics

Context Pack:

Affiliate protocols, current budget rules, compliance rules, traffic strategy and Experimentation Brain rules

Task Instruction:

Evaluate test suitability using evidence, market demand, mechanism, funnel, traffic fit, compliance, financial logic and testing readiness.

Tool Permission:

Approved web research and supplied source material

Forbidden Actions:

Do not approve spend. Do not invent performance. Do not rely on hype. Do not bypass required Brain reviews.

Required Output Format:

YES / Conditional YES / NO verdict with reasons and next action

Validation Standard:

Source quality, mechanism, traffic fit, compliance, financial logic and testability

Independent Review Requirement:

Required

Risk Level:

High

Human Review Requirement:

Required before testing

Event Log Requirement:

Required

Handoff Destination:

HeadOffice decision, Research, Finance, Experimentation or Offer Graveyard

Business Outcome:

Offer is rejected, parked, researched or moved toward controlled testing

Knowledge Commitment Requirement:

Required where strategic learning is produced

Example: Persistent Monitoring Work Unit

Work Unit ID:

System Generated

Work Unit Title:

Run Scheduled Integrity And Agent Health Check

Work Unit Type:

Monitoring / Validation / Alerting

Trigger Type:

Schedule

Request Source:

SIT Brain

Originating Brain:

SIT Brain

Owning Brain:

SIT Brain

Supporting Brains:

Operations Brain, Automation Brain, HeadOffice Brain

Assigned AI Employee:

Persistent System Monitoring Agent

Agent Pattern:

Single Agent Plus Checker For Critical Alerts

Model Or Capability Route:

Low-cost deterministic monitoring with specialist review for anomalies

Authority Level:

Supervised Automation

Input Payload:

System health, task failures, queue state, logs and permission signals

Context Pack:

SIT standards, failure thresholds, authority rules and active system inventory

Task Instruction:

Run approved checks, identify exceptions, preserve evidence, classify severity and create alerts. Do not perform broad remediation.

Tool Permission:

Read-only system access and controlled append-only logging

Forbidden Actions:

Do not deploy. Do not change production. Do not revoke permissions. Do not continue silently after repeated failure.

Required Output Format:

Health record and alert where needed

Validation Standard:

Check completion, evidence, severity accuracy and duplicate alert prevention

Failure Threshold:

Two materially identical monitoring failures

Rescue Route:

Alternative monitoring route, M or HeadOffice

Persistent Operation Status:

Scheduled

Trigger Or Schedule:

Approved recurring schedule

Cost Boundary:

Low-cost execution within approved monthly limit

Event Log Requirement:

Required

Observability Requirement:

Last run, current status, failed checks, alert count, cost and shutdown state

Handoff Destination:

SIT log, HeadOffice alert or M technical review

Business Outcome:

System integrity issues become visible before damage expands

Knowledge Commitment Requirement:

Required for repeated failure patterns

Closure Requirement:

Each execution closes individually while the scheduled work definition remains active

Governance Role

HeadOffice owns this standard.

HeadOffice is responsible for ensuring Agentic Work Units are used for important AI work across MWMS.

Individual Brains may adapt the structure for their workflows, but they must not remove the core requirements of:

ownership
task clarity
Employee assignment
agent pattern
model route
context
tool permission
risk
validation
failure handling
rescue
handoff
outcome
logging
knowledge commitment
closure

No Brain should create AI workflows that bypass this standard when the work affects:

business decisions
MCR
system structure
client outputs
public content
live operations
development
finance
compliance
security
persistent automation

Relationship To SIT Brain

SIT Brain may:

validate Work Unit completeness
detect missing ownership
detect role-card mismatch
detect permission drift
detect model-routing drift
verify independent review
enforce failure thresholds
trigger rescue routing
detect false completion
verify outcome evidence
inspect persistent-work controls
verify shutdown
block unsafe execution
inspect knowledge commitment

Relationship To Data Brain

Data Brain supports:

Work Unit IDs
schemas
event records
source provenance
client isolation
context storage
status history
observability metadata
outcome records
knowledge commitment
archive and retention

Relationship To Other MWMS Standards

This document supports and must align with:

MWMS AI Agent Operations Core
MWMS AI Employee Role Card Standard
MWMS AI Agent Orchestration Framework
MWMS AI Agent Failure Handling And Escalation Protocol
MWMS Independent Model Review And Rescue Routing Framework
MWMS AI Agent Memory And Context Framework
MWMS External Knowledge Engine And Reasoning Agent Separation Framework
MWMS AI Work Session Closure And Knowledge Commitment Protocol
MWMS AI Tool Permission And Access Framework
MWMS AI Observability Metadata Standard
MWMS AI Usage And Cost Visibility Standard
MWMS Canon Session Protocol
MWMS AI Session Context Lock Rule
MWMS AI Output Standard Full File Delivery Rule
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
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

Drift Protection

This standard protects MWMS from:

treating prompts as completed work
vague requests entering operations
AI work without Brain ownership
undefined AI Employees
unsuitable model routing
missing context
uncontrolled tools
outputs without validation
self-review of high-risk work
repeated failure loops
missing rescue routes
outputs without destination
false completion
activity without outcome
uncontrolled persistent work
remote commands bypassing authority
cost without limits
missing event logs
knowledge disappearing after sessions
weak material becoming durable knowledge
client data losing its boundary
dashboards filled with unvalidated information
automation being mistaken for business progress
course material entering MCR without value testing

Any workflow violating this standard should be paused, reviewed, simplified or redesigned.

Agentic Work Unit Drift Signals

MWMS should watch for:

no Work Unit ID
unclear title
no owner
vague Assigned AI Employee
missing Role Card
unsuitable agent pattern
model chosen without justification
required context absent
tool permissions undefined
risk not classified
human review skipped
independent review missing
repeated failures not counted
rescue not triggered
status does not reflect reality
output has no handoff
claimed outcome has no verification
persistent work has no shutdown
remote request lacks authenticated source
cost cannot be seen
knowledge commitment is unverified
Work Unit closes without save point or next action

Rule

Work Unit drift must be corrected before authority or automation increases.

Minimum Compliance Standard

An important Agentic Work Unit is compliant only when it defines:

Work Unit ID
title
type
trigger
request source
source material
Originating Brain
Owning Brain
Assigned AI Employee
agent pattern
model or capability route
authority
input
context
task instruction
tool permission
forbidden actions
output format
validation
independent review where required
failure threshold
rescue route
risk
priority
human review
approval
status
persistent-operation status
cost boundary where relevant
logging
observability
handoff
business outcome
outcome verification
knowledge commitment
closure

Architectural Intent

The architectural intent of the MWMS Agentic Work Unit Standard is to make AI work manageable at scale.

MWMS will eventually contain:

many Brains
many AI Employees
many workflows
dashboards
task systems
client systems
persistent agents
model routes
external knowledge systems
automation layers
remote command channels

Without a standard Work Unit, the system will become difficult to govern.

With a standard Work Unit, MWMS can scale AI work while keeping:

ownership clear
tasks structured
context controlled
model routing appropriate
permissions limited
outputs consistent
validation enforceable
failures recoverable
handoffs visible
reports useful
costs observable
actions traceable
knowledge reusable
shutdown possible

The long-term goal is that every meaningful AI action can answer:

What triggered this work?
Who requested it?
What type of work is it?
Which Brain owns it?
Which AI Employee performed it?
Which agent pattern was used?
Which model or capability route was used?
What input was used?
What context was applied?
What tools were permitted?
What output was required?
What validation was performed?
Was independent review required?
What happened after failure?
Where did the result go?
What outcome did it support?
Was the outcome verified?
What was logged?
What knowledge was committed?
How was the work closed?

When MWMS can answer those questions consistently, it is no longer simply using AI.

It is operating a governed AI workforce.

Strategic Summary

The v1.1 upgrade expands the Agentic Work Unit Standard from a task-structure template into a complete operational control record.

The upgraded Work Unit now governs:

trigger identity
source provenance
agent pattern
model and capability routing
authority
external knowledge retrieval
tool permissions
independent review
deterministic failure thresholds
rescue routes
persistent execution
remote commands
cost
observability
outcome verification
knowledge commitment
closure

The key shift is:

An AI task is not complete merely because a model generated an answer.

It is complete only when the work is:

owned
structured
permissioned
validated
routed
outcome-linked
verified
logged
closed

Final Rule

Every important MWMS AI request must become a governed Agentic Work Unit before it becomes operational work.

Every Work Unit must know:

who owns it
who performs it
what context it uses
which model or capability it requires
which tools it may use
what it must not do
how it is validated
when it must stop
how failure is rescued
where the output goes
what business outcome it supports
what is logged
what becomes durable knowledge
how the Work Unit closes

The final standard is:

No ownership, no work.

No role, no assignment.

No context, no reliable execution.

No permission, no tool use.

No validation, no trust.

No rescue route, no repeated automation.

No destination, no completion.

No verified outcome, no progress claim.

No closure, no durable continuity.

Change Log

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

Change:

Updated the MWMS Agentic Work Unit Standard using the AI Automations by Jack block covering ClaudeOS, multi-model orchestration, independent model review, deterministic rescue routing, persistent agents, remote command channels, external knowledge systems, operational monitoring, cost control and session closure.

Added Work Unit ID.

Added Trigger Type.

Added Request Source.

Expanded Source Material and source-provenance requirements.

Added Supporting Brains.

Added Agent Pattern.

Added Model Or Capability Route.

Added Authority Level.

Added External Knowledge Requirement.

Expanded Tool Permission.

Added Output Destination.

Added Independent Review Requirement.

Added Failure Threshold.

Added Rescue Route.

Expanded Human Review Requirement.

Added Approval Status.

Expanded Status values.

Added Persistent Operation Status.

Added Trigger Or Schedule.

Added Remote Command Boundary.

Added Cost Boundary.

Expanded Event Log Requirement.

Added Observability Requirement.

Added Outcome Verification.

Added Knowledge Commitment Requirement.

Added Closure Record.

Expanded the Default Agentic Work Unit Template.

Added Persistent Monitoring Work Unit example.

Expanded Newsletter Intelligence, Course Absorption, Brain Room and Offer Evaluation examples.

Added Relationship To SIT Brain.

Added Relationship To Data Brain.

Expanded Governance Role, Drift Protection, Drift Signals, Minimum Compliance Standard, Architectural Intent, Strategic Summary and Final Rule.

Aligned this update with:

MWMS AI Agent Operations Core
MWMS AI Employee Role Card Standard
MWMS AI Agent Orchestration Framework
MWMS AI Agent Failure Handling And Escalation Protocol
MWMS Independent Model Review And Rescue Routing Framework
MWMS AI Agent Memory And Context Framework
MWMS External Knowledge Engine And Reasoning Agent Separation Framework
MWMS AI Work Session Closure And Knowledge Commitment Protocol
MWMS AI Tool Permission And Access Framework
MWMS AI Observability Metadata Standard
MWMS AI Usage And Cost Visibility Standard

Purpose of update:

To evolve the MWMS Agentic Work Unit Standard from a basic AI task structure into the complete operating record for governed, multi-agent, independently reviewed, persistent, observable, failure-resilient and outcome-verified AI work across MWMS and future AIBS client systems.

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

Change:

Created the MWMS Agentic Work Unit Standard as the operating structure for converting AI requests into controlled, assignable, validatable, routable, reportable and outcome-based work units.

Change Impact Declaration

This v1.1 update expands the Agentic Work Unit from a structured task container into the complete governance record for AI execution, including model routing, review independence, failure rescue, persistent operation, remote triggers, cost visibility, outcome verification, knowledge commitment and formal closure.

Pages Created

None

Pages Updated

MWMS Agentic Work Unit Standard

Pages Deprecated

None

Standalone Pages Not Created

MWMS ClaudeOS Task Standard
MWMS Persistent Agent Work Unit Standard
MWMS Remote Command Work Unit Standard
MWMS Multi-Model Task Schema
MWMS AI Rescue Task Record Standard
MWMS Session Closure Work Unit Standard
MWMS External Knowledge Retrieval Task Standard

Registries Requiring Update

HeadOffice Page Registry
MWMS Canon Index
MWMS Course Absorption Decision Registry

Canon Version Update Required

Change Log Entry Required

Strategic Absorption Result

MWMS gains a stronger Agentic Work Unit structure that governs the complete lifecycle of AI work from trigger and ownership through model routing, permissions, validation, failure rescue, persistent execution, observability, verified outcome, durable knowledge commitment and final closure.

END OF FULL FILE OUTPUT