The GSP ARMS RACE Framework: How to Build AI in B2B Sales the Right Way
The GSP ARMS RACE framework helps B2B sales organizations build AI solutions that employees adopt and that scale beyond the pilot by combining four design pillars with four integrated architecture layers.
Last updated August 30, 2026
The GSP ARMS RACE framework is a practical model for implementing AI in B2B sales. It pairs four design pillars — Adoption-Led, Reuse Before Rebuild, Modular by Design, and Scalable by Default (ARMS) — with four architecture layers — Resource, Automation, Coordination, and Experience (RACE). ARMS covers the principles that should shape every decision; RACE covers the structure of what you build. Together, they determine whether an AI in sales initiative delivers durable value or stalls after the pilot.
Many projects underdeliver because of how organizations approach implementation. MIT's 2025 GenAI Divide study(opens in new tab) found that 95% of organizations investing in enterprise generative AI see little to no measurable impact on the bottom line, and that the divide "does not seem to be driven by model quality" but by how the tools are integrated into people's actual workflows.
Typical failure modes include:
- Pilots that work well enough as demonstrations but can't be scaled without starting again.
- Agents that optimize for the wrong thing because nobody connected them to what the sales team actually needs.
- A system that works well in theory, but reps stopped trusting after a few bad outputs.
- Data challenges that were either ignored or genuinely missed
- An end product that the people who commissioned it can't fully explain or fix when something goes wrong.
GSP developed the ARMS RACE framework to provide principles and architectural decisions that prevent these failures.
The ARMS RACE Framework at a Glance
The technology matters. But whether people use it, whether the parts work together, and whether it can scale are design decisions. That’s what ARMS RACE is for.
The framework contains 4 Design Pillars and 4 Architecture Pillars:
The four Design Pillars (ARMS) are the principles that should be visible in every decision:
| A — Adoption-Led | Build for the people who have to use it. Surface outputs where reps already work, keep humans in the loop on high-stakes calls, and give every agent a clearly defined job. |
| R — Reuse Before Rebuild | If something already works, extend it rather than replace it. Reserve AI for unstructured data, probabilistic judgment, and personalization; use deterministic code for everything else. |
| M — Modular by Design | Favor small, single-job agents with clear inputs, outputs, and guardrails. Grow the system by adding agents, never by bloating existing ones. |
| S — Scalable by Default | Build the pilot with the full-scale architecture in mind. Define success metrics before building, and coordinate across pilots from the start. |
The four Architecture Layers (RACE) define how the solution is built, each layer dependent on the one below it:
| R — Resource Layer | The data and existing functionality on which the system is built: CRM, ERP, transcripts, and both structured and unstructured data. |
| A — Automation Layer | The agents, code, and workflows that perform specific, measurable tasks with defined inputs and outputs. |
| C — Coordination Layer | The orchestration agent decides what runs when and weighs the other agents' output together. |
| E — Experience Layer | Where humans meet the system: AI outputs surfaced inside the tools salespeople already use, in a form they can act on. |
The Four Design Pillars – ARMS
The Design Pillars are principles to apply in every decision made throughout the project, from the first workshop with the sales team to the final configuration of the experience layer.
A — Adoption-Led
Adoption-led design means building for the people who have to use the system, because an AI solution that nobody uses delivers nothing, regardless of how elegant it is.
Adoption-led starts with fitting into existing systems rather than asking reps to adopt new ones.
For instance, a sales rep shouldn't have to log in to a new system, learn a new interface, or change how they work to engage with an AI agent. They should see the output where they're already working — inside the CRM or sales automation tool they open every morning.
Every extra step between a rep and an AI recommendation increases friction and lowers adoption.
Beyond that, adoption-led design is deliberate about what AI should decide on its own:
- Route high-stakes decisions through a person — an unusual pricing call, an exception to standard contract terms, anything where getting it wrong has significant consequences.
- Have agents show how they work, not just their outputs. Reps ignore recommendations without context.
- Make agents defer when uncertain. Agents that confidently produce incorrect answers, even when they don't have enough data, destroy trust.
- Limit each agent's access to only the data and systems it needs. For security, but also not to overload agents with excessive and irrelevant data that could skew the outputs.
- Embed human feedback into the solution so that it continuously learns and improves.
In practice: Before building any agent, define how its output will be displayed to the salesperson, what context will accompany it, and how the salesperson will be able to give feedback on it.
R — Reuse Before Rebuild
Reuse Before Rebuild means that if something already works, you don't rebuild it. Significant technology projects tempt you to build from scratch, and AI implementations are particularly susceptible to it, because the technology feels new enough that existing tools and workflows can seem inadequate by comparison.
Before reaching for machine learning or generative AI, ask whether the job can be done with standard code and fixed logic. Or with existing workflow automation capabilities that many CRM platforms like Salesforce already offer.
Save AI for the work that genuinely needs it: processing unstructured data, weighing probabilities, and tailoring outputs to individual customers or employees.
Using a large language model to do something that a simple workflow could handle is expensive and harder to audit.
| Use it when | The rule is known and stable, and the same input should always produce the same output | The task needs judgment, handles unstructured input, or personalizes to the individual |
| Best suited to | Structured data, fixed logic, repeatable steps | Unstructured data, probabilistic judgments, personalized outputs |
| Cost | Low — standard code, no per-run charges | Higher — many vendors charge per agent run |
| Explainability | Fully auditable; behavior is predictable | Harder to audit; needs accompanying context and a confidence signal |
| Examples in sales | Routing a lead by fixed territory rules, flagging an overdue invoice, updating a CRM field | Summarizing a call transcript, mining service tickets for upsell signals, drafting a personalized recommendation |
Recreating something that already works has three predictable costs: the engineering hours to build it, the ongoing bill to run it, and inconsistent outputs that nobody can easily explain.
That means when you implement AI agents, they should trigger existing workflows and build on data models that already do the job, rather than set up parallel versions.
In practice: Before scoping any new AI agent, audit what the existing system already does. The agent should be an extension of what works, not a parallel track that competes with it.
M — Modular by Design
Modular by Design means using small, purpose-built agents. Large agents are difficult to build, troubleshoot, and improve, and when something goes wrong — as it always does — finding the source of the problem inside a monolithic agent is a significant undertaking.
Small, purpose-built agents, each with a clearly defined input, output, and set of guardrails, are far easier to manage.
Modular design also makes it easier to understand what each part of the system contributes. If an agent reviewing service ticket transcripts is generating high-quality leads, you can see that. If another agent is consistently producing outputs that the sales team ignores, you can see that too and fix or replace it without dismantling everything around it.
This means apply the following scaling logic recommendations:
- Grow capability by adding new agents, not by widening the focus of an existing one.
- Reuse an agent wherever the same capability is needed across multiple solutions, rather than rebuilding it.
- Let a single orchestration agent coordinate the others — the job of the Coordination Layer described below, not something each agent handles on its own.
This approach requires governance.
Without a coordinated view of what agents exist and what they do, organizations find themselves managing a sprawling estate of overlapping, redundant agents that nobody fully understands.
A lightweight central register of all agents and their actions helps solve the problem.
In practice: If an agent seems to be taking on multiple distinct responsibilities, break it down into two or more agents with a coordination layer above them.
S — Scalable by Default
Scalable by Default means designing the system around where it's ultimately headed, even when today's scope is narrow.
AI projects often start without anyone agreeing on what success looks like. This poses the risk of building agents that consume resources but deliver little value.
So before you start building, define your objectives by answering these simple questions:
- What is this agent supposed to do?
- How will we know if it's working?
- What does failure look like, and at what point do we intervene?
When you run the agent, track performance against your targets, and continuously feed results back into the agent. Agent actions are logged and auditable, which means you have the data to do this.
Scalable by default also means coordinating across pilots from the start, so that what begins as a series of small experiments can eventually be assembled into something coherent and enterprise-wide, rather than a collection of things that work individually and can't be connected.
In larger organizations, it's harder to coordinate pilots across teams and business units, and pilots often run in isolation, making this pillar harder to implement.
In practice: Before any pilot launches, ask what the full-scale version should look like and if the architecture you're building now will get you there.
The Four Architecture Layers — RACE
AI implementations rarely become reliable, adopted, and scalable by accident. Those qualities have to be designed in. The RACE gives your AI implementation its structure.
R — Resource Layer
The Resource Layer is the data and existing functionality on which the rest of the system stands. It includes the CRM, ERP, finance systems, business intelligence tools, email platforms, telephony systems, call transcripts, and any other data sources relevant to the sales process.
In some cases, it will also include new infrastructure created specifically to support the AI project. For instance, a data lake that pulls together information from systems that don't naturally connect.
Two things to note about this layer:
Data quality problems live here.
- These problems need to be addressed before agents start producing outputs. In a February 2025 analysis, Gartner predicted that through 2026, organizations will abandon 60% of AI projects that aren't supported by AI-ready data.
- Most organizations know their data contains gaps, duplicates, and inconsistencies across systems. The project team should determine which of those problems actually matter for the specific use cases being built. Aim for the minimum viable clean-up needed to make the agents functional.
Use both structured and unstructured data.
- Structured data — opportunity records, contract values, renewal dates, product holdings — is the obvious starting point. But unstructured data — call transcripts, email threads, meeting notes, support ticket free-text — often contains the richest signals.
A CRM field tells you an opportunity was lost. A call transcript tells you it was lost because pricing concerns surfaced in week three, concerns that nobody addressed.
In practice: Map the Resource Layer before designing any agents. Make sure you know what data exists, where it lives, what condition it's in, and what work is needed to make it usable.
A — Automation Layer
At the Automation Layer, agents and scripts take defined inputs and return defined, measurable outputs. Every agent is scoped for a single job and, wherever possible, sits on top of tooling you already run.
Most of the visible AI capability lives here, which means most of the design work does too. That's defining what each agent does and doesn't do, what data it pulls from, what it produces, and when it hands off to a human or escalates to the coordination layer.
This is where the Modular by Design pillar really earns its keep: each agent should do one thing well. It's tempting to build a single agent that reviews service tickets, checks warranty status, and spots upsell potential all in one go — but that makes every one of those jobs harder to do well, and much harder to troubleshoot when something breaks.
In practice: For each agent in the Automation Layer, write a one-sentence description of what it does. If you can't do that, the agent's scope is too broad.
C — Coordination Layer
The Coordination Layer manages interactions between individual agents and transforms them into a system that reasons across the whole account picture. The coordination or orchestration agent decides the order, distributes work to agents, and reconciles their outputs before taking action.
It also preserves institutional knowledge. Individual agents in the Automation Layer generate discrete insights about a customer, an opportunity, or a situation. The Coordination Layer takes those insights, weighs them together, and determines what to do with them.
Leave it out, and each agent optimizes for its own narrow goal — which is how you end up pitching a cross-sell to a customer with an open service complaint or sending a pricing proposal while an invoice is badly overdue.
At our Atlanta manufacturing client, the coordination agent runs nightly across all customers' Insights. It only creates and routes an opportunity when the signals genuinely point to cross-sell or upsell room — not when there's churn risk or the account health looks shaky.
In practice: Plan the Coordination Layer from the beginning, even if you're only running two or three agents initially. The architecture is much easier to create at the outset than to retrofit.
E — Experience Layer
The Experience Layer is about how the system's output reaches a salesperson in a form they can act on. So, that's where the Adoption-Led principle is most visible, and that's what affects how the sales team judges the AI implementation.
In practice, it means:
- Displaying recommendations inside the CRM record, and not in a separate dashboard.
- Providing enough context for each recommendation so salespeople understand the rationale and the confidence level behind it.
- Enabling a feedback mechanism that lets reps tell the system it's wrong, which informs future agent improvement.
A large language model can enhance the layer by improving readability and rewriting agent output into natural, easy-to-act-on text. This makes the output feel like a knowledgeable colleague flagging something worth looking at, not a system-generated alert.
With our manufacturing client, we built the Experience Layer inside Salesforce using custom Lightning Web Components, visible on the same screens salespeople already use every day.
Before we built any of that, the team prototyped the interface in Figma, so they could test and refine how insights are presented without committing development time.
That step turned out to be more valuable than expected: several design assumptions that seemed obvious on paper didn't hold up when put to salespeople who had to use the interface.
In practice: Pay equal attention to the Experience Layer as to the agent design — or more. Ideally, prototype and test it with real users before you write the code or build the agents.
How ARMS RACE Addresses the Common Failure Modes
The ARMS RACE framework is a direct response to the common AI failure modes we covered in Why AI in Sales Goes Wrong:
| Low adoption, reps don't use the system | Adoption-Led pillar + Experience Layer |
| Generic outputs that experienced reps dismiss | Modular by Design + Coordination Layer context |
| Pilots that can't scale | Scalable by Default + modular architecture |
| Data quality blocks implementation | Resource Layer mapped and addressed upfront |
| Agent sprawl, nobody knows what exists | Modular by Design + central register |
| Agents optimizing in isolation | Coordination Layer |
| Trust lost to spurious outputs | Adoption-Led pillar + human-in-the-loop design |
We built the framework by watching implementations succeed and fail, and by identifying which early decisions determined whether a pilot became something the business relied on.
ARMS RACE in Action: An Atlanta Manufacturing Case Study
The manufacturing client case study we describe in the full guide is the most concrete illustration of the framework in practice.
Here’s how it applies in RACE terms:
- Resource Layer: Salesforce CRM data — customers, assets, warranties, service tickets, product holdings — plus a planned extension into Navision ERP for payment history
- Automation Layer: Individual purpose-built agents — one reviewing asset and warranty data for coverage gaps, one reviewing service ticket transcripts, one identifying license upsell potential.
- Coordination Layer: A nightly orchestration agent that reviews all Insights about each customer and determines whether an opportunity should be created, and if so, routes it to the right salesperson.
- Experience Layer: Custom Lightning Web Components inside Salesforce, prototyped in Figma before build, surfacing Insights and opportunities directly in the screens salespeople already use.
In ARMS terms, the implementation was
- Adoption-led from the start: outputs surface inside Salesforce, humans review every opportunity before it's acted on.
- Reuse-first: it extended the existing Salesforce infrastructure rather than rebuilding it
- Modular from the first agent: each agent does one thing, all outputs flow into a shared Insights object.
- Scalable by default: the Insights architecture means new agents from any team slot into the same pattern.
The result, in the first six months of the rollout: 76 agent-generated opportunities, 29 won, and $450,000 of incremental revenue.
Where Does This Leave You?
The ARMS RACE framework is a set of decisions and actions you can take right now, on a current or planned implementation, that will determine whether what you build delivers lasting value.
The starting point is an honest assessment of where you are.
The answers point clearly to where the real work needs to happen:
- If you're in the early stages, are you building your first agent with the final architecture in mind, or designing something that works for now but will need to be rebuilt when you want to go further?
- If you already have agents running, do you have visibility into how each one is performing individually, or are you only measuring the overall outcome? And do you have a coordination layer, or are your agents operating independently?
- If adoption has been a problem, is it because the outputs aren't good enough, or because the Experience Layer isn't displaying them where and how salespeople work?
The organizations that get the most from AI in sales made better design decisions earlier, and then had the discipline to stick to them as the implementation progressed. ARMS RACE is a framework for making those decisions deliberately rather than by accident.
If you'd like to talk through how the framework applies to your specific situation — whether you're starting from scratch, trying to scale something that's already running, or working out why an implementation hasn't delivered what you hoped — we'd welcome the conversation.
ARMS RACE Framework FAQs
87% of sales leaders report a top-down push from CEOs and boards to implement generative AI. A lot of these projects start under that kind of pressure rather than from genuine readiness, and the question hiding underneath is usually how to move fast without burning through the budget.
A good starting point for any AI in Sales project is the TSAR framework. This framework defines the level of benefit you're aiming for, which dictates scope, technology, and timeline before anything else.
Many companies then use the ARMS RACE framework to drive the actual implementation.
ARMS breaks down into four principles. The first, adoption-led, is about putting AI outputs inside the tools reps already use (e.g., the sales automation system) instead of asking them to learn something new, and keeping a person in the loop wherever the stakes are high. Reuse before rebuild means extending what's already working in your existing systems rather than using AI tools to start from scratch. Modular by design means small, purpose-built agents that each handle one job well, rather than a single sprawling agent that nobody can untangle once it breaks. And scalable by default refers to building the first agent with the full-scale version already in mind, so what starts as a pilot doesn't end up being thrown away.
The RACE part of the framework describes the four layers on which everything else sits. At the top is the Resource Layer, your CRM, your ERP, whatever data actually feeds the system. Below that sits the Automation Layer, the agents or workflows themselves, each with one defined, measurable job to do. The Coordination Layer comes next, weighing up what different agents produce before anything gets acted on. And at the bottom is the Experience Layer, where all of it finally reaches your sales team, wrapped in enough context that they trust what they're looking at.
TSAR, ARMS RACE, and our 10 Best Practices together turn a top-down mandate into a project with actual milestones, not something you're doing just to be seen doing it.
- AI in Sales: A Complete Guide for Sales Leaders — The full pillar guide
- The Four Levels of AI Benefit: The TSAR Framework — A deeper look at Table Stakes, Solutions, Automation, and Reimagine
- Why AI in Sales Goes Wrong (and What To Do Instead) — The failure modes at each level of the TSAR framework
- Best Practices for Implementing AI in Sales — Ten recommendations drawn from real implementations
- What AI Means for Your Sales Team — Role design, headcount, reward, and the future of the B2B salesperson
