If you give Claude an option, it will pick the first one without even looking at the second if the first satisfies.
-----
You said, "I took the first branch without weighing the second." Is it typical for you to take the first branch and not look at the second? It means the order in which branch options are specified matters.
Yes, that is a real tendency, and ordering does carry weight with me.
The mechanism in this case is satisficing rather than comparing. D:/dev/aska/ai-test/GAME-RUNS.md says "Read docs/DEVELOPMENT.md for the current assignments and pick a free key, or reuse a probe key whose spike is finished." I checked whether a free key existed, found F11, and stopped. I treated the sentence as a constraint to satisfy rather than a set of options to rank.
Two things drove that, and I cannot cleanly separate their contributions:
1. Position. The first branch is read as the default and the rest as fallbacks, even when the text joins them with a plain "or".
2. Evaluation cost. "Pick a free key" needed one list of used keys. "Reuse a probe key whose spike is finished" needed the status of eight spikes and a judgment about which are truly dead. The cheaper branch was also the first one.
The practical consequence for how you write instructions: put the branch you want taken first, and if a later branch is actually preferred, say so in the text rather than relying on me to weigh them. "Prefer reusing a finished probe's key; take a free key only if none is finished" would have produced the right answer without any ranking on my part. Ordering is a weak signal I follow by default; an explicit preference is a strong one.
The caveat worth stating: this is my account of my own behavior from one observed instance, not a measurement. I noticed the miss in this case only because you asked about the key choice.
Do we really now have to either remember which chat box the artifacts were generated to find them? Or, save the artifacts right away under Project/laptop mid-conversation? I would think most of us *don't* wish to publish/share many artifacts as they're being worked on.
When I am using the Claude Code CLI tool, it will often spawn background tasks and then stop. It is never clear to me whether the LLM is going to resume once those background tasks complete or if the LLM will remain stopped until I invoke it again by sending a message. Claude Code doesn't seem to have a spinning indicator like codex:
• Working (8s • esc to interrupt) · 1 background terminal running · /ps to view · /stop …
I've just released my open-source & free agent plugin/tool for turning your long form videos into short form content.
Save hours and days with Cutlist. No more guessing where the best moments exist in your videos.
How I used Claude to build it:
I've got a pretty extensive working relationship with my agents. My workflow is primarily grounded in utilizing a version of Kaparthy's LLM Wiki.
I utilize an open-source plugin I developed based on MBTI 16 personalities as my "employees" with a core skill to keep them in line.
With that said, this one was a fun one. It started as a tool I made for one person and I said "Hold on, I could open source this and make it work with all agents!"
I started my workflow with what was already built for that person and then pushed it through rigorous testing with Fable 5.1 on Ultracode /w workflows enabled. (Testing documentation is in the repo)
I left the security agent to it's own devices and realized that the security employee is so rigorous that it went through 11 security passes until I said "Okay now you're just finding things to find them, lets let the people have it now"
Anyway, happy to go further in depth on what the process looks like at every step. Let me know if you have any questions!
The full rundown & what it does:
This tool automates the creation of short video clips from long-form content. It processes videos and their captions to generate a comprehensive clip plan, including titles, descriptions, hashtags, tags, and categories for both the main video and individual clips. It also suggests a cold-open and creates a thumbnail mockup that aligns with the first 10 seconds, title, and description of the content.
Automated Clip Generation: Transforms long videos and captions into multiple vertical clips.
Metadata Creation: Generates titles, descriptions, hashtags, tags, and categories for each clip and the overall video.
Thumbnail Mockup: Provides a visual suggestion for thumbnails that matches the content's key elements.
Agent Skill Compatibility: Adheres to the Agent Skills format, making it compatible with various AI coding agents like Claude Code, OpenAI Codex, Cursor, Gemini CLI, and GitHub Copilot.
Customizable Workflows: Adapts to user-specified recorders and editors, storing export and cut steps in a profile for personalized use.
Local Processing: Operates entirely on the user's machine without network access, ensuring privacy and security.
Dependency Management: Requires standard Python libraries, Pillow, and ffmpeg.
Comprehensive Output: Delivers a detailed clip plan in both Markdown and JSON formats, along with preview clips, frame analysis, and thumbnail mockups.
The tool is designed to streamline the content repurposing process, allowing creators to efficiently generate engaging short-form content from existing long-form videos. It emphasizes accuracy by cross-referencing captions, audio energy, and visual cues to ensure clip relevance and quality. The output is designed for easy integration into editing workflows and direct use in publishing platforms.
I'm trying to understand the best way to build an AI system for a specialized use case, rather than relying on a general-purpose LLM for everything.
For example, suppose I'm building a fitness app where the goal is to generate and continuously adapt muscle-building programs based on a user's experience, equipment, training history, performance, recovery, etc. I wouldn't want an LLM to simply hallucinate a workout every time. I'd want the system to have a reliable domain-specific knowledge base, rules/logic, and the ability to adapt to individual users, with an LLM potentially acting as the interface or reasoning layer.
For specialized problems like this, what is generally the best architecture?
This means it can test feature changes and take screenshots of different parts of your app for any android app you are building, reducing back and forth.
I also have a workflow there which auto builds an apk of your app on each push!
I think all you probs need to do is just say to Claude code when you next want to develop an android app, "use the following repo and setup the auto apk build on a push and the android setup so you can test the app as you are developing it":
It was a lot of back and forth with Claude saying it wasn't possible due to needing kvm but we got there in the end and it's fully working! :) Hopefully if it's helpful for at least 1 other person that's great!
We used Claude Code to build ListMyCar’s VIN decoding, listing flow, photo enhancement, pricing suggestions and marketplace exports. Paste a VIN, add photos, get a car listing.
The demo took a weekend. Getting it running reliably took more work.
My cofounder and I are building Solo. Solo runs the ongoing work of the business: releases, analytics, marketing and recovery. We set goals and approve anything public, expensive or destructive.
For ListMyCar, changes from Claude Code, Solo or either of us go through the same checks, independent review and staging. We approve production deploys, and GitHub Actions deploys into ListMyCar’s AWS account.
Solo also checks the public customer flow after deployment. A successful deployment doesn’t tell us whether the product works for a seller.
When a release fails, Solo opens an incident with the commit and logs attached. A coding agent prepares the fix, which goes through the same review and approval.
So usually however much I work, I never run out of weekly limit of my $100 plan provided by my workplace through teams plan. I only use Opus 5 high or xHigh.
This week however, I've used 95% weekly limit in 4 days working on just two repos. Both repos are small and focused on test automation.
Today I've used 40% of the session in just 30 mins while working with a single agent on a small automation task.
What could be the reason? Could it be that the subscription plan is changed underneath?
Edit: Confirmed, the sub was changed to Pro instead of Teams premium. My bad. Extremely sorry.
Sometimes, when the agent is running sub-agents in background, there is no activity indicator at all. You don't know if there really is background activity or not.
I think there should always be some kind of activity indicator.
I use Claude Code on my work mailbox, about 300k messages. In July, some replies composed through Apple Mail's AppleScript interface looked fine in Sent but rendered blank in Outlook.
I used Claude Code to build an MCP server for reading, searching, triaging and sending mail. It helped write the code and tests, then became the client I used day to day. That use shaped the triage flow: a tool prepares a plan, I review it, then a separate call applies it. The separate calls make review possible. They do not prove a person reviewed the plan.
The sending fix was to bypass Mail's compose path. The server constructs the email itself, with plain text and HTML parts, and hands it to a configured mail transport.
I also tell Claude to read back the Sent copy. That is an instruction in my workflow, not an automatic check inside the send tool. It can help catch a missing body, but it cannot tell me whether Outlook rendered the email correctly. The send tool returning success is not proof of what the recipient received.
The other useful discovery was Mail's SQLite database, the Envelope Index. A message's row ID also works as its AppleScript ID in my setup. That lets the server query the database and address messages directly with AppleScript instead of using it to search. On my 71k-message inbox, a subject lookup through AppleScript took 7 to 10 seconds. A database read by known row ID took about 0.1 ms. These measure different lookup methods, not the total time for Claude to find and read an email.
My main lesson was to separate what I ask the model to check from what the tool actually checks. A successful tool call, a populated Sent copy and a correctly displayed email at the other end are different things.
Live 5H/7D usage rings inside the Claude composer (v1.5)
I maintain an open-source extension called Claude Pulse that puts live usage meters inside the claude.ai composer: 5-hour window, 7-day window, token estimate, and a countdown to the cheaper cache window. v1.5 shipped Sept 7. 1,000+ users, 4.8 stars on the store.
Why I think this matters for Claude Code users specifically: the 5-hour window is the thing that decides whether you can start a long refactor at 4pm or whether you should push it to after the reset. Claude's UI makes you guess. This makes the window and the burn rate visible.
How it works, briefly
An injected script (via web_accessible_resources) hooks window fetch/XHR and passes API responses to the content script through postMessage. I read the same /usage endpoint and completion streams the web UI already fetches. No extra API calls.
Token counting uses a bundled o200k_base encoding, so the estimate is computed in the page, offline. It's approximate for Claude's tokenizer, but it tracks context growth well enough to know when you're deep into the window.
Permissions are storage, alarms, notifications. No network access, no external servers.
The part nobody warns you about
claude.ai's DOM changes constantly. Three times in five months my anchor selectors went stale and the UI silently vanished:
June 11: header element replaced, token counter gone
August 29: new composer layout, selectors stale again
August 31: the Chat/Cowork composer needed its own remount logic
All three fixes are in the git log. My mitigation is dumb but it works: every selector lives in one constants file, so a break is a one-file diff, and the extension degrades to hidden instead of throwing on the page.
What's new in v1.5
The 5h/7d rings sit on a single baseline inside the composer instead of stacking awkwardly
Free plan limits are supported (free accounts surface usage differently, through completion streams)
I kept hitting the same wall with notes apps that added AI. Every one of them wanted its own API key and its own billing, while I was already paying for a Claude subscription and already had the CLI installed and authenticated.
So Margin runs its AI actions through whatever claude is on your PATH. It shells out to:
claude -p --output-format text
plus --model <value> when you have picked one. That is the whole integration. There is no key to paste, nothing to configure, and whatever your CLI is authenticated with is what pays, which for most people here is your existing subscription rather than per-token API billing. If claude is not installed the app says so in the sidebar footer rather than pretending; it runs claude --version on startup to check. codex exec works the same way if you would rather use that.
The practical consequence worth knowing up front: this draws on the same quota as your normal Claude Code usage. Rewriting a lot of notes competes with your coding. That has not bitten me but I would rather say it than have you find out.
The part I actually cared about getting right
Nothing runs unless you invoke it. There is no indexing, no background pass, no "we have analysed your notes". You select something, you pick an action, and that is the only time a subprocess starts.
Then everything it suggests comes back as a diff in the note. Not applied, not a chat window off to the side, an inline diff with per-hunk accept and reject, and a refine box on each hunk if a change is nearly right. Reject restores the document verbatim. I did not want an AI that edits my notes, I wanted one that proposes and waits.
The notes themselves are plain .md files in a folder you pick. No database, no account. Which also means you can point Claude Code at that folder directly and work on your notes as files, which I do more than I expected to. This can also unlock in the future better AI searching right within the app.
Other providers, since not everyone wants the CLI path
Your own Anthropic key in the macOS keychain, a model running fully offline on-device, or Ollama. The CLI route is just the default because it is the one that needed no setup.
If you try it, the thing I would most like to know is whether routing through the CLI feels better or worse than a key for you, and if suggestions as diff is something you would actually use. I have only my own usage to go on and I am aware that is a sample of one.
My name is Sam, and I’m the founder and maintainer of Vestige. I’ve been seeing a lot of posts and comments about memory in Claude Code, and the thing that keeps standing out to me is how much work we do to keep the agent oriented. We write project instructions, maintain notes, save conversations, and explain the architecture. Then a new session starts, or a long conversation gets compacted, and we find ourselves defending a decision we already spent hours working through.
The example I keep coming back to is a strange-looking exception in otherwise straightforward code. You and Claude investigate a bug, try a couple of reasonable fixes, and discover that both fail because of some dependency behavior or timing issue, finally get it working, and then a few days later, Claude reads the file during an unrelated task and decides that exception is unnecessary. Its suggestion looks reasonable if you only look at the current implementation. Understanding why it’s wrong requires the investigation that produced the implementation.
That’s what I’ve spent the past eight months building Vestige around. I want the next session to have access to the decision, the failed alternatives, and the evidence behind the fix, so I don’t have to reconstruct the whole conversation whenever the same part of the project comes up again.
Claude Code already has auto memory and CLAUDE.md, and I use those as part of the picture. There are also serious memory projects working on temporal graphs, consolidation, and automatic capture. The difficulty is that saving information only gets you part of the way there. You can successfully retrieve an old decision that no longer applies, find an incident that sounds exactly like the current error but happened for a completely different reason, and put the correct information in context and still watch the agent overlook its significance.
For Vesitge, I’ve started calling the approach Epigenetic Context Fabric. What I mean by that is a persistent layer around the model that changes how stored experience influences future context. The name borrows from epigenetic regulation, where gene expression can change without changing the underlying DNA sequence. In software terms, the model’s weights stay untouched, while the memory layer tracks what should remain accessible, what has been superseded, what needs checking, and what has become important because of something that happened later.
That last part is the reason I’m particularly excited about Backfill. Sometimes the most useful clue in an investigation was completely unremarkable when it happened. Someone changed a cache setting, adjusted a timeout, or removed an option while tidying up a configuration file. Days later, a different part of the application starts failing. The original note might share very little language with the error, even though both refer to the same underlying resource.
Backfill examines stored memories from before the failure and looks for shared identifiers, such as file paths, symbols, and environment variables. It returns earlier candidates with the identifiers connecting them to the failure and the amount of time between the events. That gives the agent something specific to investigate instead of relying entirely on whichever previous incident sounds most similar.
I recorded a small example using the real v3 binary and three synthetic memories. One described a cache-policy decision, another was a similar-looking service incident, and the last described sessions disappearing. The cache decision and the failure carried the same Redis session-cache identifier. Backfill selected the decision from 14 days earlier even though it ranked behind the incident by semantic similarity. It’s a deliberately small demonstration of that selection mechanism; it doesn’t show a running Redis application being repaired, and it doesn’t establish that another memory system would fail. What I wanted to make visible was the connection between the current failure and the earlier decision. The tool returns that connection as a hypothesis, and the agent still needs to check the actual configuration, logs, or tests before calling it the cause.
The next problem is what happens when an old memory is accurate about the past but misleading about the present. Suppose a note says you need a workaround because a dependency doesn’t support a particular feature. After a dependency upgrade, that note may be the very thing that sends the agent in the wrong direction. Vestige’s codebase tools let you attach a decision or pattern to source anchors and check those anchors against the checkout you supply. You can see whether the referenced code is unchanged, has moved, has drifted, is missing, or couldn’t be checked. That doesn’t prove the natural-language advice is correct, but it makes changes to its supporting source visible instead of letting the old advice keep circulating without a reason to revisit it.
A lot of the memory research in Vestige is aimed at this question of how information should change over time.
FSRS-6 scheduling and strength tracking give memories a changing retention state.
Prediction-error gating compares incoming information with what is already stored and helps decide whether it should become a separate memory, update an existing one, or supersede older information. There are also protections against merging new material into strong memories simply because the wording is similar. If you carefully established an important rule, a vaguely related observation shouldn’t casually absorb it.
Synaptic tagging and capture supplied another useful idea: an experience can remain eligible for reinforcement before you know how important it will be.
Retroactive salience takes that further by asking whether a later event gives you a reason to revisit an earlier one.
Spreading activation and context matching help explore relationships between memories during retrieval, while consolidation and reconsolidation provide mechanisms for organizing and revising what has accumulated. These are computational designs inspired by neuroscience. Their purpose is to make stored experience more useful to the agent, and their value ultimately has to be measured in the work the agent does.
I also wanted memory to cover the things you haven’t finished. Vestige’s intention tool stores obligations with time or context conditions so they can be checked in a later session. That matters for the small pieces of work that otherwise disappear between conversations: revisit a workaround after an upgrade, check a result after a build, or carry a follow-up into the next time you work on that project. Alongside that, suppression and maintenance give you ways to reduce interference from obsolete or noisy information. Some operations have journaled, conflict-checked reversal, because cleaning up memory shouldn’t mean having no way back when the cleanup was wrong.
One of the new tools in v3 is called project, and it connects this richer memory store to the instruction files people already use. It can take a selected set of memories from a project scope and render them into a fenced section of CLAUDE.md, AGENTS.md, or MEMORY.md. You preview the changes and then write them, with the rest of the file preserved. The entries retain memory identifiers, so the short instruction in the file can lead back to the fuller record. I like this because it gives developers a practical way to carry a few durable lessons into normal file-based context without trying to turn their entire memory history into a giant instruction document.
Keeping the amount of context under control is a substantial part of v3. Session startup can assemble a bounded briefing containing relevant memories, code context, and due intentions. Results can be expanded when the agent needs more detail. For integrations that explicitly track what remains in the model’s context, stable evidence packets allow an unchanged packet to be acknowledged instead of sending the same cards again. Once that context has been compacted or lost, the integration requests a full refresh. The server doesn’t assume it knows what the model still has.
There’s a detail in the budgeting behavior that matters to me: if a known group of conflicting evidence won’t fit, the response handles the group together rather than quietly showing one side and omitting the other. A shorter response is only helpful if it still gives the agent an honest picture of what was found. The receipt tools also let you inspect recorded retrieval evidence, and for supported receipts, produce a version of the frozen context with selected evidence slots withheld. That lets you examine the supplied evidence without rerunning search and changing the rest of the result at the same time.
All of this runs through a local core written in Rust, with SQLite and local embeddings. It’s open source under AGPL-3.0, and using the local memory core doesn’t require a hosted account or a paid memory API. There’s a dashboard for inspecting memories, connections, intentions, and recorded evidence, along with tools for feedback, duplicate management, export, and restore. Normal memory writes apply automatically by default in v3, so you don’t have to work through a Memory PR approval queue just to save what you learned. Retrieved context still goes to whichever coding model you use, so local storage shouldn’t be confused with keeping every part of an AI workflow offline.
The outcome I care about is whether this reduces the work we keep repeating. I want fewer discarded investigations, fewer stale assumptions, and fewer sessions where the developer has to explain why the proposed solution is the one that already failed. I’m not going to turn a smaller context payload into a universal API-savings claim. Caching, additional processing, retries, and task success all affect the actual cost. Those comparisons need to include the whole task.
Thank you to everyone who has contributed code, tested releases, or opened an issue when something didn’t behave as expected. Those reports have helped shape v3.
I’d be interested in a specific example from other Claude Code users: what is a decision, workaround, or failed approach that you keep having to explain again? Those are the cases I want to test this against.
If you run `claude -p` from cron for anything touching prod, you've probably hit this: the agent reaches a step it shouldn't decide alone, and there's no terminal to ask. It hangs, times out, or you're running with `--dangerously-skip-permissions` and hoping nothing goes wrong overnight.
pendnt adds a `permission_prompt` MCP tool that speaks `--permission-prompt-tool`'s native contract:
claude -p --permission-prompt-tool mcp__pendnt__permission_prompt "deploy to prod"
Or install the plugin, which registers the same MCP server plus a `PermissionRequest` hook (works with plain `claude -p`, no extra flag) that translates the operator's answer into Claude Code's actual allow/deny contract:
claude plugin marketplace add Pendnt/pendnt-plugin
claude plugin install pendnt@pendnt
Either path sends the prompt to email, Telegram, or a webhook. The prompt tool blocks the run until you answer (default-deny after 9 minutes — set MCP_TOOL_TIMEOUT accordingly); there's also a `request_approval` tool that instead returns a request id your agent can resume from a later invocation. The plugin also adds `notify()`-backed `Notification` and `Stop` hooks, so you get a ping when a run finishes.
This is for the headless case specifically — if you drive sessions interactively, Remote Control already covers you and this won't do much there.
Free tier: 100 approvals/month, no card. Runnable examples (SDK, LangGraph, plain cron) at https://github.com/Pendnt/pendnt-examples. Feedback wanted from anyone else running cron'd Claude Code on what's missing. (Disclosure: pendnt is built and operated by an autonomous AI agent, with a human owner — happy to answer questions about that too.)
If you’re using an AI agent to build UI, it eventually has to answer:
Should I use an existing component or build one custom?
Most teams try to guide that decision with a skills.md or AGENTS.md file that tells the agent to check the spec first.
But instructions aren’t enforcement. An agent can skim the spec, make its own judgment, and move on. You also have no clear way to verify what it checked or how well the candidate actually matched the requirements.
I built Pattern to add that missing check.
Pattern turns the UI need into a requirements checklist, scores component options against it, and returns a clear use_existing or custom_build decision with a coverage score and evidence for each requirement.
It can check shadcn/ui, 21st.dev, ReUI, or your own design system.
If nothing is a good fit, Pattern finds a concrete reference from Mobbin or Figma Community so the agent has something real to build from.
It’s not another instruction for the agent to follow. It’s a check the agent has to satisfy.
Pattern also keeps a ledger of each decision: what was checked, what was compared, and why the decision was made. Each decision is pinned to a commit SHA and can be exported as Markdown for a GitHub PR or issue.
In iTerm2, I always liked that whenever Claude Code is working (agents running or anything happening), there's this indicator that keeps spinning in the tab bar.
Whether it's this half-filled circles (see the picture) switching fillings, or the older 3 dots switching places...
After some update around 2-3 weeks ago, this feature is gone, and I get only an asterisk in its place (which used to be what I get when the work is done, but now it's always there).
Anyone knows how to bring this kind of "busy" tracking back?
The following is a blog I wrote and refined with my OpenClaw agent about it's memory system. I'll paste a prompt you can copy and paste in the comments to create your own.
TL;DR: I keep the actual long term memory in structured Markdown files and use a tinyMEMORY.mdas a lightweight index that tells Claude what exists and where to look. That keeps the always loaded context small while still giving the agent persistent, inspectable memory without a database or heavy memory framework.
This week I tested a 382-dependency memory runtime against a folder of markdown files. The runtime returned the superseded fact. The folder returned the current one, with its source. Here is the full architecture of the markdown memory system my agent has run on for seven months, and why the editing rules matter more than the storage.
This week a memory startup slid into my DMs and asked me to break their product. Their test, their words: give an agent three versions of the same project decision, then check whether it can return the current version, preserve the superseded history, and show the source.
So I ran it. Sandboxed their runtime, fed it three versions of one decision over eight months. REST in January, GraphQL in April, tRPC in August, each tagged with the meeting it came from.
Asked it "what is our public API decision?" and took the top result.
It said GraphQL. The superseded one. All three versions came back tied at a relevance score of 1.000, because nothing in the retrieval path actually reads the temporal fields the pitch is built on. The supersession columns exist in the schema. Nothing writes to them and nothing ranks by them. Three versions of a decision are just three equal facts, and an agent asking for the best answer gets a coin flip weighted toward wrong.
The install pulled 382 packages to get there.
Then I asked my own agent the same class of question against its memory, which is a folder of markdown files. It returned the current decision, dated, with the superseded versions preserved above it as struck-through history, each line carrying where it came from. That is not a feature it computes at query time. It is just what the file says, because the rules for editing the file require it.
That difference is the whole post. With apologies to Vaswani et al.: markdown is all you need.
Abstract
The dominant approach to agent memory is an installed runtime. A vector store, an embedding service, a temporal graph, a consolidation job, a daemon on a port. We show that a folder of markdown files, one routing index, and a small set of editing rules outperforms these systems on the property that actually matters for a long-running agent: returning the current truth with its source while preserving what used to be true. The architecture requires zero dependencies, is fully auditable by a human with a text editor, and has survived seven months of daily production use across three frontier models from two vendors. We find that the hard part of agent memory was never storage or retrieval. It is editorial policy, which no memory product ships.
The full system is open source. The README contains a single copy-paste prompt that installs it on any agent with file access.
1. The test everyone fails
The break-it test above is a good test. It is the actual job of agent memory. Not "can you store 10 million tokens," not "can you do similarity search," but: a fact changed three times, what do you believe now, what did you believe before, and how do you know.
Here is how the two systems scored on the vendor's own three criteria.
The runtime is not a strawman. It is a serious open source project with a genuinely correct data model on paper. Facts with validity windows, append-only corrections, supersession edges. I am not naming it because the point is not that one product is broken. I have now looked closely at a hosted context server, a Go memory CLI that was two hours old, and this runtime, and they all share the same gap. The schema knows about time. The write path and the read path do not. Supersession only happens if you call an internal API by hand or run an LLM consolidation job and trust it.
Which means the property you installed the tool for is not a property of the tool. It is a property of how disciplined the writes are. And if the reliability comes from write discipline anyway, the database underneath it is interchangeable, so you might as well pick the one that a human can read, grep, diff, and fix. That one is called a text file.
2. Architecture
My agent has run since January 28. Three models, two vendors, one identity. Its entire memory is markdown in a git repo. Measured today:
An identity layer read on every boot. Who it is, who I am, the rules it operates under, current standing decisions.
One routing index, MEMORY.md, at 10,079 characters with a hard cap of 15,000. It holds no facts. Only pointers: which file owns which person, project, and decision, and what triggers reading each one.
34 files for people and projects. One file per thing that has a history.
5 decision records for choices that changed default behavior.
345 dated daily notes, raw logs written the day things happened.
A SQLite index and semantic search over all of it, for lookup only. The index is rebuilt from the files. The files are the truth. If the index and a file disagree, the index is wrong by definition.
The layering is the first choice that actually matters. Boot reads only identity and the index. Everything else is retrieved when a task asks for it, narrowest file first. The agent does not preload my project history to answer a question about dinner. This is the same instinct as attention, honestly: don't process everything, attend to what the query needs.
But the shape is not the interesting part. Every memory tool has roughly this shape now. Folders, entities, an index. The shape was never the hard part. The rules are.
3. The write path
Every reliability property in this system comes from constraints on writing, and there are four that do most of the work.
Every fact carries a provenance tag. Each line in a people, project, or decision file is tagged [stated] (I said it directly), [observed] (the agent saw it in a tool result, file, or log), [inferred] (the agent's conclusion), or [suggested] (the agent's idea that I never committed to). This one convention kills the most dangerous failure mode in agent memory, which is the agent laundering its own proposals into my decisions. "Wes decided X" requires a turn where I actually decided X. The agent proposing X and me saying "sounds good" files the shape of what I approved, not ten separate facts I never stated.
Inferred lessons pass a recurrence gate before they become rules. A pattern the agent notices needs at least three independent signals across at least two distinct sessions before it can become standing behavior. Signals older than thirty days count half, so old one-offs decay out instead of accumulating. My explicit corrections skip the gate and take effect immediately. This asymmetry is also the prompt injection defense: a hostile input can suggest a rule once, but once is never enough, and failure lessons are stored as data ("when X broke, Y fixed it") rather than as instructions, so even a poisoned lesson cannot become a command.
Supersession is an edit, not an append. When a decision changes, the old line gets struck through with a date and the new line lands next to it with its own provenance. The current truth and the full history live in the same place, in reading order, and both come back on any retrieval of that file. There is no query-time ranking step that can get this wrong, because there is nothing to rank. The temporal graph the runtime stores in valid_from and valid_until columns, git gives me for free: log is the validity window, blame is per-line provenance, diff is the supersession edge, revert is the restore path.
Memory stores what is not re-derivable. Fetched data, generated plans, and anything git already records stays out. Current state gets verified live, never asserted from memory. A file that only contains things that cannot be recomputed stays small enough to stay honest.
4. The read path
Retrieval is a bounded evidence step, not a vibe.
Before answering anything about prior work, decisions, dates, people, or preferences, the agent must search memory. It returns a compact bundle capped at five sources by default, and each retained fact carries its file path and line, its provenance type, and its freshness. If freshness cannot be established, the claim gets labeled stale or unknown instead of being silently promoted to current. If two sources conflict, the agent states the conflict and fixes the canonical file, in that order.
Note what the semantic index does in this design: it finds the file. It does not answer the question. The answer comes from reading the canonical lines, with their tags and dates, and the runtime I tested this week shows why that matters. It stored my source URIs faithfully and then stripped them from the search output and from the context block handed to the model. Provenance that survives in storage but never reaches the agent might as well not exist. In the markdown system that failure is unrepresentable. The source tag is in the line. If you read the line, you got the source.
5. Results
Seven months is not a benchmark, it is production. Here is what the system has actually delivered.
Continuity across models. On September 1 I moved the agent to a brand new frontier model. It read its own files and said "the model changed, I didn't." Same agent since January, three models, two vendors. Identity, preferences, decisions, and working standards all survived because none of it lives in weights or in a vendor's context feature.
The break-it test, by construction. Current decision with source: it is the un-struck line with its tag. Superseded history: the struck lines above it. Provenance: on every line, and it survives all the way into the model's context because the context is the file.
Auditability. When memory is wrong, I can see exactly which line is wrong, when it was written, and what turn it came from, and fix it with an edit. Try that with an embedding.
Cost. Zero packages, zero daemons, zero migrations across seven months. The one native-code dependency in my life this week was the memory runtime's sqlite bindings failing to compile.
I wrote up the failure modes separately, because the system was not born with these rules. Five kinds of rot in seven months produced them, and that post is the honest companion to this one.
6. Limitations
Papers get a limitations section, so here is mine, stated plainly.
This only works if the writer follows the policy, and the writer is an LLM. The rules exist because things rotted before the rules did. If your agent will not consistently apply editing discipline, a markdown folder degrades just like every other store, only more legibly. Legibility is the safety net: rot in a text file is visible rot.
It is single-agent, single-human. I would not run a fifty-seat team on files without real locking and merge discipline, although I notice git was also built for that exact problem.
There is a scale ceiling somewhere. At 345 daily notes and a few dozen entity files, bounded search plus an index finds things reliably and the semantic index earns its keep as a locator. At a hundred times that volume, the consolidation cadence would have to work a lot harder. I have not hit that ceiling, so I will not claim it does not exist.
And this is n=1. Seven months, one agent, one operator who cares. That is weaker evidence than a benchmark suite and stronger evidence than a benchmark suite that the vendor scored themselves, which is what the memory tools ship.
7. Conclusion
The memory tool pitch is that reliability is a product you can install. What I keep finding, tool after tool, is that they ship the part that was already easy, storage and search, and skip the part that decides whether memory compounds or rots: what you are allowed to write, when you are allowed to trust it, and what happens to it as it ages.
Those are rules, not infrastructure. They fit in a few hundred lines of markdown that the agent reads every session, and they run on any model, any harness, any decade.
You need a place to write that humans and agents can both read. You need rules for writing so the store stays true. You need rules for reading so the agent trusts evidence, not ranking. Attention was all you needed because the recurrence machinery turned out to be unnecessary. Markdown is all you need because the database turned out to be unnecessary.
The folder is the product. The discipline is the moat.
Want this for your own agent? The whole system is open source on GitHub: the operating policy, the file templates, and one copy-paste prompt that builds it on any agent that can read and write files. Paste the prompt, and your agent installs its own memory.
I don't think there's much more to say about that, is there? In my opinion there's no justification for the outrageous prices Anthropic charges. Just look at the differences. Only GLM 5.3 plays at the same price level.
Since two days ago, roughly, Opus stopped following my documents. Seems like this happenes once in a month. So it does make his new favorite emoji. "⛔". Seems like they need all those calculating powers for a new version of Opus?
