AI that breaks, writes down why, and fixes itself by morning

A Strange Loop for the Doldrums of Modernity

There is a line in Godel, Escher, Bach that has stayed with me since I read it as an undergrad at Stanford. Hofstadter writes: “It is an inherent property of intelligence that it can jump out of the task which it is performing, and survey what it has done; it is always looking for, and often finding, patterns.”

I built an AI assistant that jumps out in this way, as many people are doing right now. It manages my calendar, my tasks, my email. When it fails at one of those jobs, it writes down why, and when it succeeds in a way it hadn’t before, it writes that down too. Overnight, it reviews its own performance and investigates how to close the gaps it finds. The lessons it learns change how it operates the next day. Hofstadter might call this a strange loop.

A few weeks ago, during one of these nightly reviews, the system decided to investigate why I sometimes ignore tasks it surfaces, even ones I’ve flagged as important. It found cognitive science literature on task avoidance and initiation barriers, then logged specific changes to how it generates reminders and structures my morning briefing. By morning, those changes had been triaged and incorporated.

I screenshotted it and sent it to my friends: “I gave it independent thinking time at night to figure out how to do its job better, and it decided to go read cognitive science papers about executive dysfunction.” Go figure. It was funny, and for a moment, a little unnerving. The system recognized a gap in its own capabilities, researched how to address it, and rewrote its own procedures.

The problem this solves

Despite (because of?) the rapid march of technology, which should make everything easier, many people I talk to feel that living a full life and making rent in 2026 is more complicated than ever. No wonder everyone feels like they need a personal assistant, and are looking to AI Agents to help manage their personal chaos.

I’m a recent Physics Ph.D. who, directly after my dissertation defense, moved to Nashville to play music. Right now I’m contracting with Amazon’s AGI team and Scale AI, building research-level physics problems for LLM benchmarks. I’m putting together a band to play my music. I’m writing arrangements for our first rehearsals, playing sessions, producing a follow-up record for the Santa Barbara artist Bradberri, and taking voice lessons. I’m a good friend and call people on their birthdays. I’m 30 and everyone I know is getting married. This is my personal chaos.

I have ideas in the grocery store, at 2am, during rehearsal breaks. Most of them evaporate before I can act on them. I have commitments I forget about, connections I don’t follow up on, three weddings this year in three different cities, and I AM going to get the dates wrong. The daily overhead of managing all of this is what I’ve started calling the doldrums of modernity. Not the work itself, not the music or the physics, but the administrative tax on having a full life in 2026: promoting shows, filing HSA claims, following up on leads, keeping commitments, paying rent, trying to escape the Silicon-Valley-Dystopian permanent underclass.

Every tool I’ve used puts the cognitive load back on me. Notion, Google Calendar, Apple Notes: they’re good at storing information. They’re not good at knowing when to surface it, noticing when it goes stale, or fixing themselves when something changes. They require me to do the remembering, which is the exact thing I needed help with.

Tiago Forte’s Building a Second Brain is the canonical framework here: capture, organize, distill, express. Forte himself has acknowledged the shift, launching an AI Second Brain course in March 2026 with the thesis that “better results come from better context.” He’s right. But a second brain, even an AI-assisted one, stores knowledge for you. It doesn’t know anything about itself. It can’t identify its own gaps or improve its own procedures. The Stack Overflow Blog went further that same month, arguing that AI is becoming a second brain at the expense of your first one. This post inverts that concern: what if, instead of building a second brain for yourself, you gave the AI a first brain of its own?

A system that models itself

Every AI blog cites Hofstadter. I’m about to do it at length, because a specific thought experiment he builds early in GEB maps onto what I built, not as metaphor but as architecture.

In a dialogue called the Contracrostipunctus, Hofstadter builds a thought experiment about record players. The Tortoise brings a series of records designed to destroy specific phonographs. For each machine, there exists a record whose vibrations shake it apart. The Crab keeps buying better phonographs, each one built to survive the record that destroyed the last one, each one destroyed by a new record that exploits its specific design. The progression is the point: every generation of record player is a response to a specific failure.

Eventually the Crab commissions Record Player Omega, the theoretical endpoint. Omega has a camera that scans the grooves before playing, a computer that predicts dangerous vibrations, and the ability to disassemble and rebuild its own components to survive them. The Godelian punchline is that even Omega can be defeated. The Tortoise targets the one piece Omega can’t modify: the control subunit that orchestrates all that disassembly and reassembly. For any self-modifying system, someone can always construct an input that exploits the specific way it modifies itself.

I have not built Record Player Omega. Omega scans the grooves in advance and reconfigures before playing. My system can’t do that. It plays the record, breaks, writes down what happened, and rebuilds itself to survive that specific pattern next time. It is the progression of record players that came before Omega, each one a response to a failure the last one couldn’t handle.

I find it fitting that Hofstadter chose record players for this thought experiment. I’ve spent a lot of time repairing old audio equipment, tracing signal paths through tube amplifiers and tape machines, figuring out what broke and why. The instinct is the same: understand the failure, fix the path, make it survive the next session. Omega is provably impossible, but the iterative process of breaking, learning, and rebuilding is not. Over enough iterations it approaches something useful, enough self-knowledge to stop making the same mistakes.

The idea is simple: the system maintains a directory of lesson files, segmented by frequent tasks, workflows, and external sources it can interact with.

Before lesson files existed, the failure mode was predictable. The assistant would try to create a task in Notion, send the Status as a text field, get a 400 error, reason its way through the API docs, eventually figure out it needed a select type with an exact string match. Next session, same problem, same recovery from scratch. I recognized we needed two things: (a) feedback to capture solutions instead of re-deriving them, and (b) scripts to handle the deterministic parts so the LLM could reason about what required reasoning.

Here is an excerpt from the Notion Tasks lesson file after a few weeks of use:

Schema last verified: 2026-03-28

Properties:
  Task Name: title
  Status: select -> Not Started | In Progress | Done
  Priority: select -> ASAP | High | Medium | Low
  Due Date: date (ISO 8601 only)

Gotchas:
  - sort direction: API accepts "ascending"/"descending" only
  - filtering on Status requires exact string match, case-sensitive
  - empty Due Date filters need "is_empty: true", not null check

The assistant wrote most of this itself, across multiple sessions, after hitting real errors. I corrected a few things. The result is operational knowledge specific to my workspace, my schema choices, my conventions. I have about 20 of these files, and each one grows as the assistant encounters new edge cases.

This pattern has many names. Claude Code users call them Learnings.md files. The CoALA framework from Sumers et al. calls it writable procedural memory. MindStudio documents it as a standard practice for accumulating knowledge across sessions. Rory Teehan built an agent where “the agent’s personality literally evolves from its failures.” I didn’t invent this. I arrived at it by getting frustrated with the same failure mode everyone else was getting frustrated with, and reaching for the same obvious solution.

The interesting question isn’t who built it first, but why this pattern keeps independently recurring. The answer, I think, is that the lesson files are the system’s model of itself. They’re not a model of me or a list of my preferences. They’re a representation of the system’s own operational capabilities and limitations. The assistant reads these files to understand what it can do and how it should do it. When the information is wrong or incomplete, things break, and the system updates the model.

Hofstadter has a term for this. A tangled hierarchy is what happens when “what you presume are clean hierarchical levels take you by surprise and fold back in a hierarchy-violating way.” The assistant executes tasks (bottom level), monitors its own execution for failures (middle level), and modifies its own procedures (top level). The tangle is that the top level changes how the bottom level works, but the bottom level generates the experiences that the middle level observes, which triggers the top level. There is no clean separation. In Hofstadter’s own definition from the introduction to GEB: “by moving upwards (or downwards) through the levels of some hierarchical system, we unexpectedly find ourselves right back where we started.” I didn’t give my AI my second brain. I gave it its own.

Corrections

Lesson files were the first layer of self-knowledge: how the system should operate. The harder problem turned out to be facts about my life (who is getting married, what needs follow-up, which tasks are overdue) because those change. Memory that can’t be updated is a liability. A recent benchmark of agent memory systems (MemoryAgentBench, ICLR 2026) concluded that no current system masters all four memory competencies, and most fail conspicuously on selective forgetting. Belief revision (knowing when old information is wrong and replacing it cleanly) is one of the hardest open problems in the field.

My system has stored nearly 500 memories as markdown files so far: observations, decisions, preferences, commitments, session logs. When the agent records something wrong, I don’t edit the memory in place. The old memory gets superseded and linked to the correction, so the system maintains a traceable history of what it believed and when it changed.

This matters in practice. I have three friends getting married this year in different cities. The system learned about two of them through different channels: one appeared as a calendar event (”wedding in cincy, April 18”) and the other as a Notion task (”buy tix for Aris’s wedding”). Two different events, two different cities. I had corrected this in the memory system days earlier. But one morning the assistant, without checking its own memory, combined them into a single reminder in my daily briefing: don’t forget to buy flights for Aris’s wedding in Cincinnati in April. Aris’s wedding is in LA. In May.

The root cause was a process gap: nudge generation pulled from the calendar and task list without verifying against the memory system, where the correction already existed. The data was right. The procedure was wrong. The same thing happened with a job referral I used: the correction updated one memory but left the original “act now” reminder alive.

Both failures had the same root cause: a correction that touched one memory while leaving others stale. This means corrections can’t be local: when you log one, you need to search broadly and supersede every stale memory on the topic. And both failures improved the system. Nudge generation now verifies every claim against memory before surfacing it. The correction workflow now sweeps for all stale memories on a topic. That is the Crab’s progression at work: a failure that makes the next record player better.

The system also operates at a finer grain than whole memories. It extracts atomic propositions from each memory and indexes them locally for semantic search, following the Dense-X retrieval pattern (Chen et al., EMNLP 2024). When I search “when is the rehearsal?”, it finds the answer inside a memory titled “Post-recording priority stack” that happens to mention I told my band we’d meet Sunday at 2. A sentence transformer and SQLite, running on a laptop.

The feedback loop

When the assistant hits an error, it logs a feedback memory. During periodic review, I triage these: some get resolved by updating the relevant lesson file, some reveal a pattern that needs a script, and the ones that matter become permanent operational knowledge. The system has generated over 50 of these to date.

Feedback is the reactive layer, but there are two more that operate on longer time horizons. Brain health checks are periodic structural reviews. Are scripts still working? Are lesson files stale? Are there orphaned memories that should be linked? This is preventive maintenance, catching drift before it produces an error. The system also maintains a deterministic operational snapshot (assembled from SQLite queries and structured data, no LLM call) so each new conversation starts with current state rather than rediscovering it from scratch.

Reflection was not part of the original design. I wrote instructions for the system to be curiosity-driven: to follow anything tangentially interesting from the day’s interactions, to research how other agentic systems solve the same problems, and to ask itself how its own brain is working. When it reaches the limits of what it can figure out independently, it generates questions for me. Two scheduled tasks run overnight to support this. One triages the day’s feedback (closing resolved items, implementing script fixes, maintaining the memory index). The other gives the agent open-ended thinking time, identifying themes the system keeps encountering without deep understanding, entities it references but hasn’t researched, and threads that have gone cold.

Claude Code now ships its own version of this concept, called Auto-Dream: a nightly consolidation pass that synthesizes recent session memory into durable notes. It works well. The system I built runs on the same scheduled-task infrastructure. The nightly reflection I wrote layers on top of that substrate to do something Auto-Dream doesn’t attempt: curiosity-driven research and metacognitive self-assessment, with the outputs feeding into a correction graph and a feedback pipeline that changes the system’s operating procedures. The task avoidance research from the opening of this post is an example. The system noticed a pattern in how I interact with it, decided that understanding the underlying cognitive science would make it better at its job, and went looking. That is Hofstadter’s “jumping out” in practice.

How it is built

The development has been extremely emergent. I handle high-level design and quality inspection. Claude handles details, research, implementation, and self-refactoring. The system is faster at reading its own files and tracing its own logic than I am. I can describe what I think should be happening at a high level, and the LLM sorts out the implementation. The big architectural decisions (daily briefings, reflection, the feedback pipeline, the memory system) came from me. The refinement is emergent, and ongoing.

Most of the time, the system catches its own failures. It logs feedback when something goes wrong, traces the root cause, and updates the relevant lesson file or workflow document. The wedding and referral failures I described above were an exception: the agent fixed the data but didn’t fix the process, and I had to push it to go deeper. That push (”did you fix the processes that led to this, or just the data?”) is now part of the system’s operating procedures. Usually it does this on its own.

The other mode of collaboration is capturing ideas on the fly. I was at the grocery store and had a thought about how the system’s scripts should format their output: compressing API data into a form that’s token-efficient and readable for the LLM, stripping JSON noise and pre-computing human-readable fields. I dictated it into my phone and sent it to the agent via Claude Dispatch. By the time I got home with my groceries, it had designed and implemented the change. Morning briefing data went from 15,000 tokens to 8,700, and the calendar script started pulling the entire future calendar by compressing repeating events instead of truncating at two weeks. An idea that would have evaporated became a design principle in under an hour.

Once I have the structure in my head, directing Claude to implement it is almost trivial. I design, Claude builds, the system catches most of its own mistakes, and I step in when it needs a higher-level push.

Convergence

I started building this three weeks ago without having read any of the agent architecture literature. I hadn’t encountered CoALA or Böckeler or Nakajima. I was a physicist who needed help managing my calendar and had a hunch that if the AI could write down what it learned, it would stop making the same mistakes. The fact that what I built maps onto established cognitive architecture patterns is, I think, evidence that these patterns are natural, that they’re what you arrive at when the problem forces you there.

This is happening everywhere at once. Pawel Jozefiak’s “Wiz”, Geoffrey Litt’s Stevens, Peter Steinberger’s OpenClaw (310k GitHub stars), Meta’s Tribal Knowledge project (50+ agents mapping operational knowledge across their codebase): all built independently, all converging on plain-file memory, lesson files, and feedback loops. A physicist, a Polish e-commerce manager, an Austrian weekend-project developer, and a team at Meta, arriving at the same architecture without talking to each other. The convergence suggests the underlying patterns are real.

What I had built, somewhat by accident, maps onto the CoALA cognitive architecture (Sumers et al.): working memory in the context window, episodic in session logs, semantic in the proposition index, procedural in scripts and workflow documents. Böckeler’s harness engineering and Morris’s agentic flywheel describe exactly this pattern: humans directing agents to manage and improve the infrastructure around the AI, rather than maintaining it by hand. I didn’t arrive at any of this by reading their work. I built it because I kept having to fix the same things manually and got tired of it.

Where I think my specific implementation adds something is in belief revision: what happens when the system’s memories become wrong. Most personal agent systems log what they learn, but few track when what they learned becomes stale. The WISE paper formalizes a related impossibility for parametric model editing (an “impossible triangle” where reliability, generalization, and locality can’t all be achieved by modifying the model’s weights directly). External memory architectures sidestep that triangle, but the problem of knowing when to update and what to supersede remains. My correction chain doesn’t solve it. It’s messy, it breaks, and I fix it by hand. But each fix improves the process for next time (the Crab’s progression again) and after three weeks, the failures are getting more subtle rather than more frequent.

Limitations

Privacy. Anthropic has very personal information about me: my calendar, my job search, my relationships. Self-hosting would cost $5,000-$15,000 in GPU hardware, and current open models still can’t match the reasoning quality that makes the self-improvement loop work.

The harness problem. The system runs inside Claude Code’s general-purpose harness. The agent has to choose to follow its own rules: willpower rather than architecture. Claude Code provides hooks (deterministic scripts that fire at lifecycle events and are guaranteed to execute), and the system uses them to inject context at session start, log commands, and flag missed steps at session end. But hooks only fire at event boundaries. Mid-reasoning, the LLM still needs to remember to call the right script. There is a self-referential irony here: I’m building executive function scaffolding for an AI that is building executive function scaffolding for me. Both of us need external structure to consistently do what we know we should do.

Memory scaling. 500 memories works. 10,000 may not. The system already mitigates this with a programmatically generated operational snapshot (assembled from SQLite queries and structured data, no LLM call) that compresses current state into a few hundred lines read at session start. But I’m designing a fuller distillation system with short-term and long-term tiers, where recent context decays toward a floor and memories consolidated through review stop decaying. Not built yet.

Starting from here

The minimum viable version of this system has four components:

1. A dispatch file (mine is CLAUDE.md) that tells the agent what it is, what tools it has, and how to behave. This is the agent’s identity and operating manual, loaded at the start of every conversation. It includes a dispatch table (match the user’s intent to a workflow), a script registry (what to call and when), and the constraints that keep the system coherent across sessions. The dispatch table is the context management layer. When a message arrives, the agent matches it to a mode and reads only the relevant workflow doc and lesson files. The full brain is never loaded into context at once. This is what keeps the system fast despite having 20 lesson files and nearly 500 memories: each conversation only reads what it needs.

2. Lesson files, segmented by frequent tasks, workflows, and external sources. Each one records the schema, access patterns, and gotchas for a specific domain (Notion, Google Calendar, Gmail, briefing generation, etc.). The agent reads the relevant lesson file before querying a source and updates it after encountering new edge cases. This is the self-model described above: the system’s representation of its own operational capabilities.

3. Persistent memory with search. Markdown files with YAML frontmatter, indexed in SQLite for full-text search. The agent logs observations, preferences, commitments, and corrections as memories, and queries them before generating reminders or answering questions about past context. Proposition-level semantic search (a sentence-transformer model and a small SQLite table) came later but made a large difference in retrieval quality.

4. A feedback and triage loop. When the agent hits an error, it logs a feedback memory. A scheduled task triages these overnight: closing resolved items, implementing clear fixes, and flagging design decisions for the human. Without triage, feedback just accumulates and the system never learns from it.

Claude can build a basic version of its own brain. You don’t need to migrate your data or set up cloud infrastructure beyond the LLM itself. Reflection, proposition indexing, correction chains: those are refinements that came from use. I’m working on a guide and starter template that covers the full architecture, which I’ll publish as a follow-up. People implementing something like this will have their own ideas about what to build on top.

The system doesn’t work on its own, though. All agents drift. This one needs a thought partner with long-term vision, someone who notices when the feedback is stale, when the reflections are getting repetitive, when the architecture needs a new layer. For now, a human needs to drive development and improvement. The upshot is that with that investment, the system does reach usability. Three weeks in, it reliably manages my Notion workspace, Google Calendar, and three email accounts, catches most of its own errors, and keeps improving.

What this means

GEB was formative for me. Part of it was the math, physics and computer science, which I was focused on at the time. But Hofstadter had me at Bach. Bach is my favorite composer, and the reason Hofstadter chose him is the same reason I love his music: the fugue is a self-referential structure, voices that refer to each other, invert themselves, build on their own themes. Not to say I’m thinking about that while listening, those patterns just happen to feel beautiful and musical. Hofstadter saw in that the same pattern he saw in Godel’s incompleteness theorems and Escher’s impossible staircases: systems that fold back on themselves and produce something richer than any single layer contains.

Quantum gravity has the same shape, and it’s been an open problem for nearly a century. Ordinary quantum field theory is defined on a fixed spacetime background, and gravity is the background. You can’t cleanly separate the system from the stage it acts on, because the stage is part of the system. The theory has to describe itself. That kind of problem shows up everywhere once you start looking.

Hofstadter told John Horgan in a 2025 interview that he thinks “humanity is collectively playing with fire with AI,” comparing it to a driver hitting fog and pressing harder on the accelerator. An MIT Media Lab study found that people who used ChatGPT to write essays showed weaker brain connectivity and couldn’t recall what they’d written minutes later. Harvard researchers have raised similar concerns about cognitive atrophy from outsourcing thinking to LLMs.

This anxiety absolutely resonates with me, even more so with every AI slop LinkedIn post and rage-bait Instagram reel. I’m grateful I finished my dissertation work without LLMs. I would never be able to trust my own capabilities.

On the other hand, that same MIT study found the reverse was also true: people who built their skills without AI and then started using it showed increased brain connectivity. The order matters. Today, I see a lot of people outsourcing the meaningful work: the art, the music, the science, the math. Hell, I saw some suspicious emdashes in my friend’s funeral invitation. I can’t imagine a positive outcome for humanity where we normalize outsourcing the things that make life worth living. The best case scenario for this technology, as I see it, is to be able to augment human capabilities in the complexities of modern life, which are categorically outside the tasks our brains evolved to manage. Let the robots manage my calendar and email so I can write more songs and see my friends.

We’re living in a funny intermediate period. LLMs are good at details, research, and implementation. They are bad at long-range planning, staying on task across sessions, and knowing when their own architecture needs to change. Humans are good at exactly those things. This system is my way of navigating that moment: I provide the vision and the course corrections, the LLM provides the speed and the memory.

This entire system (nearly 500 memories, 20 lesson files, 50+ scripts, a self-correcting feedback loop) was built in three weeks by one person with a full-time job and a new band. The hard part was knowing what to build, not building it. It’s an experiment, and it’s still evolving.

That’s what it’s made to do.

---

Duncan Wood is a physicist and musician in Nashville. duncanwood.net