We hosted a small room of operators, engineers, and founders to talk about something that still does not have a clean name: GTM work that behaves like software work.
Not "AI for sales." That phrase already feels tired. The useful shift is more specific: lists, scoring, enrichment, RFPs, product marketing, attribution, research, and outbound are becoming systems you can inspect, edit, reuse, and improve.
That was the thread through the night.
Full Event Recording
Nandika Jhunjhunwala: account scoring is an operating system
Most account scoring feels fake because it is treated like a spreadsheet exercise. Nandika Jhunjhunwala's talk was the opposite: scoring as a live system for deciding where GTM effort should go.
The useful distinction is fit versus timing. A good account has more than the right firmographics. The right signals have started to move. Hiring, funding, web activity, product usage, category intent, and CRM history matter when they are pulled into one model and turned into a decision.
The point is not to produce a prettier list. The point is to make the next action obvious.
Nandika showed how teams can use Default as the front door for this kind of routing, with account data flowing through CRM and product signals instead of sitting in one static enrichment run. The practical tension in her talk was clear: one-time enrichment workflows are useful, but high-volume GTM systems need state, retries, scoring logic, and clean handoff into systems like Salesforce.
Hunter Rosenblume: the RFP is a software problem
Hunter Rosenblume's talk was about work everyone hates and almost nobody fixes well: the RFP.
Treating an RFP as "content" is how teams end up with a messy doc, a tired AE, and a deadline nobody wants to own. Hunter treats it as a software problem. Break the work into parts. Reuse the company knowledge that already exists. Route the judgment calls to humans. Let the system handle the grind.
The lesson is not that AI can write answers. It is that repeated work should stop being treated as a heroic one-off.
Hunter writes at hunterrosenblume.com and is building Ordo. In the talk, his "RFP Gremlin" example came from school lunch RFPs: extracting requirements, searching the right internal context, producing a high-quality response, and keeping the human in the loop where judgment matters.
Partner demo: Type.com AI Teammates
Type.com came up during Hunter's talk because a lot of GTM automation does not fail on model quality. It fails on coordination.
For technical folks, the easiest way to think about Type.com is this: every Slack channel gets a shared virtual machine. The team can hand it work, give it context, and let it operate across the tools already attached to the workflow.
Type.com is offering event attendees a free two-week trial with $100 in credits. Request access at type.com and mention the Deepline event.
Nick Lafferty: the marketing engineer is not a growth hacker
Nick Lafferty's talk was the clearest explanation of a role more companies will need.
A marketing engineer is more than a marketer who can write SQL. It is not an engineer doing side quests for marketing either. It is someone who can turn distribution, measurement, attribution, and product surface area into one system.
The best part of the talk was the standard he uses. If marketing depends on a signal, build the system that captures it. If attribution is messy, instrument the place where reality is visible. If LinkedIn drives demand, do not argue with the CRM report. Fix how the signal gets collected.
Nick writes at nicklafferty.com and is a founding marketing engineer at Profound, where he also has a Profound author page. He talked about Profound's use of Default, lead attribution from "how did you hear about us?" fields, GitHub Actions, the Profound API, and Claude workflows for ads, research, and marketing operations.
Kathleen Booth: product marketing should compound
Kathleen Booth described a problem every scaling company recognizes. Product marketing knowledge gets recreated constantly.
Positioning, customer language, competitor notes, launch plans, sales feedback, and proof points usually live in separate places. The work gets done. The learning does not compound. The next campaign starts from memory and scattered files.
Her system points at a better version: a product marketing brain that keeps the knowledge base, intelligence layer, skills, and feedback loop together. AI writing copy is the least interesting part. The useful part is that every piece of work can teach the system something.
Kathleen writes at kathleen-booth.com and leads marketing at Sequel.io. Her demo used Claude Code less like a copywriter and more like a product marketing operating layer: persistent memory, training docs, competitive intelligence, launch process, and a way to keep customer language from evaporating after each project.
Jai Toor: GTM systems should get better every time they run
Jai's closing demo made the argument concrete.
The old model of GTM software was a stack of tools. One for enrichment, one for sequencing, one for CRM, one for analytics, one for data cleanup. The operator's job was to move context between them.
The new model is closer to a compiler. Define the data, the workflow, the rules, and the action. Then run it again. The system should complete the task and leave the next run in better shape.
Jai Toor's demo showed how Deepline fits into that shift: TAM building, enrichment, scoring, outbound, and workflow inspection in one agent-native environment. He also talked about the parts that matter once workflows get real: network logs, tool reliability, reusable run state, and the difference between a demo agent and a GTM system that can be rerun by an operator.
That is the practical meaning of GTM as code.
The pattern
The full recording is worth watching if you want the conversations between the talks: what people are actually building, where the edges are still rough, and why good GTM teams are starting to look a little more like product teams.
The pattern across the talks is simple. The interesting teams are not collecting tools. They are turning GTM judgment into systems they can run again.
Build GTM workflows your agents can run
Use Deepline to turn TAM building, enrichment, scoring, routing, and outbound into repeatable systems for Claude Code, Codex, and agent-native teams.