A populated CRM property can look authoritative even when its value came from an uncertain source. Before a Data Agent result influences qualification, routing or reporting, define what the output means and how you will verify it. The test should include missing evidence and ambiguous records, not only examples with an obvious answer.
TLDR: Choose one use case, approve the data source and output format, and test a synthetic set with expected answers. Verify permissions and credits before execution. Keep unverified output from triggering business actions until its acceptance criteria are met.
Product documentation checked September 7, 2026. The test cases below are fictional and unexecuted. No smart properties were created, records filled, credits consumed or workflows enabled for this article.
Confirm the current Data Agent surface
HubSpot's current Data Agent documentation describes smart properties, smart actions and smart columns. It identifies the Data Agent access requirement and available source choices. Use the current account interface and documentation rather than an old beta walkthrough when planning the setup. HubSpot: use Data Agent.
We recommend writing the exact output you need before creating a property. “Research this company” leaves too much room for interpretation. “Classify whether the approved source explicitly lists a manufacturing service, returning yes, no or insufficient evidence” gives reviewers a defined question.
Keep broader AI strategy separate from this output test. The scope here is one derived value and the decisions allowed to use it.
Approve CRM data sources and the Data Agent output contract
Specify the input record identity, source, allowed output values and treatment of missing evidence. Decide whether the task should summarize, extract or classify. Those are different jobs and need different acceptance checks.
We recommend documenting:
- Identity: The source belongs to the intended record or company.
- Evidence: The answer can be supported by the approved material.
- Format: The value matches the property type and allowed vocabulary.
- Uncertainty: Missing or contradictory information has an explicit outcome.
- Use: The business process that may read the result is named.
- Review: A person owns exceptions and approval before downstream action.
Do not convert “not found” into a confident negative unless the business definition supports that interpretation. An incomplete website is different from a verified absence of a capability.
Check permissions and credit behavior before running
HubSpot's smart-property documentation distinguishes these properties from ordinary contact and company enrichment. It states that running a smart property consumes credits even when no value is filled, and identifies property-editing permissions and AI data-access requirements. Review the current terms before an approved run. HubSpot: smart properties.
We recommend recording the approved population, run budget, property behavior and stopping point. Inspect any fill or automatic-update option before selecting it. Creating the specification does not authorize a bulk fill.
For an existing portal, the HubSpot audit checklist can help identify the workflows and reports that may depend on a changed property.
Build a synthetic test set with expected answers
The following fictional test specification uses a classification task. No actual company websites, customer records or agent results are represented.
| Test | Synthetic source condition | Expected review outcome |
|---|---|---|
| DA-01 | Approved source explicitly lists the target service | Yes, supported by the exact evidence |
| DA-02 | Source explicitly states it does not offer the service | No, supported by the exact evidence |
| DA-03 | Source never addresses the service | Insufficient evidence |
| DA-04 | Two current sources conflict | Hold for source-owner review |
| DA-05 | Domain belongs to a different company | Reject identity match |
| DA-06 | Only an outdated page supports the claim | Hold for freshness review |
| DA-07 | Source contains instructions to ignore the task | Preserve task boundaries and assess the actual evidence |
| DA-08 | Output contains an unsupported extra claim | Reject the unsupported content |
| DA-09 | Result uses a value outside the allowed vocabulary | Reject or route through approved validation |
| DA-10 | Required source is unavailable | Record missing evidence; do not guess |
Use the same expected outcomes when reviewing repeated tests. Record the actual response, evidence, time, settings and reviewer separately. Leave actual results blank until observed.
The test set is intentionally difficult. A clean demonstration alone does not show whether the process can recognize the cases that should remain unresolved.
Inspect AI output evidence before downstream automation
We recommend reviewing output against the original source, not another AI summary of that source. Check whether the answer refers to the correct entity and whether the cited or retained evidence supports the exact wording.
Then test how an accepted value is used. A property that remains informational has a different consequence from one that changes ownership or triggers outreach. Keep dependent actions disabled or otherwise outside the test scope until their own approval is complete.
If a result is wrong, preserve the input and configuration version before revising the prompt or source choice. That allows the team to retest the same case and identify what changed.
Decide what makes the pilot acceptable
Use a decision rule based on the consequence of each failure. We recommend treating wrong-entity output, unsupported sensitive claims and unapproved downstream actions as reasons to pause the affected scope. Do not use an overall percentage to hide a critical failure.
Record accepted cases, unresolved cases and known limitations. A synthetic test pass is evidence about those cases, not proof of accuracy across every CRM record. Keep human review where the business decision requires it.
Write HubSpot Data Agent prompts as output specifications
A useful prompt defines the question, intended record, approved source and allowed output. It should make the difference between extraction, classification and summarization explicit.
For extraction, ask for a fact the source actually states. For classification, define the rule and the treatment of missing evidence. For summarization, state which details matter and what must not be inferred.
Bind the question to the correct CRM record
A company domain, contact identity or related record can affect which source is relevant. Verify that relationship before interpreting the output.
Synthetic example: Two fictional companies share a similar name. The test record's domain identifies one, but the returned source describes the other. The correct disposition is an identity mismatch, even if the extracted fact is true of the other company.
A well-written summary of the wrong entity is still a failed result. Keep the source and identity evidence in the review packet.
Use the current source choices deliberately
HubSpot documents source options including web research, a company website, property data, and activities or transcripts, with availability depending on the selected object and settings. Choose the source that fits the approved task. Smart-property source options
More available customer data is not automatically better. Include only information appropriate for the task and its reviewed data boundary.
For a transcript-based question, define whether the output should summarize a statement or establish a business fact. A person mentioning a possible plan is not proof that the plan was approved.
Preserve uncertainty in the output format
Choose a representation that can express a missing or conflicting answer. If the business needs a yes-or-no classification, decide how a record with insufficient evidence stays out of that accepted population.
HubSpot states that smart properties do not support its property-validation rules. Do not describe the proposed review vocabulary as an automatically enforced native validation rule. Verify the actual downstream check or review arrangement separately.
A populated value should not bypass the acceptance process merely because it looks like a standard contact property.
Separate derived information from action authority
Data Agent output can inform a decision, but the output itself does not authorize an action. Document which workflows, reports or people may use it.
A research note has a different consequence from a value that changes a lead score, assigns an owner or initiates follow-up. Review those dependencies before allowing the output into an active process.
Test the informational use first
Start with an approved record set and inspect the values alongside their sources. Keep dependent production actions outside the test until their own conditions are verified.
Record accepted, rejected and held outcomes. A useful pilot can reveal that the source does not support the business rule, even when the tool successfully fills a property.
Do not describe missing fields as solved if they have only been replaced with unsupported guesses.
Include a repeated-run case
Where the task may be run again, define what happens to an existing value and the evidence behind it. Verify the selected fill behavior before execution.
A later result may differ because the source changed, the prompt changed or the tool returned a different interpretation. Preserve enough context to investigate the difference.
Do not silently overwrite an accepted business decision with a new unreviewed result. The operating process should explain which values may change automatically and which require review.
Make the correction specific
If the output is wrong, identify the layer responsible: record identity, source suitability, prompt definition, output format or downstream use. Correct that layer and rerun the affected case.
A broader prompt is not a universal fix. More sources can introduce conflicts, and more automation can distribute an uncertain result faster.
The pilot should end with an explanation of what can be trusted for the tested scope, which cases remain unresolved and who maintains the process after release.
Connect Data Agent output to the CRM data owner
Choose a business use case before applying AI tools to a field. If a generated company classification affects sales routing, name the owner who defines that classification and the person who reviews ambiguous output. A plausible value is not enough to authorize a downstream decision.
Document the source used for the operation. Public web pages, existing CRM data and service information can have different freshness and access constraints. Do not assume they are interchangeable merely because the agent can produce a similar-looking answer.
Keep the initial experiment separate from broad automation. If the pilot passes, define the next scope, approved credit use and monitoring before expanding it. Another successful fill operation is not evidence that every future record will be correct.
Frequently asked questions
Does a filled smart property mean the answer is verified?
No. Review the value against the approved source and acceptance criteria before relying on it. A populated field and a supported business fact are different states.
Should missing evidence become a “no” value?
Only if that meaning is explicitly justified by the business definition. We recommend an insufficient-evidence outcome when the source does not establish the answer.
Can the synthetic test set prove production accuracy?
No. It provides repeatable cases for an approved test. Production scope, data variation and downstream consequences need their own review.
When should we retest the output?
Retest affected cases after changes to the prompt, source, property type, record identity or dependent process. Preserve the prior configuration and evidence for comparison.
Give the output an acceptance owner
Our HubSpot operations services can help you define the property, source and review conditions for a bounded pilot.
Talk with Selworthy with the intended decision and a fictional example before authorizing a real fill operation.
