Off-the-Shelf AI Hit a Wall. Here's What HubSpot Did to Solve It.

TL;DR

• Three lessons: (1) flexible infrastructure — build your own harness and a model-swappable abstraction layer; (2) comprehensive and trustworthy context; (3) meet customers where they are.
• They never mandated AI — they brought data. The biggest blocker was engineers worrying that generated code would hurt reliability, so they showed the data: reliability stayed neutral, and today it's actually improving.
• Model choice is a three-way tradeoff, in priority order: quality, latency, cost. Every one of the hundreds of go-to-market tasks they build agents for has a different value proposition across those three — bulk low-stakes work makes cost optimization matter early; high-stakes work (especially anything touching a customer's customer) does not.
• The hard part of context isn't capacity. Beyond context-window limits and context drift there's an overfitting problem: dumping in a lot of context that isn't high quality or specific enough to the task at hand makes results worse.
• A shared platform compounds: "every agent anybody builds makes all agents better," because each one contributes both to overall context and to the platform itself.
• They gave up on keeping customers inside their own UI, integrating deeply into Claude, Gemini and ChatGPT so customers get the full agent platform and context wherever they already work — with full parity against the web/mobile UIs and their own Breeze assistant.

Key Points

Context and the question customers actually ask (~00:52–00:53)

HubSpot just turned 20 last month. They build a go-to-market platform for largely small and medium-sized businesses plus enterprises — software for marketing, sales and service teams across the full go-to-market journey. Over 300,000 businesses in about 140 countries across dozens of industries depend on it, which gives them a wide view of what's actually happening at different scales and in different regions.

The question they hear is defined by one inserted word: "How do I actually transform with AI?" Not run pilots, not play around — deliver real value at scale. Three-plus years in, their finding is that the tools and tool chains are just a starting point; how you approach it makes the difference.

And the unexpected part: they started by asking how to build differently with AI, and most of those learnings turned out to apply to what they needed to build for customers.

Lesson 1: flexible infrastructure (~00:53–00:59)

Where they hit the wall. Around 2023 they moved past code assist into early co-pilots — and off-the-shelf systems couldn't work at their scale: roughly a million builds a day across 10,000+ microservices at the time (more now). The core issue was that models understood coding problems generally but didn't understand enough about their business and how they work. They could wait for the tooling companies to catch up, or dive in themselves. They chose to dive in.

What they built:

• A set of MCP integrations in the very early days of MCP, bringing knowledge of their environment directly into the co-pilots.
• What they'd now call an agent execution platform / agent harness: a containerized approach making it easy to spin up sandboxes where test loops run entirely automated, without human intervention — lightweight for engineers, and safe from both a reliability and a security standpoint.
• No mandate. They deliberately didn't require engineers to use AI; they wanted engineers to see how different and powerful the experience is and adopt it themselves. The big blocker turned out to be reliability concerns — the platform is mission-critical for go-to-market teams and customers, and engineers feared regression. So they brought data, showing from the early adoption areas that reliability stayed neutral. Today, reliability is actually increasing as a result of how they code.
• Result three years ago: about 80% adoption across thousands of engineers, and roughly a 51% improvement in productivity and velocity — deliberately a composite metric, because they don't want to over-rotate on any single one like PRs or lines of code.

What generalized to customers: you can't depend on a single vendor or model family. Models keep improving — it's a bit of a horse race — but more importantly they're jagged across different areas. Applied to something as specific as go-to-market, different models, sizes and vendors win in different places: right tool for the right job.

So they were early to needing evals and A/B tests across models and sizes — and the criterion isn't simply "quality" or an eval score, but a mix of quality, latency and cost, in that order of priority. Each of the hundreds of go-to-market tasks they build agents for weighs those three differently: some are low-stakes bulk processes where the quality bar is still high but cost optimization matters very early; others are high-stakes, particularly when the HubSpot platform is about to do something that interacts with one of their customers' customers.

Hence the abstraction layer — today they'd call it an agent harness, far more sophisticated in 2026 than in 2023. It lets them swap models under the hood, run evals, and do regression tests and comparisons. Crucially it was built so feature teams never touch the plumbing: they create their evals, run them against a variety of models, and swap models in and out without regressions, with no involvement in any of the underlying machinery.

The takeaway: do the shared foundation first, not last. When you're trying to move fast or reach MVP, there's a temptation to use a single stack for everything. Their experience runs counter to that — the energy invested up front in harnesses buys much more control over your own destiny: the ability to run evals, swap models, and change how an agentic loop runs. It's also far easier to do today; he names Fireworks as one of the companies doing great work here.

Lesson 2: comprehensive and trustworthy context (~00:59–01:02)

Moving from co-pilots to autonomous coding agents, the agents needed to understand the codebase, the conventions and the environment — against a decade of homegrown tooling. Here they had to get beyond even MCP, letting coding agents understand everything about how the build chain worked. Most of the effort spent extracting more effectiveness from even frontier models went into backfilling that context.

And getting context right is hard. It's not just hitting a context-window limit or dealing with context drift; there's effectively an overfitting problem — throw in too much context whose quality and task-specificity aren't good and you get poor results. Getting that right turned out to be a skill worth building and a genuinely valuable platform capability.

• Internally (early 2025): 96% of engineers using AI, at a 60% improvement in velocity.
• For customers: across the go-to-market journey there are many different agents — prospecting, customer support and more — and delivering the right context at the right time drives significantly better quality, performance and cost. The sharpest example: an agent that drafts the follow-up outreach email after a sales demo went, in about six months, from a rep needing to edit it about two-thirds of the time to a rep sending it unedited about two-thirds of the time.

His summary: AI knows a lot about the world, but you need a platform that knows your world — and most of that data exists only inside your business, not out in the world and therefore not in the models.

Lesson 3: meet customers where they are (~01:02–01:04)

Internally, this meant shared tools, shared primitives, one shared platform: "every agent anybody builds makes all agents better," because each one contributes both to overall context and to the agent platform itself. Results:

• 100% of engineers using agentic coding to build at HubSpot
• +73% lines of code
• −90% time to first feedback on PRs
• velocity rising while quality — and reliability — rose too

Externally, as a SaaS vendor you'd historically think about how to keep customers inside your own UI. They let go of that entirely. The value to deliver was making the intelligence they build indispensable wherever customers work — so they integrate deeply into Claude, Gemini and ChatGPT, putting the full power of their agent platform and context right where the customer already is. Many customers still choose the web or mobile UIs, or their own Breeze assistant, and they maintain full parity across all of them.

Closing: without the foundational pieces, things plateau. Once they're in place you get compound interest — value that shows up both in how the teams build and in what they can deliver to customers.

Quotes

"AI knows a lot about the world, but you need a platform that knows your world." (~01:01)

The most compressed line of the talk — context engineering stated as a business proposition.

"Do that first, not last." (~00:58)

On the shared foundation (harness, evals, abstraction layer). He's explicit that this cuts against the lean/MVP instinct to use one stack for everything.

"Every agent anybody builds makes all agents better." (~01:02)

Why the shared platform compounds: each agent contributes context and platform capability.

"It's not a matter of just hitting a context window limit or dealing with context drift. It's also the fact that there's effectively an overfitting problem." (~01:00)

The most precise diagnosis of why context engineering is hard: more is not better.