HubSpot

Why Bolted-On AI Chats Kill Your B2B Deals Modern B2B selling faces an uncomfortable reality: by the time a buyer visits your website, they have already made their decision. They use generative AI platforms to research, compare, and shortlist vendors in a virtual black box. According to research from Forrester Research, 94% of buyers use generative AI as a primary research tool. When these late-stage buyers finally land on a homepage, the standard "How can I help you?" chat prompt pushes them backward. It is a slow, frustrating step. Sajjan Kanukolanu, VP of Global Operations and Strategy at Position Squared, argues that the industry's biggest mistake is simply bolting AI models onto dusty, legacy marketing stacks. True automation requires a systemic redesign that solves AI orchestration, pipeline integration, and core software architecture simultaneously. Without this ground-up overhaul, engineering teams build nothing more than expensive, generic chatbots. They fail to scale. The Three-Layered Architecture Behind Smart GTM Rather than relying on isolated chat interfaces, modern Go-To-Market (GTM) software systems need a structured, three-layer data pipeline. Signals: Capturing Contextual Activity The foundation relies on ingesting real-time data from CRMs, website visits, and social platforms like LinkedIn. Tracking social signals, such as executive sponsor job changes, allows systems to identify when champions move to target accounts, signaling a high-priority outreach window. Many companies miss this completely. Buyer Intelligence: Quantifying the Fit The middle layer contextualizes raw signals. A central knowledge base stores the Ideal Customer Profile (ICP) definitions, buyer personas, and operational playbooks. A context builder assembles these nodes into a unified context graph, linking individual actions directly to company accounts. This step distinguishes casual researchers from active, high-intent buyers. Action: Executing Targeted Workflows The final layer initiates personalized experiences. Instead of asking for a visitor's name, the system references the context graph to continue past discussions or serve tailored assets. Simultaneously, the system triggers outreach sequences and updates CRM records with deep behavioral context. Inside the Connected Multi-Agent Pipeline At Position Squared, this system functions through a sequence of specialized, asynchronous agents. This pipeline must operate smoothly under load. When an anonymous user lands on the site, an identification agent runs multiple parallel tracking tools to de-anonymize the visitor. Because no single service captures every footprint, consolidating these signals maximizes coverage. Once identified, an enrichment agent populates the profile with firmographic data. Next, the ICP filter agent references the knowledge base to strip away unqualified visitors—such as wrong geographies or off-target industries. Qualified records flow to a match agent, which checks HubSpot or other CRMs to determine the buyer's current stage. Finally, an action agent decides the next step, whether triggering a Slack alert to the sales representative with a drafted response or launching a direct LinkedIn campaign. Four Architectural Breakpoints to Watch Designing this system reveals several critical failure points that developers must address: 1. **ICP Drift:** Buyer profiles evolve. If companies do not retrain their models quarterly using closed-won and closed-lost data, agents continue targeting outdated audiences. 2. **Alert Fatigue:** Bombarding sales reps with "hot lead" notifications destroys trust. The system must use the context graph to strictly filter out low-value activity. 3. **The Identity Ceiling:** Web identification systems hit structural limits. While company de-anonymization approaches 70% accuracy, individual identification hovering around 15% to 20% remains standard. 4. **The Human Bottleneck:** Sales reps will ignore drafts if reviewing AI-generated emails takes longer than 30 seconds. Teams must reduce the friction to a one-click review process. Rebuilding the Sales Flywheel To make these systems succeed, developers must design policy engines that non-technical teams can audit and adjust without writing custom code. Every interaction, win, and lost deal must feed back into the central knowledge base, creating a compounding data flywheel.