Most people open Agent Hub and go straight for the agents. Switch on the prospecting agent, turn on the customer agent, see what happens. It's the natural instinct, and it's the wrong first move.
Agent Hub has a tab called Context, and it's the tab that determines whether every agent you turn on afterward produces something useful or something generic. The agents are only as good as the context they read. Set the context up well and everything downstream (agents, Breeze chats, agentic workflows) runs off the same solid foundation. Set it up carelessly, or leave it as whatever HubSpot auto-generated, and every agent inherits the same weak base.
We argued in our piece on Agent Hub and the moat that your context is the thing HubSpot can't give you. This is the practical companion to that argument: how to build that context so it's worth something.
The rest of this guide walks through the setup in the order that matters.
When you open Agent Hub and go to the Context tab, you'll find a place to define the business information every agent draws on: your company messaging, your tone, your brand, and your ICPs. Underneath that sit knowledge vaults, which hold more specific information for targeted use cases.
Do this before you activate a single agent. Everything else in Agent Hub reads from the context. If you switch on the deal progression agent before your context is defined, it's working from defaults and guesses. If you define the context first, everything you turn on afterward starts from the same accurate picture of your business.
Think of it as the difference between briefing a new hire properly before their first day and letting them figure out the company from context clues. One produces good work quickly. The other produces confident mistakes for weeks.
HubSpot will populate some of this context for you automatically. That's a helpful starting point and a dangerous stopping point.
Auto-generated context is HubSpot's best guess at your business based on the data in your portal. It's often close enough to look right and wrong enough to matter. It might describe your ICP in generic terms, summarize your messaging in language you'd never use, or miss the distinctions that define how you operate.
Go through everything HubSpot generated and edit it. Not skim it. Edit it. Rewrite the ICP description in your words. Correct the messaging so it matches how you actually talk about what you do. Fix the parts that are technically true but miss the point. The auto-generated version is a draft, and treating it as finished is the most common way this setup goes wrong.
The default fields cover the basics. Custom context is where you capture the things that make your business specific, and it's where most of the real value lives.
Document the how. How you deliver your service or product. How you communicate with a lead versus how you communicate with an existing customer, because those are different motions and an agent needs to know which one it's in. The tone you take, the sequence you follow, the things you always do and the things you never do.
And document the why. This is the part most companies skip, and it's the part that makes context useful. Why you deliver the way you do. Why your process looks the way it looks. An agent that knows the reasoning handles the situations your instructions didn't cover, instead of following rules off a cliff.
Once HubSpot has processed your custom context, it starts making recommendations that speed up the steps below.
There's a temptation to dump everything into one big context file. Resist it.
Your ICP and your products or services should live in separate buckets. The reason is practical: these get used across multiple areas. Your ICP definition feeds answer engine optimization (AEO), prospecting, lead scoring, and more. Your product and service information feeds customer agents, sales enablement, and support. When they're separated cleanly, you can update one without disturbing the other, and you can be sure the same ICP definition is feeding every system that relies on it.
Consistency matters even more than separation. If your ICP is defined one way in your prospecting context and another way in your AEO content, the agents work at cross purposes. Separate buckets, each maintained as a single source of truth, keep everything pointing the same direction.
Knowledge vaults are for depth, not breadth. They store specific information for a targeted use case, and they're best used when a particular agent needs to know a lot about one narrow thing.
The clearest example is a product-specific customer agent. If you have a customer agent whose entire job is handling support for one product, a knowledge vault stocked with that product's documentation, common issues, and resolutions is exactly the right tool. The agent draws on deep, specific knowledge without that information cluttering the general context every other agent reads.
Use the general context for what applies broadly across your business. Use knowledge vaults for what a single agent needs to do one job well. Keeping that distinction clean stops your general context from bloating and keeps each specialized agent sharp.
If there's one custom context document worth investing real time in, it's your sales methodology. This is where you write down how your team actually sells, and it feeds nearly everything on the sales side of Agent Hub.
A useful sales methodology document covers your sales process end to end: how you run discovery, what you're listening for on calls, the terms and signals you track in conversations, your pipeline and deal stage progression, and your contracting requirements. It should also capture how all of that varies across products, services, and ICPs, because a single motion rarely fits every deal you run.
This is the document that lets the deal progression agent make recommendations that fit your process instead of a generic one. It also tells a follow-up workflow what matters in your sales conversations. Write it as if you were onboarding a sharp new sales hire who needs the steps and the judgment behind them.
Here's a sample sales methodology you can use and adapt to your business:
Replace anything in brackets with your own details.
How we sell - We sell [what you sell] to [who you sell to]. We understand the problem before we propose anything, and we only propose what the buyer can take on.
Discovery - Buyers arrive with a solution in mind, and the request is rarely the whole problem. Before scoping, record the business problem, the outcome they want, who owns it on their side, and their constraints. Ask what literally happens today, step by step and in which tool. The gap between how a process is described and how it actually runs is usually where the real need sits.
What we listen for - A deadline with a date attached and a named owner are good signs. A buyer who only talks about tools, or an executive sponsor who won't use or review what we deliver, is an adoption risk we name in the proposal. Terms we track: competitor names, any deadline or event, budget language ("approved," "next quarter," "need to check with finance"), and mentions of a second phase.
Stages - Discovery booked, Problem framed, Scoped, Proposal sent, Contracting, Closed won or lost. A deal moves forward only when the buyer has confirmed the step: problem agreed, recommendation reviewed, decision maker named, terms accepted. Lost deals need a reason. A stage records what has already happened, so anyone reading the pipeline sees the same thing.
Deal hygiene - Every open deal has a dated next step, including what the buyer owes us, because untracked buyer commitments quietly disappear. No buyer activity for [14 days] means the deal is stalled, whatever stage it shows. A buyer commitment that slips twice means it's time to ask whether the deal is still real.
Scope - Propose the smallest version that solves the problem, and show what comes after it. A smaller deal that gets used is worth more than a bigger one that stalls after signature. Anything beyond scope gets priced.
Contracting - Work starts only once [your requirements: signed agreement, statement of work, payment terms] are in place. Non-standard terms need approval from [name] before they're offered. Before closed won, record what was promised and the start date, so delivery starts from the same picture sales sold.
How it varies - [Smaller offer] deals can run discovery and scoping on one call. [Larger engagements] need a second call with the executive sponsor. For [secondary customer type], find the person who actually signs during discovery.
The context files you build here power more than the Context tab. Your agents, Breeze, and your agentic workflows can all reference them. Build the foundation once, correctly, and everything you set up afterward draws from the same source of truth.
An agent activated on top of weak or auto-generated context produces weak output, and you end up debugging individual agents when the real problem is the foundation underneath all of them. Get the context right first, and everything built on it inherits that quality.
All of this rests on one assumption: the data and processes underneath Agent Hub are in reasonable shape. Context files describe how your business operates, and that only works if your business actually operates the way you're describing.
If your deal stages don't reflect how you really sell, no amount of context-writing fixes the agent reading those stages. If your CRM data is unreliable, the agents reading it produce unreliable output regardless of how well you filled in the Context tab. We wrote about that underlying problem in Your CRM data is lying to you. Setting up Agent Hub well and getting your operational foundation in order are two layers of the same job.
If you're not sure whether your foundation is ready to build on, or you want help setting up your Agent Hub context so it reflects how your business runs, that's the kind of thing a strategy call sorts out fast.