Why changing the model means recalibrating the whole agent team.

Agile has a useful rule of thumb: when the team changes, revisit its velocity. Someone leaves, someone joins, and the old delivery forecast needs another look.

Velocity records how much estimated work a team actually completes in an iteration. Using that history to forecast assumes some continuity in the team and its working conditions. Change the composition and you may need to establish a new baseline. This is a forecasting practice, not a commandment to erase the old measurements. (Agile Alliance on velocity, Scrum patterns on recalibration)

The reason runs deeper than headcount. People carry knowledge, unblock one another, catch different mistakes and establish ways of working together. The number you measured reflects those relationships.

Think about what happens when a senior developer leaves. The replacement may be excellent, but the person who knew why the billing service behaves strangely on the last day of the month is gone. Reviews slow down. Questions take longer. Or the replacement spots an unnecessary dependency and suddenly everyone can move faster.

Now consider a VP of Engineering. A replacement can change how decisions are made, which problems receive attention and how much authority teams have. The same developers, working on the same product, can become a very different organization.

We recognize these effects in human teams. We should bring that understanding to agentic systems.

When a model’s capabilities change, reconsider the team around it. Its sub-agents, instructions, memory, tools and verification were designed around a particular set of abilities. Those assumptions deserve another look, whether the replacement is stronger, weaker, or simply different.

Your strongest agent has coworkers

Imagine a coding system with a capable lead agent, several cheaper implementation agents and a verifier. The lead divides the assignment, the workers make changes, and the verifier checks the result. The harness is the software that supplies context, exposes tools and manages those handoffs.

Now upgrade the lead.

It may understand a change across the database, API and interface well enough to produce a more coherent plan. But if it starts delegating larger assignments with fewer intermediate checks, the unchanged workers may struggle. The coordinator can now see farther than its team can reliably follow.

Consider a time-zone change. The lead understands that every layer must agree on what a timestamp means. A worker receiving only “update timestamp handling” may lack the context to implement that agreement. A stronger plan still needs a usable handoff.

Perhaps the lead should handle the coupled changes itself. Perhaps workers need more explicit contracts, better context or different models. Perhaps the verifier needs to test the complete journey of a timestamp through the application. The useful redesign depends on where the work now succeeds and fails.

A better coordinator does not automatically make its coworkers better. A better worker does not automatically need the same supervision.

The reverse matters too. Replace the lead with a smaller model to reduce cost, or encounter a release that performs worse on your particular work, and the old delegation scheme may ask more of it than it can deliver. Narrower assignments, a simpler workflow or escalation to a stronger model may become necessary.

Changing the harness can have similar effects without changing a single model. Alter what workers can retrieve, how their conversations are summarized or when they are allowed to act, and you have changed their working conditions.

That is a form of drift worth watching: the team’s capabilities and the organization of its work stop fitting one another.

Some of the process belongs to the old team

Agent builders accumulate process for understandable reasons. A model forgets a dependency, so we add planning. It loses track of a long assignment, so we split the work. It claims success too early, so we add verification.

Over time, enduring requirements and temporary workarounds become difficult to distinguish. The instructions remember every bad afternoon.

Anthropic documented this problem in an application-building harness. Moving from Sonnet 4.5 to Opus 4.5 allowed the team to remove context resets. With Opus 4.6, it also removed an explicit sprint structure, while retaining the planner and evaluator because they still added value. The useful configuration changed with the model. (Anthropic’s engineering account)

Memory can preserve the old arrangement too. “Split every change into single-file tasks” may survive long after the limitation that justified it. Record why a workaround exists and which conditions should trigger a review.

The distinction matters. “This worker needs smaller tasks” is a performance assumption. “This action requires customer approval” is an authority boundary. More capability gives us a reason to revisit the former; it does not grant permission to discard the latter.

Deleting an obsolete workaround deserves a small launch party. Order me a vodka/soda please.

Measure the team you have now

The Agile lesson is to renew the evidence behind your expectations. For agents, that means evaluating the complete system when a model or harness change could materially affect the work.

Start with a handful of representative assignments: an ordinary success, a difficult case, a previous failure and a task that should stop at an access boundary. Preserve the starting conditions and what counts as a correct result.

Run the current configuration, then change the model while keeping the harness comparable. Repeat the assignments enough times to distinguish a reliable pattern from one lucky run. After that, adjust the surrounding team one meaningful change at a time.

Look for where the new arrangement strains. Are workers receiving tasks they cannot complete? Is the lead repeating work the specialists already handled? Is the verifier rejecting valid results or accepting unsupported claims? Those observations tell you which roles and handoffs need attention.

Measure accepted results, defects, elapsed time, total cost and human cleanup. More tool calls or faster token generation may explain behavior, but the job still has to get done. Keep acceptance criteria consistent during comparison; a system that passes by weakening its own tests has not demonstrated improvement.

Save the configuration alongside the results, including the model versions, instructions, tools and relevant memory state. Keep a way to restore the prior setup, and use a test environment when actions would change external systems. Historical results remain useful when you know which team produced them.

You may discover that one worker needs a different model, three handoffs can disappear, or the new coordinator is a poor fit for this job. Reconsidering the whole system does not require replacing every component. It requires checking their relationships.

We would allow a changed human team to establish how it works and demonstrate what it can deliver. Our agent teams deserve the same engineering attention.

Tread carefully. The project name and architecture diagram may look the same, but the team inside those boxes has changed. Keep your head on a swivel and stay frosty! (My Call of Duty is showing.)

Mahalo for reading!
Aloha –TK