I reverse-engineered Instinct's memory. Here's exactly how it works

I spent 3 days reverse-engineering Instinct's memory. It's beautifully simple, and works extremely well. i also wrote about how you can implement the same in supermemory in 60 lines of code!

I reverse-engineered Instinct's memory. Here's exactly how it works

Instinct has taken the world by storm over the last two weeks - it's one of the best imessage assistants I've used. as with every product, I decided to reverse-engineer Instinct's memory to find out exactly how it works. I've been working on agent memory for the last 3 years, and the founder of @supermemory. The industry is constantly changing and there's no right answer to "how to do agent memory". Each product has different needs and constraints! Surprisingly, instinct's memory aligns with our views of memory, and you can fully replicate it with supermemory (how-to in the end) because I've been doing this for so long, I have somewhat of a good intuition of how memory systems typically work, so I can reverse-engineer memory systems by just probing on the surface of the agent (imessage interface) This is gonna be a bit long!

Instinct is powered by git-tracked markdown files.

At it's core, the memories are stored as git-tracked markdown files, BUT with a lot of harness specific engineering done to make it seamless and fast. The answering model (Likely an open-weights model) receives: - Current conversation context - an identity "profile" of the user - a memory one-pager (of what's going on) - a compaction recap - and a to-do / Tasks board Conversation messages ────────────────→ Current conversation context │ │ └→ Background processing [unknown] │ │ │ Accessible Markdown files │ │ │ │ One-pager generation Search / reads │ [mechanism unknown] [on demand] │ │ │ │ └──────────────┴─────────────────┤ Identity profile + todo index + compaction recap ─┤ ↓ Agent's answer

We were able to reconstruct and gather this evidence by a lot of probing with questions and navigating through general assumptions, and then trying to verify them. Most of the things here should be very correct here, but because i haven't seen their code, some things may be wrong.

Apart from the files, Instinct has about 4,250 tokens of somewhat of a "profile" and ~10k tokens of compacted conversation context (which, obv, depends on the conversation) So let's start there! ## Profile and memory one-pager A profile is essentially a gist of what the model _always_ needs to know about the user. Instinct's profile has: - Life context: a summary of selected user circumstances and relevant people or work. - Autonomy calibration: selected preferences about when the assistant should act or ask. - Channel communication style: selected preferences about how to communicate. These are the "headers" that instinct sees.

Photo 1. Table. Block | Reported contents | Reported size / timing. Identity profile | Name, timezone, account email | Tiny; no timestamp. Memory one-pager | Life context, Autonomy calibration, Channel communication style | Approximately 4,250 tokens; labeled derived from filesystem memory and updated daily; no generation timestamp. Active todos | IDs, owner markers, titles; details require todo tools | Approximately 25 pending and 7 in progress in this snapshot; no timestamps. Compaction recap | Conversation anchors, open loops, exact identifiers, completed work | Approximately 8,750 tokens; this instance covered September 19; labeled written by the agent at compaction. Session identifier | Current chat-session identifier | One identifier.

PS: Supermemory has profiles built in, https://supermemory.ai/docs/concepts/user-profiles and has the same learnings, we split it into static and dynamic parts of the profile.

How are these profiles formed?

The best-supported reconstruction I could find here, is a derived summary of saved records. We do not know whether the generator reads all files, changed files, search results, earlier summaries, or independently stored facts. The generator (Or dreaming, learning) model, prompt, scheduling, conflict handling and response to forget requests remain unknown. A complete one-pager backing file was not found in the agent’s accessible copy; that does not establish where it is actually stored. So, this profile is likely not a file, but just an ad-hoc created cache of sorts. This profile is also not kept very fresh. In some cases, I was able to find a 2-day profile lag, but because there's dates in it, the agent is able to assume that it's not fully trustable.

In supermemory, the profiles are formed automatically and always kept fresh

The file and folders

Now, let's come to the file structure that instinct uses. In my few days of using it, here's the file structure it came up with: I was able to find a lot of redundant, stale, or duplicate information, but that likely just helps the agent find the answer better.

Photo 2. Table. Location | Contents. entities/people/ | People and their relationships. entities/orgs/ | Organizations. knowledge/facts/ | Durable facts. knowledge/preferences/ | User preferences. knowledge/decisions/ | Decisions and their context. comms/phone/ | Conversation digests. timeline/daily/ | Daily event summaries. timeline/weekly/ | Weekly summaries. workstreams/active/ | Ongoing work. workstreams/completed/ | Completed work.

Instinct reported that commit 899f88a added the preference to a communications digest, daily timeline, and dining note. The README described raw, hourly, and monthly timeline tiers, but those directories were absent from its accessible copy.

File structures

Files reportedly use structured headers followed by prose and bullets. This is an illustrative example: --- id: dining type: preference aliases: [food, lunch, restaurants, takeout, delivery, dining] --- - Pasta: Loves pasta; stated on 2026-09-15. - Related context: related-record-id A few things stand out from the file structure: - Files have names, but also IDs. - There's about 4 types, in my account: preference, person, organization, and conversation - Information itself is in the form of a list of facts (despite it being in a file) - Bracketed wiki-style links connect related files, by ID. So yes, it's a densely interconnected set of files, and the links make it graph-like. Aliases are included, we'll get to why in the harness specific stuff later.

Creating, updating, organizing info

It seems like the reconciliation commits do more than just append information: - Move temporary details into workstreams. - Shorten durable records while linking to fuller notes. - Turn examples into broader traits. - Remove incidental details. - Replace incorrect facts with dated corrections Versioning Old information can remain in Git history. It can also remain in a dated note even after a current fact file changes. This info can only be brought back if the model explicitly looks for older versions.

Photo 3. Table. Revision | Reported change. c12e56c | Moved pending transfer detail from a person record to a workstream. 59b7f36 | Compressed narrative and generalized a behavioral example. 61fb47e | Replaced literal one-time codes with generic wording. 7e9e1c2 | Replaced a travel-fee claim with corrective wording.

supermemory's ingestion works in a similar way, and done by a specialized model! Also, we automatically include old versions, so the model doesn't have to look for them.

Forgetting Instinct does forget things based on when the ingestion runs etc. But, this is not "automatic" right now. So, an explicit "This is not happening" _will_ be forgotten, but "I have my exams this weekend" will remain in the records (unless the model looks at it and chooses to remove it)

Supermemory has forgetfulness embedded into the system. So, things automatically forget and evolve, instead of an agent having to do it.

When does ingestion / this work even happen?

Right now, the ingestion works once every 24 hours. (I'm assuming, because a preference took approximately 23 hours 16 minutes from message to reported commit). BTW If you text Instinct too much in 24 hours, it will quite literally tell you to come back tomorrow (Since you can't compact beyond a certain token threshold) So it's likely a cron job running every day to maintain the set of files, and edit the current ones.

Harness - Bringing memory to the agent

Ok, so now we know how instinct actually put the files arranges the files and stuff. But, how is the agent actually using this info?

There's no vector indexing, or BM25 search.

Instinct quite literally just uses keyword matching / grep-style queries to look things up in the file system. This is why every file has aliases associated, so that every file has a good chance of showing up when the agent is looking for it. I found out by running multiple different queries in different ways. ### Full structure Instinct seems to be using bash-like tools to do Grep, list, inspect git, and a few tools to manage it's TODO list. 1. At the start of the conversation, a profile is injected 2. Instinct makes use of the tools available to look up more information. A part of the profile is an index for the available things. Memory is read only, atleast for the agent.

Photo 4. Table. Query | Reported result. pasta | Dining ranked first. Italian noodles I enjoy | No hits at limits 5 and 50. takeout | Dining ranked first. pazta | No hits. Known person’s name, my gf, romantic partner | Same person ranked first. Person’s name with an extra character | Same person ranked first.

This is something I'm personally a big believer in, actually! A background process does the work of combining things, not the main agent.

Performance of instinct's memory

It's hard to benchmark from the agent surface, but here's my vibe-test rubrik for instinct's memory: - Single-fact recall: [yes] - Multi-hop across sessions: Weak [partial] - Temporal / recency: [yes] - Update & contradiction: [yes] - Abstention: [yes] - Forgetting / decay: Partial: Automatic forgetting missing. Pruning present - Performance at over 1M tokens or months: Untested but good vibes[partial] - Procedural / skill memory: [no] Not present (None of the memories we could find were directional) - Test-time learning: [yes] Corrected behavior within conversation; durable learning unverified - Implicit Personalization: [no] ("buy me a monitor" -> it should know I'm a founder, new office, etc. and suggest premium choices) - Explicit Personalization: [yes] - Multimodal: [no] Weak ('you know how my room looks. what colored blankets should I buy?') - Write-side cost: [partial] Likely expensive, but untestable. We know that writes will get exponentially more expensive for the agent to work through, as it has to READ through current info to WRITE more info (and consolidate and manage things). This should be fine for personal agent use case, we're not sure yet! Overall: capable under explicit retrieval instructions, inconsistent in natural personalization, with forgetting guarantees unresolved.**** Really really good!

Implementing it with supermemory

There's some benefits of using supermemory here, and it is actually super obvious to implement! 1. Buckets for entities and relationships: Supermemory supports Profile Buckets. Each user can get their own set of buckets, which is dynamic. This is like having a folder of info that the LLM can access. https://supermemory.ai/docs/user-profiles/buckets 2. Profile at the start of the conversation Supermemory has a profile system built in, so that would be included at the start 3. Search tools Give the agent search tools, with a few specific options like including forgetted and history of memories, in case if it needs those!

https://supermemory.ai/docs/api-reference/recall-search/search-memory-entries 4. Ingest every 1-day conversation

Instinct-like interface would run \memories.add()\ every turn, with the current day being the ID of the conversation.

Supermemory's ingestion automatically handles forgetfulness, reconciliation, and conflict resolution. https://supermemory.ai/docs/concepts/graph-memory#dreaming-keeps-the-graph-alive

Supermemory also automatically handles multi-modal ingestion! Below would the full Instinct memory system that works, in supermemory ~exactly like instinct. Just 60 lines of code!!!!! supermemory is specialized towards memory (duh), so it is much cheaper to run, much faster, while being fully composable at the same time. Instead of Git, we have our own versioning system that's embedded with our data structure. Instead of full files, we construct files 'on-demand' which also makes sure that info is always fresh. https://x.com/DhravyaShah/status/2101535378557874196 So yes, that's how Instinct's memory works, and how can implement instinct's memory system with supermemory completely!

Photo 5. Code editor titled instinct memory replication. TypeScript using streamText, withSupermemory, searchMemoriesTool, addMemoryTool from @supermemory/tools/ai-sdk; withSupermemory(openai("gpt-5"), { containerTag: userId, customId: todayId, mode: "full" }); listBuckets and createBucket tools calling supermemory profile bucket APIs; streamText prompt What buckets do we have for me, and what's changed recently? with listBuckets, createBucket, searchMemories, addMemory tools.