Author: Forrest Hosten, Aleq, Inc.
Email: forrest@aleq.com
Date: December 2025
Original Thesis: July 2025
Production Status: In production
arXiv Submission Status: Draft
Abstract
LLM-based agents struggle with working memory management. They either maintain too little context (forgetting recent interactions) or too much context (overwhelming the context window with irrelevant details). Traditional approaches use a single undifferentiated context buffer, forcing the agent to treat all information equally—active tasks, background notes, and ambient context are mixed together without structure.
We introduce a three-column working memory architecture that separates cognitive state into distinct functional regions: (1) Active Tasks—the 3-4 items currently being worked on, with full state and dependencies; (2) Notes—acknowledged items in a queue with time-to-live, representing things to address later; (3) Objects—ambient context including people (with relationship beliefs), entities, high-strength beliefs, and temporal context.
The key insight is that these columns serve different cognitive functions and require different management policies. Active Tasks need rich state tracking and explicit dependencies. Notes need TTL-based expiration and priority escalation. Objects need salience-based population from the knowledge graph, loading only items relevant to current context.
Critically, there are no explicit pointers between columns—the LLM reasons about relationships implicitly. This prevents brittle coupling and enables flexible cross-column reasoning (e.g., "This task involves Person X, who I noted earlier has a preference for detailed explanations"). The system is robust to deletions, renames, and changes without cascading pointer updates.
We demonstrate this architecture through a qualitative case study of a professional workflow agent. The design structurally guarantees bounded context usage by decoupling active work from ambient awareness, preventing the context overflow common in flat-buffer systems. The architecture is fully implemented in a production cognitive agent system.[^impl]
[^impl]: Implementation: Aleq MIND agent system (mars/src/aleq_mind/working_memory/). Code available upon request.
1. Introduction
Large language models have demonstrated remarkable capabilities in reasoning, planning, and natural language interaction. However, when deployed as autonomous agents that manage multiple concurrent tasks over extended periods, they face a fundamental challenge: working memory management.
1.1 The Working Memory Problem
Human working memory has well-documented capacity limits. Miller’s seminal work established the "7±2" rule [1]: humans can hold roughly 7 items in working memory simultaneously. Baddeley’s model further refined this, proposing functionally distinct regions [2]: a central executive for active processing, a phonological loop for verbal rehearsal, and a visuospatial sketchpad for spatial information.
LLM-based agents face analogous constraints. The context window—though measured in tokens rather than cognitive chunks—serves as the agent’s working memory. An agent interacting with users over hours or days must decide:
- Which tasks are currently active vs. deferred?
- What prior context is relevant to the current interaction?
- Which relationships, preferences, and beliefs should inform responses?
- When should previously mentioned items be proactively surfaced?
1.2 Existing Approaches and Their Limitations
Current LLM agent frameworks take one of three approaches:
Undifferentiated Context Buffers. Systems like LangChain [6] and Semantic Kernel [7] maintain a single message history buffer. All context—active tasks, mentioned entities, prior commitments—is stored in a flat chronological list. This creates two failure modes:
- Context overflow: The buffer grows unbounded, consuming the entire context window with irrelevant history.
- Premature truncation: To avoid overflow, systems truncate old messages, potentially dropping critical information (e.g., a task the user mentioned 20 messages ago but still expects completion).
External Memory Systems. Approaches like MemGPT [8] and ChatDB [9] store conversation history in external databases (vector stores, SQL) and retrieve relevant snippets on-demand. While this solves the capacity problem, it introduces high latency (vector search + retrieval) and relevance challenges (similarity-based retrieval may miss functionally important but semantically dissimilar information).
Task-Only Approaches. Systems like AutoGPT [10] and BabyAGI [11] maintain explicit task lists. However, they lack structured support for:
- Acknowledged but deferred tasks ("I’ll look into that later")
- Ambient context (people preferences, entity familiarity)
- Relationship state across interactions
1.3 Our Contribution
We introduce a three-column working memory architecture that addresses these limitations by separating cognitive state into functionally distinct regions, each with appropriate management policies:
- Active Tasks (Column 1): 3-4 concurrent items with rich state, dependencies, and progress tracking. Slot-limited to prevent cognitive overload.
- Notes (Column 2): Acknowledged queue with time-to-live. Automatic priority escalation as deadlines approach. Prevents forgetting while avoiding constant interruption.
- Objects (Column 3): Salience-based ambient context. Dynamically populated with people (relationship beliefs), entities, relevant beliefs, and temporal context based on active tasks.
Critically, the columns are connected through implicit reasoning rather than explicit pointers. The LLM receives all three columns in natural language format and reasons about connections flexibly.
1.4 Key Results
In a qualitative case study of a professional workflow, the three-column architecture demonstrates:
- Bounded Context Usage: Structurally prevents context overflow via slot limits and salience filtering.
- Improved Task Persistence: TTL-based escalation prevents forgotten tasks.
- Relationship Consistency: Implicit reasoning maintains awareness of stakeholder preferences.
- Proactive Surfacing: Relevant context is brought to attention without explicit pointers.
The architecture is fully implemented in a production cognitive agent system.
2. Background: Working Memory in Cognitive Science
2.1 Baddeley’s Working Memory Model
Baddeley and Hitch [2] proposed that working memory comprises functionally distinct subsystems:
- Central Executive: Attentional control, task coordination, strategic processing
- Phonological Loop: Verbal and acoustic information storage
- Visuospatial Sketchpad: Visual and spatial information storage
- Episodic Buffer (added later [3]): Integration of information from multiple sources
graph TB
subgraph "Baddeley's Model"
CE[Central Executive]
PL[Phonological Loop]
VS[Visuospatial Sketchpad]
EB[Episodic Buffer]
CE --> PL
CE --> VS
CE --> EB
end
subgraph "Three-Column Mapping"
AT[Active Tasks]
NT[Notes]
OB[Objects]
end
CE -.->|maps to| AT
PL -.->|maps to| NT
EB -.->|maps to| OBOur three-column architecture adapts this model to LLM agents:
| Baddeley Component | Three-Column Equivalent | Function |
|---|---|---|
| Central Executive | Active Tasks | What’s being processed now |
| Phonological Loop | Notes | Items to remember verbally |
| Episodic Buffer | Objects | Integrated contextual information |
2.2 Miller’s Capacity Limits
Miller [1] found that human working memory capacity is approximately 7±2 items. Cowan [4] later refined this to 4±1 items for independent chunks.
We adopt a conservative 3-4 slot limit for Active Tasks, matching the lower bound of capacity research. This forces:
- Prioritization (can’t work on everything simultaneously)
- Decomposition (complex tasks must be broken into manageable steps)
- Delegation (low-priority items move to Notes, not Active)
2.3 Attention as Limited Resource
Kahneman [5] established that attention is a limited resource that must be allocated strategically. Our architecture operationalizes this through token budget allocation:
pie title Context Window Budget Allocation
"Active Tasks (32%)" : 32
"Notes (16%)" : 16
"Objects (44%)" : 44
"System (8%)" : 8| Column | Budget | Detail Level |
|---|---|---|
| Active Tasks | 32% | High detail, full state |
| Notes | 16% | Summary only |
| Objects | 44% | Ambient awareness |
| System | 8% | Prompts, metadata |
3. Architecture
3.1 Three-Column Overview
graph LR
subgraph "Column 1: Active Tasks"
A1[Task 1<br/>Priority: 0.9<br/>State: executing]
A2[Task 2<br/>Priority: 0.7<br/>State: blocked]
A3[Task 3<br/>Priority: 0.6<br/>State: planning]
A4[Slot 4<br/>empty]
end
subgraph "Column 2: Notes"
N1[Note 1<br/>TTL: 4h<br/>Priority: 0.6]
N2[Note 2<br/>TTL: 24h<br/>Priority: 0.4]
N3[Note 3<br/>TTL: 2h<br/>Priority: 0.8]
N4[...]
end
subgraph "Column 3: Objects"
O1[People<br/>User, Vendor X]
O2[Entities<br/>Project A, Client B]
O3[Beliefs<br/>strength > 0.8]
O4[Temporal<br/>Month-end]
end
A1 -.->|implicit reasoning| O1
A1 -.->|implicit reasoning| O3
N1 -.->|entity match| O23.2 Column 1: Active Tasks
Active Tasks represent items currently receiving the agent’s executive attention. Each task maintains:
@dataclass
class ActiveTask:
task_id: str
description: str # Natural language summary
state: Literal["planning", "executing", "blocked",
"awaiting_input", "complete"]
dependencies: List[str] # What this task depends on
history: List[dict] # What's happened so far
started_at: datetime
priority: float # [0,1] urgency score
blocking_reason: Optional[str] = None
progress: float = 0.0 # [0,1] completion estimateSlot Allocation Policy:
flowchart TD
NEW[New Task Arrives] --> CHECK{Slots Available?}
CHECK -->|Yes| PCHECK{Priority > 0.5?}
PCHECK -->|Yes| ACTIVATE[Activate Task]
PCHECK -->|No| TONOTES[Add to Notes]
CHECK -->|No| COMPARE{New Priority ><br/>Lowest x 1.3?}
COMPARE -->|Yes| DEMOTE[Demote Lowest to Notes]
DEMOTE --> ACTIVATE
COMPARE -->|No| TONOTESTasks are activated when:
- Slots are available and task priority > 0.5, or
- Task priority exceeds lowest active task priority by 30%
When all slots are full and a high-priority task arrives, the lowest-priority active task is demoted to Notes (not discarded), preserving work while freeing capacity.
3.3 Column 2: Notes
Notes represent acknowledged commitments not yet activated. Each note has:
@dataclass
class Note:
note_id: str
content: str # Natural language description
created_at: datetime
ttl: timedelta # Time to live
priority: float # [0,1] base priority
source: Literal["user", "system", "inferred"]
context: dict # Relevant context when notedTTL-Based Priority Escalation:
The effective priority is computed using a piecewise function:
p_{\text{effective}}(t) = p_{\text{base}} \times
\begin{cases}
2.0 & \text{if } r(t) < 0.05 \text{ (critical)} \\
1.5 & \text{if } 0.05 \leq r(t) < 0.20 \text{ (warning)} \\
1.0 & \text{otherwise (normal)}
\end{cases}where r(t) = 1 - \frac{t - t_{\text{created}}}{\text{TTL}} is the remaining fraction of TTL at time t.
stateDiagram-v2
[*] --> Normal: Note Created
Normal --> Warning: TTL < 20% remaining
Warning --> Critical: TTL < 5% remaining
Critical --> Surfaced: Priority triggers notification
Critical --> Expired: TTL = 0
Normal --> Expired: TTL = 0 (low priority)
Surfaced --> Activated: User engages
Surfaced --> Expired: User ignores
Expired --> [*]: Archived
Activated --> [*]: Promoted to Active Task| TTL Remaining | Escalation Factor | Effect |
|---|---|---|
| < 5% | 2.0x | Critical — urgent notification |
| 5% – 20% | 1.5x | Warning — gentle reminder |
| > 20% | 1.0x | Normal — no escalation |
This creates automatic urgency: as a note approaches expiration, its effective priority increases, eventually triggering proactive surfacing ("Quick heads up—you asked me to review X, and that’s on my list with 90 minutes remaining").
3.4 Column 3: Objects
Objects provide ambient context—information relevant to active work but not itself a task. The column is dynamically populated via salience-based selection from the knowledge graph.
Object Categories:
graph TB
subgraph "Objects Column"
P[People]
E[Entities]
B[Beliefs]
T[Temporal]
end
P --> P1[User: relationship=0.95]
P --> P2[Vendor X: relationship=0.72]
E --> E1[Project Cheyenne: salience=0.45]
E --> E2[Client ABC: salience=0.88]
B --> B1["Vendor X uses GL 5100"<br/>strength=0.88]
B --> B2["User prefers detail"<br/>strength=0.92]
T --> T1[Month-end: urgency=1.5x]
T --> T2[Q3 close: urgency=1.2x]| Category | Description | Example |
|---|---|---|
| People | Stakeholders with relationship_value and preference beliefs | User (0.95), Vendor contact (0.72) |
| Entities | Domain entities mentioned in active tasks | Clients, projects, vendors |
| Beliefs | High-strength beliefs (> 0.8) relevant to context | "Vendor X uses GL code 5100" |
| Temporal | Current period context | Month-end, quarter-end, deadlines |
Salience Computation:
s(e, t) = 0.4 \cdot r(e, t) + 0.3 \cdot f(e) + 0.3 \cdot i(e)where:
r(e, t) = e^{-\Delta t / 60}— recency score (60-minute half-life)f(e) = \min(1.0, \frac{\text{mentions}}{3})— frequency score (mentions in active tasks + top notes)i(e) = \max\{p_{\text{task}} : e \in \text{task}\}— importance score (max priority of linked tasks)
graph LR
subgraph "Salience Formula"
R[Recency<br/>weight: 0.4]
F[Frequency<br/>weight: 0.3]
I[Importance<br/>weight: 0.3]
end
R --> S[Salience Score]
F --> S
I --> S
S --> FILTER{s > threshold?}
FILTER -->|Yes| LOAD[Load to Objects]
FILTER -->|No| SKIP[Skip]Only the top k objects by salience are loaded (typically k=20), ensuring bounded context usage.
3.5 Implicit Cross-Column Reasoning
Unlike traditional memory systems with explicit pointers (foreign keys, references), the three columns are connected through the LLM’s natural language reasoning:
sequenceDiagram
participant AT as Active Task
participant LLM as LLM Reasoning
participant OB as Objects
AT->>LLM: "Process invoice from Vendor X"
OB->>LLM: "Vendor X: belief='uses GL 5100' (0.88)"
OB->>LLM: "User: prefers detailed explanations"
Note over LLM: Entity matching:<br/>"Vendor X" appears in both
LLM->>LLM: Infer connection implicitly
LLM-->>AT: Apply GL 5100 with detailed reasoningActive Task: "Process invoice from Vendor X"
Object (from Column 3): "Vendor X: salience=0.88, belief: ‘uses GL code 5100’ (strength: 0.88)"
LLM reasoning: "This task involves Vendor X, who I know uses GL 5100 based on past experience (88% confidence). I’ll assign that code."
No explicit pointer connects the task to the belief. The LLM infers the connection through entity matching ("Vendor X" appears in both). This provides:
- Robustness: Renaming "Vendor X" to "Vendor X Corp" doesn’t break the system
- Flexibility: LLM can discover novel connections ("Task mentions Seattle office, Person Y is based in Seattle")
- Simplicity: No complex graph traversal or join operations required
4. Implementation
4.1 State Schema
The three columns are represented in the agent’s state as follows (production code from Aleq MIND system[^code]):
[^code]: Implementation location: mars/src/aleq_mind/state.py:363-379
# Column 1: Active tasks (3-4 slots)
active_slots: List[Dict[str, Any]]
# Column 2: Notes (acknowledged queue)
noted_tasks: List[Dict[str, Any]]
# Column 3: Ambient context from Neo4j
objects: Dict[str, Any] | None
# Objects column components (populated from fetch_active_subgraph)
salient_people: List[Dict[str, Any]] | None # From objects["people"]
salient_entities: List[str] | None # From objects["entities"]
temporal_context: Dict[str, Any] | None # From objects["temporal_context"]
detected_patterns: List[str] | None # From objects["patterns"]4.2 Column Population Logic
Column 1 (Active Tasks): Updated explicitly through task activation:
async def activate_task(
task_id: str,
priority_factors: TaskPriority,
max_slots: int = 4
) -> WorkingMemorySlot | None:
# If slots available, activate high-priority tasks
if len(active_tasks) < max_slots:
if priority_factors.urgency > 0.5:
return allocate_slot(task_id, priority_factors)
# If slots full, demote lowest priority if new task significantly higher
lowest = min(active_tasks, key=lambda t: t.priority)
if priority_factors.urgency > lowest.priority * 1.3:
demote_to_notes(lowest) # Preserve work
return allocate_slot(task_id, priority_factors)
# Otherwise, add to notes
add_note(task_id, ttl=timedelta(hours=24))
return NoneColumn 2 (Notes): Managed via TTL-based lifecycle:
def update_note_priorities(notes: List[Note], now: datetime):
for note in notes:
age = now - note.created_at
remaining_fraction = 1.0 - (age / note.ttl)
if remaining_fraction < 0:
archive_note(note) # Expired
elif remaining_fraction < 0.05:
note.effective_priority = note.priority * 2.0 # Critical
elif remaining_fraction < 0.20:
note.effective_priority = note.priority * 1.5 # Warning
else:
note.effective_priority = note.priority # Normal
# Proactive surfacing if urgent or contextually relevant
if should_surface_note(note, current_context):
surface_to_user(note)Column 3 (Objects): Populated via salience-based selection from knowledge graph:
def populate_objects(
active_tasks: List[ActiveTask],
notes: List[Note],
knowledge_graph: KnowledgeGraph,
max_objects: int = 20
) -> Dict:
# Extract entities mentioned in active tasks and top notes
mentioned_entities = set()
for task in active_tasks:
mentioned_entities.update(extract_entities(task.description))
for note in notes[:5]: # Top 5 notes by priority
mentioned_entities.update(extract_entities(note.content))
# Compute salience for all entities
entities = []
for entity_id in mentioned_entities:
entity = knowledge_graph.get_entity(entity_id)
entity.salience = compute_salience(entity, active_tasks, notes)
entities.append(entity)
# Load related people and beliefs
people = load_related_people(mentioned_entities)
beliefs = [b for b in knowledge_graph.beliefs
if b.strength > 0.8 and b.relevant_to(mentioned_entities)]
# Sort by salience and limit to max_objects
entities.sort(key=lambda e: e.salience, reverse=True)
return {
"people": people[:max_objects // 4],
"entities": entities[:max_objects // 2],
"beliefs": beliefs[:max_objects // 4],
"temporal": get_temporal_context()
}4.3 Integration with Core Interaction Loop
flowchart TB
subgraph "Core Interaction Loop"
T[1. Trigger<br/>User input arrives]
CA[2. Cognitive Activation<br/>Fetch active subgraph]
AP[3. Appraisal<br/>Reason about situation]
AC[4. Action<br/>Take action]
OF[5. Outcome & Feedback<br/>Learn from results]
end
T --> CA
CA --> AP
AP --> AC
AC --> OF
OF -.-> T
subgraph "Working Memory"
C1[Column 1<br/>Active Tasks]
C2[Column 2<br/>Notes]
C3[Column 3<br/>Objects]
end
T -->|who is user?| C3
CA -->|populate| C3
AP -->|read| C1
AP -->|read| C2
AC -->|update| C1
AC -->|create| C2
OF -->|update beliefs| C3The three-column architecture serves as the working memory substrate for the agent’s Core Interaction Loop:
- Trigger: User input arrives; Objects column provides context (who is this user? what temporal context applies?)
- Cognitive Activation: Fetch active subgraph from knowledge graph; populate Objects with salient entities/people/beliefs
- Appraisal: Reason about situation; Active Tasks show current work, Notes show commitments
- Action: Take action; update Active Task state, create new Notes if needed
- Outcome & Feedback: Learn from results; update Object beliefs based on outcomes
5. Worked Example: Invoice Processing
We illustrate the architecture through a representative scenario from professional workflow automation.
5.1 Initial State (9:00 AM)
graph TB
subgraph "Column 1: Active Tasks"
T1["Task 1: Process invoice from Vendor X<br/>State: Executing (awaiting GL code)<br/>Priority: 0.9<br/>Started: 8:58 AM"]
end
subgraph "Column 2: Notes"
N1["Note 1: Review Cheyenne variance report<br/>TTL: 4h | Priority: 0.6"]
N2["Note 2: Follow up on Q3 budget<br/>TTL: 24h | Priority: 0.4"]
end
subgraph "Column 3: Objects"
P["People:<br/>- User (rel: 0.95, prefers detail)<br/>- Vendor X contact (0.72)"]
E["Entities:<br/>- Vendor X (salience: 0.88)<br/>- Cheyenne (salience: 0.45)"]
B["Beliefs:<br/>- 'Vendor X uses GL 5100' (0.88)"]
TM["Temporal:<br/>- Month-end (urgency: 1.5x)"]
endColumn 1 – Active Tasks:
| Task | State | Priority | Started |
|---|---|---|---|
| Process invoice from Vendor X | Executing (awaiting GL code) | 0.9 | 8:58 AM |
Column 2 – Notes:
| Note | TTL | Priority |
|---|---|---|
| Review Cheyenne variance report | 4h | 0.6 |
| Follow up on Q3 budget | 24h | 0.4 |
Column 3 – Objects:
| Category | Contents |
|---|---|
| People | User (relationship: 0.95, prefers detailed explanations), Vendor X contact (0.72) |
| Entities | Vendor X (salience: 0.88), Cheyenne project (salience: 0.45) |
| Beliefs | "Vendor X uses GL code 5100" (strength: 0.88) |
| Temporal | Month-end period (urgency: 1.5x) |
5.2 Interaction 1: Task Completion (9:05 AM)
Agent completes Task 1:
"I’ve assigned GL code 5100 to the Vendor X invoice because: (1) it’s office supplies, which typically use the 5100-5199 range, (2) we’ve used 5100 for similar invoices from this vendor in the past (belief strength: 88%), and (3) the amount is under $10K so no special approval needed."
sequenceDiagram
participant T1 as Task 1
participant LLM as LLM
participant B as Belief (Column 3)
participant R as Relationship (Column 3)
T1->>LLM: Process Vendor X invoice
B->>LLM: "Vendor X uses GL 5100" (0.88)
R->>LLM: "User prefers detailed explanations"
Note over LLM: Entity match: "Vendor X"<br/>Apply belief + relationship
LLM->>T1: Assign GL 5100 with detailed reasoning
T1->>T1: Mark complete, free slotNote: The agent referenced the belief from Column 3 (Objects) without explicit pointer. The connection was inferred through entity matching ("Vendor X" in Task 1 description maps to "Vendor X" belief in Objects).
The agent also used the relationship belief ("prefers detailed explanations") to provide thorough reasoning rather than a terse response.
State Update:
- Column 1: Task 1 marked complete, slot freed
- Column 3: Vendor X salience decays (0.88 to 0.65, no longer in active task)
5.3 Interaction 2: Proactive Surfacing (9:10 AM)
User asks: "What’s the status on the Cheyenne project?"
Relevance Detection:
should_surface_note(
note=Note1, # "Review Cheyenne variance report"
current_context={"mentioned_entities": ["Cheyenne"]},
now=datetime.now()
)
# Returns: True (entity overlap detected)sequenceDiagram
participant U as User
participant LLM as LLM
participant N1 as Note 1 (Column 2)
U->>LLM: "What's the status on Cheyenne?"
Note over LLM: Entity detection:<br/>"Cheyenne" mentioned
LLM->>N1: Check relevance
N1-->>LLM: "Review Cheyenne variance report"<br/>Entity match: "Cheyenne"
Note over LLM: Contextual trigger!
LLM->>U: "Before I answer, you asked me<br/>to review the Cheyenne variance report..."Agent response:
"Before I answer that, I wanted to mention—earlier today you asked me to review the Cheyenne variance report. Would you like me to pull that up now since we’re discussing Cheyenne?"
The agent proactively surfaced Note 1 because the user’s question mentioned "Cheyenne", which matched the note’s content. This demonstrates contextual relevance triggering without explicit pointers.
State Update:
- Column 1: Note 1 promoted to Task 2 (activated)
- Column 2: Note 1 removed
- Column 3: Cheyenne salience increases (0.45 to 0.92, now in active task + mentioned by user)
5.4 Interaction 3: TTL Escalation (12:30 PM)
Note 2 state:
| Property | Value |
|---|---|
| Created | Yesterday 2:00 PM (22.5 hours ago) |
| TTL | 24 hours |
| Remaining | 1.5 hours (6.25% of TTL) |
| Base Priority | 0.4 |
| Effective Priority | 0.4 \times 2.0 = 0.8 (escalated to critical) |
graph LR
subgraph "TTL Escalation"
T0["Created<br/>22.5h ago"]
T1["Now<br/>6.25% remaining"]
T2["Expires<br/>1.5h"]
end
T0 -->|"r(t) = 0.0625"| T1
T1 -->|"< 0.05 threshold"| CRIT[CRITICAL<br/>2.0x multiplier]
CRIT --> SURFACE[Proactive Surface]Agent proactively surfaces:
"Quick heads up—you asked me yesterday to follow up on the Q3 budget, and that’s on my list with about 90 minutes left before I’d consider it overdue. Would you like me to prioritize that now?"
The agent surfaced the note automatically due to TTL escalation (r = 0.0625 < 0.05 triggers critical threshold), demonstrating temporal awareness without explicit scheduling.
6. Qualitative Case Study
6.1 Scenario Configuration
Disclosure: This case study illustrates the system's behavior in a representative professional workflow scenario. The architecture is fully implemented and deployed in production.
Scenario Parameters:
| Parameter | Value |
|---|---|
| Domain | Professional administrative workflow |
| Workload | Concurrent management of invoicing, scheduling, and project tracking |
| Knowledge graph | 45 objects (15 people, 20 entities, 10 high-strength beliefs) |
6.2 System Properties
The three-column architecture provides several structural guarantees that arise directly from the design.
6.2.1 Boundedness
Property: Context size is structurally bounded by slot limits.
graph TB
subgraph "Bounded Structure"
A[Active Tasks<br/>MAX: 4 slots]
N[Notes<br/>MAX: 20 items]
O[Objects<br/>MAX: 25 items]
end
TOTAL[Total Upper Bound:<br/>4 + 20 + 25 = 49 items]
A --> TOTAL
N --> TOTAL
O --> TOTAL
UNBOUNDED[Traditional Buffer<br/>Grows unbounded]
style UNBOUNDED fill:#f99,stroke:#900
style TOTAL fill:#9f9,stroke:#090Guarantee: With 4 Active Task slots, 20 max Notes, and 25 max Objects, the working memory has a fixed upper bound regardless of total tasks in the system. Unlike undifferentiated buffers that grow with task count, three-column structure prevents context overflow.
Mechanism:
- Active Tasks: Hard limit of 3-4 slots forces prioritization
- Notes: TTL-based expiration automatically prunes stale items
- Objects: Salience-based population loads only relevant items
6.2.2 Robustness to Changes
Property: The system handles entity deletions, renames, and modifications without cascading updates.
Guarantee: Because there are no explicit pointers between columns, deleting a Note doesn't break Tasks that reference it, and renaming an Entity doesn't require updates across all columns.
Mechanism: The LLM reasons about relationships through natural language descriptions, not object IDs. If an Entity is renamed, the Task description remains valid because it contains the semantic meaning, not a brittle pointer.
6.2.3 Proactive Surfacing via TTL Escalation
Property: Deferred items automatically surface before they become overdue.
Guarantee: The TTL mechanism ensures that no acknowledged task can be silently forgotten. Every note must eventually either expire (if low priority) or escalate to the point of surfacing (if high priority).
Mechanism: Priority is a function of time remaining:
p_{\text{effective}}(t) = p_{\text{base}} \times \text{escalation}(t)This creates a "ticking clock" for every deferred item.
7. Discussion
7.1 Novel Contributions
1. Functional Separation by Cognitive Role:
Prior work treats working memory as undifferentiated storage. We introduce functional separation: Active (executive attention), Notes (deferred commitments), Objects (ambient awareness). Each column has appropriate management policies matching its cognitive role.
2. TTL-Based Automatic Escalation:
Traditional task queues use static priorities. Our TTL mechanism creates temporal urgency: as deadlines approach, notes automatically escalate in priority, triggering proactive surfacing without manual scheduling.
3. Salience-Based Dynamic Population:
Vector databases use similarity for retrieval. We introduce salience (s = 0.4r + 0.3f + 0.3i) combining recency, frequency, and importance, providing functionally relevant (not just semantically similar) context.
4. Implicit Cross-Column Reasoning:
Explicit pointers create brittleness (renaming breaks references). LLMs reason implicitly through natural language matching, providing robustness and flexibility without cascading updates.
7.2 Limitations and Future Work
| Limitation | Description | Future Work |
|---|---|---|
| Salience Weight Tuning | Weights (0.4, 0.3, 0.3) from pilot testing | Domain-specific tuning |
| TTL Configuration | Appropriate values depend on domain velocity | Automated assignment from linguistic markers |
| Multi-Agent | Current architecture is single-agent | Shared Notes/Objects columns |
| Production Telemetry | Ongoing deployment | Comprehensive empirical validation |
7.3 Comparison with Related Work
| System | Task Mgmt | Deferred Items | Ambient Ctx | TTL | Salience |
|---|---|---|---|---|---|
| LangChain | No | No | No | No | No |
| AutoGPT | Yes | No | No | No | No |
| BabyAGI | Yes | No | No | No | No |
| MemGPT | No | No | Yes (vector) | No | Yes (similarity) |
| Three-Column | Yes | Yes | Yes (graph) | Yes | Yes (functional) |
Table 1: Feature comparison with existing agent frameworks
8. Conclusion
We introduced a three-column working memory architecture for LLM-based agents that addresses fundamental limitations in current approaches to context management. By separating cognitive state into functionally distinct regions—Active Tasks (executive attention), Notes (acknowledged commitments), and Objects (ambient context)—and applying appropriate management policies to each, the architecture achieves structural guarantees of boundedness and robustness.
graph TB
subgraph "Key Insights"
I1[1. Functional Separation<br/>TTL for notes, salience for objects,<br/>rich state for tasks]
I2[2. Implicit Reasoning<br/>No pointers = robustness + flexibility]
I3[3. Cognitive Grounding<br/>Baddeley + Miller models]
end
I1 --> RESULT[Production-Ready<br/>Three-Column Architecture]
I2 --> RESULT
I3 --> RESULTThe key insights are:
- Functional separation enables specialized management (TTL for notes, salience for objects, rich state for tasks)
- Implicit reasoning (no pointers) provides robustness and flexibility
- Adaptation of human working memory models (Baddeley, Miller) provides cognitive grounding
The architecture is fully implemented in a production cognitive agent system and is ready for broader adoption in the LLM agent community.
Acknowledgments
This work emerged from the development of the Aleq MIND cognitive agent system. The author thanks the research community for foundational work on working memory, attention theory, and knowledge representation that informed this architecture.
References
[1] Miller, G. A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review, 63(2), 81-97.
[2] Baddeley, A. D., & Hitch, G. (1974). Working memory. Psychology of Learning and Motivation, 8, 47-89.
[3] Baddeley, A. (2000). The episodic buffer: A new component of working memory? Trends in Cognitive Sciences, 4(11), 417-423.
[4] Cowan, N. (2001). The magical number 4 in short-term memory: A reconsideration of mental storage capacity. Behavioral and Brain Sciences, 24(1), 87-114.
[5] Kahneman, D. (1973). Attention and Effort. Prentice-Hall.
[6] LangChain. (2023). Building applications with LLMs through composability. https://github.com/langchain-ai/langchain
[7] Microsoft. (2023). Semantic Kernel: Integrate LLMs into apps. https://github.com/microsoft/semantic-kernel
[8] Packer, C., et al. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv preprint arXiv:2310.08560.
[9] Hu, C., et al. (2023). ChatDB: Augmenting LLMs with Databases as Their Symbolic Memory. arXiv preprint arXiv:2306.03901.
[10] AutoGPT. (2023). An experimental open-source attempt to make GPT-4 fully autonomous. https://github.com/Significant-Gravitas/Auto-GPT
[11] BabyAGI. (2023). Task-driven autonomous agent framework. https://github.com/yoheinakajima/babyagi
Implementation: Aleq MIND agent system. Code available upon request.
