Skip to content

Keep a Working Memory File for Transcription

A transcription model knows the world, but it does not know your world. It has never heard your child’s name, your coworkers’ nicknames, the internal name of your team, or the side project you mention every day. Those are exactly the words it gets wrong, and they are the words you most need to be right when you search your journal later.

A working memory file fixes this. It is one short Markdown file that describes who and what you are talking about these days. A Gemini profile pulls it into every transcription prompt with {{file:...}}, and a scheduled AI agent rewrites it once a day from your recent entries. The loop looks like this:

you record → Ayumi saves the entry as Markdown → a daily agent reads recent entries and rewrites WORKING_MEMORY.md → the next recording is transcribed with that file in its prompt.

This page describes how to build that loop so it keeps helping. The hard part is not creating the file; it is keeping it small.

What the file is for — and what it is not

Section titled “What the file is for — and what it is not”

Decide the purpose before writing a line, because the purpose is what keeps the file from growing.

The file isThe file is not
A dictionary of proper nouns spelled the way you want them, so the model stops mishearing themA summary of your journal
A minimal snapshot of the topics you are in the middle of, so the model can resolve ambiguous wordsA timeline of how things developed
Stable facts that rarely change (household, job, recurring places)A collection of quotes, anecdotes, or memorable phrasing
Your current position on open questions, one or two sentences eachA copy of data that already lives somewhere else

The first row is the main job. Everything else exists only to give the model enough context to pick the right word.

An uncapped working memory grows every day: each run adds a detail and nothing removes one. Within weeks it becomes tens of thousands of characters, and then:

  • It stops helping. The words that matter are buried in prose, and the model weighs a paragraph about last week the same as a name you say every day.
  • Ayumi cuts it off. {{file:...}} embeds at most 8,000 characters; anything after that is dropped. A file that has outgrown the limit silently loses its last sections.
  • Every recording pays for it. The whole file is sent with each transcription request, so a bloated file costs tokens and latency on every recording.

So the file needs a hard cap, and the agent that maintains it needs rules that make shrinking as normal as growing.

Use frontmatter so the agent can read the date and the cap, and put the rules for the agent inside the file itself. That way any agent — or you, editing by hand — sees the rules before touching anything.

---
title: WORKING_MEMORY
updated: 2026-10-17
max_chars: 6000
---
# Working memory
## Rules for whoever updates this file
1. Total length stays under 6,000 characters. Adding means removing.
2. Overwrite; never append dated progress notes.
3. One or two sentences per item. No quotes, no anecdotes.
...
## Proper nouns
**People**: <name> (<reading>) = <relation> / ...
**Places**: ...
**Work**: <team name> (often misheard as "<wrong word>") / ...
**Projects and tools**: ...
**Your own coinages**: ...
## Stable facts
- ...
## Current situation (2026-10-17)
- **Home**: ...
- **Work**: ...
## Current conclusions
- **<open question>**: <your position, one or two sentences>.
Related: [[note]] / [[note]]

Put Proper nouns near the top. It is the part that does the most work, and if the file ever runs past the 8,000-character limit, the end is what gets cut.

  • Set a cap well under the 8,000-character embed limit. Around 6,000 characters leaves room for the rest of your prompt and for a bad day’s overshoot. Record the cap in the frontmatter so the agent can check it.
  • Count after every update. The agent should measure the full file length as its last step and trim before it finishes. A rule the agent never checks is a suggestion.
  • Trim in a fixed order. Decide in advance what goes first — for example, wordy conclusions, then duplicated lines in the current situation. The dictionary is cut last.
  • Link instead of keeping detail. When something deserves more than two sentences, write it in a separate note and leave only a link.
  • Overwrite old statements with new ones. “Started X on the 3rd… X going well on the 5th… X done on the 7th” is the shape to avoid. The file says what is true now.
  • Add one, drop one. When a new open question goes in, a settled one comes out.
  • Rewrite the current situation in full each run and stamp its heading with today’s date. Editing it piecemeal is how stale lines survive.
  • Change conclusions only when your position actually changed. Rewording the same stance every day is noise.
  • Touch stable facts only on a clear change — a new family member, a new job, a move.
  • Do nothing on quiet days. If little was recorded, update the date and one or two lines and stop. An agent that feels obliged to fill space is how the file grows.
  • Keep no changelog. The file is always a snapshot. History lives in your journal and in version control, if you use it.
  • Add only words you actually said, or words you have seen mistranscribed. Words that appear only in AI-written notes — summaries, reports, analysis your agents produce — are not words you speak, and they crowd out the ones you do.
  • Spell each word the way you want it to appear. That is the whole point of the entry.
  • Add a reading or a known mishearing in parentheses when it helps, e.g. <name> (often transcribed as "<common word>"). Skip explanations otherwise.
  • Group by kind — people, places, work, projects and tools, money and paperwork, your own vocabulary. Groups make duplicates easy to spot.
  • Remove words that stopped coming up. A temporary project or a one-off place should leave when it leaves your speech.
  • One or two sentences per item. If it needs more, it needs its own note.
  • Do not collect quotes or memorable phrasing. Your own words already exist in the entries the file was built from.
  • Do not copy data that has a home elsewhere — what you ate, the weather, where you went, purchases, workout numbers. Ayumi already records date, place and weather on each entry, and your other notes hold the rest.
  • Date every number. <value> (measured <date>) is useful context; an undated number quietly goes stale. If you cannot date it, leave it out.
  • Keep diagrams out. The model reads text; a Mermaid block costs characters and helps nothing.
  • Every recording sends this file to your transcription provider. Write it as if it were part of every request, because it is.
  • Never put secrets in it — passwords, keys, account numbers, health details you would not send to the provider. Context that helps transcription rarely needs them.
  • Keep the agent from introducing new sensitive detail. State it in the rules section so every run sees it.
  1. Put the file somewhere both your agent and your devices can reach — for example, a synced notes folder.

  2. In Settings → Transcription, open the Gemini profile you record with most and add {{file:WORKING_MEMORY.md}} to its prompt. Use Insert Variable → Markdown file… to pick the file; Ayumi keeps secure access to it even when it is outside your journal folder.

  3. Tell the model how to use it in the same prompt, for example:

    Below is a reference list of people, places, and terms I use. Use it only
    to spell names and terms correctly and to resolve ambiguous words. Do not
    mention it or add anything from it that I did not say.
    {{file:WORKING_MEMORY.md}}
  4. Record something that uses a few dictionary words and check the transcript.

Let an agent rewrite the file once a day. A reusable skill (or saved prompt) run by a scheduled task in Claude Code, Codex, or a similar tool works well, because the rules travel with the skill and every run follows them the same way.

The skill should do this, in order:

  1. Read the existing file first. Update it in place, section by section. Never regenerate it from scratch — a fresh rewrite loses the dictionary you have built.
  2. Get today’s date in your local time zone. It goes into updated and the situation heading.
  3. Gather recent activity. The last three to five days of journal entries, plus any notes you have changed recently. Read created_at from frontmatter rather than trusting folder names, since Ayumi’s date folders are UTC.
  4. Update each section by its own rule. Dictionary: add newly spoken terms, drop faded ones. Situation: rewrite in full. Conclusions: change only what changed. Stable facts: only on clear change. Related links: keep a fixed number and swap old for new.
  5. Count and trim. Measure the whole file. If it is over the cap, cut in your fixed order until it fits.
  6. Report briefly. Two or three sentences: what changed and the final character count. A short report makes drift easy to notice.

A starting point for the skill’s instructions:

Update WORKING_MEMORY.md from my recent journal activity.
Purpose: this file is injected into my voice-journal transcription prompts.
Its main job is to make the model spell my proper nouns correctly; its
second job is to show which topics I'm in the middle of. It is not a summary,
a timeline, or a collection of quotes.
Rules (the file's own rules section takes precedence):
- The whole file stays under the max_chars in its frontmatter.
- Read the file first and update it in place. Overwrite; never append dated
progress notes. One or two sentences per item.
- Dictionary: add only terms I actually said in entries, or terms that were
mistranscribed. Correct spelling, optional reading in parentheses, no
explanations. Remove terms that no longer come up.
- Current situation: rewrite in full, dated today.
- Conclusions: change only positions that actually changed. If you add a new
open question, remove a settled one.
- Don't copy data that lives elsewhere (meals, weather, places, workouts).
Date every number; drop numbers you can't date. No secrets.
- If little happened, update the date and one or two lines, and stop.
Finally, count the file's characters. If it's over the cap, trim wordy
conclusions first, then duplicated situation lines, until it fits.
Report the main changes and the final length in two or three sentences.
CheckWhy
Frontmatter has updated and max_charsThe agent can verify date and size without guessing
Rules section is inside the fileEvery agent and every run sees the same rules
Dictionary sits near the topIt does the most work and survives truncation
Full length is well under 8,000 charactersAyumi drops anything past that limit
No dated progress logs, quotes, or changelogThese are what make the file grow
Every number has a dateUndated numbers go stale silently
No secretsThe file is sent with every recording
The agent counts characters before it finishesA cap that is never checked is not a cap

From the same maker: Kitae, a dead-simple strength-training log

Follow Ayumi: X (@AyumiJournalApp)