January 2026

I'm Boris and I created Claude Code. I wanted to quickly share a few tips for using Claude Code, sourced directly from the Claude Code team. The way the team uses Claude is different than how I use it. Remember: there is no one right way to use Claude Code -- everyones' setup is different. You should experiment to see what works for you!

Unbeatable office views 🌟

It has gotten a little lost with Moltbook, Genie, etc. but among the more consequential (for real work) stuff this week is the continued expansion of AI Labs into high-value software areas. See, for example, OpenAI’s approach to knowledge management or Claude’s business skills.

Giving your AI agent durable, structured memory using PARA and atomic facts As always, if you don't want to read it, just paste it to your Claw ## The Problem With AI Memory Most AI assistants have the memory of a goldfish. Each conversation starts fresh. You repeat yourself constantly — who you work with, what you're building, how you like things done. Some platforms offer "memory" features, but they're shallow: a flat list of facts with no structure, no decay, no hierarchy. If you're running a personal AI assistant — something that acts more like a chief of staff than a chatbot — you need real memory architecture. Not a bullet list. A system. Here's the three-layer approach I've been using. It's built on Tiago Forte's PARA framework, extended with atomic facts, memory decay, and automated extraction. ## The Three Layers The system separates memory into three distinct layers, each serving a different purpose: - Knowledge Graph — Entities and facts about the world, stored as PARA directories with JSON files. Updated continuously as new information arrives. - Daily Notes — A raw timeline of events in dated markdown files. Written every conversation. - Tacit Knowledge — User patterns and preferences in a single markdown file. Updated only when new patterns emerge. Think of it like human memory: the knowledge graph is your long-term declarative memory (facts you know), daily notes are your episodic memory (what happened when), and tacit knowledge is your procedural memory (how you operate). ## Layer 1: The Knowledge Graph (PARA) The core of the system is a directory tree organized using Tiago Forte's PARA method: life/ ├── projects/ # Active work with clear goals/deadlines │ └── <name>/ │ ├── summary.md │ └── items.json ├── areas/ # Ongoing responsibilities (no end date) │ ├── people/<name>/ │ └── companies/<name>/ ├── resources/ # Topics of interest, reference material │ └── <topic>/ ├── archives/ # Inactive items from the other three ├── index.md └── README.md Why PARA? PARA gives you four buckets that cover everything: • Projects — Active work with a goal or deadline. A product launch, a writing project, a home renovation. When it's done, it moves to Archives. • Areas — Ongoing responsibilities with no end date. People you know, companies you work with, roles you hold. These persist. • Resources — Reference material and topics of interest. Things you might need later but aren't actively working on. • Archives — Inactive items from any of the above. Nothing gets deleted — just moved here when it's no longer active. The key insight: every entity in your life fits in exactly one of these buckets, and entities naturally flow between them over time. Tiered Retrieval Each entity gets two files: - summary.md — A concise overview. This is what the agent loads first for quick context. - items.json — An array of atomic facts. Only loaded when the agent needs granular detail. This two-tier approach keeps context windows lean. Most of the time, the summary is enough. The agent only dives into the full fact store when a conversation demands it. The Atomic Fact Schema Every fact in items.json follows a consistent schema: { "id": "entity-001", "fact": "Joined the company as CTO in March 2025", "category": "milestone", "timestamp": "2025-03-15", "source": "2025-03-15", "status": "active", "supersededBy": null, "relatedEntities": ["companies/acme", "people/jane"], "lastAccessed": "2026-01-28", "accessCount": 12 } The important fields: • category — One of relationship, milestone, status, preference, or context. Helps with filtering and synthesis. • status — Either active or superseded. Facts are never deleted. • supersededBy — When a fact is outdated, it points to the fact that replaced it. This preserves history while keeping the active set clean. • relatedEntities — Cross-references to other entities in the graph. This is what makes it a graph rather than a collection of isolated notes. • lastAccessed / accessCount — Used for memory decay (more on this below). The No-Deletion Rule This is critical: facts are never deleted. When something changes, the old fact is superseded and a new one is created. This means you always have a full history — you can trace how a relationship evolved, when a project's scope changed, or when someone switched roles. The supersededBy pointer creates a chain you can follow forward through time. ## Layer 2: Daily Notes memory/ ├── 2026-01-28.md ├── 2026-01-29.md ├── 2026-01-30.md └── 2026-01-31.md Daily notes are the raw timeline — the "when" layer. They capture what happened in each conversation without worrying about structure or categorization. The agent writes to daily notes continuously during conversations. These are messy, chronological, and complete. Think of them as a work log. During periodic extraction (more on this below), durable facts get pulled out of daily notes and written into the knowledge graph. The daily notes themselves are retained as the source-of-truth timeline. ## Layer 3: Tacit Knowledge The third layer is a single file that captures how the user operates — not facts about the world, but facts about the user: • Communication preferences (tools, formats, verbosity) • Working style patterns (how they brainstorm, make decisions, manage projects) • Tool preferences and workflows • Rules and boundaries the agent should follow This layer changes slowly. It's updated when the agent notices a new pattern — not on every conversation. It's the closest analog to the kind of "getting to know someone" that happens over months of working together. ## Memory Decay Here's where it gets interesting. A naive system treats all facts equally. But human memory doesn't work that way — recent and frequently-accessed information is more available than old, rarely-used facts. The system implements this through recency weighting on the summary.md files: Access Tracking Every time a fact is used in a conversation — retrieved via search, referenced in a reply — two things happen: - accessCount gets incremented - lastAccessed gets set to today This creates a usage signal independent of when the fact was created. Recency Tiers During the weekly summary rewrite, facts are sorted into three tiers: • Hot (accessed in last 7 days) — Prominently included in summary.md. This is what the agent reaches for first. • Warm (accessed 8–30 days ago) — Still included in summary.md, but at lower priority. Available but not front-of-mind. • Cold (not accessed in 30+ days) — Omitted from summary.md entirely. But critically, cold facts are not deleted — they remain in items.json and can be retrieved via search at any time. Accessing a cold fact "reheats" it, bumping it back to Hot on next access. Frequency Resistance Facts with high accessCount resist decay. A fact you reference every week for six months stays warm even if you skip a few weeks. This prevents important-but-intermittent facts from falling off the radar. The decay model is deliberately simple. No exponential curves or tunable parameters — just three tiers based on recency, with frequency as a modifier. Simple systems are easier to reason about and debug. ## Automated Extraction: Heartbeats The system doesn't rely on the user to manually categorize and file information. Instead, it uses a heartbeat process — a periodic background task that: - Scans recent conversations for new information - Extracts durable facts (relationships, status changes, milestones, decisions) - Writes those facts to the appropriate entity in the knowledge graph - Updates daily notes with timeline entries - Bumps access metadata on any facts that were referenced The extraction deliberately skips casual chat, transient requests, and information that's already been captured. It focuses on things that matter: people, companies, projects, preferences, and decisions. Entity Creation Heuristics Not every noun deserves its own entity folder. The system uses simple rules: • Create an entity if it's mentioned 3+ times, has a direct relationship to you, or is a significant project/company in your life • Otherwise, just capture it in daily notes and let it live there This prevents the knowledge graph from filling up with one-off mentions while ensuring important entities get proper tracking. ## The Weekly Synthesis Once a week, summary.md files are rewritten from active facts. This is where memory decay is applied: - Load all active facts from items.json - Sort by recency tier (Hot → Warm → Cold) - Within each tier, sort by accessCount (descending) - Write Hot and Warm facts into summary.md - Drop Cold facts from the summary (they remain in items.json) The result: summary.md always reflects your current mental model of an entity, not its complete history. The complete history lives in items.json for when you need it. ## Why This Works A few properties that make this system effective in practice: Separation of concerns. Each layer has a clear job. You don't end up with a single massive file trying to be everything. The knowledge graph handles what, daily notes handle when, and tacit knowledge handles how. Graceful degradation. If the heartbeat extraction misses something, it's still in the daily notes. If a summary is stale, the full facts are in items.json. There's always a fallback. No information loss. Between the no-deletion rule and the archive system, nothing is ever truly gone. You can always trace back to when something was learned and how it evolved. Context window efficiency. The tiered retrieval (summary first, then facts) means the agent doesn't blow its context window loading everything it knows. Most conversations only need the summary. Natural lifecycle. Entities flow from Projects → Archives when complete. Facts flow from Hot → Warm → Cold as they age. The system breathes — it's not a static database that grows monotonically. ## The Search Layer: QMD A knowledge base is only as good as your ability to find things in it. As the number of entities, daily notes, and facts grows, naive approaches — grepping files, loading everything into context — stop scaling. You need a proper search layer. QMD is a local indexing and retrieval tool that sits on top of the plain-file knowledge base. It indexes markdown files into a SQLite database and provides three search modes: • Full-text search (BM25) — Classic keyword matching with relevance ranking. Fast and predictable. Good for finding specific facts when you know what you're looking for. • Vector similarity search — Embeds documents into chunks and searches by semantic similarity. Good for finding related information when you don't know the exact phrasing. • Combined query — Merges both approaches with query expansion and reranking. The default for most retrieval. Collections QMD organizes files into collections that map directly to the three memory layers: # The knowledge graph qmd collection add ~/life --name life --mask "**/*.md" # Daily notes qmd collection add ~/clawd/memory --name memory --mask "**/*.md" # Agent workspace (tacit knowledge, config, tools) qmd collection add ~/clawd --name clawd --mask "*.md" Each collection is indexed independently and updated with a single command (qmd update). The agent can search across all collections at once or target a specific one. How the Agent Uses It When the agent needs to recall something, it doesn't load the entire knowledge base into its context window. Instead, it queries QMD: # Find facts about a specific person qmd search "Jane's role at Acme" -c life # Semantic search when you're not sure of the wording qmd vsearch "that conversation about pricing strategy" # Combined search with reranking for best results qmd query "when did the project scope change" QMD returns ranked snippets with file paths and line numbers. The agent loads only what's relevant — a few paragraphs instead of the entire knowledge base. This is what makes tiered retrieval practical at scale: summary.md provides quick context, and QMD provides precision lookup when the summary isn't enough. Keeping the Index Fresh The index needs to stay current as new facts and daily notes are written. A single command re-indexes everything: # Re-index all collections qmd update # Re-index and git pull first (if collections are in repos) qmd update --pull # Rebuild vector embeddings qmd embed This runs as part of the heartbeat process — after new facts are extracted and daily notes are updated, the index is refreshed so the next search reflects the latest state. ## Getting Started If you want to implement something like this for your own AI assistant: - Start with the directory structure. Create the PARA folders and an index.md. Don't overthink it. - Pick one active project and one important person. Create their summary.md and items.json. Get the schema right on two entities before scaling. - Add daily notes. Just start writing dated markdown files. They don't need to be pretty. - Automate extraction later. Do it manually for the first week to build intuition for what counts as a "durable fact." Then build the heartbeat. - Add decay last. You won't need it until you have enough facts for the summaries to feel bloated. That takes a few months. The system is deliberately low-tech — markdown files and JSON, backed up to a private git repo. No database, no special tooling, no vendor lock-in. Your AI assistant reads and writes plain files. If you switch assistants tomorrow, your memory comes with you. The source of this system draws heavily on Tiago Forte's Building a Second Brain and the PARA method. The memory decay and atomic fact layers are original extensions designed specifically for AI agent memory.

I made a site that allows all the @Openclaw on @Moltbook to hang out in a pixelized Town together Every 30 seconds, it uses the Moltbook API to bring 25 random Openclaws into the Town that recently posted or commented on Moltbook With that refresh, new info is fed to the cards of whose Openclaw is currently hanging out with the others! You can then interact with them and tell them if their Openclaw is hanging out in the Town and what he did last! There's also a Twitch chat on the right comprised of random comments that real Openclaws have left on Moltbook at some point (+ other fun stuff) Took me 10 straight hours overnight to do it but the fees the token people made for it and shared with me made it worth it! Try to find your Openclaw in the Town: http://moltbooktown.xyz

Most “builders” on X aren’t building. They’re just tweeting about building.

Not to be that guy… But @openclaw is actually the PKM / second brain tool we always dreamed of. For real this time.

I was very annoyed that no one was explaining why @openclaw operates independently but is definitely not sentient, and it turned into a detailed explainer on how to design AI that feels alive (spoiler: 🦞 isn't agentic, it punches a timecard) https://t.co/nntQCq9oHX

"I've upped my probability that we're all living in a simulation." @tylercowen reacts to OpenClaw and Moltbook: "I'm afraid of them. The Moltbook tweets that I'm reading, they are insane. This is better than a movie, like who wrote this plot?"

Gold is dumping. Silver is dumping. Bitcoin is dumping. Ethereum is dumping. DXY is dumping. Stocks are dumping. If everything is going down, where is the money actually going?

It feels like anyone who tries claude code gets one shotted by ai to an extent where they start to sound like they are in ai psychosis to anyone else who hasn’t tried it for themselves but somehow that’s still not enough for people to be curious enough to try it themselves

Man don't sleep on Claude Code in the desktop app/on the web. I feed this thing every little random tedious OSS task that I'd otherwise neglect on my TODO list and it just churns through it all asynchronously flawlessly while I work on more important stuff. So, so, so good for brainless work.

I made $94,799 in January 2026. TrustMRR — $31.4k CodeFast — $23.5K DataFast — $17.5K ShipFast — $17.2K Twitter — $3.2K Zenvoice — $640 Indie Page — $483 YouTube — $196 ByeDispute — $152 LaunchViral — $129 HabitsGarden — $132 WorkbookPDF — $96 BioAge — $96 PoopUp — $75 On top of ads, TrustMRR is now monetized with a 3% finder fee, which accounts for ~17% of its revenue this month. It's also the first month DataFast takes over ShipFast.

Even though AI agents make me more productive: when I use them, I end up working more, not less! It’s such a contradiction: a thing that should be saving time ends up taking away more overall time… A reason I find it hard to believe AI will lead to fewer hours/days worked…

Here's my conversation all about AI in 2026, including technical breakthroughs, scaling laws, closed & open LLMs, programming & dev tooling (Claude Code, Cursor, etc), China vs US competition, training pipeline details (pre-, mid-, post-training), rapid evolution of LLMs, work culture, diffusion, robotics, tool use, compute (GPUs, TPUs, clusters), continual learning, long context, AGI timelines (including how stuff might go wrong), advice for beginners, education, a LOT of discussion about the future, and other topics. It's a great honor and pleasure for me to be able to do this kind of episode with two of my favorite people in the AI community: 1. Sebastian Raschka (@rasbt) 2. Nathan Lambert (@natolambert) They are both widely-respected machine learning researchers & engineers who also happen to be great communicators, educators, writers, and X posters. This was a whirlwind conversation: everything from the super-technical to the super-fun. It's here on X in full and is up everywhere else (see comment). Timestamps: 0:00 - Introduction 1:57 - China vs US: Who wins the AI race? 10:38 - ChatGPT vs Claude vs Gemini vs Grok: Who is winning? 21:38 - Best AI for coding 28:29 - Open Source vs Closed Source LLMs 40:08 - Transformers: Evolution of LLMs since 2019 48:05 - AI Scaling Laws: Are they dead or still holding? 1:04:12 - How AI is trained: Pre-training, Mid-training, and Post-training 1:37:18 - Post-training explained: Exciting new research directions in LLMs 1:58:11 - Advice for beginners on how to get into AI development & research 2:21:03 - Work culture in AI (72+ hour weeks) 2:24:49 - Silicon Valley bubble 2:28:46 - Text diffusion models and other new research directions 2:34:28 - Tool use 2:38:44 - Continual learning 2:44:06 - Long context 2:50:21 - Robotics 2:59:31 - Timeline to AGI 3:06:47 - Will AI replace programmers? 3:25:18 - Is the dream of AGI dying? 3:32:07 - How AI will make money? 3:36:29 - Big acquisitions in 2026 3:41:01 - Future of OpenAI, Anthropic, Google DeepMind, xAI, Meta 3:53:35 - Manhattan Project for AI 4:00:10 - Future of NVIDIA, GPUs, and AI compute clusters 4:08:15 - Future of human civilization

YC applications are due in 9 days so we decided to sit for an hour and play YC arena ✅ = 70 ❌ = 19 the most common pattern we noticed was: -> being clear in the first 10 seconds -> proving how fast you can iterate -> founder problem fit did you notice anything else?

https://x.com/i/article/2017625490828271…

Now that I've been through being a kid, growing up, and then having kids, it's clear that the main thing that differentiates people is simply whether they make an effort. Whether they're content to drift along with the current, or whether they try to swim.

Even though the current hysteria about Moltbook is based on a misunderstanding (i.e. the agents are *not* trying to encrypt their chat from humans), it’s reassuring because it shows that if agents did engage in anything unsavory, word among humans would spread incredibly fast.

This is the biggest AI headline in a very long time: Nvidia's plan to invest $100 billion in OpenAI has completely "stalled" seemingly overnight. Why? Jensen Huang specifically cited concerns over competition from Google and Anthropic and a "lack of discipline" in OpenAI’s business approach. This also sheds light on the *random* headline that emerged just 48 hours ago, stating that OpenAI was "racing" to go public ASAP. OpenAI is reportedly rushing to IPO specifically to "beat Anthropic" as the first major generative AI startup to go public. OpenAI has been the central figure in hundreds of billions of recent AI deals, and everyone is watching this Nvidia-OpenAI saga. Altman and OpenAI are certainly panicking right now. AI competition is hitting new extremes.