Connecting an OpenAI agent to HubSpot: what is actually possible today

Someone in your business has asked whether ChatGPT can just look at the CRM. Perhaps a rep wants the history on an account before a call, or someone saw a demo where an agent updated a deal in a chat window.

The answer, as at 08 Aug 2026, is yes, in three ways that are easy to confuse, two of which are not engineering projects at all. Choosing the wrong one is the usual way this costs money for nothing. HubSpot and OpenAI each document their own half competently, and neither documents the combination.

There are three routes, and two need no engineering

Route one is the HubSpot connector for ChatGPT. Your team installs it from the App Marketplace and talks to the CRM inside ChatGPT itself. It started read-only and gained write actions on 26 Feb 2026, so it can now create and update records and log activities. It is available across all HubSpot tiers and respects each user's existing CRM permissions.

Route two is a workspace agent. OpenAI introduced these on 22 Apr 2026, in research preview on ChatGPT Business, Enterprise, Edu and Teachers. It has since dropped the research-preview wording without declaring general availability, so confirm the current position and plan list before you build around either. This is the route most people do not know exists, and it removes the reason for a great many builds. A workspace agent runs on a schedule or an API trigger, keeps working in the cloud while nobody is logged in, operates in Slack as well as ChatGPT, and carries version history, approval on write actions and service-account authentication. Nobody writes code. Where to draw that boundary in practice is the subject of governing AI write access to your CRM.

Route three is an agent you build on OpenAI's API, pointed at HubSpot's hosted remote MCP server, running on your own infrastructure.

Notice what route two does to the usual argument. "You need engineering once the work runs unattended, on a trigger, with approvals" was true a year ago and is not true now. So the first question on any agent project is no longer which model, it is whether a workspace agent already does the job. Often it does, and the rest of this piece is about the narrower set of cases where it does not.

HubSpot publishes the server. OpenAI does not publish a HubSpot connector

OpenAI's Responses API can call prebuilt connectors that OpenAI hosts and maintains: Dropbox, Gmail, Google Calendar, Google Drive, Microsoft Teams, Outlook Calendar, Outlook Email and SharePoint. A productivity set, with no HubSpot connector on it and no CRM connector of any kind.

You do not need one. The Responses API also accepts any remote MCP server by URL, and HubSpot runs one: a hosted server at mcp.hubspot.com that went generally available on 13 Apr 2026, authenticated with OAuth 2.1 and PKCE. That release added write access alongside read, which is when this became a real option rather than a demo.

One point of accuracy matters more for us than most. MCP is Anthropic's protocol. Anthropic open-sourced it on 25 Nov 2024 and OpenAI adopted it afterwards, as did a long list of other tools. Nobody at OpenAI invented it.

The practical consequence is the useful bit. Because MCP is an open standard rather than a vendor's private integration, the same HubSpot server works for a Claude-based agent too. You are not choosing a CRM integration when you choose a model, which makes the model a per-workload decision you can revisit.

What you can actually do once an agent can read the CRM

The GA release split access by object, and that split shapes what is buildable.

Read and write: contacts, companies, deals, tickets, line items and products, plus activities (calls, meetings, notes, tasks and emails).

Read only: quotes, invoices, orders, carts, subscriptions, segments, campaigns, landing pages, blog posts, site pages and marketing events.

So an agent can research an account and write a note against it, but cannot rewrite your invoices. The work that pays for itself looks like this:

• Pre-call preparation. Read the last two quarters of activity on an account and write a short brief as a note on the deal, half an hour before the meeting.
• Pipeline hygiene. Find open deals with no logged contact in three weeks, or a close date that has quietly passed, and raise a task for the owner. The job everybody agrees should happen and nobody does.
• Loss-reason capture. When a deal closes lost with the reason field blank, read the associated emails and calls, propose a reason against your existing picklist, and put it in front of the rep to confirm. Most CRMs have this field and most are empty, which makes win-loss analysis impossible.
• Order and document entry. Structured data arriving as unstructured text is the most common version of this problem.

Narrow, repeatable, and a human can check the output. That is the profile of work that survives production.

"Give it everything" is how a deal stage gets overwritten at 2am

The HubSpot MCP server respects the existing HubSpot permissions of the user it is connected as. That sounds like a safety feature and it is, but read it again. The identity you connect is the security boundary. Connect as a super admin and you have built an agent with super-admin reach, because as far as HubSpot is concerned it is you.

So give the agent its own user rather than a shared login or the founder's, and start read-only. Most of the value above is read plus a note, and notes are cheap to delete where deal stages are not.

Then scope by property, not just by object. An agent that appends notes is a different risk from one that moves stages or changes amounts. Decide which fields it may touch and enforce that in your own code, because the object-level scope will not.

Finally, use the platform's guardrails. The Responses API takes an allowed_tools list, so the model only sees the tools you chose, and require_approval governs whether a call needs sign-off. It requires approval by default. Turning that off on day one to make a demo flow smoothly is how most of these incidents start.

One HubSpot caveat: if sensitive data is enabled on the account, activity objects are blocked from MCP access entirely. That restriction is specific to the MCP server, so a design assuming it can read call logs may fail outright on such a client.

Three things that break in production and not in the demo

Rate limits. HubSpot's private apps get 100 requests per 10 seconds on Free and Starter and 190 on Professional and Enterprise, with a paid add-on taking that to 250. Daily limits run from 250,000 to 1,000,000 by tier. The detail that catches people is that the burst limit is per app but the daily limit is shared across the account, so your agent competes with every other integration you own. Exceed it and you get a 429, so anything without backoff and a retry queue fails at month end.

Ambiguity. Three companies with similar names, two contacts on the same email domain, an open deal per site rather than per customer. A human hesitates. An agent picks one. Match on IDs where you have them, and have it stop and ask when confidence is low.

Silent partial failure. A multi-step write updates the deal, then fails on the note. Nothing errors visibly, the model reports success in prose, and you have half a change in the CRM. These need a transaction boundary and a check on the end state, not trust in the model's summary. Ask a language model for a deal amount and it will happily give you "around £40,000, pending confirmation": a fine sentence and a broken currency field.

Where a build genuinely starts: you cannot get the answer back

Route two has a hard edge, and it is not where most people assume.

You can start a workspace agent from your CRM. OpenAI's docs, checked 08 Aug 2026, were explicit about what happens next: the API trigger queues the run and returns a 202 with a link to the conversation in ChatGPT, and run status polling exists behind a beta header. But the agent's response cannot currently be retrieved through the API.

In operational terms: you can fire an agent from a HubSpot workflow, and you cannot get its answer back into HubSpot. The output lands where a human goes to look at it, in Slack or a document, not in the field you wanted populated. For "summarise this account for the rep", that is fine and probably ideal. For "write the loss reason into the deal record", it is not something you can design around.

Three other boundaries hold, and they matter precisely because the one people reach for first no longer does.

• Enforced schema on writes to a system of record. A CRM field has a type. You need output validated against it and rejected when it fails, not a well-behaved agent that usually complies.
• Deterministic, repeatable output. When the same input has to produce the same result every time, and you need to prove it did, you need the prompt, the model version and the tests under your control.
• An audit trail you own. Enterprise Compliance Platform logs cover conversations involving agent tasks, but not the individual agent actions inside them. If you need to reconstruct which record was touched and why, that is logging you build.

Sometimes the right answer is a subscription you already pay for

We sell agent builds. This still applies.

HubSpot has its own AI under the Breeze brand, and Agent Hub (in beta at the time of writing) brings prebuilt agents, custom agents and agentic workflows together in one place, requiring HubSpot Credits plus a Professional or Enterprise subscription. If your requirement is well-trodden, a prospecting agent, a customer agent, summarisation inside the record, HubSpot has probably already built it and there is no integration to maintain.

So before anyone scopes a build, two questions in order. Does a workspace agent do this inside a ChatGPT subscription you hold? Does HubSpot's own AI do it inside a HubSpot one? Only when both answers are no does route three earn its money.

What good looks like

If you commission a route-three build, from us or anyone, it should have all five.

1. A scoped identity and a written read/write boundary. Its own user, least privilege, revocable in one action, with the objects and properties agreed before anyone builds.
2. Schema enforcement on every write, validated against your actual field types and rejected rather than coerced when it fails.
3. A human approval step on consequential actions. Anything touching money, stage or customer-visible communication pauses for a person. The Agents SDK has this built in.
4. Logging you could hand an auditor. Every tool call, its inputs, its outputs and the decision behind it.
5. A named owner and a review date. Platforms move. The Assistants API shuts down on 26 Aug 2026 and anything built on it stops working that day.

That last one is not a footnote. If a supplier proposes building this on the Assistants API today, that tells you what you need to know about how current their knowledge is.

What to settle before you spend anything

Work through the three routes in order and stop at the first that fits.

If your team wants to ask questions of the CRM, install HubSpot's connector for ChatGPT, spend an afternoon on permissions, and you are done.

If the work should run on a schedule or a trigger and the answer can land in Slack or a document for a person to act on, try a workspace agent before commissioning anything. That is configuration for an ops person, not a project.

You are in route three when the result has to be written back into a system of record with an enforced schema, when it must reach systems the connectors do not cover, or when you need an audit trail you control. Then the scoping conversation matters more than the model choice, because the failure mode is almost never the model. It is an agent given more access than the job needed, writing prose into fields that expected numbers, with nobody able to reconstruct what it did.

We are a HubSpot Diamond Solutions Partner and an OpenAI Select Partner, which is why we can speak to both halves rather than one. We build the same work on OpenAI and on Claude, resell nothing, take no margin on your usage, and will tell you when the answer is Breeze or nothing at all.

For the full range of options open to a UK business, see our overview of what OpenAI offers.

Request a quote and start with the workflow, not the model.