---
title: Some Jobs Need an Agent. Some Need an Engineer.
description: Breeze covers the workflows it was built for. Everything else is a build decision, and most manufacturers get it wrong in both directions.
---

[Debsan blog](https://www.debsan.co/blog)

# [Some Jobs Need an Agent. Some Need an Engineer.](https://www.debsan.co/blog/some-jobs-need-an-agent.-some-need-an-engineer)

 Written by [Sal Brucculeri](https://www.debsan.co/blog/author/sal-brucculeri) | Oct 7, 2026, 4:21:26 PM

Every manufacturer we talk to has the same reflex the moment Breeze or Claude comes up. Find the thing that already exists. Turn it on. Move on with the day.

Sometimes that reflex is right. Sometimes it burns three months of a sales manager's patience discovering that the agent they turned on was never built to do the job they actually needed done. *Both outcomes look identical in the first week.* They only diverge once someone tries to trust the output.

## The real decision is not Breeze versus Claude. It's agent versus engineer.

We've spent this whole series arguing that [Breeze and Claude are different layers, not rivals](https://www.debsan.co/blog/breeze-and-claude-are-different-layers-of-ai-not-rivals). That's still true, and it's part of why [manufacturers are finally taking HubSpot seriously](https://www.debsan.co/blog/why-manufacturers-are-finally-taking-hubspot-seriously) in the first place. But underneath that framing sits a sharper question most manufacturers never ask out loud: is this job already covered by something HubSpot shipped, or does it need someone to actually build the thing?

Breeze's agents are prebuilt. Claude's native connector, used out of the box, is configurable but still generic. Both are native HubSpot AI. The third option, the one nobody demos at a conference, is a deliberately built Claude workflow designed around your ERP, your BOM structure, your approval chain. That's the work of an **AI Forward Deployed Engineer**: an AI implementer who works inside a client's actual ERP, CRM, and financial systems to deploy AI where it reduces coordination cost or decision latency, rather than delivering a generic product or a demo from a distance.

*Notice what that definition does not say.* It doesn't say "builds AI agents." It says works inside your actual systems. That distinction is the entire decision framework.

## Breeze is the right answer when the job already has a name.

If your problem is "score inbound accounts and draft outreach," the Prospecting Agent already does that, generally available, configurable between review-before-send and autonomous send. If your problem is "answer documented service questions without a person typing the same answer forty times a week," the Customer Agent already does that, with a confidence score deciding when to hand off. If your problem is "a property is blank and I want something to try filling it," the Data Agent already does that.

None of those jobs need an engineer. They need someone to turn the agent on, configure its boundaries, and get out of the way. Paying a consultant to rebuild a solved problem is not operational transformation. It's billing for a Google search.

## Claude's connector, used as shipped, is the right answer when the job stays inside what it already reaches.

Claude's native HubSpot connector can create and update contacts, companies, deals, tickets, line items, custom objects, and a long list of marketing and engagement objects, all generally available. Quotes and quote templates are newer and still in beta. Every write goes through a global approval setting, and the connector cannot delete anything.

That's enough for a lot of ad hoc work. A rep asking Claude to draft a customer-ready paragraph and drop it into a line item. A manager asking Claude to pull a segment and summarize it. If the job is bounded, a person is reviewing every write, and nothing about it depends on logic specific to how your company actually runs, the out-of-the-box connector is the right tool. No implementation required, just configuration.

## An AI Forward Deployed Engineer is the right answer when the job crosses systems native HubSpot AI was never built to touch.

Here's where the real jobs live, the ones that actually move a manufacturer's numbers. An engineering spec becoming a quote line item. A SKU or BOM reference getting reconciled against the ERP before anyone trusts it. A warranty claim that should update an equipment record a different system owns. None of these are HubSpot problems. They are **coordination cost** problems wearing a HubSpot costume: the time and effort a company spends moving information from where it exists to where a decision needs it, separate from the cost of the decision itself.

Breeze's agents don't reach outside HubSpot's own objects. Claude's connector, used as shipped, reaches into HubSpot but has no opinion about your ERP, your engineering system, or which fields map to which. Someone has to decide that mapping, decide where the approval gate sits, and decide what's too ambiguous to automate at all. That decision work is exactly what an AI Forward Deployed Engineer does, and it is exactly the part no native tool, Breeze or Claude, does for you.

*This is also, not coincidentally, the part of the job most AI vendors skip over in the pitch deck.* A connector is infrastructure. A mapped, approved, bounded workflow built on top of that infrastructure is an implementation. Those are not the same purchase.

## The tell is where the cost actually lives, not how advanced the AI sounds.

Ask four questions before anyone writes a line of workflow logic. Does this job already exist as a named Breeze agent? If yes, stop reading and go turn it on. Does it stay fully inside the objects Claude's connector already writes to, with a person reviewing every write? If yes, configure the connector and move on. Does it require translating between HubSpot and a system that doesn't share HubSpot's schema, like an ERP, an engineering tool, or a spreadsheet nobody else can read? If yes, you need deliberate implementation. Does getting it wrong put a customer-facing document or a financial number at risk? If yes, you need an explicit approval gate someone designed on purpose, not a default setting someone forgot to check.

We laid out [which product owns which job](https://www.debsan.co/blog/breeze-owns-the-agent.-claude-owns-everything-else) in the last post; this diagnostic is how you apply that split to a specific workflow instead of the product category as a whole. Most manufacturers answer all four questions without realizing the answers point in different directions for different jobs inside the same company. That's normal. The mistake isn't picking the wrong tool once. It's assuming one tool answers every question on the list.

## This is the actual service a Forward Deployed Engineer sells, and most of the work is boring on purpose.

Debsan doesn't sell Breeze or Claude. HubSpot and Anthropic already sell those. What we sell is the judgment call in the previous section, applied to your actual ERP, your actual BOM structure, your actual quote-to-order process, by someone who has done it enough times to know where manufacturers get burned. The work itself is unglamorous: field mapping, approval placement, writing down what should never be automated. That's precisely why it doesn't show up in a product demo, and precisely why it's the part that determines whether the thing actually works six months from now.

Native AI keeps getting better at the jobs it was built for. It is not getting better, on its own, at knowing your BOM reference format or your approval chain. That part doesn't ship. Someone has to build it.

## Buy the agent for the job it already knows. Build the engineer for the job it doesn't.

That's the whole framework. Everything else in this series has been evidence for it.

### What CEOs actually ask us

**Should we use Breeze or build something custom with Claude?** Check whether the job already has a name as a Breeze agent. If it does, use Breeze. If the job crosses into systems outside HubSpot, you need a deliberate build.

**Can't we just turn on Claude's connector and skip paying for a custom build?** Yes, as long as the job stays inside objects the connector already reaches and a person is reviewing every write. The moment it needs judgment about handoffs or approval boundaries specific to your business, that's implementation work no toggle provides.

**How do we know when we've outgrown native tools?** When the actual cost is coordination cost, information stuck between systems that don't talk, rather than a missing feature inside HubSpot itself. That's the diagnostic, not how impressive the AI sounds in a demo.

**Does this mean we need to hire a software developer?** Not necessarily a developer. You need someone who treats your HubSpot instance, your ERP, and the handoffs between them as one system to be configured deliberately. That's the job description of an AI Forward Deployed Engineer, whether that person sits on your payroll or Debsan's.

[View full post](https://www.debsan.co/blog/some-jobs-need-an-agent.-some-need-an-engineer)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Sal Brucculeri"
  },
  "dateModified" : "2026-10-07T16:21:26.336Z",
  "datePublished" : "2026-10-07T16:21:26Z",
  "headline" : "Some Jobs Need an Agent. Some Need an Engineer.",
  "image" : {
    "@type" : "ImageObject",
    "height" : 60,
    "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
    "width" : 60
  },
  "mainEntityOfPage" : "https://www.debsan.co/blog/some-jobs-need-an-agent.-some-need-an-engineer",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60,
      "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
      "width" : 60
    },
    "name" : "Debsan blog"
  }
}
```