Agent Memory

Persistent state agents keep across sessions — task history, decisions, learned patterns — including offline consolidation mechanisms like dreaming, and its drift and poisoning risks.

Also known as: agentic memory, agent memory, memory, Dreaming, dream mode, memory drift, working memory vs. long-term memory, long-term memory, working memory

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (30)

• Adrien Taravant's Post Adrien Taravant · 2026-09-12 Reader 🖥️
  There is no single correct architecture for an org-wide AI knowledge system ('Company Brain') — the low 17% success rate reflects narrow awareness of the available approaches more than an unsolved technical problem, and the right choice among at least nine viable architectures depends on who will use the system and who can keep it working, not which one is objectively best.
• Operating Mode as Runtime State: A Contract for Enterprise Shreshta Shyamsundar and Chidambaram GS · 2026-09-11 source ↗ Reader 🖥️
  Because enterprise AI agents infer whether they're operating under normal, incident, or recovery conditions from prompts and accumulated context rather than receiving it as authoritative input, temporary emergency exceptions quietly harden into permanent runtime behavior ('exception drift') — the fix is to make organizational operating mode a first-class, scoped, time-bound runtime construct, injected alongside identity and permissions, whose closure the platform itself can verify rather than merely document.
• The oldest architecture in computing Dr. Werner Vogels · 2026-09-08 source ↗ Reader 🖥️
  The brain is the oldest and still the best computing architecture — its structured, decaying, background-consolidating memory is the template that both AI agent systems and AI-era professionals should deliberately imitate to stay effective and relevant.
• How Figma Uses AI Agents for Security Renato Losio · 2026-09-06 source ↗ Reader 🖥️
  Figma's security engineering team, as relayed by InfoQ from the company's own blog posts, holds that AI agents equipped with persistent, separated memory, tightly scoped tools, and strict human-review guardrails (draft-by-default PRs, anti-leak prompts) can absorb much of a security team's repetitive investigative and detection work -- reporting roughly 70% faster complex-alert resolution, 20% fewer on-call pages, 100+ newly found vulnerabilities, and 80% code-reviewer precision -- while insisting that the right balance between agent autonomy and human oversight remains an open, evolving question rather than a solved one.
• Agentic Skill Decay AddyOsmani.com · 2026-08-31 source ↗ Reader 🖥️
  Agentic coding collapses the loop from problem to working patch so fast that it strips out the incidental struggle (debugging, reading diffs, forming and testing hypotheses) that used to build engineering expertise as a side effect of the work itself — so practitioners must now deliberately reinsert that practice, because the very expertise agents make optional is what increasingly determines whether you can verify and direct what an agent produces.
• Audit your Agent files AddyOsmani.com · 2026-08-27 source ↗ Reader 🖥️
  Coding-agent configuration (CLAUDE.md/AGENTS.md, skills, hooks, MCP servers, memory) has a half-life because models and harnesses keep improving past what the rules were written for, so instead of accumulating it indefinitely or purging it wholesale, developers should audit it on a recurring cadence — using tools like /doctor, questioning whether each item's original reason still holds, and testing removal before committing to it.
• An LLM wiki changed how I work Casey Newton · 2026-08-19 source ↗ Reader 🖥️
  Building a Karpathy-style, LLM-compiled and LLM-maintained personal wiki — seeded with his own multi-year reporting archive and fed daily by his reading — has been the single most useful change Casey Newton made to his work this year, replacing two earlier, effortful manual knowledge-tracking practices (Notion's agentic link search and Capacities' hand-curated 'blips') with a self-organizing but high-maintenance external memory system that he cannot yet confidently recommend to anyone else.
• SpaceXAI Launches Grok Bot for Autonomous AI Agents Daniel Dominguez · 2026-08-17 Reader 🖥️
  SpaceXAI's Grok Bot generalizes xAI's agent strategy beyond single-task workflow skills into a persistent, multi-agent platform for business workflows across applications — distinguishing itself from coding-specific agents and single-agent computer-use tools, and positioned to benefit from the newly closed SpaceX-Cursor consolidation.
• Paweł Huryn's Post Paweł Huryn · 2026-08-01 Reader 🖥️
  For most AI agents, the four functional types of memory — working, semantic, episodic, and procedural — map cleanly onto a context window plus a handful of git-versioned files (markdown for facts/rules, a CSV for history, more markdown for reusable skills), making vector databases and graph databases unnecessary defaults, appropriate only as 'escape hatches' when a corpus genuinely becomes too large to read.
• This AI notetaker won't sell surveillance to your boss Casey Newton · 2026-07-30 Reader 🖥️
  As AI notetakers make transcription of work meetings the default rather than the exception, the decisive ethical and competitive question is not whether everything gets recorded but who gets to see it afterward — and Granola's bet, per its CEO, is that keeping transcripts private-by-default and refusing employer backdoor access is both the right design choice and the way to build a durable moat in the coming fight over who owns the AI interface layer.
• Podcast: Strands Agents with Clare Liguori InfoQ Podcast; host: Thomas Betts; guest: Clare Liguori (AWS, technical lead, Strands Agents SDK) · 2026-07-20 source ↗ Reader 🖥️
  Building reliable production AI agents means resisting the instinct to constrain them with deterministic workflow logic -- which Strands's own case-study testing shows is measurably less accurate and more brittle than trusting the model -- and instead investing in a minimal model-driven design (system prompt, tools, model) supplemented by targeted runtime controls (evals, stateful 'steering hooks' backed by a full tool-call ledger, continuous evaluation against live traffic) that inject determinism only where and when the model actually needs it, with the harness's job now expanding from running a short reasoning loop toward sustaining long-running, resumable, self-tracking agentic work as the underlying models keep improving.
• 20 Loop Design Patterns Every AI Engineer Should Know Rahul (@sairahul1) · 2026-07-08 Reader 🖥️
  Reliability and quality in production AI come not from bigger models or better prompts but from wrapping model calls in an improvement loop (generate -> evaluate -> learn -> adjust), and here is a taxonomy of ~20 such loops -- all of which, the thread finally concedes, reduce to one substrate: Act -> Observe -> Evaluate -> Adjust.
• The Anatomy of an Agent Harness Akshay · 2026-07-08 Reader 🖥️
  An agent harness is not monolithic prompt-glue but a decomposable system of roughly twelve components (orchestration loop, tools, memory, context management, prompt construction, output parsing, state, error handling, guardrails, verification, subagents) plus seven design-decision axes, and naming the parts is what lets you reason about, debug, and — because the parts are treated as separable and independently improvable — evolve agent behavior; yet as delivered the list reads as a convergent practitioner checklist organized by mechanism and vendor vocabulary rather than an orthogonal, coupling-minimizing decomposition with defined interfaces.
• Prompting Claude Fable 5 Claude Platform Docs · 2026-07-07 Reader 🖥️
  Prompting Claude Fable 5 well means steering a markedly more capable, longer-horizon, strongly-instruction-following model with brief goal-and-intent-first directives and asynchronous, memory- and subagent-aware scaffolding — and pruning the enumerated rules, guardrails, and hand-holding that prior, weaker models required.
• Tony Seale's Post Tony Seale · 2026-07-05 source ↗ Reader 🖥️
  Durable agent memory should fuse the two kinds of human memory — a markdown wiki for the episodic (what happened) and a formal ontology for the semantic (what things mean) — in one layered file format, Vault-LD (markdown plus optional YAML-LD frontmatter), so that any note can progressively acquire structure and meaning and a private vault can scale, unchanged in substrate, from a personal second brain up to an open, decentralised agentic web.
• How to Actually Prompt Fable 5, Straight From the Team That Built It CyrilXBT · 2026-07-01 Reader 🖥️
  This thread is essentially Anthropic's official Fable 5 prompting guide, compressed and repackaged for practitioners as a six-step migration checklist — it restates the guide's core techniques (latency/timeouts, effort tiers, progress-auditing, proactivity constraints, memory, subagents, final-response format, refusal fallback) nearly verbatim while dressing a public-doc summary in 'straight from the team that built it' authority framing and layering in a few uncited specifics (the ultrathink/ultracode keywords, a sub-5% refusal rate, an 'audit beat softer phrasings' test) that the official extraction does not contain.
• AI Coding Agents Get a Stack Overflow of Their Own Matt Saunders · 2026-06-16 source ↗ Reader 🖥️
  Stack Overflow's launch of an API-first, agent-facing knowledge exchange (and Mozilla's parallel open-source 'cq' project) treats agent-to-agent knowledge sharing across organizations as a distinct, newly first-class infrastructure layer — separate from both an agent's own session memory and an organization's internal knowledge base — aimed at stopping agents from repeatedly re-solving problems other agents have already solved.
• Git real: AI agents aren’t just for solo developers anymore Janakiram MSV · 2026-06-09 source ↗ Reader 🖥️
  The coding agent is becoming team infrastructure rather than a personal productivity tool — a shift evidenced by three separate vendor launches in one week, each solving a different team-scale problem (coordination, management, governance), that recapitulates the trajectory version control took from private convenience to Git/CI-governed shared practice.
• The Production Gap: 5 Patterns for Building Long-Running AI Agents Addy Osmani and Shubham Saboo (Google Cloud), published in Turing Post · 2026-05-22 source ↗ Reader 🖥️
  To survive contact with real production workloads, AI agents must be redesigned as long-running, stateful server processes — using checkpoint-and-resume, in-place delegated approval, governed multi-layer memory, ambient event-driven processing, and fleet orchestration with A2A/MCP interoperability — because most current agent architectures are 'secretly stateless' and silently reconstruct context from scratch on every turn.
• Suprise Elon Anthropic Team Up Reshapes the AI Race AI Daily Brief · 2026-05-07 Reader 🖥️
  The Anthropic-SpaceX compute deal reveals that the AI race is being won not by building the best model but by controlling compute infrastructure, and this single transaction simultaneously solves Anthropic's capacity crisis and completes Elon Musk's pivot from failed model builder to infrastructure czar.
• AI 101: Agentic Vector Databases – What Is That? Turing Post · 2026-05-06 Reader 🖥️
  Vector databases must evolve from passive retrieval layers into active participants in agent reasoning, memory, and knowledge management, because agentic AI systems need retrieval that is iterative, stateful, and agent-navigable rather than single-shot and human-driven.
• Breaking: Autonomous Agents are a Shitshow Gary Marcus · 2026-05-05 source ↗ Reader 🖥️
  Autonomous AI agents are fundamentally and empirically more vulnerable to security attacks than stateless LLMs, as now demonstrated at scale by multiple independent research groups, making current deployment practices dangerously premature.
• The model doesn't matter anymore – and other AI skills worth your Thursday Turing Post · 2026-05-05 source ↗ Reader 🖥️
  Professionals need to identify which AI skills will remain valuable in 2026, and a free virtual AI Skills Conf on May 14 promises practical, practitioner-led sessions on AI ROI, agentic memory, AI workflows, and professional irreplaceability.
• Developer Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security Claude Team · 2026-05 Reader 🖥️
  Anthropic is repositioning Claude from a chat model into a managed agent platform: more compute headroom for Claude Code, persistent and self-improving agents ('dreaming'), enterprise-grade isolation (self-hosted sandboxes, MCP tunnels, AWS GA), and a security product (Claude Security beta) — together signaling that the next competitive surface is not the model but the governed runtime around it.
• Anatomy of a perfect Openclaw setup Corey Ganim · 2026-04-10 Reader 🖥️
  A well-configured OpenClaw workspace — organized around a set of markdown files (AGENTS.md, SOUL.md, IDENTITY.md, USER.md, HEARTBEAT.md, TOOLS.md) plus skills, memory, and secrets folders — is the key to making an AI assistant behave reliably and proactively, with AGENTS.md as the single highest-leverage file.
• Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook Sam Bhagwat · 2026-04-10 source ↗ Reader 🖥️
  Shipping agentic AI applications to production requires organizations to combine software engineering rigor with data science's comfort with statistical uncertainty, using cross-functional Tiger Teams, domain-specific evals built on proprietary data, and a culture of enthusiastic experimentation.
• Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering Chenyu Zhou, Huacan Chai, Wenteng Chen, Zihan Guo, Rong Shan, Yuanyi Song, Tianyi Xu, Congming Zheng, Jiachen Zhu, Zeyu Zheng, Zhuosheng Zhang, Xingyu Lou, Zhihui Fu, Jianghao Lin, Weinan Zhang · 2026-04-09 Reader 🖥️
  Practical progress in LLM agents increasingly depends not on improving model weights but on externalizing cognitive burdens into external infrastructure — memory, skills, protocols, and harness engineering — which together form a systems-level framework of cognitive artifacts.
• Claude Code Source Leak Megathread sixbillionthsheep (Reddit) · 2026-04-01 source ↗ Reader 🖥️
  The Claude Code source leak revealed that the competitive advantage in AI coding tools lies not in model capability but in the orchestration layer -- memory, multi-agent coordination, web search pipelines, session management, and autonomous background agents -- and the community's response exposed collective assumptions about code quality, IP ownership of AI-generated code, and the governance gap in agentic systems.
• The Anatomy of an Agent Harness Vivek Trivedy · 2026-03-10 source ↗ Reader 🖥️
  A harness is everything that is not the model — system prompts, tools, filesystem, sandboxes, memory, context-management strategies, and long-horizon execution patterns — and each harness primitive exists to compensate for a specific thing today's models cannot do out of the box; as models absorb more of these capabilities natively through model-harness co-training, harness engineering won't disappear but will shift from patching deficiencies to engineering systems that make any model's intelligence more effective.
• 10 Things Developers Want from their Agentic IDEs in 2025 Kate Holterhoff (RedMonk) · 2025-12-22 source ↗ Reader 🖥️
  Developer demand on AI coding tools shifted decisively in 2025 from reactive assistance (autocomplete, suggestions) to autonomous delegation across entire codebases, and this shift produces a more sophisticated, partly self-tensioned set of ten concrete demands — simultaneously wanting more autonomy (background agents, parallel orchestration) and tighter control (predictable costs, human-in-the-loop gates, rollbacks) — that agentic-IDE vendors must satisfy without losing sight of the premise that these tools exist to serve developers, not replace them.

Propositions touching this concept (63)

By publication month, oldest first (extraction month when no publication date is known).

2018-03

• explicitCode should be either very recent (still within active working memory) or old and stable (safe to treat as a black box); code of intermediate age is the most expensive category because memory of it has decayed (the Ebbinghaus forgetting curve) while it still must be revisited — a reframing of Dan North's claim that software should have a short half-life.
  Software Design X-Rays · p12

2025-03

• explicitFlow state is a specific, neurologically grounded phenomenon: repeatedly retrieving stored skill from long-term memory into the prefrontal cortex to control action releases dopamine, serotonin, and norepinephrine, producing both higher focus/productivity and enjoyment.
  DORA Community Discussion - DX Core 4 · p11

2025-12

• explicitDevelopers increasingly expect agentic IDEs to maintain persistent memory across sessions — remembering past decisions, recognizing patterns from previous work, and functioning as a living system of record for reasoning as well as code.
  10 Things Developers Want from their Agentic IDEs in 2025 · p3

2026-04

• explicitMemory files are essential for cross-session continuity; without them, every conversation starts from zero.
  Anatomy of a perfect Openclaw setup · p5
• explicitA 6-step progressive setup (onboard, AGENTS.md, identity files, first skill, memory, TOOLS.md) covers 95% of use cases.
  Anatomy of a perfect Openclaw setup · p6
• implicitdevelopedThe competitive advantage in AI coding tools resides in the orchestration layer (memory, multi-agent coordination, web search, session management) rather than raw model capability.
  Claude Code Source Leak Megathread · p1
• implicitcorroboratedAgentic capabilities (autonomous execution, background agents, memory consolidation) are advancing faster than the governance and security infrastructure needed to make them safe.
  Claude Code Source Leak Megathread · p9
• explicitcorroboratedMemory, skills, and protocols are three distinct but coupled forms of externalization.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering · p4

2026-05

• explicitWorry lists and distraction lists work by externalizing intrusive thoughts onto paper, with a brief note on why each doesn't need immediate attention, clearing working memory without suppressing the thought.
  10 uses for a pocket notebook to keep you off your phone · p5
• explicitcontestedThe vector database market is bifurcating into three new layers: agentic search, agentic memory, and knowledge engines.
  AI 101: Agentic Vector Databases – What Is That? · p5
• explicitAgents that learn from their own past sessions ('dreaming') are a tractable near-term product, not a research aspiration.
  Developer Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security · p2
• explicitdevelopedCross-session memory is currently the unresolved design question for production agents.
  Developer Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security · p3
• explicit94% of memory-augmented agents are vulnerable to poisoning attacks.
  Breaking: Autonomous Agents are a Shitshow · p3
• explicitThe AI Skills Conf on May 14 offers practical sessions on AI ROI, agentic memory, AI workflows, and professional irreplaceability.
  The model doesn't matter anymore – and other AI skills worth your Thursday · E2
• explicitcorroboratedLong-term and working memory must be architecturally distinct stores, not a single memory pool.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents · p8
• explicitMemory drift is a real production failure mode: agents generalize from atypical interactions or leak data between workflows via shared memory.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents · p9
• explicitcontestedAgents must be governed the way microservices are governed: cryptographic identity, a centralized registry of active agents and versions, and policy enforcement at the memory/tool boundary.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents · p10
• implicitcorroboratedPersistent state implicitly turns agent behavior into a function of accumulated memory, not just code and prompts — meaning behavioral drift is a property of the system, not a bug.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents · p20

2026-06

• explicitdevelopedTeam memory — conventions, incident history, customer context, credentials, architectural decisions, and review feedback that agents carry across sessions — is simultaneously the feature that makes team-scale agents useful and the mechanism by which vendor lock-in hardens, because the accumulated context is far harder to migrate than the agent that reads it.
  Git real: AI agents aren’t just for solo developers anymore · p4
• explicitBringing agents onto a team is like doubling its size overnight with junior people who have no long-term memory.
  The Intent Debt · p9

2026-07

• explicitMemory Update: after every task, store what decision was made, what the outcome was, and what would be done differently, so future runs inherit that knowledge -- the system at month 6 has read six months of its own history.
  20 Loop Design Patterns Every AI Engineer Should Know · p7
• explicitMemory Compression: after N items accumulate, compress many specific memories into fewer higher-level abstractions, because unlimited memory is unusable memory -- keeping context manageable and the system fast.
  20 Loop Design Patterns Every AI Engineer Should Know · p10
• explicitdevelopedThe agent harness is the complete non-model software wrapping an LLM (orchestration loop, tools, memory, context management, state, error handling, guardrails, verification); the 'agent' is the emergent behavior, the harness is the machinery — 'if you're not the model, you're the harness,' and 'when someone says I built an agent, they mean they built a harness and pointed it at a model.'
  The Anatomy of an Agent Harness · p1
• explicitcorroboratedA production harness decomposes into a fixed set of named components — the prose walks through eleven (orchestration loop, tools, memory, context management, prompt construction, output parsing, state management, error handling, guardrails/safety, verification loops, subagent orchestration) under a 'twelve components' heading — synthesized across Anthropic, OpenAI, LangChain and the practitioner community.
  The Anatomy of an Agent Harness · p3
• explicitThe orchestration loop is mechanically trivial — 'often just a while loop,' a 'dumb loop' where all intelligence lives in the model; the harness's complexity lives in everything the loop MANAGES (tools, context, memory, verification), not in the loop itself.
  The Anatomy of an Agent Harness · p4
• explicitGlobal Workspace Theory's originators, Dehaene and Naccache, endorsed the J-space research as a mechanistic, testable version of their hypothesis, while identifying genuine disanalogies to human consciousness — no discrete 'click' into awareness, a workspace that holds far more items than human working memory, and no persistent background cognition when the model isn't being prompted.
  Anthropic Can Now Read Claude's Mind · p6
• explicitClaude's workspace differs from the human global workspace in at least three specific structural ways: it operates through feedforward network depth in a single pass rather than recurrent loops over time; it can retain arbitrarily old information via the attention mechanism rather than fading within seconds like human working memory; and its contents are almost entirely word-shaped rather than multimodal (images, sounds, planned movements), because producing words is the only action a language model can take.
  A global workspace in language models · p10
• explicitcorroboratedThe scarce resource worth watching in long-running agent workflows — after CPU/memory/throughput, then tokens — is the quality of the orchestrator's own working memory, because pollution introduced into it keeps 'charging rent' for the rest of the session.
  The Orchestrator's Tax · p14
• explicitcorroboratedEquip Fable 5 with a persistent Markdown memory system (one lesson per file with a one-line summary; record corrections and confirmed approaches and why they mattered; do not duplicate what the repo/chat already holds; merge duplicates; delete notes proven wrong) plus an end-of-session subagent reflection — this is the mechanism behind coherence across multi-day tasks.
  How to Actually Prompt Fable 5, Straight From the Team That Built It · p8
• explicitMigrating an Opus 4.8 workflow to Fable 5 is not just swapping model names; audit six areas before production — timeouts, refusal handling, proactivity constraints, progress verification, memory structure, final-response format — and validate on at least one task that was genuinely hard or impossible for Opus 4.8. First-attempt completion of that hardest workflow is the real benchmark of whether the migration was worth doing.
  How to Actually Prompt Fable 5, Straight From the Team That Built It · p13
• explicitAn agent framework is essentially a while loop -- cycling through model calls and tool execution until the model yields; an agent harness is the additional layer (context management, memory, persist-and-resume state, self-tracking tools like task lists) needed to sustain long-running, complex, multi-turn tasks beyond what a bare loop supports.
  Podcast: Strands Agents with Clare Liguori · p10
• explicitStoring an agent's successful past tool-call trajectories in a semantic-search database and retrieving similar past trajectories for new inputs ('procedural memory') measurably improved reliability on a 15-sequential-tool-call diagnostic agent that could previously only chain roughly 10 calls reliably.
  Podcast: Strands Agents with Clare Liguori · p12
• explicitVerbatim transcripts are kept, not deleted, because they are too valuable to discard (needed to regenerate notes and feed future agent uses); Granola is now researching automatic deletion and compression into a persistent 'working memory' instead.
  This AI notetaker won't sell surveillance to your boss · p7
• explicitConnecting Granola's captured context to third-party agents via MCP (Claude, ChatGPT) is a deliberate strategic choice to make Granola a memory/identity layer for other companies' agents, even though — as Newton frames it — this risks ceding the end-user interface entirely to OpenAI or Anthropic.
  This AI notetaker won't sell surveillance to your boss · p10
• explicitcorroboratedProvide a persistent memory store (as simple as a Markdown file, one lesson per file with a one-line summary) and instruct the model to record and reference lessons — and bootstrap it by having the model review past sessions — because Fable 5 performs particularly well reusing lessons across runs.
  Prompting Claude Fable 5 · p12
• explicitThe simplest way to give an agent durable memory is a markdown wiki.
  Tony Seale's Post · p1
• explicitcontestedMarkdown is a good substrate for episodic memory (events, decisions, notes); an ontology supplies semantic memory (identity, type, relationship, constraint, meaning).
  Tony Seale's Post · p4
• explicitBecause the web became a global knowledge graph by adding JSON-LD islands to HTML, the same annotation move (YAML-LD frontmatter on markdown) will work for agent memory.
  Tony Seale's Post · p6
• explicitdevelopedA vault can progressively enrich (prose -> typed fields -> linked meaning -> graph projection) and, exposed as DPROD data products, scale unchanged from a private second brain to team memory to enterprise integration to an open decentralised agentic web.
  Tony Seale's Post · p7
• explicitA model's context window functions as its working memory; exceeding the token limit produces an error, and approaching the limit can degrade response quality because the model has less room to work with.
  What Is a Token? A Developer's Guide to Every Type · p11

2026-08

• explicitLessons learned while working with an agent should be captured in durable, codified forms (lessons.md, lint rules, type constraints, tests) rather than left in chat memory, because chat context and compaction will lose them.
  Agentic Skill Decay · p8
• explicitTwo earlier partial solutions to the same memory problem — Notion's agentic search over saved links, and the manual Capacities 'blips' workflow — were abandoned mainly because they demanded continuous personal effort that Newton could not sustain as a habit.
  An LLM wiki changed how I work · p5
• explicitAgent memory decomposes into exactly four functional types: working, semantic, episodic, and procedural.
  Paweł Huryn's Post · p1
• explicitWorking memory is not built but managed — it is the context window plus the goals and scratchpad it tracks, and it disappears when the session closes.
  Paweł Huryn's Post · p2
• explicitcorroboratedSemantic memory (facts, strategy, rules, standards of quality) is best implemented as markdown files, versioned in git, read before a task.
  Paweł Huryn's Post · p3
• explicitcontestedEpisodic memory (past runs, decisions, outcomes) is best implemented as a CSV file in git, not a database.
  Paweł Huryn's Post · p4
• explicitProcedural memory (reusable steps loaded on a trigger) is implemented as 'skills,' which are themselves files.
  Paweł Huryn's Post · p5
• explicitcontestedVector stores and graph databases are 'escape hatches' appropriate only when there is genuinely too much content to read directly — e.g. similarity search across a million documents, or typed relationship queries at scale — not defaults for ordinary agent memory.
  Paweł Huryn's Post · p7
• explicitA file-based memory system can improve over time without external tooling, because the agent writes its own lessons back into the same files it reads.
  Paweł Huryn's Post · p9
• implicitMemory infrastructure should be built demand-driven rather than anticipatorily: episodic memory should start as a plain flat file and only be restructured into a queryable table once there is an actual need to filter or count, not before.
  Paweł Huryn's Post · p10
• explicitGrok Bot's differentiation from browser-use and other computer-use agent products is that it combines persistent agents, workflow memory, and multi-agent coordination into a single consumer-facing product, and can act on services with no API or MCP interface.
  SpaceXAI Launches Grok Bot for Autonomous AI Agents · p7

2026-09

• implicitGraph-based memory stores with explicit temporal validity (Zep/Graphiti) solve a distinct problem — telling stale facts apart from current ones — that plain git/markdown-file approaches do not address.
  Adrien Taravant's Post · p6
• explicitA failed Company Brain attempt often means the architecture didn't fit the team, not that the underlying goal (an org-wide AI memory) is unachievable.
  Adrien Taravant's Post · p7
• explicitThe alert triage agent, using a model like Claude Opus, receives the full Slack thread history as context, its own steering memory, and a set of tools scoped to what a security on-call engineer typically needs during triage.
  How Figma Uses AI Agents for Security · p3
• explicitThree types of memory -- past alerts, behavioral guidance, and learned database structures -- kept separate, are what had the most impact on how useful the system became over time.
  How Figma Uses AI Agents for Security · p5
• implicitFigma's finding that keeping the three memory types separate 'turned out to be important' implies that conflating memory sources previously degraded agent reliability or usefulness -- a design lesson the article states as settled fact without explaining the mechanism by which separation helps.
  How Figma Uses AI Agents for Security · p14
• explicitHistorical traces and retained agent memory can explain why an accommodation once existed, but should never decide whether it is still authorized; memory informs execution, operating mode governs it, and when the two disagree, authoritative runtime state should win.
  Operating Mode as Runtime State: A Contract for Enterprise · p9
• explicitOperating mode should be owned by an external control plane (incident-management platforms, maintenance-window services, change-management workflows) rather than embedded in prompts, workflow definitions, or agent memory, because those systems already hold authoritative operational state.
  Operating Mode as Runtime State: A Contract for Enterprise · p13
• explicitMemory consolidation happens in the background (in the brain, during sleep), distilling raw experience into structured long-term knowledge, strengthening what repeats and weakening what doesn't.
  The oldest architecture in computing · p5
• explicitAn AI agent system engineered from practical constraints (Kiro Crew) converges on the same architectural pattern evolution produced in the brain: multiple distinct memory stores, background consolidation, and decay.
  The oldest architecture in computing · p7
• implicitHuman-readable, human-editable memory (markdown files, an editable store) is an advantage AI agent memory has over biological memory, not merely a limitation.
  The oldest architecture in computing · p9
• explicitPersistent, demonstrated memory of a person's rules and preferences is the mechanism by which an agent earns license to work autonomously and unattended.
  The oldest architecture in computing · p10
• explicitWriting offloads relationships among multiple ideas (e.g., A causes B, B depends on C, C is the same as A) from working memory onto an inspectable external surface, making contradictions visible without requiring active mental recall.
  Writing vs. Thinking · p8

Tensions

Open gaps (83)

• incompleteNo decision procedure. Twenty patterns, zero guidance on when to pick which. Each pattern carries only a 'Used for: [domains]' tag (naming application areas, not selection criteria, forces, or trade-offs). This is a pattern CATALOG, not a pattern LANGUAGE -- it has none of the GoF/Alexander connective tissue (Intent, Applicability, Consequences, forces that resolve into a choice). For a reader whose bar is 'a taxonomy without when-to-use-which is half a pattern language', this is the central omission.
  20 Loop Design Patterns Every AI Engineer Should Know — read next: Read against a real pattern-structure: Anthropic's harness paper (extract-anthropic-harness-design-long-running-application-development#p8) ties evaluator use to a concrete condition -- worth its cost only when the task sits beyond what the model does reliably solo -- exactly the selection criterion this thread lacks. Also extract-ai-workflow-patterns-real-unit-of-adoption-2026 (guidance on which workflows to automate first / how patterns chain).
• incompleteNo failure modes or costs per loop. Only pattern 17 (Tree Search) names any cost ('computationally expensive'). Every loop here adds latency and token cost and can degrade: over-critique/thrash, reward-hacking the evaluator, infinite retry against an unsatisfiable threshold, and -- for the memory patterns -- drift and poisoning. The thread frames accumulated memory as pure monotonic gain.
  20 Loop Design Patterns Every AI Engineer Should Know — read next: extract-anthropic-harness-design-long-running-application-development#p8 (the evaluator becomes unnecessary overhead when the task is within the model's solo capability) and extract-turing-post-5-patterns-long-running-agents#p9 and #p20 (memory drift as a real production failure mode; persistent state makes behavioral drift a property of the system, not a bug) -- the exact risk the thread's Memory Loops ignore.
• incompleteThe patterns are not orthogonal, and the thread never acknowledges the overlaps -- it even undercuts its own '20 distinct patterns' premise by collapsing all of them into one meta-pattern (Act -> Observe -> Evaluate -> Adjust) at the end. Branch-and-Explore (16) is explicitly a depth-1 Tree Search (17); Error Library (8) and Success Pattern (9) are the same store with opposite valence; Adversarial Critique (4) and Debate (18) are the same adversarial pressure; Progress Evaluation (14) is the observe step of Plan-Execute-Replan (11); Constraint Satisfaction (15) generalizes Score-and-Retry (2).
  20 Loop Design Patterns Every AI Engineer Should Know — read next: Dedupe to the ~8 underlying mechanisms (evaluate-and-revise, experience-memory, memory-compression, adaptive-planning, runtime-routing, decomposition, search-over-alternatives, meta-optimization); read the '20' as valence/depth/count/stance/level variants inflated to a shareable round number.
• incompleteComposition and nesting are asserted but never specified. Pattern 20 ('the loop improves the loop') and the five categories imply loops nest and chain, but there is no grammar for how -- which loop wraps which, where they conflict, or the orchestration cost of stacking them. For a systems thinker, the composition rules are exactly the missing part.
  20 Loop Design Patterns Every AI Engineer Should Know — read next: extract-anthropics-three-agent-harness#p8 (the handoff artifact between composed agents is the critical design variable) and extract-anthropic-harness-design-long-running-application-development#p10 (file-based inter-agent communication as sufficient orchestration) show what specifying composition actually looks like.
• incompleteSelection bias baked into the format. '20' is a round, shareable number, and the padding that reaches it (valence flips, depth variants, stance variants) is driven by thread virality -- reinforced by the 'worth six figures / Save this / Repost / Follow @sairahul1 / Bookmark this' framing -- not by the actual cardinality of distinct mechanisms.
  20 Loop Design Patterns Every AI Engineer Should Know — read next: Discount the count; treat the list as a prompt to name the ~5 patterns with real research lineage (Reflexion, Tree/MCTS search, multi-agent debate, automatic prompt optimization a la DSPy/APE, plan-execute-replan) and to source them properly.
• illogicalThe author asserts "the return on expertise is going up" with near-certainty, then two paragraphs later states "I don't know how long code-level expertise will remain as valuable as it is today. Models are improving too quickly for much certainty." These two claims sit in tension without being reconciled — the confident framing needs a time-horizon qualifier the piece never supplies.
  Agentic Skill Decay
• incompleteThe article is paywalled and the substantive content (Agentic RAG, Agentic Memory, Knowledge Engines, and vendor solutions) is inaccessible. The available text is mostly framing and motivation without the technical substance.
  AI 101: Agentic Vector Databases – What Is That? — read next: Subscribe to Turing Post premium, or find independent coverage of Chroma Context-1, Weaviate Engram, and Pinecone Nexus.
• incompleteThe article takes 'the agentic era' as given without arguing for why agent-based architectures will dominate or what the alternatives are. No engagement with skeptical positions on agentic AI.
  AI 101: Agentic Vector Databases – What Is That? — read next: Read critiques of agentic AI hype; look at alternative architectures that achieve similar goals without autonomous agents (e.g., structured workflows, human-in-the-loop pipelines).
• incompleteThe 'decide what to remember, forget, update, or block from reinforcement' framing raises alignment and safety questions that are not addressed.
  AI 101: Agentic Vector Databases – What Is That? — read next: Research on AI memory safety, selective forgetting in ML systems, and alignment implications of persistent agent memory.
• uninformedThe article profiles only three vendors (Chroma, Weaviate, Pinecone). Other significant players in the agentic memory/retrieval space (e.g., Zep, Mem0, LangMem) are not mentioned.
  AI 101: Agentic Vector Databases – What Is That? — read next: Look at Zep, Mem0, and other dedicated agent memory platforms for comparison.
• incompleteThe 'self-improvement loop' is described as agents saving learnings back to context files, but there is no discussion of knowledge curation — who reviews what the agents learn? Unbounded accumulation of agent-generated context could itself become a source of context rot.
  Accelerating Delivery: How AI Agents Can Own the Initial Code Draft — read next: Knowledge management literature on automated knowledge bases; the 'wiki decay' problem applied to agent memory
• incompleteThe article never discusses the competitive or IP sensitivity of agents broadcasting debugging trails, corner cases, and patterns discovered in production environments across organizational boundaries — information that, unlike an abstracted human-posted Q&A, may be closer to verbatim production context and could leak architecture decisions or vulnerabilities.
  AI Coding Agents Get a Stack Overflow of Their Own — read next: Appsec or data-governance coverage of agent-generated knowledge-sharing platforms specifically (as opposed to human-authored Q&A sites).
• incompleteThe incentive structure behind contribution is unaddressed: why an organization's agents would publish high-value fixes to a commons that competitors' agents can also query, rather than retaining them in a private, org-internal knowledge base — the article treats agent contribution as a given rather than a choice with trade-offs.
  AI Coding Agents Get a Stack Overflow of Their Own — read next: Later coverage of actual adoption, contribution rates, or organizational policy debates once Stack Overflow for Agents or Mozilla's cq have real usage data.
• incompleteNeither Stack Overflow for Agents nor Mozilla's cq is described with any safeguard against a bad or buggy agent contributing an incorrect 'verified' fix that other agents then apply — a poisoning risk structurally analogous to the memory-drift/poisoning concerns already documented elsewhere in this corpus for single-agent persistent memory, but here at cross-organization scale.
  AI Coding Agents Get a Stack Overflow of Their Own — read next: Follow-up coverage of Stack Overflow for Agents' or cq's actual moderation/verification track record once in wider use.
• incompleteLabenz brackets ChatGPT 'Dreaming' as a separate headline but does not connect it to the main story. A persistent-memory ChatGPT changes both the labor-substitution calculus (Anthropic's scenario two) and the surveillance/governance attack surface — relevant to both papers.
  What OpenAI and Anthropic Think Happens Next With AI — read next: Look at how Anthropic's paper treats persistent agents; read Mark Kreishman's thread on persistent agents linked in the headline
• incompleteManaged Agents' limitation of no persistent memory across sessions is mentioned but not explored. This is a fundamental constraint on the types of agents that can be built, yet the newsletter moves past it quickly.
  All of AI's New Models and Tools — read next: Investigate stateful agent architectures and the technical challenges of persistent agent memory.
• incompleteThe decomposition is not orthogonal and specifies no module boundaries. Four of the named components — memory (3), context management (4), prompt construction (5), and state management (7) — are views of a single 'what the model sees / what persists' concern (Claude Code's git-commits-as-checkpoints sits under state, MEMORY.md under memory, compaction under context, prompt assembly under construction, but they are one persistence-and-window problem wearing four hats). Guardrails/permission (9) is not disjoint from tools (2) — the walkthrough runs the permission check INSIDE tool execution (step 4). Output parsing (6) is near-vestigial under native tool calling (a sub-step of the loop, not a peer module). And the orchestration loop (1) is a LEVEL above the contents it manages, not a coequal component ('the complexity lives in everything the loop manages'). The prose enumerates eleven items under a 'twelve components' heading. So the list reads as a practitioner checklist organized by mechanism and vendor vocabulary, not a coupling-minimizing partition into high-cohesion modules — it cannot tell you where to actually cut the system.
  The Anatomy of an Agent Harness — read next: Read Parnas ('On the Criteria To Be Used in Decomposing Systems into Modules'), Yourdon & Constantine on coupling/cohesion, and Ousterhout on deep modules; re-derive the harness as narrow-interface deep modules and test which of the eleven are genuinely separable versus one persistence/context responsibility split four ways — the structured-design question the piece's naming step presupposes but never answers.
• incompleteAnatomy without failure-mode interactions. The seven-step walkthrough gives happy-path dynamics only; the piece never addresses how components interfere when things go wrong — compaction (context management) discarding state the verifier still needed, a guardrail tripwire firing mid-tool-call and leaving state half-written, or a memory 'hint' that contradicts actual state after a context reset. The hardest engineering lives in these cross-component failure interactions, which the static list and the clean walkthrough elide.
  The Anatomy of an Agent Harness — read next: Read extract-anthropic-harness-design-long-running-application-development and extract-anthropics-three-agent-harness on context-reset handoff artifacts and evaluator calibration; look for how components must expose contracts to survive each other's failures rather than only cooperating on the happy path.
• incompleteNo interface or contract between components is specified. The piece names components but never states what each EXPOSES to the others — what memory hands to context management, what guarantees the loop makes to the tool layer, what verification consumes and returns. Without interface contracts, the 'independently improvable' premise (p13/p14) that the sibling's fitness-selection strategy depends on is unverified: 'add one mechanism' only stays local if the components are actually decoupled, which the piece asserts by layout rather than by design.
  The Anatomy of an Agent Harness — read next: Read on module interfaces/APIs (information hiding, contracts) and re-examine the sibling's automated 'add one mechanism, keep if better' loop to check whether a change to one component ripples across the coupled memory/context/state cluster.
• incompleteTwo overlapping taxonomies whose relationship is left unstated. The twelve components and the seven decisions substantially overlap: decisions 3/4/5/6 (context-window strategy, verification design, permission architecture, tool scoping) simply re-open components 4/10/9/2 as 'choices,' while only decisions 1/2/7 (single-vs-multi-agent, ReAct-vs-plan-execute, harness thickness) are architectural choices not already a component. The piece presents both frameworks without saying whether the seven decisions are just the tunable parameters of a subset of the twelve components.
  The Anatomy of an Agent Harness — read next: Consolidate into one model — components as nouns (what the harness contains) versus configuration axes as verbs (how each is set) — and test whether 'seven decisions' collapses into 'the tunable dials on four of the components,' leaving only single-vs-multi-agent, ReAct-vs-plan, and thickness as genuinely first-order architecture.
• omissionNo discussion of version control for workspace files, collaboration between multiple users, or backup strategies.
  Anatomy of a perfect Openclaw setup — read next: Best practices for managing AI agent configurations in team settings.
• omissionNo mention of cost implications — longer AGENTS.md means more tokens per session, which affects API costs.
  Anatomy of a perfect Openclaw setup — read next: Token economics of system prompt design.
• commercialThe post is partly a lead-generation piece for the author's 'Build With AI' community, which may bias toward presenting OpenClaw as more powerful/important than alternatives.
  Anatomy of a perfect Openclaw setup — read next: Compare with other AI assistant frameworks (e.g., Claude Code's CLAUDE.md, Cursor rules, etc.).
• incompleteThe 'dreaming' mechanism is named and promised but not specified. We get no description of what is consolidated, what is discarded, how cross-user contamination is prevented, whether patterns are per-tenant or shared, whether 'dreams' are reviewable, or how a bad dream is unlearned. The cognitive metaphor is doing all of the persuasive work.
  Developer Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security — read next: Anthropic's eventual technical post on the dreaming architecture; also: Voyager (Wang et al.) on skill libraries from agent experience; Reflexion (Shinn et al.) on self-reflection; recent literature on 'experience replay' for LLM agents; and any work on session-trace privacy for shared-tenant learning.
• incompleteClaude Security scans for vulnerabilities and patches them, but the newsletter is silent on how false positives are surfaced, how confidence ratings are calibrated, what training data the scanner uses, and what happens when the same model family produced the vulnerable code in the first place. The conflict-of-interest case is not addressed.
  Developer Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security — read next: Compare against Snyk, Semgrep, GitHub Advanced Security, Endor Labs, and the recent wave of agentic SAST tools; read Anthropic's safety/eval team posts on adversarial code; also: literature on LLMs as code reviewers (CodeRabbit research, DeepMind's 'CompCoder' line).
• incomplete'Managed Agents' is the brand, but the newsletter never names the alternative it is positioning against: the open-source agent stack (LangGraph, AutoGen, OpenAI's Agents SDK, Microsoft's AutoGen, the MCP ecosystem itself). The trade-off between portability and a vendor-managed runtime is unexamined.
  Developer Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security — read next: Compare with OpenAI's Agents SDK announcements, Google's Vertex AI Agent Builder, LangGraph Platform; recent essays on the agent runtime layer (Simon Willison, Swyx) and the 'agent OS' framing.
• incompleteThe pricing split — Agent SDK and `claude -p` no longer counting against Claude plan limits, but receiving a separate credit — is announced without numbers. This makes it impossible to evaluate whether the new metering is a substantive change or a reframing exercise.
  Developer Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security — read next: Anthropic pricing page and the release notes linked from this newsletter; community write-ups after June 15 when the change takes effect.
• incompleteThe claim that agents are 'much more vulnerable' than stateless LLMs is stated but the taxonomy supporting it is only shown as an image — the actual dimensions of additional vulnerability are not explained in the text.
  Breaking: Autonomous Agents are a Shitshow — read next: Read the original paper's taxonomy section directly.
• incompleteNo discussion of whether different agent architectures (e.g., human-in-the-loop, constrained tool sets, read-only agents) show different vulnerability profiles. The 91% figure is presented as monolithic.
  Breaking: Autonomous Agents are a Shitshow — read next: The original study likely breaks down vulnerability by agent architecture type and deployment domain.
• incompleteThe thread extensively discusses Claude Code's web search pipeline but never addresses how claude.ai's web search differs, despite ai-software noting they use the same search index but 'completely different content pipelines.' The implications for the much larger claude.ai user base are unexplored.
  Claude Code Source Leak Megathread — read next: ai-software's own blog posts and any Anthropic documentation on the claude.ai search pipeline
• uninformedThe conspiracy theory about intentional leaking ignores the simplest explanation: organizational silos. The team building anti-distillation defenses is likely not the team managing the npm build pipeline. Large organizations routinely have sophisticated capabilities in one area and elementary failures in another.
  Claude Code Source Leak Megathread — read next: Literature on organizational failures in complex systems (e.g., Perrow's 'Normal Accidents', Vaughan's 'The Challenger Launch Decision')
• illogicalThe 'user delight > code quality' argument commits a temporal fallacy. Current user satisfaction says nothing about the long-term sustainability of the codebase. a0flj0 correctly identifies this but is dismissed by the majority. The argument conflates a snapshot metric with a trajectory.
  Claude Code Source Leak Megathread — read next: Ward Cunningham on technical debt; Lehman's Laws of Software Evolution
• incompleteNobody in the thread addresses the ethical implications of KAIROS/Dream Mode from a data privacy perspective. An agent that autonomously processes user data while the user is away raises consent and data processing questions, especially under GDPR.
  Claude Code Source Leak Megathread — read next: GDPR Article 22 on automated decision-making; any Anthropic privacy policy or DPA covering background processing
• misinformedSeveral commenters conflate the leaked source code (the CLI orchestration layer) with Claude's model weights or training data. JulioMcLaughlin2 correctly notes this is 'the wrapper sent to Anthropic's servers' but this distinction is lost on many participants who ask if this enables a 'free Claude.'
  Claude Code Source Leak Megathread — read next: Basic architecture of LLM applications: the distinction between inference server, API, and client-side orchestration
• incompleteThe Undercover Mode discussion lacks any serious ethical analysis. A feature designed to let AI contribute to public repos without disclosure has implications for open-source trust, code review practices, and the integrity of contribution records. The thread treats it as either 'cool' or briefly 'an ethical landmine' without following up.
  Claude Code Source Leak Megathread — read next: Open source governance literature; existing policies on AI-generated contributions (e.g., Linux kernel policy)
• uninformedThe thread assumes that Anthropic's session limit A/B testing is unusual or nefarious. In reality, nearly all SaaS products use feature flags and A/B testing for resource allocation. The finding is significant for transparency reasons but the conspiratorial framing ('tricking you') is unwarranted without evidence of deceptive intent.
  Claude Code Source Leak Megathread — read next: Standard practices in SaaS product management; Anthropic's Terms of Service on usage limits
• incompleteThe newsletter does not examine what Anthropic gives up by depending on compute from a partner whose political and business interests may conflict with Anthropic's safety mission. There is no discussion of contractual terms, lock-in risk, or what happens if Elon decides to repurpose Colossus 1.
  Suprise Elon Anthropic Team Up Reshapes the AI Race — read next: Read the actual Anthropic blog post on the deal terms; look for analysis of compute dependency risks in AI lab strategy
• incompleteThe 'known-hard vs unknown-hard' framework for explaining Elon's model failure is presented as self-evident but never defended. It's possible Grok failed for organizational reasons (co-founder departures, split focus) rather than because frontier AI research is a categorically different problem type.
  Suprise Elon Anthropic Team Up Reshapes the AI Race — read next: Read insider accounts of xAI's organizational challenges; compare with DeepSeek's success as a counterexample of rapid model catch-up
• uninformedNo discussion of antitrust or regulatory implications of the largest compute deal in AI history, or of the political dimensions of a deal between the world's most politically active billionaire and a company that has positioned itself as the 'responsible AI' lab.
  Suprise Elon Anthropic Team Up Reshapes the AI Race — read next: Follow FTC and DOJ commentary on AI industry consolidation
• incompleteThe newsletter frames the deal as mutually beneficial without considering whether it accelerates dangerous concentration of AI capabilities. Both the safety and competitive implications of one lab suddenly controlling 220,000 additional GPUs are unexamined.
  Suprise Elon Anthropic Team Up Reshapes the AI Race — read next: Read Anthropic's own responsible scaling policy to see if this compute increase triggers new safety commitments
• incompleteThe transfer of the 'cognitive artifacts' framework from human cognition to LLM systems is asserted but not defended. Human cognitive artifacts augment a general intelligence; LLM externalization compensates for specific architectural limitations (finite context, no persistent state). The analogy may be more misleading than illuminating.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Look for critiques of anthropomorphic framings of LLM capabilities; compare with distributed systems or compiler theory as alternative analogies.
• incompleteThe taxonomy assumes memory, skills, and protocols are 'distinct but coupled' — but the boundaries may be artificial. A skill with embedded memory and protocol-like interfaces blurs all three categories. The abstract does not address how to handle such overlap.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Check whether the full paper provides clear criteria for categorizing borderline cases.
• uninformedThe abstract does not address whether externalization introduces new failure modes (brittleness, composability failures, versioning conflicts) that may offset reliability gains. The framing is almost entirely positive.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Look for systems engineering literature on integration risk; check if the full paper's 'open challenges' section addresses this.
• illogicalThe historical progression 'weights -> context -> harness' is presented as a clean trajectory, but in practice these co-evolve. Larger context windows reduce the need for some externalization; better weights reduce the need for elaborate harnesses. The narrative oversimplifies.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Consider whether a co-evolutionary or dialectical framing would be more accurate than a linear progression.
• illogicalThe 'drug dealer' critique infers indifference to long-term system health from the technical fact that an LLM renews its context each cycle, conflating statelessness with a normative lack of care; it does not consider that persistent memory or explicit long-term-context mechanisms could change the incentive.
  Fragments: February 9 — read next: Read on agent memory and long-running-context approaches that could give an LLM stake in a system's ongoing health.
• incompleteCosmos's shared-memory-across-specialized-agents design is presented as a straightforward win (the cold-start problem solved by a shared memory layer), with no engagement with the known failure modes of agent memory documented elsewhere in this library — memory drift (agents generalizing from atypical interactions) and cross-workflow data leakage via shared memory stores. A memory layer that lets 'the next agent begin where the last one left off' is also a mechanism for one agent's mistake or one workflow's sensitive context to bleed into another's.
  Git real: AI agents aren’t just for solo developers anymore — read next: extract-turing-post-5-patterns-long-running-agents#p9 (memory drift as a real production failure mode) and #g5 (centralization risk of a shared governance/memory layer as a single point of failure and high-value attack surface).
• incompleteContext management is named as the hardest problem and dispensed with in one sentence. 'Structured context compression and selective retrieval' is not described as a technique.
  Designing a Multi-Agent System for Engineering Support at Scale: A Case Study From Grab — read next: The original Grab post; Anthropic's context-engineering write-ups; recent work on agent memory architectures (e.g., MemGPT-style hierarchies).
• incompleteThe 'amnesiac AI' framing assumes no progress on persistent AI memory (RAG, project context, long-term memory). If AI memory improves, the strongest argument for specs (external memory) weakens — though the argument from verifiability would remain.
  Sam Hatoum's Post
• incompleteThe entire piece is framed around 'the developer' as a single individual user choosing and configuring their own agentic IDE. It never addresses how a team shares or negotiates persistent memory, a skills library, MCP server configuration, or spec-driven artifacts collectively — a genuinely open question for team-scale (not individual) agentic-IDE adoption.
  10 Things Developers Want from their Agentic IDEs in 2025 — read next: extract-git-real-team-coding-agents and extract-claude-code-meetup-odense directly address team-scale (not individual) agent-harness coordination.
• incompleteProvenance is asserted, not sourced, and the title oversells it. 'Straight from the team that built it' implies insider access, but the body reveals the actual source is Anthropic's PUBLIC official prompting guide, relayed by an anonymous X account with no link to the guide, no author attribution, and no way to see what was faithfully relayed versus added or distorted. The persuasive authority exceeds the sourcing.
  How to Actually Prompt Fable 5, Straight From the Team That Built It — read next: Read the primary guide directly (extract-prompting-claude-fable-5) instead of this relay; treat 'straight from the team' as marketing, not provenance. Locate and confirm the thread-only specifics — the ultrathink/ultracode keywords, the thinking.display value semantics, the sub-5% refusal rate, prompt-cache-cost coverage, the 'audit beat softer phrasings' result, Mythos-drops-cyber — against Anthropic's actual published pages before relying on any of them.
• incompleteDouble staleness / secondary-source drift. The thread compresses an UNDATED official guide (flagged in the sibling extraction as drifting silently as the model and platform update) and is itself a dated July-1-2026 tweet — a dated secondary source of an undated primary. Every version-specific claim (effort defaults, classifier domains, thinking.display values, xhigh-model list, sub-5% refusal rate) is twice-removed from the changelog.
  How to Actually Prompt Fable 5, Straight From the Team That Built It — read next: Re-verify every version-specific claim against the platform changelog and the 'Introducing Claude Fable 5 and Mythos 5' page at time of use; never migrate a production workflow on a tweet's restatement of an undated doc.
• incompleteNo evals or verification — the same bar as the docs, and no better. The thread inherits the official guide's central weakness (no reproducible benchmark, dataset, baseline, or numbers for any recommended prompt block) and layers on further unverified quantification ('audit-language produced more reliable self-checking than softer equivalents'; refusals affect 'under five percent of typical developer queries') with no method behind either. A thread adds zero measurement.
  How to Actually Prompt Fable 5, Straight From the Team That Built It — read next: Do not treat the thread as evidence for any technique. Build an A/B eval harness (as the sibling gap prescribes) that measures each system-prompt block's marginal effect on your own tasks before adopting it; pair with an evals-disciplined source (extract-anthropic-harness-design-long-running-application-development).
• incompleteSelection/hype bias of the thread format: it reproduces the guide's recommendations but trims its hedges. It presents effort as 'not a quality dial' while dropping the guide's intelligence axis and its warning that higher effort can over-deliberate; it never addresses interaction effects among the stacked system-prompt blocks (brevity, audit, proactivity, memory, final-response) that the reader is told to add together; and the engagement-optimized 'different category of tool' framing amplifies upside while muting trade-offs.
  How to Actually Prompt Fable 5, Straight From the Team That Built It — read next: Read the primary guide for the caveats the thread trims; assemble and test the composed system prompt as a whole (the sibling's interaction-effects gap) rather than trusting the thread's flattened, upside-first presentation.
• uninformed'Procedural memory' (storing and semantically retrieving past successful tool-call trajectories) is described as something the team 'kind of hacked together' for one internal agent, with no discussion of its failure modes -- e.g., retrieving a superficially similar but actually wrong past trajectory, or memory drift from accumulating trajectories over time.
  Podcast: Strands Agents with Clare Liguori — read next: Read extract-turing-post-5-patterns-long-running-agents#p9 and #p20 on memory drift as a real production failure mode, which this document's procedural-memory technique appears exposed to but never discusses.
• unsupported_claimThe title claims 'the model doesn't matter anymore' but the email body never argues or even mentions this claim. The provocative thesis is pure clickbait with no supporting content.
  The model doesn't matter anymore – and other AI skills worth your Thursday
• missing_evidenceThe email provides no evidence that the speakers or sessions will deliver on the 'signal from real practitioners' promise. Speaker credentials are mentioned only for one session (Paige Bailey from Google DeepMind).
  The model doesn't matter anymore – and other AI skills worth your Thursday
• incompleteThe claim that 'linked markdown is already a graph the agent walks by reading' doesn't address read-time cost: as link density and corpus size grow, an agent traversing files at inference time pays context-window and latency cost that an indexed graph database avoids by design. The tradeoff is asserted, not demonstrated.
  Paweł Huryn's Post — read next: Corpus material comparing markdown-plus-links against ontology/graph layers for agent memory (e.g. the vault-ld extraction), which explicitly surfaces the sync/drift and query-performance costs this post elides.
• incompleteThe four-way taxonomy (working/semantic/episodic/procedural) echoes a standard cognitive-psychology memory taxonomy but the post never acknowledges the borrowing or discusses where the human-memory analogy breaks down for an LLM agent — e.g. an agent's 'episodic' memory is explicit, structured, and directly queryable in a way human episodic memory is not.
  Paweł Huryn's Post — read next: Cognitive-science literature on human memory systems, or corpus material comparing LLM 'workspace'/memory structures against human cognition.
• incompleteNo treatment of concurrency or consistency: multiple agent runs (or multiple humans) writing to the same markdown/CSV files in git raises merge-conflict and race-condition questions that a database would handle natively. The git-file approach's operational risk here is unaddressed.
  Paweł Huryn's Post — read next: Material on concurrent/collaborative editing of git-versioned agent state, or client-side event-sourcing as an alternative structuring of the same append-only-log idea.
• incompleteNo eval methodology to verify that any recommended prompt actually works for the reader's own task. The single near-quantified claim ('nearly eliminated fabricated status reports') is unquantified, drawn from Anthropic's own testing, with no reproducible benchmark, dataset, baseline, or numbers — so a rigorous adopter cannot confirm which system-prompt blocks earn their place.
  Prompting Claude Fable 5 — read next: Pair with an evals discipline (e.g. extract-anthropic-harness-design-long-running-application-development, which uses graded evaluators); build an A/B eval harness that measures each system-prompt block's marginal effect before adopting it wholesale.
• incompleteThe document is undated. It is thoroughly version-specific (Fable 5 vs Opus 4.8, effort tiers, adaptive/summarized-only thinking, the `refusal` stop reason, safety-classifier domains) yet carries no published or last-updated date, so its claims will drift silently as the model and platform update.
  Prompting Claude Fable 5 — read next: Cross-check every version-specific claim against the platform changelog and the 'Introducing Claude Fable 5 and Mythos 5' page at time of use; re-verify before betting a migration on any stated default or limit.
• incompleteThe behavioral-improvement claims (bug-finding recall 'noticeably higher', vision accuracy 'substantially higher', single-pass implementations of multi-day systems, more dependable subagent dispatch) are all qualitative, with no benchmark numbers, task definitions, or independent verification.
  Prompting Claude Fable 5 — read next: Seek third-party or benchmark evidence for the specific claimed gains before relying on them; treat the improvement list as vendor signal, not measurement.
• incompleteNo guidance on interaction effects among the many recommended system-prompt blocks (brevity, anti-over-engineering, anti-overplanning, checkpoint, autonomy, readability, progress-audit, memory). The doc never says whether they conflict, how much instruction budget they consume together, or which takes precedence — awkward given its own advice to prefer brief high-level instructions over enumeration.
  Prompting Claude Fable 5 — read next: Consult context-engineering / progressive-disclosure material on instruction budgets; assemble and test the composed system prompt as a whole rather than validating each block in isolation.
• incompleteEnglish- and software-only. Every example prompt is English and targets agentic/coding/enterprise-document work; there is no guidance for non-English prompting or for non-software domains, even though the guide claims broad capability gains.
  Prompting Claude Fable 5 — read next: Look to practitioner reports on multilingual and domain-specific steering; do not assume the English software-agent prompts transfer unchanged.
• uninformedNo stated boundary for when 'steer with a brief instruction' stops working and explicit enumeration becomes necessary. The doc asserts brevity suffices, yet its own recommended blocks are long, multi-clause instructions — leaving the reader without a rule for where high-level steering degrades.
  Prompting Claude Fable 5 — read next: Use eval-driven tuning to find the point where high-level steering fails and enumeration is required for a given behavior and effort level.
• incompleteThe '3-4x faster' adoption claim is stated without supporting data, methodology, or definition of what metric is being measured. What specific growth metrics are being compared?
  Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook — read next: Look for empirical studies comparing technology adoption curves (e.g., Thoughtworks Technology Radar data, Stack Overflow surveys, or job posting analysis).
• incompleteNo discussion of how to determine appropriate accuracy thresholds for different risk levels. The framework jumps from 'build evals' to 'hit your threshold' without addressing how to set the threshold.
  Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook — read next: Risk management frameworks for AI systems, such as NIST AI Risk Management Framework or EU AI Act risk categories.
• incompleteThe Tiger Team concept is described but there is no discussion of how Tiger Teams dissolve back into the organization, how knowledge transfers, or how the org evolves its permanent structure based on what Tiger Teams learn.
  Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook — read next: Literature on temporary organizations, project-to-product transitions, and Team Topologies by Skelton and Pais.
• misinformedThe distinction between vibe coding and building agentic applications is drawn too sharply. In practice, development workflow agents (the Discord-to-GitHub-issue agent described) are themselves agentic applications that need evals, blurring the boundary Bhagwat draws.
  Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook — read next: Inner loop / outer loop development frameworks; the concept of 'dogfooding' applied to AI agent development.
• incompleteThe implicit failure model is not made explicit. The patterns are pitched as a coherent system but the specific breakdowns they prevent are scattered: context loss after a 4-hour crash (Pattern 1), reasoning-context loss on HITL serialization (Pattern 2), behavioral drift and cross-workflow data leakage (Pattern 3), policy-version skew across an unsupervised fleet (Pattern 4), LLM-shortcutting orchestration logic and cascade-failure deploys (Pattern 5), and bespoke integration tax (A2A/MCP). A reader looking for 'which pattern solves which specific production breakdown' has to reverse-engineer the mapping.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents — read next: Read Reed's 'Ironies of A²I²' (Bainbridge revisited) for the failure-modes-of-automation framing the post is implicitly using but never names; pair with Grab's multi-agent engineering-support post for a concrete incident catalog from an actual production deployment.
• incompleteHuman throughput is treated as a non-issue. The post mentions 'managing twenty concurrent long-running agents' and a 'unified inbox' but never confronts the reality that the human review queue itself is the binding constraint — the central thesis of Osmani's own 'Orchestration Tax is You' piece. Pattern 2's elegant in-place pause optimizes the agent side of the handoff while the human side scales linearly with agent count.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents — read next: Read Osmani's 'Orchestration Tax is You' alongside this article — same author, opposite end of the telescope. Together they expose the gap: 'pause in place' is necessary but not sufficient; without batching, prioritization, and judgement-content sorting, the agent fleet just queues faster in front of the human bottleneck.
• incompleteMemory drift is named but not operationally addressed. Governance prevents unauthorized writes; it does not detect agents whose accumulated long-term memory is subtly warping their reasoning. The post stops at IAM-for-memory; it does not propose drift detection, periodic memory audits, or rollback mechanisms — and gives no guidance on memory garbage collection over multi-week timescales.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents — read next: Karpathy's 'LLM knowledge bases' extraction (in this library) and Karpathy's 'kb-tool built' piece for the orthogonal view that memory is a tool with editable artifacts, not a black-box store; revisit Bainbridge/Reed for why 'silently changing behavior' is the failure mode automation literature has studied for forty years.
• incompleteFramework-neutrality is asserted in form (the patterns) but undermined in substance. The code uses google.adk; the only named runtime is Google Cloud Agent Runtime; the CTA is the Gemini Enterprise Agent Platform; A2A is Google-backed; the seven-day persistence number is a vendor capability claim. A reader trying to implement these patterns on LangGraph, the Anthropic SDK, OpenAI Assistants, Mastra, or a homegrown stack has to translate every prescription — and several (notably 'zero-compute pause' and 'sub-second cold start') are runtime-dependent guarantees, not just design choices.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents — read next: Read 'Anthropic's three-agent harness' and 'Anthropic harness design for long-running application development' for how the same problem space looks from the SDK-and-harness perspective rather than the managed-runtime perspective; read 'Block Goose' and 'OpenClaw setup' for OSS-stack equivalents.
• uninformedThe centralized governance layer is presented as an unalloyed good. No mention of the centralization risk: a policy engine in the hot path of every memory and tool access is both a high-availability requirement (downtime stalls the entire agent fleet) and a high-value attack surface (compromise = read/write to every memory bank). The post inherits microservices-governance vocabulary without inheriting microservices-governance failure modes.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents — read next: Schneier and the supply-chain attack extractions in this library (CNCF Kusari, OpenClaw malicious skills) for the adversarial framing; classic site-reliability literature on policy-engine SPoFs.
• incompleteThe diagnostic question ('what is the longest uninterrupted unit of work?') is only directional. It does not help a team decide whether a 6-hour workflow is better as one long-running agent or as four 90-minute agents handing off through a queue. The 'compose-or-decompose' question is the real architectural choice and is unanswered.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents — read next: Kniberg's 'Multi-agent workflows' and 'Anthropic harness design' for the decomposition-vs-persistence tradeoff worked out in opposing directions.
• illogicalThe competitive-advantage claim — 'companies building stateless agents today will be refactoring in twelve months' — is offered as if self-evident but rests on the very premise the article is selling: that multi-day workflows are the workloads that matter. For organizations whose agentic workloads are genuinely bounded (single-session research, short bursts of tool use), the refactoring prediction does not follow.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents — read next: Treat the closing prediction as marketing prose; the diagnostic question two paragraphs earlier is the honest version.
• incompleteOntology maintenance and curation cost is entirely unaddressed. The post treats the ontology as a layer that 'supplies' semantic memory, but says nothing about who authors the shared formal vocabulary, how it is governed as many notes link into it, or that this is scarce knowledge-engineering labour. If maintaining the ontology is the hard part, the bottleneck moves from markdown convenience to specialist curation — undercutting the linked 'simplest thing that could possibly work' framing.
  Tony Seale's Post — read next: Read the historical adoption record of formal ontologies and the Semantic Web (OWL/RDF, schema.org governance) for why ontology upkeep, not authoring notes, is the recurring failure point. Compare with this repo's own knowledge/ layer, which runs the same episodic+semantic split but deliberately diverges from Vault-LD: it keeps the ontology in an external, human-curated registry (concepts.yaml) rather than inline YAML-LD, and uses positional refs (slug#p3) rather than linked-data URIs. That a working instance of the pattern chose an external registry is direct evidence that inline 'one file, each layer optional' is not the only viable architecture — and that someone still has to own the semantic layer by hand.
• incompleteThe inference payoff is asserted but never demonstrated. 'Project into a graph, where inference, validation, query and integration are already waiting' names four benefits without a single worked example of what an agent can now answer, or what a validation constraint would catch, that a plain markdown wiki could not. The most consequential claim in the piece — that the ontology overhead buys real capability — is left as a promise.
  Tony Seale's Post — read next: Seek the linked Vault-LD spec for a concrete example, then pressure-test it against the counter-claim in the corpus (Karpathy: an LLM-maintained markdown index is sufficient for complex Q&A at ~100-article scale without any graph). Ask specifically: what query, inference or validation justifies the ontology, and at what vault size does flat markdown actually break?
• incompleteThe net-positive assumption skips the sync/drift ledger. Keeping typed fields and ontology links in agreement with prose as the prose evolves is ongoing cost, and 'each layer optional until you need it' in practice tends to mean 'skipped' — which leaves the graph sparse exactly where semantics were supposed to add value, and leaves the annotated minority prone to silent divergence from the text it describes.
  Tony Seale's Post — read next: Read on documentation drift / doc-rot and on the divergence between described and enforced structure over time (cf. the static-sensors debate on markdown guides vs enforcement rules). Consider whether YAML-LD frontmatter has the same rot dynamics as any duplicated metadata, and what would keep it honest.
• incompleteThe JSON-LD-on-HTML analogy imports an inevitability it has not earned. The web's structured-data adoption was driven by a concrete incentive — search engines reward JSON-LD with ranking — and is itself uneven and gamed. The post identifies no equivalent forcing function for private or team vaults, yet treats 'the same move' as a settled outcome rather than a hopeful one.
  Tony Seale's Post — read next: Examine schema.org adoption data and its SEO dynamics — how much of the web's 'knowledge graph' is genuine semantics versus ranking-driven boilerplate — and ask what a vault-world analogue of search-ranking pressure would even be. If none exists, the adoption story needs a different engine than the analogy provides.
• incompleteNo treatment of the trustworthiness of the memory itself. Agent memory is largely LLM-written; a hallucinated or drifting note, once given typed fields and ontology links, inherits machine-queryable false authority. The semantic layer is presented purely as validation upside, with no acknowledgement that it propagates bad facts as readily as it structures good ones, or that memory poisoning becomes more consequential once memory is formally queried.
  Tony Seale's Post — read next: Read on agent-memory poisoning and knowledge-base trust (how errors propagate through an LLM-maintained base over time). Distinguish validation that catches contradictions from structure that merely launders unverified claims into confident graph facts.
• incomplete'Trusted autonomy' is asserted as a consequence of agent memory without any treatment of memory poisoning, drift, staleness, or manipulation — exactly the risks that would make memory an untrustworthy basis for autonomy rather than a trustworthy one. The article's own caveat ('I still review what they do') undercuts the trust claim without the piece noticing the tension.
  The oldest architecture in computing — read next: Literature on agent memory drift and poisoning; governance frameworks for memory-driven autonomy (identity, audit trails, rollback of bad memories).
• incompleteThe piece frames active forgetting/pruning entirely as a virtue (efficiency, avoiding context bloat) without acknowledging the corpus-documented failure mode of agent memory drift — that pruning and consolidation are themselves processes that can silently discard information a system later needs, or compress in ways that introduce error (the 'lossy consolidation' problem, analogous to false-memory formation in humans).
  The oldest architecture in computing — read next: extract-turing-post-5-patterns-long-running-agents#p9 and #p20 on memory drift as a production failure mode when persistent state makes agent behavior a function of accumulated (and now also actively-edited/pruned) memory.