Agent capability compounds in a few narrow places and stalls everywhere else. It is worth being precise about which is which, because the two categories look identical on a demo and behave nothing alike over a year.

This is not an argument about whether general intelligence arrives or when. It is a narrower and more useful question: of the work a team does this quarter, which parts will still be paying off after the next model release, and which parts will have to be redone from scratch. That question has a defensible answer, and most roadmaps get it wrong in the same direction.

What actually compounds

Three things improve in a way that persists. Each makes the next task easier rather than merely making this task succeed.

Tool reliability compounds because a tool is a contract. A well named action that returns typed, unambiguous data will still be a good action a year from now, against a model that has not been trained yet. Nothing about it is coupled to the current generation. Every hour spent making a tool return a clean status instead of a blob is an hour that keeps paying.

The quality of the environment compounds for the same reason. Clean picklists, populated fields, sensible object relationships, and permissions that reflect how people actually work: none of these are AI investments in any obvious sense, and all of them raise the ceiling on what any agent can do in that org.

The feedback loop between an action and its recorded outcome compounds hardest of all. If every write is logged with what was proposed, what was applied, and whether a human corrected it afterwards, you accumulate an asset that no vendor can sell you and no model release invalidates.

• Typed, narrowly scoped tools that a future model can use without rewriting.

• Data that means what its labels claim it means.

• Outcome logs that record correction, not just completion.

• Evaluation sets built from real cases with known correct answers.

What does not compound

Prompt length is the clearest example. A long prompt tuned against one model is a liability against the next one. It encodes workarounds for a specific set of failure modes, and when those failure modes change, the workarounds become noise that actively degrades performance. Teams discover this the week after an upgrade, when a system that worked for months starts behaving oddly and nobody can say which of nine hundred words is responsible.

Model swaps do not compound either, though they feel like progress. A newer model raises the floor across the board, which is genuinely useful and completely undifferentiated. Your competitor gets the same lift on the same day. Nothing about your system is better than it was relative to anyone else.

Demo breadth is the most expensive non-compounding investment, because it looks like coverage. Twenty scenarios handled shallowly is harder to maintain than three handled properly, and it produces a system that impresses in a meeting and disappoints in week two.

Why the distinction is expensive to ignore

Consider two teams with identical budgets over six months.

The first spends it on tool reliability, data cleanup, and outcome logging. At the end they have a system that is measurably better than it was, and they can prove it, because they have the frozen evaluation set and the correction logs to show the trend. When the next model ships, they swap it in and everything gets better at once, because nothing was coupled to the old one.

The second spends it on prompt tuning and chasing model releases. At the end they have a system that is different. Whether it is better is genuinely unclear, because there was never a stable measurement to compare against. When the next model ships, a portion of their work has to be redone, and nobody is sure which portion.

The uncomfortable part is that both teams looked equally busy throughout, and in the first eight weeks the second team looked further ahead.

The environment is the real substrate

The most reliable predictor of how well an agent performs in a given org is not the model and not the prompt. It is the state of the org.

An agent operating on clean, well described data with narrow tools and clear permissions performs well with a modest model and a short prompt. The same agent in an org with three spellings of every status, blank required fields, and a permission model nobody has reviewed since 2019 will underperform regardless of what is behind it. This is why two deployments of the same product produce opposite verdicts.

• Fix the data before tuning the prompt. The prompt is compensating for the data.

• Narrow the scope before broadening the capability.

• Log corrections from day one, even when nothing consumes them yet.

• Treat permission fidelity as a correctness requirement, not a security afterthought.

How to tell which kind of work you are doing

There is a simple test. Ask whether this work would still be valuable if the underlying model were replaced tomorrow with something twice as capable.

Cleaning up picklist values passes. Writing a typed action that returns a status and a reason passes. Building a frozen evaluation set from real cases passes. Adding four hundred words of instruction to steer around a specific hallucination fails, because a better model does not need the steering and may be actively confused by it.

The test is not perfect and some work sits in between, but it separates the two categories quickly enough to be useful in a planning meeting, which is where the decision actually gets made.

The short version

None of this requires a position on whether general intelligence arrives. It only requires being honest about which improvements survive contact with the next release.

Tools, data, and feedback loops survive. Prompts, model choices, and demo surface area do not. A team that understands the difference ships something that is genuinely better every quarter. A team that does not ships something that is merely current, and has to keep paying to stay that way.