Abstract
Agentic AI systems increasingly depend on persistent memory to deliver coherent, personalized and auditable behavior over time. A common implementation pattern uses a small number of low level memory blocks, such as static key value storage, fact extraction modules and vector databases. While simple, this block oriented view couples agents to storage details, makes governance difficult and does not align well with advanced cognitive frameworks such as GSCP-15 (Gödel's Scaffolded Cognitive Prompting, 15 phase variant). This article proposes a layered, controller based memory architecture explicitly aligned with GSCP-15. It decomposes memory into functional layers (identity and policy, profile and preferences, episodic interaction, semantic knowledge, vector index, task workspace and working memory), introduces a MemoryController as the primary interface for agents, and describes a promotion and governance pipeline for transforming transient conversational traces into stable, governed knowledge. The result is a system in which GSCP-15 stages can operate over a coherent and auditable memory substrate, rather than a loose collection of ad hoc blocks.
Introduction
Modern agent frameworks seek to move from single shot model calls to long lived, tool using agents that cooperate over extended time horizons. In such systems, memory is not a convenience feature, but a primary determinant of capability: without robust memory, agents cannot personalize, cannot reason over past actions, and cannot be governed in a traceable way.
A typical early design introduces three basic memory blocks. First, a static memory component stores fixed key value pairs such as "user's name is Sam". Second, a fact extraction component uses an LLM to pull structured facts from conversation history ("user is vegetarian", "user likes potatoes"). Third, a vector memory component stores conversation chunks as embeddings in a similarity search index such as Weaviate for semantic retrieval.
This pattern works for prototypes, yet it exposes several limitations. It conflates fundamentally different concerns (identity, preference, episodic events, world knowledge, and retrieval indices). It forces agents to be aware of storage primitives. It provides weak support for promotion, decay and conflict resolution. Most importantly, it does not align naturally with multi phase reasoning frameworks such as GSCP-15, where planning, retrieval, tool routing and governance need structured, queryable state.
The goal of this article is to outline a more principled memory architecture for GSCP-15 style agents. The design is based on a few core ideas: distinguish types of memory by their function, not their storage technology; centralize access through a MemoryController; treat vector stores as indices pointing to canonical records; and embed promotion, validation and retention policies into the memory layer itself.
Background
Limitations of block oriented memory
In the three block design, each component is defined primarily by its storage form.
StaticMemoryBlock: simple key value store for configuration like identity and rules.
FactExtractionMemoryBlock: pipeline that writes extracted facts into some internal list or table.
VectorMemoryBlock: embedding store for free form conversation chunks.
This has several drawbacks:
Agents must understand which block to query for which purpose, embedding storage semantics into agent prompts and code.
There is no clear separation between short lived episodic history and longer lived profile level facts.
Governance is difficult because the same fact may exist in multiple places, and there is no canonical record that can be audited or updated centrally.
Vector storage is treated as a primary memory source rather than an index into structured data.
Promotion from raw conversational traces into stable knowledge lacks a clear process, leading either to over retention or to loss of important contextual information.
As agents become more capable, these limitations create fragility, inconsistent behavior and compliance risks.
Overview of GSCP-15
GSCP-15 can be viewed as a structured, multi phase framework for LLM centric reasoning and action. While implementations differ, the framework typically includes phases such as:
Problem framing and intent classification.
Retrieval planning and evidence gathering.
Decomposition into subgoals and tasks.
Tool selection and tool calling.
Intermediate result consolidation and conflict resolution.
Policy and safety checks with uncertainty thresholds.
Final answer synthesis and optional external validation.
GSCP-15 sees the model as one component in a governed pipeline that includes retrieval systems, tool executors, policy engines and audit logs. For this to work in practice, the memory system must support:
Access to different kinds of state for different phases (profile, episodic, domain knowledge, task state).
Explicit recording of events and decisions for later replay and analysis.
Mechanisms to promote some information into long term memory while allowing other information to decay.
Clear interfaces so that planners and schedulers can request "context for this request" without understanding storage details.
Layered memory architecture
The proposed design organizes memory into functional layers, each with a clear purpose. These layers can be implemented using any appropriate storage technology, but agents and GSCP-15 orchestrators interact with them through a common MemoryController.
Identity and policy memory
This layer captures relatively static information that defines who the agent is and what constraints it must respect.
Examples include:
Agent role description and capabilities.
User or tenant identity that must always be available (name, organization, locale, time zone).
Non negotiable policies and guardrails, such as forbidden domains, regulatory constraints and access scopes.
This memory is typically versioned, with changes managed through configuration or administrative workflows. It is read on almost every request but written infrequently.
Profile and preference memory
Profile memory stores stable, high signal attributes about a user, workspace or tenant. Examples:
Dietary preferences such as "vegetarian".
Modality preferences such as "prefers C# examples" or "default model is gpt-5 via Azure".
Communication style preferences, such as "concise responses" or "avoid emojis".
Unlike identity and policy, profile data emerges over time and may be modified by the system itself. It should be strongly structured, for instance via a UserProfile schema, so that facts can be validated, deduplicated and overridden.
Fact extraction components write into this layer only after passing through a promotion pipeline, described later.
Episodic interaction memory
Episodic memory records the sequence of events that occurred during interactions.
Typical records might contain:
Timestamp, user and agent identifiers.
Request text, key intermediate prompts, tool calls and responses.
Decisions made by the planner or orchestrator.
Outcomes such as success or error codes.
This layer is append only by design. It forms the basis for later summarization, offline evaluation and audit. Retention policies may be applied to raw events, with summaries retained longer than detailed traces.
Semantic knowledge memory
Semantic knowledge represents facts and relationships that hold beyond individual sessions. It is distinct from user profile; it covers domain knowledge and world facts that are relevant for the agent's scope.
Examples include:
Domain model concepts and their relationships, such as "vegetarian avoids meatProducts".
Organizational structures, such as "Team X owns System Y".
Procedural knowledge, such as "incident severity determines escalation timeline".
This layer is often implemented as a document store plus, optionally, a graph database. Fact promotion pipelines write into this store, which then becomes a source of truth for retrieval and reasoning.
Vector index memory
Vector memory indexes various artefacts in embedding space, but is not considered a primary store. It typically embeds:
Episodic events or their summaries.
Knowledge articles or graph nodes.
Project documentation and task artefacts.
Each embedding record carries metadata including type, source identifier, timestamps and tags. When a GSCP-15 phase requests semantic retrieval, it queries the vector index, then resolves the returned identifiers into canonical records from the episodic or knowledge layers. This pattern preserves a single source of truth and supports updates and deletions without uncontrolled duplication.
Task and workspace memory
Many GSCP-15 workflows operate within the scope of a task, ticket or project. Task memory captures state specific to that scope, such as:
Requirements and acceptance criteria.
Intermediate designs, plans and code artefacts.
Open questions, decisions and unresolved risks.
In a multi agent system, task memory often appears as a shared workspace or blackboard used by multiple agents. At the end of a task, selected elements of task memory may be promoted into long term knowledge or profile memory if they are reusable.
Working memory and scratchpad
Working memory is short lived state used during a single reasoning step or small sequence of steps. Examples include temporary calculations, candidate solution options and internal reasoning notes. It may be captured in prompts or ephemeral storage, but it is not treated as persistent memory. For governance and debugging, some working memory may be logged as part of episodic events, subject to policy.
MemoryController interface
To decouple agents from storage, a MemoryController mediates all memory interactions. It exposes a small set of high level operations that align with GSCP-15 phases.
Representative methods include:
GetContextForRequest(userId, taskId, querySpec)
Returns structured context objects: identity and policy, profile, relevant episodic events, relevant knowledge items and task artefacts. Semantic retrieval is handled inside this method using the vector index and metadata filters, but the caller receives resolved records and optionally synthesized summaries.
RecordEvent(event)
Appends an interaction event, including prompts, tool calls and outcomes, to the episodic store. This method may also enqueue the event for later summarization and fact extraction.
UpsertProfileFact(userId, fact)
Validates and merges a new or updated fact into the profile store. Conflicts and sensitive updates can trigger user confirmation flows or administrator review.
PromoteTaskArtifacts(taskId, selectionPolicy)
At task completion, evaluates which artefacts or derived facts should be promoted into long term memory, guided by a selection policy. For example, stable preferences discovered across multiple tasks might become profile entries.
Agents and GSCP-15 orchestrators rely on these operations instead of accessing specific blocks, which simplifies prompt design and reduces coupling.
Fact extraction and promotion pipeline
The traditional FactExtractionMemoryBlock is best recast as a multi stage pipeline that transforms conversational traces into stable knowledge under governance.
A typical pipeline includes:
Candidate extraction. An LLM processes an interaction segment and produces candidate facts with structure such as subject, predicate, object, evidence references and confidence scores.
Normalization and schema enforcement. Candidates are mapped onto known schemas, constrained by types and enumerations. For instance, diet attributes are normalized into allowed values like vegetarian, vegan or omnivore.
Conflict analysis. New candidates are compared with existing facts. Conflicts are detected, and resolution strategies are applied, which may include keeping both with timestamps, selecting the most recent or highest confidence, or marking the fact as disputed.
Sensitivity and importance scoring. Some facts may be too sensitive to store without explicit consent, or may require anonymization. Other facts are low impact and may be discarded after serving their immediate purpose.
Promotion decision. Only candidates that pass validation and meet importance thresholds are promoted into profile or knowledge layers. Others remain in episodic memory or are used only within the current task.
This pipeline can itself be implemented as a GSCP-15 governed process, with phases to gather evidence, apply policies and generate explanations for promotions.
Alignment with GSCP-15 phases
The layered memory architecture supports each GSCP-15 phase with appropriate state.
During problem framing, the orchestrator asks the MemoryController for identity, policy and profile information to understand constraints and preferences.
During retrieval planning, it uses the semantic index and knowledge memory via GetContextForRequest, optionally re-ranking based on task specific criteria.
During decomposition, previous task artefacts and episodic events can inform decomposition patterns or reuse of historical solutions.
During tool selection and execution, task memory holds intermediate artefacts and links them to episodic events for traceability.
During consolidation and conflict resolution, the orchestrator may read from knowledge and profile layers while writing back decisions into episodic memory.
During governance and safety checks, policy memory and audit trails from episodic memory are inspected, and promotion pipelines update profile and knowledge as appropriate.
Because the MemoryController exposes high level semantics rather than raw storage, a GSCP-15 implementation can evolve its internal storage technologies without changing prompts or agent coordination logic.
Operational workflow example
Consider an agent helping a user design software architecture over multiple sessions.
The user begins a new project. The orchestrator opens or creates a task workspace and calls GetContextForRequest. Identity and policy memory confirms that cloud vendor and compliance rules apply. Profile memory reveals that the user prefers C# and Azure services.
As the conversation proceeds, episodic events capture exchanges and tool calls. The agent uses vector retrieval to fetch similar past projects and architecture documents, but receives them as structured artefacts via the MemoryController.
The agent notices that the user repeatedly prefers certain architectural patterns. The fact extraction pipeline proposes a new profile fact such as "prefers event driven architectures". After validation, this fact is written into the profile layer.
At the end of the project, the orchestrator invokes PromoteTaskArtifacts. Selected architecture diagrams and key decisions are stored as knowledge artefacts that can be retrieved for future projects. Some project specific state is discarded according to retention policy.
In a later session, the user returns with a new requirement. The orchestrator again calls GetContextForRequest, which now supplies both prior profile and relevant artefacts from the previous project. The GSCP-15 reasoning pipeline uses this context to make the interaction feel continuous and personalized.
At no point do agents directly manage separate static, fact and vector blocks. They operate over a coherent memory substrate aligned with their reasoning framework.
Discussion and future directions
The layered, controller based design described here is intentionally abstract with respect to storage technologies. Static configuration might be stored in files, profile and knowledge in relational or document databases, episodic events in an event store, and vector indices in services like Weaviate or other vector databases. The critical aspect is functional separation and a unified interface.
Several areas merit deeper work:
Formal schemas for profile and knowledge layers, including ontologies for common enterprise domains.
Quantitative evaluation of retention and promotion strategies, balancing personalization benefits against privacy and cost.
Tooling for visualizing and auditing memory state, especially when GSCP-15 orchestrators operate across many agents and tenants.
Techniques to simulate limited memory or controlled forgetting in order to study how agents perform under constrained context.
Integrating these capabilities into GSCP-15 can produce agents that are not only more capable, but also more governable: each piece of knowledge can be traced back to evidence, transformation steps and policy decisions.
Conclusion
Moving from three ad hoc memory blocks to a layered, controller based architecture transforms memory from an implementation detail into a first class system component. By distinguishing identity and policy, profile and preferences, episodic interaction, semantic knowledge, vector indices, task workspaces and working memory, and by mediating access through a MemoryController, agentic systems gain clarity, auditability and flexibility.
When this memory architecture is aligned with GSCP-15, the result is a coherent cognitive and data substrate. Reasoning phases can request the right type of context without awareness of storage mechanics. Fact extraction and promotion become governed processes rather than opaque side effects. Vector indices serve as powerful retrieval tools that point back into canonical records, rather than becoming a fragile second source of truth.
This combination of structured memory and scaffolded reasoning provides a practical path toward long lived, multi agent AI systems that behave consistently over time, adapt to user preferences, and satisfy enterprise demands for transparency and control.
Join the conversation! Your thoughts help the community grow.