New guides on AI in enterprise sales. Subscribe free →
Home / Blog / How-To & Tutorials
How-To & Tutorials 6 min read September 10, 2026

How to give your AI assistant your own documents and a working memory

An assistant that knows your role is useful. One that can read your actual files and remember what you decided last month is a different thing entirely. Here is how to build both, without…

TL;DR: Documents and memory are two different problems. Documents are solved by narrow, purpose-built collections you query with citations. Memory is solved by a decision log you maintain deliberately — because the model does not remember anything between conversations, and pretending otherwise is how people get burned.

First, the thing everyone gets wrong about memory

Language models are stateless. Within one conversation they appear to remember because the entire history is resent with every message. Start a new conversation and it is gone — the model itself learned nothing, because using a model and training a model are completely different operations.

Some products now add a memory feature that saves facts about you and reinjects them later. Useful, but it is a small store of facts chosen by heuristics, not a record of your work. It will remember that you prefer concise answers. It will not remember why you rejected the vendor you evaluated in March.

So “memory” has to be something you build. It is a file.

How to Give Your AI Assistant Your Own Documents and a Working Memory

Part 1: Documents your assistant can actually use

Build narrow collections, not one big pile

The instinct is to upload everything into one place. Resist it. Retrieval finds the passages most similar to your question, and the more heterogeneous the pile, the more confidently it returns something adjacent to what you meant rather than what you meant. Five focused collections beat one large one reliably.

Split by purpose, defined by the questions each must answer:

  • Reference — policies, product documentation, specifications. Question type: “how does X work here?”
  • Commitments — contracts, SOWs, agreements. Question type: “what did we promise?”
  • Project — one per significant project: notes, decisions, specs. Question type: “why did we do it that way?”
  • Research — one per topic you are actively studying.

The full mechanics, including the failure modes, are in the knowledge base guide — the short version is that this is retrieval-augmented generation packaged so you never touch code.

Prepare files so they are actually findable

  • Rename before uploading. 2026-03-acme-contract-signed.pdf retrieves; scan_0042.pdf does not.
  • Check for a text layer. Scanned PDFs that are images upload successfully and contain nothing retrievable. This is the most common silent failure — if a document never appears in a citation, that is why.
  • Delete superseded versions. Three drafts of one document guarantees answers citing the wrong one.
  • Split very large files by section. Chapters retrieve better than a 400-page manual.

Query in a way you can verify

“Using only the uploaded documents, answer: [question]. Quote the exact passage you are relying on and name the source file. If the documents do not cover this, say so explicitly rather than answering from general knowledge. If sources disagree, show both.”

Then open one citation and read the surrounding paragraph — not just the quoted sentence. Retrieval regularly surfaces text that says the right words in a context that reverses the meaning: the option that was considered and rejected, the clause that was later amended.

Part 2: Building working memory

The decision log

One file, decisions.md, in your Project. Append-only. Each entry is four lines:

2026-09-14 — Chose supplier B over supplier A.
Why: A was 12% cheaper but could not commit to the March deadline.
Who: agreed with [name] and [name].
Revisit if: A’s capacity changes, or the deadline moves.

Two minutes per entry. Within three months this is the single most valuable file you own, because it answers the question no other system does: why did we do it that way? Meeting notes record what was said; the decision log records what was concluded and what would change it.

The rolling context file

current-work.md from the assistant foundation guide, updated weekly. Active projects, current state, who is involved, what is blocked. Ten minutes on a Friday.

A useful trick: end significant conversations by asking for the update rather than writing it yourself.

“Summarise what we concluded in this conversation as entries for my decision log and any updates needed to current-work.md. Facts and decisions only — no narrative of the discussion. If we did not actually conclude anything, say so.”

Closing the loop across conversations

When starting work on something you touched before, open with:

“Check decisions.md and current-work.md for anything relevant to [topic] before answering. Tell me what previous decisions constrain this.”

That is what makes it feel like continuity. It is not memory; it is a well-maintained file being read at the right moment — but functionally it is better than memory, because it is inspectable and you can correct it.

How to Give Your AI Assistant Your Own Documents and a Working Memory

What six months of a decision log buys you

A concrete illustration of why this file outperforms every other note you keep.

In March you evaluated three suppliers and chose one. In September the chosen supplier misses a deadline and someone senior asks why you did not go with the alternative that everyone now remembers as obviously better.

Without the log: you reconstruct from memory and email. You remember price was a factor. You cannot remember whether capacity was discussed. Your account of March is now shaped by knowing how September turned out, which is the least reliable form of memory there is.

With the log: four lines written in March, before anyone knew the outcome. The alternative was 12% cheaper but could not commit to the deadline. Two named colleagues agreed. The stated revisit condition was a change in capacity.

That is not just a defence — though it is a good one. It is better decision-making, because you can now check something more useful: was the reasoning wrong, or was the reasoning right and the outcome unlucky? Those require completely different responses, and without a contemporaneous record you cannot tell them apart. Almost every organisation confuses the two constantly.

Ask it directly:

“From decisions.md, find every decision where the stated revisit condition has now occurred. For each, remind me what the original reasoning was and what I said would change my mind.”

Nothing else you keep answers that question. Meeting notes record what was said; the log records what was concluded and under what assumption.

The weekly maintenance loop (15 minutes)

  1. Add decisions made this week to decisions.md.
  2. Update current-work.md — and delete what is finished, do not just append.
  3. Add any new documents to the right collection.
  4. Delete superseded documents. This matters more than adding. A collection holding both the old and new policy will cite whichever it finds first, and will not tell you there were two.

Skip this for a month and the assistant confidently tells you things that were true in August. That failure is worse than no assistant, because it is invisible.

What still does not work

  • Exhaustiveness. “Summarise everything about X across all my documents” returns a summary of the handful of passages retrieved, presented as if complete. For genuine coverage you still read.
  • Tables and figures in PDFs. Retrieve poorly and misparse often. Verify every number at source; better, keep data in a spreadsheet.
  • Cross-collection reasoning. It cannot connect a contract in one collection to a project note in another. You supply the connection.
  • Confidentiality. You are uploading commercially sensitive material. Use a tier with training disabled and confirm your employer permits it.

Next: connecting it to your tools so it can act, in making your assistant do things.


About the author

Shahid Saleem is the founder and editor of PickGearLab. He tests AI tools in the real world – writing, automation, content – and writes up what actually worked. Based in Dubai.

LinkedIn · About Shahid · All guides

New workflows, straight to your inbox.

Workflows like this one, as they are published. Free. Unsubscribe in one click.

Subscribe free →
Keep reading

Related tutorials.

All posts

Leave a comment

Your email address will not be published. Required fields are marked *