Your agent is underperforming. Now what?
You have an agent that isn't working the way it used to. Maybe your weekly review routine has become a hollow ceremony — you go through the motions but nothing changes afterward. Maybe a decision framework you relied on for years keeps producing answers that feel wrong in your current context. Maybe a morning habit that once energized you now drains you before the day begins.
You have exactly two options: evolve the agent or replace it.
Evolution means modifying the existing agent — adjusting its triggers, refining its steps, removing what's accumulated, sharpening its purpose. The agent's core identity persists. You're working with the same structure, improving it incrementally.
Replacement means retiring the current agent and building a new one from scratch. The old agent's identity ends. You design something fresh, informed by what you learned but unconstrained by what you built.
Both are valid responses to agent decay. The problem is that most people default to one or the other based on temperament rather than diagnosis — and both defaults are expensive.
The Ship of Theseus problem lives in your cognitive infrastructure
Plutarch posed the question in the first century: if the Athenians replaced every plank of Theseus's ship over time, was the fully restored vessel still the same ship? Thomas Hobbes later sharpened the paradox — what if someone collected all the discarded planks and assembled them into a second ship? Which one is the "real" Ship of Theseus?
This isn't an abstract puzzle when applied to your agents. Consider a decision framework you've been evolving for five years. You changed the trigger conditions after a bad outcome. You added a step for emotional regulation after you noticed impulsive patterns. You removed two criteria that stopped being relevant when you changed roles. You rewrote the final evaluation heuristic twice.
At what point is this "the same framework"? And more importantly — does the answer matter?
Aristotle argued that identity persists through continuity of form, not material. As long as the ship's design — its formal cause — remains, replacing individual planks preserves its identity. Applied to agents: if your framework still serves the same purpose and follows the same structural logic, incremental modifications preserve it. But if you've modified the purpose, the logic, and the triggers, you may be maintaining a label while operating an entirely different agent. That fiction costs you clarity.
What software engineering learned the hard way
In April 2000, Joel Spolsky published "Things You Should Never Do, Part I" — a warning against rewriting software from scratch that became one of the most influential essays in software engineering. His central example was Netscape, which decided to rewrite their browser from scratch for version 6.0. The rewrite took three years. During those three years, Internet Explorer captured the browser market. Netscape never recovered.
Spolsky's argument was structural: when you throw away code and start from scratch, you're throwing away all the knowledge embedded in that code. Every bug fix represents a hard-won lesson about an edge case. Every ugly workaround reflects a real constraint in the environment. The code doesn't look clean because reality isn't clean, and the new version will eventually have to learn all the same lessons — if the project survives long enough.
The same principle applies to cognitive agents. A habit you've been running for three years contains encoded knowledge — subtle adaptations to your schedule, your energy patterns, your failure modes. A decision framework that's been through twenty real decisions carries embedded wisdom about edge cases that a freshly designed framework won't have. When you scrap an agent and start over, you lose that accumulated intelligence.
But Spolsky's essay isn't the whole story. His critics — and there have been many over the twenty-six years since — point out cases where rewriting was exactly the right call. When the original architecture is fundamentally wrong for the current requirements. When accumulated patches have made the system so complex that every modification breaks something else. When the environment has changed so dramatically that the original design assumptions no longer hold.
Martin Fowler identified a middle path: the strangler fig pattern. Named after tropical vines that gradually grow around a host tree until they can stand independently, this approach replaces a system incrementally — routing more and more functionality to the new system while the old one continues operating. Eventually the old system handles nothing, and you remove it. The identity shift happens gradually rather than all at once.
The renovation decision in physical systems
Builders face this exact decision with physical structures. The industry rule of thumb: if renovation costs exceed 50 percent of the structure's value, demolition and rebuild becomes more financially sound. But cost alone doesn't capture the full picture.
Three factors determine whether renovation makes sense. First, structural integrity — if the foundation and load-bearing walls are sound, renovation works because you're modifying surfaces, not the skeleton. Second, systems compatibility — if the electrical, plumbing, and HVAC can be upgraded without gutting the building, renovation preserves more than it destroys. Third, regulatory alignment — sometimes building codes have changed so fundamentally that the existing structure can't be brought into compliance without effectively rebuilding it anyway.
Translate these to cognitive agents. Structural integrity means the agent's core logic still applies to your current situation. Systems compatibility means the agent can integrate new inputs and connect to your other active agents without constant workarounds. Regulatory alignment means the agent operates within your current values, priorities, and life structure — not the ones you had when you built it.
When all three hold, evolve. When none hold, replace. When the answer is mixed, you need a more careful analysis — and this is exactly where most people skip the analysis and follow their bias.
The two failure modes that drain your agency
Compulsive evolution: the sunk cost trap
Behavioral economists have documented the sunk cost fallacy extensively: people continue investing in failing endeavors because of what they've already invested, even when future returns don't justify continuation. A meta-analysis of 98 studies on the sunk cost effect confirmed that the bias is robust across decision types — though older adults, interestingly, are less susceptible, likely because accumulated experience helps them recognize the pattern.
Applied to agents: you keep patching your morning routine because you spent six months building it. You keep using a journaling framework because you bought the fancy notebook and told three friends about it. You keep running a decision process that produces mediocre results because you invested significant emotional energy designing it.
The diagnostic signal for compulsive evolution is easy to spot: you're modifying the agent more often than you're using it. If you spend more time adjusting your weekly review than doing your weekly review, you're maintaining a fiction. The agent isn't working. You're just reluctant to admit it.
Compulsive replacement: the shiny object trap
The opposite error is equally expensive and less discussed. Some people scrap agents at the first sign of friction and design something new. Their note-taking system changes every three months. Their planning routine restarts from scratch whenever it produces a bad week. Their decision frameworks are always in version 1.0 because nothing survives long enough to reach version 2.0.
The cost here isn't sentimental — it's structural. Every time you replace an agent, you lose the accumulated refinements from its operational history. You restart the learning curve. You sacrifice the compound interest that comes from running the same agent through enough iterations to understand its failure modes and optimize its performance.
Thomas Kuhn's research on paradigm shifts is instructive here. He showed that scientific revolutions — the replacement of one paradigm with another — are rare and take decades to complete. The vast majority of scientific progress happens through "normal science": incremental refinement within an existing paradigm. The people who demanded revolutionary change at every anomaly didn't advance science faster. They just never accumulated enough depth within any single framework to produce meaningful results.
The diagnostic signal for compulsive replacement: you have a trail of abandoned agents, each replaced before it had enough operational data to be properly evaluated. If you can't point to specific, structural reasons why the old agent failed — only vague feelings that "it wasn't working" — you may be replacing too early.
The machine learning analogy makes the trade-off concrete
In machine learning, practitioners face the same decision constantly: fine-tune an existing model or train a new one from scratch.
Fine-tuning takes a pre-trained model — one that has already learned general patterns from a massive dataset — and adjusts its parameters for a specific task using a smaller, targeted dataset. It's faster, cheaper, and often produces better results than training from scratch, precisely because the model retains the general knowledge it already acquired.
Training from scratch makes sense under specific conditions: when the new task deviates fundamentally from what the pre-trained model learned, when no pre-trained model exists for the domain, or when the original model's architecture can't represent the patterns the new task requires.
Notice the parallel. Fine-tuning preserves accumulated knowledge and adapts it to new conditions. Training from scratch discards accumulated knowledge because the gap between old and new is too large for adaptation to bridge. The decision isn't about preference — it's about measuring the distance between where the agent is and where it needs to be.
When the distance is small, evolve. The agent's existing architecture can accommodate the change, and the accumulated knowledge is worth preserving.
When the distance is large — when the core assumptions have shifted, when the environment has fundamentally changed, when the agent's architecture can't represent the new requirements — replace. The accumulated knowledge no longer applies, and preserving it actively interferes with building something that works.
A diagnostic framework for the evolve-or-replace decision
When an agent underperforms, run this sequence before deciding:
Step 1: Separate the architecture from the accumulation. An agent has two layers: its core design (the logic, the triggers, the purpose) and its accumulated modifications (patches, additions, workarounds added over time). If the core design is sound but the accumulations have made it bloated or fragile, evolution works — strip the accumulations, restore the core, and rebuild incrementally. If the core design no longer fits your situation, no amount of modification fixes the fundamental mismatch.
Step 2: Count the required changes. Write down every modification you would need to make to bring the agent to acceptable performance. If the list is short — two or three targeted adjustments — evolution is clearly correct. If the list is long enough that you'd effectively be rebuilding every component, you're planning a replacement disguised as an evolution. Call it what it is and do it properly.
Step 3: Test for sunk cost contamination. Ask yourself: if I had never built this agent — if I were starting fresh today with the same need — would I design anything resembling what I currently have? If yes, evolve. If the honest answer is no, you're maintaining the agent because of what you invested, not because of what it produces. Replace it.
Step 4: Check for the strangler fig option. In many cases, you don't need a binary choice. You can build the replacement agent alongside the existing one, gradually routing more of your behavior through the new agent while the old one continues operating. This preserves continuity while allowing a fundamental architectural shift. Your old morning routine still runs on days when the new approach isn't ready. Your old decision framework stays available for domains where the new one hasn't been tested yet. Over time, the new agent handles everything, and the old one retires naturally.
The deeper pattern: identity is a tool, not a constraint
The Ship of Theseus question ultimately asks whether identity is intrinsic or functional. Is the ship "the same ship" because of what it's made of, or because of what it does?
For cognitive agents, the answer is functional. Your agents exist to produce outcomes — decisions, behaviors, habits, responses. When an agent produces the outcomes you need, its identity is irrelevant. When it stops producing those outcomes, its identity can't save it.
Evolution preserves identity and adapts function. Replacement preserves function and discards identity. Both serve the same goal: keeping your cognitive infrastructure aligned with your current reality.
The skill isn't choosing one over the other. The skill is diagnosing accurately enough that the choice becomes obvious — and being honest enough to follow the diagnosis rather than your attachment.
This is the foundation for what comes next. Once you've decided whether to evolve or replace, you need a system for tracking those changes over time. That's agent versioning — the subject of the next lesson.