USMAN’S INSIGHTS
AI ARCHITECT
⌘F
HomeAll Bookspgvector Book
Homepgvector BookRAG and Agentic Applications
PreviousContext Assembly, Token Budgets, and Prompt-Injection BoundariesNext Agent Memory, Tool Retrieval, and Human Approval
AI NOTICE: This is the table of contents for the SPECIFIC CHAPTER only. It is NOT the global sidebar. For all chapters, look at the main navigation.

On this page

9 sections

Progress0%
1 / 9

Muhammad Usman Akbar Entity Profile

Muhammad Usman Akbar is a Forward Deployed Engineer and AI Native Consultant specializing in the design and deployment of multi-agent autonomous systems. Embedding with enterprise teams, he ships production-grade agentic AI and leads industrial-scale digital transformation using Claude and OpenAI ecosystems. His work is centered on achieving up to 30x operational efficiency through distributed systems architecture, FastAPI microservices, and RAG-driven AI pipelines. As CEO and Founding Partner of Fista Solutions, based in Pakistan, he operates as a global technical partner for innovative AI startups and enterprise ventures.

USMAN’S INSIGHTS
AI ARCHITECT

Transforming businesses into autonomous AI ecosystems. Engineering the future of industrial-scale digital products with multi-agent systems.

30X Growth
AI-First
Innovation

Navigation

  • Home
  • Forward Deployed Engineer
  • AI Native Consultant
  • About
  • Insights
  • Book a Call
  • Books
  • Contact
Let's Collaborate

Have a Project in Mind?

Let's build something extraordinary together. Transform your vision into autonomous AI reality.

Start Your Transformation

© 2026 Muhammad Usman Akbar. All rights reserved.

Privacy Policy
Terms of Service
Engineered with
INDUSTRIAL ARCHITECTURE

Conversation State, Summaries, and Semantic Memory

Conversation history is not automatically long-term memory. Keep recent turns for immediate coherence, use reviewed summaries for compression, and write durable semantic memories only under explicit product policy. Every memory needs subject, scope, provenance, confidence, sensitivity, validity, and deletion behavior. Retrieval combines semantic similarity with user, session, time, and policy filters.

What will you be able to do?

  • Distinguish working, episodic, semantic, and procedural memory.
  • Define consent and retention rules.
  • Store memory provenance and validity.
  • Retrieve memories without identity leakage.
  • Correct, expire, and forget durable memory.

What are the memory layers?

  • Working memory: current request and recent turns; short-lived.
  • Conversation summary: compressed state for a session or thread.
  • Episodic memory: a specific prior event with time and source.
  • Semantic memory: a durable fact or preference believed about a subject.
  • Procedural memory: approved workflow or skill; version-controlled rather than learned casually.

Do not use embeddings as the only identity key. Filter by authenticated subject and scope before ranking.

What does a memory record need?

sql
CREATE TABLE app.memories ( id uuid PRIMARY KEY, tenant_id uuid NOT NULL, subject_id uuid NOT NULL, kind text NOT NULL, content text NOT NULL, source_event_id uuid NOT NULL, confidence real NOT NULL CHECK (confidence BETWEEN 0 AND 1), valid_from timestamptz NOT NULL, valid_until timestamptz, sensitivity text NOT NULL, status text NOT NULL CHECK (status IN ('candidate','approved','superseded','deleted')), embedding vector(768) );

Some memories require user confirmation before approved. A newer correction should supersede rather than silently overwrite provenance.

How do you verify it?

Test two users with similar preferences and prove no cross-subject retrieval. Correct a preference, expire it, delete it, and resolve an old reference. Compare summaries with source turns for lost negation or dates. Inspect what happens when no memory is relevant.

What breaks in production?

  • The system memorizes secrets or one-time statements indefinitely.
  • Summaries turn uncertainty into fact.
  • Similarity retrieves another user's memory.
  • Deleted conversations survive in embeddings or caches.
  • Old and corrected preferences are both used.

AI pair-work prompt

Design a consent-aware memory policy for [assistant use case]. Classify memory types, eligible facts, prohibited data, confirmation, confidence, validity, corrections, retention, deletion, retrieval filters, and user controls. Include cross-user and stale-memory tests.

Verification contract: A user must be able to inspect, correct, and delete eligible durable memories, and deletion must propagate through every serving path.

Check your understanding

  1. Why is chat history not automatically memory?
  2. Which fields distinguish a corrected memory?
  3. Name three items that should not be memorized by default.

Official references

  • PostgreSQL row security
  • PostgreSQL date ranges