ConceptFoundationalModel Fluency & the AI PM Role / The AI literacy baseline every PM needs / #2

Describe the difference between a context window and a model's memory.

TRACE · what a context window actually is, and what it isn't, tested on a five hour planning call at Bramknell Logistics

Rivenote joins a video call, listens the whole way through, and writes up the notes and the action items so nobody has to. Tegan Sculthorpe built its live in call feature, Ask Rivenote, so a team could ask it a question mid meeting and get an answer pulled from everything said so far. This is the one Tuesday call that taught her the feature had two different failure modes wearing the same words, "I don't see a record of that."

The direct answer
A context window is not memory. It is the fixed slice of a conversation a model can actually see on one call, and once a transcript runs past that limit, the earliest turns silently drop or get compressed, with nothing left behind and no warning shown. Memory, when a product genuinely has one, is a separate system built on top of the model: specific facts pulled out and saved outside the conversation, then loaded back into every future call, including a brand new session days later. Test which one you are looking at by asking the same fact back in a fresh session with no shared history. If it comes back, that is memory. If it only ever worked inside the same long call before the window filled, it was never memory at all.
Do this, in order
  1. Treat context window and memory as two different systems, never as one feature with two settings.Why: a hard token limit that resets every call and a deliberately saved fact that survives a new one are not the same mechanism just because both feel like "remembering."
  2. Test any "it forgot" symptom in a brand new session with no shared history, not a rephrase in the same call.Why: only that test tells you whether you're looking at a window problem or a memory problem, and the two need completely different fixes.
  3. Never assume a large context window means nothing gets dropped on a long call.Why: Bramknell's ceiling was 128,000 tokens, and the running transcript plus every earlier live answer crossed it by 12:50 p.m., under four hours in.
  4. Make the drop visible instead of silent.Why: a warning at the ceiling gives a person the chance to catch what's about to fall out, instead of finding out thirty four minutes into a re debate.
  5. Widen what a memory system is allowed to capture, not just how big the window is.Why: only 61% of decisions spoken out loud on long calls ever made it into memory at all, because the save step needed an exact trigger phrase.
  6. Leave short calls alone.Why: under ninety minutes, the whole conversation stays inside the window the entire time, so tightening the save rule there just adds noise for a problem that never happens.

How to answer this, stage by stage

Nobody is grading whether you can recite the word "token." They're grading whether you can tell two things apart that a product's own marketing happily blurs together.

1
Scope it to one product, one call
Say it like this
"Let's ground this in one real case. Rivenote joins a video call, listens, and writes up notes and action items. It also has a live, in call assistant called Ask Rivenote, so a team can type a question mid meeting and get an answer. Tegan Sculthorpe built that feature, and owns what happened when one call ran five hours long."
Why this works
One real product stops the answer from turning into a dictionary definition of "context window."
2
State the split in one line, before anything else
Say it like this
"Quick definition up front, because the whole answer hangs on it. A context window is what the model can see on this one call, right now, and it has a hard limit. Memory, if a product has one, is a separate store of saved facts that gets loaded back in, even on a call that starts from nothing. They're not two strengths of the same thing. They're two different pieces of plumbing."
Why this works
Giving the clean definition first means the story that follows is proof, not the reader's first exposure to the idea.
3
Say your structure out loud
Say it like this
"I'll run this as TRACE. Timeline: what actually happened, and when, across one long call. Recut: slice the confusion apart cleanly, window against memory. Assume nothing: rule out the boring explanations before the interesting one. Cause candidates: three real reasons it could have failed. Evidence test: the one check that tells you which one it actually was."
Why this works
Two seconds of structure signals a method, not a guess dressed up as confidence.
4
Reframe the question
Say it like this
"This isn't really 'why did the tool forget.' Forgetting implies it had the fact and lost it. What actually happened is closer to two separate failures wearing the same sentence: one thing fell out of a window that was never designed to hold it that long, and a completely different thing was never written down anywhere in the first place."
Why this works
This line is the whole answer in miniature. Skip it and the rest sounds like a list of technical facts.
5
Give the decision, committed
Say it like this
"So here's what I'd actually say. Don't judge whether something will be remembered by how big the context window is. Judge it by whether it was ever saved to a separate memory store on purpose. A window this big just delays the drop. It doesn't prevent it, and it does nothing at all for a brand new session."
Why this works
This is the direct answer to the question, said plainly before a single number gets discussed.
6
Prove it with the real call, numbers first
Say it like this
"Here's what actually happened. Bramknell Logistics ran a five hour ten minute planning call. At 9:38, the team decided out loud to move the Ohio contract to Vantage Line and drop Bell Fleet. The running transcript crossed Rivenote's 128,000 token ceiling at 12:50. At 1:47, a manager asked Ask Rivenote whether the Ohio call had already been made. It said, 'I don't see a record of a decision on this yet.' The team spent the next thirty four minutes re arguing a decision they'd already made."
Why this works
Four real times, in order, beat any paragraph explaining what a token ceiling is in the abstract.
7
Name the evidence test before the interviewer does
Say it like this
"The test that actually separates a window problem from a memory problem isn't asking again, mid call, in different words. It's opening a completely new session, with nothing carried over, and asking the same question there. Tegan did that the following Monday. Four different phrasings, zero hits. That's not a search problem. That's a fact that was never saved anywhere."
Why this works
Naming the exact test yourself, and its result, is stronger than waiting for the interviewer to force it out of you.
8
Say what stays the same, then close
Say it like this
"One thing I'd leave alone: short calls. Under ninety minutes, nothing ever gets close to that ceiling, so this exact confusion can't happen there. So, to close it: a bigger window buys you time inside one conversation. It buys you nothing across two. If you only remember one line from this, remember that a window resets, and memory, when it's real, doesn't."
Why this works
Naming a place the problem doesn't apply shows judgment, and the close restates the decision in one breath.

Let's learn

Rivenote is a program that sits in on a video call, listens the whole time, and hands the team a clean set of notes and a list of who owes what once the call ends. Before it, someone on the team had to type notes by hand and email a summary afterward, and it usually took about twenty five minutes to write up properly, longer if the meeting ran long or the notetaker had to step out.

Once Rivenote shipped, that twenty five minutes dropped close to zero. The bigger change was Ask Rivenote, the live in call assistant Tegan Sculthorpe built. Type a question into the call at any point, get an answer pulled from everything said so far that meeting. For a year and a half, it was the most used thing Rivenote had ever shipped. Teams stopped keeping their own scratch notes during a call entirely, because asking the assistant was faster than scrolling back through a shared doc.

Hand sketched comparison diagram titled Before the habit, and the year it held. Left panel, a document icon labeled Tegan's old job, caption a paper pad, every decision written down within the hour. Right panel, a person icon labeled Eighteen months in, caption teams stopped keeping their own notes at all.
Tegan spent four years writing decisions down by hand before she built software to do it. For a year and a half, Ask Rivenote earned the same trust her old pad used to.

Then came a Tuesday. Bramknell Logistics, a regional freight company, ran its quarterly planning call as one continuous video meeting, five hours and ten minutes, no restart, Rivenote present the whole way through. Forty minutes in, the team made a real call: move the Ohio distribution contract to Vantage Line, and stop renewing with Bell Fleet. Nobody used a formal phrase for it. Someone just said, "yeah, let's go with Vantage then, we're done with Bell Fleet," and the room moved on.

Here is the turn. The extra minutes it took the assistant to answer wrong were never the real problem. The real problem is that "I don't see a record of this" sounds exactly the same whether it means "this genuinely hasn't been decided yet" or "this fell out of what I can currently see." A manager who had stepped away and rejoined at 1:47 asked Ask Rivenote whether Ohio had already been settled. It answered, "I don't see a decision on this yet in what I have so far." Nobody in the room could tell that was a blind spot instead of the truth. So they spent the next thirty four minutes re arguing a decision that had already been made, and the regional director very nearly picked up the phone to reopen the conversation with Bell Fleet's account rep before someone remembered it had already been settled that morning.

It didn't get the decision wrong. It just quietly ran out of room to hold it, and nobody could tell the difference from the outside.

What it costs at its worst: twelve people sat through thirty four minutes of that re debate, about six and a half hours of combined time on one call. And it could have been worse. If the director's call to Bell Fleet had gone through, Bramknell would have been renegotiating with a vendor it had verbally dropped that same morning, in front of the vendor it had verbally chosen instead. A confidently worded "I don't see a decision on this" from a tool people trust is more dangerous than silence, because silence makes a person ask around. A wrong answer that sounds sure of itself gets believed.

Knowledge spark: what's a token? A token is the small chunk of text a model actually reads, a bit shorter than a whole word on average. A context window's size is measured in tokens, not minutes or pages, because that's the actual unit the model is limited by.
The choice I would take back Rivenote's live save step only writes a decision into memory when it hears an exact trigger phrase, something like "let's decide" or "so we're going with." Early testing showed that without a gate like that, the assistant saved everything as a "decision," including half formed suggestions nobody meant seriously, and that noise made the whole feature useless. The gate was the right call then. It stopped being the whole story once calls got long enough that a phrase like "yeah, let's go with Vantage" needed to count too, and nothing backed it up once the window truncated.

What I would leave alone: any call under about ninety minutes. The entire conversation stays inside the token window the whole time on a call that short, so the assistant never needs memory to answer a question about something said earlier that same meeting. Tightening the trigger phrase rule there would only add noise to a problem that structurally can't happen yet.

The lesson: a feature that quietly behaves differently depending on how long the call has been running is a feature nobody actually designed on purpose. We built one mechanism, a window, and let people believe it was two, a window and a memory, because we never made the line between them visible to anyone using it.

Now here is the same thing as a story

Say the short version out loud in an interview. Read this one when you want to feel exactly how the same four words, "I don't see a record," can mean two completely different things.

Tegan Sculthorpe spent four years as an operations analyst before she ever wrote a line of product code, sitting in on client planning calls with a paper legal pad, writing down every decision the second someone said it out loud. She'd learned the hard way that a decision left unwritten for even an hour was a decision that would get re argued in three weeks by someone who genuinely didn't remember agreeing to it. She joined Rivenote two years ago to build, in software, the thing she used to be by hand.

She built Ask Rivenote herself. For a year and a half it was the best loved thing the company had shipped. Teams used it constantly, live, mid call: did we already cover the budget line, what number did Priya give earlier, who's supposed to own the intake form. It got good enough, fast enough, that a habit formed nobody had planned for. First, people still kept a personal scratch doc open during calls, just in case. Then they stopped opening it. Then, on most teams, the doc quietly stopped existing at all. Why keep your own notes when the assistant already has better ones?

Bramknell Logistics' quarterly planning call ran long that Tuesday, the way it always did, one continuous session from nine in the morning. Forty minutes in, the regional director made the Ohio call out loud, in the middle of an unrelated sentence about a warehouse lease, and the room moved straight on to the next topic. Nobody wrote it down. Nobody needed to. Ask Rivenote had it.

Hand sketched horizontal timeline titled One call, five hours ten minutes. Four marks along the line. Nine a m, call starts. Nine thirty eight a m, Ohio decision made out loud. Twelve fifty p m, this mark in amber, transcript crosses the ceiling, 128,000 tokens. One forty seven p m, this mark in red orange, Ask Rivenote answers no record found.
Same call, no restart, no break. Just over three hours between the decision and the point where the transcript had already outgrown what the model could see.

Somewhere around 12:50, with nobody watching for it, the running transcript, plus every earlier answer Ask Rivenote had given that morning stacked into its own chat history, crossed 128,000 tokens. Nothing announced it. No banner. No dropped notification. The pipeline just started sending the model the newest chunk that fit, and quietly left the oldest part behind, the part that held the Ohio decision.

At 1:47, a warehouse ops manager who'd stepped out to take a call rejoined and asked, out loud, into the meeting, "did we already decide on Ohio or are we still going back and forth." Ask Rivenote answered instantly and confidently: "I don't see a decision on this yet in what I have so far." The manager had no way to know that sentence meant "it fell off the back of what I can currently see" instead of "this genuinely hasn't happened." Neither did anyone else in the room. So they started over. Thirty four minutes of re arguing vendor pros and cons that had already been settled, until the regional director, halfway through drafting a message to Bell Fleet's account rep to reopen talks, stopped and said, "wait, didn't we already do this?"

We did not lose thirty four minutes to a bad guess. We lost it to a decision that was never truly saved anywhere at all, and a window that had already let it go.

Tegan opened the incident the next morning expecting a clean, single answer: the window had filled, case closed, ship a bigger one. She almost stopped there. What made her keep going was a nagging question: even inside the window, before it filled, the live save step should have been catching real decisions and writing them to memory on the spot, the same way it always had on shorter calls. Had it caught this one, or not.

Hand sketched comparison diagram titled Two systems, not one. Left panel, a gauge icon labeled Context window, caption everything said so far, a hard token ceiling, empties at the next new call. Right panel, a document icon labeled Memory, caption only facts someone chose to save, loaded back into a brand new call.
The window and the memory store are not two settings on the same dial. One resets every call. The other only holds what somebody, or something, decided was worth writing down.

She checked the boring explanations first. The transcript around 9:38 was clean, correctly spelled, nothing garbled by the transcription engine. Bramknell's workspace had the memory feature switched on, confirmed, because Ask Rivenote had correctly pulled a fact from a meeting two weeks earlier for a different question that same morning, before the window filled. So the plumbing worked. Something behavioral, not broken, was actually going on.

Hand sketched comparison diagram titled What happens at the ceiling. Left panel, a plain box labeled Under the ceiling, caption everything said so far still fits, nothing dropped. Right panel, a box with a question mark labeled Over the ceiling, caption oldest turns quietly drop, no warning shown.
Under the ceiling, the whole call is visible. Cross it, and the oldest turns leave with nothing to mark that they ever did.

That left three real candidates. One: the live window genuinely explained the 1:47 answer, since the ceiling crossed at 12:50, before the question was ever asked. Two: the decision had been saved to memory just fine, and the manager's exact phrasing simply didn't match how it got stored, a plain search problem. Three: the decision was never captured anywhere at all, because the live save step only fires on an exact trigger phrase, and "yeah, let's go with Vantage, we're done with Bell Fleet" never matched the pattern it was listening for.

The evidence test was the one that actually mattered. The following Monday, Tegan opened a brand new session, no shared history, no continuation of Tuesday's call at all, and asked about the Ohio decision four different ways: plainly, by vendor name, by contract number, by date. All four came back empty. That single test ruled out candidate two on the spot. A retrieval mismatch would have surfaced under at least one phrasing. Nothing did, which meant the fact was never written down in the first place. Candidate three, confirmed. Candidate one still stood on its own, proven by nothing more exotic than the clock: the ceiling crossed at 12:50, the question landed at 1:47, an hour later.

Hand sketched icon list titled Three suspects, one real cause. Three rows. One, ceiling crossed live, explains one forty seven p m. Two, this row greyed out and ruled out, rephrasing never finds it either. Three, this row emphasized in red orange, never saved, no trigger phrase matched.
Two things were true at once. The window explains why the live answer failed. The save rule explains why it was never coming back at all, on any day.

The decision Tegan would take back sat in a design review nine months before launch, the one where the team built the trigger phrase gate for the live save step, because ungated extraction in early testing had turned every stray suggestion into a saved "decision," and the feature drowned in noise nobody trusted. Gating it was the right call at the time. Most decisions on most calls did get phrased the way the gate expected, because most calls were short enough that people spoke a little more formally, a little more on the record.

Run the same Tuesday again, with one change: whenever the running transcript nears the ceiling, before anything drops, a second pass, less strict than the live gate, sweeps the part about to fall out and writes any sentence that reads like a decision into memory on its own judgment, flagged as "worth a second look" rather than treated as certain. Same five hour call. At 1:47, the ops manager asks the same question. Ask Rivenote answers in about four seconds: "yes, decided 9:38 this morning, Ohio moves to Vantage Line." No re debate. No half drafted message to Bell Fleet.

What I'd tell myself, sitting in that design review nine months earlier: I built a gate to keep the feature honest, and never once asked what would back it up on the one day the gate itself would miss something real.

TRACE, so "it forgot" never gets said again

Not a way to prove the window was the villain. TRACE is what actually separates two structurally different failures that happen to share one apologetic sentence.

TTimeline. Lay out exactly when, in one continuous call.
9:00, call starts. 9:38, the Ohio decision, spoken plainly, no formal phrasing. 12:50, the running transcript plus the assistant's own chat history crosses 128,000 tokens. 1:47, the question that exposes the gap. Just over three hours sit between the decision and the ceiling. Just under an hour sits between the ceiling and the question that found the hole.
The gap that matters isn't the length of the call. It's the order these four moments landed in.
RRecut. Slice the confusion apart cleanly.
A context window is a hard limit on what the model can see on this one call, right now. It resets to empty the moment a new call starts, no matter what happened in the last one. Memory, if the product genuinely has one, is a separate system: specific facts, pulled out on purpose and written down outside the conversation, then re loaded into every future call, old or brand new.
Everything else in this answer is just this one distinction, tested against a real Tuesday.
AAssume nothing. Rule out the boring explanations first.
Before trusting anything exotic, Tegan checked whether the 9:38 transcript was even clean. It was, correctly spelled, easy to search. She checked whether Bramknell's memory feature was switched on at all. It was, and had worked correctly earlier that same morning on an unrelated question. Neither was the problem, which meant the real cause was behavioral, not a setting left off by accident.
Rule out "the feature's just broken" before reaching for "the feature has two failure modes." One of those is a bug ticket. The other is a design gap.
CCause candidates. Three real hypotheses, not everything possible.
One, the live window: the ceiling crossed at 12:50, well before the 1:47 question, so anything from 9:38 had already fallen out of what the assistant could currently see. Two, a retrieval mismatch: maybe the decision was saved fine, and the manager's exact wording just didn't match how it got stored. Three, never captured: the live save step only fires on an exact trigger phrase, and the casual "let's go with Vantage" was never going to match it, live or after the fact.
One and three can both be true at once, and in this case they were. That's the part a one line explanation misses.
Hand sketched decision tree titled Which session are you asking in. Root box reads Ask about something said before, branching into three conditions. Same call, window not full yet, leads to Might work, context window. Same call, window already full, leads to Fails, fell out silently. Brand new call, days later, leads to Works only if saved, memory.
Three branches, three different answers, all from the exact same question, "did we already decide this."
Running tokens across Bramknell's call, against the 128,000 ceiling
200k 150k 100k 50k 0 128,000 ceiling 9:38, decision 12:50, ceiling crossed 1:47, "no record found" 9:00 10:30 11:30 12:50 2:10
Running tokens, transcript plus chat history128,000 token ceiling
The 9:38 decision sat 14,000 tokens in. By 1:47 the call was 151,000 tokens past that point, well outside a window that only ever holds the most recent 128,000.
EEvidence test. The one check that separates the top two candidates.
Open a brand new session, no shared history, and ask the same fact back four different ways. If any phrasing surfaces it, that's candidate two, a search problem, fixable by improving retrieval. If none does, that's candidate three, never captured at all, fixable only by changing what gets written to memory in the first place. Tegan's four phrasings on Monday all came back empty.
This is the strongest move in the whole framework. It's checkable against what actually happened, not a guess about which explanation sounds more likely.
Decisions spoken out loud that ever reached memory, across 40 reviewed Rivenote calls
100% 50% 0 96% Calls under 90 minutes 61% Calls over 3 hours
Short calls, stays inside the windowLong calls, some decisions never captured
Bramknell wasn't a freak accident. Across a broader sample, long calls quietly lost more than a third of their spoken decisions to the trigger phrase gate.

Three things worth saying plainly, since interviewers push here. Tegan considered a second fix before the one she shipped: just make the trigger phrase gate stricter, so it only ever caught unmistakably formal decisions, and train the team to speak more formally when something mattered. She rejected it, because it puts the burden on twelve people changing how they talk in a five hour call, instead of on the product catching real language the way people actually use it. The AI specific failure worth naming by name is silent context truncation: a running conversation quietly outgrows what a model can see, with no error and no visible sign, and the fix is not a bigger window, since any window eventually fills on a long enough call, it's a visible warning plus a second, less strict capture pass that runs before anything drops. The trade off, accepted on purpose: that second pass is deliberately looser than the live gate, which means it will occasionally flag something as a "decision" that wasn't quite one, a small accuracy cost, in exchange for never again saying "I don't see a record" about something that was, in fact, decided out loud in the same room an hour earlier.

And if you want to be sure it really works, try it somewhere else

Same five letters, a veterinary clinic instead of a freight company, and this time the whole call barely runs twenty minutes. The confusion still shows up, because it was never really about how long the call was.

Thistlefield builds an ambient scribe for veterinary clinics: it listens during an appointment and drafts the visit note, and it's meant to carry a patient's history forward automatically, visit to visit, weeks or months apart. Griet Kinnaird runs product there, and hit a version of Tegan's exact confusion eleven months into the job, on a case where the "call" itself was never anywhere close to any token ceiling.

Hand sketched comparison diagram titled Two visits, one missing fact. Left panel, a person icon labeled Visit one, three weeks ago, caption owner mentions a reaction out loud, never added to the signed note. Right panel, a document icon labeled Visit two, today, caption assistant checks memory, finds nothing, because memory only reads the signed note.
Different clinic, different clock, same underlying gap: something said out loud never made it into the one place the assistant is allowed to look.

Three weeks earlier, a dog's owner had mentioned, mid sentence, that the dog had a mild reaction to amoxicillin once as a puppy. The vet was interrupted before finishing that part of the note, and it never made it into the signed, finalized chart. Today, a different vet at the same clinic, treating an ear infection, asked Thistlefield's assistant whether this patient had any known drug reactions. It said no record found. The vet nearly prescribed amoxicillin.

The decision Griet would take back Thistlefield's memory only ever reads the signed, finalized note, never the raw audio of the visit, because early on, pulling from raw audio surfaced too many false positives, symptoms mentioned and later ruled out, that cluttered a patient's record with things that turned out not to be true. That rule kept the record trustworthy. It also meant anything said out loud but never added to the finished note, for any reason, simply ceased to exist as far as the assistant was concerned.

Mapped onto TRACE: the timeline shows the fact spoken at minute fourteen of visit one, and the gap discovered at minute six of visit two, three weeks later. The recut is the same clean split, context window against memory, except here the window was never the issue at all, since a twenty minute visit never comes close to any ceiling. The assumption Griet ruled out first was that the raw audio simply didn't exist anymore; it did, sitting in a searchable archive nobody's live workflow ever queried. The cause candidates: a note taking error, a memory bug, or memory doing exactly what it was built to do, reading only the signed record. The evidence test gave the same shape of answer as Bramknell's: pulling the raw transcript directly, bypassing the assistant's memory path entirely, found the sentence in seconds, proving the fact was never lost to a technical failure. It was excluded on purpose by a rule nobody had revisited since the day it was written.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to the reframe: it's not "did it forget," it's "was this ever saved on purpose, and does the fact survive a brand new session."
Cost: no time to trace a real incident. Ask one question instead: last time something "wasn't there," did a fresh, unrelated session ever get tried, or only a rephrase in the same conversation.
The model got better, for real: say the next model ships with a context window ten times the size. The live truncation risk on a five hour call mostly disappears. The memory capture gap doesn't shrink at all, because it was never about the window's size in the first place.

Where people run it wrong.
They treat a big context window as proof that nothing will ever get dropped, instead of proof that it takes longer to happen.
They test "does it remember" by asking again in the same conversation, and mistake context window persistence for real memory.
They fix a memory gap by shipping a bigger window, when the actual problem is what gets written down in the first place.

How to use it live. When an interviewer asks this cold, buy two seconds by asking one thing back: "are we talking about the same conversation, or a fact coming back in a brand new one?" That question alone is usually exactly what a question shaped like this one is listening for.

Flashcards (tap any card to flip it)

1 · THE FRAMEWORK
What framework fits a question that asks you to tell apart two things a product's own marketing treats as one feature?
Tap to flip
ANSWER
TRACE: timeline, recut, assume nothing, cause candidates, evidence test. Built for ruling out the obvious sounding explanation before trusting it.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Tegan Sculthorpe, who built Rivenote's live in call assistant, and the Ohio decision that fell out of a five hour call at Bramknell Logistics.
3 · THE ASSUMPTION
What did Tegan rule out before trusting the exciting explanation?
Tap to flip
ANSWER
That the transcript was garbled, and that the memory feature was switched off. Neither was true, so the cause had to be behavioral, not a broken setting.
4 · THE RECUT
How does TRACE slice apart a context window and memory?
Tap to flip
ANSWER
A context window is a hard limit on what's visible on one call, and it resets every new call. Memory is a separate saved-facts system that gets loaded back in, including on a brand new session.
5 · THE OLD DECISION
What decision would Tegan take back?
Tap to flip
ANSWER
Gating the live save step behind an exact trigger phrase. It kept the feature honest on short calls, but left casual, real decisions on long calls with no backstop once the window truncated.
6 · THE NUMBER
Fill in the blank: the token ceiling was ___ tokens, crossed at ___, about ___ before the failed question.
Tap to flip
ANSWER
128,000 tokens. Crossed at 12:50 p.m. About one hour before the 1:47 p.m. question that came back "no record found."
7 · THE EVIDENCE TEST
What's the one test that tells you whether you're looking at a window problem or a memory problem?
Tap to flip
ANSWER
Ask the same fact back in a brand new session with no shared history. If it comes back, that's memory. If it only ever worked inside the same long call, it was context window persistence, not memory.
8 · CROSS-PRODUCT TRANSFER
Section 4 runs TRACE again on a different product. Which one, and what's the equivalent gap?
Tap to flip
ANSWER
Thistlefield, a veterinary ambient scribe run by Griet Kinnaird. A drug reaction mentioned out loud in one visit never made it into the signed note, so memory, which only reads signed notes, never had it either.

Check yourself Score: 0 / 0

True or false
1. True or false: Ask Rivenote failed at 1:47 p.m. and again on Monday for the exact same reason.
  • True
  • False
Show hint
Check the Cause candidates and Evidence test steps in the TRACE recap.
Show answer
False. The 1:47 failure was a context window problem, proven by the clock: the ceiling crossed at 12:50, before the question. The Monday failure was a memory problem, proven by four phrasings all coming back empty in a brand new session.
Multiple choice
2. Which of these would actually have fixed Monday's failed question at Bramknell?
  • A. A much bigger context window.
  • B. Asking Ask Rivenote the question with different wording.
  • C. A decision capture step that doesn't need an exact trigger phrase.
  • D. Restarting the call from the beginning.
Show hint
A brand new session starts with zero context no matter what fixed the live call.
Show answer
C. A bigger window only delays truncation inside one call; it does nothing for a fresh session. Only something that actually gets written to memory survives to Monday.
Fill in the blank
3. This exact mix up almost never happens on calls under ___ minutes, because the whole conversation stays inside the token window the entire time.
Show hint
Look at "What I would leave alone" in Let's learn.
Show answer
Ninety minutes. Short calls never get close enough to a 128,000 token ceiling for anything to fall out.
Short answer, name the reversal
4. What old decision would Tegan take back, and why did it make sense when the team first made it?
Show hint
Look at the key point box titled "The choice I would take back," in Let's learn.
Show answer
Model answer: Gating the live save step behind an exact trigger phrase. Without it, early testing showed the assistant saved half formed suggestions as real decisions, and the noise made the feature useless. It made sense when calls were short and people spoke more formally.
Short answer, apply it yourself
5. Think of an AI tool you use that seems to "remember" things. What's one question you could ask it, in a brand new conversation, to test whether that's real memory or just a long context window?
Show hint
The test has to start from zero shared history to mean anything.
Show answer
Model answer: Open a fresh chat with no prior turns and ask it to recall a specific fact from an earlier, separate conversation. If it can't, whatever felt like "remembering" before was context window persistence inside that one earlier conversation, not real memory.
Short answer, work the numbers
6. If Bramknell's call had used a model with a context window ten times bigger, 1,280,000 tokens, would Ask Rivenote have gotten the Monday question right? Why or why not?
Show hint
Separate what a bigger window fixes inside one call from what it does across two.
Show answer
No. A bigger window would likely have kept the 1:47 live answer correct, since the call never would have crossed a ceiling that size. It changes nothing about Monday, because a brand new session starts from zero regardless of window size, and the decision was never written to memory in the first place.
Before you close the answer
Why this works
Tests whether you'll blur "big context window" and "has memory" into one comforting idea, or hold the line that they're genuinely different mechanisms with different failure modes. Most candidates reach for "just make the window bigger" and stop there.
Follow-up traps
"Couldn't you just make the context window bigger so this never happens?" Response: a bigger window delays truncation inside one call, it doesn't fix a fact that was never written to memory; Bramknell's Monday test proved a bigger window would have changed nothing there.

"Isn't memory just a context window with a longer reach?" Response: no. A context window resets to empty at the start of every new session. Memory, when it's real, doesn't; it's a separate store that gets loaded back in on purpose, on any call, old or new.
If pressed
Some memory systems don't store raw text at all; they save an embedding, a compressed numeric fingerprint of the fact, and retrieve it by similarity before re injecting the original text as a short system message ahead of the next call. That's still memory in the sense that matters here, since it survives a brand new session, but it means a memory "miss" can also happen for a completely different reason: the fact was saved, but worded too differently from the question for the similarity search to find it.
From U2xAI Academy

From answering questions to owning outcomes.

A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.

  • A live AI agent you actually shipped
  • A launch decision you can defend under pressure
  • An interview-ready portfolio, not more flashcards
Know more