The fastest way to get a disappointing answer from AI is to start with a product name.

Most builders do not get stuck because they picked the wrong tool. They get stuck because they started with a tool at all.

Let’s say you have a business problem. You open an AI assistant. You ask it to build something. And within about thirty seconds, you are knee-deep in half-right suggestions, implementation details you did not ask for, and a vague feeling that maybe you need to be more technical before you can even begin.

As someone who learned this the hard way, let me tell you something: you do not.

I once used Cursor to build a weather app for my late dog.

Before you say anything, that was a completely reasonable concept to my dog.

But that wasn’t the first thing I built. My first idea was to build a quick little idea generation app, learn something, ship something. I opened Cursor, started typing, and trusted it to figure out the rest. Cursor is good at code. So I let it handle the code.

What followed was a tour of everything that happens when you skip the thinking step. Each fix introduced a new error. Each new error needed its own fix. At one point Cursor managed to break my local setup while trying to help me. I eventually scrapped the whole project and started over. This time, with a dog weather app, one of the ideas my original app spat out, and honestly at that point I needed a win.

The second attempt worked. But not because I suddenly got better at coding and Cursor. It worked because I slowed down and thought about what I was trying to build before I started building it.

What you need is a better starting point.

Before you ask AI to build anything in HubSpot, define the problem first.

I know that sounds simple. But it is the most basic difference between getting a useful answer and getting a polished hallucination. And that gap is wider than you'd expect.

What happens when you skip the thinking step

Let’s use a real example. Your Customer Success team is going into renewal calls blind. They spend 20 minutes manually pulling deal history before every call because renewal risk signals aren't visible from the company record. You decide to fix it.

So you open Breeze Assistant and type:

👤 "Help me get better visibility into my pipeline."

🤖 Breeze Assistant: “You have 26 deals totaling $1,247,001 in pipeline value. Your biggest visibility win comes from separating late-stage forecast from top-of-funnel. Create a 'Late-stage forecast' view filtered to Qualified To Buy, Decision Maker Bought-In, and Contract Sent. Add a 'Needs attention' view for deals missing a pipeline, close date, or owner. If you want, I can build a pipeline dashboard layout with the exact reports I'd recommend."

Technically fine. Completely useless for the actual problem.

Let me explain.

First off, Breeze Assistant doesn't give you a generic non-answer regardless of the prompt. It goes to work right away, pulls your real deal data, and comes back with a substantive analysis: stage distribution, owner assignment gaps, named deals, recommendations for your next dashboard. That's the unique HubSpot context it offers.

That's real, but also completely beside the point. The root problem wasn't pipeline hygiene. My core problem was that CSMs couldn't see renewal risk on the company record. Breeze Assistant made a smart guess about what "visibility" meant, did solid work on that guess, and handed me a thorough answer to the wrong question.

This is the Breeze Assistant version of what happened to me with Cursor. It wasn't that the tool failed. It was that I let the tool decide what I was building. Breeze Assistant filled in the blank because I left it blank.

Here's the thing, a more specific prompt wouldn't have fully fixed this either. The issue isn't the wording of the ask, it's that I hadn't done the thinking before I opened anything. Better inputs start before the prompt.

The fix is not a better prompt. It's defining the problem better.

Define the problem before you open anything.

Call it a build brief. It has four parts:

1. The business problem. Not the feature you want, the problem underneath it. What's going wrong, what's being missed, what's taking too long?
   
   
2. What success looks like. What would someone be able to do, see, or skip if this were solved? "Better visibility" is not success. "CSM opens a company record and sees renewal risk in under 10 seconds" is.
   
   
3. Who it's for and where they live in HubSpot. Which record type? Which view? Breeze Assistant needs to know where you're working.
   
   
4. The constraints. No developer? Say it. Existing HubSpot data only? Say it. Constraints help Breeze Assistant give you answers that will actually work.

Stitch it together:

[Who] needs to [do what] when [trigger or context]. Right now, [what's broken or missing]. Success would look like [concrete outcome]. Constraints: [what can't change].

Here's the renewal example written out:

"My CSMs spend 20 minutes pulling deal history before every renewal call because they can't see renewal risk signals from the company record. I need deal age, last activity date, and open support ticket count visible directly on the company record in HubSpot Smart CRM, using data we already have in HubSpot. No new integrations, no developer."

Now paste that into Breeze Assistant.

If you're not sure where to start, ask Breeze Assistant to interview you.

Most builders who aren't developers haven't spent time in the seat of someone who has to gather requirements before they build anything. Developers know what questions to ask before they start, like “What's the scope? What are the edge cases? What counts as done?” Because they've been burned by starting without those answers.

If you don't know what questions to ask, ask Breeze Assistant to ask them for you.

👤 "I have a problem I want to solve in HubSpot, but I'm not sure how to scope it yet. Before I try to describe it, ask me the questions a developer would ask before agreeing to build something, one at a time. Don't give me solutions yet."

Breeze Assistant will start pulling out the scope you didn't know you needed to define. What record is this on? Who uses it? What does it need to show? What happens if there are multiple deals? By the time you've answered five questions, you have most of your build brief already written. And you know a lot more about your own problem than you did when you started.

Then write the brief. Then paste it in.

Watch what Breeze Assistant does with a real problem statement.

Here's the same problem, but defined before I opened anything:

👤 "My CSMs spend 20 minutes pulling deal history before every renewal call because they can't see renewal risk signals from the company record. I need deal age, last activity date, and open support ticket count visible directly on the company record in CRM, using data we already have in HubSpot. No new integrations, no developer."

🤖 Breeze Assistant: Yes — you can do this without integrations or custom code. Create four company properties: a rollup for the earliest create date on your open renewal deals, a calculation that shows time since that date (deal age), a rollup for renewal deal last activity, and a rollup counting open support tickets. Then add them to the company record in a 'Renewal health' section.

One decision to make first: if a company has multiple open renewal deals, do you want the oldest driving the risk signal or the most recent? That choice changes the signal more than the field type does.

Want me to turn this into a field-by-field build spec with exact property names and filter logic?"

The only difference was what I brought into the conversation. Specificity with AI isn't just polite, it's functional. The more clearly you define the outcome, the scope, and the constraints, the less Breeze Assistant has to guess – and the less it guesses, the more useful its first answer is.

Tell Breeze Assistant how much you want it to do.

Once Breeze Assistant has the spec, ask it how much it can handle:

👤 "Okay I want to build this. What are my options if I want AI to do as much of the implementation as possible rather than me clicking through HubSpot manually?"

Breeze Assistant came back with three options:

• Option 1: Most automated. Breeze Assistant creates the properties for you directly, then you spend 2–3 minutes placing them on the company record layout manually (the one step it can't do for you).
• Option 2: AI-assisted in HubSpot.Use Breeze Assistant inside the Properties tool to generate each property from a prompt. You review and confirm each one before it's created.
• Option 3: Add an AI insight layer. Once the core fields are live, create a smart property, something like "Renewal risk summary", that uses Data Agent to generate a plain-English signal on top of the deterministic fields.
  
  

For this use case, Breeze Assistant recommended starting with Option 1 or 2 to get the core fields live first, and only adding Option 3 if your CSMs want a synthesized signal alongside the raw numbers.

This is where a lot of builders stop. And for this problem, that's exactly right. Breeze Assistant can handle it. But sometimes the problem is bigger than what Breeze Assistant can do alone. Here's how to know.

When to go further: the routing model

So what happens when Breeze Assistant isn't enough? Here's the map of where to go next - and importantly, what each path is for.

Breeze Assistant gave me the what. What it didn't tell me, unless I asked explicitly, is which HubSpot tool to use when Breeze Assistant isn't enough. So here’s what to ask when you are ready to make that next move because you want something custom that isn't an out-of-the-box HubSpot feature.

👤 “Analyze this use case as an implementation-architecture question, not a how-to question. I want the full HubSpot solution landscape: no-code, admin/config, AI-assisted, workflow-based, dataset-based, custom-code, and developer-tooling options. Include the real product names and implementation surfaces I’d encounter in practice, plus internal technical surfaces I would not know to name myself, such as MCP or CLI options if relevant. For each option, say what it handles, level of effort, typical owner, tradeoffs, and whether you recommend it first.”

Here's what Breeze Assistant said, pertaining to this particular use case, but translated into a decision you can make right now:

Start here: No code, build it natively → Properties + Company record customization This is the core architecture for this problem – not Breeze Assistant, not even workflows. Rollup properties pulling deal age, last activity, and open ticket count from associated records, placed on the company record layout where CSMs will see them. Fully no-code. Fully deterministic. Breeze Assistant can help you build it faster, but this is the foundation.

Use AI to build it faster → Breeze Assistant Once you know what to build, Breeze Assistant can create the properties for you directly (rollups, calculations, field names, filter logic), after you confirm. It's an accelerator on top of the native architecture, not a replacement for it.

Logic needs to be more specific than rollups allow → HubSpot Workflows When "all associated renewal deals" is too blunt - when you need to filter by pipeline, set a risk flag based on multiple conditions, or keep a company field in sync on a trigger – you move into Workflows. Breeze Assistant can draft the workflow; you review and turn it on.

You want a plain-English risk signal on top of the data → Data Agent smart properties Once the core fields are live, you can add an AI-generated summary, something like "Renewal risk summary", that synthesizes deal history, support patterns, and activity signals into a readable note directly on the company record. This is an overlay on the deterministic fields, not a replacement for them.

You need this to run on a schedule across hundreds of companies → datasets + scheduled workflows When the problem becomes operational (think nightly refreshes, weekly recalculations, enrollment based on multi-object logic), you set a dataset as the trigger and run the workflow on a cadence. Still admin/ops territory, no engineering required.

The logic is too custom for native properties or standard workflows → custom code action Composite risk scoring, custom deal-selection rules, advanced cross-object logic.

This is where you cross from no-code into developer territory. Only move here if rollups and workflows genuinely can't express the logic you need.

Only once you get here, four more surfaces become relevant:

• Agent Builder is for building custom agent experiences inside HubSpot. Think tool orchestration, controlled action-taking, external integrations. Relevant if you're building something that needs to reason across systems, not just display fields on a record.
• Developer MCP server is for developer-oriented implementation work: a builder who wants AI-assisted tooling around build and config tasks. Useful if your team decides to implement custom automation or code-backed logic, but not the first tool you'd reach for on a native CRM-property solution.
• HubSpot Agent CLI is for developer workflows where someone wants to drive implementation from a technical, code-oriented environment. Relevant if engineering owns the solution and wants an AI-assisted dev loop. Not necessary for a no-code or native-first version of this problem.
• Remote MCP server is for those building connectors for LLMs like Claude, ChatGPT or something similar to Breeze Assistant within their own software, and you want that agent to be able to take actions within HubSpot on behalf of your users.

None of these are first-choice surfaces for the use case we discussed in this blog. They only become relevant if you intentionally build something custom that requires code.

For the renewal risk problem: you don't need to go past Breeze Assistant. But knowing what each path is for, and that they're not the same thing, is what separates a builder who knows where they're going from someone who types "Help me get better visibility into my pipeline" into Claude Code, hits a wall, and wonders if they're technical enough to continue.

They are. They just needed a better starting point.

Where to start

Write your build brief before you open anything. Four parts: the business problem, what success looks like, who it's for and where in HubSpot, and the constraints. Then open Breeze Assistant in your HubSpot portal and paste it.

If Breeze Assistant can solve it, great. Let it. If what you're trying to do is bigger, now you know which direction to walk.

My dog's weather app is working great, by the way.