At GTM as Code NYC on September 22, six speakers showed working systems for introductions, events, customer feedback, account research, outbound, and shared GTM data. The common lesson was practical: make each decision, its source data, and its review step visible before automating the next action.
Thanks to Parallel and WorkOS for helping make the event happen. Below are the six edited talks, with the part of each system worth borrowing. You can also watch the six-talk playlist or see the original event page.
The takeaways in brief
- Keep the reason with the recommendation. A suggested introduction, feature match, or account score is easier to trust when a person can inspect the records behind it.
- Put exclusions before expensive work. Check whether an account should enter a workflow before enriching it or sending outreach.
- Give every handoff an owner. An event nomination, call answer, or agent action needs an explicit point where someone accepts, rejects, or corrects it.
- Resolve shared context once. If people and accounts mean different things in each tool, an agent interface only makes the inconsistency easier to reach.
These are patterns from the talks, not claims that one architecture fits every team. The recordings show how each speaker handled a particular problem.
Jai Toor: suggest warm introductions, then ask people
Jai started with a bounded group: event registrants. A Deepline Play enriched professional background; another ranked possible overlaps in work and education history. The useful output was not just a score. It showed why two people might have something to discuss, so an organizer could reject a weak match.
The boundary mattered as much as the matching logic. Shared history does not mean two people know each other or want an introduction. Jai did not turn every match into an email; each person would need to opt in before a real introduction.
Video not loading in LinkedIn or your in-app browser? Watch it on YouTube.
Read Jai's workflow and working transcript.
Jen Igartua: build the event app around the CRM
Jen's team needed a place to nominate guests, see capacity, inspect account context, and carry notes into follow-up. Her internal app sits over Salesforce rather than starting another customer database. The CRM keeps the campaign and opportunity records; the app gives people a usable path through the event work.
The interesting design choice is where approval happens. A teammate can suggest a guest, but the host still decides who gets invited. Notes made during the event can then lead to a specific follow-up instead of disappearing into a spreadsheet. The edited recording masks the attendee and client records shown in the live demo.
Video not loading in LinkedIn or your in-app browser? Watch it on YouTube.
Read Jen's system breakdown and working transcript.
Brandon Galang: keep customer evidence attached to product requests
Brandon connected signals from calls, support, and field notes to product feature requests. Each proposed match retains its source. A product manager can inspect a connection that looks wrong instead of accepting an agent's summary as the record.
He also asked what happens after a convincing demo. Retrieval has to be evaluated for quality and cost when the job runs repeatedly. A smaller candidate set may be cheaper, but it is only useful if the important evidence still turns up. Product, sales, and support may disagree about what counts as the same request; those disputed examples belong in the review set.
Video not loading in LinkedIn or your in-app browser? Watch it on YouTube.
Read Brandon's system breakdown and working transcript.
Karim Yahia: use a voice agent to fill one missing field
Karim's insurance research problem was narrow: agency websites often did not say which management software an agency used. He tested a voice agent asking that question over a business line. The system was designed around the missing field, rather than starting with a general instruction to “research the account.”
A spoken answer is still an assertion from the person who picked up. It needs the call context, uncertainty, and human review before becoming a verified CRM fact. The talk describes an experiment; it does not establish a compliance rule or a controlled performance result.
Video not loading in LinkedIn or your in-app browser? Watch it on YouTube.
Read Karim's experiment and working transcript.
Tom Bonagura: make outbound states explicit
Tom treated outbound as a sequence of account states. A new domain enters a queue, gets checked against CRM exclusions, and only then moves to enrichment and scoring. Existing customers, open deals, and do-not-contact records are held with a reason. Accounts can be rechecked when the facts behind that decision change.
That hold reason is easy to overlook. Without it, an operator cannot tell whether an account failed, was excluded, or is waiting for a new signal. Tom split eligibility, enrichment, scoring, and contact search into modules so a rule can change without rewriting the whole path.
Video not loading in LinkedIn or your in-app browser? Watch it on YouTube.
Read Tom's state machine and working transcript.
Jack Perales: give the team one resolved view of accounts and people
Jack showed how WorkOS resolved account and person records from several tools into shared entities. Event registrations and follow-up could then use the same identity and context. Teammates reached the system through an internal app and MCP tools, while existing systems still handled their own records and permissions.
His talk makes a useful point about agent access: a new interface cannot correct conflicting identities by itself. Start with a reliable resolved record and clear source data. Give write actions an owner, permission check, and audit trail before putting them behind a prompt.
Video not loading in LinkedIn or your in-app browser? Watch it on YouTube.
Read Jack's architecture and working transcript.
Where to start with your own workflow
Pick one decision your team makes often: whether to suggest an introduction, invite a guest, attach feedback to a request, qualify an account, or send it to outbound. Write down the input, the rule, what gets recorded, and who can override the result. Then test it on a small set of real cases. The talks are useful because they show those edges, including the places where the code should stop.
Frequently asked questions
What is GTM as Code?
It is go-to-market work expressed as inspectable logic: inputs, rules, states, outputs, and review steps that a team can change and rerun.
Where are the full transcripts?
Each linked speaker article includes a working transcript behind an expand control. The transcripts omit private names where needed and may still contain transcription errors, so check the edited recording before quoting a precise phrase.