Models know a lot about software, but we don’t really know how current that knowledge is. A model might have a knowledge cutoff of February 2026. That cutoff merely sets an upper boundary. Its knowledge of your SDK could come from 2023 or combine several conflicting versions, or your SDK might be entirely absent from its training data altogether.
A knowledge cutoff tells us the newest information a model could possibly know. The age of the particular information we’re about to rely on remains unknown. That uncertainty affects anyone building tools, SDKs, APIs, frameworks, and other technologies that agents use. Technology providers can contribute one fact they know very well: how quickly their technology changes.
What’s volatile?
Think about two pieces of technical knowledge. The fundamentals of HTTP have barely changed, while the recommended way to authenticate with a particular SDK might have changed several times in the last year. An agent relying on old knowledge of HTTP is probably fine. An agent relying on old knowledge of that SDK might not be. I’ll call that difference volatility: how frequently the current way of using a technology changes.
Volatility isn’t limited to breaking changes. Suppose an SDK adds a method that replaces 100 lines of custom code. The old implementation might still work and remain supported for years. But if an agent doesn’t know about the new capability, it could generate substantially more code or recreate functionality the SDK now provides.
Backward compatibility leaves this problem intact. That’s particularly visible in enterprise software, where maintaining compatibility is often essential for adoption. Yesterday’s pattern might continue working indefinitely, while new applications should use a newer approach. Support and recommendation answer different questions, and the model might know the answer to only one of them.
Model knowledge doesn’t become stale all at once
It’s tempting to think about model knowledge as a snapshot. The model was trained at time X, the technology changed at time Y, so everything before Y is known and everything after Y isn’t. Not quite.
We’ve seen this firsthand in our Agent Experience research. A newer model can perform worse than the model it replaced, and its knowledge of a particular technology might be older. A cutoff is an upper bound, not a snapshot of everything the model knows.
That makes reasoning about staleness from the model side difficult, but we can approach the problem from the other direction. If part of your technology hasn’t meaningfully changed in ten years, old model knowledge may remain useful. If it changed six times in the last twelve months, there’s much less reason to assume unspecified model knowledge reflects its current state. We don’t need to know exactly what the model knows to recognize where trusting it becomes increasingly risky.
High volatility isn’t bad
For years, developers have treated regular updates as a positive signal. A project releasing improvements every month looks active. A repository that hasn’t changed in three years might make you wonder whether anyone still maintains it. So are we now penalizing the technologies that innovate fastest? No. Volatility measures how frequently the current way of using a technology changes. It doesn’t judge whether those changes are valuable.
A rapidly evolving SDK might be exactly what you want because it gains new capabilities and responds quickly to feedback. The consequence is simply that agents using it have a higher current-information requirement. Frequent improvements increase the amount of current information an agent needs to use the SDK well.
They may need to consult authoritative documentation more frequently. That can mean more retrieval and inference, with more latency and context. Keeping agent instructions focused and current takes effort too. A technology that changes less frequently might allow an agent to rely more heavily on what the model already knows. Its knowledge is cheaper to maintain. Think of volatility as a price tag.
Stability has inference value
Historically, stability reduced maintenance costs for humans. If an SDK maintained its patterns for years, developers didn’t constantly need to relearn it or update their applications. Agents introduce another benefit: stable knowledge can remain useful across model generations.
If the recommended way to accomplish something barely changes, models can reuse what they’ve learned without repeatedly consulting external sources. As the rate of change increases, so does the need for current grounding. Every documentation lookup can add a tool call and another LLM roundtrip. At sufficient scale, those costs add up sufficiently to be meaningful.
Two technologies might offer comparable capabilities while imposing very different costs on agents trying to use them correctly. That gives technology providers another reason to think carefully about unnecessary churn. Stability has inference value.
Don’t call yourself high volatility
How should technology providers communicate volatility? My first instinct was to label different areas. A short rating looks easy to publish and easy for an agent to understand:
Authentication: high volatility
API surface: medium volatility
Error handling: low volatility
I don’t think that’s particularly useful. What’s high? Six changes per year? Twelve? Does changing once every six months make something medium? Any threshold immediately introduces judgment, while different consumers have different tolerances. An enterprise building systems expected to run untouched for years might interpret the same change rate differently from a startup trying to use the newest capabilities.
Technology providers can leave that judgment to consumers and expose the underlying facts. A consumer can then interpret the same history according to its own needs. For example, a provider could say:
Authentication guidance changed four times in the last twelve months.
API usage guidance last changed three weeks ago.
This area received roughly monthly updates over the last year.
I’m deliberately not proposing a schema. Whether this belongs in YAML, a README, a skill, or some future machine-readable manifest doesn’t really matter. What matters is separating observable change from someone’s opinion about whether that amount of change is good or bad. Consumers can decide what those facts mean for them.
Volatility exists above individual technologies
Imagine you’re building a React application connected to some platform and need API access. Suppose two roughly equivalent SDKs are available. Each SDK team can tell you how quickly its own technology changes, but which SDK should you use? Answering that question requires a broader view. Every product team has an obvious interest in adoption of what it builds, so its guidance alone can’t arbitrate between competing technologies.
Humans have dealt with this problem forever. They ask colleagues and compare projects. They look at community discussions and talk to maintainers. Their experience from previous work adds context. Eventually, they make a judgment.
Agents don’t necessarily do any of that. Without explicit guidance, they make the decision from whatever context is available. Often, that means model knowledge, which might disproportionately represent the technology with the longest history or the largest documentation footprint rather than the approach we’d recommend today. Where organizations don’t provide arbitration, agents will arbitrate for them. That’s an Agent Experience problem.
Who describes your journey
An SDK team can authoritatively describe changes to its SDK. An API team can do the same for its API. But a developer building an application starts with a goal that crosses those product-team boundaries. Their journey connects technologies owned by several teams.
For an application connected to a platform, that goal might involve authentication and API access alongside UI and deployment choices. Someone concerned with the overall developer experience needs to connect those outcomes to the available technologies. That might be a platform team or a Developer Relations organization. It could also be an architecture group or the community. The important distinction is: technology providers describe change. Integrators arbitrate relevance and choice.
The latter shouldn’t flatten everything into a label such as “Platform X React development: medium volatility.” That would throw away exactly the information agents need. The agent should be able to discover that API access guidance changed recently while another part of the stack has remained stable for years. Then it can spend its retrieval and inference budget where it matters.
A volatility map
Technologies might eventually publish something resembling a volatility map: a factual description of which areas change and how frequently. Those maps could then be composed at higher levels. A technology provider describes the surface it controls, while a team responsible for an end-to-end developer journey maps functional areas onto current recommendations. A user’s environment adds its constraints. The agent uses that information to decide which parts of its internal knowledge deserve verification before it commits to a plan.
Conceptually, the flow could look like this. Each layer adds context that the layer below it can’t provide on its own. Together, they narrow the knowledge an agent needs to verify:
Whether this should become a manifest is an open question. The format matters less than making the information available where agents can use it. As agents make more technology choices, the cost of leaving that context implicit increases.
More grounding might require more restraint
There’s another consequence of volatility that I haven’t tested yet. Imagine an agent working on an existing application. The task is simple: add another endpoint. The application uses version 4 of an SDK, while the current documentation describes version 6 and recommends patterns that didn’t exist when the application was built.
We’ve taught the agent to consult current guidance. Great. It might correctly conclude that the application uses an older approach, then incorrectly conclude that it should modernize it. Suddenly, adding an endpoint turns into upgrading the SDK and refactoring initialization. The agent touches code unrelated to the user’s request.
The more frequently a technology changes, the more often agents encounter a gap between an existing codebase and current guidance. That suggests that higher volatility might require not only more grounding, but stronger guardrails. Current guidance should inform new decisions while the conventions of the existing application constrain the work at hand. In existing applications, agents may need explicit instructions to stay within the task and reserve upgrades or migrations for dedicated work.
I don’t yet know whether agents become more prone to this kind of scope expansion as technology volatility increases, but it’s testable. Give agents the same task while progressively increasing the distance between the conventions in the codebase and current guidance. Then measure how often grounded agents make unrequested changes. That’s an Agent Experience experiment I’d like to run.
What’s volatile about your technology?
When we build skills and agent instructions today, we often start by identifying gaps in model knowledge. That’s useful, but model knowledge is a moving and largely opaque target. A more durable question might be: what’s volatile about our technology?
Which recommendations change frequently? Which choices shifted recently? Which parts of the developer experience are stable enough that model knowledge is likely to remain useful? Where should an agent verify authoritative guidance before trusting what it thinks it knows?
In my previous article, I argued that agents should start with a hypothesis rather than a plan. Volatility helps us decide which parts of that hypothesis deserve verification. Agents can trust stable knowledge and verify knowledge that ages quickly. Technology providers are in the best position to show them which is which.