An AI agent should use as little AI as possible

The most consequential decision in building an AI agent is where the AI stops. Our oldest production agent has run for nine months and made more than a million record edits in HubSpot without breaking anything, and the model is not the reason. Most of what that agent does never touches a model at all.

Every step you hand to a model is a step that can go wrong a new way on each run. Code fails predictably and loudly. A model fails plausibly and quietly, which is worse, because the output still looks like an answer. So before you write an agent, go step by step and ask which ones have exactly one right answer. Those belong in code, however capable the model is.

Unreliable agents are usually agents where nobody drew the line

An agent produces output you cannot trust when the deterministic and the model-driven parts of the workflow were never separated. The model inherits steps that have a single correct answer, and it answers them the way models answer everything, with a confident guess.

We built a quoting agent for a machinery manufacturer whose product knowledge lived in more than fifty machine brochures on SharePoint. The first version was close to a chat session with access to the library. It worked well on one example and broke on the next four. The model was not the weak point. The version that survived contact with real deals needed real guardrails: retrieving the right specs and assembling the document had to stop being judgment calls, and the rep's review became the last gate before anything reached a customer. The rep's job turned into review instead of research.

How do you decide which steps use AI? Ask whether you could write the test.

If you can write a test that fails whenever a step is wrong, that step belongs in code. If correctness is defensible rather than provable, it belongs to the model. That question is sharper than asking what the model is capable of, because models now handle many deterministic steps correctly most of the time, and "most of the time" is the failure mode you cannot debug.

Step	One right answer?	Owner
Pull the deal, its contacts, and the last ten emails	Yes	Code
Check whether the company already exists in the CRM	Yes	Code
Decide which machine fits the customer's stated requirements	No, defensible	Model
Total the quote against the price list	Yes	Code
Decide the lifecycle stage from a call transcript	No, defensible	Model, with its reasoning written down
Draft the email, summary, or quote prose	No, defensible	Model
Write the record back, send it, or create it	Yes	Code, behind a guard

The expensive mistakes hide in steps that look like judgment

The steps that cost you money are the ones that feel fuzzy and are not. "Does this company already exist in our CRM?" reads like a judgment call. It has exactly one right answer, and a model that searched and found nothing will report "no" with complete confidence. A failed lookup is not proof of absence: the record may sit under a different domain, a former name, or a typo.

Idempotency is the clearest case of a property a model cannot hold. Making sure something happens exactly once is not a matter of judgment, and no amount of prompting makes a model dependable at it. In the operating system we run our own company on, every call that creates something, a company, a deal, a contact, an invoice, a signature request, goes through one guarded helper that runs a duplicate search, writes a journal entry before it acts, carries an idempotency key, and reads the record back to verify. The model decides whether a deal should exist and what it should say. The code decides that it happens once.

We found that boundary by getting it wrong. One of our own migration scripts called the CRM API directly instead of going through the guarded helper, and duplicated a deal in one of our portals. No model was involved in that failure. The guard was bypassed, which does the same damage as never having built it.

What the split looks like in production

ATLANT 3D sells atomic-scale nanofabrication systems into academia, where interest is easy to find and budget is not. We built them a funding enrichment agent: for each academic contact it researches active grants, funding status, and institutional budget indicators, then writes the result to a HubSpot property. The research is model work, because "does this lab have money to buy" is a defensible conclusion rather than a lookup. The write is code. RevOps time spent on data management went from 90% to 30%, and their lead scoring now reflects who can buy instead of only who fits.

The same split is what makes volume safe. ATLANT 3D compared two outreach approaches over one period: a consultant working manually reached 10 contacts, and AI-powered sequences built on enriched data reached 600 and produced 20 more meetings. That trade only works because the sending path is deterministic and the data underneath it is correct. Six hundred AI-personalized emails on top of wrong job titles is six hundred embarrassments.

A pipeline-review automation we built has the same shape. Reading a deal and writing its summary is model work. Deciding which deals are in scope, running before every review cycle, and assembling the overview is code. Preparation dropped from 40 hours to 30 minutes.

Design the split before you build

The platforms are converging on this shape. HubSpot's Agent Builder lets you choose which parts of a workflow are deterministic and which get handled by a frontier model, and it can be triggered by events outside the CRM, including a webhook. That is the right architecture to expose. It is also a reminder that a tool which lets you place the boundary will not place it for you.

So draw it on paper first. List the steps, and mark each one as having a single right answer or a defensible one. Pulling records and writing results back are code. Reasoning, classifying, and drafting go to the model. Whatever the model decides, a human still has to be able to review the decision rather than rubber-stamp it. An agent built that way is auditable when it works and debuggable when it does not, and that is the difference between a demo and something you can put in front of customers.

If you want that map drawn for your own workflows before anyone builds anything, it is what our Scoping engagement produces: $2,500, credited toward implementation.

FAQ

What is a deterministic agent?

A deterministic agent is one whose steps produce the same result every time they run on the same input, because those steps are ordinary code rather than model calls. Most production agents are hybrids: deterministic code handles retrieval, calculation, and writes, while a model handles the steps where the correct answer is defensible rather than provable.

Which steps in an AI agent should not use AI?

Any step where you could write a test that fails when the step is wrong. Fetching records, checking whether something already exists, arithmetic against a price list, and writing or sending anything all belong in code. Existence checks and idempotency are the two that most often get handed to a model by mistake, because they feel like judgment and are not.

Does using less AI make an agent less capable?

No. It concentrates the model on the work only a model can do, which is reasoning, classifying, and drafting, and it removes the steps where a plausible-looking mistake is expensive. Our oldest production agent has made more than a million record edits in nine months without breaking anything, and most of its steps are deterministic.

How do you stop an AI agent from creating duplicate CRM records?

Route every create through a single piece of code that searches for an existing record first, carries an idempotency key, and reads back what it wrote. Do not ask the model to decide whether a record already exists: a search that returns nothing is not proof the record is absent, and the model will report absence with full confidence.

Where should AI sit in a HubSpot workflow?

On the reasoning in the middle, not on the edges. Pulling records out of HubSpot and writing results back should be deterministic, while classification, scoring rationales, and drafted text go to the model. Have the model write down its reasoning alongside its decision so the output stays auditable.