How Instinct's memory works: a reverse-engineering teardown — supermemorySkip to content\nMenuClose****HomeProductBlogChangelogPricingDocsConsoleInstinct is powered by git-tracked markdown filesProfile and memory one-pagerHow are these profiles formed?The files and foldersFile structuresCreating, updating, organizing infoWhen does ingestion even happen?Harness: bringing memory to the agentPerformance of Instinct's memoryImplementing it with supermemoryOther posts
\nBlog·Engineering
\nInstinct keeps its memory as git-tracked markdown files, found with grep rather than vectors. Here is the whole system as far as black-box probing can reconstruct it, and how to rebuild it on supermemory in about 60 lines.
\nBy Dhravya ShahSeptember 20, 2026·9 min read
\nInstinct 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.
\nI've been working on agent memory for the last 3 years, and I'm 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 at the end.
\nBecause 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 (the iMessage interface).
\nThis is gonna be a bit long.
\nAt its 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.
\nThe answering model (likely an open-weights model) receives:
\nConversation messages ────────────────→ Current conversation context\n│ │\n└→ Background processing [unknown] │\n│ │\nAccessible Markdown files │\n│ │ │\nOne-pager generation Search / reads │\n[mechanism unknown] [on demand] │\n│ │ │\n└──────────────┴─────────────────┤\nIdentity profile + todo index + compaction recap ─┤\n↓\nAgent's answer
\n\nCaveat\nWe reconstructed this by a lot of probing with questions, navigating through general assumptions and then trying to verify them. Most of it should be correct, 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, obviously, depends on the conversation).
\nSo let's start there.
\nBlock\nReported contents\nReported size / timing
\nIdentity profile\nName, timezone, account email\nTiny; no timestamp
\nMemory one-pager\nLife context, autonomy calibration, channel communication style\n~4,250 tokens; labeled derived from filesystem memory and updated daily; no generation timestamp
\nActive todos\nIDs, owner markers, titles; details require todo tools\n~25 pending and 7 in progress in this snapshot; no timestamps
\nCompaction recap\nConversation anchors, open loops, exact identifiers, completed work\n~8,750 tokens; this instance covered September 19; labeled written by the agent at compaction
\nSession identifier\nCurrent chat-session identifier\nOne identifier
\nA profile is essentially a gist of what the model always needs to know about the user. Instinct's profile has:
\nThese are the "headers" that Instinct sees.
\n\nPS: supermemory has profiles built in — see user profiles — and has the same learnings. We split it into static and dynamic parts of the profile.
\nThe best-supported reconstruction I could find 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, or learning) model, prompt, scheduling, conflict handling and response to forget requests all remain unknown.
\nA 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.
\nThis profile is also not kept very fresh. In some cases I was able to find a 2-day profile lag, but because there are dates in it, the agent is able to assume that it's not fully trustable.
\n\nIn supermemory, the profiles are formed automatically and always kept fresh.
\nNow 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:
\nLocation\nContents
\nentities/people/\nPeople and their relationships
\nentities/orgs/\nOrganizations
\nknowledge/facts/\nDurable facts
\nknowledge/preferences/\nUser preferences
\nknowledge/decisions/\nDecisions and their context
\ncomms/phone/\nConversation digests
\ntimeline/daily/\nDaily event summaries
\ntimeline/weekly/\nWeekly summaries
\nworkstreams/active/\nOngoing work
\nworkstreams/completed/\nCompleted work
\nI was able to find a lot of redundant, stale or duplicate information, but that likely just helps the agent find the answer better.
\n\nInstinct 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.
\nFiles reportedly use structured headers followed by prose and bullets. This is an illustrative example:
\nid: dining\ntype: preference\naliases: [food, lunch, restaurants, takeout, delivery, dining]
\nA few things stand out from the file structure:
\nSo yes, it's a densely interconnected set of files, and the links make it graph-like.
\nAliases are included — we'll get to why in the harness-specific stuff later.
\nIt seems like the reconciliation commits do more than just append information:
\nRevision\nReported change
\nc12e56c\nMoved pending transfer detail from a person record to a workstream
\n59b7f36\nCompressed narrative and generalized a behavioral example
\n61fb47e\nReplaced literal one-time codes with generic wording
\n7e9e1c2\nReplaced a travel-fee claim with corrective wording
\nOld 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.
\n\nsupermemory's ingestion works in a similar way, and is done by a specialized model. We also automatically include old versions, so the model doesn't have to look for them.
\nInstinct does forget things based on when the ingestion runs, but this is not "automatic" right now.
\nSo 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.
\n\nsupermemory has forgetfulness embedded into the system, so things automatically forget and evolve instead of an agent having to do it.
\nRight now the ingestion works once every 24 hours. I'm assuming this because a preference took approximately 23 hours 16 minutes from message to reported commit. By the way, 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.
\nSo it's likely a cron job running every day to maintain the set of files and edit the current ones.
\nOk, so now we know how Instinct arranges the files. But how is the agent actually using this info?
\nInstinct 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.
\nI found out by running multiple different queries in different ways.
\nQuery\nReported result
\npasta\nDining ranked first
\nItalian noodles I enjoy\nNo hits at limits 5 and 50
\ntakeout\nDining ranked first
\npazta\nNo hits
\nKnown person's name, my gf, romantic partner\nSame person ranked first
\nPerson's name with an extra character\nSame person ranked first
\nInstinct seems to be using bash-like tools to do grep, list and inspect git, plus a few tools to manage its todo list.
\nMemory is read-only, at least for the agent.
\n\nThis is something I'm personally a big believer in. A background process does the work of combining things, not the main agent.
\nIt's hard to benchmark from the agent surface, but here's my vibe-test rubric for Instinct's memory:
\nCapability\nVerdict
\nSingle-fact recall\n✅
\nMulti-hop across sessions\nWeak ☑️
\nTemporal / recency\n✅
\nUpdate & contradiction\n✅
\nAbstention\n✅
\nForgetting / decay\nPartial — automatic forgetting missing, pruning present
\nPerformance at >1M tokens or months\nUntested, but good vibes ☑️
\nProcedural / skill memory\n❌ Not present — none of the memories we could find were directional
\nTest-time learning\n✅ Corrected behavior within conversation; durable learning unverified
\nImplicit personalization\n❌ "Buy me a monitor" should know I'm a founder with a new office, and suggest premium choices
\nExplicit personalization\n✅
\nMultimodal\n❌ Weak — "you know how my room looks, what colored blankets should I buy?"
\nWrite-side cost\n☑️ Likely expensive, but untestable
\nOn write-side cost: we know 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 the personal agent use case, but we're not sure yet.
\nOverall: capable under explicit retrieval instructions, inconsistent in natural personalization, with forgetting guarantees unresolved.
\nReally, really good.
\nThere are some benefits to using supermemory here, and it is actually super obvious to implement.
\nsupermemory is specialized towards memory, so it is much cheaper to run and 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.
\n\n
Below is the full Instinct memory system, in supermemory, working almost exactly like Instinct. Just 60 lines of code.
\nimport { streamText, tool } from "ai";\nimport { openai } from "@ai-sdk/openai";\nimport { withSupermemory, searchMemoriesTool, addMemoryTool } from "@supermemory/tools/ai-sdk";\nimport { z } from "zod";
\nconst API_KEY = process.env.SUPERMEMORY_API_KEY!;\nconst userId = "user_alex"; // containerTag — stable per user\nconst todayId = new Date().toISOString().slice(0, 10); // e.g. "2026-09-20"
\n// 1. Profile injected automatically at the start of every turn (static + dynamic + buckets)\nconst model = withSupermemory(openai("gpt-5"), {\ncontainerTag: userId,\ncustomId: todayId, // one document per day -> ingest every 1-day conversation\nmode: "full", // profile + query search\n});
\n// 2. Dynamic bucket tools: list existing buckets, create new ones on the fly\nconst listBucketsTool = tool({\ndescription: "List the profile buckets configured for this user",\ninputSchema: z.object({}),\nexecute: async () => {\nconst res = await fetch("https://api.supermemory.ai/v4/profile/buckets", {\nmethod: "POST",\nheaders: { Authorization: Bearer ${API_KEY}, "Content-Type": "application/json" },\nbody: JSON.stringify({ containerTag: userId }),\n});\nreturn res.json(); // { buckets: [{ key, description }, ...] }\n},\n});
const createBucketTool = tool({\ndescription: "Create or add a new topical bucket for this user's profile (space-level, additive)",\ninputSchema: z.object({\nkey: z.string().describe("lowercase slug, letters/digits/-/_ only"),\ndescription: z.string().optional(),\n}),\nexecute: async ({ key, description }) => {\nconst res = await fetch(https://api.supermemory.ai/v3/container-tags/${userId}, {\nmethod: "PATCH",\nheaders: { Authorization: Bearer ${API_KEY}, "Content-Type": "application/json" },\nbody: JSON.stringify({ profileBuckets: [{ key, description }] }),\n});\nreturn res.json();\n},\n});
// 3. Search tool with forgotten/history options exposed to the agent\nconst searchTool = searchMemoriesTool(API_KEY, {\ncontainerTag: userId,\n// lets the agent opt into forgotten memories / relationship history when needed\n});
\nconst result = await streamText({\nmodel,\nprompt: "What buckets do we have for me, and what's changed recently?",\ntools: {\nlistBuckets: listBucketsTool,\ncreateBucket: createBucketTool,\nsearchMemories: searchTool,\naddMemory: addMemoryTool(API_KEY, { containerTag: userId }),\n},\n});
\nSo yes — that's how Instinct's memory works, and how you can implement Instinct's memory system with supermemory completely.
\n\n
Memory and continual learning for any model, any harness. Available through our API, plugins, and MCP.\nBuild with supermemory
\nThe default engine for memory and continual learning for agents.\nSan Francisco\nProduct
\nConsole
Company
Talk to sales
Connect
© 2026 supermemory
\nResponsible disclosure
StatusBack to top↑