If you were forwarded this newsletter, join 10,877 weekly readers—some of the smartest GTM operators & founders—by subscribing here:
Thanks for reading this hand-poured, 100% organic (human-written) newsletter.
Presented by:
Clay is the infrastructure GTM engineers build on. Start building for free.
& Supported by:
Attention → AI Agents for RevOps.
Clarify → The Autonomous CRM. Sell more, admin less.
Clearskies → The Context Layer for Revenue AI.
Nooks → Revenue infrastructure for reps and agents.
Rox → Revenue Agents for the Global 2000.
Sumble → High precision GTM data + intelligence.
Terret → The answer-to-action engine for revenue teams.
Hey y’all!
After publishing Inside “ChatGTM”: Cursor’s Internal Sales AI Used by their 400+ Sales Org, I got a message on LinkedIn from a guy named Bruno, at a company I didn’t recognize: XBOW. My quick research showed me that XBOW is legit. XBOW’s AI hacker reached #1 on HackerOne’s leaderboard, the first time a machine outranked human bug hunters. Their founder is Oege de Moor, who created GitHub Copilot and GitHub Advanced Security. They were founded in January 2024 and have already raised $272M to date, most recently at a $1B+ valuation. Anyway, Bruno’s message to me said: “We have an internal tool that goes across the funnel (we use a bowtie model) and has a UI that is similar to Cursor’s and then there are all the backend jobs and a Slack Bot that complements it. It has been a game changer for our GTM teams.” I immediately set up a call to learn more.
Bruno Leardine (Director of GTM Engineering) also brought his CRO (Niroshan Rajadurai) and Head of RevOps (Justin Miller) to the call. One of the first things they told me is that they had decided to build a truly AI-native revenue org, based on their prior experience at GitHub. And they were going to build their revenue org the same way a modern product org runs: planning in sprints, building their tools in-house, and staying on the leading edge of agentic tools.
The tool they’ve built is one of the most sophisticated internal GTM systems I’ve seen. The first version was built by just Bruno, Niroshan, and Justin. And they were kind enough to give The Signal readers a behind-the-scenes look at:
Their unique approach to building
The most interesting capabilities of their in-house tool
How they built the whole system with just 3 people
How this compares to what I’m seeing in the industry
Plus, I’ll share how their approach ties into a big theme I’m seeing across the best GTM teams.
Let’s get into it.
The XBOW team’s unique approach to building
Most GTM teams don’t operate like a Product team. But this team has an atypical perspective based on their background at GitHub. Plus, they had specific constraints: as a cybersecurity company, XBOW can’t use the same off-the-shelf LLM products that others can, because they can’t just hand a third-party tool company-wide access to their Drive and Slack. So they built everything a bit differently.
1. Foundation before agents.
Justin (Head of RevOps) spent the first 6 months getting a standard tech stack in place: ZoomInfo, Salesforce, Gong, and others. But, eventually, they cut their sales stack from twelve tools down to just five (tools like Rox, Clay, and Sumble) and got the data model right. They also put in a lot of work with the field on where all the data should live. That was all before they even started building any agents. If you bolt an agent onto a messy stack, you’re going to get poor results.
2. Develop everything through rapid experimentation.
Justin told me they started experimenting, not only with what they were building internally, but also in their choice of partners. Working with nimble startups helped them experiment faster as co-builders / design partners. Bruno said: “It was clear to me that Rox was thinking about prospecting six to twelve months ahead, and that’s a burden I don’t need to have. So I can come and learn and be advised on the topic, and then go figure out other parts of the business that I don’t have a partner looking into.” These tools have become more popular recently (back then, they weren’t as well established), but the XBOW team knew they wanted to move away from the incumbent sales tech providers to try out some tools that could really help them level up. So they tested to see what worked and found some real winners.
3. Centralize the org’s knowledge.
They decided to centralize knowledge and context so the tool “knows the business cold” and sits on the source of the data. As Director of GTM Engineering, Bruno’s rule for every integration is to go to the raw source (the Slack API directly, for instance), with no middle layer.
Pro tip from Bruno:
The principle behind this is that the goal is to build agents that know what to verify and when reality has changed. Correctness of information is not a function of documenting everything, all the time. It comes from validation systems that help agents reconcile what is written, what is said, and what is actually practiced. I spent a lot of time trying to get this right at the beginning.
4. Cover the whole bow tie.
Both Justin and Niroshan (CRO) called out that they didn’t want to just stop at top-of-funnel. Their system runs “the full bow tie.” This is Jacco van der Kooij’s model that doesn’t just cover awareness through acquisition (like traditional marketing funnels), but also includes renewal and expansion. This matches something I believe more every week: the lines between sales, CS, and support are blurring, and a unifying layer across the whole customer lifecycle is becoming the obvious architecture when building a modern revenue engine.
The actual in-house tool the XBOW team built
Maybe not surprisingly, the XBOW team’s product-style approach led to… a product. It’s the central hub of their entire revenue system.
The tool is a web app (custom UI) and a Slack bot named Bolt. Technically, it uses GitHub Actions and AWS workflows to do the automated work, and it’s all built with Claude Code.
Sellers get their most urgent open opps pushed to them every morning (via “Daily Bolts”), each with one action to take today. They can ask Bolt questions mid-meeting, either via Slack or in the app.
Below is the homepage of the tool. As you look at the left-hand nav bar, you can quickly get a sense of the types of “jobs to be done” that this tool helps their reps execute.
I can’t go into every one of these in depth here, but these are a few of my faves:
One of the first things the team built was a few ways for their non-technical reps to send a valuable pitch to prospects.
One was deal intel and asset generation (from CS to the CEO, quick access to what’s going on in a deal or with a customer and being able to translate that into bespoke assets to be presented or shared with customers/prospects). Think: on-brand pitch and report decks generated on demand.
Then, a technical enablement opportunity popped up, because what XBOW does is really very technical and findings can be hard to understand. So they built a “vulnerabilities finder,” which gives sellers a (valuable) reason to reach out to a CISO. (For context, XBOW’s product surfaces security vulnerabilities that used to require a 20-year pentest veteran to interpret). With this tool, you paste a report URL, the internal tool researches the findings and explains them in language a seller selling into a CISO can actually use.
Below are a few more use-cases.
For Tracking POVs
As they were scaling quickly, they began running a lot of Proof of Values (a variant of a POC, or proof-of-concept) so they needed a single pane of glass into POV status and outcomes. Which scaled into being able to log product feedback/asks back to the product team:
When you click on any tile you will see details on that POV:
For Prospecting
They wanted to consolidate down from six outbound tools into one process for everything from identifying accounts and contacts at the accounts, to actually messaging them (powered by context from what’s working/what’s not from all of their sent emails and messages logged in Salesforce).
So, they built a feature that can be prompted with natural language, and it will generate a message in just two clicks, powered by Rox.
One seller used this feature to research all the account context from before she joined XBOW. The tool studied the POV results and customer feedback, asked what had changed in the product since, and generated a win-back plan. The plan worked, and the account is now in a new product evaluation.
For Coaching
From there, they moved on to coaching, to raise the standards for the whole team. This feature scans every call, runs eight different agents to analyze it, and automatically populates this coaching material:
One rep booked a meeting with the lead security architect at a target account, and said it only happened because of the account prioritization and targeted messaging they got from this internal tool.
For Expansion
Every Friday, XBOW has a 90-minute customer review call with all the CS and Sales leaders, covering customer progress, product gaps and adoption strategy. Those calls are recorded and updated in this tool:
Similar to the “POV Board” for sellers, you click on a specific customer and it opens up more about them.
One CSM, in her third week, used this to answer a compliance question and build a decision tree a customer asked for (which applications to assess with XBOW). This would have been several hours of work (scanning all the pieces of documentation), but only took her minutes with the tool.
For Other Departments
Bruno and team have expanded this internal product beyond just the revenue org over time. If you look on the left-hand panel below, you’ll see the other departments who are benefiting from it:
How they built the whole system with just 3 people
The first version was built by just Bruno, Niroshan, and Justin.
Part of what made this possible is that Bruno and the team subscribe to the idea of “building your intelligence and buying your infrastructure.” For example, they outsource jobs like prospecting to tools like Rox to get the time back and obsess on their internal system infrastructure. This allowed them to focus on the unique areas where they could create the most value, rather than reinventing the wheel.
Now, they’ve onboarded others, and the full GTM Eng team is contributing. Bruno mentioned that the infrastructure around the code is crucial—this is what allows him to onboard operators into that developer cycle, gets them building with Claude Code, and lets them present what they’ve built.
Also, he considers their internal users (the sellers) as builders too. Because of the way they architected the tool, the sellers can give feedback that the GTME team can quickly implement.
To that end, they describe their BDRs as “agent managers.” As of this month, XBOW’s BDR team rolls up through Revenue Operations, and the role is being redefined as agent managers (aka, workflow managers). These are humans in the loop doing QA and executing steps that should still have a human connection, with career paths into Sales/RevOps/CS/GTME.
The team told me that even as they’re automating and accelerating a lot of their functions (especially around inbound follow-up and outbound outreach to right account/right people/right time), they still believe they’ll need a human in the loop in their revenue org.
Bruno said:
I am in the business of keeping our team’s attention on priorities. I build for their focus and performance. Anything that takes their attention away is not good, and any design that brings their attention back is what I am maniacal about. I want to 4-5x their output and want them to not even think about what is in the background. Things just work for them.
They have a simple form that anyone can use to suggest ideas. It goes directly to Bruno’s GTM Engineering team, and accepted features get passed into their repo:
How this compares to the rest of the industry
XBOW is one of the best examples of a truly AI-native revenue org running on the back of one of the most sophisticated internal GTM systems I’ve seen. They took a unique approach, informed by their DNA building GitHub Copilot previously.
Many of the themes here are consistent with what I’m seeing in the fastest-growing AI-native revenue orgs. My key takeaways:
Buy the infrastructure, build the brain.
Partner with products/teams who are co-builders (like Rox, in their case).
Be model agnostic.
Leverage users as builders.
Reskill operators to build alongside agents.
I’m honored to share a glimpse at what Bruno, Niroshan, Justin and team built at XBOW (thank y’all!). I strongly believe more revenue organizations will look like this in the coming years.
PS: Watch this (incredibly high-quality) 5-minute video of Bruno explaining what he built (they named their internal tool “GTME”):
That’s it for today.
As always, thank you for your attention and trust. I do not take it for granted.
See you next time,
Brendan 🫡
If you liked today’s post, consider sending it to one person who you think would enjoy it.
Edited by Jonathan Yagel.
The “foundation before agents” point really stood out to me. Getting the data, systems, and processes right first seems to make everything you build on top of them much more useful.
So practical and useful. As always thank you!
It will be if you can further double click.. how did they pick signals? how often do they iterate on it?
How do they identify if something is not working? How often do they cleanup? etc