Key Takeaways
- An agent's behavior can change without any change on your end, because it inherits its underlying model's update cycle — vendors rarely warn you before a swap changes how edge cases get handled.
- Per-action pricing that looks trivial in a demo scales into real cost at production volume — get the vendor to model cost against your actual monthly transaction count before committing.
- Most agents request far broader access than the task requires by default, which is what stalls a security review — ask what the agent can access versus what it actually needs; they're rarely the same list.
- Context and configuration built up over months of use typically doesn't transfer if you switch vendors — pricing that switching cost in before committing deeply is worth doing upfront.
- None of these limitations are a reason to avoid the category — they're a reason to ask sharper questions before signing, since every vendor operates under some version of these constraints.
An agent that closed tickets correctly on Tuesday can close them wrong on Wednesday, and nothing in your setup will have changed. That's not a bug report — it's a property of how these systems are built, and it's the first thing vendor demos never mention.
None of what follows is a story about an agent "failing." These are properties baked into how the category works — costs, dependencies, and access patterns that don't show up in a pilot but show up the moment you're running one at real volume, for real money, against your real systems.
If you want the deeper failure-mode analysis instead of the constraint list, that's covered in 5 Ways AI Agents Fail Without Anyone Noticing. This is the actual list of AI agent limitations that don't make it into a vendor's demo — not because they're secret, but because nobody selling the thing is incentivized to bring them up first.
Why doesn't an AI agent's approved behavior stay the same over time?
Every agent built on a foundation model inherits that model's release cycle. Model providers retire specific model snapshots on their own schedule — often with six to twelve months' notice, sometimes less — and whatever sits on top of that model inherits the change whether or not the vendor tells you it happened.
You approved a workflow because the agent handled a specific edge case correctly during testing. Six months later, the underlying model gets swapped to a newer version, and the same edge case gets handled differently. Not worse, necessarily. Different. Different is enough to break a process you built assumptions around.
A 30-person logistics brokerage running an agent to draft carrier rate confirmations found this out when a model update changed how the agent formatted a specific accessorial-charge line — the output was still grammatically correct, just structured differently than the accounting system's import script expected. Nobody touched the integration. The agent's underlying model updated on the vendor's timeline, not the brokerage's.
This isn't a defect you can inspect your way out of before signing a contract. Ask the vendor directly: what happens when the underlying model changes, and do you get notice before it does. The demo won't raise it, and the sales call usually won't either.
Why Demo Pricing Doesn't Survive Real Production Volume
Per-seat pricing was built for software people log into. Per-run or per-task pricing was built for something people don't log into — they let it run, which means the meter doesn't stop when nobody's watching. An agent priced at a few cents per action looks trivial until it's processing a real company's actual volume: a 40-person insurance agency running claims-intake triage generates thousands of discrete actions a month, not the dozen a sales demo walked through. The unit economics that looked negligible at proof-of-concept scale stop looking negligible once the agent is doing the job it was bought to do.
The upfront quote almost never includes a projection past pilot volume. Get the vendor to model cost at your actual monthly transaction count, not the pilot's, before you commit — and get the number in writing.
Why does an AI agent's access request stall a security review?
Agents need permissions to do useful work, and the industry default is to ask for more than the task requires, upfront, once, so the vendor doesn't have to come back and ask again later. That's convenient for the vendor's onboarding funnel and expensive for you. A department head who wants an agent to draft calendar invites gets an OAuth consent screen requesting read/write access to the entire mailbox, contacts, and calendar — not because the task requires it, but because scoping permissions narrowly is engineering work most vendors haven't done.
If your company runs any kind of security review — even an informal one, handled by whoever owns compliance at a 25-person company — that mismatch between requested scope and actual task is exactly what gets flagged, and exactly what stalls a rollout for weeks while legal and IT argue about it. Ask what the agent can access, separate from what it needs, before you request access. Those are two different lists, and vendors will hand you the first one and call it the second.
Why doesn't an AI agent configured for another company transfer to yours?
An agent's judgment comes from patterns it was configured or trained against. Configured on one company's ticket-routing conventions, its default calls reflect that company's categories, escalation thresholds, and tone — not yours. Vendors sell this as "pre-trained" or "industry-tuned," which sounds like a head start. In practice it means the agent arrives with somebody else's assumptions built in, and getting it to reflect your business takes real reconfiguration: rewriting categories, correcting escalation logic, adjusting tone by hand.
A 15-person property management company piloting a tenant-request routing agent built on multifamily-industry patterns spent three weeks correcting its default assumption that maintenance requests under a set dollar threshold should auto-approve — a rule that made sense for the vendor's largest reference customer and made no sense for a company self-managing a smaller portfolio with tighter cash flow. The agent wasn't wrong on its own terms. It was configured for somebody else's business, and the company paid in setup time to make it theirs.
What happens when a connected tool's API changes underneath an AI agent?
An agent that reads from your CRM and writes to your invoicing tool is only as stable as both of those tools' APIs, and you control neither one. A field gets renamed, a rate limit gets tightened, an authentication method gets deprecated — any of it can silently break a connection the agent depends on, and the failure mode is rarely a clean error message. More often it's a task that runs, completes, and writes bad data, because the agent doesn't reliably know the handoff failed.
A 20-person accounts-receivable team running an agent that pulled from NetSuite and sent follow-up emails through Outlook learned this when NetSuite renamed a custom field during a routine update. The agent kept running. Every follow-up email cited the wrong invoice balance for eleven days before someone in AR happened to notice a customer's confused reply.
That's worse than ordinary software brittleness, because the agent is making a judgment call about what to send when something's already gone wrong, not failing loudly and stopping. Ask what happens when a connected tool's API changes underneath the agent: does it stop, does it alert someone, or does it keep going on degraded information.
The Actual Cost of Switching AI Agent Vendors
The configuration, the context, and the workflow-specific tuning an agent accumulates over months of use doesn't travel with you if you switch vendors. That's not a hidden clause — it's just how the economics of the category work right now. Nobody exports "everything this agent has absorbed about how your business handles returns" into a portable file you hand to the next vendor. You rebuild it, from a different starting point, at whatever onboarding process the new vendor runs.
A 10-person marketing agency that spent four months feeding client history and campaign conventions into an agent's context, then switched vendors over a pricing dispute, rebuilt that same context from zero at the new vendor — the identical task, done twice, six months apart. That's a real cost, and it's worth pricing in before you commit to a level of dependency you didn't intend to reach. It doesn't mean don't commit. It means know what an exit actually costs in your specific case, not the general case a sales deck describes.
What should you ask before buying an AI agent?
None of this is a reason to avoid AI agents. It's a reason to ask sharper questions before you sign, because the limitations above are structural — they show up with different severity depending on how a given product is built, not because a vendor is careless.
This is also, plainly, where Kuvai's approach differs on the specifics above. Kuvai's teammates are grounded in your company's own Company Context rather than generic training data pulled from other companies' workflows, which is why the reconfiguration problem described above is smaller when the starting point is your business, not a reference customer's.
Access is scoped at hire rather than granted broadly upfront, and every teammate defaults to conservative autonomy with approval required before it acts on anything consequential — which doesn't make the security-review question disappear, but it changes what you're reviewing. And Kuvai is upfront about what's built today versus what's on the roadmap, rather than letting a future feature read as a shipped one.
That's not a claim that switching costs disappear, that a future model update can't change behavior, or that cost stops scaling with usage. Those are category-level constraints, and no vendor opts out of all of them through marketing copy. It's a claim about which of them Kuvai has actually built around, and which it hasn't — the same standard this article just asked you to hold every other vendor to.
For the broader question of whether the category is worth the cost and risk described here, see Are AI Agents Worth It in 2026. For the difference between the general category and the term "agentic AI," see Agentic AI vs AI Agents. And for the deeper mechanics of deployments that fail outright rather than just run into these constraints, see the pillar piece Why AI Agents Fail to Deliver.
Want a teammate that's honest about its own limitations before you connect it to a tool? Sign Up for Free — no credit card required, free to start, cancel anytime.