The first thing almost every team does, when they decide to give an agent the ability to take real actions, is teach it the API of the system it has to act in.
It is a perfectly reasonable instinct. The API is what's there. It has documentation. It has SDKs. It has a million examples on the open internet. Of course you would teach the agent how to call it.
So the team writes tool descriptions. Here is createIssue in Jira. Here are its required fields. Here is what the response looks like. Here is when to call it. The agent learns the tool. It calls the API. It works. The team ships.
Then the team has to support a second issue tracker for a customer who uses Linear. So they add another tool. Here is createIssue in Linear. The fields are subtly different. The response shape is subtly different. Call this one when the workspace is configured for Linear.
Then the customer wants to support a third tool. Then a fourth. Then someone asks if the agent can also create a ticket in Zendesk when the issue is from a customer, and a task in Asana when the issue is from internal stakeholders, and decide between them dynamically.
A few months in, the agent's tool list is a hundred entries long. The model spends an increasing fraction of its context window reading tool definitions instead of doing actual work. Adding a new system means writing a new tool description, testing it against the model, adjusting the prompt, and praying that the model doesn't start picking the wrong tool for the wrong situation. Switching providers - which the customer occasionally asks for - means a code change and a model retest.
The team built integrations. They thought they were building infrastructure.
The wrong place to put the abstraction
The mistake here is not technical. It is architectural, and it shows up in every era of software in roughly the same way: putting the abstraction at the wrong layer.
When you teach the agent the API directly, you have made the agent the integration layer. Every provider's quirks live in the agent's understanding. Every API change is an agent change. Every new tool is a prompt change. The agent's intelligence - the part that's supposed to be reasoning about goals - is being burned on the cognitive overhead of learning APIs, which is exactly the cognitive overhead that infrastructure is supposed to absorb so that the layer above it doesn't have to.
There is a precedent for this. Early web applications used to talk directly to specific database drivers. If you wanted to switch from MySQL to PostgreSQL, the application had to change. Then ORMs arrived, and the database became an implementation detail. The application stopped saying "run this MySQL query" and started saying "find me users where email matches this pattern." The query was a verb. The driver translated the verb into the dialect of the specific database. Switching databases became a configuration change, not a code change.
The same shift is overdue in the agent layer. The agent should not know that one customer's company tracks issues in Jira and another's tracks them in Linear. The agent should be able to say "create an issue, with this title, in this project, of this priority" - and the layer below should know which provider that resolves to, what fields that provider needs, what defaults to apply, and which credential to use to make the call.
The abstraction belongs underneath the agent, not inside it.
What "intent" looks like in practice
When you push the abstraction down, the shape of the agent's interface changes. Instead of a hundred tools, the agent has a small, stable vocabulary of capabilities: things it can ask to be done. Create an issue. Send a message. Assign a task. Schedule a meeting. Request an approval. The capability is a verb that describes a business intent, not an API.
Every capability has a stable shape. It has a small number of meaningful arguments. The arguments describe the intent in business terms - project, priority, assignee - not in the schema terms of any particular provider. The agent learns the verb once and uses it forever, regardless of which provider is on the other side.
When the capability fires, the layer below resolves it. It looks at the workspace's configuration. It picks the right provider. It maps the business arguments to the provider's specific fields. It applies the workspace's defaults. It pulls the correct credential. It makes the call. It handles the provider-specific retry semantics, the rate limits, the error codes, the eventual consistency. None of that is in the agent's prompt. None of it is in the agent's memory. The agent doesn't need to know any of it, and the moment any of it changes, the agent doesn't need to be retrained on it.
Adding a new provider becomes a configuration task. The capability already exists. The argument shape is already defined. You teach the layer how to translate that capability into this new provider's API, and every agent in the system can now use it without changing.
This is what makes the layer infrastructure rather than glue. Glue grows linearly with the number of providers and the number of agents. Infrastructure grows with the number of capabilities, which is bounded by the business, not by the catalog of SaaS tools.
A better abstraction is also a safer one
There is a second-order effect of this design that is worth naming explicitly, because it is the one most teams don't see coming.
When the agent expresses intent in business terms, the policy layer can also reason about that intent in business terms. Is this user allowed to create issues in this project? Is this assignee external? Is this priority above the threshold that needs human approval? Those are questions about the intent itself, and they are answerable without knowing or caring which provider is on the other end.
If the agent expresses intent in API terms, the policy layer has to reverse-engineer the business meaning out of provider-specific fields. Is assignee_email = "external-domain.com" an external assignee? Maybe - depends on the provider. Is priority_id = 4 a high priority? Depends on the provider's internal mapping. Now the policy is provider-aware, which means it has to be rewritten every time you add a provider, and it can be silently bypassed if the agent decides to call a slightly different endpoint with the same effect.
A capability-shaped abstraction collapses these problems. Policy lives at the level of the business intent. It is the same regardless of provider. It is enforced once, in one place, on a representation that does not depend on which API is downstream. That is what makes it durable. That is what makes it auditable. That is what makes it governable.
The same property that makes the system easier to extend is the property that makes it easier to control. This is not an accident. Good abstractions tend to compound: the right boundary makes everything above and below it simpler, and the things downstream of it (policy, audit, switching providers, adding agents) get easier in proportion.
The harder thing the easier thing makes possible
The framing of "agents speak intent" sounds, when you first hear it, like a small technical preference. Sure, capabilities are nicer than raw tools. Whatever.
It is not a small preference. It is the design choice that determines whether the layer between the agent and the world can be governed at all. A system in which the agent calls APIs directly is a system in which the only governance available is whatever the agent agrees to follow. A system in which the agent expresses intent and the layer translates is a system in which governance is a property of the layer, applies to every agent equally, and survives every model change without rewriting.
The difference between those two architectures is, in the long run, the difference between a feature you shipped quickly and an infrastructure you can build a company on.
We picked the second one on purpose.