Memory Type Classification

for Agentic Learning System

Overview: Cognitive Memory Types in AI
Agents
AI agents benefit from implementing memory architectures inspired by human cognition. The primary memory types used
in agentic systems are:

Temporal Classification
Short-term Memory (Working Memory): Active context for current session, temporary and fast
Long-term Memory: Persistent storage across sessions for learning and adaptation

Cognitive Classification
Semantic Memory: Factual knowledge about concepts and meanings ("what")
Episodic Memory: Specific past events and experiences ("when" and "where")
Procedural Memory: Internalized rules for how to perform tasks ("how")
Working Memory: Active scratchpad for current processing
Associative Memory: Relationships and connections between concepts

Memory Type Mapping for Your System

SEMANTIC MEMORY (Facts & Knowledge)
Semantic memory stores structured factual knowledge that can be queried and retrieved. Think of it as the agent's
encyclopedia.

Tables Using Semantic Memory:

1. learner_static_profiles

Type: Pure Semantic (Long-term)

What it stores: Factual knowledge about WHO the learner is
Examples: "John Smith's email is john@[Link]", "Sarah is a beginner-level intern"
Retrieval: Direct lookup by learner_id or email
Duration: Permanent, updated when Circle profile changes
 2. learner_educational_profiles

Type: Semantic (Long-term)

What it stores: Factual knowledge about WHAT the learner is working on
Examples: "John is assigned to the E-commerce REST API project", "His mentor is Dr. Smith"
Retrieval: Direct lookup + temporal queries (current project)
Duration: Long-term, updated per internship/project change

3. project_knowledge_base (RAG System)

Type: PRIMARY SEMANTIC + Associative

What it stores: Technical knowledge, code examples, best practices, implementation guides
Examples: "How to implement JWT authentication in FastAPI", "Django ORM query optimization patterns"
Retrieval: Vector similarity search (semantic search) filtered by space_id
Duration: Permanent knowledge base
Why Semantic: This is factual technical knowledge about "what" and "how" things work in general
Associative Component: Vector embeddings create semantic links between related concepts

4. weekly_interaction_summaries

Type: Derived Semantic (Long-term)

What it stores: AGGREGATED facts extracted from episodic memories
Examples: "John completed 8/10 tasks this week", "His on-time completion rate is 75%"
Retrieval: Time-range queries, trend analysis
Duration: Permanent summaries
Why Semantic: These are factual statements derived from analyzing many episodic events

5. question_patterns (Pattern Facts)

Type: Episodic → Semantic (Hybrid)

What it stores: PATTERNS derived from repeated question events
Examples: "John has asked about authentication 5 times", "His recurring struggle topic is token management"
Retrieval: Vector similarity + aggregation
Duration: Long-term pattern tracking
Why Hybrid: Individual questions are episodic events, but the pattern ("asked 5 times") is semantic knowledge

EPISODIC MEMORY (Events & Experiences)

Episodic memory stores specific events with temporal and contextual information. Each record is a unique experience
that happened at a specific time.

Tables Using Episodic Memory:

1. learner_milestones

Type: PRIMARY EPISODIC + Derived Semantic

What it stores: Specific task completion events with timestamps
Examples:
EPISODIC: "John completed Task-123 on Nov 1st at 3:45pm, 2 days late"
DERIVED SEMANTIC: "John's average completion time is 5 days" (calculated from episodes)
Retrieval: Time-based queries, pattern analysis, aggregation
Duration: Permanent episodic records
Why Episodic: Each milestone is a specific event that occurred at a specific time

2. learner_behavior_discipline

Type: PURE EPISODIC (Long-term)

What it stores: Every individual interaction event
Examples: "At 10:32am on Nov 3rd, Sarah posted in Circle with frustrated sentiment about authentication"
Retrieval: Time-based, pattern detection over time
Duration: Permanent event log (consider partitioning old data)
Why Episodic: Each row is a timestamped experience with specific context

3. conversation_memory

Type: EPISODIC (Long-term storage) + WORKING MEMORY (when loaded)

What it stores: Chat history as sequence of message events
Examples: "At 2:15pm, learner asked 'How do I fix this auth error?', agent responded with..."
Retrieval: Session-based lookup, semantic similarity search for relevant past conversations
Duration: Long-term storage, becomes short-term when loaded into context
Why Episodic: Each conversation is a specific temporal sequence of events
Dual Nature: Stored as episodic memory, but functions as working memory when in active context window

4. question_patterns (Event Records)

Type: EPISODIC (individual questions)

What it stores: Each specific question asked
Examples: "On Nov 2nd at 9am, John asked 'Why isn't my JWT token working?'"
Retrieval: Vector similarity to find similar past questions
Why Episodic: The individual question event with timestamp and context

5. agent_tool_usage

Type: EPISODIC + Procedural Learning

What it stores: Each tool invocation event
Examples: "At 3pm, senior_bot used answertechquestion tool for John's auth question, execution took 2.3s,
learner was satisfied"
Retrieval: Aggregation for effectiveness analysis
Duration: Long-term for learning patterns
Why Episodic: Each tool use is a specific event
Procedural Link: Patterns inform future procedural decisions ("When should I use which tool?")

6. code_submissions
 Type: EPISODIC + Derived Semantic
What it stores: Each code submission event
Examples: "John submitted code for Task-123 on Nov 3rd, quality score 85, test coverage 70%"
Retrieval: Time-based, quality trend analysis
Why Episodic: Each submission is a specific event
Semantic Derivative: Overall skill level is semantic fact derived from submission history

7. meeting_participation

Type: PURE EPISODIC

What it stores: Attendance events
Examples: "John joined standup on Nov 4th at 9:05am (5 minutes late), participated actively"
Retrieval: Time-based, attendance pattern analysis
Duration: Permanent attendance records
Why Episodic: Each meeting is a specific temporal event

8. peer_collaboration

Type: EPISODIC + Associative

What it stores: Help events between learners
Examples: "On Nov 3rd, Sarah helped John debug authentication issue for 20 minutes"
Retrieval: Graph queries (who helps whom), time-based
Why Episodic: Each collaboration is a specific event
Associative Component: Creates relationship graph between learners

⚙ PROCEDURAL MEMORY (How-to Knowledge)

Procedural memory encodes HOW the agent should behave and perform tasks. Unlike the other memory types that are
stored in database tables, procedural memory is primarily encoded in code and prompts.

Implementation Locations:

1. System Prompts

Location: senior_bot.py and manager_bot.py

What it encodes: Base instructions for agent behavior
Example:
system_prompt = """
You are a Senior Technical Mentor.
When a learner asks a question:
1. First check if they've asked similar questions before
2. If asked 3+ times, offer a pair programming session
3. Always reference their current project context
4. Use code examples from the knowledge base
5. Keep tone encouraging but constructive
"""

How it evolves: Can be updated through meta-prompting based on user feedback

2. Tool Definitions

Location: @tool decorators throughout agent code

What it encodes: What actions the agent CAN take and HOW to use them
Example:

@tool
def answertechquestion(member_email: str, question: str, space_id: int):
"""
Answer technical questions by combining knowledge base and search.
PROCEDURE:
1. Identify question topic
2. Search project knowledge base for space
3. If insufficient, use Tavily search
4. Format response with code examples
5. Save interaction to memory
"""

3. Agent Workflow Logic

Location: AgentExecutor and LangGraph flows

What it encodes: Sequence of steps for complex multi-step tasks
Example: Weekly report generation workflow
def generate_weekly_report_workflow():
"""
PROCEDURE:
1. Query database for week's data
2. Calculate performance metrics
3. Identify struggle patterns
4. Generate AI narrative
5. Post to Circle
6. Notify mentor
"""

4. APScheduler Jobs

Location: Bot initialization code

What it encodes: Periodic automated procedures
Example:

scheduler.add_job(
func=generate_weekly_reports_for_all_learners,
trigger=CronTrigger(day_of_week='mon', hour=9),
id='weekly_reports'
)

5. Dynamic Instructions (Learned Procedures)

Location: Can be stored in agent_state_tracking.current_context or separate table

What it encodes: Behaviors learned from feedback
Example: After multiple users say "be more concise", update system prompt:

updated_instruction = """
Original: Provide detailed explanations.
Updated: Keep responses under 3 paragraphs unless asked for more detail.
Reason: Multiple users requested brevity.
"""

Optional: Table for Procedural Evolution

If you want to track how procedural memory evolves over time:

 CREATE TABLE agent_instruction_evolution (
id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
agent_type TEXT CHECK (agent_type IN ('senior_bot', 'manager_bot')),
instruction_version INTEGER,
system_prompt TEXT,
tool_usage_rules TEXT,
performance_metrics JSONB, -- success_rate, user_satisfaction
learned_from_interactions TEXT[], -- References to episodic events
created_at TIMESTAMP DEFAULT NOW(),
is_active BOOLEAN DEFAULT TRUE
);

This enables meta-learning where the agent can:

1. Track which instructions led to successful outcomes (using episodic memory)

2. Use LangMem prompt optimization to refine instructions
3. Store evolved procedures for future use

WORKING MEMORY (Active Context)

Working memory is the agent's "scratchpad" - what's actively being processed RIGHT NOW. It's temporary and limited in
size.

Implementation Components:

1. LLM Context Window

What it holds: Current prompt + recent conversation + retrieved context

Size limit: 8k-128k tokens depending on model
How populated:

context = {
"system_prompt": system_instructions, # Procedural
"recent_messages": load_from_conversation_memory(limit=10), # Episodic
"learner_context": get_learner_context(learner_id, days=7), # Semantic + Episodic
"knowledge_base": rag_search(query, space_id, limit=3), # Semantic
"current_state": get_agent_state(learner_id) # Working memory persistence
}

2. LangChain ConversationBufferMemory

What it holds: Recent messages in current session

Persistence: Backed by conversation_memory table
How it works: Automatically loads last N messages into context
memory = ConversationBufferMemory(
chat_memory=PostgresChatMessageHistory(
session_id=f"{learner_id}_{chatroom_uuid}",
table_name="conversation_memory"
),
memory_key="chat_history",
return_messages=True
)

3. LangGraph State Variables

What it holds: Variables during multi-step agent reasoning

Example:

class AgentState(TypedDict):
current_task: str
attempts: int
next_step: str
gathered_evidence: List[str]
confidence_score: float

4. agent_state_tracking Table

Type: Persisted Working Memory

What it stores: Snapshot of agent's current mental state with a learner
Examples: "Currently helping John with authentication, intervention level = high, recent topics = ['JWT', 'token
refresh']"
Purpose: Resume interrupted conversations, maintain cross-session awareness
Duration: Ephemeral (30-day TTL recommended)
Why Working Memory: Represents the agent's active focus, not historical events

Memory Flow Example: Complete

Interaction
Let's trace how all memory types work together when a learner asks:

"I'm still stuck on authentication"

 Step-by-Step Memory Retrieval:
STEP 1: Working Memory Activation

Load last 10 messages from conversation_memory (EPISODIC → WORKING)

Purpose: Understand immediate conversation context
Result: "Learner asked about auth 2 days ago, we discussed JWT tokens"

STEP 2: Semantic Memory - Profile Lookup

Query learner_static_profiles and learner_educational_profiles (SEMANTIC)

Result: "John Smith, beginner level, working on E-commerce REST API project"

STEP 3: Episodic Memory - Question Pattern Detection

Query question_patterns for similar questions (EPISODIC)

Result: "John asked about authentication 3 times in past week"

STEP 4: Episodic Memory - Task Status

Query learner_milestones for auth-related tasks (EPISODIC)

Result: "Task 'Implement JWT auth' is 2 days overdue, status='blocked'"

STEP 5: Semantic Memory - RAG Knowledge Retrieval

Vector search project_knowledge_base for 'JWT authentication' (SEMANTIC)

Filter by space_id for relevant project
Result: "Retrieved 3 code examples: FastAPI JWT implementation, token refresh flow, error handling"

STEP 6: Episodic Memory - Behavioral Context

Query learner_behavior_discipline for recent sentiment (EPISODIC)

Result: "Last 2 posts showed 'frustrated' sentiment"

STEP 7: Semantic Memory - Performance Summary

Query weekly_interaction_summaries (DERIVED SEMANTIC)

Result: "Top struggle topics = ['authentication', 'token management']"

STEP 8: Procedural Memory - Decision Making

Agent's system prompt includes rule (PROCEDURAL):

IF learner asks same question 3+ times:

- Offer pair programming session
- Escalate to mentor
- Provide more hands-on example

Decision: Trigger proactive intervention

 STEP 9: Working Memory Assembly

Combine all retrieved information into LLM context window (WORKING MEMORY)
Build comprehensive prompt with all context

STEP 10: Response Generation

LLM generates response using procedural knowledge and assembled context:

"John, I see you've been working on authentication for 3 days and Task-123 is blocked. You've asked
about this 3 times now, so let's tackle this together. Here's a complete JWT implementation example from
our knowledge base [shows code]. I'm also scheduling a 30-minute pair programming session with you
tomorrow at 2pm. Would that work?"

STEP 11: Episodic Memory - Write Interaction

Save conversation to conversation_memory (EPISODIC)

Update question_patterns: increment asked_count to 4 (EPISODIC)
Log tool usage to agent_tool_usage (EPISODIC)

STEP 12: Working Memory - Update State

Update agent_state_tracking (WORKING MEMORY PERSISTENCE):

{
"intervention_level": "high",
"recent_topics": ["authentication", "JWT", "pair_programming"],
"learner_mood_detected": "frustrated",
"recommended_next_actions": ["schedule_pair_programming", "check_in_tomorrow"]
}

Summary Table: Memory Type Usage

Memory Primary
Duration Storage Location Example from System
Type Purpose
Long- Store factual Learner profiles, knowledge
Semantic Database tables
term knowledge base, derived metrics
Long- Record Task completions,
Episodic Database tables
term specific events conversations, interactions
Long- Define agent System prompts, tool
Procedural Code & prompts
term behavior definitions, workflows
Short- Context window + Active Current conversation, LLM
Working
term state tracking processing context, agent state
 Memory Primary
Duration Storage Location Example from System
Type Purpose
Long- Vector embeddings Link related Semantic search, peer
Associative
term + graphs concepts relationships

Key Insights for Implementation

1. Most tables serve dual purposes:
Primary storage type (episodic events)
Derived semantic facts (aggregations and patterns)

Example: learner_milestones

Stores EPISODIC: Individual task completion events

Generates SEMANTIC: "John's on-time rate is 65%" (derived fact)

2. Conversation memory is hybrid:

Long-term episodic storage in database
Short-term working memory when loaded into context
Uses semantic search via embeddings for retrieval

3. Procedural memory is mostly code, not data:

System prompts define base behavior
Can evolve through meta-prompting (LangMem)
Consider storing evolved procedures in database for version tracking

4. Working memory is the orchestration layer:

Pulls from semantic memory (facts)
Pulls from episodic memory (relevant past events)
Applies procedural memory (rules for how to respond)
Synthesizes into coherent agent response

5. The agent should update multiple memory types per

interaction:
async def handle_learner_question(question: str, learner_id: str):
# READ from semantic memory
learner_profile = get_semantic_profile(learner_id)

# READ from episodic memory

past_questions = get_episodic_questions(learner_id, topic)

# APPLY procedural memory

response = apply_procedural_rules(question, context)

# WRITE to episodic memory

save_interaction(question, response)

# UPDATE working memory

update_agent_state(learner_id, current_context)

# UPDATE derived semantic memory (if pattern detected)

if is_recurring_pattern(past_questions):
update_question_patterns(learner_id, topic, count+1)

Recommended Next Steps

1. Implement memory type tagging: Add memory_type metadata field to track what type each record represents
2. Build retrieval strategies per type:
Semantic: Direct lookup + vector search
Episodic: Time-based + pattern detection
Procedural: Template-based instruction loading
3. Create memory orchestration function: Single function that retrieves all relevant context for an interaction
4. Set up procedural evolution pipeline: Use LangMem to evolve system prompts based on episodic feedback
5. Monitor memory balance: Ensure agent uses all memory types, not just one (e.g., don't rely only on
RAG/semantic)

References
LangChain Memory Documentation: Semantic, Episodic, Procedural classification
LangMem SDK: Prompt optimization for procedural memory evolution
CoALA Paper: Cognitive architecture for language agents
Memory Matters Paper: Long-term memory in LLM agents
MongoDB Agent Memory Guide: Comprehensive memory taxonomy