Skip to content
ConsultEvo

How AI Works: A Practical Guide to Models and Marketing Workflows

AI systems use learned patterns, supplied context and, in some products, tools or external data to produce an output. The mechanism depends on the system. In a language model example, a customer note such as “I need to compare plans” might be mapped to a proposed CRM category. That category is not a verified fact or an instruction to update the record. An application should validate it before a person or system acts.

A practical chain is prompt and relevant context, then model-generated output, then application checks, then human or system action. This is a simplified language-model example, not a description of every AI architecture. Model behavior and product controls vary, and fluent output can still be wrong or biased.

This guide explains the model concepts first, then applies them to bounded marketing workflows. The implementation examples are proposed designs, not claims that HubSpot provides each complete workflow as a built-in feature.

How does AI work?

For a language model, the simplified process begins when the system converts input into tokens. Tokens are pieces of text. They may be characters, parts of words, whole words or punctuation. Token counts vary by model and encoding, so a word count is not a precise token count. OpenAI’s token guide explains the concept and provides model-specific counting guidance.

The model uses patterns learned during training, together with the current prompt and supplied context, to generate output tokens. A product may add formatting rules, safety controls, retrieval from external sources or tool calls. Those additions are product-specific, not part of one universal AI sequence. OpenAI’s explanation of its language models describes next-token generation as part of that process.

Training and inference are different. Training adjusts a model through data and a training process. Inference is the model producing an output from an input. An ordinary prompt does not necessarily update model parameters or teach the model from that interaction. A product may retain conversation context or use another form of stored information, but that is not the same as retraining the model.

Generation can be probabilistic, so the same prompt may produce different answers. A plausible answer is not proof of accuracy. Factual claims should be checked against reliable evidence before they change CRM data, guide customer advice or enter published content.

AI, machine learning, generative AI, automation and agents

AI describes systems built to perform tasks such as interpreting information, classifying inputs or generating outputs. Machine learning is one approach to building AI systems, in which patterns are learned from data. Generative AI produces new content such as text or images. Automation executes a specified process or rule, such as routing a record when a required field has a particular value.

An AI agent is a system that can use tools or take bounded actions toward a task. The term does not mean the system is conscious or has unrestricted authority. A workflow can combine rules, model calls, retrieval, stored context and human decisions. If a system can update a CRM, send a message or publish content, define which actions it may take and which require approval. Teams assessing bounded agent workflows can also review AI agent consulting as a relevant service.

Use deterministic rules to decide whether processing is allowed. Use AI only for the ambiguous interpretation inside that boundary.

Use rules for consent, required fields, numerical thresholds, duplicate identity, date windows and eligibility. If those checks pass, AI may help interpret a free-text customer note. If the task is “is the opt-in field true?”, a rule is more appropriate than asking a model to infer consent.

A practical marketing workflow: classify CRM intent with bounded AI

The following is a hypothetical design. Keep the CRM record and original note as the source of truth. Store an AI classification as a proposed value with enough provenance to explain its origin. HubSpot documents workflow enrollment triggers and a batch upsert option using a unique property, but those capabilities do not make a multi-step process exactly-once or automatically race-safe.

A marketer or CRM administrator could use a HubSpot workflow to identify eligible records, then pass only permitted fields to an approved AI feature or external integration. Before launch, check the feature, account permissions and data-handling terms. For help designing the broader CRM workflow, see HubSpot systems consulting.

01Identify eligible workA filter, event, schedule or webhook trigger identifies a record or event. A deterministic preflight rule checks consent, eligibility and required fields.
02Send permitted contextThe integration sends the note and source identifiers needed for classification, not unrelated CRM fields. Sensitive-data eligibility is checked before transmission.
03Request a bounded resultThe model maps the note to one allowed category and returns structured fields. It does not decide consent, eligibility or other exact policy conditions.
04Validate before writingThe integration checks the schema, allowed values, evidence, policy flags and source revision. A named CRM operations reviewer handles exceptions.
05Write and measureOnly a validated result updates the intended CRM property. Save provenance and write status, then monitor corrections, stale results and duplicate attempts.

For example, an allowlist might contain pricing_question, product_fit, support_issue and unclear. The following is an illustrative contract, not a HubSpot-published schema:

{
  "portal_id": "illustrative-portal",
  "object_type": "contact",
  "source_record_id": "illustrative-record-id",
  "source_event_id": "illustrative-event-id",
  "processing_version": "intent-v1",
  "classification": "pricing_question",
  "evidence_source_ids": ["illustrative-event-id"],
  "needs_human_review": false,
  "schema_version": "1",
  "source_record_version": "illustrative-revision-4",
  "write_status": "validated_pending_write"
}

The event identifier and processing version distinguish one source event from later runs. If the workflow instead processes a current record snapshot, define that snapshot grain explicitly and use its revision or timestamp. Do not treat a confidence score as calibrated merely because a selected model exposes one. The implementing team must evaluate any threshold against reviewed examples.

Reject missing fields or categories outside the allowlist. Compare the current source revision with the revision used for inference. If the note changed, reprocess it or send it to review. Route ambiguous, sensitive, conflicting or invalid results to a named person instead of writing them. Preserve the original note separately from the proposed classification.

Marketing use cases: give each one a bounded job

Choose a defined input, output and destination for each task. HubSpot reported that 47% of marketers using AI in its cited research used it for research, summarization or data gathering. This is a survey finding from the specified research, not a universal benchmark.

Trigger or source AI responsibility Validation Destination and fallback
Customer note in the CRM Map free text to one allowlisted intent category. Check the enum, source revision, evidence reference and policy flags. Update one controlled property and retain the note. A mixed support and pricing request goes to the CRM reviewer.
Identified research documents Organize findings and extract claims from supplied reports or approved pages. Retain source IDs and verify material claims, quotations and figures against the documents. Save to a research brief. Unsupported or conflicting claims are marked for manual research.
Approved content brief Draft an outline or article within the brief and source constraints. Check source fidelity, factual claims, brand requirements, privacy and legal requirements. Save as a draft. An editor removes unsupported promises before a separate publication action.

HubSpot documents AI-assisted blog generation and offers a Case Study Generator. Those pages establish content-generation capabilities, not the complete source-checking and approval process above. A useful operating pattern is to give each use case one bounded model job, one validation gate, one destination and one named exception owner.

Prevent duplicate, stale or unauditable AI updates

First define the row grain. A processed item might be a current record snapshot, a source event, a model run or an aggregate. These are different records and should not share an ambiguous key.

For event processing, a proposed idempotency key is portal_id + object_type + source_record_id + source_event_id + processing_version. This is a design recommendation, not a HubSpot field contract. For model-run logging, add a run identifier. For citation tracking, use one row per cited result within a specific run. For an aggregate, define the reporting period, prompt set, engine or model grouping and aggregation rule.

Concurrency matters

A lookup followed by create is not race-safe. Worker A and worker B can both find key K missing and then both create a row. Enforce uniqueness in the database where possible, or use a supported transactional or unique-property upsert. Retry with the same identity after a timeout rather than creating a new one.

HubSpot documents batch upsert using a configured unique property for supported objects and conditions. Confirm the current API and object requirements before relying on it. Workflow enrollment and re-enrollment identify work to consider, but they do not provide an exactly-once guarantee for external calls, retries, manual enrollment or concurrent workers.

Keep an audit record with the source record or event ID, source timestamp or revision, model and provider identifiers where available, prompt and schema versions, validation result, reviewer decision and write status. Store the original source separately from the derived CRM value so an operator can answer why a field changed.

Check permissions, privacy and operational limits before launch

Before sending CRM or customer data to an AI tool, confirm account permissions, object and property access, subscription and feature availability, data sensitivity and the selected tool’s applicable data-handling terms. HubSpot’s Sensitive Data guidance describes restrictions around sensitive data and AI inputs. Exact treatment depends on the feature, property type, account settings and terms. Exclude data that is not eligible or choose a different workflow.

For integrations, check the current API version and endpoint, follow limits for that endpoint and authentication method, and handle HTTP 429 responses using applicable retry guidance, including Retry-After where supplied. HubSpot’s current API documentation describes date-versioned APIs. Verify the version and limits during implementation because they can vary by endpoint and account.

Go-live checks
  • Confirm the fields are permitted for the selected AI feature and account settings.
  • Verify user or app permissions and the intended CRM destination property.
  • Record the source record ID, event ID when applicable and source revision.
  • Check the current API version, endpoint-specific limits and 429 handling.
  • Test retries with the same idempotency key and verify duplicate prevention.
  • Reject invalid output and stale source revisions before any write.
  • Name the person who owns ambiguous, sensitive or conflicting exceptions.

A useful mental model, and its limits

Language-model fluency is not proof of human-like understanding, unbiased judgment or self-awareness. Data, labels, objectives, context and deployment rules can all influence an AI result. A commonly used educational taxonomy describes reactive, limited-memory, theory-of-mind and self-aware AI. It is not a universal technical standard, and the latter two are conceptual categories rather than established capabilities of current general-purpose systems.

Many commercial products combine model training, retrieval, stored history, ranking systems, business rules and experimentation. Classifying the whole product into one category can therefore mislead. Similarly, a system that produces a convincing classification is not necessarily making a verified decision. The surrounding rules, evidence checks and approval path determine what the organization is actually allowing it to do.

Judge a workflow by operational measures, not by how convincing an output sounds. Define the denominator and observation period, then track valid-output rate, human-review rate, processing time, correction rate and duplicate-write rate. Keep raw observations separate from reported summaries, and keep CRM events separate from aggregate marketing metrics. Compare like with like and keep consequential decisions governable.

Official implementation references