What If Your Internal Tools Had to Compete for Your Business?

Anyone who has struggled with a mandatory company tool knows the problem with being described as an internal customer.

Customers can usually leave.

You submit a ticket.

Coinbase CEO Brian Armstrong thinks AI agents could change that relationship. In a September 27, 2026 post on X, he argued that internal platforms should have to compete for users inside their own companies.

His proposal: publish uptime, latency and cost, collect feature requests openly, and allow teams running real products to charge other departments for using them. Agents would discover the available services, compare them and choose alternatives to weaker offerings.

In a separate post that day, Armstrong proposed a /feedback endpoint: a way for an agent to report a bug or missing feature directly to a service in a structured format. Another agent could draft a code change when the request made sense, with a human approving it.

These posts describe how Armstrong thinks internal software should work. They do not establish that Coinbase has implemented this system or demonstrated that it makes companies faster.

Still, the management idea is worth taking seriously.

Consider an internal service that is slow, confusing and difficult to improve. If every team has to use it, its owners can receive plenty of complaints without losing any business. The negotiation happens through tickets, roadmaps and meetings between managers.

Now imagine that the company approves two services that can perform the same task. An agent can compare their advertised performance and cost before choosing one. Suddenly, a dissatisfied user has something more useful than an escalation path.

An alternative.

That is the incentive change underneath Armstrong’s proposal. A team running an internal service would have to think about whether people actually wanted to use it, alongside whether leadership had designated it the standard.

There is, of course, a very corporate complication.

The alternative still has to exist. Someone has to build it, secure it, support it and pay for it. Two competing services can create choice while also creating two sets of maintenance bills.

And comparing services is easier than switching between them. A faster response time does not tell an agent whether the replacement handles the same permissions, preserves the same records or produces an answer the next system can use.

Those are implementation questions the posts do not resolve. The scenario depends on compatible services, reliable measurements and permission to choose. An agent cannot create an approved alternative simply by being disappointed with the current one.

Payroll makes the limitation easy to see. A company cannot sensibly treat the system that pays employees as something to swap casually because another service looked cheaper on Tuesday.

But for tasks where alternatives really are interchangeable, the proposal points to a useful management question: is the internal platform winning its users, or merely inheriting them?

Publishing the numbers could help even before an agent makes a single choice. A visible cost or reliability problem gives the next roadmap meeting something more concrete to discuss than which manager complained most recently.

For years, companies have talked about treating internal teams like customers. Armstrong is proposing a version in which the customer might actually get a choice.

Which means the team running a mandatory company tool could eventually receive a message it has rarely had to consider:

Your customer has selected another provider.