Will every customer get an API continuously shaped by its own agents?
\nA SaaS vendor publishes one API, and each customer works around the parts that don't fit. A person learns a workaround once. Different agents repeat it on every request, relying on context memory, potentially thousands of times a day, and every pass costs time and compute and risks an error. As compute and code become less expensive, a vendor can fit the API to each customer instead of to the ideal or average one.
\nThis means we're well on our way to intelligent APIs. They have three parts:
\nWhat makes an API intelligent is a continuous, and evolutionary, feedback loop. The vendor's software watches how a customer (and its agents) use the API, proposes changes to that customer's layer, tests them against the customer's recent traffic, and ships them as versions it can roll back, with the customer's approval for anything that changes meaning or permissions.
\nStripe, Shopify and Twilio set the standard for APIs. Each already varies by customer in some way:
\nexpand pulls related records into one response. Shopify's GraphQL lets each request choose exactly which fields come back.Each is set by a person and stays put until a person changes it. Desk research has found no vendor that documents an API tuning itself to how each customer uses it.
\nEach company can download a description of its own setup. Salesforce's SOAP API guide offers two. The Enterprise WSDL is built \"for a single Salesforce organization.\" It lists that company's objects and fields, and must be downloaded again \"when changes are made to the custom objects or fields in their org.\" The Partner WSDL is generic and works \"within any organization,\" which is why partners use it. Same operations; the difference is whether the description includes the customer's data model. A REST API beta goes further and generates an OpenAPI file covering resources \"that reflect your customizations and configurations.\"
\nAgents get standard tools, selected per team. Salesforce's standard MCP servers offer \"a fixed set of tools\" for reading, creating, updating, deleting and querying records, and calls run with the user's permissions. Admins can then build custom servers for each role, \"a sales rep server, a support agent server,\" mixing those tools with the company's automations, because \"beyond a few dozen tools, an AI client struggles to select the right one.\"
\nSalesforce also has a customer layer: formula fields, roll-up summaries, validation rules, list views, reports and Flows, set up for each company. But people build it by hand, for people. What's missing is a layer shaped by how agents actually use the system, and an automated loop that keeps it up to date.
\nIndustries already get their own(ish) designs. Industry clouds such as Health Cloud, now Agentforce Health, add their own data model and setup on the same platform. One industry version became a separate business: Veeva built its life-sciences CRM on Salesforce, and its annual report says it is now moving customers to its own platform and won't renew the agreement.
\nMost of the customization happens in implementation. Any admin can add a field in minutes; the real work is deciding which fields, rules and reports the business needs. Partners — usually people in a vendor's solutions engineering or customer success team — study the business, translate it into objects, fields, rules and workflows, and hand it over to the customer's admins. A 2021 IDC study that Salesforce sponsored projected that its ecosystem would make \"$6.19 for every $1 Salesforce makes by 2026.\" Much of the money around Salesforce sits outside Salesforce itself.
\nThat model has two limits:
\nAgent traffic, ideally via traces, can show exactly what's needed: which questions get asked, which fields get read and which never do.
\nPicture a pharmaceutical sales team and a software sales team on the same Salesforce product.
\nThe pharma team. Every visit to a doctor is also a compliance record: who can be visited, which samples are allowed, what can be said. Its agents ask: \"Which doctors in my territory can I still see this quarter, and what can I leave them?\" Its layer is mostly rules that every update must pass.
\nThe software team. Its agents ask: \"Which accounts have rising product usage but no open deal?\" Most of what it needs is a daily view that combines CRM records with product-usage data.
\nThe harder test is two software companies that define \"at risk\" differently. An industry version would build in one definition. A customer layer can hold each company's.
\nThose differences matter because agents pay for every mismatch on every call. In the review behind The Agent Readiness Test for Enterprise Operations Software, a different vendor's API returned 20 records per call, so reading 113,000 records took 5,650 calls and an hour and a half. Bulk export would fix that case. It wouldn't stop an agent from rebuilding the same total from raw records on every question, and getting a slightly different answer each time.
\nThere are two main objections so far:
\nBoth move the work rather than remove it. Someone still has to turn raw records into a small, correct answer. As one reader of the readiness post put it, \"pre-filtering/sorting/processing is where you get lots of gains.\"
\nThe vendor is better placed to do part of that work, in four cases:
\nThe split I'd propose: the vendor keeps the data accurate, the customer makes it useful, and an intelligent API lets the vendor take on part of the second job.
\nThis pattern isn't new. By the 1930s, IBM's tabulating machines were standard, and each shop wired its own plug-in control panel for each job. Salesforce made customization cheap by turning it into settings that one shared platform reads per customer, while the core stayed fixed.
\nBut there's a limit. Before 1883, each American railroad ran on its own time; once trains from different lines had to connect, standard time zones replaced them. Customization wins inside one business. Where businesses have to exchange data, such as invoices, payments and orders, the shared format has to win.
\nSalesforce already has the per-company description, the per-team tools, a hand-built customer layer and the industry versions. What it lacks is the loop that shapes that layer from agent usage; today people set up each piece by hand. Whoever builds that loop, Salesforce or a challenger, turns implementation from a one-time project into a service that keeps adjusting to each customer.