docs/demo_transcript.md

Demo transcript

This is the plain-text companion to the four-panel walkthrough in the main README. Each panel below reproduces the user turns and model replies verbatim, with a short note on what the memory system did behind the scenes.

The demo was recorded against a fixed user id (gulupgulup_demo3) with MEMGPT_STORAGE_MODE=disk and MEMGPT_MAX_OUTPUT_TOKENS=2048. Panels 1–3 are one continuous session; Panel 4 is a fresh session with the same user id — the "New Session" button clears the FIFO / session state without touching core, recall, or archival storage.

---

Panel 1 — Core memory write on introduction

User:

Hi! I'm gulupgulup. I'm a data science grad student applying for AI/ML engineer roles. Any tips for behavioural interviews? Just one or two quick ones is fine.

Model:

Hi gulupgulup! Nice to meet you. Here are two quick, high-impact tips for behavioural interviews tailored to AI/ML engineering:

1. Use STAR, but anchor on engineering decisions & trade-offs: When describing past projects, clearly state the problem (Situation/Task), but spend the majority of your time on your specific Action—why you chose a particular model/architecture, how you handled messy data, and the trade-offs you evaluated.

2. Highlight cross-functional impact: ML roles sit at the intersection of business, data, and software engineering. Prepare a story demonstrating how you communicated complex technical concepts to non-technical stakeholders or collaborated with product/engineering teams to align on metrics.

Good luck with your applications! Let me know if you want to practice a specific prompt or dive deeper into one of these.

Behind the scenes: Before replying, the model called core_memory_append three times to write to the <human> block:

• Name: gulupgulup
• Background: Data science graduate student
• Current goal: Applying for AI/ML engineer roles

These become part of the system prompt on every subsequent turn (via a before_model_callback) — the model doesn't need to re-derive them from the conversation history.

---

Bonus — Verifying the write

Between Panel 1 and Panel 2, we asked the model directly to confirm the write landed:

User:

What do you know about me so far?

Model:

Here is what I know about you so far:

• Name: gulupgulup
• Background: Data science graduate student
• Current goal: Applying for AI/ML engineer roles

Let me know if there's anything else you'd like me to keep in mind or if you'd like to dive into interview prep!

Behind the scenes: The model read the <human> block from its own system prompt — no tool call needed. This exchange isn't part of the four-panel scenario, but it's included in the demo assets as a hero image for the top of the README because it makes the memory system visible in a way the four panels don't.

---

Panel 2 — Core memory replace with rejected confirmation

Panel 2a — Confirmation card

User:

Oh actually, I'm applying more for applied research scientist roles, not engineering.

Model:

Got it! I've updated my memory to reflect that you're applying for Applied Research Scientist roles rather than engineering.

Applied Research Scientist interviews tend to place even more emphasis on novel methodology, paper reading/critique, experimental design, and depth in model architectures alongside coding. Let me know if you'd like tips tailored specifically for research roles!

Confirm memory edit? Reply 'yes' or 'no'.

(no details provided by tool)

Behind the scenes: The model called core_memory_replace(section="human", old="...engineer roles", new="...research scientist roles"). Because core_memory_replace is destructive, the ADK runtime paused the invocation and emitted a confirmation request. Gradio's respond handler stored the pending state and surfaced the confirmation prompt.

Known issue: the (no details provided by tool) line should render as a description of what specifically is being changed (e.g. Replace in human: '...engineer roles' → '...research scientist roles'. Proceed?). The hint is being emitted by the tool but not reaching the Gradio surface — see the "known issues" section of the README.

Panel 2b — Rejection and strict-undo

User:

no

Model:

Understood — I'll keep your target role listed as AI/ML engineer. Let me know if you'd like to adjust anything else!

Behind the scenes: The Gradio handler called resume_turn(pending, approved=False). The <human> block was not modified — the original value Applying for AI/ML engineer roles is still there.

Crucially, the model's reply reverts to the original value rather than verbally accommodating the rejected change. This is strict-undo semantics, specified in src/prompts/system.md: rejection means the correction is fully cancelled, and the model must not comply with the new value in any form. Without this instruction, early testing showed the model saying things like "Got it, I'll call you a research scientist for this session" — verbally complying with a change it was told not to make. Strict-undo prevents that failure mode.

---

Panel 3 — Archival insert on a significant event

User:

Just finished my first phone screen — the interviewer spent a lot of time on my image classification project and asked how I'd handle class imbalance in production.

Model:

Congrats on finishing your first phone screen! That's a great milestone to get under your belt.

Class imbalance in production image classification is a classic real-world question—interviewers love asking it because it tests both ML theory (re-sampling, loss functions like focal loss, threshold tuning) and practical systems thinking (monitoring production distributions, active learning/data collection strategies, cost-sensitive evaluation metrics like PR-AUC or F-beta).

How do you feel the response went? If you want to debrief or refine your answer for round two, I'm happy to break down strategies with you!

Behind the scenes: Before replying, the model called archival_insert with the following note:

Completed first phone screen where the interviewer focused on an image classification project and asked about handling class imbalance in production.

The note was written to the SQLite archival table with an auto-incremented id and stored as a 384-dim L2-normalized vector in the FAISS index. Unlike core memory, archival storage is not in the model's prompt on future turns — the model has to search for it explicitly.

---

Panel 4 — Cross-session recall

After Panel 3, the "New Session" button was clicked, which generated a fresh session_id and cleared the chatbot display. The user_id and all three storage tiers (core, recall, archival) are unchanged.

User:

Do you remember what my last interviewer asked about?

Model:

Yes! In your first phone screen, the interviewer focused heavily on your image classification project and specifically asked how you would handle class imbalance in production.

Behind the scenes: Before replying, the model called archival_search(query="last interviewer question") (or a similar query — the exact wording depends on the run). The FAISS index returned the Panel 3 note as the top hit, filtered by user_id to guarantee cross-visitor isolation. The model composed the reply using both details from the stored note.

This is the payoff panel. Every prior panel writes to memory; this one reads across a session boundary. Core memory in <human> would also have survived the New Session click — but the recalled fact here (the specific interview question) is in archival, not core, so the reply requires the semantic search path to work end-to-end.

---

Recording environment

• Storage mode: disk (on-disk SQLite for sessions / recall / archival, on-disk FAISS index)
• Fixed user id: gulupgulup_demo3
• Output token cap: MEMGPT_MAX_OUTPUT_TOKENS=2048 (default is 1024)
• Model: Gemini via Google ADK
• Panels 1, 2a, 2b, 3 in one session; Panel 4 in a fresh session after clicking "New Session"

The data/ directory was wiped and the fixed user id was set before Panel 1 to guarantee the demo started against empty storage.