Half These AI Agents Cannot Touch Anything Until You Build It

Every platform in this category says its agent takes action. Almost none of them say who has to build the thing the action runs through, and that turns out to be the difference between a product you switch on and a project you staff.

We read the documentation of fourteen platforms while writing their tool pages. They split cleanly in two, and the split does not follow price, size or how loudly a vendor uses the word agentic.

The two shapes

In the first, the agent arrives able to touch named systems through operations the vendor already built. You grant it permission and switch it on. What it can do is a fact about the product, and you can read it before you buy.

In the second, the agent arrives able to reason and nothing else. It acts through data actions, service nodes, exposed Apex classes, activated queries or an API connector that somebody in your organisation writes first. What it can do is a fact about your backlog.

Neither is wrong. The second is how you get an agent into a bank whose systems nobody else has heard of. But a demo looks identical either way, and only one of them ends with a working agent in the quarter you bought it.

Where your team builds the reach

Salesforce is the clearest case, and the most rigorous. An agent action is an Apex class, a SOQL query, a flow or a prompt template that somebody deliberately published to it, and a Named Query has to be manually activated in the org's API Catalog before the agent can use it at all. Nothing arrives switched on. That is excellent governance and it is also a queue of work for whoever owns your Salesforce org.

Genesys is the same shape stated more plainly: tools are data actions, and you select an existing data action rather than authoring one in the agent builder. If your administrator has not built the data action, the agent cannot do the thing, however well it reasons about wanting to.

Kore.ai is the most explicit about the consequence. Its Service Node makes REST or SOAP calls and its Data Service node does CRUD operations against a table, and the documentation notes that an agent cannot reach a data table without permission from that table's owner. Three separate people may need to act before one refund can be issued.

Where the vendor ships it

The trade is narrower reach for immediate reach. Dialpad's agent can perform a Create Contact or an Update Lead because Dialpad wrote those operations, and anything without a connector goes through Zapier rather than through your own endpoint. Re:amaze reads order data and does not write at all.

Fin sits at the useful end of this: it acts through your help desk's own API, so its reach is whatever permissions you grant on a system you already run, without a build.

Why the distinction is invisible when you are buying

Because both kinds of vendor demonstrate the same thing. In a demo the agent looks up an order and issues a refund. In the first group that demo runs on connectors shipped with the product. In the second it runs on integration work the vendor's solutions engineer did for the demo environment, which does not come with your contract.

The question that separates them takes one sentence: was the integration in that demo shipped with the product, or built for the demo? Ask it, and ask who at your company would build the equivalent.

What this changes about evaluation

• Cost the build, not just the licence. A buyer-built platform needs developer time in a queue you do not control, and that time is usually the larger number in year one.
• Find out who signs off. Where the reach is yours, someone owns the system being touched, and their approval is on the critical path for every new capability.
• Ask what happens on day one. Vendor-shipped reach means a narrow agent working immediately; buyer-built means a capable agent doing nothing until the first integration lands.
• Match the shape to your systems. If your refund logic lives in a service nobody has heard of, vendor-shipped connectors will not reach it, and the API connector approach is the honest answer.
• Check the limits, because in the second group they are yours to hit. LivePerson caps an integration call at 20 seconds with three retries and says it is not configurable. Kore.ai allows 1 to 60 seconds. Those numbers matter when your systems are slow.

The useful reframe is that in half this market you are not buying an agent. You are buying a reasoning engine and a set of hooks, and the agent is the thing your team builds with them. That is a perfectly good purchase. It is just a different one from what the marketing describes, and it needs a different plan and a different budget line.

Fourteen platforms, each read on the vendor's own documentation in August 2026, with the mechanism named in the vendor's words and the source on every row. This covers the platforms whose documentation we have read for their tool pages, not all 83. We take no money from any vendor here.

WRITTEN BY AR · UPDATED 2026-08-11

I read the fine print. Vendor pricing pages, billing definitions, terms, funding filings and acquisition notices — then I do the arithmetic nobody publishes: what a platform actually costs at your volume, what its headline metric is really counting, and who owns it now. I do not run benchmarks, and no page here pretends otherwise.

Editorial policy