My Coding Agent Did the Dumbest Thing. It Was Totally Avoidable.

Let me tell you what happened to me last month. I was working on a material requirements feature. I had Claude Code open, Opus 4.6. I asked it to build out a material requirements feature. Sounds simple enough, right?

Wrong.

Luckily I was in plan mode, because I sat there and watched it plan a brand new parts database. It had completely ignored the parts database that already existed in the project. You know, the one I had built days before.

Yeah I caught it. But I only caught it because I had plan mode on and I had the patience to watch it rip through what seemed like the entire codebase just to never figure out it was already there.

I am not blaming Claude. It could have just as well been my prompt or the structure of the codebase but nevertheless it comes back to the same issue.

The agent didn't know. It had no memory of our prior work. For context it had to rely on my prompt and its ability to grep the codebase. Outside of that it had no ideas about my goals, plans, decisions and lessons learned up to that point.

Now if I'd skipped plan mode, I'd have spent hours untangling that mess.

I want you to think about what really happened in that moment. The agent's first move wasn't to work on what I needed it to. It was reconstruction. It knew what it knew, and it had to fake the rest.

That's why in a recent post Andrej Karpathy called agents "spiky entities."

He said this about frontier models: "This matters because frontier models do not come with a manual. They are artifacts of pretraining mixtures, RL environments, benchmark pressure, product priorities, and economic incentives. They spike in some places and behave strangely in others."

To me this implies that between those spikes are valleys. The valleys are the knowledge between domains that are not in the training data. Frankly, those valleys make potentially good work suck. There's no spike for your database. There's no spike for your logic. There's no spike for that decision you made in the meeting two weeks ago.

The valleys between the spikes are treacherous.

That's why we made ContextStream. It's designed to help fill in between the spikes.

Not by storing your code. Not by indexing your chat history. By capturing the things that don't live in either one — the decisions, the constraints, the lessons, the reasons. The stuff that explains why your project looks the way it does.

It stores and retrieves your context, but it's not a filing cabinet. It's not something you have to remember to use. It's not a discipline. It captures your project knowledge passively while you work. Your decisions, lessons learned, code changes, your constraints.

The model brings its spikes — its training data, its RL on certain domains. ContextStream brings everything between them.

Put those together and the agent's knowledge is smoothed out. Now it actually knows your project. Not in some vague or general way, but in the specific way that matters when it's about to plan a duplicate of something you already built. It just knows not to.

Filling the valleys does something else, too. It makes the project remember. The next time you sit down to work, the valleys are still filled. The agent doesn't have to relearn what you built last week. You don't have to re-explain the decision you made in Tuesday's meeting. The terrain stays smooth across sessions.

That's what was missing the day my agent started planning the duplicate. The valleys weren't filled. So it filled them with whatever it could grep up in the moment.

ContextStream changes that. Before the agent touches a plan, before it builds a single thing — it's going to get the full context. Existing schemas, prior decisions, constraints from your last few sessions. That retrieval isn't optional. It's the first step of getting back to work. It's the difference between an agent that can just get to work and a dumb agent you have to teach everything to again.

The alternative is simple. Pull in what the project already knows before you start. Work with that context in hand. Let the important stuff get captured on the way out. Pick it up next session without starting over.

Notice that third one. Let it get captured. Not "remember to save it." Not "make sure you file it properly." The valleys get filled as a side effect of the work, not as an extra chore.

Every session leaves the terrain a little smoother. The project gets smarter every time someone works in it. You stop watching agents rebuild things that already exist. You stop reconstructing context that should already be there.

Most people come at AI coding agents with the wrong mental model. They make elaborate prompts. They prune markdown files like bonsai trees. The makeshift solutions get more complicated every week.

None of it fixes the spikiness. None of it fills the valleys.

When the valleys are filled, the question changes. You stop asking how to make the agent smarter. You start asking what the project already knows that should shape the next move.

That's a better question. It's also one the agent can answer for itself once the valleys are filled.

The parts database situation came about because the valleys weren't filled. Opus 4.6 knew exactly how to build what I asked for. The spike was there. What was missing was everything my project already knew. The agent doesn't start cold when the valleys are filled. It starts from project state.

This is the question you should be asking before every single task.

How does the context we have shape our next move?

Sometimes the answer is a prior decision. Sometimes it's a constraint. Sometimes the agent needs to know what you built and why.

ContextStream MCP shows up before the work starts. Not during. Not after the false start. Not after you watch plan mode outline what already exists.

Before.

That's the whole game.