A generic assistant loses to a configured one.

Every serious AI assistant has made the same bet. Claude and ChatGPT have Projects, Gemini has Gems, and HubSpot customers were asking for the same thing: their own instructions, their own context, and control over which tools the assistant was allowed to use.

HubSpot had the pieces, spread across three products.

• Breeze Assistant was the general-purpose chat.
• Custom Assistants let admins build role-specific AI assistants.
• Custom Agents ran automated tasks.

They all overlapped, and there was no clear answer to which one a user should reach for.

Custom Assistants were the closest to what customers wanted but also the hardest to extend. They ran on a separate LLM stack from Breeze Assistant, so the things customers asked for next - memory across conversations, governance and sharing with a team - couldn't be added to them.

One assistant you configure yourself

Breeze Projects put personalisation inside Breeze Assistant itself by holding three things: context the assistant treats as ground truth, instructions for how it should work, and the tools it's allowed to use. Every conversation inside a project inherited all three, and the project remembers what happened in it. Projects can be shared, so a team works from one setup instead of each person rebuilding it and the admin can specify what tools the project needs to use.

I picked up Projects in April 2026 and took the first version to every customer. That version got people creating projects. It didn't get them filling them.

Reading every project

Two weeks after launch I pulled every project created and read what was inside. 86% had no knowledge attached. 34% had no instructions. 35% were empty shells - a name and nothing else. Only 11% had both instructions and context, the state the product was built for.

Users who attached knowledge were about three times less likely to skip instructions and twice as likely to write structured prompts. Context was the leading indicator of a project that worked, and almost nobody was adding it.

The intent was there: 17-21% of populated projects rebuilt the old Custom Assistants pattern by hand - a role, a style, a list of rules.

Solving cold start

V2 attacked the blank page from three sides.

• First, templates. I clustered the projects people were already creating and built the starting points around the largest use cases. Sales work dominated - prospecting alone was 28% of populated projects, pipeline review 14% - so the templates lead with it: move deals forward, follow up and manage tasks, track your pipeline, prep for meetings, prospect, and plan a campaign.

  The v0 placeholder modelled that same role, style and rules pattern, and users copied it. I wrote the templates to current prompting practice instead: task first, no “act as a senior X” persona. Each one has a single worked example, because one input and its expected answer carries more signal than a list of rules. Each points explicitly at the attached context, because that was the behaviour the data said mattered most. Around a fifth of projects were written in languages other than English, so I specced translations from day one.

• Second, the assistant writes the first draft. Describe the project in a sentence and it generates the title and instructions, so nobody starts from an empty box.
• Third, less friction to add context. Files upload straight into a project, and instructions reference CRM records with an @mention instead of pasted text. Both go directly at the 86%.

Sunsetting Custom Assistants

Projects only fixed the fragmentation if Custom Assistants went away. I owned the sunset decision.

Custom Assistants worked for the customers who used them, so the job was to move them without breaking anyone's workflow. I anchored the sunset to a hard external date - the launch that replaced the product surface Custom Assistants lived in - and made the migration tool the critical path. Each assistant's title, instructions and knowledge mapped one-to-one into a project. Existing conversations moved across read-only, so no history was lost.

The rollout ran in stages. Creation closed in mid-June. Customers got an in-product warning with the migration path, and account teams on the highest-usage accounts heard first. Customer-built assistants were batch-migrated in mid-July, and by early August all of them had moved to Projects.

Results

Weekly project chats doubled in the two weeks after V2 shipped. Projects grew from 0.3% to 1.3% of all Breeze Assistant weekly users at its peak. Retention was our goal: people who use a project in a given week are about 60% more likely to come back within 14 days than the average Breeze Assistant user. Within two weeks of sharing launching, 13.5% of new projects were shared with a teammate.