GTM Engineering: The Technical Bits — Everett Berry, Clay

Summary of Technical Concepts in “GTM Engineering: The Technical Bits” (Auto-subtitles)

The talk argues that GTM (go-to-market) teams can now ship on a cadence similar to engineering teams, and that “GTM engineering” is about using technology to remove the constraints that previously prevented fast iteration. The speaker frames GTM engineering into four technical areas: data, orchestration, agents/state management, and execution/messaging.

---

1) Data: Building a “perfect virtual copy” of the market

Goal

Maintain an accurate, actionable representation of target accounts/contacts and their ever-changing state.

Key problems

• Account state changes continuously: acquisitions, new offices, product launches, hiring/firing, churn/expansion.
• GTM actions change accounts too: marketing/sales touchpoints, meeting booking.
• Requires combining:
  • Third-party data (firmographics, technographics, hierarchies, contact details, etc.)
  • First-party data (from internal systems)
• Entity resolution is needed because the “same” account appears differently across providers.

Key technique: “Waterfalling”

Instead of relying on a single provider, the system queries multiple vendors in sequence/layers to fill gaps (e.g., one provider only completes “halfway” phone numbers). The talk emphasizes that providers should ideally be evaluated with “evals” to determine the most accurate sources for each data field.

Operational constraint

Updating purchased/enriched data continuously is expensive, so the system must selectively update only certain fields on appropriate schedules.

Product/implementation example

A CRM-like structure with many fields tracking account status, customer/expansion/churn, size, scoring, etc.

---

2) Orchestration: Keeping many GTM tools in sync

Problem

GTM stacks involve dozens of tools (CRM, sequencers, dialers, note-taking/call recording, chat like Slack, plus others). Each tool has different update needs:

• Some require real-time single-record updates
• Others need batch updates (hundreds of thousands of records daily)
• Some data changes frequently (employee count) while others rarely (HQ location)

Additional challenges

• Fan-out + distributed failure modes: one system’s update triggers others, and failures happen often.
• Race conditions / sync dependencies: e.g., Salesforce contact creation must propagate to Outreach/sequencer before actions can occur.
• Requires mechanisms like weights/loops to check readiness.

Proposed architecture style

A graph-based orchestration layer (described as general-purpose nodes), including nodes for:

• agents
• tool calls
• conditional logic
• code execution
• map-reduce-like fanout/aggregation

Clay-specific framing

Orchestration is triggered by events/schedules, combines information, and then pushes context back to rep-facing interfaces.

---

3) Agents / Persistent Account State: Long-running, high-reliability automation

The talk positions agents as a major advance, but with strict requirements:

• Long-running agents that track account context over weeks or months
• High error tolerance: mistakes affect customer communication
• Agents produce unstructured outputs that must map cleanly into structured systems like a CRM

Key architectural approach

• One persistent agent per account that maintains state and periodically wakes via:
  • smart triggers
  • heartbeat/scheduled wakeups
• On wakeup it:
  • ingests current context from the data layer + orchestration layer
  • makes decisions and updates CRM fields

Feedback loop

• Need agent feedback to improve performance and correctness.
• Mentions “learning” / continual learning and next-best-action as cutting-edge but not fully solved.

Design principle

Separate fields agents update from fields updated by deterministic systems or humans.

Example (“basic agent” / “closed loop” mention)

Agent interacts with systems like Gong, email, CRM, and data warehouse. Triggering is time-based (avoid immediately retrying a lost account; wait before re-engaging).

---

4) Execution / Messaging: The hardest outbound problem (and also relevant to inbound)

What execution includes

Delivering the right message through the right channel while handling human and platform constraints.

Performance observations

• Cold email effectiveness declines over time.
• Channel effectiveness comparison (per talk snapshot):
  • LinkedIn ~3–4× more effective than cold email
  • Cold calling and cold email roughly similar
• Smart lead example:
  • Across ~20 million emails, reply rates around 0.5%–1%
  • Implication: with low reply rates, agents must be correct because margins are small

Human/domain constraints

• Who sends email matters:
  • If emailing “on behalf of the rep” (rep/domain used), wrong behavior can harm company/domain reputation.
• Common tactic:
  • Use multiple domains
  • Requires routing replies back so reps can process responses.

Multi-channel coordination

If a call results in a booked meeting, the system must:

• suppress further email outreach
• unenroll from lifecycle marketing where appropriate

Agentic support

Agents help coordinate execution state across channels and systems. Example described:

• a “rep-proxied” inbox setup connected to the sequencer, sending on behalf of reps
• for some accounts, use multiple domains, requiring the routing problem to be solved

---

Overall takeaway

If teams correctly implement:

1) a high-quality data layer, 2) a robust orchestration layer, 3) persistent, reliable agents for account state and decisions, and 4) careful execution/messaging coordination (including routing + deliverability),

…they can create a technical foundation for fast GTM iteration and measurable growth.

---

Main speakers / sources

• Speaker: Everett Berry
• Mentioned company/tool sources: Clay (infrastructure for these problems), Smartlead (email statistics), Salesforce, Outreach, Gong, Slack
• Other person referenced in title: Clay (company referenced in title; no additional distinct speaker content visible in the subtitles)