Video summary

AI in GTM at Notion — Flora Liu

Main summary

Key takeaways

Technology

Summary of technological concepts & GTM system build (Notion — Flora Liu)

Flora Liu (engineer on Notion’s Product Growth team, now on GTM Engineering) argues that GTM (go-to-market) at most companies has become a distributed systems problem: many disconnected tools and workflows (sales assist, product-led growth, lifecycle messaging, customer ops) operate on fragmented customer context, leading to human error, context switching, data latency, and brittle automations.

Goal: a unified, programmable GTM decisioning system

The team is transforming a “spiderweb of tools” into one cohesive system spanning both:

  • Self-serve growth (product-led)
  • Sales assist

Vision: the system should be programmable, proactive, continuous—able to decide and act for each customer journey step, then learn from outcomes.

Core architecture: “Know → Decide → Act → Learn”

Flora describes an architecture reduced to four questions for any workflow:

  1. What do we know about the customer? (trusted context)
  2. What should happen next? (next best step)
  3. How do we execute that safely? (guarded actions)
  4. Did it work? (feedback loop)

This becomes a four-layer system:

  1. Know (context layer): consolidated, trusted customer context
  2. Decide (decision layer): choose a single next-best action
  3. Act (execution layer): emit concrete actions (emails, in-app nudges, tasks for reps/agents)
  4. Learn (feedback loop): record decisions/outcomes so the system self-improves

Key detail: humans and agents must operate on the same loop

The system is designed so both humans and agents read and act on the same context/substrate, with different roles:

  • Agents: scale repetitive work (context gathering, research, drafting, producing artifacts)
  • Humans: judgment and relationship ownership; approve/verify risky steps

Implementation choices (important guardrails)

  1. Agents don’t talk directly to customers by default

    • For sales-assist flows, humans stay in the loop and approve agent actions.
    • Security/trust boundaries are preserved (e.g., web form input treated as untrusted).

  2. Eligibility & routing are first-class primitives

    • Eligibility checks were fragmented across tools; they centralize them into one place.
    • A single classifier routes next steps and helps prevent double-sends and improves communication consistency.

  3. Own the contact layer; “rent” other services

    • They avoid building/redesigning general vendors (email/enrichment/orchestration/CRM).
    • Their edge is the contact/context layer, which they do not outsource.

Data & context layer: Snowflake + DynamoDB + Notion

Consolidation and truth computation

  • Snowflake (data warehouse) computes modeled “truth” via daily (and sometimes real-time) transforms.
  • Output entities include: accounts, contacts, workspaces, eligibility, and facts, with ownership metadata and timestamps.

Serving layer optimized for agents

  • DynamoDB used as a key-value store for fast agent queries (denormalized, key-addressable profiles with “no joins”).
  • Also persists agent-generated artifacts like:
    • research snippets
    • summarized notes
    • rolling summaries keyed to the same IDs so downstream systems can fetch everything together.

Notion as the shared “substrate” for structured + unstructured context

Data and artifacts are brought into Notion to support both:

  • structured data (tables/entities)
  • unstructured sales notes (e.g., “champion left,” “don’t contact,” “blocked/legal”)

This reduces tool/context switching for internal GTM teams and enables humans and agents to operate on the same source of truth.

Notion is positioned as “a collaborative brain” and context layer for AI agents.

Triggering actions: “Signals” → workflows

A signal is a single customer event important enough to change what should happen next.

  • User-driven signals (e.g., customer hits AI limit, requests contact sales)
  • External/reactive-to-proactive signals (funding, hiring, tech-stack changes)

Signal service

  • Watches the customer profile
  • Determines whether an action is available
  • Decides who should own the action (human vs agent)
  • Emits tasks aligned with the Know/Decide/Act model

If no signal: predictive lifecycle marketing kicks in

When there’s no direct trigger, the marketing component uses a predictive engine to:

  • recommend relevant product features
  • send lifecycle emails, in-app nudges, and multi-channel communications to drive adoption

Execution of automation: Temporal for durable multi-agent workflows

For sales workflow automation:

  • Each signal becomes a workflow on Temporal (they “rent” orchestration).
  • Workflows include steps that may involve network calls (enrichment, web search, draft generation).

Temporal provides:

  • retries
  • deduping
  • “resume where failures left off”
  • isolation so one malformed transcript doesn’t break the whole batch

Example sales workflow (cold outbound)

  • A research sub-agent does concurrent research
  • A drafting step produces multiple candidate emails (scored)
  • A review agent selects the best and revises
  • Runs in a loop to improve drafts before creating the final sales task

Example reactive workflow (after follow-up call)

  • Parses Gong transcript
  • Extracts sales MEDDIC-like fields (metrics, economic buyer, decision criteria, plan, champion)
  • Drafts a grounded follow-up message
  • LLM steps are traced for evaluation and quality improvement

Self-improvement: decision logs & verification loops

To make the system continuously improve:

  • Every action is logged as a decision
  • Outcomes are threaded back to the decision that caused them
  • Instead of “just analyzing outputs,” they wire engagement history back into decisioning to determine whether to:
    • continue the thread
    • advance steps
    • pivot strategies

This applies to life cycle message performance over time as well—enabling self-healing and continuous improvement.

Human UX: tasks, prioritized workflow, pre-researched drafts

Notion-based workflow views help reps:

  • start with prioritized tasks
  • view pre-researched email drafts already assembled
  • ask agents questions that query the context layer
  • add final judgment/“sales secret sauce” without starting from scratch

Team scaling goal

They aim to “raise the floor”:

  • ramp new reps faster using captured playbook patterns
  • let weaker reps learn from stronger reps’ workflows without requiring manual teaching of every lesson

Build vs buy (per layer)

Flora emphasizes “build or buy” as a per-layer decision:

  • They build where they have edge (notably the context layer and their data model/workflows).
  • They rent well-known infrastructure/tools:
    • orchestration (Temporal)
    • general comms/CRM/enrichment/email vendors

They also stress debugging:

  • they don’t want the context layer to be opaque or un-debuggable by design

Results (early metrics)

Early performance is described as promising:

  • Over the last 13 weeks:
    • Enterprise reps increased qualification / qualified opportunities
    • Lifecycle marketing users receiving context-aware recommendations were 63% more likely to take the next step

Key takeaways / guidance from an engineering perspective

  • Start by shadowing your best human: encode the most legible, documented workflow; a mediocre process yields a mediocre agent.
  • Model GTM as primitives/entities/context/triggers/actions/eligibility rules so it becomes engineering-friendly.
  • Be headless by default: design for agents as operators, not just “co-pilots.”
  • Use a shared substrate so humans and agents don’t drift into separate systems—Notion is that substrate for them.

Main speakers/sources

  • Speaker: Flora Liu (Notion engineer; Product Growth team → GTM Engineering team)

Original video