Feature 100 < feature 1: the economics of a growing agent shelf

Ask a team that has just pushed their first agent in production what the second one will cost, and the answer is usually along the lines of "about the same". The rationale put forth is about following similar discovery, similar integration work, similar trust validation and similar security review => same number of months. Sometimes the estimate could be higher because the team now understands what the first one actually took. If it is right, then an Agentic AI program within a company costs the same per feature as you add more features, and its budget grows in a straight line with its ambitions. In my experience, a lot of programs that get cut are cut somewhere along that line.

At O3 Technologies, we make the opposite claim: feature ten should cost less than feature one. A claim like that looks good on a chart. But in this article I want to set out why I think it holds, with the evidence that supports it and where it doesn't, because the ground conditions matter more than the chart or the slogan.

The part of an agent that gets cheaper by itself

Let's start with the part that everyone watches - the model. The price of a given level of capability has been falling faster than almost anything else in technology. Epoch AI tracked inference prices against benchmark scores and found that the price of reaching GPT-4's level on a set of PhD-level science questions fell by about 40 times a year. Across the benchmarks and thresholds they examined, the decline ranged from 9 to 900 times a year.

That is good news, but it tells you very little about your own cost curve. It is market at work, and the price drop is available to all buyers in the market, so you would have received it however you built your agents. If someone tells you the second agent is cheaper because tokens got cheaper, they are describing something that happened to everyone.

The more interesting question is what the rest of an agent costs, and the answer to that has been known, in a slightly different form, for about a decade. In 2015 a group of Google engineers published a paper on the hidden technical debt in machine-learning systems. Their observation was that in a mature system, the code that does the learning is a small fraction of the whole. Most of the effort and most of the maintenance sit in what surrounds it: glue code, configuration, data dependencies, moving and cleaning data, monitoring.

Agents have the same shape, with more integration and more trust & governance on top. When I look at where the time goes on a first production agent in regulated work, model choice and prompting are real work but a modest share. Most of it goes into getting the agent access to a claims platform or a policy-admin system with permission model that security will sign off; sitting with adjusters or pharmacists until the rules they apply from experience are written down precisely enough for an agent to follow and a reviewer to check; building a labelled set of real cases and agreeing what "correct" means for each; building the decision trace, the approval gates and the screens people review in; and taking all of it through security, privacy and compliance review.

That last item tends to be larger than plans assume. McKinsey, drawing on gen-AI programs at more than 150 companies, reported that roughly 30 to 50 percent of a team's development time went into making a solution compliant or waiting for compliance requirements to settle. The same report describes teams repeatedly building one-off solutions that the next team could not use.

Every item mentioned above is where engineers, reviewers, and experts spend their time. And people's time does not follow a price curve. The cost of feature one hundred falls only if the work done for feature one is still usable when feature one hundred is built. Nothing makes that happen by default.

What carries forward

So which of that work carries forward? Less than the simple version of our claim suggests, but more than the flat estimate assumes. In our delivery work, we have seen different kinds of asset behave very differently.

1. The trust scaffolding carries furthest. A decision trace that records what the agent read, which rule it applied, why it acted and where a person signed off has the same structure whether the decision is about a claim, a prior authorization or a KYC escalation. So do the override control, the redaction layer and the approval gate. Interestingly, much of the saving shows up in review time rather than engineering time. Reviewers spend their attention on what is new, and a feature assembled mostly from components that have already passed review presents a much smaller new surface. In the same report, McKinsey describes approval processes speeding up by as much as 90 percent once reviewers can confirm that an application uses approved, shared services.
2. Connectors carry forward for a related reason. The slow part of an integration is usually the approval around it: the service account, the scoped permissions, the data-classification decision. Once a connector to your policy-admin system exists, with permissions enforced below the AI layer, every later agent that needs that system can use it. You pay for the approval once per system.
3. Evaluation suites carry forward twice. A golden set of a few hundred real first-notice-of-loss submissions, labelled with your adjusters, serves the intake agent and then the triage agent that follows it. The second use is less obvious. Prompts are tuned to a model, and they don't transfer well. Researchers studying cross-model prompt transfer found that a prompt optimized for one model often performs substantially worse on another. With new model generations arriving within months of each other, without an eval suite, each model change is a re-validation project and a good reason to stay on an old model. But with a good eval suite, a model change is a test run. I'd go as far as saying the eval suite is what keeps "no lock-in" true after go-live, a critical factor to manage cost independence.
4. Skills carry forward within a domain and almost nowhere else. By skills I mean the rules, conventions and decision patterns written down for agents to follow. Your claims-triage rules are of no use to a procurement agent. The method for capturing and testing them cuts across the domains. Also, if designed well, the agent roles such as a triage agent or a retriever carry forward as scaffolding (the control loop, the tool-calling pattern, the trace hooks), with new specialization on top.
5. Prompts carry forward least. They are worth versioning, but the part that lasts is usually the pattern and the test that checks it, rarely the wording.

Now lay these out over a sequence of builds and the shape of the curve gets clearer. Suppose an insurer builds claims intake first. It needs connectors to the claims and policy-admin systems, a classifier for first notice of loss, intake rules written as skills, a labelled set of real submissions, and a full review. The second feature is underwriting submission triage. It reuses the policy-admin connector, the trace format, the eval harness and the review screens, but its appetite and referral rules are entirely new, so most of its saving comes from access and review. The third is fraud-signal review on claims. That one lands back in the first feature's domain and draws on its claims connector, its classifier and its labelled data, so it costs less again. Had the third feature been a procurement workflow, the saving would have shrunk to the trust scaffolding.

As you would have noticed from above para, the order of a roadmap is itself an economic decision, and most roadmaps make it by accident. Putting the next use case where the last one left the most behind bends the curve more than any single asset does.

The same logic works across clients, at the level of pattern rather than content. The guideline-extraction and rules-management approach built for a LegalTech firm is structurally similar to a contract review in procurement. So while none of specific client's rules and skill move, the structure, the eval design and the plan-confirm-execute control flow can transfer well. This is what our agent factory is for.

The layers that reuse most have the fewest standards

The next part of the argument is the one that gets the least attention but the one I find most interesting.

If you rank the layers of an agent by how far they carry forward in regulated work, the top of the list is trace structure, evaluation suites and approval evidence. If you rank the same layers by how mature their shared standards are, the order is close to reversed.

Tool connections have a real standard. The Model Context Protocol, which Anthropic donated to the Linux Foundation's Agentic AI Foundation in December 2025, defines how agents call tools and data sources. By the time the foundation launched, more than 10,000 MCP servers had been published. Skills got an open packaging format, Agent Skills, the same month.

Evaluation has nothing comparable. Every framework defines its own structure for tasks, datasets and scorers. The UK AI Security Institute, which maintains the open-source Inspect framework, has described the lack of shared measurement standards as a problem for the whole field. Approval and audit evidence has no standard either. ISO/IEC 42001 expects AI systems to keep event logs that tie an action to an actor, a resource and a time, and leaves the format to each organization. Trace conventions for agents are still forming; that is the subject of a separate piece on observability.

You could reasonably say this is temporary, and that standards for evals and audit evidence will arrive. I expect the same. But a program being built now has to decide where these assets live and what format they're in before that happens, and that decision determines where the value accumulates. An eval suite kept in a vendor's proprietary format is an asset you rent. The same cases kept as plain test files with written grading criteria, in your own repository, are an asset you own, whichever framework happens to run them this year. This is the practical reason behind our rule of zero proprietary runtimes. Where no standard exists, the format still has to be one you can read and run without us.

Why the first one costs more

There is a catch in all of this, and again it's something that we have encountered long before agents existed: building something to be reused costs more than building it once.

Jeffrey Poulin's reuse economics, developed out of IBM's reuse program in the 1990s (yes, I have been around few decades), put numbers on it. The commonly cited default values have reusing a component cost about a fifth of writing it new, and writing a component for reuse cost about one and a half times a single-use version. Robert Glass was more conservative, his rule of three holds that a reusable component is three times as hard to build as a single-use one, and should prove itself in three different applications before it earns a place in a library.

So on a agent shelf, feature one costs more than a standalone pilot would. The curve on our economics page, with feature one hundred at 27 percent of feature one, is labelled illustrative for a reason. Real curves start higher, dip only once reuse begins, and step back up whenever a program enters a new domain. The way to handle that is to pay the reuse premium selectively, on assets you expect to use at least three times, and to let genuinely one-off work stay one-off. McKinsey's platform finding points the same way: the investment often breaks even after a few solutions, rarely on the first.

Two more costs are missing from the optimistic version. First one is maintenance. The 2015 Google paper named a principle for machine-learning systems - changing anything changes everything - and agents follow it closely. A model upgrade changes the behavior of prompts nobody touched, a connector breaks when the source system ships an update, a skill goes stale when a regulation changes. Reuse spreads a defect as efficiently as it spreads value, so every shared asset needs an owner, a regression test, and managed lifecycle with some of them eventually retiring.

The other is discoverability. In the early history of software reuse, the main obstacle turned out to be the library itself: components existed, but the next team couldn't find them or didn't trust them, and rebuilt them anyway. An asset is reusable only when someone can find it, read what it does, see its current eval results and know who maintains it.

And some costs don't carry forward at all. Every new data source needs its own access approval, and every new user group its own change management. Every new workflow needs the business to decide what a good outcome looks like. An agent shelf removes repeated engineering and repeated review, but it can't make those decisions for you.

How to tell whether it's working

If the claim holds for your program, a few numbers should move. The share of each feature that is built new should fall as the program goes deeper into a domain. Time through security and compliance review should fall from one feature to the next; if it doesn't, your reviewers don't yet have enough evidence about the shared components, and that is worth finding out. Requalifying a production agent on a new model should take days, and should not turn into a project. And the fully loaded cost per feature, including your own people's time, should trend down, with visible steps up whenever you start somewhere new.

None of those numbers depend on the model getting cheaper, which is why they are worth tracking. The model will keep getting cheaper and better for everyone. What separates one program's cost curve from another's is whether the access, the judgment and the evidence paid for in the first build are still there, in a form you own, when the next build starts.

So the useful question about your second agent is what your first one left behind.

If your second use case has been estimated at the cost of your first, talk to us about what the first build can hand forward.