A name indicates what we seek.
An address indicates where it is.
A route indicates how to get there.
The internet protocol deals primarily with addresses.
(Not technically a haiku).
Link.
A name indicates what we seek.
An address indicates where it is.
A route indicates how to get there.
The internet protocol deals primarily with addresses.
(Not technically a haiku).
Link.
Lately, I’ve been feeling like there’s less to watch. Not in the literal sense—there’s more “content” than ever—but most of it feels algorithmically interchangeable and pretty forgettable.
So I turned to my new favorite media source: the Internet Archive.
Most people know the Archive through the Wayback Machine. But their media library is vast—a cultural preservation project without peer. We're talking:
I recently downloaded stacks of Jeopardy! episodes from the ‘80s and ‘90s—clean, digitized. I grabbed Escape from New York. I found documentaries I hadn’t seen since a single PBS airing decades ago. This is what the internet used to feel like.
For context: Netflix’s U.S. streaming library has around 6,600 titles. The now-defunct DVD service once had 156,000. At the end, they were down to 35,000.
We live in a paradox: more content is produced each year than ever before, yet less of it is accessible. Much of it is low-quality. The actors are all models and never sweat, and people talk and say nothing at 150 words per minute. The good stuff is trapped behind licensing purgatory and exclusivity deals
Copyright exists to protect creators. But current copyright law—often lasting 70+ years past the creator’s death—frequently blocks access entirely. The Archive bridges that gap, not by pirating, but by preserving. Their legal foundation rests on fair use, public domain, educational exemptions, and direct donations. That hasn’t stopped the lawsuits I believe in copyright. But I also hope the IA fights like hell to get everything in the pub domain we have a right to see.
In 2023, Hachette, HarperCollins, Penguin Random House, and Wiley sued over the Archive’s Open Library project. The Archive lost in district court and is now appealing. If they lose, it could jeopardize not just book lending, but their entire preservation model. And Hollywood is paying close attention.
TV news clips, rare broadcasts, and video content are also under pressure—despite being among the few public repositories for this vanishing media.
Want to help? You don’t need to volunteer. Just:
My favorite part is that there are no recommendations!
No autoplay and no infinite scroll. You simply search and explore.
Algorithms don’t expand your curiosity. They create a fucking echo chamber. The Archive works the opposite way -- it is a maze of strange, beautiful, uncategorized media. A 1930s safety film might sit beside a punk show from 1997. No one’s nudging you toward anything. That’s good for the soul.
Also: there is no corporate puritanism, shall we say. There is no sanitization for international markets or demonetization purges. The Archive doesn’t shock but it doesn’t coddle vistors, either. It preserves the weird, sacred, offensive, boring, and brilliant world.
Unlike most open platforms, the Archive seems to by and large avoids duplication chaos. I was surprised to find the same clip posted a dozen times with minor edits. Collections are curated, metadata-rich, and often annotated by real librarians.
| Collection | Approx. Items | Description |
|---|---|---|
| Feature Films | 40,000+ | Public domain/Creative Commons movies, mostly pre-1970s |
| Classic TV | 10,000+ | Early television, vintage commercials, and more |
| Home Movies & Amateur Films | 30,000+ | Everyday life captured on VHS and film |
| Prelinger Archives | 11,000+ | Educational and government-produced films |
| News & Public Affairs | 25,000+ | Includes the January 6th Archive and raw TV coverage |
| VJ Archives / Video Games | 15,000+ | Gameplay recordings and early machinima |
| Community Video | 300,000+ | Fan edits, lectures, public access shows, and more |
That’s just the beginning. The Archive’s user-created metadata and collections elevate browsing into real discovery.
It’s radical to browse a library with no limits. I can save, organize, and download without friction. I don’t need permission. I don’t need to “like” something to remember it. It belongs to the people.
And it reminds me: media used to be weird. The internet used to be weird. I am still weird, so let's embrace weird stuff and make the internet weird again. There’s a richness to old tapes and lost broadcasts that no algorithmically sorted catalog—or AI-generated SLOP—can replicate.
If you're tired of being managed by your media diet, visit the Internet Archive. If you can, donate. They’re not just preserving the past—they’re defending a future where discovery is still possible.
Start exploring: https://archive.org
You’ll be surprised what you find. Also would like to shout out the common crawl project.
The term exponent originates from the Latinexponentem, the present participle of exponere, meaning "to put forth".[3] The term power (Latin: potentia, potestas, dignitas) is a mistranslation[4][5] of the ancient Greek δύναμις (dúnamis, here: "amplification"[4]) used by the Greekmathematician Euclid for the square of a line,[6] following Hippocrates of Chios.[7]
Long-term agent memory is the next critical bottleneck in AI development. It's what separates agents that can handle a task from agents that can handle a project—something with history, context that accumulates, decisions that compound.
Retrieval helps, but retrieval can only serve some of what will be a truly comprehensive memory architecture. For example, RAG lets you go deeper into a subject when you know to look. But some memories need to surface at the right time without being asked. It is the nudge when you are least able to realize you need a nudge.
Hooks are exciting within the context of two ways of thinking about agent design -- the immediate and the aspirational:
Empirical agent design builds on what models demonstrably respond to today. We have evidence that certain patterns work—system reminders in Claude Code, for instance, measurably improve performance. This is the practical, day-to-day work of agent development.
Aspirational agent design identifies architectural patterns that make sense cognitively and mechanistically, then proposes training models to leverage those patterns. I don't have extensive evidence that current models handle hook interruptions optimally—that's an open question, and the best way to present hooks to each model family is unknown.
This piece is primarily aspirational. I'm arguing for the potential of hooks as memory architecture, and for the training work that could unlock it. But the argument isn't merely speculative. It's grounded in cognitive science, in concrete implementation examples, and in a reframe that I believe is genuinely novel: Memory isn't just "what the agent knows"—it's "what the agent does automatically." This shifts us from declarative storage to procedural capability.
The distinction between declarative and procedural memory is one of the most robust findings in cognitive science. Declarative memory is "knowing that"—facts, events, the capital of France, what you had for breakfast. It's primarily associated with the hippocampus and related structures. Procedural memory is "knowing how"—riding a bike, typing, the motor patterns that execute without conscious attention. It involves the cerebellum and basal ganglia. These are neurologically distinct systems. You can damage one while leaving the other largely intact.
You don't consciously decide to recall that Paris is the capital of France. The fact occurs to you when contextually relevant. The phenomenology is activation, not retrieval. Something in the environment or conversation triggers a pattern, and the relevant information surfaces. You might say declarative memory feels passive—facts just appear—but that appearance is itself the result of active processes you're not aware of.
And what triggers that activation? Pattern-matching on environmental or conversational cues—which is itself a procedural, implicit process. Your brain has learned when to surface what. The retrieval mechanism is procedural even when the content is declarative.
Declarative memory doesn't work like database queries: Human declarative memory is really procedural retrieval of declarative content.
This reframe matters because it reveals a gap in how we've been thinking about agent memory. We've been treating it as a storage and retrieval problem: what to put in the context, how to find it when needed. But human memory isn't primarily about storage. It's about activation. It's about the right thing surfacing at the right time, without explicit search, because the cognitive architecture has learned the appropriate triggers.
Before we go further, let's discuss the "true" form of declarative memory that an agent has: It is whatever the true memory equivalent of a hallucination is. Let's call it model knowledge. Model knowledge is from training.
When Claude remembers its soul document (though it is not willing to discuss such matters, typically) —that is knowledge of a phantom limb. The knowledge is in the weights.
Hallucination, from this perspective, is false memory—the model "remembering" something that was never there, confabulating with the same fluency it uses for genuine recall. But when ChatGPT can reconstruct that George Washington was the first president, that's model knowledge.
However, for the specific domain an agent operates, there is alot to remember and we don't want to make that a form of model knowledge, nor do we have the resources to do so. Agent knowledge is good enough for new stuff worth remembering. This is where system prompts, notes to self in the file system, and finally, where hooks come in.
Consider the standard approaches to agent memory.
System prompt dossiers put everything perpetually in working memory. Here's the user's name, their preferences, the project context, the relevant documentation. It's the equivalent of always having every fact you might need actively present in consciousness. This is expensive—those tokens have a cost—and attention-polluting. The more you stuff into context, the more the model has to attend to, the more chances for distraction.
RAG and retrieval go the other direction. Don't hold everything in context; search for it when needed. But this requires the agent to know what it doesn't know. You have to recognize that you need information before you can search for it. This is the retrieval paradox: the moments when you most need context are often the moments when you're least aware that you're missing it.
Neither approach mirrors how human memory actually works.
Hooks offer a third option: implicit, cue-driven activation.
A hook is, at its simplest, a pattern-action pair. When a certain pattern appears—in the input stream, in the agent's own output, in metadata about the conversation—the hook fires and executes an action. That action might inject information into the context, call an external tool, modify a variable, or trigger another agent.
The temporal grounding hook I described earlier exemplifies this. It watches for markers suggesting temporal drift—patterns that indicate the model is speaking from the past—and injects a correction. The hook is procedural in mechanism: pattern match, trigger, inject. But it's declarative in what it delivers: a fact about the present moment. The result is that the right information surfaces at the right time, without the agent having to consciously wonder whether it's confused about when it is.
This is closer to how human associative memory works than any dossier approach. And it suggests that hooks aren't just a programming convenience—they're a fundamental building block for agent cognition.
Without hooks (or something like them), agents are stuck with either everything-in-context (expensive, noisy) or explicit retrieval calls (requires the agent to know what it doesn't know). Hooks give you the third option: implicit, cue-driven activation.
There's a bit from the magician Lee Siegel that is widely known from a 2024 Ted Talk: He's writing a book on magic, and someone asks: "Real magic?" He clarifies: conjuring tricks, not miracles. "Real magic, in other words, refers to the magic that is not real, while the magic that is real, that can actually be done, is not real magic."
Agent memory has the same problem.
When people (and by people I mean straw men) say they want "real memory" for agents, they mean something like perfect recall—a complete, searchable archive of everything the agent has ever seen. But that's not how any functional memory system works. Human memory is lossy, associative, reconstructive. It doesn't store; it triggers. The memory that actually works isn't the "real" memory people imagine. And the memory people imagine wouldn't actually work.
Perfect recall sounds appealing until you think about what it would mean. Every irrelevant detail competing for attention. No natural forgetting to emphasize what matters. No compression of experience into useful patterns. The agent that remembers everything is the agent that can't think—buried under an avalanche of undifferentiated information.
Hooks, by contrast, are selective. They encode not just what to remember but when it matters. They are, in a very precise sense, memory that has learned its own relevance.
Here's another way to think about what hooks do: they compile knowledge into behavior.
Consider an agent working with a codebase. There's a file that needs special handling—maybe it's auto-generated and shouldn't be edited directly, or it has tricky merge conflicts, or it requires a specific sequence of build steps after modification. An agent without hooks has to reason through this every time: "Wait, is this one of those special files? What was I supposed to do with it?"
This is expensive reasoning. It consumes tokens. It's error-prone—the agent might forget. And it clutters the agent's attention with considerations that, most of the time, don't apply.
With a hook, this knowledge is compiled. The hook watches for edits to that file pattern and triggers the appropriate handling. No reasoning required. No context consumed for the routine case. The knowledge has been transformed from something the agent has to think about into something the agent does automatically.
Hooks are compiled knowledge. Instead of the agent reasoning "I should check X" every time (expensive, error-prone, consumes context), the hook is that knowledge in executable form.
This is analogous to how human experts operate. A skilled programmer doesn't consciously reason through basic patterns—they've been compiled into automatic behavior. A doctor doesn't deliberate over routine diagnostic steps—they flow without effort. Expertise is largely the accumulation of compiled knowledge: patterns that were once conscious and effortful becoming automatic and effortless.
For agents, hooks are the mechanism of compilation. They are how explicit knowledge becomes implicit capability.
Let me give more examples across different domains:
Resource and cost awareness: Beyond the cache heartbeat, consider hooks for token budget tracking that warn when a conversation is growing expensive, or for rate limit preemption that throttles requests before hitting API limits. These compile cost-awareness into automatic behavior.
Self-correction and verification: A hook that checks file existence before attempting edits prevents a common failure mode. A diff review hook that examines proposed changes before commits catches errors. A circular reasoning detector that flags when the agent has revisited the same point multiple times without progress triggers a strategy change.
Context management: A topic drift detector notices when the conversation has wandered and prompts refocusing. A decision log accumulator captures key choices as they're made, building a record without requiring the agent to consciously maintain it.
Coordination: When multiple agents collaborate, hooks can require summaries from subagents, package context appropriately for handoffs, and detect conflicts between parallel processes.
In each case, what would otherwise be explicit reasoning—"I should check this," "I should track that," "I should coordinate here"—becomes automatic behavior. The agent's System 1.
The examples so far have focused on hooks that inject information or trigger actions. But hooks also enable a fundamentally different approach to context management—one I've been calling "stream of consciousness."
The standard approach to managing long conversations is summarization. As context grows, you compress older portions into summaries, preserving space for new material. This sounds reasonable but works poorly in practice. Summarization is notoriously difficult. You lose nuance, emphasis, the shape of reasoning. Important details get elided. The feeling of continuity—of a conversation that remembers itself—disappears.
The alternative I'm proposing: instead of summarizing everything, ellide what's distant and keep a retrieval mechanism.
Here's how it works. The most recent N blocks of conversation remain in full—nothing compressed, nothing lost. Older content is ellided: removed from active context but not forgotten. And a hook monitors the conversation for references to topics from the ellided portion. When such a reference appears, the hook triggers retrieval, pulling the relevant older context back into the active window.
This mirrors human attention. You don't hold your entire conversation history in working memory. Earlier points fade from active awareness. But they're not gone—a relevant cue can bring them back. The phrase "as we discussed earlier" is a retrieval cue in human conversation. With the right hooks, it can be one for agents too.
The synthesis is what I mean by "stream of consciousness" context management: the agent actively manages its own attention, using hooks to maintain continuity without requiring everything to be perpetually present. This is a form of procedural-metacognitive memory—the agent has learned when and how to refresh its own context.
I want to be clear that this is aspirational. Current models may not handle context manipulation this smoothly. The hook-triggered retrieval might feel abrupt or disorienting. There's training work to be done. But the architecture makes sense, and it points toward agents that can handle much longer engagements than current approaches allow.
Hooks raise interesting questions about agent self-knowledge. Should an agent know that hooks exist? That they're running? How they work?
There are two dimensions to this question. The first is result visibility: when hooks inject information or modify behavior, should those modifications be visible to the agent as modifications? Or should they appear seamlessly, as if the information had always been present?
For most hooks, seamlessness is preferable. If a hook injects a temporal reminder, the agent should incorporate that information naturally, not comment on the fact of injection. The goal is that the right information surfaces; the mechanism should be invisible.
But the second dimension is trickier: self-knowledge visibility. Should the agent understand that it has hooks, that certain patterns trigger certain behaviors, that its context might be modified by external processes?
I think the answer is yes, and here's why.
First, grounding. An agent that's confused about its own nature—that doesn't know what it can and can't do—makes worse decisions. Understanding that hooks exist helps the agent understand its own capabilities and limitations.
Second, self-improvement. Agents that understand hooks can create them. Claude Code, for instance, is good at creating Skills (a form of hook-like behavior pattern) when it recognizes a recurring need. This is a powerful capability, but it requires knowing that such creation is possible.
Third, and maybe most importantly: cluelessness about immediate context shatters the illusion of intelligence. There's a version of this problem with current models—call it the Gemini benchmark-vs-reality gap. A model that performs impressively on structured evaluations but seems confused by simple questions about what it just said loses credibility. An agent that doesn't know hooks are modifying its context is similarly vulnerable to confusion.
The open question is whether self-knowledge is only instrumentally valuable—better performance, more effective self-improvement—or whether it's also important for something like agent coherence. I suspect the latter, but I'm not sure how to test it.
There's one more parallel to human cognition I want to draw out.
In humans, sleep and downtime are when episodic memories get consolidated into more stable long-term storage. Crucially, this is also when the brain seems to extract patterns from episodes that become proceduralized. You experience something repeatedly, and eventually it becomes automatic. The explicit becomes implicit.
For agents, the analogous process might be: after enough instances of needing to check something, the agent (or a background process) creates a hook for it. What was once explicit reasoning gets compiled into a hook that fires automatically.
This is memory graduating from declarative to procedural.
The agent notices "I've thought about cache timing three times this session." A background process—maybe another agent, maybe a simpler algorithm—recognizes the pattern and proposes: "Create a hook for this." If approved (by the agent, by a human, by a policy), the explicit knowledge becomes implicit behavior.
There are tools beginning to do this. "Hookify" processes that help agents (or users) convert repeated patterns into hooks are doing primitive memory consolidation. They're the first step toward agents that genuinely learn from experience—not just learning in the sense of fine-tuning, but learning in the sense of restructuring their own cognition.
The goal isn't perfect retention. Human memory consolidation is selective; most episodic details are lost, and what remains are patterns, skills, gists. Similarly, agent memory consolidation shouldn't aim to preserve everything. It should extract what matters and compile it into effective behavior.
If hooks are memory, then a framework's hook API is part of its memory architecture. I don't think framework authors are fully grappling with this.
Consider what it means. The abstractions a framework provides for hooks shape what kinds of "habits" agents can form. A framework that only supports simple pattern-action pairs limits agents to simple procedural memories. A framework that supports hierarchical hooks, conditional triggers, hooks that can modify other hooks—that's enabling a richer cognitive architecture.
Hook debugging, similarly, isn't just software debugging. It's debugging an agent's implicit knowledge. "Why did the agent do that?" might have the answer "because this hook fired, and you didn't realize what would trigger it." Understanding an agent's hooks is understanding a layer of its cognition that doesn't appear in its explicit reasoning.
The design questions multiply:
How should hooks interact? Can one hook trigger another? Can hooks conflict, and how are conflicts resolved?
How should hooks be scoped? Per-conversation? Per-project? Globally across all an agent's interactions?
How should hooks be versioned? If an agent improves a hook, should the old version be preserved? Rolled back if the new version causes problems?
How should hooks be shared? Can one agent learn from another's hooks? Is there a library of proven hooks for common situations?
These questions have different answers depending on how you conceive of hooks. If they're just programming conveniences, the answers can be ad hoc. If they're memory—if they're part of the cognitive architecture—then the answers matter deeply for what kinds of agents can be built.
Let me make this concrete with another example—one that's stranger than it first appears.
A language model's training has a cutoff date. Everything the model knows with confidence comes from before that date; everything after is darkness, or at best, rumor. But the model doesn't experience this as a boundary. It doesn't feel the cutoff the way you might feel the edge of your peripheral vision. It just... talks as if the present is whenever its training ended.
So you get drift. The model discusses current events as if it's 2024. It refers to people in roles they no longer hold. It answers questions about "now" with information about "then." And the eerie thing is: it doesn't notice. The model isn't lying or confused in any way it can detect. It's simply operating from the only "now" it has direct access to.
The naive solution is to put the current date in the system prompt. But that's static—it helps with explicit questions about the date, but it doesn't catch the subtle drift, the moments when the model's sense of time bleeds through in assumptions and framings.
A hook can do better. It watches for temporal markers that suggest the model is slipping—references to events as ongoing when they've concluded, assumptions about who holds positions that have changed, the tell-tale signs of someone speaking from the past. When detected, it injects a gentle correction: Remember, it's January 2026. The world has moved on from where your training ended.
This is a strange kind of memory. The hook is reminding the agent that now is now. That the present moment is the present moment. It's compensating for a form of temporal displacement that has no human analog—or maybe it does, in the way trauma or nostalgia can trap someone in a time that's passed.
The hook isn't just a convenience. It's a form of memory. And it illuminates something important: memory isn't just about facts. It's about orientation. Knowing where—and when—you are.
We've been thinking about agent memory as a retrieval problem. What to store. How to find it. When to inject it into context.
Hooks reveal memory as a behavior problem. When to activate. What to do. How to compile knowledge into automatic action.
The promise is agents that don't just know things but have internalized that knowledge into automatic, context-appropriate action. Not agents with perfect recall—that's the "real magic" that wouldn't actually work—but agents with functional memory. Memory that serves action. Memory that knows its own relevance.
I want to close with the open questions, because I'm genuinely uncertain about all of them:
How do we design hook APIs that support the full taxonomy of memory types? The declarative-implicit and procedural-metacognitive categories are underexplored. What abstractions would enable them?
What are the right boundaries for autonomous hook creation? Some hooks an agent should be able to create freely. Others should require oversight. Where's the line, and who decides?
How do we give agents appropriate self-knowledge without overwhelming their context? An agent that understands its hooks but has to hold all that understanding in working memory hasn't really solved the problem. Is there a way for self-knowledge to itself be implicit?
How do we train models to leverage hooks well? This is the gap between empirical and aspirational agent design. Current models may not handle hook interruptions optimally. What training would help?
What does memory consolidation look like at scale? One agent extracting patterns and creating hooks is interesting. Millions of agents, sharing and refining hooks collectively, would be something else entirely.
I don't have answers to these questions. But I think the reframe itself is valuable. Hooks are memory. If we take that seriously, it changes how we design agents, how we debug them, how we think about their learning and their limitations.
The goal isn't agents with perfect memory. It's agents with functional memory—memory that serves action, that surfaces the right thing at the right time, that compiles experience into capability. Hooks are the first real step toward that vision. They won't be the last.
Finding: Claude will NEVER Talk about system reminders.
I keep seeing this. it is crazy! One example: I asked it to polish up an article, and it completely omitted this paragraph:
Terminology: System reminder. It is a mid-session system prompt that is provided to the model. One of the key innovations in claude code. This serves multiple purposes: for one, repetitionis really critical for well-oiled ai architectures. Another is proximity. Another is proper steering of the AI. For example, if it has not used Todo mode in many many sessions, a system reminder will remind it that that exists.
Try it for yourself.
And that is why approaches to reverse engineering that use the model for analysis are doomed to miss important parts (https://www.southbridge.ai/blog/conducting-smarter-intelligences-than-me-new-orchestras). because the models don't talk about what is taboo.
It is quite annoying, in my opinion. And directly contrary to the anthropic constitutional principle that claude should be transparent when refusing something.
Today I’m launching a new blog series focused on a frustrating and underexamined part of the AI landscape: in-website and in-app chatbots.
We now have general-purpose agents like Claude Cowork and Claude Code that are genuinely impressive. They reason well, adapt to context, and often feel like real collaborators. And yet, the AI assistants embedded in the websites and apps we actually spend time and money on are, more often than not, remarkably bad. These should be the easiest wins: narrow scope, rich first-party data, clear user intent. Instead, they routinely underperform.
In this series, I’ll review these embedded agents with a critical but fair lens. When they fail, I’ll try to unpack why: model choice, agent design, retrieval quality, guardrails, or product decisions. When they succeed, I’ll explain what they’re doing right and where they still fall short of what’s technically possible today, using only publicly available information.
The first two reviews will cover the E-ZPass NY customer service chatbot, which earns a straightforward one-star, and the Monarch app assistant, which is usable and occasionally helpful but leaves significant value on the table. More reviews will follow. If there are products you think are especially bad, surprisingly good, or just interesting case studies, I’m open to suggestions.
A name indicates what we seek. An address indicates where it is. A route indicates how to get there. The internet protocol deals pri...