Blog

This is BIG: Launching today in HubSpot: Custom Agents & Agentic Workflows

Written by Ralf van Thuijl | Jul 23, 2026 11:54:41 AM

July 23rd, HubSpot's public beta for Custom Agents and the Agentic Workflow Builder opens in your HubSpot Portal. It's genuinely one of the most powerful and useful features HubSpot has shipped in the last year(s) (my humble opinion).

I've been in the private beta of Breeze Studio custom agents since June 2025, with a small group of partners on HubSpot's AI Partner Advisory Council. So I've watched it get built from the ground up. It's been quite a journey to see it grow, and one of the main ways I grew into AI myself.

Now I can finally share what I've learned, and what you can actually do with the agentic side of HubSpot.

In this article:

  • The 2 major impact features that will be available in HubSpot from July 23rd
  • Why it matters and why AI Agents and Agentic workflow solve different for your business than AI Assistents do
  • What it lacks, what may be coming, and what I see as key quality-of-life improvements
  • 2 industry specific use cases in manufacturing and business services
  • What I would do first if you plan to get started with Custom AI Agents and agentic workflows in HubSpot.

Before we dive in...

Every custom agent you run in HubSpot now costs credits. You can still test and run simulations for free, but a live agent counts against your credit meter and cap. The costs shown are estimates — informational, and they vary from the real run.

Set your run limits before you switch anything on. That's the first thing I'd do today if you are diving straight in.

What will be available from July 23rd

Two big functions, wired together:

1. Custom Agents. A custom agent is a configurable AI worker. You give it:

  • Instructions - role, goal, method, output format,
  • Actions it's allowed to take - read and write to the CRM, browse the web, use HubSpot tools, or call out to other software through MCP
  • Knowledge it can read - your brand kit, your ICP, your product and pricing catalogue, files, HubSpot content, or a defined set of CRM records
  • Inputs it receives at run time — including a pointer to one specific record: a deal, a company, a ticket.

These workers handle recurring tasks for you, like a very capable intern would — as long as you give them the right "employee onboarding".

2. The Agent Automation Builder — Agentic Workflows.

This is the automation around the worker, or workers. You already had automation and workflows for years, but now we can actually chain several AI Agents together for full workflow/process automation. If you already build workflows, either in HubSpot, N8N or Make or Zapier, you will already know how this works.

How it works?

An Agent is basically a workflow step. So is an ad-hoc AI step you write as either a small prompt, or a very elaborate AI Agent. In addition, you can call upon external LLMs if you want to outsource work out of Hubspot. Currently those models are by: Anthropic, OpenAI, Cohere, Gemini or Grok

I already have an AI Assistant. Why do I need AI Agents? Here's my plea:

This is one of the first questions I get, and it's fair. The short answer to the question?: An AI assistant helps you, once. An AI agent does the work (potentially) without you, every time.

Here's a comparison in a bit more detail between what AI Assistants do vs AI Agents vs traditional workflow automation:

But there's more to it. Here's roughly where B2B commercial teams are right now:

  • 1.9% of commercial teams are still doing nothing with AI;
  • 14% are setting up potential use cases, but not investing yet in real AI or agents;
  • Only 43.9% have started testing agent solutions or a proof of concept

What does this mean? That most teams also lack experience in building scalable AI solutions. Part of the reason is that most of us are still "zero-shot prompters".

A zero-shot prompt asks the model to do something without giving it examples, context or a format — "write a blog post about X," "summarise this call." Whatever you leave out, the model guesses.

This is fine for a single task, but if you're looking for a highly scalable commercial process where you need stability, repeatability and dependability this falls apart:

  • Generic and repetitive — A single prompt or assistant reads like everyone else's output, because it is.
  • Inconsistent — You get a different answer depending on who typed it, which context ai randomly grabs, and a different one again tomorrow.
  • No company context — no brand voice, no ICP, no product or pricing, unless someone remembered to paste it in.
  • Confident gap-filling — the AI model assumes a lot, and the assumption is plausible enough that nobody checks.
  • No fixed output format — so nothing downstream can actually use the result.

An AI agent has the same judgement every time, is set up once and applied the same way every time it runs. It's the same model with the prompt written properly once — role, goal, method, output format — with your brand kit, ICP, way of working, standard operating procedures, buyer persona's, and product catalogue behind it as context. Instead of hoping every rep prompts well, you set it up one time.

So the rule I use with customers:

  1. Can a rule decide it? → traditional workflow. Faster and fully predictable. Most cases still land here.
  2. Does it need judgement, occasionally, for one person? → Breeze Assistant. Nothing to build.
  3. Does it need judgement, repeatedly, at volume? → (custom) AI agent and possibly an automated workflow that runs it, or multiple agents.

It's beta, where it may still lack functionality:

Being honest, after thirteen months in it:

  • Some integrations and connections are limited, though agents work well with all your CRM data, objects and context out of the box, you may need a developer to integrate with your other system's data if there is no MCP connector. Then again, this would be the same with most other middleware/AI-orchestration platforms that don't have an out of the box connector for your system. Not everything is plug and play.
  • Reporting on how an agent works — what it read, what it produced and why — could be better. It's on the roadmap. I personally think it's very important we can measure ROI well, but also monitor usage and run diagnostics on how agents process data.

None of this is a reason to wait. It's a reason to scope your first build around what's live today, and to set run limits before the meter starts.

Key improvements I see to the functionality

Here would be my dreamsheet for improvements to the functionality (and I shared this with HubSpot's Product team). Some are already on the roadmap:

  • More MCP connections with popular applications;
  • More diagnostic tools and visibility to determine where agents are pulling data from (transparency into what it retrieves and how) visibility in the agent interface into when the agent calls which tools, context, and data — but especially what it is actually retrieving and seeing;
  • Better controls over the output format / interface of agent summaries and how, including more power to translate AI Agent output to interface CRM Cards.
  • Reporting dashboards on agent runs and outcomes, ideally linked back to the original business case. Reports that can be shared with CFOs / financial managers
  • Logging / calibration tools to calibrate agent outputs and iterate on output quality using examples.
  • Integration with office software such as Google Slides / PowerPoint for generating slide decks (a major need for sales) and populated spreadsheets.

Let's dive into some use cases but first: Where a custom agent is actually worth building

A quick filter before either example. If HubSpot already ships an out-of-the-box agent or AI feature for the job, use that — don't build your own. Pre-call research, call recaps, deal scoring, lead routing, generic quote generation, RFP responses: those already exist. Rebuilding them is wasted effort.

A custom agent is worth it when the job needs your proprietary knowledge — your catalogue, your engineering rules, your pricing, your delivery method, your rate card. That's what a stock agent can't have. Both examples below are chosen to sit outside what's already in the box.

Use Cases

Let's make it tangible, because there's enough solutions, but not always the right fit problem or use case.

Example Use case 1 for Machine Manufacturers: An Agentic workflow that does all the RFQ prework for Application Engineers.

Take a manufactuer of complete food-processing lines. An RFQ here isn't a line-item order — it's a functional spec, sometimes a full tender: throughput, product characteristics, hygiene and ATEX constraints, footprint, plant integration. It arrives as a long PDF and waits for an application engineer to find time to read it, judge the fit, and start a response. Serious tenders sit cost a lot of time to sift through, judge, and create a credible first analysis or response that is often what wins a place on the shortlist.

Almost everything is engineered-to-order, and a machine-made price is a machine-made mistake. So you don't create an AI agent to create a quote, but rather to save time on qualification.

Here's what an Agentic Workflow could look like in HubSpot:

 

  • A Tender Reader Agent can turn specs into a structured requirements list
  • An Application & Feasibility Agent can check the requirements against your past reference projects and engineering know-how — separating what resembles work you've done before from genuinely new engineering, and flagging risks and gaps. Config and pricing stay in your ERP's CPQ; the agent qualifies, it doesn't quote.
  • A Qualification & Handover Agent can score the fit, pull the most relevant reference projects, draft the questions to send back, give a budget estimation, and routes it to the right engineer.

A lot of prework is done by the time the engineer picks up a qualified structured tender - reference cases attached, open questions listed, feasibility flagged.

Example ingredients for your custom agents:

Inputs

  • the tender PDF
  • your past reference projects & builds
  • engineering rules / know-how
  • good-fit rules
  • the customer record

Outputs:

  • a qualification summary
  • a fit score
  • an indicative budget range from comparable jobs
  • clarifying questions
  • the right engineer assigned

Here's what Tender Agent as an example could look like:

 

Example Use case 2 — For IT Services/Software Implementation Companies: A custom Scope-to-Proposal Agentic Workflow

Now let's take the example of a software implementation partner — the kind of firm that puts SAP, Oracle or Microsoft Dynamics into a mid-market business. A prospect sends an RFP: modules wanted, integrations, a data-migration, user counts, a go-live date. Today a solution architect reads it, maps it to their toolkit, estimates effort, checks who's free, prices it, and drafts a proposal — usually over a couple of evenings, because it competes with billable work.

The same RFP now triggers an Agentic workflow.

 

  • A Requirements Reader Agent pulls the modules, integrations, migration scope and user counts into a structured list.
  • A Solution & Effort Mapper agent reads a vault of your solution modules, accelerators and past-project benchmarks — mapping what's covered by standard configuration versus custom build, estimating effort per phase, and flagging the risks (a fragile integration, an unrealistic timeline).
  • An Estimate, Staff & SOW agent applies your rate card and current bench, produces price and margin, proposes a staffing plan from who's actually available, and drafts the statement of work.

What lands on the architect's desk is a first-draft SOW that already looks like your firm's work: scoped your way, estimated against real benchmarks, priced on the real rate card, staffed with real names. Low-margin or high-risk deals are flagged for a partner first. The architect edits and pressure-tests the judgement calls — they don't start from a blank page at 21:00.

Example ingredients for your custom agents:

Inputs

  • an RFP PDF
  • The software modules
  • Benchmarks
  • Your rate card and benchmarks
  • The customer record in the CRM

Outputs:

  • a draft SOW
  • a fit score
  • a price
  • margins
  • effort in days
  • risk flags
  • a staffing plan and the right architect assigned

Both stories run the same architecture: one agentic workflow, a handful of specialised custom agents doing consecutive work, each grounded in a knowledge vault only you can provide, all under one control plane. Several agents, each one performing one key task, on one workflow.

And here's what that Requirements Reader Agent could look like:

[END CHAPTER HERE WITH TAKEAWAYS]

What to do first: 
start at the process, not the tool

The order that actually works. Notice the tooling comes last, not first:

  1. Map the commercial process. Step by step, task by task. Find the frictions — the time sinks, the manual reading, the places deals stall. This is a business conversation.
  2. Separate automation from AI. A status changed, a field needs filling, a record needs routing — that's formatted data, and it's automation. Reading a tender, judging fit, working out the next step after a call — that's context, and that's where an AI agent can belong. Most frictions are automation. Be honest about which is which.
  3. Pick one use case by business impact. Quantify it roughly — hours saved × rate, or the growth it makes possible. Don't over-engineer the maths. Choose the single highest-impact one. Not three.
  4. Then check the data and provide the knowledge. An agent reading three years of inconsistent stages will confidently write the wrong thing — so clean the segmentation and status for that use case before you point an agent at a record. But data is also about the context and knowledge in the examples you need to provide it with. If you think of AI Agents as a very capable intern, they still need to know how your business works.
  5. Design before you build. One agent, one task, with defined inputs, outputs and success criteria. A small team of narrow agents beats one that tries to do everything. However, you may find out when you start building, you intended to build 1 agent, and it turns out to be 3 or more. This is why you map out your process step by step, task by task.
  6. Simulate before you spend. Simulation mode tests output and estimates cost without consuming a single credit. Use it on every agent, against real cases.
  7. Set run limits, then govern. Cap monthly runs to real demand and check the total against your plan. Decide who owns performance, who keeps versions, who reviews it and when. Keep a human on anything customer-facing.

In teams that do this well, steps 1–4 take longer than the build itself. The failures I've seen all skipped straight to "let's build an agent".

Summary

Most commercial use cases are still better solved with clean data and plain automation. Agents belong on the twenty percent that genuinely needs to read between the lines.

What changed today is that this now runs in the system your commercial team already opens every morning, where previously there would be friction in enabling CRM users to themselves launch AI agents on demand.

After thirteen months of building these, the conversation I still find most useful is the unglamorous one: working out where an agent actually fits in a commercial process, and where it doesn't.

That's exactly how we start with customers at Webs / Siloy Benelux. Before anyone builds anything, we run a short working session — an AI Opportunity Scan — that maps your commercial process and produces a ranked list of where AI would genuinely return, and which of those frictions are a fit for a custom agent versus a plain workflow. No credits, no build — just a clear picture of what's worth doing. And if you already know the one friction you want gone, we build that agent with you and prove it on your own data before you scale it.

So: are you planning to build your first custom agent in HubSpot — and do you already know which process you'd point it at?

If you want to think that through — what needs an agent, and what just needs a decent workflow — send me a message.