Context Stuffing ≠ Context Engineering
Why Context Hoarding Disorder Is Quietly Breaking AI Systems
Mistaking context stuffing for context engineering? That’s Context Hoarding Disorder, and it’s getting expensive. Here’s how to diagnose it and cure it.
Right now, context engineering is having a moment.
It’s being treated like the new black:
bigger context windows
richer RAG pipelines
more files
more memory
more agents
more evals
The implication is simple:
If we just give the model enough context, it will reason better.
That sounds responsible.
It demos well.
It feels like engineering.
At scale, it’s a trap.
Because most of what’s being called context engineering right now is something else entirely:
context stuffing.
And confusing the two is going to lead to some very expensive mistakes.
We’ve Made This Mistake Before (Several Times)
This failure mode isn’t new.
AI just put it on a faster clock.
Agile taught us you can’t scale teams by piling people into a room like clowns into a Volkswagen.
Product taught us that epics disguised as stories are just ocean-boiling with extra steps.
Mobile taught us you can’t cram a desktop buffet into a phone-sized takeout box — small screens force information hierarchy.
Digital transformation taught us that dumping everything into a Hadoop lake doesn’t create insight — it creates data swamps where information goes to die.
Cloud & DevOps taught us that “cheap per unit” collapses into surprisingly expensive at scale faster than you can say “egress fees.”
Every time, we tried to scale volume before we shaped structure.
AI is replaying the same mistake —
at inference time, with a meter running.
The Conversation We’re Trying to Avoid
If you’ve ever worked on a platform or infrastructure-heavy product, you know how this story goes.
At some point, a CFO taps you on the shoulder and asks:
“Hey… what the hell is going on with these costs?”
Not angrily.
Not theatrically.
Just… economically curious.
That’s when you realize:
nothing is technically “broken”
adoption looks healthy
usage is growing
And yet…
you’re bleeding money.
That’s not a tooling failure.
That’s a design failure.
What People Think Context Engineering Is
What many teams are doing today:
jamming more documents into RAG like stuffing socks into an overpacked suitcase
expanding context windows reflexively
persisting everything “just in case”
chaining agents without boundaries
adding evals to compensate for inconsistency
This feels thorough.
It feels rigorous.
It feels safe.
It’s also how you:
dilute attention
normalize retries
hide structural problems
and quietly defer accountability
That’s not engineering.
That’s hoarding.
Context Stuffing (The Anti-Pattern)
Context stuffing is the belief that volume substitutes for intent.
It assumes:
relevance will emerge automatically
the model will prioritize for you
more coverage equals more accuracy
evals will save you if things go sideways
At small scale, this is survivable.
At production scale, it creates:
noisy retrieval
unstable outputs
ballooning eval surface area
systems nobody fully understands
Sound familiar?
It should.
This is data lake thinking, replayed at inference time.
The Hidden Cost of Hoarding
Context stuffing doesn’t just make systems messier.
It quietly robs attention, balloons tokens, and drives retries.
When you hoard context:
more tokens get pulled into every interaction
attention gets diluted across irrelevant material
outputs get less confident
retries become normalized
agents get added to “fix” inconsistency
Nothing looks broken.
Everything just gets a little worse — and a little more expensive — every time.
You didn’t design a smarter system.
You designed one that consumes more to decide less.
That’s not an LLM problem.
That’s a hoarding problem.
Context Hoarding Disorder (CHD)
Let’s call this what it is.
What we’ve been describing — context stuffing, hoarding “just in case,” persisting everything — that’s not just sloppy engineering.
It’s Context Hoarding Disorder (CHD).
And like all hoarding disorders:
it starts with good intentions
it feels responsible at first
it looks manageable at small scale
and it quietly becomes expensive as hell
Here’s the question that exposes it:
If a decision or behavior can’t be changed, what the fuck are we doing with this data?
If the answer is “it might be useful someday” — that’s not context.
That’s emotional-support data.
And CHD is the compulsion to keep it around anyway.
Agents Don’t Fix CHD — They Automate the Blast Radius
Another pattern showing up fast: agent sprawl.
When systems feel brittle, teams respond with:
more agents
narrower agents
longer chains
orchestration layers on orchestration layers
Without:
ownership
boundaries
interaction discipline
Agents don’t fix structure problems.
They automate the blast radius.
Bad context design used to fail one query at a time.
Now it fails at agent scale — multiplied, distributed, and harder to debug.
This is Conway’s Law, rendered in silicon.
Eval Worship Is the New Safety Theater
Evals were meant to provide confidence.
Increasingly, they’re being used to compensate for chaos.
When context is poorly shaped:
outputs become inconsistent
teams add more evals
retries get normalized
models are trained to survive noise instead of leverage signal
Evals don’t fix bad context design.
They make bad context design survivable.
And survivable systems scale —
right up until the bill arrives.
This is safety theater for the AI age.
What Context Engineering Actually Is
Context engineering is not about how much context you include.
It’s about how context is shaped, scoped, and invoked.
Real context engineering:
defines bounded context domains
separates always-needed from episodic information
retrieves with intent, not completeness
limits which contexts can interact
keeps working context small
composes answers instead of mashing inputs
In short:
Context engineering is organizational design for attention.
Same discipline.
New surface area.
Why Projects, Gems, and Notebooks Keep Appearing
Look at how people actually work.
Across tools, teams are independently inventing:
projects
notebooks
workspaces
gems
scoped agents
“this work lives here“ constructs
Different names.
Same instinct.
This is the mobile transformation lesson all over again.
Small screens taught us that unbounded information architecture becomes unusable shockingly fast. You can’t show everything at once. Progressive disclosure isn’t optional.
Projects and notebooks aren’t new thinking — they’re the same principle we learned when we tried to cram desktop experiences into phone-sized real estate.
Because deep down, everyone already knows this truth:
Unstructured context becomes unusable shockingly fast.
Nobody wants:
one infinite chat
one global memory
one giant RAG bucket
one attention soup
That’s not intelligence.
That’s Grandma’s attic full of shit.
Projects and notebooks aren’t UX polish.
They’re coping mechanisms.
They exist because humans intuitively understand what many AI systems don’t yet enforce:
context without shape becomes noise.
Let’s Be Explicit
This matters enough to say plainly:
Context stuffing ≠ context engineering.
Stuffing hoards information.
Engineering shapes attention.
One postpones decisions.
The other makes them explicit.
Why This Matters Right Now
We are currently teaching teams that:
more context is safer
more agents is sophistication
more evals is rigor
At demo scale, that’s fine.
At production scale, this thinking:
degrades accuracy
drives unpredictable behavior
constrains future options
and forces rewrites under pressure
These aren’t rookie mistakes.
They’re expensive, structural mistakes —
and we already know how this story ends.
The Pattern (One Last Time)
Agile → right-size teams to protect communication
Product → right-size work to protect flow
Mobile → right-size information to protect attention
Digital → right-shape data to protect meaning
DevOps → right-size infrastructure to protect cost
AI → right-shape context to protect everything else
Scale fails when structure is deferred.
Get the Right People in the Room (And Ask the Right Questions)
Context engineering is not a solo PM activity.
If you’re trying to figure this out alone, you’re already losing.
Here’s who you need:
Find the data engineer who survived the Hadoop swamp.
They already learned that dumping everything into a lake doesn’t create insight. They know what happens when structure gets deferred. They’ve seen this movie.
Find the person who got good at splitting user stories.
Not the one who writes epic-sized stories with subtasks. The one who learned to right-size work so it doesn’t boil the ocean. They understand boundaries.
Find the UX person who survived mobile transformation.
They already learned you can’t show everything at once. They know what happens when you try to cram desktop thinking into a constrained space. They understand progressive disclosure and information hierarchy.
Find the platform person who watched cloud costs explode.
They know what “cheap per unit” looks like when it scales without discipline. They’ve had the CFO conversation. They have scars.
Get them in a room.
Product, engineering, architecture, platform, UX.
And ask these five questions:
Five Questions to Ask Before You Add More Context
1. What decision does this context support?
Not “what might it help with.” What specific decision can’t be made without it?
If the answer is “it might be useful” — that’s hoarding.
2. Can this be retrieved instead of persisted?
Working memory ≠ reference library.
Not everything needs to be in the room. Some things can be called when needed.
3. Who owns this context boundary?
If nobody can explain what stays in vs. what stays out, you don’t have a boundary.
You have a bucket.
4. What happens if we don’t include this?
Name the actual failure mode.
“We might need it later” isn’t a failure mode. It’s a hoarding instinct.
5. Are we adding this to fix structure or avoid it?
More context to compensate for bad shape isn’t engineering.
It’s technical debt with a meter running.
These aren’t rhetorical questions.
They’re the conversation.
The data engineer will recognize question 2.
The story-splitter will recognize question 4.
The UX person will recognize question 1.
The platform person will recognize question 5.
You’re not inventing new discipline.
You’re translating lessons they already learned.
Closing
If your “context engineering” strategy is:
add more context
add more agents
add more evals
You’re not engineering.
You’re postponing the bill.
Context Hoarding Disorder isn’t a tooling problem.
It’s an information architecture problem.
And we already know how to fix those.
We’ve done it before.
Get the right people in the room.
Ask the five questions.
Shape your context instead of stuffing it.
Before it gets expensive.