Accuracy, cost, security: what should you prioritize in your agent stack?

The relative prioritization of accuracy, cost and security undoubtedly depends on who you’re talking to … the CTO, CFO or CISO. But the truth is you cannot set a universal ordering of these agent properties; you have to make the decision for each specific agent. An agent that drafts internal summaries and a deployed agent that files insurance claims share a technology and almost nothing else.

And in that case, you should be considering: how far the agent is from production, what it can reach once it’s there, and the cost of a wrong answer. The rest of this post dives deeper into these criteria.

Accuracy leads until the agent works

Accuracy should be the top concern for any agent that doesn’t yet do its job reliably, which is most agents most of the time. An agent that is cheap and locked down but wrong 30% of the time is a demo. Nothing else you optimize matters until the thing produces output somebody would act on.

This is why developers rank accuracy first and why they’re right to. Agents are hard to build. The model is a black box that takes any input and gives a slightly different answer each time, and an agent chains several of those calls together, so small errors compound. Most of the engineering effort in the field goes into making the loop more reliable, and that effort is still the biggest lever.

Accuracy stays on top for longer in domains where a wrong answer is expensive. A coding agent that writes a bad function costs a review cycle. A research agent that misreads a paper costs an afternoon. Those are real costs, but a human catches them before anything irreversible happens, so the fix is a better eval and a better loop, and that’s accuracy work.

The sign that accuracy has done its job is when your evals stop moving. When a new model or a prompt change no longer shifts the numbers much, the agent is as good as the current generation gets, and the next bottleneck is somewhere else.

Cost leads when volume arrives

Cost moves to the top the moment an agent that works gets used a lot. Per-token prices have been falling, but agents burn far more tokens than chat does, and agents that call other agents burn more still. The net effect for most teams is that spend goes up as usage goes up, not down.

Coding agents are where this has shown up first, because that’s where adoption is furthest along. Teams report spending a meaningful fraction of engineering payroll on coding tools, and the spikes are rarely from heavy legitimate use. They come from a misconfigured plugin, an agent stuck in a loop, or a tool that sends a screenshot back on every turn. One of those left running for a week can cost more than a month of normal use.

The fix follows a pattern. First visibility, so you can see who is spending what and on which tasks. Then budgets, so a runaway agent hits a ceiling before it hits the finance team. Then engineering the loop itself, with prompt caching, cheaper models for simple subtasks, and tool sets that don’t bloat the context on every call. The order matters. Teams that start with loop engineering usually discover they were optimizing the wrong thing.

Cost stays the lead concern for as long as volume keeps growing and the agent’s blast radius stays contained. An agent that only produces text for a human to read can run up a bill, but a bill is the worst it can do.

Security leads when the agent can act, and when the domain is vertical

Security moves to the top on the day an agent can do something a human can’t easily undo. That line gets crossed when the agent stops producing text for review and starts calling tools that write to production systems: filing a ticket, moving money, changing a record, sending an email, merging code, provisioning infrastructure. From that point on, a wrong action costs more than a wrong answer.

The same shift happens when agents move out of coding and into vertical domains. Coding is forgiving in a specific way: the agent’s output goes through a pull request, a test suite and a reviewer before it touches anything real, so most of the safety is built into the surrounding process. Finance, legal, healthcare, sales and operations don’t have that scaffolding. A legal agent reads privileged documents. A finance agent touches ledgers. A sales agent has write access to the CRM and the customer’s inbox. In those domains the tools the agent calls are the sensitive part, and the agent is usually one prompt injection away from calling them with the wrong arguments.

Three questions tell you whether you’re there yet. Can the agent call a tool that changes state in a system of record? Does the agent handle data that would be a breach if it left the building? Could an attacker influence the agent’s inputs, through a document, a web page, a ticket or an email it reads? If the answer to any of them is yes, security is the lead concern regardless of how the evals look, because an accurate agent with the wrong permissions is a more effective attacker than an inaccurate one.

Where each concern leads

The pattern is that accuracy is a question about the model and the loop, cost is a question about volume, and security is a question about what the agent can reach. Each one takes the lead as the agent gains the corresponding property.

Build so the order can change

The practical implication is that an agent’s lead concern will change two or three times over its life, and the architecture should let it change without a rebuild. Most teams get this wrong in one of two ways. They bolt security on at the end, after the agent has write access and a dozen integrations with keys in config files, and then discover that retrofitting policy means touching every one of them. Or they front-load security on a prototype that doesn’t work yet, and the project dies in review before anyone finds out whether it was worth securing.

The way out is to put the controls that will matter later in a layer that doesn’t get in the way now. If every tool an agent calls goes through one shared runtime from the start, then adding a budget, a permission rule or an audit log later is a configuration change rather than a refactor. The agent team keeps optimizing for accuracy; the platform team turns the other dials when volume and exposure arrive.

That’s the layer Stacklok builds. For example, our platform runs MCP servers in a managed runtime with credentials injected at launch, keeps a registry of servers that have been vetted, enforces which agents can reach which tools, and logs every call in one place. None of it slows a prototype down, and all of it is already there when the agent gets write access to something that matters.

If you’re not sure which concern leads for an agent you’re running, then reach out for a chat and let’s talk through it together.