When MCP isn't enough: How AmpUp scaled GTM integrations from 10 to 50 and deleted 200,000 lines of code

(co-byline with Amit Prakash, Co-founder of AmpUp)

TL;DR:

• AmpUp is an AI sales coaching platform that reads from Gong, Salesforce, Gmail, Google Calendar, and the rest of the GTM stack, runs analysis across that data, and writes coaching insights back into the CRM.
• They started in early 2025 with MCP via Composio handling about 10 source integrations. The setup was clean for the first wave of customers, then started bending in three predictable ways as the product scaled.
• Moving to Ampersand gave them two access patterns over the same connectors: MCP for chat-shaped workflows, continuous pull for analytical ones, with multi-tenancy and field mapping handled in one place.
• Net result: roughly 200,000 lines of integration code retired, and an engineering team back on coaching features instead of patching pagination bugs.

If you have read MCP for agentic SaaS: the missing plumbing, not the whole house, you already know our position on the protocol. MCP is foundational. It is also, on its own, not enough to ship an agentic product into production. AmpUp's story is the cleanest version of that argument we have seen from a customer in 2025 and 2026, so we asked their co-founder Amit Prakash to walk us through what they built, what broke, and what changed.

1. The starting point: MCP was the right first bet

AmpUp is an AI sales coaching platform. Their product reads from CRMs, call recorders, calendars, and email, runs analysis across that data, and writes coaching insights back. To do all of that, they needed integrations, and they needed them fast.

In early 2025 the team picked MCP via Composio and went live with around 10 sources: Gong, Salesforce, Gmail, Google Calendar, plus a handful of others customers asked for. For a small engineering team trying to validate a product, MCP plus a gateway was the cleanest answer on the market. One protocol, a registry of tools, a chat-shaped interface their LLMs already understood. They shipped in these connectors in a couple of days.

With this initial quick launch, MPC began to look like it solved the full integration story, but the cracks showed up the moment AmpUp scaled past the first wave of customers and started seeing the real shape of the workload.

2. Where MCP started bending out of shape

Three problems hit AmpUp at once. None of them are MCP's fault. They are the same problems we have been writing about for a year on this blog: MCP is plumbing, not a building. AmpUp had to learn that the expensive way.

2.1 Auth fragmentation across providers

Every provider in their stack had its own auth model. Some used static API keys. Some used OAuth 2.0 with refresh tokens that rotated on different schedules. Some used custom auth schemes that fit neither pattern. On top of that, each provider exposed a different surface area of MCP tools, and AmpUp had to make per-customer decisions about which tools to enable or disable based on each customer's actual permissions and use case. At 10 connectors that is a non-trivial config matrix. At 50, which is where AmpUp's roadmap was clearly heading, it becomes a config matrix nobody on the team wants to own.

2.2 Calls that didn't belong in chat

MCP is brilliant when the question lives inside an LLM conversation. "What's the status of deal X?" maps cleanly to a tool call. The model decides what to ask, the server answers, the response streams back into the chat. Not every tool call AmpUp needed to make was chat-shaped. They had backend jobs that needed to read Slack messages on a schedule. They had analytics pipelines that needed to pull CRM state in bulk. Neither workload starts with an LLM deciding to invoke a tool. They start with backend infrastructure deciding to fetch data.

Forcing those calls through MCP felt wrong. So AmpUp did what teams in their position do: they pulled in slack-sdk directly to read Slack messages, then a different SDK for another non-chat workload, then another. Within a few sprints they had two integration layers, MCP and a parallel set of vendor SDKs, doing overlapping jobs and drifting out of sync.

2.3 The analytical workload MCP was never designed for

This was the deal-breaker.

A meaningful chunk of AmpUp's product is analytical, not transactional. To surface deal risk for a CRO or extract objection patterns for a sales enablement lead, the system doesn't run a single tool call. It runs analysis over hundreds of meeting transcripts, cross-referenced with CRM state, going back months. The shape of that workload is not "fetch one record, decide what to do." It is "read everything, find the patterns."

MCP makes you do that record by record. Each fetch is a separate request. Each request hits a rate limit. Each request burns tokens to send schema and context back into the model. Past the demo questions, the real ones get expensive in three currencies at once: API quotas, model tokens, and wall-clock latency.

"Demo questions worked great. The questions our customers actually pay us to answer started taking minutes instead of seconds, and our token bill started looking like a problem." -- Rahul Balakavi, Co-founder, AmpUp

3. The shape of analysis a sales coaching product actually runs

Before getting to what changed, it is worth being precise about what AmpUp's product needs from its integration layer. This is the part most "AI for sales" products gloss over, and it matters for the architectural argument.

A typical AmpUp coaching workflow looks like:

1. Pull every transcript and meeting summary across the deal, often spanning 40 to 80 documents per opportunity.
2. Pull the CRM record for the deal, the account, the stakeholder map, and the activity history.
3. Pull adjacent deal data from comparable accounts to surface what worked when, and what didn't.
4. Run pattern recognition across all of it.
5. Write the resulting coaching insight, deal risk score, or objection pattern back to the CRM.

Steps 1 through 3 are bulk reads. Step 5 is a write. Step 4, the pattern recognition, is where AmpUp's LLM and scoring models do the work.

MCP is the right transport for step 5 and for chat-shaped lookups inside step 4. It is the wrong transport for steps 1 through 3. AmpUp needed both, in the same product, talking to the same set of provider connectors.

4. The architectural shift: MCP plus continuous pull

This is where Ampersand changed the shape of AmpUp's stack.

Ampersand gave AmpUp two access patterns over the same set of 150-plus connectors. MCP for the tool-call workflows, where chat-shaped fetches and writes belong. Continuous pull for the analytical workloads, where AmpUp wants field-perfect data flowing into its own systems on a schedule, ready to query at the speed of its own infrastructure rather than the provider's API.

Same vendor, same auth single source of auth management, same multi-tenancy layer translating between provider schemas and AmpUp's internal data model. Two ways to get at the data, both production-grade.

AmpUp wrote about the pull side of this on their own engineering blog, in Why We Pull Data Instead of Querying It: Ampersand, MCP, and the CRM Enrichment Trap. The short version: for analytical workloads that span more data than any single context window can hold, pulling continuously and querying locally beats querying remotely on every request. By a lot.

The longer version is that AmpUp now uses both patterns daily, in the same product, against the same connectors. Pre-call brief generation pulls from their local mirror. Real-time CRM writes go through MCP. They never had to choose between the two.

5. The translation layer: where multi-tenancy earns its keep

Here is the part of Ampersand's pitch that does not show up in a 30-second demo but matters more than anything else for an agentic GTM company shipping to enterprise customers.

Every customer's CRM is a different CRM. The same is true for every other system in the GTM stack.

A concrete example from AmpUp's connector set. Gong and Granola both expose meeting data, and both are valuable to AmpUp because their customers use both. The shape of that data on the wire is completely different. Gong organizes around "calls" with detailed speaker diarization, snippets, trackers, and a deep object model around opportunities. Granola organizes around "notes," with a leaner shape that leans on summaries and structured note-taking. Field names differ. Pagination differs. Rate limits differ. Auth models differ.

AmpUp's internal data model has one concept of "meeting" with one schema. Their coaching engine should not have to ask "is this a Gong call or a Granola note?" every time it processes a transcript. It should ask "what did the rep say in the discovery section of this meeting?" and get the answer back the same way regardless of source.

Ampersand's field mapping layer does exactly that translation, per customer, per provider, automatically. When a customer connects Gong, Ampersand maps the Gong object model to AmpUp's internal meeting schema. When the same customer also connects Granola, Ampersand maps that to the same internal schema. AmpUp's downstream code talks to one model. The complexity sits where it belongs, in the integration layer, not in the coaching logic.

Everything in the left column was code AmpUp wrote, owned, debugged, and maintained. Everything in the right column is code AmpUp no longer writes.

6. The 200,000-line cleanup

Before the migration, AmpUp's integration layer had grown into the largest module in their codebase. Provider-specific clients. Custom auth handlers. Field mappers per customer. Pagination cursors. Retry queues. A schema translation layer between every external system and their internal model. None of it was bad code. All of it was code that didn't make their product better. It just kept the product working.

After the migration, AmpUp measured what they had retired. The number came in at roughly 200,000 lines.

"We deleted close to 200,000 lines of code. That's not a refactor. That's a category of work we don't have to do anymore. Our engineering team builds coaching features now, not integration plumbing." -- Amit Prakash, Co-founder, AmpUpAmit Prakash, Co-founder, AmpUp

7. What this means if you're building agentic GTM and some takeaways

The AmpUp story is specific, but the lessons can be generalized across industry and is a frequent story we hear. A few takeaways for any team building an agentic product on top of customer GTM data.

MCP is the right starting point. It is not the whole answer. The protocol is excellent at what it does. It is also, by design, narrow. Plan for the 30 percent of your workloads that will not fit a tool-call shape, and have a story for those before they hit production.

Multi-tenancy is the big kahuna. Demoing on a clean tenant is easy. Shipping to your tenth enterprise customer with their renamed objects, custom fields, and field-level permissions is the actual job. The team that owns that translation layer for you is doing more work than is visible from the outside. Pick a vendor that exposes primitives, not pre-canned actions. Pre-canned IPaaS-style MCP servers wrap a fixed set of verbs over a fixed set of objects. That works until your product needs to do something the wrappers did not anticipate, which for any non-trivial agentic product is week three.

Time saved on integrations is time spent on the thing customers actually pay for. This is obvious in retrospect and hard to feel in the moment. The week AmpUp deleted their HubSpot client and let Ampersand handle it, they shipped a coaching feature they had been promising customers for a quarter. The opportunity cost of building integrations is lost on the time you could spend building a product your users love.

8. Where AmpUp goes from here

AmpUp is scaling its connector footprint across more verticals, more call recorders, and deeper integrations into outreach and revenue intelligence tools. None of that roadmap is possible if they are still hand-rolling integration code per provider per customer.

If you want to see what AmpUp's coaching product looks like on top of all this, their site walks through the platform and you can book a demo directly, and if you are working through your own version of the integration architectural choice, grab some time with one of the Ampersand engineers.