Stop Re-Explaining Your Data to AI: Personal Context Layer for Analysts

I'm Denis Shokhirev, enterprise AI architect in Freiburg, Germany. At DennisCraft AI Studio, I ship production AI systems for DACH B2B clients using Claude, Supabase, n8n, Doppler, and self-hosted Postgres. After deploying 14 production AI agents in the last 6 months, I see the same pain: analysts constantly re-explain their business logic, field definitions, or edge cases to the AI — losing time and increasing friction.

Why LLMs Forget User Context — and Why It Matters

LLMs like Claude or GPT-4 are stateless by design: every prompt is a fresh start, with limited context size (GPT-4: 128K tokens, Claude: 200K). If you don't provide all the relevant context with each prompt, the model can't “remember” how your tables are structured, what business terms mean, or which edge cases to watch out for. This isn't an AI limitation — it's an architecture issue.

Common Workarounds (and Why They Fail)

I've seen two recurring approaches in deployed systems:

• “Stuff everything in the system prompt.” This quickly hits context length limits, especially when analysts deal with multiple tables or complex business rules.
• “Copy-paste previous answers.” This is manual, error-prone, and breaks any hope of automation.

Result: AI responses become inconsistent, and valuable organizational knowledge is lost between sessions.

Pattern: Personal Memory Layer for Analyst-AI Interaction

The production-ready solution? A personal memory layer between the analyst and the LLM API. Instead of relying on ephemeral prompts, you persist, structure, and selectively inject the analyst's context into every new AI request — automatically.

Reference Architecture

Practical Implementation Steps

• Automatic Extraction of Facts: Use pattern matching or summarization to extract terms, definitions, and business rules from previous conversations. Store as structured JSON per user in Postgres (JSONB column).
• Contextual Filtering: On each new request, filter the memory for relevance — via BM25, or cosine similarity over embeddings (Supabase Vector or pgvector in Postgres).
• Memory Hygiene: Regularly prune stale or irrelevant entries with scheduled n8n workflows. Otherwise, prompts bloat and model responses degrade.

Example: Implementing a Personal Context Layer with Supabase + Claude

Real-world case: A logistics analyst explains “zone_group” and “shipment_id” structure to the agent. From then on, the memory layer automatically injects these definitions into every subsequent prompt — no more repetitive explanations.

import openai
import psycopg2
import json

def get_personal_context(user_id):
    conn = psycopg2.connect(database="contextdb", user="ai", password="****")
    cur = conn.cursor()
    cur.execute("SELECT facts FROM memory WHERE user_id=%s", (user_id,))
    rows = cur.fetchall()
    return [json.loads(row[0]) for row in rows]

def build_prompt(user_id, user_input):
    context = get_personal_context(user_id)
    prompt = "User context:\n"
    for fact in context:
        prompt += f"- {fact['term']}: {fact['definition']}\n"
    prompt += f"\nUser query: {user_input}"
    return prompt

def query_llm(prompt):
    response = openai.ChatCompletion.create(
        model="gpt-4",
        messages=[{"role": "system", "content": prompt}]
    )
    return response.choices[0].message.content

Anthropic's Claude can be used similarly via their SDK; just switch the API endpoint.

Production Pitfalls and How to Avoid Them

• Memory Pollution: If you don't filter for relevance, prompts quickly exceed context limits (“context window overflow”), causing LLM errors. Use vector search or at least keyword-based filtering.
• Data Privacy: Personal facts may contain sensitive info. Always encrypt at rest (Postgres + pgcrypto), and enforce strict row-level security (Supabase RLS).
• Versioning: If definitions change, track history (JSON array of revisions or a separate revisions table). I’ve seen cases (fintech, Germany) where lack of versioning caused LLMs to mix up old/new “risk_tier” definitions, leading to reporting errors. Versioning fixed this.

For reference: Supabase docs on RLS — supabase.com/docs/guides/auth/row-level-security

FAQ

Can RAG (retrieval-augmented generation) solve this?

RAG works for document retrieval, but personal memory is better stored separately — otherwise, user-specific context gets drowned in generic knowledge.

Should memory be plain text or structured?

Structured memory (JSONB) is best for filtering and versioning. Plain text only works for MVPs or simple use cases.

How do I automate memory cleanup?

Use n8n to run scheduled workflows that remove stale facts based on user activity or age.

Can this memory layer work for teams, not just individuals?

Yes, just add a group_id and filter accordingly. This lets teams share and evolve context collaboratively.

Any size limits for memory in Supabase/Postgres?

Technically, you can store tens of megabytes per record, but in practice, 100+ facts per user degrades LLM focus. Prioritize only the most relevant facts.

In your production AI stack, where does your LLM most often lose critical context — project switch, terminology drift, or long-running sessions? I’d genuinely like to know. I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.