The GTM Context Layer—One Operating Truth, Every Agent

Julia Nimchinski:

And next up, please welcome Deepinder Singh Dhingra, founder and CEO of RevSure AI. Deepinder, great to have you back, how have you been?

Deepinder Singh Dhingra:

I’ve been doing great. Thank you, Julia, for having us back.

Julia Nimchinski:

Our pleasure. Welcome, team.

Deepinder Singh Dhingra:

I’m joined by Tejas and Shubh, who’s part of our team. Tejas is a GTM engineer in our team, and we’re going to be demonstrating how to use a unified infrastructure for Agentic GTM, and Shubh is an AI agent engineer in our team, and together, we’ll be talking about the Agentic Harness. I’ll go to my desk.

Julia Nimchinski:

Let’s get into it.

Deepinder Singh Dhingra:

Perfect. So, what I thought, for today’s session is we’ll kind of take you through our thinking and our findings and our active learnings around what it takes to make Agentic go-to-market successful. What are the critical success factors? We all have known the perils of trying to drive Agentic go-to-market. Like, we see rogue agents sending… emails to existing customers, we see an SDR agent trying to reach out to a customer that might have already visited a trade show and asked for a demo already, right? And we see all of these instances, and we wonder why. And the reason is that we’ve been VIP coding agents, whether that is on Claude or ChatGPT or any one of our other favorite agent tools.

We’ve been wipe-coating those agents without the right Agentic harness. What ends up happening when we kind of do this VIP coding, or we try to deploy Agentic AI on top of current GTM stack, it only amplifies the chaos. Right? Because the GTA motion is pretty fragmented across all of these disconnected tools, messy data, multiple buyer handoffs, which leads to a lot of context loss, and we know AI is only as good as the context. All of the tools that you see here right, are… amazing tools in and of themselves, but they were never built for the error of agents, and they only have data which is siloed to their purpose.

So what ends up happening when an… as an example, my favorite example, is when an SDR agent calls on a customer. without realizing that the customer was already a prospect, without realizing that the customer was already an existing customer, customers get surprised, hey, why are you reaching out? I’m already using your product. Or, if an SDR agent reaches out to a prospect, asking for a demo meeting, and by the way, that prospect had already visited your trade show and asked for a demo meeting, and that’s already on the calendar, right? And so what ends up happening is, because of this disconnected context and fragmented, GTM tech stack.

You end up creating more noise because you don’t have this common context shared source of truth and an Agentic harness. And no wonder… This is why most internal efforts are ending up in failed POCs. First, you have to grapple with the fragmented Agentic AI tool ecosystem. with all good intentions, you kind of try to deploy the right data lake environments, the right CDPs with the data integration middleware, and then try to kind of choose what’s your right LLM model, what is your right Agentic orchestration environment. But there’s really no unified control plane. It’s a bunch of technologies that you’re stitching together.

Which is great, but there’s no unified control plane, there are no guardrails, there’s no common context that is shared across all of these tools. And also, one is faced with missing GTM engineering expertise. We all know that GTM engineering is one of the fastest-growing roles. Many, many companies have evolved to have GTM engineering teams, but many companies are still grappling to kind of put this function together. But GTM engineering is not a simple skill set. You require a combination of the right GTM process, architecture, Agentic AI engineering skills, because agents are not static software. We all know they’re living, breathing systems. that have to be constantly refined and nudged and managed.

They bring a lot of intelligent automation, but you have to be able to monitor those agents continuously, and look out for exceptions before they, you know, those exceptions go wild. And that’s our perspective. We realized, as we were building, RevShaw, that you really need a unified infrastructure That brings together the right Harness for… to enable Agentic and programmatic go-to-market.

Deepinder Singh Dhingra:

Now, what does that infrastructure need to have, right? And this is our learning, and I put it in this view. I think there are several similar-looking views, but this is our active practice as of today, right? You need to be able to bring together all of the data from your current GTM tech stack, whether that’s the CRM systems, the marketing automation systems. The paid ad system, the sales engagement, automation tools, buyer intelligence, customer success, product usage, web interactions. data in your warehouses, this is all of the context of your GTO motion. We’ll talk more about unpacking what context means.

But first, you have to bring together all of the interactions that are happening across your GTA motion. You need to bring it on an enterprise foundation, that practices data isolation. Authentication, authorization, role-based access, etc. Yeah, I won’t go into more detail on the PII reduction, we’ll actually show you this in action. build the GTM context data graph that not only understands your entire GTM ocean, your visitors, your ICPs, your accounts, channels, products, segments, your personas, your playbooks. Etc. But also understands the semantic meaning of how you think about funnel definitions. How do you think about what does pipeline mean to you?

How do you bring all of that intelligence together? What are the key metrics around funnels, conversions, pipeline health? account signals, lead signals, what is… what is… what… what defines a good lead? What defines a good account? What defines a marketing-qualified account for you? What defines a… a qualified Stage 2 opportunity for you. All of that context and semantic meaning needs to be encoded into the context layer. then you need to bring a layer of signals, both predictive signals and AI signals that are extracted. Before you can then drive it for activation. That activation could be through open APIs, through your MCP server gateway, through writebacks. in bulk, incremental alerts, then this forms the foundation of the Agentic Harness.

Once you have this Agentic Harness that combines the right combination of Context? data? Intelligence, Signals and predictions. Purpose-built for the GTA Motion, and purpose-built with your GTA motion encoded into it. Then you’re ready to build agents. Because if you don’t do this, and you start building agents before laying this foundation. with this harness, your agents will go rogue. Further. what’s going to happen is you’re going to end up spending unnecessary token processing cost. We have a lot of our customers that try to use Claude or ChatGPT or Copilot, which are great tools, right, to do agentic reasoning.

For example, if I ask a simple question. what are my ICP leads? Every time, lead by lead, you have to assess what ICP means, right? Or every time you need to figure out, you might have that in a skill file somewhere, which is not centralized. Or if you want to ask the question, what is the incremental impact of my paid search campaigns on organic search? Or on… Or on brand. Right? You have to figure out, what does page search mean? Do you have that campaign channel taxonomy in your context? What do brand campaigns mean in your context versus non-brand campaigns?

And then you have to figure out how to analyze incrementality do you have the right tool sets to analyze incrementality? Because the agent is going to give you some result, because all of the LLM models are going to give you some result, but is that right? Can you rely on that? And that’s why you need this Agentic harness that brings together all of these layers. of the context graph, the semantic intelligence, the signals and predictions, as well as the activation layer. Once you have this Agentic Harness, then you can build agents. You can build agents, right?

In our case, you know, we can build agents on our Agentic orchestration layer, but you can build custom agents. in any… Agentic orchestration tool, because you’ve built it on a foundation of our Agentic Harness. Whether you use Claude or ChatGPT, Gemini, you can build it on CLI, GTM as code, programmatic GTM, and you can also build it in other analytical engine environments or data lake environments. So this is our learning of how we think about, building the Agentic Harness and building a unified infrastructure for Agentic and programmatic go-to-market. What we’re going to do now is we are going to start showing you and peeling the onion from these layers so that I actually make this real.

So I’m gonna switch over to… our product environment to show you how all of this comes together, because this is not just slideware, this is actually product and technology in action.

Deepinder Singh Dhingra:

So, this is our power user application. The first step in building the Ragentic Foundation is to bring all of the data, right? Say, hey, let’s build the agents on a common layer of data across your GTM ocean, which also has the context of all the visitors, leads, accounts, campaigns, channels, interactions, opportunities, customers, etc. So, what you’re seeing here is, in this environment, we’ve integrated all of this data across multiple systems. The CRM system, the marketing automation system, a couple of them are archived, because in this case, we’re not using them, but you have the ability to integrate G2, Sendoso, First Party Pixel, paid ad tools, Google Search Console, Google Analytics, all of the data from web interactions.

From paid media interactions, from… conversation interactions from demo tour interactions, product usage data, Slack conversations that you might be using in your prospecting motion, as well as what you might be using in your customer success motion. emails, meetings, etc, data and context that is stored in your data warehouses. You can add any data source across the GTM tech stack. Whether you have multiple CRM systems, multiple marketing automation systems, etc, that’s the first step. First, you’re obviously connecting to all of your data sources. right, across your GTM ocean. It could include biointelligence tools, deionization tools, etc.

Once you have that, what this does, it builds the context graph. Right? You have… each of this data comes and resides in the context graph. What is the context graph doing? It is linking all of the leads, accounts, activities, campaigns, my apologies, from the… all of these data sources into one, into one data model. That is deduped, that is linked, that is harmonized. For example, if I click on this lead object. Right? All of the leads and the contacts across your entire GTM motion, the marketing motion, the prospecting motion, from the CRM, from the marketing automation system. from the product users that are using your product and existing customers, or free sign-up trial product users, from emails and meetings, net new leads, net new accounts getting identified and harmonized.

Similarly, all of the campaigns Across the paid interactions, the unpaid interactions, digital, non-digital, trade shows, conferences. if you’re running agents, those are also running interactions and campaigns, in your GTM motion, all of that, UTM-based campaigns, referral campaigns, right? All of the activities Similarly, all of the accounts. All of this data getting harmonized into one data model, which is the context graph. The reason this is the context graph is it’s bringing all of the interactions, all of the touchpoints, all of the details. off within your GTA motion. Then you start encoding the specifics of your GTM motion.

Usually, people try to create skills or certain things in Cloud or ChatGPT to just encode GTM context, but we feel that you need a more crystallized way of encoding GTA motion into the context graph, rather than as a layer on top of the context graph. So, for example, what is your operating calendar? What is your fiscal calendar? What’s your operating calendar? Simple things, because your agent is not going to… your agents are not going to understand what your operating calendar is. They’re going to make assumptions if you don’t give that information, right? What are the personas That you’re interacting with.

Right? Who are the typical titles that are champions across different regions, across different geographies? Who are the typical titles that are economic buyers? who’s gatekeepers, who’s influencers, who’s your technical buyers? Seed that in, so then the AI can start understanding who your typical buyer personas are. The AI also should need to understand your funnel stages, your unique funnel, whether you have an ABM motion, a PLG motion, a lead-based motion, what defines a lead for you? What defines an MQL? What does a meeting book qualify? What statuses denote that? Similarly, for pipeline, what are the different stages of pipeline?

You have to encode this information Into your context layer, into your context graph, because you need all of this information For Agentic reasoning to happen in a reliable way. Otherwise, agents will assume a lot of information about your GTM context, but you need your specific GTM context to be fed into this… into this GTM ocean. Similarly, what are details about your company, right? What are your value propositions? What is… who are your personas? What are their messaging? What are the specific messaging that you have for each persona? What are your case studies, your collaterals? Right, your success stories.

What is your ICP definition? Similarly, what are the playbooks that you might have? And then finally, also security and guardrails, right? You want, okay, if someone is reaching out, I need to give the agent what tone I need to take, what brand tone I need to take. I need to tell the agent whether they will have access to the contact names, the email IDs, or not. You are controlling what Is fed to the agent, what context and what information is going to be shared. by your Agentic ecosystem. Not one agent. But across all of the agents, across your GTA Motion, whether those marketing agents, your SDR agents, your sales agents, etc, this becomes the centralized context repository that is feeding all of your agents.

Once you have done that, what you have now, in effect. Is details of your business context encoded within your, within the context graph. Details of every lead, obviously, you’ve ingested from all of the, all of your systems, your GTM systems. So, for example, for every lead here, I have all of the details of interactions that are happening. in the GTA motion. So if I have an SDR agent, the SDR agent now has every detail of every interaction for every lead, all of the activities, campaign touches, the funnel movements, across all of the sources, right? So now your SDR agent Has the unique journey that every lead in every account has gone through.

The paid interactions, the digital interactions, the email interactions, the paid MBA interactions, the conference interactions, so they know exactly what state that lead is in. what funnel stages that lead is part of, right, or has gone through. Also, they now start understanding, hey, what did the lead mention when they interacted with me? Did they mention any competitors? What is the inferred buyer persona of this lead? You’re seeding this to the agent. Rather, expecting the agent to infer. The reason you’re doing this is that you don’t want to rely on Agentic reasoning where you can actually have… you can encode your GTA motion context, and you can use at scale the ability to feed intelligence and signals to agents.

And then let them reason on top of it, right? We find a lot of customers saying, hey, you know what I’m going to do in real time? I’m going to go get signals from, you know. a buyer intelligence tool, and I’m going to get signals from conversation intelligence, and I’m going to run 10 parallel MCP server calls to get all of this, so in real time, my agent is going to bring all of this information together, and then they’re going to do agent increasing. But that’s a waste of time, and there’s a waste of token processing costs.

Why do you want your agents and your LLM models to be accessing 10 MCP servers, getting that information, doing identity resolution and entity resolution lead by lead, when you can do that foundation work right at that start? You can do the foundation work on each lead, each account, you can get all of the signals, whether those job chain signals, propensity signals, predictions, etc, at the lead level, at the account level. What are the meeting signals? You are pre-processing this information for your context graph, so that this context graph And this context layer can understand, okay, what is the overall sentiment of this account?

What are the top pain points? What is the stakeholder coverage? What is the MedPick score? What are the top pain points they’ve kind of already expressed? What are the web signals, you know, that, you know, that we’ve been able to… did they announce layoffs? Did they announce product launches? All of these signals are pre-populated. Intent signals, job meeting signals, buying stage signals, buying group engagement signals. Who have we engaged with within the buyer group? Have we engaged with the economic buyer? Yes, no. users, technical buyers, etc. All of this is part of the context layer.

Now, once I have that. it is now ready for Agentication. This context Built as a foundation with all of the signals, predictions. and propensities, etc. Contextual to your GTA Motion, per your GTA Motions context, is now available for running Agentic action. So I’m going to transfer from this to Tejas, who’s a GTEM engineer in our company, who uses this to now drive the next set of agents. So, Tejas.

Tejas Kapur:

Yep, thanks for that, Deepinder. Just let me quickly share my screen. So, now the layer I’m going to cover is… you’ve seen how we bring in all the context, how we harmonize it all, right, and how we layer in additional context from signals and external events that are happening. Now, this is what we call our account research agent, so I have an output ready to go here. So what happens is we combine all the external context with your internal activity data and internal contacts that we get from your CRM systems. to build out this comprehensive Account 360-degree dossier that gives you everything you need to know about what the account is doing right now, with web signals, every single product launch, every single funding round.

Leadership hires across time horizons are tracked, monitored, and stitched into the data layer here, which is what you can see. Then, we can also help you expand the account by helping you find net new contacts at the account that fit your ICP only. As you can see here, we have engaged ones who are already a part of your CRM, and then we have unengaged contacts. who are… who are, you know, within the buying group and within your ICP, and who you should reach out to. So once we have all this information, we can also help reps with, you know, what to do with an account, because a company is only as good as the prospects or the leads that you have.

So then we build out this action plan, which helps you prioritize the top 5 to 10 you know, prospects based on seniority, lead score, fit, etc. And there, how we link this back to our activation layer at the end is you can sync all these contacts to any of your data sources. And it gets saved as a list, which can… which has all the researched context that we’ve got here, which is then again used by reps from the CRM systems or via our MCP tools, which we’ll go into shortly. Now, another example of how we activate all this is sending all these new signals and context that we receive to Slack by tagging, say, the lead owner or the account owner.

So whenever there’s a signal or there is a lead or account worth engaging, we can send, kind of, alerts to your Slack, something like this. Detailing why this lead surfaced, what makes him relevant now, and also the detailed recommended action stitched together from all that context that we have about this lead. Now, I’m going to quickly move into our MCP.

Deepinder Singh Dhingra:

Before you go there, Tejas, if you go back to the portal, so on the context layer, what Tejas showed you is just a couple of examples. Now that you have the context layer and the signals and the semantic intelligence encoded into the context layer, you are now able to build a bunch of agents on top. Each agent is sharing the same context. the same signals. the same GTA Motion context. So, for example, you can have lead research signals, account research signals, agents, enrichment agents, SDR agents, personalized email outreach agents, all operating and aware of each other’s actions.

Because now, because on this con… on this common Agentic Harness and this common infrastructure, every agent that you build has the same context across the GTA motion. Also is aware of each other’s agent’s actions. Right? So now, there is no way for an agent to go rogue, because that agent now understands that, hey, I already… there was already a trade show, and that the prospect had already, you know, asked for a demo meeting, so I don’t need to reach out to that person asking for a demo meeting. I might do some other action. That’s how you make sure that every agent within your GTA motion is coordinating, rather than working in silos.

Tejas Kapur:

No, absolutely. Yep, so I’m… right now you’re looking at our MCP connector, so all the context, all the signals, all the data that we just went through, even the agents that are built in the RevShaw application, are exposed as MCP tools. So these tools can now be packaged into complex workflows to create what we call plays or skills. Now, this is an example of how we currently use this at RevShop. So this is a play that’s put together from all our own tools. You can see here that once we… this is basically looking at a target account and how to action on that account.

Over here, you can see we’ve called every single context from RevShaw, including, you know, the basic account details. what signals have we found from meetings, pain points, objections? We’ve also tracked LinkedIn touches here and seen they are heavily engaged with our LinkedIn content and stuff that we’ve put out there. From there, we’ve gone on to call different kinds of agents that have done account research, found prospects from the account. And then triggered a Slack Alerts agent to send all that good context back to your reps on Slack. So if you look in here, all this is packaged together in this reusable artifact that can also now be called from another layer of CLI, which Shubh can take care of.

She’ll be honest.

Deepinder Singh Dhingra:

So what you’re seeing right now is, like, you could now… run these MCP tools, which is on our unified infrastructure, through Claude or ChatGP to any other Agentic orchestration layer, but it’s a unified MCP layer that exposes all MCP tools and context, with analytical logic, with signals, with propensity models, with all of the interactions and the touchpoints and the details. and now you can use any Agentic Acquisition layer, on top of it, right? Including, let’s say at RevStore, we have our own Agentic Acquisition layer, but you can actually build agent skills on top of it.

And… What we also do is the enablement of programmatic go-to-market, right? So instead of… Instead of triggering agents manually, you can actually just run this in an automated programmatic workflow.

Shubh Tripathi:

Okay, so, hello everyone. So, I am Shubh, and I’m Agent AI GTM Engineer at Refsure. So, I’ll quickly walk you through the CLI. So… how we enable the programmatic workflow. So, recently we got a problem, like, a company we want to sell to has just had a leadership change, or recently got a funding. So, this creates a short window where, like, we can outreach instead of doing a spam. So, doing the research manually means reading the news, looking up the company, and finding the buying group. This play turns into that repeatable workflow, which I’ll just show you.

So, creating a workflow is quite easy. We have our RevShore CLI, which you can directly use using the RevShore command line. It’s an NPM package which anyone can install, and it’s public. So, first I’ll show you how I created that, play. So… I just created it using Claude. So, it is nothing but just a natural language prompt, which I give to Claude to create a play. So, the output was, it gave me a script which I can execute or integrate it into any of my workflows. So, let me just execute that skill, and Show you how it works.

So, it’s a signal toot.py. So, it will first find all the accounts in our CRM which have the WebSignal setup. it will go through all the accounts, and one by one, it will, like, see for all the web signals available for the accounts which we have in our CRM. Then, on those web signals, it will filter, like, which of them have a funding or leadership event, because we track so many things about About a prospect. After that, like, here we can see that it found 3 accounts. So, it found 6, but for the demo, we just kept the limit to 3.

So, it found 3 accounts, one is the Harvey, one is Google, and one is Fireworks CI. So now, it will, like, find the relevant ICP… ICP-relevant prospects for each of these accounts, which we can reach out to. After finding the relevant ICP contact, it will, like, find the LinkedIn profile for each of the prospects, so we can directly reach out to them. And at last, after doing the enrichment, the lead enrichment through multiple sources, such as Apollo, MixedRank, and through multiple sources, at last asked me that if I want to publish it into any LinkedIn matching audience or DMP, So, it, we have 25 DMP registered, so I can publish to anywhere, and this list will get uploaded there.

So, but I do not want it, so the result is also saved as a CSV. So, now I can upload the CSV and, into my… one of my agents, or anywhere. And, like, because this, like, this is a normal Python play built on a stable CLI, you can deploy it anywhere. Like, we can run it as a Chrome job, a cloud function, part of a data pipeline, or a step in a larger workflow. Yeah. So this was short about CLIH. We are running out of time, so I’ll wrap it up.

Julia Nimchinski:

Thank you so much.

Tejas Kapur:

Depending the lingo and mood.

Deepinder Singh Dhingra:

No, no, go ahead, yeah, that was our overall perspective of how you bring a unified infrastructure for Agentic go-to-market, yeah, together.

Julia Nimchinski:

Defender and team, always phenomenal featuring you. We do want to address one question from the audience, and then we’ll transition to the next one. So, question is, if ReptShare’s Endstay is an Agentic GTM platform, how far are you prepared to move from recommending the next action to actually owning revenue outcomes? Tender.

Deepinder Singh Dhingra:

We are actually… On that path. Right? We believe over the past 3 years, we’ve built one of the strongest Agentic go-to-market infrastructures, and now we’re very confident that we can start owning revenue outcomes and revenue work streams across marketing, sales, SDR, BDR motion. So that’s where we are going next. Thank you for that question, whoever asked, yeah.

Julia Nimchinski:

Phenomenal. Thank you again. And… Great.

Deepinder Singh Dhingra:

Thank you.