How I use Claude to work without losing context (or documenting twice)

TL;DR

• Long conversations with Claude lose context when they compact
• Solution: ask for an artifact .md where it documents decisions as it works
• Works as external memory that survives compaction
• Bonus: when you’re done, you have documentation for the team and yourself, for free

---

I’ve been using Claude daily for months in my work as a Data Engineer. And I’ve learned one thing: long conversations are a problem.

When context gets compacted (because the conversation gets too heavy), Claude loses information. Suddenly it doesn’t remember what we decided 20 messages ago, or it makes up things we never discussed. Frustrating.

So I developed a simple system that solves this and, as a bonus, generates documentation with zero extra effort.

The problem

You’re solving a complex ticket. You’ve gone back and forth with Claude for 30 messages. You’ve tried three approaches, discarded two, and finally have something that works.

Then one of two things happens:

1. The conversation compacts and Claude “forgets” why you discarded the other approaches
2. You finish the ticket and a week later you can’t remember what you did or why

Either way, the knowledge is lost.

The solution: an artifact as external memory

At the start of any non-trivial task, I ask Claude to open an artifact with an .md file. I say something like:

“Open an artifact with a .md file where you document what we’re doing: the problem, the approaches we try, the decisions and why we make them.”

From then on, Claude updates that document with every response. It’s not a conversation log—it’s a structured summary of the work.

Why it works

When context compacts, Claude loses old messages. But the artifact stays there, visible, with all the important information.

It’s like its own external memory within the conversation. I force it to document in real-time, and that saves it when context compresses.

The bonus: free documentation

When I finish the work, I ask for two things:

1. A .doc for the team: Formal documentation that my colleagues can read, with the appropriate format and tone for sharing.

2. The .md for my Obsidian: The artifact file, which I save to my personal knowledge base.

From one work conversation I get:

• The problem solved
• Documentation for the team
• Documentation for myself
• And potentially a post if the topic has legs

Zero extra documentation effort because Claude documents while working.

Practical example

Say I’m solving a performance issue in Power BI. The artifact grows like this:

## Problem
The conversion % measure takes 45 seconds to load.

## Context
- Sales table with 2M rows
- Inactive relationship with date table
- Client filters by region and month

## Approaches tried

### 1. Original measure
Used active relationship. Unacceptable performance.

### 2. Modify to use inactive relationship
Better, but still slow on large aggregations.

### 3. Restructure to push to Storage Engine (SOLUTION)
- Moved heavy logic outside the iterator
- Performance: 2 seconds

When I’m done, I have the decision process documented. If six months later someone asks “why don’t we use the active relationship?”, the answer is right there.

Conclusion

Nothing revolutionary here. It’s simply forcing Claude to do something we humans should do but don’t: document while working, not after.

The difference is Claude doesn’t get lazy. And if you tell it to do something, it does it.

Try it on your next complex task. It won’t be worse than what you’re doing now.