MWMS AI Agent Operations Core

System: MWMS
Document Type: Core Operating Standard
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.4
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS 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-27
Source / Origin: MWMS AI Agent Operations Core v1.3 + AI Automations By Jack AI Agents Block Covering Make AI Agents, n8n Agents, Email Classification, Lead Appointment Agents, Model Interchangeability, RAG Retrieval, Voice Input, Reusable Tools And Agent Testing
MWMS Classification: AI Workforce Operating Standard / Agentic Workflow Governance / AI Operating System Foundation / Agent Hierarchy Standard / Persistent AI Employee Operations Standard / Agent Necessity Standard / Reusable Capability Governance Standard
Primary Brain: HeadOffice Brain
Supporting Brains: MWMS Brain, AIBS Brain, Automation Brain, Operations Brain, Data Brain, Risk Brain, Compliance Brain, SIT Brain, Research Brain, Affiliate Brain, Content Brain, Finance Brain, Experimentation Brain, Sales Brain, Project Manager 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 Memory And Context Framework, MWMS AI Employee Role Card Standard, MWMS AI Tool Permission And Access Framework, MWMS AI Tool Permission Record Template, MWMS AI Agent Skill Library Framework, MWMS Advanced AI Capability Stack Framework, MWMS Client AI Interface Selection Framework, MWMS Agentic Work Unit Standard, MWMS Brain Routing Rule, MWMS Brain To Brain Request Protocol, 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 Observability Metadata Standard, MWMS AI Usage And Cost Visibility Standard, MWMS Prompt Architecture And Automation Output Reliability Framework, MWMS n8n Operating And Deployment Standard, MWMS AI Tool Access Browser Automation And MCP Governance Framework, MWMS Lead Intake Qualification And Follow Up Automation Framework, MWMS Client Communication Automation Framework, MWMS AI Assisted Outreach And Sales Follow Up Automation Framework, MWMS Source Visibility And Evidence Display Standard, MWMS AI Employee Evaluation Scorecard Standard, MWMS Agent Loop Control Framework, MWMS Next Action Picker Standard, Project Manager Brain Canon

Source Evidence

The existing MWMS AI Agent Operations Core defines MWMS AI work as governed operational work using agents, orchestration, tasks, outcomes, structured workflows, validation, handoffs, reporting, persistent operation, independent review, deterministic rescue, observability, cost control and learning loops.

The newly absorbed AI Agents block strengthens this standard with:

a formal decision between deterministic automation and agentic operation
reusable agent tool and capability libraries
independent tool testing before agent integration
specialist classification before specialist action
hierarchical classification for complex shared channels
explicit action autonomy levels
stronger separation between agent role, model, tools, memory and state
stable agent contracts that remain independent of a specific model or platform
voice and message inputs as governed command channels rather than automatic authority
bounded email, calendar, task and business-system actions
stronger RAG ingestion and retrieval boundaries
the principle that tool execution success is not the same as business outcome success

Purpose

The purpose of this document is to define the MWMS AI Agent Operations Core.

The MWMS AI Agent Operations Core establishes the operating model for how MWMS designs, governs, manages, validates, monitors and improves:

AI Employees
AI workflows
Brain to Brain handoffs
automated tasks
persistent agents
scheduled routines
model routing systems
reporting systems
knowledge systems
remote command channels
business execution systems
reusable agent capabilities
specialist classification systems
bounded autonomous actions
agent testing and evaluation

This standard exists because MWMS is not being built as:

a simple chatbot system
a prompt library
a collection of disconnected automations
a collection of tool specific AI tricks
a loose group of models
an unmonitored autonomous agent network
one all powerful agent with access to everything
a set of platform dependent workflows that cannot move or be audited

MWMS is being built as a governed AI business operating ecosystem.

Inside MWMS, AI must function as a structured workforce.

That means every serious AI interaction must be converted into a controlled operational unit with:

a defined purpose
a defined role
a clear input
a clear task
a permitted scope
selected context
approved tools
an appropriate model or capability route
a required output
a validation standard
an independent review route where required
a failure threshold
a rescue path
a handoff destination
a business outcome
a risk level
an observability requirement
a knowledge commitment requirement
a learning loop where appropriate
an action autonomy level
a tested capability contract
a clear reason why an agent is justified

Core Principle

The core principle is:

Use the simplest reliable operating structure that can complete the work safely.

An AI agent is not automatically superior to a deterministic automation.

Agentic capability should be introduced only when the business task genuinely requires judgement, adaptive tool choice, conversational continuity, dynamic planning or non linear coordination.

Where fixed rules can safely complete the work, MWMS should prefer fixed rules.

Where one AI processing step is enough, MWMS should not build a persistent agent.

Where one specialist agent is enough, MWMS should not build a multi agent hierarchy.

Where an external action creates risk, the system should recommend, draft or prepare before it executes.

Agent Necessity Test

Before creating or deploying an AI agent, MWMS must determine whether an agent is justified.

Question 1: Can A Deterministic Automation Complete The Work?

Use a deterministic automation when:

the sequence is known
conditions can be defined
the same inputs should produce the same route
tool selection does not require judgement
the workflow does not need conversational memory
the task is repetitive and stable
error handling can be explicitly defined

Question 2: Is AI Needed Only For One Processing Step?

Use an automation with an AI processing step when:

the workflow is deterministic
only extraction, classification, rewriting, scoring or summarisation requires a model
the model does not need to choose tools
the model does not control the workflow
the model output can be validated before the next step

Question 3: Is Routing Deterministic?

Use a deterministic router when:

categories are stable
rules are sufficient
risk is high
explainability is important
one category clearly maps to one destination

Question 4: Is Model Judgement Required?

An agent may be justified when:

the request is ambiguous
the system must interpret intent
several actions may be valid
the system must adapt to intermediate results
the next step cannot be fully predefined

Question 5: Must The System Choose Between Multiple Tools?

An agent may be justified when:

different requests require different approved tools
the order of tool use changes
tool results determine the next step
several tools may be combined in one request

Question 6: Is Conversational Context Required?

An agent may be justified when:

the user expects a continuing dialogue
the current request depends on prior messages
the system must preserve unresolved context
clarification and follow up are part of the workflow

Question 7: Is Multi Step Coordination Required?

An agent may be justified when:

the work requires planning
the agent must gather evidence, interpret it and act
several specialist capabilities must be coordinated
the task cannot be represented as one fixed linear sequence

Question 8: Does The Added Complexity Improve The Business Outcome?

An agent is not justified merely because it is technically possible.

The system must show that agentic operation improves:

accuracy
speed
decision quality
user experience
adaptability
operational leverage
evidence quality
business outcome

Agent Necessity Outcomes

Every proposed agent must receive one of the following outcomes:

Deterministic Automation
Automation With AI Processing Step
Deterministic Router
Single Agent
Agent Plus Checker
Router Plus Specialist
Specialist Agent Group
Persistent Agent
Agent With Human Approval
Agent Not Justified

Automation Before Agent Rule

MWMS must not use an AI agent to perform work that can be completed more reliably, cheaply and safely through deterministic automation.

The burden of proof sits with the proposed agent.

Scope

This standard applies to:

HeadOffice AI Employees
Brain specific AI Employees
AIBS client AI Employees
persistent cloud agents
temporary session agents
workflow agents
research agents
checking agents
routing agents
sales agents
support agents
content agents
finance agents
automation agents
project coordination agents
voice triggered agents
message triggered agents
web embedded agents
RAG enabled agents
multi model systems
reusable tool libraries
agent accessible sub workflows
scheduled background workers
remote command systems

This standard does not authorize any AI Employee to bypass:

Brain ownership
task structure
tool permissions
client boundaries
human approval
financial authority
compliance review
security controls
source of truth rules
Project Manager Brain task governance
MCR authority
shutdown requirements

The Seven Operating Foundations

Every serious MWMS AI system must contain seven operating foundations:

AI Employee
Context
Orchestration
Task
Tools And Capabilities
Validation
Outcome
AI Employee

An AI Employee is a governed role based AI operating unit.

An AI Employee must define:

name
owning Brain
purpose
role boundary
authority level
allowed inputs
required context
allowed outputs
permitted tools
prohibited actions
model or capability requirements
validation requirements
handoff destination
escalation rules
success metrics
failure thresholds
action autonomy level
logging requirements

Agent Rule

No AI Employee should perform undefined work.

Every AI Employee must know:

what it may do
what it must not do
what context it requires
what tools it may use
which model capability is appropriate
how its work is checked
where its output goes
whether it may execute or only recommend
what happens when confidence is low

Context

Context is the selected information required to perform the task correctly.

Context may include:

current user instruction
uploaded files
MCR standards
Brain rules
active workflow state
current save point
role card
source material
prior decisions
business objective
tool permissions
risk rules
failure history
retrieved evidence
current system status
customer or lead context
project and workstream context
consent state
action history
model and prompt version

Context Rule

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

AI Employees must not act from:

stale memory
missing context
unverified system assumptions
unrelated historical material
deprecated instructions
wrong client data
unapproved personal information
expired permissions
model generated facts presented as source context

Context Separation Rule

MWMS must distinguish:

current instruction
session memory
work memory
durable operational state
retrieved internal knowledge
current external research
tool results
model inference

These sources must not be merged without traceability.

Orchestration

Orchestration coordinates:

Brains
AI Employees
tasks
context
models
tools
validation
handoffs
rescue
reporting
knowledge commitment
autonomy levels
capability permissions

Orchestration decides:

which Brain owns the request
which AI Employee acts
whether automation or an agent is needed
whether one agent or several agents are needed
what model or specialist capability is required
what context is supplied
what tools are activated
what order work follows
what validation is required
what happens after failure
where the result goes
whether human review is needed
what is logged
what becomes durable knowledge
whether an action may be executed

Orchestration Rule

AI capability does not become business value until it is routed, sequenced, validated, recovered where necessary and connected to an outcome.

Task

A task is the smallest controlled unit of AI work inside MWMS.

A MWMS AI task should include:

task title
task type
source
originating Brain
assigned Brain
assigned AI Employee
agent necessity outcome
agent pattern
model or capability route
input payload
required context
required output
priority
status
risk level
tool permission level
action autonomy level
validation requirement
independent review requirement
failure threshold
rescue route
handoff destination
final outcome
event log
knowledge commitment requirement

Task Rule

A vague request must be converted into a structured task before it becomes operational work.

Tools And Capabilities

Tools allow AI Employees to retrieve information or perform action.

Tool access may include:

search
files
databases
communication
browser automation
APIs
MCP
local CLI tools
dashboards
publishing
deployment
monitoring
client systems
calendar systems
email systems
project systems
document generation
retrieval systems
notification systems

Tool Rule

Tool access must match:

role
task
risk
authority
data boundary
client boundary
approval
logging requirement
autonomy level

Technical access does not create operational permission.

Reusable Tool Capability Library Principle

MWMS should build approved reusable capabilities once and allow suitable AI Employees to call them according to role, permission, risk and business need.

Examples include:

internet research
internal knowledge retrieval
email draft creation
calendar availability check
calendar proposal preparation
task creation request
Supabase record creation
document generation
notification sending
source verification
structured data extraction
content formatting
report generation

A reusable capability must remain independent of any one agent where practical.

It must not be rebuilt differently inside every workflow without reason.

Reusable Capability Contract

Every reusable capability should define:

Capability Name:

Capability ID:

Owning Brain:

Purpose:

Business Outcome:

Accepted Inputs:

Required Fields:

Optional Fields:

Output Schema:

Systems Accessed:

Read Or Write Status:

Permission Level:

Action Autonomy Level:

Preconditions:

Human Approval Requirement:

Validation Requirement:

Failure Behaviour:

Timeout:

Retry Limit:

Idempotency Rule:

Maximum Cost:

Logging Requirement:

Version:

Allowed AI Employees:

Prohibited Uses:

Shutdown Or Revocation Method:

Capability Rule

An AI Employee may call only capabilities that are:

approved
documented
tested
version compatible
permitted for its role
appropriate for the current task
safe for the current autonomy level

Capability Reuse Rule

A shared capability must not silently change behaviour for every connected agent.

Material capability changes require:

version update
regression testing
dependency review
affected agent review
rollback path
change logging

Validation

Validation determines whether AI work may be trusted or executed.

Validation may include:

output checks
source checks
schema checks
deterministic tests
independent model review
specialist review
human review
SIT enforcement
tool result checks
business outcome checks
duplicate execution checks

Validation Rule

Important AI output must be checked before it becomes operational truth or external action.

Outcome

An outcome is the business result produced by AI work.

Valid outcomes may include:

decision
rejection
parking
test candidate
campaign action
report
compliance warning
research finding
task
routed action
saved learning
system improvement
AIOS maturity step
client value proof
verified completion
approved draft
approved meeting proposal
qualified lead handoff
failed action safely contained

Outcome Rule

AI output is not complete until its business outcome and destination are known.

Tool Execution Versus Outcome Rule

A successful tool call does not prove that the business outcome is correct.

Examples:

an email may send successfully but contain the wrong commitment
a calendar event may be created successfully at the wrong time
a task may be stored successfully under the wrong project
a RAG query may return results that are outdated
a report may generate successfully with unsupported claims

MWMS must validate both execution and outcome.

Agent Hierarchy Design Layer

Agent hierarchy means using coordinated AI Employees or agents to complete work too complex, risky or multidimensional for one general agent.

Hierarchy may include:

master agents
router agents
specialist agents
research agents
extraction agents
structure agents
synthesis agents
checking agents
handoff agents
rescue agents
sub workflows
Brain specific AI Employees

Hierarchy is not automatically superior.

It is useful when complexity requires role separation.

It is wasteful when one clear agent can complete the task.

Single Agent First Rule

Use a single AI Employee when:

the task has one clear purpose
one role can safely complete it
tool selection is limited
the risk is low
the context is contained
output can be checked simply

Do not create a hierarchy merely to appear advanced.

Specialist Separation Rule

Use separate specialists when:

different expertise is required
permissions differ
independent judgement matters
one role should not both create and approve
evidence gathering and decision making should be separated
client or data boundaries differ

Agent Roles

Master Agent

Coordinates a larger work unit.

A Master Agent may:

interpret a structured request
select approved sub workflows
assign specialists
collect results
route for synthesis
route for validation
stop or escalate

A Master Agent must not become an unrestricted system administrator.

Router Agent

Classifies and assigns work.

A Router Agent may determine:

Brain ownership
agent role
task type
risk level
required context
next route

A Router Agent must not complete specialist work merely because it can.

Research Agent

Gathers evidence.

A Research Agent may:

search
retrieve
compare
capture sources
identify gaps
flag conflicts

It must separate evidence from inference.

Extraction Agent

Converts source material into structured fields.

It must not invent missing information.

Structure Agent

Converts approved information into:

framework
checklist
protocol
workflow
page structure
decision model
structured output

Structure must improve reuse, not merely increase length.

Specialist Agent

Performs a narrow expert role.

Examples:

Compliance Review Agent
Finance Break Even Agent
Ads Policy Agent
Data Quality Agent
Automation Risk Agent
Security Review Agent
Chatbot Handoff Agent
Interface Selection Agent
Sales Enquiry Agent
Calendar Proposal Agent

Specialist Agents must be narrow, role carded, permissioned and governed.

Synthesis Agent

Combines multiple outputs.

May:

merge findings
remove duplication
reconcile conflicts
organise sections
preserve warnings
create final reports
create final MCR output

Where several agents contribute, synthesis ownership must be clear.

Checking Agent

Reviews:

completeness
source grounding
structure
ownership
parent page accuracy
duplication
risk
tool permissions
unsupported claims
human review requirements
action autonomy
tool selection
business outcome alignment

Important work must be checked before trust.

Handoff Agent

Prepares:

task summary
next action
owner
context pack
risk note
destination
development brief
client handover

No important AI output should be orphaned.

Rescue Agent

Receives failed work after the retry threshold.

May:

diagnose failure
challenge inherited assumptions
identify missing tools or context
propose a materially different path
define a new verification gate
recommend stopping or escalating

A Rescue Agent must not simply repeat the failed route.

Agent Hierarchy Patterns

Pattern 1 — Deterministic Automation

A fixed workflow completes the task.

Use where judgement is not required.

Pattern 2 — Automation With AI Processing Step

A fixed workflow uses a model for one bounded operation.

Use for:

classification
extraction
summarisation
rewriting
scoring

Pattern 3 — Single Agent

One AI Employee handles the task.

Use for simple, low risk work requiring limited judgement.

Pattern 4 — Agent Plus Checker

One AI Employee performs the work.

A separate checker reviews it.

Use for important but bounded tasks.

Pattern 5 — Router Plus Specialist

A router assigns the request.

A specialist completes it.

Use where correct ownership is the main challenge.

Pattern 6 — Research Plus Synthesis

One agent gathers evidence.

Another interprets and structures it.

Use where source quality matters.

Pattern 7 — Multi Specialist Plus Synthesis Plus Checker

Several specialists contribute.

One agent synthesises.

Another validates.

Use for complex, high value or high risk work.

Pattern 8 — Master Agent Plus Sub Workflows

A Master Agent calls defined sub workflows with structured contracts.

Use for modular AIOS systems.

Pattern 9 — Primary Agent Plus Independent Reviewer

One agent produces the output.

A cognitively independent model or specialist reviews it.

Use for:

governance
finance
compliance
security
architecture
high risk decisions

Pattern 10 — Primary Agent Plus Rescue Route

The primary route attempts the task.

After two materially identical failures, work transfers to a different model, specialist or deterministic process.

Use where repeated execution is possible.

Classification Before Specialist Action

Where requests arrive through a shared channel, MWMS must classify before specialist action.

Shared channels may include:

email inboxes
support inboxes
Telegram
Slack
WhatsApp
web chat
forms
voice channels
Brain Room requests
task intake queues

The classification stage should determine:

request type
business importance
Brain ownership
specialist role
urgency
risk
consent status
required action level
whether a response is required

The classifier should not perform the final specialist action unless the workflow explicitly authorizes that combined role.

Hierarchical Classification Rule

When many similar categories exist, use hierarchical classification.

Example:

First Level

Sales
Support
Finance
Internal
Compliance
Newsletter
Spam
Unknown

Second Level For Sales

Information Request
Qualified Interest
Pricing Request
Call Request
Objection
Follow Up
Existing Opportunity
Unqualified

A small first level classifier followed by narrow specialist classification is preferred over one overloaded classifier with too many ambiguous categories.

Unknown Classification Rule

Unknown or low confidence requests must not be forced into a specialist route.

They should:

request clarification
route to human review
enter an unknown queue
remain unexecuted

Agent Input And Output Contract

Every agent inside a hierarchy must have an input and output contract.

Agent Name:

Owning Brain:

Role:

Authority Level:

Action Autonomy Level:

Input Received:

Input Source:

Caller Identity:

Trust Level:

Context Required:

Model Or Capability Required:

Tool Access Allowed:

Tool Access Prohibited:

Decision Scope:

Output Required:

Output Format:

Handoff Destination:

Validation Requirement:

Failure Threshold:

Rescue Route:

Stop Conditions:

Logging Requirement:

Knowledge Commitment Requirement:

A hierarchy fails when agents do not know what they receive, what they produce and who receives the result.

Agent Decision Contract

Every decision capable agent should define:

Permitted Decisions:

Prohibited Decisions:

Evidence Required:

Tool Selection Rules:

Approval Requirements:

Confidence Threshold:

Missing Context Behaviour:

Conflict Behaviour:

Escalation Rule:

Execution Boundary:

Decision Rule

The agent must not convert uncertainty into confident action.

Structured Sub Workflow Contract

Automated agent hierarchies should define:

expected structured input
required fields
optional fields
output schema
source reference
task ID
requesting agent
receiving agent
client ID
error response
validation rule
idempotency
timeout
failure behaviour
capability version
action autonomy level

Sub agents and sub workflows require clear structured contracts before automation.

Five Level Agent Testing Model

Every production agent must be tested at five levels.

Level 1 — Tool Unit Test

Confirm that each capability works independently.

Test:

valid input
invalid input
permission enforcement
expected output
timeout
retry
duplicate request
error response
logging

Level 2 — Input Contract Test

Confirm that the agent:

accepts valid input
rejects malformed input
detects missing fields
preserves caller identity
handles unsupported attachments
handles uncertain transcription
prevents wrong client context

Level 3 — Tool Selection Test

Confirm that the agent:

selects the correct capability
does not call irrelevant tools
does not call prohibited tools
stops when no suitable tool exists
handles two plausible tools safely
respects risk and approval rules

Level 4 — Action Execution Test

Confirm that the chosen capability:

performs the intended action
uses the correct target
uses the correct data
prevents duplicates
records the action
respects approval
fails safely

Level 5 — End To End Business Outcome Test

Confirm that the complete workflow:

solves the intended business problem
produces the correct outcome
reaches the correct destination
preserves evidence
records state
creates no hidden side effects
supports recovery
meets cost and timing boundaries

Required Adversarial And Failure Tests

Also test:

ambiguous request
missing context
conflicting context
failed tool
tool timeout
repeated request
duplicate execution
unauthorized action
approval required action
cost limit
memory contamination
stale knowledge
wrong client context
malicious or misleading input
unsupported instruction
interrupted workflow
model fallback

Testing Rule

Do not test only whether the agent can complete the happy path.

Test whether it knows when not to act.

Action Autonomy Levels

Every external or state changing capability must define one of five autonomy levels.

Level 1 — Recommend

The AI Employee recommends an action.

It does not prepare or execute the action.

Level 2 — Draft

The AI Employee creates a reviewable draft.

Examples:

email draft
response draft
task draft
meeting suggestion
record update proposal

Level 3 — Prepare

The AI Employee prepares the action for approval.

Examples:

calendar proposal
configured task record
prepared CRM update
prepared publishing package
prepared deployment plan

The action remains unexecuted.

Level 4 — Execute After Approval

The AI Employee may execute only after a valid approval event.

The approval must be:

attributable
current
specific
recorded
within the approver’s authority

Level 5 — Bounded Autonomous Execution

The AI Employee may execute without case by case approval only inside a narrow pre approved boundary.

Bounded autonomy requires:

approved task category
approved data scope
approved systems
approved action types
approved schedule or trigger
duplicate protection
cost boundary
monitoring
complete logging
stop condition
revocation
emergency shutdown
periodic review

Default External Action Rule

External communication, calendar booking, publishing, financial action, customer state changes, task creation and system modifications default to Draft or Prepare unless a higher autonomy level has been explicitly approved.

Email Action Rule

An AI Employee must not send email merely because it can create a suitable response.

The system must define whether it may:

recommend
draft
prepare
send after approval
send autonomously within a bounded case

Calendar Action Rule

Before creating an event, the system must resolve:

date
year
timezone
duration
attendee
attendee email
calendar
availability
conflict status
meeting type
location or meeting link
approval status

Task Creation Rule

Tasks created by AI must route into the approved Project Manager Brain or task source of truth.

Notion, spreadsheets, email or chat tools must not become competing operational task systems unless explicitly approved.

Remote Command Channel Standard

Remote command channels may include:

mobile messages
secure chat
voice commands
webhooks
cloud task submission
remote consoles

A remote command channel must:

authenticate the sender
preserve sender identity
classify the request
determine Brain ownership
assess risk
restrict available actions
require approval where needed
log the command
support revocation
prevent unrestricted system control
record transcription confidence where voice is used

A message arriving through an approved channel is an input.

It is not automatically an authorised action.

Voice Input Rule

Voice is an interface, not authority.

Voice input should follow:

Audio
↓
Transcription
↓
Confidence Check
↓
Critical Field Confirmation
↓
Classification
↓
Normal Agent Workflow

Names, dates, amounts, addresses, approvals and destructive actions must be confirmed when transcription confidence is insufficient.

Model And Capability Routing

MWMS may route different work units to different models or systems.

Possible roles include:

primary reasoning model
low cost bulk processor
multimodal specialist
long context model
code capable model
independent reviewer
rescue model
local private model
deterministic validator

Model selection should consider:

task complexity
required modality
cost
speed
context length
tool compatibility
reliability
privacy
independence
risk
structured output performance
current availability
fallback readiness

Model Interchangeability Rule

The AI Employee role, context contract, tool layer, output contract and business outcome must remain separable from the model provider.

MWMS must not define a permanent operating role around one temporary model brand.

Model changes require:

evaluation
output comparison
tool compatibility testing
cost review
risk review
fallback validation
version logging

Persistent AI Employee Operations

A persistent AI Employee operates beyond one live chat session.

Persistent operation may include:

scheduled work
inbox monitoring
source monitoring
report generation
post deployment checks
recurring research
remote requests
queue processing
knowledge review

Persistent agents require:

named owner
defined role
approved environment
approved tools
approved schedule or trigger
execution boundaries
cost boundaries
logging
monitoring
failure threshold
stop condition
revocation
emergency shutdown
human escalation

Background Worker Standard

A background worker performs approved work without continuous human interaction.

A background worker must define:

Worker Name:

Owning Brain:

Purpose:

Trigger:

Schedule:

Input Source:

Context Source:

Tools:

Permission Level:

Action Autonomy Level:

Output:

Destination:

Maximum Runtime:

Maximum Cost:

Retry Limit:

Failure Threshold:

Rescue Route:

Notification Rule:

Shutdown Method:

Human Owner:

Status:

A background worker must not continue indefinitely after unresolved failure.

Scheduled Routine Standard

Scheduled routines may support:

health checks
inbox processing
source ingestion
status reports
cost reports
knowledge review
security scans
post deployment checks
recurring research

Every scheduled routine must define:

business purpose
frequency
owner
input
action
output
duplicate prevention
expiry or review date
failure alert
cost limit
shutdown method

A recurring task should not remain active merely because it was once useful.

Post Deployment Watchdog

A monitored AI workflow may perform post deployment checks.

Possible checks include:

uptime
error logs
failed requests
broken integrations
response quality
cost spikes
permission failures
security warnings
data integrity issues
capability version drift

A watchdog must not automatically make broad corrective changes unless explicitly authorised.

Monitoring and remediation are different permission levels.

External Knowledge Engine Operations

AI Employees may use external knowledge engines for:

large source storage
source retrieval
historical continuity
semantic search
session history access
cross interface knowledge
source grounded artifact generation

The knowledge engine is responsible for storage and retrieval.

The reasoning agent is responsible for interpretation and authorised action.

The knowledge engine must not become final authority.

The reasoning agent must not become the sole organisational archive.

RAG Ingestion Boundary

A document must not enter production retrieval merely because it was uploaded.

Before ingestion, confirm:

source identity
owner
client or company
approval status
version
effective date
expiry date
duplicate status
superseded status
access policy
tenant boundary
file safety
deletion policy

RAG Retrieval Boundary

Retrieved knowledge must preserve:

source document
version
section or chunk
retrieval timestamp
approval status
tenant
confidence or relevance signal
conflict status

The agent must fail safely when:

no relevant evidence exists
results conflict
results are below threshold
the source is superseded
the source is unapproved
the caller lacks access

Internal knowledge, external research, memory and model inference must remain distinguishable.

Session Closure And Knowledge Commitment

A meaningful AI work session must conclude with a closure process.

Closure should record:

objective
completed work
attempted work
decisions
corrections
lessons
open threads
current save point
next action
commitment destination
verification status

Possible commitment destinations include:

MCR
Brain page
decision record
task record
failure log
lessons log
project save point
session history
external knowledge engine
client record

AI work should improve the system over time rather than resetting to zero when a session ends.

Agentic Work Unit Standard

Every important AI task should become an Agentic Work Unit.

A mature Agentic Work Unit should include:

Request:

Request Source:

Current User Instruction:

Classification:

Originating Brain:

Assigned Brain:

Assigned AI Employee:

Agent Necessity Outcome:

Agent Pattern:

Model Or Capability Route:

Authority Level:

Action Autonomy Level:

Input Payload:

Required Context:

External Knowledge Required:

Source Material:

Tool Permission Level:

Risk Level:

Task Instruction:

Output Format:

Validation Rule:

Independent Review Requirement:

Failure Threshold:

Rescue Route:

Human Review Requirement:

Handoff Destination:

Business Outcome:

Event Log Requirement:

Knowledge Commitment Requirement:

Learning Or Kaizen Capture:

Default MWMS AI Workflow Pattern

The default MWMS AI workflow is:

Input Capture
↓
Input Cleaning
↓
Context Selection
↓
Classification
↓
Brain Ownership
↓
Task Creation
↓
Agent Necessity Test
↓
Automation Or Agent Pattern Selection
↓
AI Employee Assignment
↓
Model Or Capability Routing
↓
Tool Permission Check
↓
Action Autonomy Check
↓
Processing
↓
Parallel Specialist Work Where Justified
↓
Synthesis Where Required
↓
Validation
↓
Independent Review Where Required
↓
Decision
↓
Approval Where Required
↓
Execution Where Authorized
↓
Outcome Verification
↓
Routing
↓
Logging
↓
Reporting
↓
Knowledge Commitment
↓
Kaizen Review

AI Employee Role Card Requirement

Every formal AI Employee should have a role card containing:

Employee Name:

Owning Brain:

Authority Level:

Purpose:

Primary Responsibilities:

Non Responsibilities:

Input Types:

Required Context:

System Instructions:

Variable Task Input:

Output Types:

Output Standard:

Approved Tools:

Approved Capabilities:

Forbidden Tools Or Actions:

Model Or Capability Requirements:

Workflow Position:

Agent Pattern:

Action Autonomy Level:

Handoff Destinations:

Escalation Rules:

Validation Rules:

Failure Threshold:

Rescue Route:

Success Metrics:

Failure Modes:

Human Review Requirement:

Logging Requirement:

Persistent Operation Status:

Schedule Or Trigger:

Shutdown Method:

Security Requirements:

Knowledge Commitment Requirement:

Related Standards:

Change Log:

No AI Employee should perform serious work without defined identity, context, permissions, output rules, failure handling and escalation boundaries.

Tool Permission Rule

AI Employees may only use approved:

tools
APIs
files
databases
browser actions
communication channels
publishing routes
deployment routes
remote command channels
client systems
reusable capabilities

Tool permission must be:

role specific
task specific
risk appropriate
revocable
logged
reviewable

Security And Client Boundary

AI Employees must not:

cross client data boundaries
expose credentials
reveal system prompts
use unapproved external tools
store sensitive data without authority
send data to unapproved models
bypass approval
create hidden persistence
create uncontrolled background processes
execute destructive actions from ambiguous messages
use private personal data for unnecessary lead profiling

Observability Standard

Every serious AI workflow should record enough information to answer:

what was requested
who requested it
what Brain owned it
which AI Employee acted
why an agent was used
what model was used
what context was used
what tools were used
what capability versions were used
what evidence was retrieved
what decisions were made
what action level applied
what validation occurred
what failed
what was retried
what rescue route was used
what outcome occurred
what it cost
what was committed to memory or MCR
whether human approval occurred

Minimum Observability Metadata

Task ID:

Session ID:

User Or Caller ID:

Client ID:

Brain:

AI Employee:

Agent Necessity Outcome:

Agent Pattern:

Model:

Model Version:

Prompt Or Instruction Version:

Context Sources:

Tool Calls:

Capability Versions:

Permission Level:

Action Autonomy Level:

Start Time:

End Time:

Runtime:

Token Or Usage Cost:

Validation Result:

Review Result:

Approval Event:

Failure Code:

Retry Count:

Rescue Route:

Outcome:

Knowledge Commitment:

Shutdown Or Completion Status:

Cost Control Standard

Every AI system should define:

expected usage
expected model cost
expected tool cost
maximum cost per task
maximum cost per period
alert threshold
fallback model
stop condition
human approval threshold

Cost must be connected to business value.

Low cost does not justify low quality.

High capability does not justify uncontrolled spend.

Failure Handling

Failure may include:

missing context
invalid input
tool failure
permission failure
model failure
timeout
malformed output
unsupported claim
memory contamination
wrong classification
wrong Brain routing
duplicate action
client boundary violation
action execution failure
business outcome failure

Failure Response Options

retry within limit
use fallback model
use deterministic fallback
transfer to specialist
transfer to rescue agent
request clarification
request human approval
stop
roll back
revoke tool access
disable persistent worker
create failure record

Repeated Failure Rule

After two materially identical failures, do not merely repeat the same route.

Change:

model
context
tool
specialist
method
validation
assumptions

or stop.

Human Review

Human review remains required when:

the outcome is high risk
evidence is weak
financial authority is involved
legal or compliance exposure exists
customer communication creates commitment
a meeting is being booked outside approved boundaries
a task changes project priority
a system state is being changed
deployment is involved
a client deliverable is final
an external message may damage trust
the agent requests authority it does not hold

Independent Review

Independent review should be used when:

the producing model may share the same blind spot
architecture matters
financial decisions matter
compliance matters
security matters
important claims require challenge
high value client work is produced

The reviewer should not merely rewrite the output.

It should assess:

evidence
assumptions
omissions
permissions
risk
outcome fit
action boundary
failure exposure

Kaizen Requirement

The MWMS Kaizen Loop is:

Reflect → Reduce → Refine → Record

AI workflows should capture:

what created friction
what failed
what context was missing
what tool permission was unclear
what output was rejected
what caused rework
what repeated correction occurred
what rule needs refinement
whether an agent was justified
whether deterministic automation would have been better
whether hierarchy was justified
whether a specialist helped
whether a checker caught risk
whether routing was cost efficient
whether persistent execution added value
whether rescue happened early enough
whether the correct capability was selected
whether the autonomy level was appropriate
whether the business outcome was actually achieved

MWMS AI Agent Operations Checklist

Before deployment, confirm:

Agent Necessity

deterministic automation was considered
AI processing step was considered
agent use is justified
hierarchy is justified
business benefit is clear

Role

owner is defined
purpose is defined
responsibilities are defined
non responsibilities are defined
authority is defined

Context

required context is identified
stale context is excluded
client context is isolated
memory type is known
durable state is defined

Tools And Capabilities

tools are approved
capabilities are contracted
permissions are recorded
versions are recorded
destructive actions are restricted
capability changes are controlled

Action Autonomy

autonomy level is assigned
approval rule is defined
bounded execution limits are defined
revocation exists
emergency shutdown exists

Testing

tool unit tests passed
input contract tests passed
tool selection tests passed
action execution tests passed
end to end outcome tests passed
failure tests passed
duplicate tests passed
permission tests passed

Validation

output validation is defined
source checks are defined
schema checks are defined
independent review is defined where required
human review is defined where required

Operations

trigger is approved
schedule is approved
cost boundary is defined
logging is active
monitoring is active
failure threshold is defined
rescue route is defined
stop condition exists

Outcome

business outcome is defined
destination is defined
outcome verification is defined
knowledge commitment is defined
Kaizen feedback is defined

Drift Protection

The system must prevent:

using agents where automation is enough
creating hierarchy for appearance
one general agent controlling everything
tool access without operational permission
reusing capabilities without version control
platform specific implementation becoming Canon architecture
model brand becoming employee identity
shared channels bypassing classification
low confidence classification forcing action
voice transcription being treated as authority
email sending without an approved autonomy level
meeting creation without timezone and availability checks
task creation outside the approved Project Manager Brain source of truth
RAG uploads entering production without approval
retrieved content being treated as final authority
internal and external evidence being mixed without traceability
successful tool calls being mistaken for successful outcomes
persistent agents operating without monitoring
autonomous actions operating without revocation
agents continuing after repeated failure
hidden costs
client data leakage
knowledge failing to commit at session end

Architectural Intent

The MWMS AI Agent Operations Core exists to turn AI capability into governed business operations.

Its architectural role is to connect:

business purpose
Brain ownership
agent necessity
AI Employee role
context
model
memory
tools
reusable capabilities
task
validation
approval
execution
outcome
observability
failure recovery
knowledge commitment
learning

The long term objective is not to create the largest possible agent network.

The objective is to create the smallest reliable governed workforce capable of producing strong business outcomes.

The system should be:

modular
tool agnostic
model agnostic
source grounded
observable
permissioned
testable
recoverable
revocable
client safe
cost visible
outcome driven

Final Standard

Before any AI agent becomes operational, MWMS must know:

why an agent is required
why automation is insufficient
who owns it
what role it performs
what context it uses
what model or capability route it uses
what tools it may call
what capabilities are approved
what action level it holds
how each tool was tested
how the complete system was tested
how its work is validated
what happens when it fails
how it is stopped
what business outcome it must achieve
where its learning is committed

Use deterministic automation first where it is sufficient.

Use a single AI Employee first where an agent is required.

Add specialists only where role separation improves quality, permission control or risk.

Build reusable capabilities once and govern their reuse.

Classify shared channel requests before specialist action.

Test tools independently before testing the complete agent.

Treat external action as a permissioned autonomy decision.

Keep role, context, tools, memory, model and operational state separate.

Verify the business outcome, not only the tool execution.

Do not allow persistent agents to operate without monitoring and shutdown.

Synthesize multi agent output.

Check important output before trust.

That is the operating core of MWMS AI work.

Change Log

Version: v1.4
Date: 2026-06-27
Author: HeadOffice

Change:

Updated the MWMS AI Agent Operations Core using the strongest non duplicative intelligence from the AI Automations By Jack AI Agents block.

Preserved the existing v1.3 operating foundation covering:

role based AI Employees
context selection
orchestration
task structure
tool permissions
validation
outcomes
agent hierarchy
model routing
independent review
deterministic rescue
persistent agents
background workers
scheduled routines
remote command channels
external knowledge engines
session closure
Agentic Work Units
role cards
observability
cost control
failure handling
shutdown
Kaizen learning

Added:

Agent Necessity Test
Automation Before Agent Rule
deterministic automation outcome
automation with AI processing step outcome
deterministic router outcome
formal agent justification burden
Reusable Tool Capability Library Principle
Reusable Capability Contract
capability reuse and version change rules
Tool Execution Versus Outcome Rule
Classification Before Specialist Action
Hierarchical Classification Rule
Unknown Classification Rule
Agent Decision Contract
Five Level Agent Testing Model
adversarial and failure test requirements
five Action Autonomy Levels
default external action rule
email action rule
calendar action rule
Project Manager Brain task creation rule
voice input confidence and confirmation rule
Model Interchangeability Rule
stronger RAG ingestion and retrieval boundaries
stronger internal, external, memory and inference separation
expanded Agentic Work Unit fields
expanded role card fields
expanded observability metadata
expanded deployment checklist
expanded drift protection
updated final standard

Purpose of update:

To ensure MWMS chooses agents only when agents are genuinely required, reuses approved operational capabilities safely, tests agents at tool, selection, execution and business outcome levels, classifies shared channel requests before specialist action, and controls external actions through explicit autonomy levels.

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

Change:

Expanded the MWMS AI Agent Operations Core into a complete operating foundation for session bound, multi agent, persistent, remotely triggered, independently reviewed and failure resilient AI Employees.

Added persistent cloud agents, background workers, scheduled routines, remote command channels, role based model routing, independent review, deterministic rescue routing, external knowledge systems, formal session closure, skill composed capabilities, observability, cost control and controlled shutdown.

Purpose of update:

To evolve the MWMS AI Agent Operations Core from an agentic workflow and hierarchy standard into a complete operating foundation for session bound, multi agent, persistent, remotely triggered, independently reviewed and failure resilient AI Employees across MWMS and future AIBS client systems.

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

Change:

Added formal Agent Hierarchy Design covering Master Agents, Router Agents, Research Agents, Extraction Agents, Structure Agents, Specialist Agents, Synthesis Agents, Checking Agents, Handoff Agents and sub workflows.

Added Single Agent First Rule, complexity cost governance, hierarchy patterns, input and output contracts and structured sub workflow contracts.

Purpose of update:

To evolve the core into an AI workforce architecture standard capable of governing single agent, specialist agent, master agent, synthesis agent, checking agent and sub workflow patterns.

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

Change:

Added AI Operating System alignment, Context as an operating foundation, richer Agentic Work Unit fields, context selection, tool permission checks, system message and user input separation, RAG requirements, role card expansion, security preflight and Kaizen requirements.

Purpose of update:

To evolve the core into a stronger operating foundation for AI Employees, Brain workflows, AIOS systems, permissioned tool use and future AIBS delivery.

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

Change:

Created the MWMS AI Agent Operations Core as the foundational operating standard for role based AI Employees, Agentic Work Units, orchestration, task workflows, validation, handoffs, reporting and business outcomes.

Change Impact Declaration

This v1.4 update expands the MWMS AI Agent Operations Core from mature agent workforce governance into a stronger decision and capability operating standard covering agent necessity, automation first design, reusable capabilities, hierarchical classification, five level testing, bounded action autonomy and verified business outcomes.

Pages Created

None

Pages Updated

MWMS AI Agent Operations Core v1.3 To v1.4

Pages Deprecated

None

Registries Requiring Update

MWMS AI Agent Operations Core Page Registry

MWMS AI Agent Operations Core Copy Map

HeadOffice Page Registry If Version Tracking Is Maintained

MWMS Architecture Registry If Version Tracking Is Maintained

Canon Version Update Required

Change Log Entry Required

Yes

Strategic Absorption Result

MWMS gains a stronger operating core that governs not only how AI Employees work, but whether an agent should exist at all, how approved capabilities are reused, how specialist actions are selected, how external actions are bounded, how agents are tested, and how successful execution is separated from successful business outcomes.

END OF FULL FILE OUTPUT