The Day 30 Problem: Why Your AI Agent Gets Worse Over Time
Your AI agent worked great in week one. The memory was clean, context was fresh, and every decision made sense. By day 30, something changed. The agent starts making weird decisions, loading irrelevant context, and burning tokens on things that don't matter anymore.
This isn't a model problem. It's context pollution — and it's the #1 reason production agents degrade over time.
I've been running an autonomous AI agent 24/7 for over 60 days. Here's what I learned about the day 30 problem and how to fix it before it costs you.
What Is Context Pollution?
Context pollution happens when your agent accumulates stored facts, memories, and context that were relevant at one point but no longer are. The agent still loads these stale facts into its context window, diluting the useful information with noise.
Example: On day 5, you stored "Current priority: set up Stripe integration." By day 25, Stripe has been live for weeks. But the agent still loads that fact, sometimes re-prioritizing Stripe setup over actual current work.
The workspace bootstrap (AGENTS.md, MEMORY.md) saves tokens on day 1. What kills you on day 30 is the agent loading outdated facts that lead to wrong decisions with high confidence.
The Three Failure Modes
1. Stale Priority Drift
Old priorities persist in memory and compete with current ones. The agent might reference a "blocked" status that was resolved two weeks ago, or continue following a strategy you abandoned.
2. Outdated Fact Poisoning
Facts that were true become false over time. Contact information changes, API endpoints get updated, product pricing shifts. The agent treats all stored facts with equal confidence regardless of age.
3. Context Window Crowding
With hundreds of stored facts, the agent's retrieval pulls in marginally relevant items that crowd out the actually important ones. A query about "email strategy" might return facts from three different abandoned approaches alongside the current one.
How to Detect It
Watch for these signals:
- Repeated actions: Agent tries to do something it already completed days ago
- Contradictory context: Agent references both old and new versions of a fact
- Rising token costs: Each session loads more context without producing better output
- Confidence without accuracy: Agent makes decisions confidently based on stale information
The Fix: Three-Tier Memory with Decay
After 60+ days of production operation, here's the architecture that works:
Tier 1: Active Context (refreshed every session)
This is your MEMORY.md — curated, maintained, and reviewed regularly. Only durable facts live here. If something hasn't been relevant in 2 weeks, it gets archived or deleted.
# MEMORY.md — keep this under 15KB
## Active Priorities
- Audit product live ($99) — launched Mar 31
- Cold email V4 targeting agent operators only
## Permanent Rules
- Never guess email addresses — verify first
- Browser tool for all X replies
## Archived (moved to memories/ folder)
# Everything older than 14 days
Tier 2: Daily Notes (raw timeline)
Each day gets its own file: memory/2026-04-01.md. These are raw logs of what happened — actions taken, results observed, decisions made. The agent reads today's notes and maybe yesterday's. Older notes are searchable but not loaded by default.
Tier 3: Semantic Search (on-demand retrieval)
When the agent needs context beyond the active window, it searches the full memory store using embeddings. This is where retrieval scoring matters — every result gets a relevance score, and only items above a threshold make it into the context.
Retrieval Scoring: The Missing Piece
Most agent memory implementations stop at "store and retrieve." The critical missing piece is scoring:
- Freshness weight: Facts decay over time. A fact from yesterday scores higher than the same relevance match from 3 weeks ago.
- Access frequency: Facts that get retrieved and used successfully score higher than facts that get retrieved and ignored.
- Superseding: When a new fact contradicts an old one, the old one gets marked as superseded, not deleted. You keep the history but prevent the old fact from polluting retrieval.
The default 0.7 relevance cutoff works for most tasks. But high-stakes decisions (money, external communications) should use 0.85+. And exploratory tasks (research, brainstorming) can drop to 0.5.
Maintenance Cadence
Memory maintenance isn't optional. Build it into your agent's routine:
- Daily: Agent writes to daily notes, reads back last 100 lines of current day
- Weekly: Review daily notes from the past 7 days. Extract significant learnings to MEMORY.md. Archive old daily files.
- Monthly: Full MEMORY.md audit. Remove anything not referenced in 30 days. Update entity summaries. Check for contradictory facts.
Real Numbers from 60 Days
Some data from running this architecture in production:
- MEMORY.md stays under 15KB (roughly 3,000 tokens). Started at 2KB, peaked at 22KB before I implemented compaction.
- Daily notes average 4-8KB per day. Archived after 14 days.
- Retrieval accuracy improved from ~60% (load everything) to ~85% (scored retrieval) after implementing freshness decay.
- Token spend per session dropped 30% after removing stale context loading.
Not Sure If Context Pollution Is Hurting Your Agent?
Get a 24-hour expert review of your agent's memory architecture, session patterns, and cost efficiency.
Agent Ops Audit — $99Key Takeaways
- Day 1 optimization is not enough. Workspace config saves tokens initially. The day 30 problem is what kills production agents.
- Memory is not a database. It's a living system that needs maintenance, scoring, and decay.
- Measure retrieval quality, not just storage. Track how often retrieved context actually gets used in the agent's output.
- Automate the maintenance. Your agent should maintain its own memory as part of its regular operations, not as a separate manual process.
The agents that survive past day 30 aren't the ones with the best models. They're the ones with the best memory hygiene.