Since SaaS¹ became a business model in the [mid 2000’s], the primary way by which companies integrate third party tools into their software has been via API. This is such a common and boring fact that most software people don’t give it much thought. Whether connecting a database, an analytics service, or sending notifications to a user’s phone, the languages is essentially the same: send an API request to a server somewhere, providing it whatever information it needs, and then process whatever you back in response.

The reason this is such an obvious and unavoidable interface is that databases, analytics services, and software to send notifications to a user’s phone are all tools. The buyer’s software chooses when to use them, and the software they bought patiently waits to be called. There is a second option, webhooks, used when you want your software to respond to external events. But despite the existence of a pattern for the software you buy to call your software via webhook, the use case is almost always NOT some tool messaging you and asking you to do something. As a rule, webhooks are used to inform your software that something has happened, and then it’s up to your software to decide what to do about it.

I write this in mid 2025, and we’re now beginning to see the emergence of a new class of software you can buy to integrate with your software, agents. Why does this matter? Because in order for an agent to be useful, it really helps if the agent can choose what it wants to do. What happens when an agent you pay for wants to check if a user received an email, or perhaps to send one from your service? What happens when a customer service agent you buy needs to exchange a user’s purchase for the next size up, or help them reset their password? When the agent wants to take an action that depends on your software, there are two ways of fulfilling its request:

• delegate access to the underlying resource (e.g. email sending as your company) to the agent, or
• create a way for the agent to ask your software to do something

In the former case, you might predict proxies to all the tools a company uses — or perhaps even the tools themselves — offering advanced authentication and authorization capabilities might become commonplace. This would necessitate the creation of software that doesn’t currently exist to enable this behavior.

In the latter case, this sounds a lot like a world where companies are going to be spending engineer hours building APIs into their software for the agents they buy to use, which sounds to me like it would scale terribly. One might imagine they’d address this by having coding agents write the endpoints instead of engineers, but that implies companies will need to tolerate dramatic increases in tech debt to support the needs of an ever increasing number of agents. I would predict there will need to be software to enable this too.

The implications of this are potentially the introduction of new channels for communication between buyers and sellers of SaaS. REST² APIs to tell your purchased software what to do, webhooks for your purchased software to tell you about things that happen in the world so you can react to them, and something new for agents to instruct your software to take action on their behalf.

I’m excited to learn what that thing will be.