Your app is losing its grip on your customers. Nothing about it needs to have become worse. Its UI might be thoughtfully designed and its workflows refined over years of research. The standard around it has simply changed.
Imagine that you use five apps to do your work. Three work well with your AI agent: you tell the agent what you need, it does the work and you move on. Then you reach the fourth app and need to open a browser, sign in, find the right record, fill in a form and submit it. A workflow that takes only a couple of minutes suddenly feels painful because your app is now competing with not needing an app at all.
People want the outcome
People use an expense app because they want to get reimbursed. They use an issue tracker to keep track of work. They use a newsletter app to communicate with their audience. The app has always been a means to an end.
APIs and automation have supported that distinction for decades. If you cared enough, you could automate many workflows long before language models arrived. Someone still had to understand the API, build and host the integration, then maintain it when something changed. For many workflows, opening the app was simply cheaper.
Agents change that equation by taking on much of the burden of understanding and operating software. The path from I want this done to automation is becoming much shorter. UIs will remain valuable, but they will no longer be the obvious interface for every job.
The job chooses the interface
Imagine you’re a sales rep reviewing your accounts. You have the same pipeline view you’ve used hundreds of times. Accounts are where you expect them to be, opportunities have a familiar layout, and you can scan the screen to spot what changed. Asking an agent to generate that view every morning could make the job harder because the layout might change and force you to interpret a new report each day.
A deterministic, purpose-built UI can be dramatically more efficient for that kind of job. Now imagine that you need to move twelve opportunities to the next stage, update their expected close dates and schedule follow-ups with their owners. Opening twelve records and repeating the same sequence of actions no longer looks efficient.
A single product can therefore contain jobs that people perform best directly and jobs they should delegate to an agent. The job chooses the interface. Your customers don’t owe your UI their attention.
Familiarity is losing its grip
For years, bringing people into your app had benefits beyond completing the immediate task. People learned where things were and became familiar with your terminology. Repetition turned workflows into habits until they could use the product almost without thinking. That familiarity created friction when they considered leaving because another product meant learning a different structure and way of working.
Agents absorb that cost. When you tell an agent to send a newsletter, you don’t need to know where the campaign editor lives or which screen contains the scheduling options. More importantly, switching newsletter providers doesn’t necessarily require you to learn where those things live in the new product. Your workflow might remain: Send the newsletter. The complexity underneath changed while your interaction stayed the same.
The more of your workflow the agent absorbs, the less attached you need to be to the mechanics of the application underneath it. Enterprise software still comes with procurement constraints, compliance requirements and contracts. Some data is genuinely difficult to migrate, and some systems are deeply embedded in organizational processes. Those dependencies remain, but accumulation alone doesn’t create dependency.
Suppose you’ve used a newsletter service for three years. It contains years of campaigns, analytics and configuration, which sounds like substantial lock-in. What do you actually need to leave? You might need your mailing list with its consent and unsubscribe state, a few templates, plus an archive of old campaigns. If you can extract those, you could be ready to use another product tomorrow.
Three years of data doesn’t necessarily create three years of dependency. When an agent can help extract and transform what matters, another piece of switching friction becomes smaller. Your product increasingly has to win because people choose to keep using it, rather than because leaving is exhausting.
Jobs can churn before customers do
Contracts can give SaaS companies a false sense of security. Imagine that your organization has a bespoke application for tracking issues. It works, everyone is allowed to use it and the organization has another two years on the agreement. The problem is that using it with an agent is painful.
Meanwhile, an ordinary spreadsheet is approved and your agent can work with it effortlessly. You start tracking a few things there. There is no procurement event, no formal decision to replace the issue tracker and no shadow IT. You simply moved a job.
Then another job moves and new data starts accumulating elsewhere. Your current workflow begins forming around the alternative, and other people discover that it’s easier too. The organization still pays for the original product, so on paper you’re still a customer. In practice, the product is already losing you because jobs churn before customers do.
Customers also run on different clocks. One contract renews next month, another in six months. Teams with more autonomy might not need to wait for a renewal at all. Customers can leave slowly, one workflow at a time, until procurement formalizes a decision their users effectively made months earlier.
Your engagement dashboard might lie
Agent use makes familiar product metrics harder to interpret. Suppose direct interaction with your web app drops sharply. That could mean customers are leaving, or it could mean your product works brilliantly with agents and customers complete the same amount of work without visiting the UI. Pulling them back into the app to restore engagement would solve the wrong problem.
Now suppose direct interaction falls and the number of workflows completed through your product falls with it. That is a different signal because the jobs might be leaving. Even stable engagement deserves scrutiny when agent adoption is changing how people work everywhere around your product. Your workflows might genuinely be better performed in the UI, or customers might be unable to make the transition.
Monthly active users won’t necessarily clarify the picture. Depending on your definition of active, an authenticated API request from an agent might still count the person it represents. The useful question is how customers get their jobs done and whether those jobs still flow through your product.
Try your product with an agent
You don’t need a strategy deck to start figuring this out. Pick a few real jobs your customers perform and use your product with an agent. Choose actual work rather than a demo designed to make the agent look good, then observe where it gets stuck.
Can the agent authenticate and discover the capabilities it needs? Are important operations available programmatically, or are they trapped behind the UI? Does the agent need to fall back to browser or computer use to click through a workflow designed for a person? Computer use is a useful fallback, but it doesn’t replace designing a product for agentic workflows.
Exposing an API is increasingly table stakes. Once the API exists, you still need to consider whether an agent can understand your product’s capabilities, use them reliably and recover when something goes wrong. Trying real customer jobs will show you where that work needs to begin.
You will have to win on merit
For a long time, product merit was closely tied to human usability. We made interfaces attractive and workflows intuitive. We improved onboarding, helped people discover features and reduced the time required to become proficient. All of that still matters for jobs where people operate the product directly.
Increasingly, people won’t operate every part of your product. Their agents will. At the same time, familiarity and learned workflows will exert less influence over whether customers stay. Fighting that change won’t restore the old switching costs.
Your product will have to earn its place in a customer’s workflow even when the customer no longer sees its interface. That changes what usability, differentiation and loyalty mean. It leaves every product team with a more interesting question: what does merit mean when your user isn’t the one using your product?