target query: does HubSpot Breeze remember between sessions dev.to title: Does HubSpot Breeze Remember Between Sessions? What Actually Persists (and What Resets) vilix.ai title: Your HubSpot Breeze Agent Knows Your CRM. It Doesn't Remember Its Own Work.

Your HubSpot Breeze Agent Knows Your CRM. It Doesn't Remember Its Own Work.

You built the scheduled agent in HubSpot's Agent Builder. It has everything: the Smart CRM with every call, email, and meeting; Growth Context with your team's roles, campaigns, and process rules; a project loaded with instructions, reference files, and memories that persist across conversations.

Then Tuesday morning arrives. The agent emails leads it already emailed Monday. It re-runs enrichment on contacts it enriched last week. It drafts outreach using the expired campaign offer you retired Friday. Your CRM is fully awake, and your agent still acts like last night never happened.

That is not a configuration bug. It is the shape of how HubSpot's AI remembers.

The memory that feels complete

Start with what Breeze genuinely persists, because it beats most platforms:

• Saved memories and previous conversations inside Breeze Assistant. Return next week and it can draw on earlier chats.
• Project context that carries over. Instructions, files, HubSpot records, connected apps, and memories persist across conversations within a project.
• Portal context via Context Home. Business, brand, product, team, and process context managed once, reused everywhere.
• A self-updating CRM. Calls, emails, and meetings are captured as teams work, so the records your agents read keep getting fresher on their own.

Breeze Assistant can even show a Sources section with citations: the records, connected apps, and memories behind a response. That transparency is rare, and it makes the memory feel complete. Ask it a question and it answers like something that has been paying attention.

It has been paying attention. Just not to itself.

The run that starts from facts, not experience

Agent Builder custom agents can now trigger on a schedule. That is exactly where the gap opens. Every scheduled run wakes up, reads the CRM, reads its project, reads its vaults, and acts. What the run cannot do is read what it did and decided during the previous run.

Walk through the nightly lead-scoring agent:

1. Run fires at 2 AM. It reads the lead records.
2. It scores, drafts outreach, updates deals.
3. Run ends.

Night two, the run fires again. The agent sees current records, but not which leads it touched last night or why. Not the Tuesday enrichment API timeouts that forced a manual fallback. Not the Monday subject-line test that switched it to B. Not the expired Friday campaign offer.

The CRM records the outputs: three emails sent, a score updated. The reasoning is gone, so the next run reconstructs the same judgments from scratch, and reconstructions drift. That is how you get duplicate outreach, re-enriched contacts, and the retired offer rising from the dead.

The stale-memory incident pattern

This gap has a nasty second-order form. HubSpot projects retain instructions, reference materials, and memories across conversations: the continuity you want, until a fact underneath changes. An Elite HubSpot partner documented the pattern. A project keeps an old early-access memory, a sales agent combines it with a draft roadmap and a customer request, and the result is a persuasive email promising something unreleased.

Name the mechanism: memory without a lifetime is not continuity. It is a liability wearing continuity's name. Persistent context improves consistency across runs, and it equally preserves an outdated assumption after the campaign, territory, product, or policy changes. If a memory cannot expire, it cannot be trusted.

The fix: a recall-act-record loop

The scheduled agents that survive this gap share one habit. It is not a HubSpot feature. It is a loop:

1. Recall before acting. Open every run by reading what previous runs decided: which leads were touched and why, what failed, what was tried.
2. Act with that context in scope. The agent reasons with its own history alongside the CRM facts.
3. Record after acting. Write back what the run decided, what it tried, what happened, and why. Not to the CRM as customer facts. To a memory store built for the agent's own operational history.
4. Give every memory a lifetime. Campaign offers expire. Enrichment workarounds expire. Tactical notes expire. A memory system that cannot retire items will eventually work against you.

Notes and custom properties can hold some of this, but the CRM is your customer system of record. Packing it with agent operational logs clutters human views, and searching "everything I decided about enrichment failures last week" by meaning is not a CRM job. Run memory belongs in a memory layer, next to the CRM, not inside it.

What the layer looks like in practice

The requirements list is short:

• Available from every tool, not locked inside one project or portal. Your n8n workflow, your Breeze agent, and your assistant should all read the same memory.
• Full conversation history, not just distilled facts. The reasoning behind a decision has to survive with the decision, or the next run replays the mistake with better context.
• Human-readable and inspectable. If you cannot read what the agent recorded, you cannot audit it, and the stale-memory pattern burns you silently.
• Deletable and portable. Expiry on the inside, export and delete on the outside. Remove a single memory, or take everything and leave.

Vilix AI is built for this. Cloud-hosted, so no infrastructure to run: the agent reaches it over MCP like any other tool, and the same memory follows every device and every AI tool. It stores full conversations, not just facts. Free forever, with a 7-day Pro trial that needs no credit card, and full portability: export everything or delete individual memories (or wipe the account) anytime. The honest tradeoff is cloud versus self-hosted: if policy requires on-prem infrastructure, the spreadsheet-and-CRM-notes route fits better.

FAQ

Can a HubSpot custom agent remember its own decisions? Not natively. It re-reads CRM records, project context, and knowledge vaults each run. Decisions and reasoning from the previous run are not stored unless you wire a memory layer.

Does Context Home persist agent runs? No. Context Home holds portal context: business, brand, product, team, process. Shared knowledge, not a record of what an agent did.

How do you stop a scheduled agent from emailing the same leads twice? Give every run a recall step and a record step. Before acting, the agent reads which leads previous runs touched and why. After acting, it writes back what it decided. The CRM holds customer facts; the memory layer holds the agent's own history.

What belongs in agent memory versus the CRM? The CRM gets customer-facing facts: contact details, deal stages, engagement history. Agent memory gets operational history: decisions, attempts, failures, reasoning, tactical notes.

How do you prevent stale memories? Assign lifetimes. Campaign offers expire at the offer's end date. Workarounds expire when the incident closes. Brand principles get an annual review. Expiry should remove the item from default retrieval, not just add a warning nobody reads.

HubSpot's 2026 AI bet is real: shared context makes every agent smarter, and the schedule trigger in Agent Builder puts agents on autopilot. Just do not confuse the CRM's memory with your agent's memory. One knows your business. The other has to be built, one recorded run at a time.