GTM Engineering With AI, Abnormally
Why we choose to build in-house and how our AI development gets better with every project.
Abnormal AI stops the cyberattacks that legacy tools miss. If your company still treats AI like a pilot program, you’re in the wrong place. AI-powered engineering is our default, and we’re hiring.
In August 2025, I was a product manager at Abnormal, midway through a team planning offsite. We just launched some new product modules and I was excited about the roadmap we had built that morning. Then, my CTO pulled me aside for a walk.
After some small talk, he got to it: “Evan [our CEO] really needs us to transform our Go-To-Market engine, and we want to spin up a product engineering team to make it happen.”
I’ve always loved the ambiguity of 0 → 1 problems. But I’ll admit, I wasn’t sure where they were going with this.
At the time, GTM Engineering wasn’t ripping through the online discourse. RevOps often meant procuring third party solutions that theoretically augmented your system of record, but practically left another mini data silo. There were also various startups pitching AI SDRs or AI Support Bots, but no breakaway winner.
And while coding agents were undeniably changing software engineering, the conventional wisdom was that vibe coding, letting AI write the vast majority of code, was only really viable for proof-of-concepts or mock prototypes, not production scale applications.
Oh, how much can change in six months…
Shrivu’s last post gave an introduction into how Abnormal is applying AI to transform our R&D processes. In this post, I’ll introduce how we’re similarly applying those principles to not only transform our GTM engine, but also the way in which we develop those automations.
First, a timeless question: why build versus buy?
Some principles are timeless.
As a business, you invest in building things that you want to be your “core competencies”, a fancy term for “hard things that enable an edge over the competition”.
As a security company, every dollar that Abnormal invests towards stopping breaches will return more dollars down the road in the form of more customers (who pick us to keep them safer than competitors who stop less attacks), and larger contracts (as companies using Abnormal reinvest their risk reduction and operational savings into greater protection).
In contrast, you procure things that are a commodity, where those edges over the competition don’t exist.
A security company is not going to rebuild an internal HR system to manage global payroll and international compliance because a dollar invested there enables no edge that matters to a customer evaluating security vendors.
So, why do we seek an edge in GTM?
If AI has the potential to dramatically reduce the cost of software development, then companies that seize on its potential are afforded a much more ambitious scope of core competencies.
Think about what it would mean for a B2B SaaS company’s go-to-market engine to be twice as efficient than their next best competitor at generating quality leads, converting them into deals, and retaining customers over the long-run.
That’s a lot more than twice the revenue, especially when the delta is reinvested into product, distribution, and market expansion, compounding steadily over time.
And not only does AI have the potential to make existing tasks far more efficient, it can also unlock totally new workflows by dramatically lower the barrier to perform previously unviable tasks.
But the thing is, you can’t get that edge by procuring the same tools everyone else buys.
GTM is somewhat adversarial in nature.
Generally, someone gets attention by trying the “New Thing” to stand out.
When other people notice the “New Thing”, they gradually start to mimic you.
Eventually, everyone does the “New Thing” so it no longer stands out.
The cycle repeats itself once someone else finds a new “New Thing”.
Your edge decays to zero over time if nothing changes.
Consider this post from late 2025.
The wrong takeaway from that story is Ramp wasted time building when they could have just waited and bought.
The right takeaway is that Ramp was first.
They captured years of alpha while competitors were still doing manual outbound. By the time everyone caught up, Ramp had already moved on to the next frontier.
They were ahead of the curve, not because they picked the best third-party vendor, but because they built the in-house muscle to rapidly adapt to their personalized company needs.
Now, what makes Abnormal’s approach… abnormal?
Core competencies are not novel principles and Abnormal is by no means the first to build automations for GTM. But in a world of AI, where the cost of writing code is quickly going to zero, we’re constantly pushing the boundaries of how the latest models can be applied in pursuit of maximum advantage.
We have three distinct theses for what “state of the art” means in March 2026 when it comes to applying AI towards GTM.
#1: Enabling AI-native GTM is a product development problem, because our ambitions cannot be done with no-code tools.
We’ve developed a set of AI design principles for every project we ship that most horizontal no-code tools like Glean Agents or n8n automations currently can’t support in totality.
Push. Not Pull.
Whether they’re pre-meeting briefs, an auto-drafted follow-up email, or CRM updates, our system subscribes to external events and lands in our user’s natural flow before anyone needs to ask.
We don’t rely on humans opting into a tool or being extensively trained through an “enablement session”, and there’s no URL to remember or a chat box to type into.
Deliverables. Not Data Dumps.
When our system surfaces an insight, it doesn’t hand you a wall of text (some tools call them “insights”) and make you connect the dots.
It produces a finished artifact: a formatted email draft or a coaching recommendation with specific call timestamps.
The gap between “plausible output” and “output someone actually trusts and uses” is enormous. We found that closing the gap often requires continuous feedback loops, robust evals, and reasoning traces that you can only truly set up by touching code.
AI Remembers. Humans don’t repeat.
Most agent-builder platforms create one-off workflow-style chat bots. This often leaves our users entering data which was already captured “somewhere else” earlier in the customer journey. We want our agent’s output to inform our future agent’s context, and set up feedback loops that can tune the prompts over time without much human intervention.
For all these reasons, we code.
#2: We enable our product managers to personally launch production-grade applications in under a week.
Even if a third-party platform could match the fidelity of code without the risks, there’s an even bigger second-order reason to build in-house.
In theory, we could code every project I described above with a traditional product development process: PMs write specs → designers make mocks → engineers implement requirements — probably with a lot of back & forth, and occasionally a few post-launch misalignments to iron out.
But, by basing GTM AI Transformation within our R&D culture, not as a RevOps responsibility nor a skunkworks growth-hacking prototype team, we’re defining a new model for how product managers and engineers collaborate at Abnormal to develop AI products with AI tools.
Within Abnormal’s GTM AI Transformation teams:
Engineers “build the factory”: scalable reusable data connectors into every key SaaS platform (Gong, Salesforce, Slack, Google Drive, Google Calendar, and more), and agent tools that “act” in the world (e.g. write to data sources or notify users). Of course, there are also guardrails and documentation to ensure AI writes production-quality code that matches the nuances of the existing codebase (thank you Shrivu).
Product Managers “design the car”: they talk to users, synthesize pain points into requirements, and implement GTM automations end-to-end by using Claude Code to assemble those core primitives built by the engineers. It’s like making each AI PM the mini-founder of their own GTM automation startup; but with a robust set of SDKs to handle the hard parts of scalable engineering, and insider access to the data of a 1000+ employee enterprise.
When we break down the traditional telephone game of bulky PRDs and designate a single owner who has the best software engineering + product design principles at their fingertips, the time from idea to launch goes so much faster, literally measured in days.
We started with GTM because it’s an ideal proving ground with asymmetric upside and capped downside; in the worst case, an automation is annoying and we roll it back quickly, often during a limited pilot phase. But there’s no reason this model stops at go-to-market, and that’s one of the most exciting things about the future at Abnormal…
#3 The more automations we ship, the faster (and better) our future automations get.
Most organizations experience slower velocity as more projects launch, because of the accumulated code maintenance costs.
We are observing the opposite across many of our projects.
It works in our specific environment because you can actually abstract a large swath of GTM automation use-cases into a particular structure:
A trigger: calendar event fires, call transcript lands, CRM field updates, etc.
An agent: system prompt with access to relevant data and tools.
An action: send email, post to Slack, update a record, generate a document, etc.
While the surface-level automations may look very different, this framework enables the team to design them all on top of a single underlying platform, and factor out the common logic into hardened abstractions.
Once a connector or tool is built reliably by an engineer, it can be reused an infinite number of times at the same quality by a product manager; and subsequent improvements to the primitive will benefit all projects.
As such, the marginal cost of producing a new automation decreases and primarily resides in the agent layer (ie the prompt).
Coupled with our feedback loops in AI planning around our codebase, we have lots of ways to actually reduce our debt and minimize the risk of AI slop over time.
This is the secret to why our AI PMs are repeatedly launching and maintaining production quality applications at a rapid clip.
P.S. if this sounds cool in theory but you’re a little incredulous, or if you’re sold and want to be closer to the action, come talk to us! My team is hiring :).