# AI in GTM at Notion Flora Liu, Notion | AI Engineer World's Fair 2026 | 21:15 Source: https://www.youtube.com/watch?v=L4I7WgiEquo Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/ai-in-gtm-at-notion Published: 2026-08-26 Tags: agents, data-pipelines, human-in-the-loop, workflows ## TL;DR - GTM became a distributed systems problem because customer context is spread across disconnected tools and much of the important information is unstructured. - Notion organizes its system around context, decision, action, and learning, with humans and agents working from the same customer substrate. - Agents research and prepare work, while humans approve customer-facing actions and add judgment where the risks are high. ## Summary Flora Liu describes Notion's effort to unify self-serve growth and sales-assisted GTM into one decisioning system. Customer data previously lived across Salesforce, Gong, Outreach, ZoomInfo, Snowflake, and years of notes and meeting documents. The team found that stale data, bad account mappings, and unreadable notes could make automation act on the wrong facts. Their architecture has four layers: a trusted context layer, a decision layer that selects the next step, an action layer, and a learning layer that feeds outcomes back into decisions. Snowflake models the data, DynamoDB serves fast customer profiles, and Notion gives humans and agents a shared workspace. Signals create durable Temporal workflows for research, drafting, and follow-up. Agents do not contact customers directly. Early results include more qualified opportunities among enterprise reps over 13 weeks and a 63% higher likelihood of taking the next step among users who received context-aware recommendations. ## Key ideas ### GTM became a systems problem when agents made fragmented workflows easier to connect [00:01](https://www.youtube.com/watch?v=L4I7WgiEquo&t=1s) Liu says she would have called GTM a marketing operations problem a year earlier. Agentic technology expanded what a small engineering team could automate, including work that had been too costly or difficult to coordinate. Notion had separate systems for marketing, sales, and customer operations, while customers moved between self-serve growth and sales assistance as part of one journey. The team therefore aimed to build one programmable, proactive, continuous decisioning system across both motions. Their starting point was a spiderweb of tools connected by notes, proposals, and contracts. ### Bad mappings, stale data, and unreadable notes can make automation act on dangerous assumptions [04:34](https://www.youtube.com/watch?v=L4I7WgiEquo&t=274s) The team faced three practical problems. Customer records conflicted across systems, including contacts tied to the wrong accounts, and one bad mapping could make a sales rep lose trust. Each vendor added another hop, so workflows acted on stale data. The most important facts were often buried in notes, such as "the champion just left," "do not contact this customer again," or "blocked in legal." Those details determine what a rep should do next. An automation that cannot read or process them could take a catastrophically wrong action. ### Four questions define the architecture: context, decision, action, and learning [05:36](https://www.youtube.com/watch?v=L4I7WgiEquo&t=336s) After working with CX, RevOps, product, engineering, and sales, the team reduced every workflow to four questions: what do we know about the customer, what should happen next, how do we execute safely, and did it work? These became four layers. The context layer contains trusted customer information. The decision layer chooses one next step. The action layer sends an email, displays an in-app nudge, or creates a rep task. The learning layer watches outcomes and feeds them back into future decisions, creating a loop. ### Humans and agents need to work from the same customer context [06:39](https://www.youtube.com/watch?v=L4I7WgiEquo&t=399s) Liu says the architecture only works when humans and agents operate on the same loop. The context must be visible and usable by both. Agents gather context, research accounts, draft recommendations, and write artifacts at scale. Humans add nuance, judge whether a recommendation is correct, and own the customer relationship. Notion designed agents as additional operators inside the same system instead of placing an AI layer above the business. Reps can inspect the same product usage, activity, notes, and recommendations that agents use. ### Agents do not contact customers, and eligibility rules are centralized [07:29](https://www.youtube.com/watch?v=L4I7WgiEquo&t=449s) For sales-assisted workflows, humans approve agent actions by default. A contact sales form is treated as untrusted user input, which keeps the trust boundary intact when an agent sits in the middle. The team also moved routing and eligibility into one shared primitive. Segmentations and signal definitions can then be consumed across product, sales, and engineering. A single classifier decides what the customer should receive, which helps prevent duplicate sends and conflicting communication. Notion owns the contact layer while renting services such as email delivery and enrichment. ### Snowflake computes customer truth, while DynamoDB serves fast profiles [09:01](https://www.youtube.com/watch?v=L4I7WgiEquo&t=541s) Notion ingests GTM data into Snowflake, where daily and sometimes real-time transforms produce versioned entities such as accounts, contacts, workspaces, eligibility, and facts. DynamoDB serves a denormalized, key-addressable profile that agents can query in milliseconds without joins. Research snippets, summarized notes, rolling summaries, and other generated artifacts use the same identifiers. The team brings this structured and unstructured context into Notion, where GTM teams can investigate accounts and take actions without opening seven separate tabs. ### Signals turn customer events into durable workflows and concrete tasks [11:20](https://www.youtube.com/watch?v=L4I7WgiEquo&t=680s) A signal is a customer event important enough to change what should happen next. It might be a user reaching an AI limit or contacting sales, or an external event such as new funding, hiring, or a change in technology stack. The signal service checks the customer profile, determines whether an action is available, assigns ownership, and emits a task for a human or agent. Every signal becomes a Temporal workflow. These workflows handle retries, deduplication, rate limits, and resuming after failure, so one malformed transcript does not stop a batch. ### Shadowing strong reps produces repeatable workflows while humans retain judgment [13:04](https://www.youtube.com/watch?v=L4I7WgiEquo&t=784s) The team observed its strongest reps and encoded repetitive work into multi-agent workflows. For cold outbound, research sub-agents work concurrently, several email drafts are scored, and a review agent selects and revises the best one before the draft reaches a sales task. After a follow-up call, an agent parses the Gong transcript, extracts metrics such as the economic buyer, decision criteria, plan, and champion, then drafts a grounded follow-up. Each language-model step is traced. Reps receive prioritized, pre-researched tasks and can apply their own judgment instead of starting from a blank page. ### Build versus buy is decided separately for each layer [17:21](https://www.youtube.com/watch?v=L4I7WgiEquo&t=1041s) Liu rejects a blanket rule to build everything. Notion builds where it has unique customer data and rents general services such as orchestration, email, CRM, and enrichment. The team owns the context layer because a generic product cannot capture its internal data models and workflows, and the team needs to debug that layer. Notion uses plain markdown, databases, and hierarchies so engineers, agents, and GTM staff can work with the same context. Internal agents were cheaper and faster to build than the team expected, especially around its own data model. ## Notable quotes - "Every workflow could be reduced to four questions. What do we know about the customer? What should happen next? How do we execute that safely? And did it work?" (05:36) - "We found that instead of building an AI layer on top of our business, we designed our architecture so that the agent can operate as another operator within the same system as humans." (07:09) - "If you encode a mediocre process you get a mediocre agent." (19:43) - "If humans and agents can't read from the same substrate, you're basically building two systems that will eventually drift apart." (20:05) ## Tools & references mentioned - Notion - Salesforce - Gong - Outreach - ZoomInfo - Snowflake - DynamoDB - Temporal - Clay - Nooks - Ivan Zhao ## Who should watch - You are connecting sales, marketing, product, and customer data and need a practical architecture for shared decision-making. - Your team is building GTM agents and needs boundaries around customer contact, eligibility, retries, and human approval. - You want to decide which parts of an internal AI system to build around proprietary context and which services to rent.