As a quick refresher if you’re new to the GTM Engineer Experiment Series: A big part of my job working in growth and 📝GTM engineering at startups like Hearth, Rippling, and now Netic is trying out a lot of new products and running experiments. I was an early user of many now popular GTM engineering tools like 📝Clay, 📝HeyReach, and PhantomBuster.
I’ve found that GTM alpha comes primarily from ideas, software, and workflows that others haven’t found yet. So, I try new tools and ideas often.
In the GTM Engineer Experiment Series, I (and members of The GTM Engineer Lab) document what works, what doesn’t, and what we think is really going on. You should be able to take learnings from these experiments and apply them to your own job (and you’ll have to tell us what works! Just email us at [email protected]).
Today, I’m sharing howShashank Khanna, Founder in Residence and the Head of GTM Engineering at 📝Vanta, usedDust to answer a question every GTM Engineer I know wrestles with: of all the workflows that could be built/automated, which ones are actually worth our team’s time?
Vanta’s GTM Engineering team democratized agent-building with 📝Dust by making it dead simple for everybody at Vanta to build agents. Now, over 900 people at Vanta use Dust each month to build agents that the entire company can use. The most popular ones have been a support copilot, an account research & prioritization agent, and a recruiting agent. This has shown Shashank and his team exactly where they should prioritize their time, building production-quality systems.
In this essay, I’ll walk through precisely how Shashank built this engine and how you can do the same thing at your company.
As I dug into this experiment with Shashank, it became clear that Dust can be a guiding compass for GTM Engineering prioritization and innovation within your company. By making it easy for everyone to build agents, GTM Engineering prioritization not only becomes more straightforward, but new, impactful ideas also emerge. This is why I was excited to write about Dust and decided to partner with them to produce this post. Big thank you to Dust for supporting the GTM Engineering community!
---
So what is Dust?
Most AI agent tools are built for individuals. Dust is built for teams. Dust puts AI agent building on multiplayer mode and connects to your company’s knowledge across platforms like Slack, Google Drive, Notion, GitHub, Salesforce, and Snowflake.
Anyone can build agents that draw on that knowledge to handle tasks like researching accounts, answering customer questions, or drafting prospect emails. Dust also gives ops and IT the governance controls (permissions, SSO/SCIM, audit logs, role-based access) they actually need to confidently roll something like this out across an org.
The agent builder itself is no-code, so anyone with a Dust seat can prototype an agent in an afternoon without ever opening Terminal. With the whole company on the same platform, you get visibility into who’s building what and what’s being used the most.
If you want to check out Dust, you can sign up and use code: THEGTMENG for 1 month free.
---
How Vanta democratized agent building so that GTM Engineers could prioritize the highest impact builds
A large challenge Shashank’s GTM Engineering team faced as it supported a much larger sales and marketing org was deciding what to build.
There were infinite workflows to automate, but finite GTM Engineering hours. Shashank saw three ways his team could decide how to prioritize:
- Use ideas from leadership
- Use ideas from GTM Engineers
- Use ideas from reps across Sales and Customer Success
The last source can be the most impactful, but it has a built-in problem. It’s hard to tell which rep ideas will scale well across the team. To get real value out of rep-generated ideas, Shashank needed a way to let reps build their own agents and a way to see which ones were used the most.
Shashank used Dust to give him both. Reps could build agents and the rest of the team could use their favorites. The GTM Engineers at Vanta could let real adoption tell them which ideas deserved deeper engineering investment.
“Dust became a discovery engine for GTM Engineering. It allowed us to run many small experiments across the company, see which ones worked, and then focus engineering time on the workflows with the clearest demand.”
---
Exactly how the GTM Engineering team built this
Here’s exactly what Shashank’s team did, in detail:
- Invested in the data foundation Dust would read from. Agents built in Dust are as effective as the underlying data. Hooking Dust up to your systems is fairly simple, but making sure your systems are clear for agents, properly permissioned, and that there’s no garbage in the data is more challenging. Some tips from Shashank:Invest in data foundations (which is useful, regardless), and make sure reps get access to the clean account data. There should be one source of truth field for data points like employee size or industry, and the data should not be staleBuild custom MCPs on top of tools like Gong and Snowflake to gate what reps have access to and to clean out the garbage. This is particularly important with Gong dataDocument how the underlying data is structured so agents can interpret it correctly
- Rolled out Dust company wide, and invested heavily in enablement. In order to get sellers actually building agents in Dust, Vanta:Ran enablement sessions with the Dust teamConstantly highlighted Dust during team all-hands. Their CRO, Stevie Case, would give weekly shoutouts to people who shipped useful agentsShashank himself taught many Dust sessions, getting deep into the details with the teamVanta even has a post-sales AI Product Manager whose entire job is to monitor usage of AI tools and enable people on them to see what’s resonating vs. not
- Immediately began monitoring agent adoption through Dust’s admin analytics. This is how Shashank tracked which agents were being naturally adopted
- Had his team productionize the best of what surfaced. Ranked by usage, they saw:Support copilot: The most used agent at Vanta, it researches customer questions and drafts accurate responses for customer-facing reps. This was so popular that a dedicated human now manages it, almost full-timeCantaloupe 2.0: GTM Engineers noticed multiple independently built agents focused on account research, account prioritization, and message drafting. They merged them into a unified prospecting specialistCompetitor monitoring:Tracks what Vanta competitors are shipping and sayingRecruiting copilot: A non-GTM agent that is used to generate job descriptions, hiring guides, and candidate prep notes
---
Why Dust is uniquely equipped to support this experiment
Dust is split into two key layers:
1). Individual prototyping with shared access. Reps across sales and CS can build their own agents on the data sources Shashank’s MCPs gate, without engineering involvement. The bar is low enough that anyone can prototype in an afternoon, and the agents they build are available to the rest of the org.
Your sellers are both smart and hungry enough to use AI to create their own agents. The companies putting the power in rep hands are finding impactful solutions faster than the ones relying on leadership and GTM Engineers to determine exactly what to build.
This also attracts top sales talent that wants to work at a forward-thinking org where they, themselves, can improve their AI skillset.
2). Central oversight. Shashank’s team sits on top in Dust with admin analytics. They monitor which agents gain adoption, who is building what, and which workflows are emerging as candidates for deeper investment. The same platform that lets reps build, gives the central team the signal to know what to operationalize.
If reps could build, but Shashank’s team couldn’t see the patterns, GTM Engineers would still be guessing what to productionize. If Shashank’s team could see the patterns, but they couldn’t gate data or the agent builder was too technical, not enough agents would be built and used. Dust is the only tool I’ve come across to do both inside of one platform.
This not only helps the GTM Engineering org know where to prioritize, but it also surfaces ideas they would not have thought about in the first place.
---
Final thoughts
Up until finding this GTM Engineering Experiment with Vanta and Dust, I have seen two ways that companies prioritize where to inject AI into their 📝go to market org:
- From leadership, tops down
- From the GTM Engineers themselves
I can’t tell you how many times I’ve seen dozens (or even hundreds) of hours poured into GTM Engineering projects that didn’t solve a real problem, or that got no sales adoption.
The way Vanta is deciding to build - using Dust to make agent-building a company-wide capability, watching what gets used, and operationalizing the winners - is the first instance I have seen of systematically sourcing GTM Engineering use cases bottoms up. It makes complete sense as a prioritization mechanism.
By turning the whole org into agent prototype builders, GTM Engineering at Vanta has become a team that productionizes agents with validated demand.
If you want to set up something similar at your company, here’s what matters most from Shashank’s experience:
Use Dust as a discovery layer, not just a production system
Dust’s strength is in fast prototyping and surfacing what people actually want to use. Once a workflow proves itself with real adoption, GTM Engineers can rebuild it as a more durable system.
Invest in the data foundation before rolling out to builders
Letting everyone build agents works best if the underlying data is clean, gated, and well-documented. The custom MCPs that Shashank’s team built on top of tools like Gong and Snowflake were the unglamorous work that made everything else possible. It kept reps away from data they shouldn’t see, and it prevented agents from using garbage data that would make them ineffective.
Build a culture that celebrates the builders
Every sales org has early adopters who have the capacity to lead the charge on AI experimentation. In order to activate these early adopters, give them the right incentive/reward structure. Stevie’s weekly shoutouts to those builders encouraged them to keep shipping, and it gave the rest of the org a signal that building was valued. This in turn drove more and more reps to build agentic workflows in Dust.
---
Thanks for reading! Let me know if you try this out and reply to this email if you have a GTM Engineering Experiment you’d like featured :)