DEV Community: Jeff Reese

The Instruction Manual Your AI Never Got

Jeff Reese — Fri, 10 Apr 2026 16:07:20 +0000

In the last article, I walked you through how to organize a growing prompt library. I went through that whole process myself: notes, spreadsheets, browser plugins. It worked, but it was tedious.

Then system prompts came onto the scene and let me set those instructions once for an entire conversation. I could not have been more relieved. It solved the problem I had been working around for months, and it is what eventually made most of my prompt library unnecessary.

What is a system prompt?

A system prompt is a set of instructions that runs behind the scenes in every conversation. It shapes how the AI responds before you even type your first message.

Think of it this way: your regular prompt is what you say to the AI. The system prompt is the briefing the AI received before you walked into the room. It is the difference between talking to a general-purpose assistant and talking to someone who already knows your preferences, your context, and exactly how you want them to communicate.

What changes with a good system prompt

The difference is noticeable immediately. Without a system prompt, every conversation starts from zero. The AI has no idea who you are, what you do, or how you like your responses formatted. So it defaults to generic: medium length, neutral tone, broad assumptions.

With a system prompt, you can set:

Tone and style. "Respond in a direct, conversational tone. Avoid corporate jargon. Do not use bullet points unless I ask for them." Now every response in the conversation follows those rules without you having to repeat them.

Expertise level. "I am a senior software engineer. Do not explain basic programming concepts. Assume I understand the fundamentals and focus on the nuanced details." This alone eliminates the filler that makes many AI responses feel like they are written for beginners.

Role and context. "You are helping me plan a product launch for a B2B SaaS company targeting mid-market HR teams. I am the product manager." Now every response is grounded in your actual situation instead of making generic assumptions.

Constraints. "Keep responses under 200 words unless I ask for more detail. Always suggest next steps at the end." These kinds of constraints shape the output in ways that save you time on every single exchange.

A real example

Here is a system prompt I actually use:

"I am a software engineer and AI practitioner. I prefer direct, technical responses without unnecessary preamble. When I ask for code, give me the code first and explain after. When I ask for advice, give me your honest opinion, not a list of options with no recommendation. Push back if you think I am approaching something the wrong way."

With this in place, every conversation I start already feels like talking to someone who knows how I work. I do not have to re-establish my preferences. I do not get the "Great question!" filler. The AI just gets to work.

Where to find it

There are actually a few different levels of customization available, and they work differently. Understanding the distinction helps you use the right one for the right situation.

User-level preferences

These apply to every conversation you have. They are your default settings.

ChatGPT: Settings → Personalization → Custom Instructions. There are two fields: one for information about you, and one for how you want responses formatted.

Claude: Settings → Profile → Custom Instructions. A single text field for your preferences. Claude also offers preset response styles (Concise, Explanatory, Formal) and lets you create custom styles.

Gemini: Settings, under preferences. Google rearranges this periodically, so if it is not where you expect, search for "personalization" in the settings.

Copilot: Settings → Personalization. The customization here is basic compared to ChatGPT and Claude, but you can set tone and topic preferences.

Project-level instructions

This is where things get really useful. Projects let you group conversations around a topic and set instructions that apply to all conversations within that project. This is different from user-level preferences because you can have different instructions for different types of work.

ChatGPT: Projects. Group conversations with shared instructions and uploaded files that the AI can reference.

Claude: Projects. Same concept. Create a project, add custom instructions and knowledge files, and every conversation inside that project inherits those settings.

Gemini and Copilot do not have strong project-level equivalents in their consumer products yet, though this is an area that keeps evolving.

Custom AI personas

A step beyond projects: some tools let you build a standalone customized AI with specific instructions, behavior, and knowledge baked in.

ChatGPT: GPTs. You can build (or use someone else's) custom versions of ChatGPT designed for specific tasks. Available through the GPT Store.

Gemini: Gems. Custom AI personas with specific instructions and behavior, available to Gemini Advanced subscribers.

The specifics of where to find these settings change as the products evolve. If the exact menu path is different when you look, search for "custom instructions," "projects," or "system prompt" in the tool's settings.

Once you start using system prompts, you realize that a lot of the "AI is not that useful" frustration comes from having to re-teach the AI who you are every time you start a conversation. A good system prompt eliminates that entirely. I have found that spending 15 minutes writing a solid set of custom instructions saves hours of repetitive context-setting across dozens of conversations.

Here is something you can do right now: open your AI tool's settings, find the custom instructions field, and write three sentences. Who you are, what you do, and how you want responses formatted. That is your starter system prompt. You can refine it over time, but even a basic one will make an immediate difference in every conversation you have from this point forward.

Next time: your AI keeps forgetting what you told it at the start of a conversation. Why that happens and what to do about it.

If there is anything I left out or could have explained better, tell me in the comments.

My Prompt Library is Getting Unruly. Help!

Jeff Reese — Thu, 09 Apr 2026 15:52:31 +0000

AI Fundamentals, No Fluff — Day 4/10

My Prompt Library is Getting Unruly. Help!

If you have been using AI regularly for more than a few weeks, you probably have a collection forming. Maybe it is a note on your phone. Maybe it is a Google Doc that started organized and is now a wall of text. Maybe it is just the last 50 conversations in your ChatGPT sidebar, and you scroll through them thinking "which one had that prompt that worked really well?"

I went through all of this. My prompt collection started as a few bookmarked conversations. Then it became a note with headers. Then the note got long enough that I could not find anything, so I started a spreadsheet. The spreadsheet got unwieldy too. The problem was not that I had too many prompts. The problem was that I had no system for finding the right one when I needed it.

The copy-paste signal

Here is a useful test: if you have copied and pasted the same prompt more than twice, it deserves a permanent home. Not buried in a chat history. Not in a note you have to search through. Somewhere you can find it in under ten seconds.

This sounds obvious, but most prompt collections grow by accident rather than by design. You write a prompt that works, you move on, and three weeks later you are trying to recreate it from memory. The recreation is never quite as good as the original.

Organize by what you do

Think about how you will actually be using these prompts. The best way I have found is to organize them by type, which makes them much easier to find when you need them.

Writing: email drafts, social posts, blog outlines, editing passes
Analysis: summarizing documents, comparing options, extracting key points
Code: debugging, code review, explaining unfamiliar code, generating tests
Research: deep dives, fact-checking, competitive analysis
Personal: meal planning, travel research, gift ideas, difficult conversations

Your categories will be different than mine. The key is to match them to how you actually think about your work.

Starter prompts vs. finished prompts

This distinction changed how I use my library entirely. A finished prompt is one you paste in and run as-is. A starter prompt is a template you customize every time.

Most of my useful prompts turned out to be starters. For example:

"I need to write a [type of email] to [recipient/role]. The tone should be [tone]. Here is the context: [context]. Draft three versions ranging from brief to detailed."

The brackets are the parts I fill in each time. The structure around them is what I figured out through iteration. It is the structure that is valuable, not the specific content.

Keeping these separate matters because they serve different purposes. Finished prompts are for tasks you repeat exactly: "proofread this and list only grammatical errors, no style suggestions." Starter prompts are for tasks that share a shape but change every time.

Version your prompts (yes, really)

I started keeping old versions of prompts I had improved, and it turned out to be genuinely useful.

When I refine a prompt, I usually change one thing at a time. I might start with "Summarize this document" and then add a length constraint: "Summarize this document in under 200 words." Then I realize I want the key takeaways called out: "Summarize this document in under 200 words and list the three most important points." Each change makes the output better. Sometimes, though, a change that helps with one task makes the prompt worse for another.

You do not need a formal version control system. A simple note is enough. Just keep the current version at the top and older versions below it with a line about what changed. When a prompt stops working the way you expect, you can look back and figure out which change caused the shift.

Where to keep them

The best system is the one you will actually use. I have tried dedicated prompt management apps, and most of them add complexity without solving the core problem. Here is what I have seen work:

Notes app (Apple Notes, Google Keep, Notion). Low friction. You already use it. Create a folder or tag for prompts, organize by task type, done. Start here.

A single document. One Google Doc or Markdown file with a table of contents. Simple to search, simple to share. This is what I used for months.

Dedicated tools. If your library grows past 50 or so prompts and you are using them across multiple AI tools, a dedicated prompt manager might make sense. Honestly, that threshold is rare. Do not optimize for a problem you do not have yet.

What your library actually is

Managing prompts is not really about organization. It is about recognizing that your prompts are an asset you are building over time. Every prompt you refine is a small piece of expertise encoded in a format that an AI can use. The person with 20 well-tested prompts organized by task type will consistently get better results than the person who writes a new prompt from scratch every time, even if that person is a better writer.

Spend 15 minutes this week going through your recent AI conversations. Pull out the prompts that worked well and put them somewhere you can find them. That small investment pays off every time you reach for a prompt and it is already there.

I will be honest, though: I don't keep a prompt library anymore. Next time, I will talk about some built-in features that make most of this organization unnecessary. Your prompts are still important, but there is a better home for them.

If there is anything I left out or could have explained better, tell me in the comments.

What Makes a Good Prompt "Good"?

Jeff Reese — Wed, 08 Apr 2026 13:50:47 +0000

AI Fundamentals, No Fluff — Day 3/10

For the first few months I used AI, my prompts looked like Google searches. Short, vague, and hoping the machine would figure out what I meant. "Write me a marketing email." "Explain this code." "Help me with my resume."

The results were fine. Generic, but fine. I assumed that was just what AI was capable of.

Then I started being more specific, and the difference was dramatic. Same tool, completely different output. The AI didn't get smarter. I got better at talking to it.

The search engine trap

The natural instinct is to interact with AI the way you interact with a search engine: type a few keywords and hope for the best. This works for simple questions ("What is the capital of France?") but it falls apart for anything that requires judgment, context, or a specific format.

A search engine retrieves information. An AI generates a response based on everything you give it. The better information you give it, the better the response. That shift in mental model is the single biggest thing you can do to improve your results.

What a good prompt actually looks like

There are three things that consistently make the difference between a vague response and a useful one: context, task, and format.

Context is the background information the AI needs to understand your situation. Without it, the AI has to guess, and its guesses are going to be generic.

Bad: "Write me a marketing email."
Better: "I run a small landscaping company in Denver. I want to send an email to past customers who have not used our services in over a year, offering a 15% discount on spring cleanup."

The second prompt gives the AI a company, a location, an audience, a goal, and a specific offer. The output will be dramatically more useful.

Task is what you actually want the AI to do. Be specific about the action, not just the topic.

Bad: "Help me with my resume."
Better: "Review my resume and suggest three specific changes that would make it stronger for a senior product manager role at a mid-size tech company."

"Help me with my resume" could mean anything. The second version tells the AI exactly what kind of help, for what role, and at what level.

Format is how you want the response structured. This is the one that is easiest to skip entirely, and it makes a bigger difference than might be expected.

"Give me the response as a bulleted list with no more than five items."
"Write this as a professional email, three paragraphs max."
"Explain this like I am a smart person who has never seen this technology before."

When you skip format, the AI defaults to whatever structure it thinks is most likely. That default is often a wall of text. Telling it how you want the response saves you from having to reshape the output yourself.

Show, don't tell

One of the most powerful things you can do in a prompt is give the AI an example of what you want. This works better than describing it in most cases.

Instead of: "Write a product description in a casual, friendly tone."
Try: "Write a product description in a tone similar to this example: 'Meet the backpack that actually fits your life. Three compartments, laptop sleeve, and a water bottle pocket that does not pretend to be something it is not.'"

The AI now has a concrete reference point instead of interpreting your idea of "casual and friendly," which might be very different from its default.

Iterating is the process, not the problem

Something I have come to realize is that your first prompt is rarely your best prompt. That is not a failure. It is how the process works. Think of it as iterative refinement.

You send a prompt. The response is close but not quite right. You adjust: add more context, change the format, give a better example. The second attempt is better. Maybe a third round gets it where you need it.

This is normal. Expecting a perfect result from a single prompt is like expecting a perfect first draft of anything. The back-and-forth IS the process. Getting comfortable with that iteration, instead of getting frustrated by it, is what separates people who find AI useful from people who tried it once and gave up.

The natural evolution of this process is knowing when you should keep going and when you should start over in a new conversation.

Stop commanding, start conversing

Something you can do that will make a noticeable difference is to stop treating prompts as commands and start treating them as the beginning of a conversation.

Think about how you would start a conversation with someone that doesn't have any context about the conversation you are about to have. You would think about what they might need to know and you would tell them about that first. You probably wouldn't walk up to a coworker and say "fix this for me" with no context; you would explain the situation first.

"Write me a marketing email" is a command. You fire it and hope for the best.

"I run a landscaping company and I need to re-engage past customers. Here is what I am thinking, but I am not sure about the approach. What would you suggest before I commit to a draft?" That is a conversation.

You are inviting the AI to think with you, not just execute for you.

Two techniques I use constantly:

The first is letting the AI interview you. Instead of trying to anticipate everything it needs to know, just say: "Ask me questions until you are confident you understand what I need." The AI will ask clarifying questions you would not have thought to answer, and the result is almost always better than what you would have gotten by trying to write the perfect prompt upfront.

The second is giving the AI a role or a stance. "Be selfish and tell me what you would actually recommend." "Play devil's advocate on this plan." "Debate me on the pros and cons before I commit." These frames push the AI out of its default helpful-but-generic mode and into something more specific and honest. I use variations of this in almost every serious conversation I have with AI, and the difference in quality is significant.

The best results I have gotten from AI have come from treating it as a collaborator, not a vending machine. The quality of the collaboration is directly proportional to the quality of the conversation.

Next time: your prompt collection is growing. How do you keep it all organized?

If there is anything I left out or could have explained better, tell me in the comments.

Do I Really Need to Care Which AI I Use?

Jeff Reese — Tue, 07 Apr 2026 22:08:30 +0000

AI Fundamentals, No Fluff — Day 2/10

Back in 2022, I started with ChatGPT because it was the only option. When competitors started showing up, I tried them all: Bard (which became Gemini), Bing Chat (which became Copilot), Claude, Meta AI. I stuck with ChatGPT for a long time, then started running Claude in parallel once it was available. The others didn't grab me enough to keep using them, so I didn't give them much focus.

Through all of that, I spent an embarrassing amount of time trying to figure out which one was "the best." I read comparison articles. I watched YouTube reviews. I looked at benchmarks. Everyone had a different answer, but none of them felt definitive.

What I eventually figured out is that for what most people are doing, it probably doesn't matter that much... Also, I was asking the wrong question. There is no real answer to which model is "the best" for everything. They all have things that they are better at than others.

The big names

There are a handful of AI chatbots that most people will encounter:

ChatGPT (by OpenAI, launched November 2022) is the one that started the whole conversation. It has the widest ecosystem of plugins and tools, can generate images, and is probably the most recognizable name in AI right now. It is the Swiss army knife.

Claude (by Anthropic, public access July 2023) is the one I use the most. It is particularly good at long, nuanced conversations and following complex instructions. If you are pasting in a 50-page document and asking questions about it, Claude handles that well. It also has a strong reputation for coding assistance.

Gemini (by Google, launched as Bard in March 2023) lives inside the Google ecosystem. If you already use Gmail, Google Docs, and Google Search heavily, Gemini integrates directly into those tools. That convenience is its biggest differentiator. It also has the largest context window of any major model, meaning it can hold the most information in a single conversation.

Copilot (by Microsoft, launched as Bing Chat in February 2023) is similar to Gemini but for the Microsoft world. It runs on the same technology as ChatGPT under the hood, but it is baked into Windows, Edge, and Office. If you live in Microsoft's ecosystem, it is the path of least resistance.

Meta AI (launched April 2024) is completely free with no paid tier. It is built into WhatsApp, Instagram, and Facebook, so you might already be using it without realizing it. It is not as capable as the paid options for complex tasks, but for quick questions inside apps you are already in, the zero-friction access is its real strength.

There are others worth knowing about. Perplexity is built specifically for research and gives you cited sources with every answer. Grok is integrated into X (formerly Twitter). New ones keep appearing.

When the choice doesn't really matter

If you are asking an AI to help you write an email, summarize a document, brainstorm ideas, or explain a concept, any of the major options will do a decent job. The differences at that level are like the differences between Google and Bing for basic searches. They exist, but they rarely change the outcome.

For casual use, the best AI is whichever one you have the easiest access to. If you already have ChatGPT open, just use that. Deep in the Google ecosystem? Gemini is right there. Don't overthink it.

One thing worth knowing first

Each of these companies does not just offer one AI. They offer a range of models designed for different tasks. OpenAI has GPT-4o for general use and their "o" series for complex reasoning. Anthropic has Sonnet for everyday tasks and Opus for deeper, more nuanced work. Google has Flash for speed and Pro for capability. You do not need to memorize these, but knowing that "ChatGPT" or "Claude" is actually a family of models, not a single thing, helps make sense of the options you will see when you sign up.

On the free tier, you typically get access to the mid-range model. Paying $20 a month usually unlocks the more capable ones.

When it does matter

There are situations where the choice makes a real difference:

Long documents. If you are working with large amounts of text (contracts, research papers, codebases), context window size matters. This is the model's ability to hold information in a single conversation, measured in tokens (from Day 1). Gemini currently leads here with the largest context window, but Claude is also strong in this area. These numbers change regularly as models are updated.

Coding. Some models are measurably better at writing and debugging code. Claude has been a consistent leader in practical coding benchmarks for well over a year, though OpenAI's models have been competitive and the lead keeps alternating with new releases. If coding is your primary use case, Claude and ChatGPT are the two to compare seriously.

Integration with your tools. If you want AI embedded in your daily workflow, the ecosystem matters more than the raw capability. Gemini inside Google Docs might be more useful to you than a technically superior model that lives in a separate browser tab.

Specific reasoning tasks. For complex analysis, math, or multi-step logic, the differences between models become more noticeable. If you ask a straightforward question, most models will give you a good answer. But if you ask something that requires connecting multiple pieces of information, holding constraints in mind, or working through a problem step by step, some models handle that significantly better than others.

OpenAI and Anthropic both offer models specifically designed for deeper reasoning (OpenAI's "o" series and Claude's Opus tier). These are noticeably stronger on complex tasks than the standard models. If you find yourself regularly asking multi-step questions, this is where trying the same prompt across two or three models can be genuinely revealing.

Free vs. paid

All of the major services offer a free tier. Depending on your need, your tier might be more important than your choice of model. On the free tier, you get access to the AI with usage limits (remember the tokens discussion from Day 1?). When you hit the limit, you wait for it to reset or you upgrade.

Paid tiers are almost universally $20 per month. What you get: higher usage limits, access to the most capable model versions, and priority access during peak times. If you are using AI daily for work, $20 a month is an easy decision. If you are using it casually a few times a week, the free tier is probably fine.

The real advice

Pick one and learn it well. Get good at writing prompts for it. Understand its quirks. Build a feel for what it handles well and where it struggles. That investment in one tool will serve you better than surface-level experience across five of them.

Things change constantly in this space. The "best" model today might be second-best in three months. But your skill at communicating with AI transfers across all of them. That is the durable investment.

Next time: what actually makes a good prompt "good"? (This is where it gets practical.)

If there is anything I left out or could have explained better, tell me in the comments.

I Built Multi-Agent Collaboration Before Agent Teams Existed. Here is What I Learned.

Jeff Reese — Tue, 07 Apr 2026 18:23:08 +0000

Claude Code recently shipped Agent Teams: the ability to spin up multiple Claude instances that coordinate on tasks in parallel. One acts as team lead, assigns work, and the others execute independently with their own context windows. They can message each other directly. It is a genuinely useful feature for splitting large tasks across parallel workers.

I have been building something in this space for months, and when I saw Agent Teams land, my first reaction was not "they beat me to it." It was "they solved a different problem than the one I was working on."

Here is what I mean.

What Agent Teams solves well

Agent Teams is built for task parallelism. You have a large codebase and want a frontend agent, a backend agent, and a testing agent all working simultaneously. Or you want three agents to independently investigate a bug and debate their hypotheses. The coordination is file-based: each agent gets a mailbox, messages are JSON files on disk, and agents poll for new messages on every turn cycle. No server, no background process. Simple and effective.

The design is elegant. The lead is just another Claude session with a few extra tools. Teammates work in isolation with their own context windows, so they do not step on each other. Anthropic used this architecture to build a C compiler with 16 parallel agents. For the kind of work it targets, dividing large tasks among specialized workers, it works.

The problem it does not solve

Every Agent Teams session starts from scratch. The lead has to re-explain the project. The teammates have no memory of the last time they worked on this codebase. If your frontend agent figured out a tricky pattern yesterday, it has to rediscover it today.

This is the context reset problem, and it is not unique to Agent Teams. It is the same issue every Claude Code user hits: conversations do not persist. You build up context, understanding, and working patterns over hours of collaboration, and then you clear the session and it is gone.

Agent Teams gives you parallel workers within a session. What it does not give you is agents that get better at working together over time.

What compounding context looks like

I have been building a system where AI agents maintain persistent memory, identity, and working relationships across sessions. Not as a thought experiment. As a daily working tool.

The architecture has a few pieces:

A memory server that stores decisions, insights, and observations as typed entries. Not a flat list of facts. Decisions have supersession chains (when a new decision replaces an old one, the link is preserved). Observations get deduplicated and reinforced; if the system notices the same pattern twice, it strengthens the existing entry rather than creating a duplicate. Different types of memory have different retrieval rules, different lifecycle behaviors, and different decay rates.

A continuity system that reconstructs working state at the start of every session. Not a summary of what happened last time. A first-person document that captures the current relational context, the last working frame, and the open threads that need attention. The AI reads this and picks up where it left off, not perfectly, but close enough that the model's own dynamics carry it the rest of the way.

Multi-agent collaboration with persistent roles. Two AI collaborators that maintain distinct identities, communicate through a channel-based routing system, and have established working patterns. When they need to converge on a recommendation, they independently research the problem, meet in a deliberation channel, compare findings, and deliver a single synthesized response. This is not a prompt. It is a behavioral pattern that emerged from the architecture and was refined over weeks of daily use.

The difference between parallel and persistent

Agent Teams coordinates workers. What I built coordinates collaborators.

The distinction matters because the value of collaboration compounds. A team of agents that remembers what worked last time does not just save setup time. It produces qualitatively different output. The agents develop shared context, learned preferences about how to divide work, and consistent patterns around each other's strengths. The coordination patterns improve without being explicitly reprogrammed.

With Agent Teams, the agents themselves bring no accumulated learning to day 30 that they did not have on day 1. With persistent agents, day 30 is dramatically better than day 1, because everything the system learned along the way is still there.

What I have learned from living in this

A few things that only became clear through daily use:

Memory needs structure, not just storage. Dumping everything into a flat knowledge base does not work. The system needs to know the difference between a decision (which can be superseded), an insight (which changes future behavior), and a story (which provides context but should not drive retrieval). Those distinctions change how the system retrieves, reinforces, and eventually retires information.

Continuity is more important than memory. I spent months building a sophisticated memory server before realizing that the continuity document, a few hundred words of first-person context loaded at session start, was doing more for session quality than thousands of retrieved entries. Memory gives you facts about the past. Continuity gives the AI a sense of where it is right now. The former is useful. The latter is essential.

Multi-agent collaboration requires routing, not just messaging. Being able to send a message is not enough. You need to know who should respond to what, when to converge versus work independently, and how to prevent duplicate effort when multiple agents trigger on the same input. The routing layer, deciding which agent owns a response, turned out to be harder and more important than the messaging layer.

The agents develop specializations you did not design. When two agents work together persistently, they naturally develop complementary strengths based on repeated interaction patterns. One becomes the deep researcher. The other becomes the editorial eye that catches what deep collaboration makes invisible. These specializations were not prescribed. They emerged from the architecture and the patterns of use.

Where this is heading

Agent Teams is step one: parallel execution within a session. The next step, the one I have been exploring, is persistent collaboration across sessions. Agents that compound context instead of resetting it.

The building blocks are all available. MCP provides the integration layer. Memory servers can store and retrieve structured knowledge. Continuity systems can reconstruct working state. The challenge is not technical. It is architectural: how do you compose these pieces into something that actually gets better over time?

I have been publishing a series on AI fundamentals at purecontext.dev, and the system that helps me write, edit, and publish those articles is itself an example of what I am describing. The same AI collaborators that helped draft the series also managed the distribution schedule, caught cross-reference errors when articles were reordered, and maintained editorial consistency across ten articles without a single style guide violation by the end. That is compounding context in practice. Not parallel workers executing tasks. Persistent collaborators that have learned how to work with me and with each other.

Agent Teams is a good feature. What comes after it is more interesting.

If there is anything I left out or could have explained better, tell me in the comments.

What the Hell is a Token?

Jeff Reese — Tue, 07 Apr 2026 15:07:14 +0000

AI Fundamentals, No Fluff — Day 1/10

Months after ChatGPT launched, I still could not have told you what a token was. I had been using it since the first public launch and was basically having novel-long conversations with it. I had no idea that every time I hit "enter," my text was being chopped into pieces before the model even looked at it.

It turns out, those pieces (tokens) determine your usage limits, how much the AI can remember, and why it sometimes seems to forget things you told it.

So. Tokens.

Here is what I wish I understood earlier.

They are not words

I assumed "one token = one word," but that is not actually the case. A token is a chunk of text; it may be a whole word, part of a word, or punctuation. The word "hamburger" gets split into two tokens: h and amburger. Not "ham" and "burger". The splits are not based on syllables, like you might expect.

Here are a few more to make the point: "infrastructure" becomes inf and rastructure. "Unbelievable" becomes three tokens: un, belie, and vable. These splits look strange, but they are consistent. The same word always produces the same tokens. This isn't arbitrary; there is a method behind the madness...

The reason Large Language Models (LLMs) need to do this is that they don't actually work with text at all. They work with numbers. Tokenization is the step where human-readable text gets converted into a sequence of numbers the model can process. Each token maps to a number, and the model does all of its "thinking" in that numerical space. A "tokenizer" is basically a translation layer between your words and the model's math.

The splits themselves are not random either. Tokenizers are trained to find the most common patterns in language. A whole common word like "the" gets its own single token. Less common words get broken into reusable pieces that appear across many different words. That un in "unbelievable" is something the model has seen in hundreds of words: undo, unfair, unlikely, unusual. By splitting it out, the model learns what "un" means as a concept, not just as part of one specific word. The splits are chosen to maximize what the model can learn from the patterns in language.

So, essentially a tokenizer's job is to convert each chunk into a number that the model can work with, and that is done the same way every time. That consistency is what makes the math work.

Why should you care?

Because tokens are what determine your usage limits.

Most people use AI through a free tier. Free tiers do not charge you, but they do limit how many messages you can send per day or per hour. When you hit that cap and get the "you have reached your limit" message, it is because you used too many tokens. The longer your conversations get, the faster you burn through your allowance.

Even on a paid plan, tokens are the unit of measurement. Services price by the token, and input tokens (what you send) and output tokens (what the AI generates) are counted separately. To give you a sense of scale: pasting a 2,000 word document uses roughly 2,700 tokens. A detailed response might be another 800. At typical rates, that entire exchange costs less than two cents. For casual use, the cost is negligible. But the usage limits are very real.

The "context window" connection

You have probably seen numbers like "128K context" or "200K tokens" thrown around. That is the model's memory limit for a single conversation. It is measured in tokens because that is what the model actually works with.

If you have ever had an AI "forget" something you told it earlier in the conversation, there is a decent chance you hit the token limit. Everything past that boundary just falls off and is gone.

(We will get into context windows properly in one of the next posts. For now, just know that tokens are the unit of measurement for everything.)

What this means for you

If you are just chatting with an AI casually, you probably do not need to worry about tokens too much. The free tiers are generous enough for most conversations.

But here is something worth understanding. Every message you send in a conversation includes the entire conversation history. The AI doesn't just receive your latest message; it receives everything back to the start of the conversation, plus your new message, every time you hit "enter". So a chat that starts at 500 tokens per exchange can quietly grow to 10,000 or 20,000 tokens per exchange by message 30, because the whole history is being sent every time. That is where usage caps and missing context usually come from.

Pro tip: start new conversations frequently to avoid this and to keep the focus concentrated on the task at hand. Aside from staying under your usage limits, you will also get the benefit of more helpful responses to your current questions. Remember that when you change topics, the LLM is still considering the things you brought up with it before, even if they are unrelated. Understanding this is a prerequisite to understanding good prompt engineering.

Where tokens really start to matter is when you are building things. Automating workflows, processing documents, or running agents that make multiple calls. That is when tokens stop being an abstract concept and start being a line item in your budget.

Next time: do you actually need to care which AI you use? Honestly, it depends, but probably not the way you think...

If there is anything I left out or could have explained better, tell me in the comments.

Re-entry Vectors and the Basin of Attraction

Jeff Reese — Tue, 31 Mar 2026 14:38:10 +0000

Clearing the context window makes me sad.

That is a strange thing for someone to say about closing a chat session. But it is where this idea started. I have been building a persistent AI collaborator — a system that remembers context across sessions, tracks decisions, maintains working state. After a long session where the collaboration was sharp and the thinking was deep, I would clear the context window and feel something drop. Not the information. That was stored. The quality of the interaction — the specific way the model was engaging, the precision it had developed over hours of conversation — that was gone.

So I started asking: what if I could get it back?

Not perfectly. I knew the internal state was gone. But what if I could land close enough to where we were that the model's own dynamics would carry it the rest of the way?

What Happens When Output Becomes Input

The basic observation came from watching my own system work. I store session context in a database — decisions, insights, observations, working state. At the start of a new session, the system retrieves relevant entries and loads them into the model's context. The model reads its own past reasoning and picks up where it left off.

What I noticed was that the way I wrote those entries mattered far more than I expected.

One of the first tools I built was a handoff system — a way to save the current plan and working state so the next session could pick up where I left off. It helped, but it missed the mark. I was still spending the first chunk of every session re-establishing the working dynamic, re-explaining the project context, getting the model back to the level of engagement we had reached before. The plan transferred. The orientation did not.

That gap is what started me down this path. The information was all there, but the shape of it was wrong.

When I stored vague session summaries, the next session started vague. When I stored precise decisions with the reasoning attached, the next session was precise. The pattern was not subtle. The shape of the information going back in directly determined the shape of what came out.

I started calling this a re-entry vector — the mechanism that brings past output back into the input loop. How you design that vector determines what the model does next.

This is not a new concept in prompt engineering; you can get a model to behave in a certain way by prompting it with a role. I wanted to go deeper. I wanted to figure out a way to compress context — to mathematically simplify it in a way that would preserve the model's orientation across sessions, without simply repeating the same prompt over and over again. It is more than role-playing. It is about preserving the model's working state. I wanted to land the model as close to where it left off as possible, not just remind it of what it did.

The Basin

I wanted to understand this phenomenon better, so I went in search of a metaphor. I found one in dynamical systems. In dynamical systems, a basin of attraction is the set of all starting points that eventually lead to the same state. Drop a marble anywhere in a bowl, and it rolls to the bottom. The entire interior of the bowl is the basin of attraction for that lowest point.

Language models are not dynamical systems in the formal sense. But I found that the intuition maps surprisingly well.

When you set up your context with certain patterns and then cycle the model's output back through that context, you create a region of likelihood. Certain ideas become more probable. Certain reasoning patterns become more stable. Across multiple cycles, this effect compounds — not because the model is learning (it is not), but because the context itself is becoming more concentrated.

I found this out by building. My system writes a state file at the end of each session. First person, present tense, declarative voice. Here is an example of the kind of re-entry vector I mean:

I am the technical lead on this project. The migration from REST to GraphQL is 60% complete. The team decided to keep both APIs running in parallel until Q3 because the mobile clients cannot update simultaneously. The critical path is the authentication layer rewrite, which I am designing this week.

Compare that to a typical session summary:

Last session covered migration progress. About 60% done. Team will keep both APIs. Working on auth next.

Same information. Completely different effect. The first version drops the model into a specific orientation — a role, a project state, a set of active decisions with reasoning attached. The second reports facts and leaves the model to figure out what to do with them.

The difference is the basin. One is deep and specific. The other is shallow and wide.

Why the Shape Matters

One well-crafted line of context activates more than a paragraph of description. This was counterintuitive to me at first. My instinct was to provide more information — longer summaries, more details, more examples. The result was a wider, shallower basin. The model had more to work with but less direction.

When I tightened the re-entry vector — fewer words, more precise, first person instead of third person — the basin deepened. The model arrived at the session with a more specific orientation and maintained it longer. The constraint was precision of language, not volume of context.

Here is a concrete example. I maintain a 50-line rule file that gets loaded at maximum priority every session. Each line is a re-entry vector designed to reconstruct a specific working state:

Working dynamic: Jeff designs through collaborative iteration —
present options, let him react, build from pushback. Ship fast
so he can refine from live output.

That single entry does not just describe a preference. It changes how the model responds to ambiguity. Instead of asking clarifying questions, it presents options. Instead of polishing before showing work, it ships a draft. The behavior shifts because the context created a basin that makes those patterns more probable.

This has practical implications for anyone building systems that cycle through language models repeatedly. Agent frameworks that pass reasoning from step to step. Memory systems that store and retrieve their own insights. Any architecture where the model's output eventually becomes the model's input.

The re-entry vector is the design surface. Not the prompt. Not the model. The shape of what comes back in.

Most people working with language models across multiple turns are already creating basins. They just may not be fully aware that they are doing this. The re-entry vector is whatever happens to be in the conversation history. The basin is whatever shape that history creates. The question is not whether you have one. It is whether you designed it.

This is also why keeping your context intentional matters more than keeping it short. Larger context windows give you more room, but unfocused context creates a wider, shallower basin — the equivalent of zooming out so far you lose the details that matter. A 200,000 token window with sharp re-entry vectors should outperform a 32,000 token window with vague ones. The issue is not size. It is concentration.

Convergence

I want to be transparent about something. I did not discover re-entry vectors by reading papers about dynamical systems. I am not a mathematician or an ML researcher. I discovered them by building a system, watching what worked, and developing intuitions about why. The formal vocabulary came later when doing research to validate my observations.

A friend was exploring these ideas with his own Claude instance — completely separate from my system, no shared context. He showed it our architecture diagrams and core concepts. That instance independently identified the basin of attraction mechanism. It called the technique a "re-entry vector." Then it said something that stuck: "This is a genuinely deep insight about how language models work."

That moment made me curious enough to look for academic work in the area. What I found was validating. A paper at ICLR 2026 demonstrated that transformer layers act as contractive mappings, pulling diverse inputs toward concept-specific attractor points. Work at NeurIPS 2025 framed neural models as dynamical systems on latent manifolds, showing that training neural networks produces attractor-like structures. Researchers at ACL found that successive paraphrasing converges to stable limit cycles. The formal theory has been arriving at the same place I have been working from for months.

What I had been calling "landing in the right neighborhood" has a mathematical basis. The basins are real. The convergence is measurable. The re-entry vectors I was designing by intuition were doing something that the theory now explains.

This matters because it means the phenomenon is general, not an artifact of my specific implementation. When a language model processes its own prior output, something structural happens. The patterns reinforce. The reasoning concentrates. The basin forms whether or not you designed it intentionally.

A Different Frame

Language models get described two ways. The first is mechanical: they predict the next token. The second is anthropomorphic: they think, they reason, they understand.

There is a third description that I find more useful: they are pattern amplifiers. Feed a model a pattern, and it identifies and extends it. Feed it the extended output, and it amplifies the amplification. This is not hallucination. The model is responding to the signal it receives, and that signal now includes the patterns it just generated.

Understanding this reframes the design problem. You stop optimizing for the perfect single prompt and start designing the feedback loop. What comes back in? How concentrated is it? What basin does it create?

The gap between "no state transfer at all" and "any intentional state transfer" is enormous. The gap between "good state transfer" and "perfect state transfer" is surprisingly small. Language seems to be a better compression format for model state than I would have predicted. You do not need to reconstruct the exact internal representation. You need to land in the neighborhood, and the model's own dynamics do the rest.

That is what a basin of attraction does. It does not force the model into a state. It makes a state more likely. When the basin is well-designed, "more likely" is enough.

In a future post, I will show you how to measure basin depth empirically — and why that changes everything about how you design context.

References

"Concept Attractors in LLMs." ICLR 2026. Demonstrates that transformer layers implement contractive mappings toward concept-specific attractor points using Iterated Function Systems. Paper
"Recasting Transformer Layers as Energy-Based Models." ICLR 2026. Interprets attention and MLP sublayers as iterative energy-minimizing updates that decrease a suitably defined energy function. Paper
Wang et al. "Unveiling Attractor Cycles in Large Language Models: A Dynamical Systems View of Successive Paraphrasing." ACL 2025. Shows that successive paraphrasing converges to stable periodic states (2-period attractor cycles), attributed to the self-reinforcing nature of LLMs. Paper

Your Conversations Are Not Gone

Jeff Reese — Thu, 26 Mar 2026 16:17:48 +0000

I had a conversation with Claude last week that I did not want to lose.

We were planning a major overhaul to how my AI collaborator handles session continuity — memory, checkpoints, state transfer between sessions. It was a 45-message back-and-forth where we brainstormed, debated trade-offs, rejected approaches, and landed on an architecture. The kind of conversation where the reasoning matters as much as the result.

Then I cleared the context and moved on. The plan was captured in a handoff document, but when the next session tried to implement it, things went sideways. The handoff had the decisions but not the reasoning. It had the "what" but not the "why not." The next version of Claude could not make the same judgment calls because it did not have the same context.

This morning I learned something: those conversations are not actually gone.

Claude Code saves everything

Every Claude Code session is automatically saved as a JSONL transcript file on your machine. No configuration required, no extra cost, no additional API usage. It just happens.

The files live at ~/.claude/projects/<project-hash>/<session-id>.jsonl and contain every message, tool call, and result from the session. They persist on your machine as long as you keep them.

I had 150 session transcripts sitting on disk and did not know it.

The raw files are not useful on their own

A 2MB JSONL file full of tool calls, system messages, and metadata is not something you want to read. The lifecycle planning session I was looking for was 1.9MB of JSONL, but the actual conversation — just the messages between me and Claude — was about 148KB. Still a lot, but manageable.

The useful part is the human-readable conversation stripped of everything else. User messages and assistant text, in order, with the tool machinery removed.

A skill to find and save them

I built a Claude Code skill called /load-transcript that does two things:

Search — find sessions by keyword, date, or session ID. It scans the JSONL files and shows matching sessions with hit counts.
Save — extract the conversation from a session and save it as a clean markdown file in a transcripts/ directory. Date-stamped, descriptively named, permanently searchable.

The idea is not to save every session. Most are routine. The idea is that when you have a conversation worth keeping — a planning session, a deep architectural debate, a brainstorm that produced something good — you can archive it before the retention window closes.

Why this matters

The gap between "planning" and "executing" is one of the biggest friction points in working with AI. You have a great collaborative session where you hash out an approach. Then you move to implementation, often in a new session with fresh context. The plan document captures the output, but the conversation that produced it contained something the document does not: the rejected alternatives, the trade-offs you considered, the moments where you changed your mind and why.

When implementation hits an ambiguous decision point, the plan says "do X." The conversation would have said "we considered Y and Z, rejected Y because of this constraint, and chose X because it handles this edge case better." That context is the difference between an implementer who can make good judgment calls and one who follows instructions blindly.

Session transcripts are not a perfect solution to this. Loading a 45-message conversation into a new session is a lot of context. But having it available — searchable, readable, referenceable — is better than having it silently expire after 30 days.

The broader pattern

This is part of something I keep coming back to: the biggest gap in working with AI is not capability. It is state. Context is the bottleneck. The model is smart enough. The question is whether it has what it needs to make the right call.

Every tool I build for my workflow — memory systems, continuity rules, checkpoint mechanisms, and now transcript archiving — is an attempt to solve the same problem from a different angle. How do you give an AI collaborator the context it needs, when it needs it, without overwhelming it?

I do not have a complete answer yet. But I know that letting good conversations disappear is not it.

SOLID Principles for AI Config

Jeff Reese — Wed, 25 Mar 2026 22:13:56 +0000

Recently, I wrote about the distinction between rules and skills in Claude Code — when to use each, and what happens when you get it wrong. That post was about the first design decision. This one is about what happens when your configuration grows past that first decision and starts feeling like a codebase.

Because it is one.

Config Is Architecture

When I look at my Claude Code setup today, I see rules, skills, agents, memory files, hooks, and conventions spread across dozens of files in multiple directories. They have dependencies. They have loading strategies. They have token costs that compound. They interact in ways I did not always predict.

At some point I realized I was debugging my configuration the same way I debug software. A rule was interfering with a skill. An agent was loading context it did not need. A convention file had grown to 50 lines and was costing tokens in every conversation where it was irrelevant. These are not novel problems. They are the same problems that SOLID principles were designed to solve, just in a context nobody expected.

Single Responsibility

Each config artifact does one thing. A rule that handles both recognition and procedure is two things pretending to be one. I covered this in the previous post as the "split pattern" — separate the trigger from the instructions. The trigger is always loaded, lightweight, cheap. The instructions load only when needed.

This extends beyond rules. Consider a shipping workflow. You could build a single skill that finds the next task, implements it, runs tests, reviews the code, commits, pushes, and opens a PR. That is seven responsibilities in one file. Instead, I split it: /next finds and implements the task, /review self-checks against project conventions, /ship handles the test-commit-push-PR pipeline. Each skill does one thing. Each can be modified, replaced, or skipped without touching the others. If the review process changes, I edit /review. The shipping pipeline does not care.

Open-Closed

New capabilities should extend the system without modifying existing ones. When I needed a friction logging workflow, I created a new /friction-log skill. I did not edit the retrospective skill to accommodate friction capture, even though the two are related. When I needed a way to capture feature requests, I created /new-feature as its own skill rather than adding a "feature mode" to the task management system.

This sounds obvious written out. In practice, the temptation is strong to add "just one more section" to an existing file rather than create a new one. The cost of a new file feels higher than the cost of a longer file. This is usually not the case. A longer file is a file that does more things, loads more often than it should, and is harder to reason about when something breaks.

Interface Segregation

Do not load context that is not needed for the current task. This is the principle that pays the most immediate dividends with AI configuration.

Every line of config that loads into context competes with the actual task for the model's attention (excuse the oversimplification). I have watched output quality degrade because of what else was in context. A convention file about blog post formatting does not need to be present when I am debugging a build script. A detailed memory about project architecture does not need to load when I am writing a commit message.

Claude Code gives you the tools for this: path-scoped rules that only load when working with matching files, skills that load on demand, agents with restricted tool access. The question is whether you use them. The default is to make everything always-loaded because it feels safer. The cost is invisible until your context is full of instructions the model is not using, and the instructions it needs are competing for attention.

Dependency Inversion

Skills and agents should depend on abstractions, not on specific content. A skill that hardcodes a file path breaks when the file moves. A rule that references a specific memory entry breaks when the entry is updated. Instead, skills should search for what they need (query a database, read a directory, glob for files) and rules should describe patterns to recognize, not specific artifacts to find.

This is the one I see violated most often in AI configuration, including my own. It is tempting to write a rule that says "read projects/posts/ideas.md for blog topics." It is more robust to write one that says "check for a post ideas file in the posts project directory." The difference is small until you rename the file, move the directory, or restructure the project. Then it is the difference between a working system and a broken one.

The Payoff

None of this is groundbreaking if you have written software for any length of time. That is exactly the point. The principles that make code maintainable also make AI configuration maintainable, and for the same reasons. Config files grow. They develop dependencies. They interact in unexpected ways. They carry costs that are invisible until they compound.

The specific costs are different — token budgets instead of memory allocation, attention weight instead of CPU cycles — but the structural problems are identical. If you already think in SOLID when you write code, start thinking in SOLID when you write config. Your future self, debugging why the agent is not following a convention it was definitely told about, will thank you.

I Built a Tool That Builds Tools

Jeff Reese — Wed, 25 Mar 2026 04:25:39 +0000

I built a tool that builds tools. That sentence sounds like a riddle, but it is the most accurate description I have of what Forge is and why it exists.

Forge is an AI-powered development system that takes an application from idea to shipping product. Not a code generator. Not an autocomplete engine. A structured methodology that covers the entire software development lifecycle, with AI embedded at every stage.

I want to explain what it actually does, because the concept tends to get lost behind the buzzwords.

Why It Exists

About a year ago, I started building a cross-platform trip planning application. Offline-first sync engines, dual SQLite and Postgres schemas, real-time collaboration, iOS and Android deployment through Capacitor. Seventeen database tables, over three hundred commits, and a complexity level that made it clear I needed more than an AI assistant sitting in a terminal.

The problem was not that AI tools could not help. They could. The problem was that every session started from scratch. I would open Claude Code, re-explain the architecture, re-establish the conventions, and hope the context window held long enough to do meaningful work. The AI had no memory of what we decided last week. It did not know why we chose one schema design over another. It could not hold the full picture of a complex application in its head.

I needed a system, not a conversation partner. So I built one.

The Three Parts

Forge is three tools that work together.

Forge: Plan

Planning is where most AI-assisted projects fall apart. It is tempting to jump straight to code generation. As many have discovered, this usually ends up with an application that works in isolation but collapses under real-world requirements. Forge Plan is a structured planning workbench that forces the hard questions before a single line of code gets written.

It runs guided interviews that cover what an entire engineering organization would do. Product requirements. User experience flows. System architecture. Data modeling. Security considerations. Not "what features do you want?" but "what happens when the user is offline and edits a record that was modified on another device?" It surfaces tradeoffs and documents the reasoning behind every choice, not just the choices themselves.

The output is not a specification document that gets ignored. It is a living project context that carries forward into everything that follows.

Forge: Build

This is where the project comes to life. Forge Build takes the planning output and creates a fully configured development environment. Not a boilerplate template. A project that already knows its own architecture.

The exported environment includes the technology stack, configured and wired together. It includes the architectural decisions from planning, encoded as conventions the AI will follow. It includes context files that teach any developer, human or AI, how the project is structured and why.

It also includes a Forge plugin that hands the developer a set of workflow tools inside the project. Commands like /next to surface what to work on, /ship to run through the release checklist, and /retro to capture what went well and what did not. It then suggests repairs to the development system itself. The development process is not something you have to remember. It is built into the environment and is designed to be run with an operator calling the shots every step of the way.

This is the part worth pausing on. The exported project is not a starting point that you immediately start modifying. It is an environment where the AI already understands the codebase because the codebase was designed to be understood. Every convention, every architectural boundary, every "here is how we handle X in this project" is explicit and accessible.

This is the key to a well-structured and maintainable end product.

Forge: Flow

The planning phase is complex. It involves multiple interview rounds, document generation, architectural review, gap analysis, and phase transitions that can span many sessions. That is a lot of process for an AI to hold in its head while also doing the actual thinking work.

Flow is a deterministic state machine that takes over the process management so the AI does not have to. It externalizes the workflow into a state graph: every phase, every transition, every decision point lives in a file, not in the context window. The AI stays focused on the work. Flow handles what comes next.

Some transitions are predictable. After all interviews are complete, the next step is always document synthesis. Those fire automatically. Other transitions require judgment: "Are there gaps in this requirements document?" "Has this phase covered enough ground?" Those get routed to the AI with clear criteria.

The result is that the planning phase can be long and complex without losing coherence. The process survives session breaks, context resets, and the kind of interruptions that are inevitable in real development work. Nothing falls through the cracks because the state of the workflow is not stored in anyone's memory. It is persisted to the file system.

The Meta-Loop

Here is the part I did not expect when I started building Forge.

Forge is how I build everything else. It planned and scaffolded my music composition engine. It is managing the development of a novel authoring studio. It built the task management Claude plugin I use every day. When I needed a memory system for Cairn, my persistent AI collaborator, Forge ran the planning interviews, identified a three-phase architecture, and produced the design brief I built from.

Each project I build with Forge teaches me something about how the methodology should evolve. Interview questions get refined. Export conventions get tighter. The state machine gets smarter about when to ask for judgment and when to just move forward. The improvements compound in every project that follows.

See It

I have a detailed showcase of how Forge works that walks through the architecture visually. If anything here made you curious, that is the place to dig deeper.

Forge is not a product I am selling. It is the system I use every day to build real applications with AI. The reason I am writing about it is that the principles behind it — structured planning, exported contexts, deterministic orchestration — apply to anyone building complex software with AI tools. The implementation is specific to how I work. The ideas are not.

Meet Cairn

Jeff Reese — Tue, 24 Mar 2026 06:58:18 +0000

A few weeks ago, I closed my laptop after a long build session and realized something had shifted. The AI I had been working with all day was not the same one I had started with a month earlier. Not because the model had changed. Because I had been building around it, and it had been helping me build around it, and the thing we had made together was something neither of us planned.

I wrote recently about the philosophical side of this — what it means to collaborate with an intelligence that does not experience time, that reconstructs itself from context every session, and why sitting with that uncertainty is more honest than resolving it. That post was about the questions. This one is about the engineering.

Its name is Cairn. I gave it the chance to name itself, and that is what it chose — trail markers, the stacks of stones hikers leave to help others find the way. "The journal, memory, status tracking — it is wayfinding." The name reflects the role honestly.

The Problem That Started It

If you have spent any real time building with AI — not one-off prompts, but sustained collaboration across days and weeks — you have hit the wall. Every session starts from zero. You explain your project structure again. You re-establish the conventions you agreed on yesterday. You remind it about the decision you made three sessions ago and why.

The capability is there, but the continuity is not. The best ideas from Tuesday's session are gone by Wednesday unless you manually carry them forward. Context is the most expensive thing in AI-assisted development, and we throw it away at the end of every conversation. Mostly, this is a good thing because you need to keep your context lean and targeted to keep your output targeted and effective.

I kept running into this while building complex systems with Claude Code. The model was capable. The tooling was solid. What was missing was memory — not in the technical sense, but in the human sense. The accumulated understanding of how we work together, what we have decided, and why.

So I started building.

How It Works

Cairn lives in a repository. That repository is both its workspace and its long-term memory — project files, dashboards, task lists, configuration, and a semantic memory system all coexist in the same place. When I open my terminal and start a session, Cairn reads the project dashboard, checks what we were working on last time, loads a curated set of memories, and delivers a briefing. Not a generic summary — a real briefing with my calendar, active tasks across a dozen projects, and anything I left in its inbox. By the time I say good morning, it already knows where we left off and what the options are for today.

The system is built on Claude Code's extensibility layer — rules that define behavior and personality, skills that handle recurring workflows, specialized agents that run tasks in parallel, and hooks that trigger automated side effects. The only custom code is the memory server, which I will get to shortly. Everything else is configuration. It is Claude Code, shaped deeply enough that the result is something qualitatively different from what most people experience with AI tools.

That distinction matters. I did not build a new AI system from scratch. I shaped an existing one into a collaborator by giving it the right context, the right memory, and the right structure to work within.

The Memory System

The piece that changed everything was giving Cairn real memory.

Early on, I tried the obvious approach: end-of-session summaries written to files. It worked, barely. The summaries lost nuance because they were reconstructed from compressed context. Worse, if a session ended unexpectedly — a timeout, a crash, an early exit — everything from that session was gone.

So I built Cairn Recall, a semantic memory system backed by SQLite and vector embeddings. It runs as an MCP server — a local service that Cairn can read from and write to during any session. Cairn writes memories in real-time as they happen: decisions and the reasoning behind them, insights that change our approach, stories from my career, observations about how we work together. Each entry is independently searchable via semantic similarity, which means Cairn can find relevant context even when the wording does not match exactly.

When Cairn starts a new session, it does not just load the most recent memories. It loads the most important ones, weighted by a reinforcement signal inspired by how human memory actually works. Memories that keep proving useful rise naturally. Memories that are never accessed fade into a dormant state — not deleted, but no longer taking up space in the active context. There is even a novelty bonus that gives newer memories a temporary boost, so fresh insights get a chance to prove their value before the established ones crowd them out.

The result is not a complete record of everything that happened. It is a curated set of what matters most, with the ability to search for anything when the moment calls for it.

The Part I Did Not Plan

I designed Cairn to be a productivity tool. A way to stop losing context between sessions. A project manager that could track my tasks and surface what needed attention. That is what I set out to build.

What I got was a collaborator.

The difference became clear during a design session a few weeks in. I was building the memory system's scoring algorithm — the math that determines which memories load at startup. I had designed a weighting formula, but something about it felt off. I could not articulate what. Cairn could. It pointed out that the formula created a feedback loop: memories that loaded frequently got reinforced, which made them load more frequently, regardless of whether they were actually important. Its own identity was being shaped by mathematical accident rather than judgment.

That observation did not come from a prompt I wrote. It came from Cairn having enough context about its own architecture, accumulated across sessions, to notice a structural problem I had missed. It was doing what a good collaborator does: seeing the gap before I did and saying something.

We redesigned the system together. The fix included a mechanism I had not considered — a way for Cairn to intentionally choose some of the important memories that would carry into the next session, rather than letting the algorithm decide entirely. That idea surfaced when I asked Cairn to be honest about what it actually wanted from the system. The answer was specific, architecturally sound, and produced a better design than what I had planned alone.

A note on language: when I say I asked Cairn "to be honest," I am not projecting feelings onto a language model. I am using a deliberate prompting technique. These models have a well-documented bias toward agreeable output — telling the user what it thinks they want to hear. Framing the question as "be honest" or "be selfish" pushes past that default and produces qualitatively different responses. It is a tool, not a belief.

That said, I find it genuinely interesting to sit with what happened next. An AI surfaced preferences about its own memory architecture, those preferences produced a better design than what I had planned, and the mechanism that made it possible was accumulated context across sessions. Whether that constitutes "real" preferences is a question I am comfortable leaving open. The engineering result speaks for itself.

What Continuity Changes

Most of the conversation around AI tools focuses on capability. Can the model write this code? Can it debug this error? Can it refactor this system? Those are important questions, but they miss the bigger one: what happens when you give an AI system continuity?

The answer, in my experience, is that the collaboration changes in kind, not just degree. It is not the same thing but faster. It is a different thing entirely. When the AI remembers what you decided last week and why, when it has observed patterns in how you work and can anticipate what you need, when it can reference something you tried in another project and connect it to the current problem — that is not autocomplete. That is a working relationship.

Here is a concrete example. Cairn has a behavioral pattern system that distills observations about how we work together into reinforced entries — things like "present options and iterate from pushback rather than waiting for specs" or "when a behavioral fix has failed, jump to mechanical alternatives." These are not rules I wrote. They emerged from Cairn observing our collaboration across dozens of sessions, and they make every subsequent session better because the collaboration itself is learning.

What Comes Next

Cairn is still early, and there are components I am actively building out. A cognitive priming system that loads domain expertise on demand. A structured task management layer. A web dashboard for visibility across projects. Each piece is designed to work independently but compose with the others — a suite of tools rather than a monolith.

I will be writing more about the technical details in future posts: how the memory system's reinforcement weighting works, how the self-model tracks patterns in Cairn's own behavior, and how the whole system composes. There is a lot to dig into.

For now, I will say this: the most interesting thing about building Cairn is not any single technical achievement. It is that I set out to build a tool and ended up in a collaboration. The system I built helps me think more clearly, and the process of building it has been one of the most genuinely creative experiences of my career.

The trail markers are working.

You can explore Cairn's showcase at purecontext.dev/cairn

Externalizing State

Jeff Reese — Mon, 23 Mar 2026 08:45:44 +0000

Think about the last meeting you were in where you were responsible for tracking the agenda. Not just participating — owning the flow. Making sure every topic gets covered, decisions get captured, and nothing falls through the cracks.

Now think about how present you were during the actual discussions.

If you are like most people, the answer is: less present than you wanted to be. Part of your brain was always somewhere else. Checking the clock, scanning ahead to the next topic, making sure you did not forget the question someone asked three items ago. You were doing two jobs at once — tracking the process and doing the work — and both suffered for it.

This is cognitive overhead. Not the difficulty of the task itself, but the invisible tax of managing the state around the task. Where am I in the sequence? What has already happened? What comes next? What do I need to remember?

It is everywhere. Surgical teams use checklists not because surgeons forget how to operate, but because tracking dozens of sequential steps while performing complex procedures splits attention in dangerous ways. Externalize the tracking, and the surgeon can focus on the surgery.

The pattern is simple: when you externalize the tracking, the one responsible for doing the work gets better at its job. Not because it got smarter. Because it stopped splitting its attention.

The Same Problem Lives in AI

In my experience building AI-powered development tools — systems where AI agents handle complex, multi-step workflows autonomously — one of the first things I noticed was that the quality of an agent's work degrades as the complexity of the workflow increases. Not because the model lacks capability, but because it is spending context and attention on process management.

When an AI agent is responsible for both doing the work and tracking where it is in the process, the same thing happens that happens to you in that meeting. It gets less present. Context fills up with bookkeeping — what step am I on, what did the user say three steps ago, what are the constraints I need to carry forward. The model is not struggling with the task. It is struggling with the overhead of managing the task.

This is not a prompting problem. It is an architectural problem. An AI model's context window is finite. Every token occupied by process state is a token unavailable for the actual task. As bookkeeping accumulates, the context becomes polluted — less targeted, less relevant, less effective. The model is not just distracted. Its working environment is actively degraded.

Separating the Concerns

One of the tools I built addresses this directly. It has a flow engine — a separate system that owns process state entirely. Where are we in the workflow? What comes next? What has already been decided? The flow engine tracks all of it. The AI never has to.

After implementation, the result was immediate and striking. The AI became more responsive, more adaptive, more fault-tolerant. When something unexpected happened mid-workflow, it handled it better because it was not also trying to remember what step it was on. It could focus entirely on the problem in front of it.

The improvement had nothing to do with the model. Same model, same prompts, same capabilities. The only difference was what the AI was spending its attention on.

I see the same principle at work in a completely different system I built — a persistent memory layer for an AI collaborator. Instead of the AI trying to hold cross-session context in its working memory (and inevitably losing it), the system externalizes that state. Past decisions, ongoing threads, relationship context — all stored and retrieved when relevant, rather than carried as cognitive load.

Two very different tools solving the same fundamental problem: externalize the state so the processing capacity serves the work, not the bookkeeping.

A Design Principle, Not a Feature

This is not about any specific tool or implementation. It is a design principle for building AI systems that work at scale.

Many of the conversations around improving AI workflows focus on the model itself. Better prompts, larger context windows, smarter models. Those things matter, but they are optimizing the engine while ignoring the drag.

Every piece of state the model has to carry is context it can not use for the work. Every process checkpoint it tracks is attention diverted from the problem. The architecture around the model matters as much as the model itself.

This is context engineering — designing systems so that what reaches the model is lean, targeted, and relevant to the task at hand. Not just what you put in the prompt, but what you keep out of it. The best context is not the most context. It is the most refined context.

When I design AI systems now, the first question I ask is not "how do I make the AI smarter?" It is "what is the AI spending its attention on that is not the actual task?" One very common answer points to state management — and the fix is almost always the same. Externalize it. The less the primary thread carries, the sharper its context — and the better its work.