Why your sequence reply rate is lying to you, and the Agent Hub build that reads every reply.

Reply rate is the metric every sequence dashboard leads with, and it is the least informative number on the page. A 12 percent reply rate could mean twelve meeting requests per hundred sends or twelve unsubscribe demands. The dashboard does not distinguish. The only way to know is to read every inbox manually, and on any real send volume, nobody does. Replies sit unread for days while the sequence report claims success.

This is a data structure problem, not a diligence problem. Reply sentiment has never been a native, reportable property in HubSpot. Until recently, closing that gap meant middleware, a third-party sentiment tool, or custom code. HubSpot's Agent Hub removes all three requirements.

What follows is the architecture of a reply classification agent built entirely inside a portal, including the two failure modes hit along the way. Both failures are instructive, because they generalize to every agent deployment.

What is HubSpot's Agent Hub?

Agent Hub is HubSpot's centralized workspace for pre-built agents, custom agents, and agentic workflows, currently in beta. It combines the agent builder (where you define an agent's instructions, inputs, actions, and outputs) with a workflow canvas that can trigger those agents from CRM events. The builder is no-code: instructions are written in plain language, actions are selected from a library, and outputs are defined as structured fields the workflow can branch on.

Agent Hub is included with Professional and Enterprise editions. Custom agents consume HubSpot Credits when they run, drawing on the credit allocation already bundled into paid subscriptions. The Run Agent workflow action that connects agents to automation carries a limit of 500 executions per day, which is worth knowing before you point it at a high-volume trigger.

What does a reply classification agent actually do?

The agent reads the most recent inbound sequence reply directly from the contact's CRM record and returns exactly one of two values: Positive reply or Negative reply. The full loop has four steps.

First, a contact replies to a sequence. The workflow trigger is the sequence enrollment association with a "latest reply is today" condition, so enrollment fires the moment the reply lands.

Second, the workflow runs the agent, passing the enrolled contact as the agent's input. The agent uses CRM read access to locate the actual inbound email body. Not a pasted snippet, not a summary property. The real email.

Third, the agent classifies the reply text against explicit rules and returns a single enumeration value through a structured output field.

Fourth, the workflow branches on that value. The positive branch stamps a sequence outcome property and can route to rep follow-up. The negative branch stamps the opposite outcome and can feed suppression logic. "Tell me more" routes to the positive branch. "Please remove me" routes to suppression. No human triage in between.

The result is that reply sentiment becomes a reportable CRM property, updated in real time, on every sequence reply.

Why do agents fail when you tell them to "find the reply"?

Agents classify whatever context they can reach, and an instruction to "find the reply" does nothing if the agent has no path to the data. The first version of this build failed exactly this way. The instructions told the agent to locate the most recent inbound reply in CRM, but the agent's configuration had neither a contact to inspect nor a CRM read action attached. It had five unrelated actions (company research, call summaries, file tagging) and no way to reach an email body.

The failure was invisible at the instruction level. The instructions read correctly. The agent simply could not execute them, so it classified from missing context.

The fix required three specific pieces working together: a CRM Object input typed to Contacts, so the workflow hands the agent a specific record; the "Read your HubSpot CRM records" default action, so the agent can actually inspect that record's email activity; and instructions that name the exact activity to inspect, the latest inbound email reply associated with recent sequence activity. Once all three were in place, classification sharpened immediately.

The general lesson: an agent's instructions describe intent, but its inputs and actions define capability. When the two diverge, the agent does not warn you. It just produces confident output from whatever it could reach.

Why are fallback rules the most dangerous line in your instructions?

A fallback rule converts missing context into a definitive answer, and the agent will apply it silently every time retrieval fails. The original instructions contained one line: if no relevant reply is found in CRM, return Negative reply. Reasonable on its face. In practice, it meant that every retrieval failure was recorded as a prospect rejection.

The symptom was a contact whose reply read "tell me more" landing in the negative branch. The phrase was never misclassified. It was never read. The agent could not access the reply, hit the fallback, and returned Negative with full confidence. The workflow then dutifully stamped a false negative on a warm prospect.

AI amplifies whatever logic you feed it. A fallback that maps "I could not find the data" to "the answer is no" will generate false negatives at exactly the rate your retrieval fails, and nothing in the output will flag it. The corrected instructions separate the two states: ambiguous replies default to Positive unless there is a clear refusal or opt-out, and the agent is told not to classify from missing context at all.

How do you build the reply classification agent?

The final configuration is deliberately minimal: one input, one action, one output, and instructions that do nothing but reply lookup and classification.

The agent. Name it for its single job. Add one input with type CRM Object, set to Contacts, labeled Contact. Attach one action: Read your HubSpot CRM records. Remove every action that does not serve reply lookup; unrelated actions add noise and blur the research context. Define one structured output, primary_classification_field, with data format Enumeration and exactly two values: Positive reply and Negative reply.

The instructions. Direct the agent to inspect the provided contact's recent email activity, find the most recent inbound reply tied to sequence activity, and read the actual reply text before classifying. Enumerate the negative markers (unsubscribe, remove me, not interested, explicit refusal) and state that everything else, including questions and requests for more information, is positive. Default ambiguity to positive. Prohibit explanation in the output.

The workflow. Trigger on sequence enrollment with latest reply today, with re-enrollment on. Add the Run Agent action and map the enrolled contact record into the Contact input. Branch on primary_classification_field with three paths: Positive reply, Negative reply, and none met. Each classified branch edits the record to stamp a sequence outcome property.

One operational note: after changing an agent's input shape, reopen the Run Agent step in the workflow, remap the input, and save the action again. Workflow steps can hold a stale snapshot of the agent's old configuration, and the resulting error (missing required agent input) points at the workflow, not the agent.

How do you build the reply classification agent?

Agent Hub is included with HubSpot Professional and Enterprise editions, and custom agent runs consume HubSpot Credits already bundled into those subscriptions. There is no separate license for the builder itself. The cost of this build is configuration time, measured in hours, plus per-run credit consumption once live. For most portals, the credits are already sitting in the subscription unused, which makes the activation math straightforward: the capability is paid for whether or not it runs.

What this supersedes.

Implementation scope.

The full build is a half-day of focused work for a portal with sound email logging: one agent, one workflow, one custom outcome property, and a test pass covering an explicit positive, an explicit negative, and an ambiguous reply. The agent test panel runs without consuming credits, sending email, or writing to CRM, so the classification rules can be validated before anything goes live. The two failure modes above cost the most time on the first build; knowing them in advance is most of the speed.