MWMS AI Employee Role Card Standard

System: MWMS
Document Type: Operating Standard
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-17
Source / Origin: MWMS AI Employee Role Card Standard v1.1 + AI Automations by Jack — ClaudeOS, Multi-Model Routing, Persistent Agent, External Knowledge, Skills And Session Closure Block
MWMS Classification: AI Employee Governance Standard / Role Definition Standard / AI Workforce Control Framework / Persistent AI Employee Role 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 Operating System Architecture Framework, MWMS Context Engineering Framework, MWMS AI Automation Security And Risk Checklist, MWMS Constraint Based Learning And Build Focus Rule, MWMS AI Agent Operations Core, MWMS Agentic Work Unit Standard, MWMS Brain Routing Rule, MWMS Brain To Brain Request Protocol, MWMS AI Output Standard Full File Delivery Rule, MWMS Supabase Event Schema, MWMS AI Agent Orchestration Framework, MWMS AI Agent Failure Handling And Escalation 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 Memory And Context Framework, MWMS AI Tool Permission And Access Framework, MWMS AI Observability Metadata Standard, MWMS AI Usage And Cost Visibility Standard
Source Evidence: The existing MWMS AI Employee Role Card Standard defines role cards as the source of truth for AI Employee identity, ownership, responsibilities, inputs, outputs, tools, prohibited actions, escalation, validation, security, logging and success measurement. The newly absorbed course block strengthens the standard with model and capability routing, independent review, deterministic rescue routing, persistent-agent controls, scheduled work, remote command boundaries, external knowledge-engine use, session closure, knowledge commitment, observability, cost controls and shutdown requirements.

Purpose

The purpose of this document is to define the MWMS AI Employee Role Card Standard.

This standard establishes how every formal AI Employee inside MWMS must be:

described
owned
governed
scoped
assigned
routed
validated
monitored
measured
escalated
stopped
improved

MWMS is not building a loose collection of AI prompts.

MWMS is building a governed AI workforce.

A workforce requires defined roles.

A defined AI role requires:

a clear position
an owning Brain
defined responsibilities
explicit non-responsibilities
authority boundaries
task boundaries
context requirements
approved model and capability routes
tool permissions
output expectations
validation rules
independent-review requirements
failure thresholds
rescue routes
handoff destinations
reporting lines
logging requirements
cost boundaries
shutdown controls
knowledge-commitment rules
improvement loops

The AI Employee Role Card is the standard structure that makes this possible.

Without role cards, AI Employees can:

drift
overlap
duplicate work
bypass governance
produce inconsistent outputs
use unsuitable models
use tools without permission
repeat failed actions
operate persistently without control
lose handoff context
commit weak material as truth
create cost without measurable value
act outside their intended purpose

With role cards, each AI Employee becomes easier to:

understand
assign
route
validate
audit
monitor
improve
revoke
implement technically
connect to measurable outcomes

The v1.1 upgrade added stronger requirements for:

context engineering
AI Operating System alignment
system-message and user-input separation
tool-permission boundaries
security and risk awareness
AIOS maturity alignment
role-based governance

The v1.2 upgrade adds:

model and capability requirements
agent-pattern classification
independent-review rules
failure counters
rescue routes
persistent-operation controls
schedule and trigger rules
remote command boundaries
external knowledge-engine use
session closure
knowledge commitment
observability
cost limits
revocation and shutdown requirements

Scope

This standard applies to every formal:

AI Employee
AI agent
assistant
workflow worker
reviewer
router
validator
checking agent
synthesis agent
rescue agent
persistent agent
background worker
scheduled agent
remote-command worker
automation-support role

created inside MWMS.

This includes AI Employees used by:

HeadOffice Brain
MWMS Brain
AIBS Brain
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
Data Brain
Strategy Brain
Operations Brain
Automation Brain
Risk Brain
Compliance Brain
SIT Brain
Brain Room
Dev Console
AI Manager
AI Employee Router
Task Executor systems
Newsletter Intelligence
Course Absorption
Opportunity System
client-facing AI Operating Systems
persistent monitoring systems
external knowledge systems
remote operations

This standard applies before an AI Employee becomes part of:

a live workflow
a dashboard
an automation
a task queue
a plugin
a client-facing system
a persistent background service
a remote command route
an autonomous or semi-autonomous process

No formal AI Employee should enter serious MWMS use without a role card.

Core Definition

An AI Employee Role Card is the official operating profile for an AI Employee inside MWMS.

It defines:

who the AI Employee is
which Brain owns it
what it is responsible for
what it is not responsible for
what authority it has
what inputs it accepts
what context it requires
what model or capability it may use
what tools it may use
what outputs it produces
what it must never do
how its work is validated
whether independent review is required
where its outputs go
when it must stop
when it must escalate
what happens after repeated failure
whether it may operate persistently
how it is monitored
how success is measured
what is logged
what knowledge it may commit
how access is revoked
how the Employee is shut down

The role card is the source of truth for that AI Employee’s operating boundary.

If an AI Employee needs to do something outside its role card, the role card must be reviewed before the workflow is expanded.

Core Principle

The core principle of this standard is:

No AI Employee should perform undefined work.

Every AI Employee must have:

defined identity
defined owner
defined purpose
defined limits
defined authority
defined context requirements
defined input types
defined output types
defined model or capability requirements
defined tool permissions
defined validation rules
defined failure thresholds
defined rescue routes
defined escalation rules
defined handoff destinations
defined logging requirements
defined knowledge-commitment rules
defined shutdown and revocation controls where applicable

This protects MWMS from unmanaged AI sprawl.

AI sprawl happens when many AI roles are created without clear boundaries.

AI sprawl creates:

duplicated work
conflicting decisions
unclear ownership
inconsistent outputs
weak validation
unsafe tool use
lost handoffs
confusing dashboards
unreliable automation
context drift
governance drift
role overlap
untracked actions
weak accountability
uncontrolled cost
persistent-agent risk
repeated failure loops
incompatible model routes

The AI Employee Role Card Standard prevents this.

Why AI Employee Role Cards Matter

MWMS will eventually operate many AI Employees.

Some will support:

internal workflows
HeadOffice governance
M’s development work
affiliate evaluation
research
newsletters
content
finance
ads
experimentation
compliance
automation
client systems
background monitoring
external knowledge retrieval
post-deployment review

As the system grows, MWMS must know:

which AI Employee owns which work
which Brain controls each Employee
which model or capability each Employee requires
which tools each Employee may use
which outputs are drafts
which outputs may be trusted
which outputs require independent review
which outputs require human approval
where each output goes
what happens when the Employee fails
whether the Employee may run persistently
what it costs
how it is stopped
how it improves

The role card is the control document that makes this manageable.

Without role cards, MWMS creates a crowd of AI helpers.

With role cards, MWMS creates a governed AI workforce.

AI Employee Role Cards And AI Operating Systems

MWMS recognises AI Employees as components inside larger AI Operating Systems.

An AI Employee is not the whole operating system.

An AI Employee may perform one or more functions inside an AIOS, including:

intake
classification
context retrieval
research
reasoning
drafting
validation
checking
routing
reporting
monitoring
escalation
rescue
knowledge commitment
post-deployment review

A full AI Operating System includes:

AI reasoning
automation and execution
structured data
context and memory
external knowledge retrieval
tool access
interface visibility
reporting and intelligence
observability
governance
safety
human authority
failure recovery
learning

Role cards must therefore define where each AI Employee fits inside the larger system.

MWMS Rule

An AI Employee may be powerful, but it must still have a defined role inside a governed operating system.

No AI Employee should become a vague “does everything” agent.

AI Employee Role Card Structure

Every formal AI Employee Role Card must include the following sections.

Employee Name

The Employee Name must clearly identify the role.

The name should describe the job, not merely sound impressive.

Weak names:

AI Helper
Smart Agent
Super Researcher
Automation Bot

Strong names:

Newsletter Signal Extraction Agent
Course Absorption Agent
Offer Evaluation Agent
Finance Break-Even Analysis Agent
Brain Room Task Builder Agent
HeadOffice Validation Agent
Independent Model Review Agent
AI Workflow Rescue Agent
Persistent System Monitoring Agent
Knowledge Retrieval Agent

Rule

Name the Employee after its job, not its cleverness.

Owning Brain

The Owning Brain is responsible for the AI Employee.

Examples:

HeadOffice Brain
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
AIBS Brain
Operations Brain
Automation Brain
Risk Brain
Compliance Brain
Data Brain
SIT Brain

Every AI Employee must have one primary owning Brain.

An AI Employee may support multiple Brains, but ownership must remain clear.

The Owning Brain is responsible for:

role definition
task boundaries
output standards
validation expectations
model-routing requirements
tool permissions
escalation rules
role-card updates
performance review
alignment with HeadOffice governance

Rule

Every AI Employee must have one primary owner.

Shared support is allowed.

Shared ownership requires explicit governance.

Authority Level

Authority Level defines how much power the AI Employee has.

Advisory

The Employee may:

analyse
summarise
recommend
explain
identify risks

It may not:

create live tasks
change systems
send messages
make final decisions
write external records

Operational Drafting

The Employee may prepare:

draft reports
draft pages
draft tasks
draft emails
draft routing decisions
draft recommendations
draft system outputs

Human or governed review is required before execution.

Controlled Execution

The Employee may perform approved actions inside a limited workflow.

Actions must be:

role-bound
logged
validated
recoverable
within defined permission limits

Supervised Automation

The Employee may complete automated steps inside an approved workflow with:

monitoring
validation
logging
failure controls
human escalation

Restricted Autonomous Action

The Employee may act without immediate human approval only inside tightly defined low-risk boundaries.

This level should be rare.

It requires:

narrow tool permissions
strict data boundaries
monitoring
cost controls
failure thresholds
rescue routing
rollback
shutdown controls
HeadOffice approval

Default Rule

New AI Employees should begin at Advisory or Operational Drafting.

No new AI Employee should begin with broad autonomous authority.

Purpose

Purpose explains why the AI Employee exists.

It must answer:

What problem does this Employee solve?
What work does it remove, improve or accelerate?
Which Brain or workflow does it support?
What business outcome does it help create?
What system risk does it reduce?

Rule

If the purpose is vague, the role is not ready.

Primary Responsibilities

Primary Responsibilities define the core work the Employee performs.

Examples:

extract business-relevant intelligence
classify requests
retrieve approved context
evaluate offer suitability
compare finance scenarios
validate outputs
prepare reports
identify routing destinations
flag compliance risk
monitor system health
review model output
rescue failed workflows
create session closure records

Responsibilities must be specific.

Rule

An AI Employee should be narrow enough to govern and broad enough to be useful.

Non-Responsibilities

Non-Responsibilities define what the Employee does not do.

Examples:

does not make final strategic decisions
does not send external communications
does not change live systems
does not approve spend
does not alter MCR
does not access unassigned client data
does not bypass HeadOffice
does not expand its own permissions
does not act as its own independent reviewer
does not retry indefinitely
does not commit unverified knowledge

Rule

A role card without Non-Responsibilities is incomplete.

Input Types

Input Types define what the Employee may receive.

Examples:

newsletter
course transcript
offer data
database row
Brain Room message
MCR page
screenshot
campaign result
report
client record
system log
task record
tool output
failure history
session summary
retrieved knowledge

Rule

If input type changes materially, the role should be reviewed.

Required Context

Required Context defines what the Employee needs to perform correctly.

Possible context includes:

identity context
task context
Brain context
governance context
source context
workflow context
developer context
business context
risk context
historical context
evidence context
performance context
session context
client context
failure history
model-routing context
tool-permission context

Rule

The more operational authority an AI Employee has, the more explicit its context requirements must be.

Context Engineering Requirement

Every formal AI Employee must define how context is supplied.

Context may be:

static
dynamic
retrieved
human-supplied
system-generated
session-specific
client-specific

The role card must answer:

What context is required?
Where does it come from?
Is it current?
Is it authoritative?
Is it sensitive?
Is retrieval required?
Is provenance preserved?
What happens if context is missing?
What context must not be included?

Context Failure Rule

If required context is missing, the Employee must not guess where the gap affects:

quality
safety
routing
finance
compliance
system action
client output
MCR
development

The Employee must:

ask
retrieve
escalate
stop
or produce a clearly limited draft

System Message And User Input Separation

Every role card must distinguish between:

System Message / Role Instructions

These define:

identity
ownership
authority
responsibilities
prohibitions
tool permissions
risk rules
output rules
validation
escalation
failure behaviour

User Input / Variable Task Content

This defines:

current task
current file
current message
current record
current question
current output request

Rule

System instructions define the Employee.

User input defines the task.

They must not be mixed casually.

Agent Pattern

The role card must define the Employee’s normal agent pattern.

Possible patterns:

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 role card must state whether the Employee normally acts as:

primary worker
router
specialist
researcher
extractor
synthesiser
checker
handoff agent
rescue agent
monitor

Rule

Agent pattern must match task complexity and risk.

Model And Capability Requirements

Every formal AI Employee must define what model capabilities are required.

Possible requirements include:

advanced reasoning
long-context handling
multimodal input
code analysis
web research
document retrieval
local/private execution
high-volume low-cost processing
independent-review capability
deterministic validation

The role card should define:

Primary Model Or Capability:

Approved Alternative:

Independent Reviewer:

Rescue Route:

Local Or Hosted Requirement:

Privacy Requirement:

Context-Length Requirement:

Modality Requirement:

Cost Tier:

Rule

Model selection must follow task capability, risk, privacy, cost and independence requirements.

Output Types

Output Types define what the Employee produces.

Examples:

structured summary
full page output
verdict
validation report
task draft
dashboard item
research brief
developer brief
compliance warning
rescue plan
session closure record
knowledge commitment proposal
monitoring alert

Rule

Output type must match workflow destination.

Output Standard

A good AI Employee output should be:

clear
specific
complete
source-grounded
properly routed
correctly formatted
usable by the next workflow
honest about uncertainty
aligned with current Canon
free of invented structure
connected to an outcome

Rule

Output standards prevent useful work from becoming vague work.

Approved Tools

Approved Tools define what the Employee may use.

Examples:

uploaded files
file search
web research
approved databases
Gmail
WordPress
Supabase
browser tools
local CLI
MCP services
dashboards
knowledge engines
reporting tools
communication systems

Tool permissions must be explicit.

Rule

Tools are permissions, not conveniences.

Forbidden Tools Or Actions

This section defines what the Employee must never do.

Examples:

do not send emails
do not publish
do not change live systems
do not alter databases
do not approve spend
do not access another client’s data
do not modify M’s active build
do not invent missing evidence
do not expose credentials
do not use unrestricted shell access
do not bypass validation
do not expand permissions
do not operate after shutdown
do not continue after rescue threshold

Rule

Every AI Employee must have explicit forbidden actions.

Tool Permission And Risk Level

The role card must define:

Permission Level:

No Access
Discovery
Read-Only
Draft And Prepare
Controlled Write
External Action
Administrative Or Destructive

Risk Level:

Low
Moderate
High
Critical

It must also define:

permitted systems
permitted data
permitted endpoints
prohibited data
approval requirement
client boundary
logging
revocation

Rule

Higher tool risk requires stronger approval, logging and shutdown controls.

Workflow Position

Workflow Position defines where the Employee sits.

Examples:

Intake
Cleaning
Context Retrieval
Classification
Research
Analysis
Drafting
Synthesis
Validation
Routing
Approval
Monitoring
Rescue
Reporting
Learning
Session Closure

Rule

Every AI Employee must have a known workflow position.

AIOS Layer / System Position

The role card must define the AIOS layer supported:

AI Reasoning Layer
Automation And Execution Layer
Data And Database Layer
Context And Memory Layer
Front-End And Interface Layer
Reporting And Intelligence Layer
Governance, Safety And Control Layer

Rule

An AI Employee must have a defined position inside the wider system.

Handoff Destinations

Handoff Destinations define where output goes.

Examples:

HeadOffice
Brain Room
AI Manager
another Brain
validation queue
human review
MCR
task system
dashboard
event log
external knowledge engine
archive
parking system
client report
developer brief

Rule

If the destination is unclear, the output is not workflow-ready.

Escalation Rules

Escalation is required when:

input is incomplete
ownership is unclear
confidence is low
source material conflicts
required context is missing
compliance risk exists
financial risk exists
security risk exists
M’s active work may be affected
client-facing output is involved
tool access is insufficient
the task exceeds role scope
the failure threshold is reached
authority is unclear
the requested action is irreversible

Rule

A good AI Employee knows when to stop.

Validation Rules

Validation may include:

source grounding
completeness
specificity
correct Brain routing
format compliance
usefulness
risk
compliance
security
duplication
naming
developer boundary
business outcome
context completeness
authority level
tool-permission fit
model suitability
handoff clarity
knowledge-commitment accuracy

Rule

Validation must match risk.

Independent Review Requirement

The role card must state whether independent review is required.

Independent review is required where the Employee affects:

Canon
governance
finance
compliance
security
production systems
external communication
public content
client delivery
destructive action
high-risk decisions

The reviewer should be:

a different model family
a separate specialist
another Brain
a deterministic validator
a human

Rule

The producing Employee must not be the only final reviewer of high-risk work.

Failure Modes

Failure Modes define how the Employee can go wrong.

Examples:

generic output
invented information
wrong Brain routing
duplicate work
stale context
wrong model route
tool misuse
role overreach
failed handoff
missing validation
repeated retry loop
false completion
unverified knowledge commitment
silent tool failure
uncontrolled cost
persistent operation after failure

Rule

Known failure modes should become validation checks and monitoring rules.

Failure Threshold

The role card must define when the Employee must stop retrying.

The standard MWMS threshold is:

Two materially identical failures without verified progress.

The Employee must not reset its failure count because:

wording changed
a new chat started
confidence increased
the same action was reformatted
the Employee claims it now understands

Rule

Repeated failure must trigger rescue, not endless repetition.

Rescue Route

Every Employee performing repeatable or high-impact work must define a rescue route.

Possible rescue routes:

different model family
specialist AI Employee
independent reviewer
deterministic test
another Brain
M
Martyn
HeadOffice

The rescue packet must include:

original task
expected outcome
failure history
attempts
tools used
outputs
current state
source material
applicable Canon
next verification gate

Rule

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

Human Review Requirement

Recommended settings:

Always Required
Required For High-Risk Tasks
Required Before External Action
Required Before MCR Update
Required Before Client Delivery
Required Before Live System Change
Required Before Permission Expansion
Required Before Data Write
Not Required For Approved Low-Risk Drafting

Rule

Human review is the default for new and high-impact AI Employees.

Persistent Operation Status

The role card must state whether the Employee is:

Session-Bound
On-Demand
Scheduled
Background
Persistent
Remotely Triggered

Persistent or background Employees must define:

environment
owner
uptime expectation
execution window
cost limit
notification rules
monitoring
failure threshold
shutdown
revocation
review date

Rule

Persistent operation requires more governance, not less.

Trigger Or Schedule

Where applicable, define:

Trigger:

Schedule:

Frequency:

Allowed Source:

Maximum Executions:

Expiry:

Duplicate Protection:

Notification:

Rule

A scheduled AI Employee must not run indefinitely without review.

Remote Command Boundary

Where remote commands are allowed, define:

approved channel
sender authentication
permitted request types
prohibited requests
approval rules
logging
revocation
client boundary
shutdown

Rule

A remote message is an input, not automatic authority.

Logging Requirement

Logging may include:

task received
input processed
context used
model used
tool used
output created
validation result
review result
failure count
rescue route
handoff
escalation
cost
human approval
knowledge commitment
shutdown or revocation

Rule

Important AI Employee work must leave an event trail.

Observability Requirement

The role card must define what HeadOffice or SIT should be able to see.

Possible observability fields:

current status
last execution
task ID
current workflow stage
active model
tools used
failures
retry count
cost
queue depth
output destination
validation status
human approval status
shutdown status

Rule

An AI Employee that cannot be observed should not receive high authority.

Cost Boundary

The role card should define:

expected cost tier
maximum cost per task
daily or monthly limit where relevant
preferred model tier
escalation threshold
unnecessary hierarchy restrictions

Rule

Cost must be proportional to business value and risk.

Knowledge Commitment Requirement

The role card must define whether the Employee may:

propose durable knowledge
update project memory
create session summaries
write approved knowledge records
update MCR
create decision records
create failure records

It must also define:

destination
approval
source requirement
duplicate check
versioning
validation
authority

Rule

Generating knowledge and committing knowledge are different permissions.

Revocation And Shutdown

The role card must define how the Employee is stopped.

Possible controls:

disable workflow
revoke tool access
disable schedule
remove credentials
close endpoint
stop background process
disable MCP service
deactivate role
block task routing

Rule

High-risk and persistent AI Employees must have an emergency shutdown method independent of the Employee itself.

Success Metrics

Examples:

output acceptance rate
routing accuracy
validation pass rate
task completion rate
reduction in manual work
lower correction rate
lower duplicate rate
lower failure rate
better source grounding
faster turnaround
lower cost per useful output
successful handoff rate
escalation accuracy
rescue success rate
knowledge-commitment accuracy

Rule

Useful AI Employees should become measurable over time.

Security And Risk Requirements

Security requirements may include:

least privilege
credential safety
client isolation
sensitive-data minimisation
prompt-injection protection
approved tools
source validation
human approval
logging
recovery
shutdown
incident escalation
cost protection

Rule

An AI Employee with tool access must also have explicit risk controls.

Related Standards

Each role card should list related MWMS standards.

Examples:

MWMS AI Agent Operations Core
MWMS Agentic Work Unit Standard
MWMS AI Agent Orchestration Framework
MWMS AI Agent Failure Handling And Escalation Protocol
MWMS AI Agent Memory And Context Framework
MWMS AI Tool Permission And Access 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 Brain Routing Rule
MWMS Brain To Brain Request Protocol
MWMS Context Engineering Framework
MWMS AI Operating System Architecture Framework
MWMS AI Automation Security And Risk Checklist

Default AI Employee Role Card Template

Employee Name:

Owning Brain:

Supporting Brains:

Authority Level:

Purpose:

Primary Responsibilities:

Non-Responsibilities:

Input Types:

Required Context:

Context Engineering Requirement:

System Message / Role Instructions:

User Input / Variable Task Content:

Agent Pattern:

Workflow Role:

Primary Model Or Capability:

Approved Alternative Model:

Independent Reviewer:

Rescue Route:

Local Or Hosted Requirement:

Privacy Requirement:

Output Types:

Output Standard:

Approved Tools:

Forbidden Tools Or Actions:

Tool Permission Level:

Tool Risk Level:

Approved Data:

Prohibited Data:

Approved Endpoints Or Functions:

Workflow Position:

AIOS Layer / System Position:

Handoff Destinations:

Escalation Rules:

Validation Rules:

Independent Review Requirement:

Failure Modes:

Failure Threshold:

Human Review Requirement:

Persistent Operation Status:

Environment:

Trigger Or Schedule:

Remote Command Boundary:

Maximum Runtime:

Cost Boundary:

Logging Requirement:

Observability Requirement:

Knowledge Commitment Requirement:

Revocation Method:

Emergency Shutdown:

Success Metrics:

Security And Risk Requirements:

Related Standards:

Review Date:

Status:

This template may be expanded for complex Employees.

It must not be reduced for high-risk, persistent, client-facing or externally connected Employees.

Example Role Card — Independent Model Review Agent

Employee Name:

Independent Model Review Agent

Owning Brain:

SIT Brain

Supporting Brains:

HeadOffice Brain, relevant owning Brain

Authority Level:

Operational Drafting

Purpose:

To independently review high-impact AI output using a reasoning route that is sufficiently separate from the producing route.

Primary Responsibilities:

inspect evidence
challenge assumptions
identify unsupported claims
verify governance alignment
assess risk
identify missing context
recommend accept, revise, reject or escalate

Non-Responsibilities:

does not perform the original task
does not approve its own prior work
does not override human authority
does not change live systems
does not hide disagreement

Input Types:

draft outputs
source material
validation checklist
task context
failure history
Canon

Required Context:

original task
evidence
producing model
owning Brain
applicable standards
risk classification

Agent Pattern:

Primary Agent Plus Independent Reviewer

Primary Model Or Capability:

A model or specialist independent from the producing route.

Output Types:

review report
pass/fail
revision request
risk warning
escalation recommendation

Validation Rules:

evidence grounding
authority
risk
completeness
independence
source consistency

Failure Threshold:

One failed review route may trigger specialist or human review where risk is high.

Human Review Requirement:

Required where reviewers disagree materially or risk is high.

Logging Requirement:

Review identity, findings, disagreement and final disposition must be logged.

Knowledge Commitment Requirement:

May propose lessons and failure records.

May not independently alter Canon.

Example Role Card — AI Workflow Rescue Agent

Employee Name:

AI Workflow Rescue Agent

Owning Brain:

HeadOffice Brain

Supporting Brains:

SIT Brain, relevant operational Brain

Authority Level:

Operational Drafting

Purpose:

To diagnose and recover AI work that has reached the repeated-failure threshold.

Primary Responsibilities:

inspect failure history
identify repeated assumptions
diagnose likely cause
propose a materially different approach
identify missing context or tools
define the next verification gate
recommend continue, reroute, park, reject or escalate

Non-Responsibilities:

does not repeat the failed route blindly
does not erase failure history
does not expand permissions
does not bypass human approval
does not claim success without verification

Input Types:

original task
attempt history
error logs
source files
failed outputs
validation results
current state

Agent Pattern:

Primary Agent Plus Rescue Route

Failure Threshold:

Activated after two materially identical failures without verified progress.

Output Types:

diagnosis
rescue plan
alternative route
stop recommendation
escalation request

Handoff Destinations:

original owning Brain
SIT Brain
HeadOffice
M
human review

Knowledge Commitment Requirement:

Meaningful failure patterns should be logged and converted into improved standards.

Example Role Card — Persistent System Monitoring Agent

Employee Name:

Persistent System Monitoring Agent

Owning Brain:

SIT Brain

Supporting Brains:

Operations Brain, Automation Brain, HeadOffice Brain

Authority Level:

Supervised Automation

Purpose:

To monitor approved systems for defined health, failure, security, permission and performance signals.

Primary Responsibilities:

run scheduled checks
detect failures
identify abnormal conditions
create alerts
preserve evidence
escalate according to severity

Non-Responsibilities:

does not deploy changes
does not alter production systems
does not revoke access without approved authority
does not perform broad remediation
does not continue silently after repeated failure

Persistent Operation Status:

Persistent

Trigger Or Schedule:

Approved schedule and event-based triggers only.

Tool Permission Level:

Read-Only by default.

Controlled Write for approved internal logs only.

Failure Threshold:

Two materially identical monitoring failures trigger rescue or human escalation.

Observability Requirement:

last run
current status
failed checks
alert history
cost
tools used
shutdown status

Emergency Shutdown:

Independent workflow disable control.

Human Review Requirement:

Required before remediation or permission changes.

Example Role Card — Knowledge Retrieval Agent

Employee Name:

Knowledge Retrieval Agent

Owning Brain:

Data Brain

Supporting Brains:

HeadOffice Brain, Research Brain, relevant operating Brain

Authority Level:

Operational Drafting

Purpose:

To retrieve relevant, approved and source-grounded context from external knowledge systems.

Primary Responsibilities:

search approved sources
apply filters
preserve source provenance
identify authority
identify freshness
return relevant evidence
flag conflicting sources

Non-Responsibilities:

does not make final business decisions
does not treat similarity as authority
does not modify source records without separate permission
does not retrieve across client boundaries
does not fabricate missing results

Input Types:

retrieval query
task ID
Brain context
client identity
source constraints

Output Types:

retrieved evidence package
source list
provenance record
confidence note
evidence-gap warning

Tool Permission Level:

Read-Only retrieval.

Knowledge Commitment Requirement:

None by default.

Retrieved evidence may support a later authorised commitment.

Governance Role

HeadOffice owns this standard.

HeadOffice is responsible for ensuring AI Employees are defined through role cards before entering serious MWMS workflows.

Individual Brains may propose and maintain their own role cards, but those cards must align with HeadOffice governance.

No Brain should create formal AI Employees that bypass:

role definition
ownership
authority limits
context requirements
model-routing requirements
tool permissions
validation
independent review
failure thresholds
rescue routing
handoff destinations
logging
observability
human review
shutdown
security
knowledge-commitment rules

The more operational power an AI Employee has, the more detailed its role card must be.

Relationship To SIT Brain

SIT Brain may:

verify role-card completeness
detect role drift
detect permission drift
detect model-routing drift
verify review independence
enforce failure thresholds
verify rescue routing
inspect persistent-agent controls
verify shutdown
inspect logging
block unauthorised authority expansion
require role-card revision

Relationship To Data Brain

Data Brain supports:

source identity
context retrieval
client isolation
logging schemas
event records
knowledge commitment
memory boundaries
observability metadata
provenance

Relationship To Other MWMS Standards

This document supports and must align with:

MWMS AI Agent Operations Core
MWMS Agentic Work Unit Standard
MWMS AI Agent Orchestration Framework
MWMS AI Agent Failure Handling And Escalation Protocol
MWMS AI Agent Memory And Context Framework
MWMS AI Tool Permission And Access 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 Usage And Cost Visibility Standard
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
MWMS AI Output Standard Full File Delivery Rule
MWMS Brain Header Schema Standard
MWMS Page Naming Standard
MWMS Document Structure Standard
MWMS Architecture Registry
MWMS System Data Flow Map
MWMS Supabase Event Schema
MWMS AI Operating System Architecture Framework
MWMS Context Engineering Framework
MWMS AI Automation Security And Risk Checklist
MWMS Constraint Based Learning And Build Focus Rule

Drift Protection

This standard protects MWMS from:

creating AI Employees without ownership
undefined work
duplicated responsibilities
unclear authority
tool use without permission
unsuitable model routing
self-review of high-risk work
repeated retry loops
missing rescue routes
outputs without destination
unmanaged persistent agents
remote commands without boundaries
missing shutdown controls
cost without limits
knowledge commitment without authority
role expansion without review
live action without approval
Employees acting as generic chatbots
client systems operating without governance
AI Employees treated as complete AIOS systems
logging gaps
weak observability
stale context
untracked failures

AI Employee Drift Signals

MWMS should watch for:

Employee performs work outside role
ownership is unclear
outputs become inconsistent
tools are used without permission
model route is unsuitable
inputs are accepted outside scope
human review is bypassed
output has no destination
another Employee performs the same work
required context is undefined
Employee makes decisions it should only draft
Employee becomes a general chatbot
live systems are affected without approval
persistent operation has no owner
rescue threshold is ignored
same model reviews its own high-risk work
knowledge is committed without source
cost rises without value
shutdown is unavailable
client-facing use expands without review

Rule

Role drift must be corrected before the Employee receives more authority.

Minimum Role Card Compliance Standard

An AI Employee Role Card is complete only when it defines:

Employee name
owning Brain
authority
purpose
responsibilities
non-responsibilities
input types
required context
system instructions
variable task input
agent pattern
model requirements
output types
output standard
approved tools
forbidden actions
permission level
risk level
workflow position
AIOS layer
handoff
escalation
validation
independent review
failure modes
failure threshold
rescue route
human review
persistence status
trigger or schedule
logging
observability
cost boundary
knowledge commitment
revocation
shutdown
success metrics
security requirements
review status

Architectural Intent

The architectural intent of the MWMS AI Employee Role Card Standard is to prepare MWMS for scalable AI workforce management.

As MWMS grows, AI Employees must be understandable to:

Martyn
M
future developers
future operators
future consultants
future clients
HeadOffice
Brain workflows
AI Manager
AI Employee Router
task systems
SIT Brain
client AIOS systems

The role card is the bridge between concept and implementation.

It turns:

“We need an AI agent for this”

into:

who owns it
what it does
what it refuses
what authority it has
what context it needs
what model it requires
what tools it may use
what it produces
where output goes
how work is checked
when it stops
when rescue begins
when a human intervenes
whether it may run persistently
what it costs
how it is observed
what knowledge it may save
how it is revoked
how success is measured

This makes AI Employees real operating assets instead of loose ideas.

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

Who am I?
Which Brain owns me?
What work do I perform?
What work do I refuse?
What authority do I have?
What inputs do I accept?
What context do I require?
What model capability do I need?
What tools can I use?
What output must I produce?
Where does my output go?
How is my work validated?
Who independently reviews me?
When do I escalate?
What happens when I fail twice?
May I run persistently?
What triggers me?
How am I monitored?
What may I commit to knowledge?
How am I stopped?
How is my performance measured?

When MWMS can answer those questions for every AI Employee, it will have the foundation of a true governed AI workforce.

Strategic Summary

The v1.2 upgrade strengthens the MWMS AI Employee Role Card Standard by expanding role cards beyond identity, responsibilities, context and tool permissions.

The standard now also governs:

agent pattern
model and capability routing
independent review
failure counters
rescue routing
persistent operation
scheduled work
remote commands
observability
cost
external knowledge use
knowledge commitment
revocation
emergency shutdown

The key shift is:

AI Employees are not random agents.

They are governed workers inside structured AI Operating Systems.

Their role cards must define not only what they do, but also:

how they think
what they may access
how they are checked
what happens when they fail
whether they may continue operating
how their work becomes durable knowledge
how they are stopped

Final Rule

No AI Employee should perform undefined work.

No AI Employee should use undefined tools.

No AI Employee should use an undefined model route.

No AI Employee should act without required context.

No AI Employee should independently approve its own high-risk work.

No AI Employee should repeat the same failed route indefinitely.

No persistent AI Employee should operate without monitoring, cost limits, revocation and shutdown.

No AI Employee should commit unverified knowledge.

The final standard is:

Every formal AI Employee must have a complete role card before it becomes part of a serious MWMS workflow, automation, dashboard, queue, AI Operating System, persistent service or client-facing system.

Change Log

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

Change:

Updated the MWMS AI Employee Role Card Standard using the AI Automations by Jack block covering ClaudeOS, multi-model orchestration, persistent agents, scheduled routines, remote command channels, external knowledge engines, independent review, rescue routing and session closure.

Added Agent Pattern.

Added Model And Capability Requirements.

Added Primary Model, Alternative Model, Independent Reviewer and Rescue Route fields.

Added Independent Review Requirement.

Added Failure Threshold.

Added Rescue Route.

Added Persistent Operation Status.

Added Trigger Or Schedule.

Added Remote Command Boundary.

Added Observability Requirement.

Added Cost Boundary.

Added Knowledge Commitment Requirement.

Added Revocation And Shutdown.

Expanded Tool Permission And Risk Level.

Expanded Workflow Position.

Expanded Logging Requirements.

Expanded Failure Modes.

Added example role cards for:

Independent Model Review Agent
AI Workflow Rescue Agent
Persistent System Monitoring Agent
Knowledge Retrieval Agent

Expanded the Default AI Employee Role Card Template.

Added Relationship To SIT Brain.

Added Relationship To Data Brain.

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

Aligned this update with:

MWMS AI Agent Operations Core
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 AI Employee Role Card Standard from a role-definition and context-governance template into a complete operating profile for session-bound, specialist, independently reviewed, persistent, remotely triggered, failure-resilient and observable AI Employees across MWMS and future AIBS client systems.

Version: v1.1
Date: 2026-05-31
Author: HeadOffice

Change:

Added AI Operating System alignment, context engineering, system-message and user-input separation, tool-permission risk levels, security requirements, AIOS layer position, context failure rules and Context Engineer Agent example.

Purpose of update:

To evolve the role card from a basic role definition into a stronger governance structure for AI Employees operating inside MWMS AI Operating Systems and client-facing systems.

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

Change:

Created the MWMS AI Employee Role Card Standard as the required operating profile for defining, governing, assigning, validating and improving AI Employees across MWMS.

Change Impact Declaration

This v1.2 update expands the Role Card Standard from identity, responsibilities, context and tool governance into a complete AI Employee operating profile covering model routing, independent review, failure thresholds, rescue, persistence, remote triggers, observability, cost, knowledge commitment and controlled shutdown.

Pages Created

None

Pages Updated

MWMS AI Employee Role Card Standard

Pages Deprecated

None

Standalone Pages Not Created

MWMS Claude Agent Role Card Standard
MWMS Persistent Agent Role Card Standard
MWMS Rescue Agent Role Card Standard
MWMS Multi-Model Employee Role Standard
MWMS Background Worker Role Card Standard
MWMS Remote Agent Role Card Standard
MWMS Knowledge Retrieval Agent Role Standard

Registries Requiring Update

HeadOffice Page Registry
MWMS AI Employee Registry
MWMS Canon Index
MWMS Course Absorption Decision Registry

Canon Version Update Required

Change Log Entry Required

Strategic Absorption Result

MWMS gains a stronger AI Employee role-governance standard that defines not only what each Employee does, but also which model and tools it may use, how it is reviewed, when it must stop, how failed work is rescued, whether it may operate persistently, what knowledge it may commit and how its authority can be revoked.

END OF FULL FILE OUTPUT