Do Agent Frameworks Become Obsolete in Six Months?

Boris Cherny, a founding member of Claude Code who has been dubbed the “father of Claude Code” by developers, recently poured cold water on Agent developers: The carefully constructed harness you build today may have a shelf life of only six months.

This does not mean Claude Code, Cursor, or other Agent frameworks will disappear in six months. Rather, it means that complex engineering solutions built around the weaknesses of current models may rapidly lose value when the next generation arrives. Today, you may still need planners, routers, prompt chains, and multilayer error-correction mechanisms. Tomorrow, a model may be able to complete the same task in a single call.

For teams investing heavily in “building Agents,” this assessment is hard to hear. But judging from Claude Code’s evolution, it is not an inflammatory claim made for attention. It reflects firsthand product experience from a team working at the frontier of model development.

What Exactly Is a Harness?

In the context of Agents, a harness can be understood as the “tack” placed around a large language model. The model handles reasoning and generation, while the harness connects it to a real software environment, including:

• Providing the model with tools for reading files, searching, using the terminal, and editing code;
• Managing the context window and compressing or restoring historical information;
• Planning tasks, breaking them into steps, and retrying after failures;
• Orchestrating sub-Agents and controlling concurrency and task dependencies;
• Defining permission boundaries and intercepting dangerous commands;
• Recording trajectories, costs, execution times, and results;
• Validating outputs through tests, static analysis, or review Agents.

Without a harness, a large language model is merely a chat interface that happens to be good at writing code. With a harness, it may be able to open a repository independently, locate a problem, modify files, run tests, and then submit the results to a human.

As a result, competition among Agent products over the past year has often been about more than simply who has access to the strongest model. It has also been about who can constrain that model within an execution chain that is stable, recoverable, and auditable. Claude Code’s value comes not only from the Claude models, but also from the systematic way it organizes the terminal, codebase, permissions, and context.

The problem is that these organizational approaches may not have a very long lifecycle.

Why Six Months?

Cherny’s central argument is that large language models are more like rapidly growing organisms than traditional software components with fixed specifications.

Upgrades to traditional infrastructure generally emphasize compatibility. When a database releases a new version, its query semantics do not suddenly change across the board. When a compiler improves, the build system does not become obsolete overnight. But changes in the capability boundaries of large language models are not smooth. A single version upgrade may simultaneously transform the model’s tool-calling capabilities, long-context performance, error-recovery behavior, and ability to sustain long-running tasks.

This directly affects harness design.

Suppose a model frequently forgets the task objective. The development team will typically introduce a state machine that reinjects the plan after each completed step. If the model does not proactively validate its code, the team will enforce an “edit-test-fix” loop. If the model struggles with large repositories, the team will add retrieval, summarization, and file-ranking modules.

All of these solutions are useful today. But when a new model can reliably maintain long-term goals, proactively run tests, and accurately understand an entire repository, the original state machine and retrieval chain may change from “reliability safeguards” into “capability ceilings.”

The biggest problem with a complex harness is not the amount of code it contains, but the way it solidifies developers’ assumptions about older models. The model may already be capable of deciding its own next step, while the framework still forces it to fill in fixed fields. The model may be able to explore dynamically, while the workflow requires it to follow predetermined nodes rigidly. The model may discover that the original plan was wrong, while the scheduler continues pushing it toward an outdated objective.

The guardrails that prevented the model from making mistakes yesterday may become the fences that prevent it from performing at its best tomorrow.

The six-month shelf life is therefore best understood as a product discipline: after every model cycle, teams should reassess whether each complex module in the harness is still necessary, rather than assuming the existing architecture will remain correct forever.

Claude Code Is Both the Counterexample and the Evidence

Claude Code’s early history illustrates this point well.

Cherny recalls that Sonnet 3.5 was the first model that made the team feel they were approaching the threshold at which a model could “directly complete an entire coding task.” He therefore began building an internal tool that allowed an Agent to take over more coding work. During roughly the first six months, however, the product was not very useful. Cherny himself may have used it to produce only around 10% of his code.

The team was not unaware that the product was still immature. Rather, it was building the interaction model and execution environment in advance for the next generation of models. In other words, Claude Code temporarily existed in a peculiar “model futures” state: the product did not yet have the capabilities required for product-market fit, but the team believed upcoming models would fill the critical gaps.

Once model capabilities crossed that threshold, the product design that had previously seemed overly ambitious suddenly became reasonable. The Agent was no longer limited to completing the next line of code. It could read a project, modify multiple files, execute commands, and iterate continuously.

This history demonstrates two things at once:

1. Product teams need to stay half a step ahead of current models; otherwise, when a new model is released, they can only scramble to assemble an interaction layer around it;
2. There is no value in getting too far ahead, either. When a model is fundamentally incapable of performing a task, piling on workflows usually produces a demo rather than a reliable product.

A good Agent product must therefore maintain an uncomfortable balance: it must leave room for the next generation of models without betting everything on capabilities that have not yet materialized.

“Loosening the Reins” Does Not Mean Removing Safety Mechanisms

Cherny argues that models should be given more freedom, but this can easily be misinterpreted as “doing less engineering” or even “removing permission controls.” In reality, the opposite is true.

What should be relaxed is the micromanagement of the model’s reasoning path, not enterprise security boundaries.

For example, the following two types of constraints must be distinguished:

| Constraint Type | Typical Approach | Should It Be Retained Long-Term? | | --- | --- | --- | | Capability patches | Enforcing fixed steps, repeatedly restating objectives, manually decomposing every subtask | Should be continually reduced as models improve | | Security boundaries | Sandboxing, permission approvals, secret isolation, audit logs, rollback mechanisms | Should be retained and strengthened over the long term |

Allowing an Agent to decide whether to read the tests or inspect the call chain first is “loosening the reins.” Allowing it to access a production database without confirmation is not.

Allowing an Agent to revise its approach after a failure is “loosening the reins.” Allowing it to bypass branch protection and push directly to the main branch is not.

The stronger the model becomes, the more a product should reduce hardcoded controls over its thought process while making permissions, outcome validation, and impact boundaries clearer. The former determines the upper limit of its capabilities; the latter determines whether the system can be deployed in production.

Multiple Agents Are Not Necessarily More Advanced Than a Single Agent

Another common impulse in current Agent products is to add more Agents whenever a single Agent is not stable enough. One Agent handles planning, another handles implementation, another handles testing, and yet another reviews the first three.

This architecture looks impressive in a diagram, but it may not be well suited to actual delivery.

Multiple Agents can create value when tasks are naturally parallelizable. Examples include investigating several independent modules simultaneously, processing multiple unrelated issues in batches, or assigning different Agents to run time-consuming experiments. But when tasks involve large amounts of shared state, multiple Agents instead introduce communication overhead, inconsistent context, and merge-conflict costs.

More importantly, multi-Agent systems are often used to compensate for the limitations of a single model. If the model cannot plan reliably, a planning Agent is added. If it cannot check its results, a review Agent is added. If it easily loses context, a memory Agent is added. Once the next generation of models can handle all these responsibilities itself, the elaborate division of roles may rapidly become unnecessary.

Before introducing multiple Agents, developers can ask three questions:

• Are the subtasks genuinely independent and suitable for parallel execution?
• Is the information exchanged between Agents smaller and clearer than the complete shared context?
• Does adding another Agent improve the success rate enough to offset the cost, latency, and debugging complexity?

If the answer to all three is no, a multi-Agent system may simply turn one unreliable call into five interdependent unreliable calls.

What Does Not Easily Become Obsolete: Evaluation and Domain Knowledge

If a harness has a shelf life of only six months, what should Agent teams accumulate instead?

The first is domain-specific evaluation.

Prompts, routing rules, and workflows become obsolete, but realistic task sets do not become obsolete so easily. A payments team knows which refund logic is most prone to errors. A database team knows which migrations may lock tables. A large frontend team knows which component changes can cause subtle regressions. These production-derived cases are the true benchmarks for determining whether a new model has improved.

Without an evaluation set, teams will simply be led around by model demos. Every time a new model is released, people will declare another “programmers have been replaced” moment based on a few impressive examples, only to discover weeks later that the model remains unreliable in their own codebase.

The second is the environment and feedback loop.

Whether an Agent can run tests, read logs, observe application behavior, and continue fixing problems based on errors is often more important than how elegantly its prompts are written. These feedback interfaces remain valuable after model capabilities improve because they provide facts that reasoning alone cannot conjure out of thin air.

The third is organizational knowledge.

Code is only one part of an enterprise system. Who maintains which services, which rules originate from regulatory requirements, and which seemingly useless compatibility branches must not be removed—this information is often scattered across documentation, tickets, and employees’ experience. If an Agent cannot access it, even the strongest model can produce only code that is “syntactically correct but organizationally wrong.”

When Cherny says that “the hard part is understanding the domain,” this is exactly what he means. The moat of future Agent products may not be more complex loops, but the ability to connect models to high-quality, verifiable working environments enriched with business semantics.

100% AI-Written Code Does Not Mean 100% Absence of Human Responsibility

Cherny has also shared a more radical personal workflow: he now has AI generate nearly all of his code and uses multi-Agent workflows to process changes and pull requests at high frequency.

This figure is easy to misunderstand. The fact that AI writes every character does not mean humans have withdrawn from software engineering. Human work is shifting from “typing line by line” toward four higher-leverage activities:

• Selecting problems: deciding what is worth doing and what should not be done;
• Providing context: giving the Agent business constraints, historical decisions, and acceptance criteria;
• Designing feedback: ensuring that tests, logs, and reviews expose errors quickly;
• Taking responsibility: deciding whether a change is safe to deploy in a real environment.

Producing a large number of pull requests in a single day does not necessarily mean the team has achieved an equivalent increase in useful output. If review capacity, testing infrastructure, and release processes do not improve at the same pace, more pull requests will merely shift the bottleneck from coding to review and integration.

Therefore, “how much code AI wrote” is not the most useful metric to track. More meaningful metrics include how long a task takes from proposal to production, how many times humans intervene, whether the rollback rate increases, and whether the Agent can reproduce successful outcomes consistently on the same tasks.

Practical Advice for Agent Developers

Faced with rapidly changing models, the most practical strategy is not to stop building harnesses, but to design them as systems that can be deleted.

First, keep the model layer replaceable. Do not tightly couple business logic to a specific model’s special prompt format, tool-parameter conventions, or undocumented behavior. A unified interface may not eliminate every difference, but it should at least allow the team to compare models at low cost.

Second, define exit criteria for complex modules. Whenever you add a planner, memory layer, or error-correction loop, document which failure mode it addresses and how much it improves the success rate. When a new model is released, rerun the evaluations and remove the module if its benefits have disappeared.

Third, prioritize observability. Preserve tool calls, context changes, failure reasons, and points of human takeover. A harness can only be simplified if the team knows where the complexity is actually being spent.

Fourth, keep workflows thin and boundaries hard. Specify less about how the model must think, and more about what it cannot access, how much it may spend, which operations require confirmation, and how final results will be validated.

Fifth, continuously test an “unleashed” baseline. Many teams test only whether a new module outperforms an old one, but no longer test how well the latest model performs the task directly. The result is an increasingly complex framework that obscures the fact that the bare model has already surpassed the entire legacy workflow.

A Six-Month Shelf Life Eliminates the Wrong Kind of Moat

Agent harnesses will not disappear. As long as models need to interact with files, terminals, browsers, and enterprise systems, they will require some form of runtime environment. As long as Agents can affect the real world, they will require permissions, auditing, and recovery mechanisms.

What will disappear rapidly are the components tightly coupled to the shortcomings of a particular model generation but packaged as long-term platform capabilities.

This is the most important lesson for developers from Cherny’s remarks: Do not mistake what a model temporarily cannot do for your permanent moat.

Over the next six months, models are likely to continue absorbing capabilities such as planning, retrieval, tool selection, and error recovery. Agent products will not become worthless as a result, but their value will migrate toward both ends of the stack: secure, reliable execution environments at the bottom, and hard-to-replicate domain knowledge and organizational processes at the top. The “smart glue” in the middle, made up of large amounts of prompting and state machines, is in the most precarious position.

For teams already building Agents, the question to ask now is not “What else can we add to the framework?” but “If the next generation of models is twice as capable, which parts of the code we are writing today should we delete immediately?”

Only teams that can answer this question seriously are likely to outlive their own harnesses.

References

• “The Harness: Decoding Agent Harnesses”: Breaks down Claude Code’s harness design from the perspectives of tool calling, context management, permission controls, streaming architecture, and multi-Agent orchestration.
• Claude Code’s Real Moat Was Never the Model—An In-Depth Explanation of Harness Engineering: Discusses the relationship between model capabilities and the Agent engineering layer, as well as the role of harnesses in real-world coding products.