July 17, 2026

AI for the Over 40 – Week 29: AI Context Management: What Happens When You Hit the Ceiling

I almost could not write this article.

Not because I did not know what to say, but because the tool I was using to write it kept breaking mid-sentence. I was running into max compaction errors, “response could not be fully generated” messages, and conversations that stopped dead with no clear explanation and no obvious way to recover what had been in progress.

This has been happening more and more lately. Not because AI is getting worse, but because I am asking it to do more.

Twenty-nine weeks into this journey, I am working inside a Claude Project loaded with every published article from this series, a comprehensive Project Bible containing all my frameworks and voice guidelines, and the accumulated context of everything we have built together. That richness is what makes the work good. It is also what keeps pushing me into limits I cannot easily diagnose.

That is the frustrating paradox of getting better at AI: the more you can do, the more you want to do, and the harder you eventually hit the ceiling.

The ceiling you don’t hit until the work gets real

In Week 1, I asked AI simple questions and was impressed by the answers. I never hit a token limit. I never saw an error message. Everything just worked.

That was not because the limits did not exist. It was because I was not doing enough to find them.

Twenty-nine weeks later, the work looks very different. I am collaborating with AI on complex writing projects that require deep context: the full arc of a 28-week series, the frameworks I have developed along the way, and a specific voice and editorial sensibility that has taken months to refine. I am building organizational tools that need to synthesize evidence against development dimensions. I am running multi-platform research projects that generate hundreds of lines of strategic analysis.

Every one of those activities pushes harder against the limits than anything I was doing in the early weeks, and each one breaks in a slightly different way.

What nobody tells you at the start is that the frustration does not disappear as you build AI literacy. It changes character. Early frustration is about not knowing what AI can do. Later frustration is about knowing exactly what AI can do, but not being able to get there because of constraints you cannot see, cannot diagnose, and cannot always solve by paying for a higher tier.

The black box diagnosis problem

In Week 16, I built a diagnostic framework for process problems, adapted from medical differential diagnosis. The idea was simple: start with a vague frustration, systematically examine People, Process, Technology, and Data, and identify which barrier is actually blocking progress.

That framework works because you can examine the system, ask questions, and get answers that narrow down the cause. Now I am the one with the problem, and my own framework cannot fully help me.

When an AI conversation fails, I get almost nothing useful. Sometimes the conversation stops and produces an error message like “max compaction exceeded” or “response could not be fully generated.” Other times, it just does not finish. When I ask the AI what happened, it cannot really tell me, not because it is refusing, but because the diagnostic information is not available in the chat interface.

Was it the token budget? The context window filling up? Connector overhead? The complexity of the request? Some combination of all of those?

I do not know. More importantly, I cannot easily find out. Not through the chat interface. Not through subscription settings. Not through any tool available to me as a normal user.

That is what makes AI infrastructure problems different from the enterprise software problems I have spent 23 years solving. In Business Central, when a batch posting fails, I usually get an error log, a stack trace, or at least a specific record that caused the failure. I can diagnose the root cause and fix it.

With AI, I often get the equivalent of a check engine light, but there’s no OBD port to plug into.

What I tried and what actually worked

Let me walk through what happened while writing this article, because it illustrates both the problem and the solution.

My first instinct was to continue in the current chat. Sometimes when a response fails, you can ask Claude to continue, and it picks up where it left off. I have used that successfully many times. This time, it did not work. Multiple attempts produced the same result. The conversation had hit a wall it could not get past.

Next, I tried retrying. Claude suggested retrying the last exchange, so I did, and I immediately regretted it. Retry does not simply re-attempt the failed response. It starts over from the prompt that triggered the failure. Everything Claude had generated after that prompt, including partial output from the failed response that I wanted to reference, disappeared. I was now in a worse position than before I retried because I had lost the partial work and gained nothing.

That was the moment I realized I needed a different strategy.

I opened a new conversation within the same Project and asked Claude to review the previous chat so we could pick up where we left off. Sometimes that works because the new conversation inherits the Project context, including files, instructions, and accumulated knowledge, and Claude can search past conversations to find relevant history. In this case, even that approach failed. The new conversation also hit limits before producing meaningful output. The act of searching for and loading context from the prior conversation was itself consuming the token budget I needed for the actual work.

What finally worked was manual context transfer with everything else stripped down.

I turned off every connector I was not actively using. I deleted Project files that were not essential for this specific task. Then I opened a new conversation and, instead of asking Claude to find anything, I explicitly carried forward what mattered: my original prompt, the feedback and partial output I had received before the conversation broke, and the specific documents I wanted Claude to reference.

In other words, I hand-delivered the context instead of asking the system to retrieve it. It was not elegant. It was not effortless. But it worked.

Three tactics that made the difference

I want to be explicit about what I learned because anyone who keeps pushing AI into more serious work will eventually hit similar walls. And if you have not hit them yet, it helps to know these tactics exist before you need them.

The first tactic is to turn off what you are not using.

Every connector and integration you have enabled, including web search, MCP servers, platform tools, or external apps, can consume context at the start of a conversation. Even when you are not actively using them. Even when they have nothing to do with the work in front of you. I had too much turned on by default: tools for Monday.com, MCP servers, web search, and other integrations that were consuming context budget in conversations where I did not need them.

The practical move is simple. Before starting complex work, check what is enabled. Turn off web search if you are not researching. Disable connectors you do not need in the current session. You can always turn them back on later. Think of it like closing background apps when your computer is running slow. It seems obvious once someone points it out, but it is invisible until then.

The second tactic is to explicitly carry context forward.

When a conversation breaks, and you need to continue in a new chat, do not just ask the AI to “reference our prior conversation” and hope for the best. That search-and-retrieve process can consume a meaningful amount of the same context budget you are trying to preserve.

Instead, manually carry forward the pieces that matter. Copy your original prompt. Save any useful output you received before the break, even if it was partial or rough. Load the specific documents you need referenced rather than relying on the system to find them through search. The principle is to minimize what the model has to retrace and maximize what you hand it directly. You know what matters. The system does not.

The third tactic is to design for multiple conversations, not one marathon.

I had been approaching complex work as if it needed to happen in a single continuous conversation. When the conversation broke, I treated that as a failure. But that framing was wrong. Some work needs to span multiple conversations, just as some projects need to span multiple meetings. The skill is not avoiding the boundary. The skill is crossing it cleanly. For complex work, periodically ask the AI to summarize the current state: what has been established, what remains, and which decisions or constraints matter most. That summary becomes your carry-forward artifact if the conversation breaks. Do not wait for failure to create it.

What money fixes and what it doesn’t

Some of these limits respond to a higher subscription tier. More context capacity, more capable models, and faster throughput can genuinely help, especially if you are hitting limits on a free or lower plan. But some limits do not respond to money, at least not at the tiers available to individual users. Without better diagnostic information, you cannot always tell which category you are in before you spend.

I am already on a top-tier subscription and using one of the most capable models available, and I am still hitting walls I cannot fully diagnose. What I have not been willing to do yet is downgrade from my preferred model or turn off extended thinking to conserve capacity. For now, I would rather find workarounds that let me keep pushing the ceiling than lower my ambitions to fit comfortably below it.

That may change, but it is a conscious choice about what I am optimizing for: capability ceiling versus comfort zone.

There is also a structural issue I am watching closely. My Project Bible, which is the compressed summary of 28 weeks of articles, frameworks, and context, is itself growing. It replaced loading individual articles, which was a major improvement. But at some point, even the Bible may exceed what fits comfortably in a context window alongside actual work.

My understanding is that Anthropic’s platform currently switches from loading all Project files directly into the context window to a retrieval-based approach only when the files are too large to load entirely. A better default would be retrieval-based from the start: load what is relevant rather than loading everything. I am hoping that architectural change arrives before my Project Bible forces the issue.

The deeper pattern

The pattern I keep coming back to is that constraints are the teacher.

I would not have learned about connector overhead if my conversations had not been breaking. I would not have developed a manual context transfer protocol if the automated one had worked reliably. I would not have started designing for multi-conversation workflows if single conversations always succeeded.

That does not mean I am romanticizing the limitations. Some of these are genuine product gaps, and the lack of diagnostic information is the most obvious one. Better error messages, accessible telemetry, and clearer feedback about what is consuming context would make all of this easier.

I hope those improvements come.

But waiting for perfect tooling is exactly the trap I have been writing about since Week 19. The tools are not perfect, and they are not going to be perfect next quarter either. The question is whether you develop the literacy to work with what exists, including its constraints, or wait for those constraints to disappear.

In Week 13, I hit the infrastructure wall for the first time and discovered that the gap between an AI demo and AI production is enormous. In Week 17, I built a context architecture using Projects, bounded contexts, and a three-layer system to work within those constraints. This week, I learned that even well-designed architecture still needs a recovery protocol for when things fail anyway.

That is infrastructure literacy growing in real time. Not theoretical understanding, but operational resilience built from direct experience with failure.

And underneath all three tactics is a principle that connects to something I have been saying since the beginning of this series: you cannot delegate context management to the platform any more than you can delegate AI literacy to a vendor or career development to a manager.

For now, the most reliable path is the one where you carry the context forward yourself.

Because you know what matters, and the system does not.

Your Week 29 challenge: Build your recovery protocol

You may not be hitting these limits yet. But if you keep building AI literacy and pushing your AI work forward, you probably will. The time to build a recovery protocol is before you desperately need one.

Start by testing your recovery options. Take a moderately complex task, let it run for a while, then deliberately start a new conversation and try to continue. What survives? What gets lost? What does the AI remember, and what do you have to provide again? Understanding that boundary before you are frustrated changes everything.

Next, audit what is consuming your context budget. Look at the connectors, integrations, and tools loaded in your AI environment. Which ones are you actively using right now? Which ones are passively consuming space? Turn off what you do not need for the current session.

Then practice the carry-forward. Before closing any meaningful working session, copy your key prompts and the AI’s most important output somewhere accessible. Build the habit before you need it. Your future frustrated self will thank you.

Also pay attention to what you cannot diagnose. The next time something does not work the way you expected, notice what information you wish you had. Can you tell why it failed? Can the AI tell you? What are you guessing, and what do you actually know? That gap between what you need to diagnose and what you can access is the frontier of infrastructure literacy.

Finally, decide what you are willing to trade. Every limit has potential workarounds: simpler models, shorter context, fewer features, or less ambitious tasks. Knowing which tradeoffs you are willing to make, and which ones you are not, is itself a form of strategic clarity.

The bottom line

Twenty-nine weeks in, I am doing things with AI I could not have imagined when I started. I am also more frustrated than I have been since the beginning.

Those two facts are not contradictory. They are causally linked.

The early weeks were about discovering what AI can do. These weeks are about discovering what happens when you push hard enough to find the edges. Those edges are not clean, well-documented, or easy to understand. The system often will not tell you where they are until you have already crossed them, and it may not tell you why you crossed them even afterward.

But I know something now that I did not know in Week 1: the constraints are not obstacles to the journey. They are part of it.

Every limit I have hit has forced me to understand something about how these tools actually work, not theoretically, but operationally. That operational understanding is what separates someone who uses AI from someone who can work with it reliably enough to build real things.

The frustration is with the curriculum. The recovery protocol is the homework. And the growing capability, despite the constraints and because of them, is evidence that the learning is working.

This post is part of my “AI Over 40” series. It first appeared on LinkedIn: AI for the Over 40 [Week 29]: When Getting Better Makes Everything Harder.

Read more AI and Copilot blogs.

Trending Posts