No Capability Behind a UI: The Promise HubSpot Has Not Kept Yet

In May 2026 HubSpot made a promise any software company could copy. Duncan Lennox, its chief product and technology officer, wrote in Our Vision for Building an Open Ecosystem for the Agent Era that HubSpot is "working toward a simple standard: anything you can do inside HubSpot, you should be able to do through an API." Under the heading "Coming next: full API parity", the post adds: "No capability should live only behind a UI."

The vision post set no date, and HubSpot developers and partners still say publicly that new features ship which a person can click and an agent cannot call. The promise and the complaint are both reasonable. The gap between them is the most common agent-readiness problem in software, and HubSpot is just the company that wrote it down.

What HubSpot has actually opened

HubSpot has opened more than most. Its remote MCP server, the connector that lets assistants such as Claude and ChatGPT work inside a HubSpot account, became generally available to every account on 13 April 2026. It can read CRM records, marketing objects, and engagements, and it can create and update contacts, companies, deals, tickets, line items, products, and engagements. On 30 March HubSpot shipped developer platform version 2026.03, its first date-based version, and each version is now supported for 18 months before builds against it fail.

That is real work. It is also partial, and the edges show where parity breaks:

• Quotes, invoices, orders, carts, subscriptions, and segments are readable through the MCP server but not writable.
• When an account turns on sensitive data, HubSpot's announcement says "engagement objects (calls, emails, meetings, notes, and tasks) will be blocked from access through the MCP server". The same announcement says the block does not apply to the standard CRM APIs, so the agent connector reaches less than the API does.
• The vision post gives no date for parity. The intelligence layer it describes will be available "soon".

None of this is unusual. It is what parity looks like when a product was built for people first and opened to software afterwards.

The market has noticed where HubSpot stands. In October, IDC published its first assessment of agentic AI platforms and compared 25 vendors. Salesforce, HubSpot's largest CRM rival, was placed among the Leaders. HubSpot was not one of the 25.

Why a UI-only feature is a missing feature

An agent cannot use what it cannot call. A person can learn a new screen, find a setting three menus deep, and work around a missing export with a spreadsheet. An agent working for that person has two options: an API, or driving the interface like a browser robot. The second is slow, breaks when a button moves, and fails at the first login challenge or bot wall.

So every UI-only release splits a product's customers in two. The ones who work by hand get the feature. The ones who have delegated that work to an agent get nothing, and they are increasingly the customers who spend the most time in the product. What an agent needs is access it can predict and that respects the user's permissions, not a route through a dozen screens.

There is a competitive cost too. When a customer's agent can do a job in one tool and not in another, the agent's owner notices which tool is the bottleneck. Agents that drive a browser on a person's behalf, which we covered in Muse and Dots Both Drive a Browser, make the interface route possible but no more reliable.

How to stop it happening

These are for software makers. Most cost little if they are in place before the next release, and a lot once a backlog has formed.

Make the API part of "done". A feature is not finished until it has an endpoint, documentation, and a permission scope. Put that in the release checklist next to the tests, and give it the same power to block a launch. Parity slips one feature at a time, and each slip looks small on its own.

Build your own interface on your public API. If the screens your team ships call the same endpoints customers can, parity is the default instead of a project. Every internal-only endpoint is a future gap.

Give agents the same permission model as people. An agent acting for a user should be able to do what that user can do and nothing more. HubSpot's MCP server gets this right ("users can only access or modify records they already have permission to view or edit") and then breaks it with the sensitive-data block, where the connector reaches less than the API the same user is allowed to call. A second, narrower rulebook for agents is a parity gap that looks like a security feature.

Keep the agent connector as wide as the API. An MCP server is a thin layer over endpoints that already exist. If it covers less than the API, the assistants your customers use most will see a smaller product than the one they pay for. Generate the tools from the API description where you can, so the two cannot drift apart.

Publish what is covered. A table that lists every feature with its API status, its MCP status, and a date for each gap costs an afternoon. It turns "they keep shipping features without APIs" into "this ships in March", and it is the document a buyer's agent will look for first. Say in the changelog when a new feature has no API yet, and when it will.

Version so integrations survive. Agents built on your API break when the API changes under them. HubSpot's 18-month support window for each platform version is a good model: long enough to plan around, and stated up front.

How to get out if you are already behind

Most products are already behind, so this is the more useful list.

Stop the gap growing first. Before backfilling anything, adopt the "done" rule above for new work. A team backfilling old features while shipping new UI-only ones never catches up.

Take an inventory. List every action a person can take in the interface and mark each one: API, MCP, both, or neither. Support tickets, community threads, and failed API calls show which gaps customers already hit. That list is where the complaints in public come from, so it is better to have it first.

Backfill by use, reads before writes. Fill the gaps customers hit most, starting with reading data. A read endpoint carries less risk, and it lets an agent understand a workflow before it is allowed to change anything. Add writes once the permission model is settled.

Publish the gaps with dates. Customers forgive a stated gap with a date far more readily than silence. HubSpot's vision post would carry more weight with a date next to "Coming next".

Measure parity as a number. Covered actions divided by total actions, reported each quarter. A number that only goes up is the strongest evidence a promise like HubSpot's is being kept.

If you buy software rather than build it

Ask for the coverage table before you sign. Give an agent a real task in a trial account and watch where it stops: an action that works in the interface and fails through the connector is the gap you will live with. Ask when the missing pieces will ship, and get the answer in writing.

The same test applies to websites

A website has its own version of the problem. A form that only works with JavaScript, a price shown only in an image, and a booking flow behind a client-side widget are all capabilities that live only behind a UI. Our implementation guide for applications covers the software side. For a page, the Agent Analyzer checks whether an agent can read it and act on it, and the Agent Visualizer shows the point where an agent working through the page gives up.

What this does not tell you

We have not measured HubSpot's parity, and HubSpot has not published a figure. The complaints about UI-only features come from individual developers and partners, and their counts of what is and is not covered cannot be checked from outside. HubSpot's MCP coverage has grown since April and may be wider by the time you read this. The recommendations above are our judgement, not results from a study, and parity is not the only thing that decides whether an agent can do a job: rate limits, pricing, and permissions matter as much.