← Writing
6 min read

I Taught My Agent to Remember. It Still Forgot to Ask for Help.

Last week ended on a cliffhanger I set up myself: teaching the agent to remember things, instead of investigating every question from a blank slate. This week, that happened. It can now search a small library of past incidents and carry context across a conversation. Both worked on the first real test. Then I asked a completely reasonable follow-up question, and the agent quietly stopped using the memory I'd just built it.

Two New Powers

The first addition was retrieval: a vector store (Chroma, if you're keeping track) holding a handful of past incident write-ups, plus a new tool the agent can call to search them. The mechanism underneath is worth explaining, because it's not what it sounds like. It isn't keyword matching — it's closer to reading for meaning. Every note gets converted into a list of numbers that represents what it's about, not what words it contains, so a question phrased completely differently from the original incident can still find it.

It's not pattern matching so much as reading context, rather than doing a plain text comparison.

The second addition was simpler in concept: stop starting every question from zero. Let the conversation carry forward, so a follow-up like "what about that" actually refers to something.

Both worked beautifully, the first time I tested them. That should have been my first clue to test them a second time.

The Same Fact, Two Different Answers

I asked the agent about a cost spike, and then asked a natural follow-up in the same conversation. Twice, with slightly different phrasing:

Follow-up phrasing Tool called Result
"Has this come up before, and how was it resolved?" search_runbooks Correct — surfaced the exact documented fix
"How would I actually fix that?" none Generic AWS advice, no lookup at all

Same conversation. Same underlying fact, already sitting in a runbook that exactly matched the situation. Two different follow-up questions asking for essentially the same thing, and only one of them made the agent go check. The other one just improvised — competently, confidently, and completely disconnected from a resolution I already had on file.

Debugging a Vibe, Not a Stack Trace

This is the part of building with LLMs that doesn't feel like normal debugging. There's no error, no traceback, no line number. There's just an answer that's a little too generic, and a nagging sense that it should have known better. The temptation is to just rewrite the prompt and hope. I tried to resist that.

Instead, before touching anything, I ran one more test: the same conversation, same failing follow-up moment, but rephrased closer to the version that had already worked. If that also failed, the problem was something structural — maybe memory itself was quietly breaking retrieval. If it succeeded, the problem was narrower: specific wording, not the architecture.

It succeeded. Which meant the fix wasn't "rebuild how memory works" — it was one sentence, in the system prompt, telling the agent to check its runbooks before giving generic advice whenever it's asked how to fix something:

system prompt addition
# added to the existing system prompt
"When asked how to fix, resolve, or address a cost or infrastructure
issue, always check search_runbooks for a documented resolution first
-- prefer a specific, already-known fix over generic best-practice
advice."

Reran the exact original failing phrasing. It called the tool. It surfaced the caching fix. Problem closed.

So far, every real failure has turned out to be a missing instruction, not a missing capability.

That's twice now — this and last week's EC2 inconsistency were both cases where the agent technically had everything it needed and just didn't reliably know when to use it. I don't know yet if that pattern holds forever, but it's held for two out of two, which is enough to change how I debug the next one: check what it knows before assuming it's confused.

Small aside

Also this week: I briefly panicked because my entire tools list appeared to vanish from the notebook. It had not vanished. I had collapsed the cell. Not every bug is a bug.

What's Next

Memory and retrieval are both logged as working, with real test cases to prove it rather than a gut feeling. Next up is the part I've been putting off: an actual evaluation harness instead of me eyeballing five outputs and calling it a day. I already have one confirmed, unfixed bug waiting for it — the agent hallucinated a completely wrong year while reading a real cost report last week — so Phase 3 isn't starting from a blank page either.

Written by
Rajen Tandel

Software developer based in Reston, VA. I work on Angular applications, AWS infrastructure, and agentic AI systems. I write about the practical side of engineering — the stuff that doesn't make it into the docs.