MWMS AI Work Session Persistence Standard

System: MWMS
Document Type: Standard
Status: Draft For MCR
Authority: HeadOffice
Applies To: All MWMS Brains, AI Employees, Brain Room, Dev Console, HeadOffice Intelligence, Deep Search Workflows, Research Workflows, Affiliate Evaluation, Ads Review, Content Workflows, Experimentation Brain, Future Client Facing AI Systems
Primary Location: MCR
Future Operational Destination: mwmsbrain.site, mwmsheadofficebrain.site, Brain Room, Dev Console, AI Employee Dashboards, Future Client Portals
Parent Page: HeadOffice
Source Of Truth: MCR
Related Frameworks: MWMS Agent Loop Control Framework, MWMS Next Action Picker Standard, MWMS Agent Loop Context Schema, MWMS AI Observability Metadata Standard, MWMS AI Employee Evaluation Scorecard Standard, MWMS Deep Search Quality And Observability Framework
Course Source: Matt Pocock AIhero Build DeepSearch In TypeScript
Absorption Status: Approved For Integration

Purpose

The purpose of this standard is to define how MWMS stores, resumes, reviews, and reuses AI work sessions.

An AI work session is more than a chat.

An AI work session is a recorded unit of work that may include:

user messages
AI Employee responses
action history
visible workflow steps
source activity
tool activity
database activity
annotations
generated title
workflow state
evidence trail
review status
final output
Kaizen notes

This standard ensures AI work does not disappear after a response is generated.

MWMS must treat valuable AI work as durable operational memory.

Scope

This standard applies to any MWMS system where AI performs, supports, records, analyses, or recommends work.

This includes:

Brain Room conversations
Dev Console support sessions
HeadOffice Intelligence reviews
Newsletter Intelligence processing
Research Brain investigations
Affiliate Brain offer evaluations
Ads Brain compliance reviews
Content Brain research sessions
Data Brain validation workflows
Experimentation Brain test analysis
Finance Brain cost reviews
Deep Search workflows
Agent loop workflows
Future client-facing AIBS sessions
Future AI Employee dashboards
Future task and workflow systems

This standard does not define exact database implementation.

It defines the MWMS governance and structure for persistent AI work sessions.

Core Rule

Every meaningful AI work session must be persistable, resumable, traceable, and reviewable.

The MWMS rule is:

AI work should not live only in temporary chat output.

If the work matters to MWMS, it must become a durable work record.

Definition Of An AI Work Session

An AI Work Session is a structured record of AI-assisted work.

It may begin from:

a human message
a Brain Room thread
a Dev Console question
an AI Employee task
a newsletter item
an offer evaluation
a research request
a source inspection workflow
a HeadOffice review
an automation trigger
a client-facing request

It may contain:

conversation history
action history
source records
tool actions
decisions
outputs
review notes
trace metadata
evaluation results
Kaizen learnings

The session is the durable container for the work.

Why AI Work Session Persistence Matters

Without session persistence, MWMS risks:

losing important context
repeating work
creating orphaned answers
breaking audit trails
losing source evidence
losing action history
making sessions hard to resume
making outputs hard to review
making AI Employees difficult to evaluate
making handoff between Martyn, M, and future AI Employees harder
making HeadOffice visibility weaker
turning useful AI work into disposable chat

With session persistence, MWMS gains:

operational memory
resumable workflows
better search and retrieval
stronger review process
better debugging
better Kaizen learning
stronger AI Employee accountability
better client-facing readiness
better HeadOffice oversight

Work Session Versus Chat

A chat is a conversation.

A work session is a business record.

Chat	AI Work Session
temporary conversation	durable work record
messages only	messages plus actions, sources, state, and outcome
hard to audit	traceable
hard to resume	resumable
weak business context	linked to Brain, task, workflow, and Employee
answer focused	outcome and process focused
user-facing only	system and HeadOffice visible

MWMS must treat important AI sessions as work sessions, not casual chats.

Required Session Components

A complete AI work session should contain:

Session identity
Brain and AI Employee ownership
User or trigger origin
Message history
Action history
Visible step annotations
Source and evidence records
Tool activity
Database activity
Trace metadata
Generated title
Workflow state
Final output
Review status
Evaluation result
Kaizen note

Not every early implementation needs all fields, but the architecture should allow them.

1. Session Identity

Each AI work session needs a stable identity.

Recommended fields:

Field	Description
session_id	Unique session ID
thread_id	Conversation or Brain Room thread ID
task_id	Related task ID if applicable
trace_id	Related observability trace ID
loop_id	Related agent loop ID if applicable
created_at	Session creation time
updated_at	Last session update time
session_status	Open, active, completed, parked, failed, archived
session_type	Chat, task, research, evaluation, source review, report, support

Rule

No meaningful AI work should be stored without a stable session ID.

2. Brain And AI Employee Ownership

Each session must show which system owns the work.

Recommended fields:

Field	Description
brain_name	Brain responsible for the session
brain_site	Site where session belongs
ai_employee_name	AI Employee handling the work
ai_employee_role	Employee role or function
workflow_type	Type of workflow
workflow_name	Specific workflow name
source_of_truth	MCR, Brain site, Supabase, WordPress, external tool
parent_system	Higher-level system or workflow

Rule

If a session cannot identify its owning Brain, it should be routed to HeadOffice review.

3. User Or Trigger Origin

Each session should record how it started.

Recommended fields:

Field	Description
user_id	User ID where available
user_name	Human operator name
user_role	Martyn, M, Admin, Developer, Client, AI Employee
request_origin	Brain Room, Dev Console, Newsletter, Task Queue, API, Client Portal
trigger_type	Manual, automatic, scheduled, event-based, routed
trigger_record_id	Record that triggered the session if applicable
client_id	Client account if relevant
organisation_id	Organisation if relevant

Rule

MWMS must know whether a session was started by a human, AI Employee, automation, or external trigger.

4. Message History

The full relevant message history should be preserved.

Message history may include:

user messages
AI responses
system messages
tool-visible messages
review comments
clarification messages
final answer messages

Recommended message fields:

Field	Description
message_id	Unique message ID
session_id	Parent session
role	User, assistant, system, tool, reviewer
content	Message text or structured content
message_parts	Structured parts if available
annotations	Step notes or metadata attached to message
created_at	Message creation time
order_index	Message order
visibility	Internal, operator-facing, client-facing
source	Human, AI Employee, system, tool

Rule

AI Employees should use the full relevant work session context, not only the latest instruction.

5. Message Parts

Messages may contain more than text.

A message may include:

plain text
structured output
source references
tool results
reasoning notes
step annotations
citations
screenshots
file references
JSON objects
decision records
routing records

Rule

MWMS should preserve structured message parts where they carry operational value.

Flattening everything into plain text can destroy useful system context.

6. Action History

AI Employee actions must be recorded as part of the session.

Examples of actions:

search
inspect source
query database
evaluate evidence
generate answer
route
escalate
create task
update record
request human review
park
reject
stop

Recommended action fields:

Field	Description
action_id	Unique action ID
session_id	Parent session
step_number	Action step
action_type	Search, inspect_source, answer, route, escalate, etc.
action_reason	Why the action was chosen
action_status	Pending, completed, failed, skipped
tool_used	Tool used if applicable
input_summary	What was passed into the action
output_summary	What came back
cost_estimate	Estimated cost
latency_ms	Action time
failure_reason	Failure if applicable
used_in_final_output	Yes or no

Rule

The action trail is part of the work session, not separate background noise.

7. Visible Step Annotations

Visible step annotations are human-readable notes showing what the AI Employee is doing.

Examples:

Understanding request
Searching external sources
Inspecting official source
Checking internal records
Evaluating evidence
Preparing final answer
Routing to Affiliate Brain
Human review required

Annotations help operators understand progress while work is happening.

Recommended annotation fields:

Field	Description
annotation_id	Unique annotation ID
session_id	Parent session
action_id	Related action if applicable
label	Short visible step label
description	Optional detail
status	Pending, active, complete, failed
created_at	Time created
visibility	Internal, operator-facing, client-facing

Rule

AI Employee loops should not appear as silent loading states when meaningful work is happening.

8. Source And Evidence Records

Research sessions must preserve source and evidence context.

Recommended fields:

Field	Description
source_ids	Stored source records
source_urls	URLs used
source_titles	Source titles
inspected_source_count	Number of sources inspected
evidence_summary	Summary of evidence gathered
evidence_sufficiency	Weak, acceptable, strong
source_trust_rating	Low, medium, high
source_freshness_rating	Outdated, acceptable, current, unknown
conflicting_sources_detected	Yes or no
source_used_in_final_output	Yes or no

Rule

If sources helped produce the answer, the session should preserve which sources mattered and why.

9. Tool Activity

Tool activity should be connected to the work session.

Recommended fields:

Field	Description
tool_name	Name of tool
tool_type	Search, scraper, database, file, email, analytics, etc.
tool_input_summary	Summary of input
tool_output_summary	Summary of result
tool_status	Completed, failed, skipped
tool_error	Error if failed
tool_latency_ms	Tool execution time
tool_cost_estimate	Tool cost if available
tool_result_used	Whether result affected final output

Rule

Tool actions should not disappear after the final answer is generated.

10. Database Activity

Database activity should be visible where relevant.

Recommended fields:

Field	Description
records_read	Internal records read
records_written	Internal records created
records_updated	Internal records updated
records_failed	Failed DB actions
parent_record_id	Parent entity
output_record_id	Saved output
db_operation_status	Successful, partial, failed
db_error_summary	Error if any
duplicate_detected	Yes or no

Rule

A session is not fully successful if required backend persistence fails.

11. Generated Session Titles

AI work sessions should receive meaningful, stable, human-readable titles.

Bad titles:

first 50 characters of message
Untitled Chat
New Conversation
Help please
Question

Better titles:

Affiliate Offer Evaluation For Aqua Tower
Google Ads Policy Check For Health Claims
Research Session On AI Tool Pricing
Newsletter Signal Review For HeadOffice
Dev Console Support For Supabase Connector
Deep Search Source Review For Vendor Page

Recommended title fields:

Field	Description
generated_title	AI-generated title
title_source	AI generated, user edited, system generated
title_confidence	Confidence in title
title_locked	Whether user/system locked the title
title_updated_at	Last title update

Rule

AI-generated titles should summarise the work session, not merely repeat the first message.

12. Workflow State

A session should store its workflow state.

Suggested statuses:

Status	Meaning
open	Session exists but work not complete
active	Work is currently happening
waiting_for_user	Needs user input
waiting_for_review	Needs human review
routed	Sent to another Brain or Employee
parked	Paused for later
completed	Final output exists
failed	Could not complete
archived	Closed for historical reference

Rule

MWMS should be able to tell whether a session is still active, completed, parked, failed, or waiting for review.

13. Final Output

Each meaningful session should identify its final output.

Recommended fields:

Field	Description
final_output_created	Yes or no
final_output_type	Answer, report, recommendation, task, route, decision, page draft
final_output_location	Where output is stored
final_answer_summary	Short summary
final_confidence	Confidence score
final_limitations	Limitations
final_decision	Proceed, reject, park, route, test, monitor, escalate
final_next_action	Recommended next action

Rule

A session should not be considered complete unless the final output is stored or the reason for no output is recorded.

14. Review Status

Sessions may require human review.

Recommended fields:

Field	Description
human_review_required	Yes or no
review_reason	Why review is needed
reviewed_by	Reviewer name
reviewed_at	Review time
review_status	Pending, approved, rejected, needs revision
review_notes	Human review notes
approval_status	Approved, blocked, pending

Rule

Review status must be part of the work session, not only a separate comment or memory.

15. Evaluation Result

Sessions may include evaluation results.

Recommended fields:

Field	Description
evaluation_required	Yes or no
evaluation_score	Scorecard result
factuality_score	Factuality score
relevancy_score	Relevancy score
source_quality_score	Source score
safety_score	Safety score
traceability_score	Traceability score
regression_case_created	Yes or no
failure_reason	Why eval failed if applicable

Rule

If a session reveals a quality issue, it should be eligible to become an eval or regression case.

16. Kaizen Note

Every valuable session should support improvement.

Recommended fields:

Field	Description
kaizen_note	Improvement note
improvement_category	Prompt, tool, source, workflow, UI, evaluation, data, cost
improvement_priority	Low, medium, high
recommended_follow_up	Suggested improvement
added_to_regression	Yes or no
routed_for_improvement	Destination Brain or system

Rule

A completed AI work session should not only answer the task.

It should also help MWMS improve when possible.

Session Resume Rule

An AI work session should be resumable.

To resume properly, the system should preserve:

original request
message history
current workflow state
action history
evidence summary
source IDs
final or partial output
pending review status
next action
unresolved issues
Kaizen notes

A resumed session should not require the human to restate everything.

Session Search And Retrieval Rule

Persistent sessions should be searchable.

Searchable fields should include:

generated title
Brain
AI Employee
workflow type
user
session status
source URLs
final output summary
tags
created date
updated date
decision outcome
review status
Kaizen category

MWMS should be able to find old AI work sessions quickly.

Session Title Quality Rule

A good generated title should be:

short
specific
stable
human-readable
related to the work objective
useful in a list view
not overly clever
not generic
not misleading

Preferred title pattern:

[Workflow Type] For [Subject]

Examples:

Source Review For Google Ads Health Policy
Offer Evaluation For Aqua Tower
Deep Search Session For AI Tool Pricing
Dev Console Support For Brain Room Error
Newsletter Routing Review For AI Compliance Signal

Session Ownership Rule

Every session should have one primary owner.

Ownership may belong to:

a Brain
an AI Employee
a human operator
a task
a client account
a workflow
HeadOffice

Ownership prevents orphaned sessions.

If ownership is unclear, route to HeadOffice.

Session Visibility Rule

Not all session data should be visible to every user.

Visibility levels may include:

Level	Meaning
internal_system	system only
head_office	HeadOffice review
operator	Martyn, M, approved internal users
client_visible	client-facing
developer	technical/debugging view
archived	historical reference

Rule

MWMS should separate internal traces from user-facing session content.

Session Privacy And Security Rule

Persistent sessions must not expose unnecessary sensitive information.

Avoid storing raw:

API keys
passwords
private credentials
payment details
private personal data
confidential client details beyond what is needed

Where possible, store:

IDs instead of raw secrets
summaries instead of full sensitive text
redacted values
permission-controlled records

Persistence should strengthen MWMS memory without creating security risk.

Work Session Lifecycle

Suggested lifecycle:

Session created
Title assigned or generated
Message received
AI Employee assigned
Context loaded
Actions performed
Annotations recorded
Sources or records attached
Final output generated
Backend persistence confirmed
Review or routing completed
Evaluation or Kaizen captured
Session completed, parked, routed, or archived

Minimum Starting Implementation

MWMS does not need to implement every field immediately.

The first practical implementation should capture:

session ID
thread ID or task ID
Brain
AI Employee where applicable
generated title
message history
action history
visible step annotations
final output
status
review status
trace ID where available
Kaizen note where useful

This is enough to begin turning AI work into durable system memory.

Recommended Conceptual Session Record

{
  "session_id": "",
  "thread_id": "",
  "task_id": "",
  "trace_id": "",
  "loop_id": "",
  "created_at": "",
  "updated_at": "",
  "session_status": "",
  "session_type": "",
  "generated_title": "",
  "title_source": "",
  "brain_name": "",
  "brain_site": "",
  "ai_employee_name": "",
  "workflow_type": "",
  "workflow_name": "",
  "user_name": "",
  "user_role": "",
  "request_origin": "",
  "trigger_type": "",
  "message_history": [],
  "action_history": [],
  "annotations": [],
  "source_ids": [],
  "evidence_summary": "",
  "tools_used": [],
  "records_read": [],
  "records_written": [],
  "final_output_created": false,
  "final_output_type": "",
  "final_output_location": "",
  "final_answer_summary": "",
  "final_confidence": 0,
  "final_decision": "",
  "human_review_required": false,
  "review_status": "",
  "evaluation_score": 0,
  "failure_reason": "",
  "kaizen_note": "",
  "visibility": ""
}

This is a conceptual schema only.

Exact implementation can be adapted by M or future developers.

Relationship To Agent Loop Context

The Agent Loop Context describes the live working state of the loop.

The AI Work Session is the durable parent record that stores the overall work.

Relationship:

Agent Loop Context	AI Work Session
active working memory	durable session record
used during loop execution	used for storage, review, and resume
step-by-step state	full work session container
may be compacted	should remain searchable and recoverable
controls current action	preserves final record

Both are needed.

Relationship To Observability Metadata

Observability metadata explains what happened technically and operationally.

AI Work Session Persistence stores the human and workflow-facing work record.

Together they answer:

what happened
who did it
where it belongs
what was said
what actions occurred
what sources were used
what result was produced
whether it can be reviewed or resumed

Relationship To Evaluation Scorecards

Evaluation scorecards judge AI Employee quality.

Persistent sessions provide the raw material for evaluation.

A weak session can become:

an eval case
a regression case
a Kaizen note
a prompt improvement
a workflow improvement
a tool improvement

Without session persistence, MWMS loses the data needed to improve AI Employees.

Relationship To Brain Room

Brain Room should eventually treat conversations as AI work sessions when they involve meaningful work.

Brain Room sessions should preserve:

thread title
message history
task linkage
AI replies
action steps
decisions
final outputs
review state
Kaizen notes

This makes Brain Room a durable collaboration space, not just a chat interface.

Relationship To Dev Console

Dev Console sessions should preserve:

developer question
AI answer
related file or system
suggested action
final decision
whether code was changed
whether issue was resolved
Kaizen note if the problem reveals system weakness

This helps M and future developers avoid repeating troubleshooting work.

Relationship To HeadOffice Intelligence

HeadOffice Intelligence sessions should preserve:

newsletter or signal source
extracted insight
action trail
Brain routing
decision status
review status
final routed action
evidence or source notes
Kaizen note

This improves intelligence continuity.

Relationship To Future Client Systems

Future client-facing AI sessions should preserve:

client account
user request
AI response
visible steps appropriate for client
final recommendation
review state where needed
privacy controls
support handoff notes

Client-facing sessions may need stricter visibility and privacy rules.

Drift Protection

This standard prevents the following drift:

AI work disappearing after response
useful sessions becoming impossible to find
work being repeated unnecessarily
messages saved without actions
actions saved without final output
final output saved without context
sessions with no owner
sessions with no title
AI Employee steps hidden from humans
review notes detached from the session
evaluation cases being lost
Kaizen learning disappearing
Brain Room becoming disposable chat instead of operational memory

If the session matters, persist it.

Architectural Intent

The architectural intent of this standard is to make AI work durable.

MWMS is not building a collection of temporary AI chats.

MWMS is building an operating system where AI Employees perform work that can be:

resumed
searched
reviewed
audited
evaluated
improved
routed
reused

The AI Work Session is the durable container for that work.

This turns AI conversations into operational assets.

Change Log

v1.0 Initial Draft

Created the MWMS AI Work Session Persistence Standard based on absorbed insights from Matt Pocock AIhero Build DeepSearch In TypeScript.

Integrated principles from course blocks covering:

telemetry repair after workflow changes
passing full message history
backend persistence of new agent loop setup
preserving message parts and annotations
storing visible workflow steps
generating meaningful chat titles
session resumability
durable AI work records
trace linkage
action history
review status
evaluation and Kaizen reuse

Established this standard as the MWMS governance page for turning AI conversations into durable, searchable, reviewable, and reusable AI work sessions.