Flora Liu, an engineer on Notion's GTM engineering team, explains how Notion rebuilt its go-to-market data and automation around AI. She traces the shift from a marketing ops problem to a distributed systems problem: customer data scattered across Salesforce, Gong, Outreach, and Snowflake, with each department building agents in isolation. The team organized every workflow into four layers — what do we know, what should happen next, how to execute safely, and did it work — with humans and agents operating on the same substrate. The talk covers Snowflake computing the source of truth, DynamoDB serving denormalized profiles to agents, signals that turn customer events into durable Temporal workflows, and a safety rule that agents never speak to customers directly. Early results include enterprise reps logging more qualified opportunities and a 63% higher likelihood of next-step action for users given context-aware recommendations. # Channel Presentation Observations: "AI in GTM at Notion — Flora Liu" ## Explicit Self-Description Evidence - **Speaker role stated directly**: > "I'm an engineer on the product growth team at Notion and now working on the GTM engineering team." - **Company affiliation**: The speaker identifies herself as a Notion employee presenting internal work: > "a small team and myself, um, we've been trying to turn this spider web into a unified GTM system." - **Notion's own product self-description** (creator describing her employer, not the channel): > "notion's platform is a collaborative brain for human and agents to think together." - **Invitation to contact**: > "feel free to contact me if you guys want to ask more questions" — suggests the speaker is accessible to the audience post-talk. ## Observable Presentation Patterns - **Talk format**: The transcript reads as a conference-style presentation or recorded talk ("hi everyone... I'd like to share with you today"), with slides implied ("like what you see here," "some of the data I showed you in the boxes earlier"). - **Speaker's stated professional journey**: She frames a perspective shift: > "A year ago, I would have told you that building a GTM system was a marketing ops problem. And today, I think it's one of the most interesting distributed systems problems that I've worked on." ## Intended Audience - **Technical practitioners building GTM/AI systems**: The content assumes familiarity with Snowflake, DynamoDB, Temporal, MCP, Gong, Outreach, Clay, and multi-agent workflow design. - **Engineers and technical leaders specifically**: > "A few key takeaways... from entering this world as an engineer in the last six months" — advice is directed at builders ("before you build shadow your best human," "Model GTM as primitives"). - **Crossover audience of GTM/RevOps and engineering**: References to sales reps, marketing ops, RevOps, and MEDDPIC extraction suggest appeal to both engineering and go-to-market functions. ## Claimed Scope of Content - **Detailed technical case study**: Architecture of a four-layer GTM decisioning system — > "Know... Decide... fire... and then learn" — including data infrastructure, signal service, temporal workflows, and evaluation loops. - **Quantified outcomes claimed by the presenter** (creator claims about her team's results, not independently verified): - > "In the last 13 weeks, we are already seeing enterprise reps have increased qualification or qualified opportunities." - > "users who received context aware recommendations were 63% more likely to take the next step." - **Honest framing of maturity**: > "It's very early for us. We're still building this out, but the initial signs are promising." ## Demonstrated Tone and Approach - **Practice-oriented and prescriptive**: Shares actionable lessons with imperative framing ("Start with the most legible workflow," "be headless by default"). - **Human-and-agent collaboration thesis**: > "we designed our architecture so that the agent can operate as another operator within the same system as humans" — a recurring editorial throughline. - **Build-vs-buy philosophy articulated**: > "We refuse to outsource the context layer because that's where our edge is." ## Notes for Channel-Level Synthesis - The video demonstrates a **first-party practitioner talk** format — an internal Notion engineer presenting her team's work with specific technical detail, self-quantified metrics, and takeaways — rather than third-party commentary or product marketing. - Claims about results ("initial signs are promising," "63% more likely") come solely from the presenter and are uncorroborated within the material. - No explicit channel-level self-description (e.g., "on this channel we cover...") appears in the transcript; all identity evidence is inferred from the talk's format, speaker introduction, and content scope. # Delivery Observations — "AI in GTM at Notion" (Flora Liu) ## Tone & Register - **Conversational-engineering tone**: blends casual speech with technical vocabulary. E.g., *"we've been wrestling with pieces of it for years"* alongside *"a denormalized key addressable profile that agents can quickly query in milliseconds with no joins."* - **Honest, hedged framing of progress**: repeatedly signals early-stage status rather than overclaiming — *"It's very early for us. We're still building this out, but the initial signs are promising"* and *"our thesis... seems to be right so far."* ## Recurring Phrases & Verbal Habits - **"Last but not least"** — used at least twice (*"And last but not least, we decided that it was very important to own the contact layer"*; *"Last but not least, be headless by default"*). A stable verbal tic. - **Filler "um"** appears frequently throughout (e.g., *"um, we've been trying to turn this spider web"*), consistent with a live, unpolished talk. - **Self-corrections and restarts**: *"a Neil sales rep coming in"* (apparently "a new sales rep"), *"tool uh marketing sales built tools for sales"*, *"contact contact sales"*, *"investigate investigate accounts"*. These are observable disfluencies, not prepared-script delivery. - **Contrast-pair framing** — a recurring rhetorical structure: - *"if you encode a mediocre process you get a mediocre agent"* - *"so that they're working in the same system, but they might have different roles"* - *"instead of building an AI layer on top of our business, we designed our architecture so that the agent can operate as another operator"* ## Vocabulary & Metaphors - **Metaphor-heavy problem framing**: *"a spiderweb of tools"*, *"the costly, time-consuming, and previously unsolvable spaghetti could now be sorted"*, *"automating on yesterday's world"*. - **Repeated architectural vocabulary**: **"context layer"** recurs across the talk (*"a context layer we can trust"*, *"we refuse to outsource the context layer because that's where our edge is"*). **"Loop"** also recurs: *"feed it back into the decisioning so that it's a loop"*, *"humans and agents are operating on the same loop"*, *"these verification loops"*. - **Domain jargon used without much softening**: *MCPs, MedDIC fields ("metrics economic buyer decision criteria plan and champion"), Temporal, DynamoDB, Snowflake, rate limit* — assumes a technical audience. ## Teaching Habits & Structure - **Four-part enumeration as scaffold**: the talk pivots on the four questions *"What do we know about the customer? What should happen next? How do we execute that safely? And did it work?"* which map to Know / Decide / Act / Learn — then explicitly returns to them: *"our thesis that us building a single system on know, decide, act, and learn."* - **Numbered roadblocks**: *"First data quality... Secondly, data latency. Third, and this is a big one, structured and unstructured data."* A consistent habit of signaling list position aloud. - **Concrete examples to ground abstractions**: e.g., the critical-notes illustration — *"the champion just left or don't contact this customer again"* — supporting the point about unstructured data. - **Explicit takeaway section**: *"A few key takeaways"* with imperative-style advice (*"before you build shadow your best human"*, *"Start with the most legible workflow"*). - **Quantified evidence when available**: *"63% more likely to take the next step"*, *"In the last 13 weeks"* — but only near the end, not throughout. ## Personal Anecdote as Framing Device - Opens with a first-person shift in perspective: *"A year ago, I would have told you that building a GTM system was a marketing ops problem. And today, I think it's one of the most interesting distributed systems problems."* - References an internal story: *"our CEO Ivan built spent it building a video game and he came back convinced that software engineering could be applied to many problems."* - Closes the talk personally: *"from entering entering this world as an engineer in the last six months."* ## Uncertainty Notes - "Last but not least" and contrast framing appear multiple times — **stable patterns**. - The customer-journey narrative (opening hook, CEO anecdote, personal takeaway) appears once each; these are **structural choices**, not verifiable recurring habits. - Live-demo language (*"So you can see that they're working in the same system"*, *"Let's see how an agent and human work together"*) suggests on-screen visuals I can only infer from phrasing, not directly observe. # AI in GTM at Notion — Flora Liu ## Speaker - **Flora Liu**, engineer on the product growth team at Notion, working on the GTM engineering team (self-identified in transcript). ## Framing: GTM as a Systems Problem - A year ago she believed building a GTM system was a **marketing ops problem**; now she considers it "one of the most interesting distributed systems problems" she has worked on. - GTM at most companies is a "spiderweb of tools" stitched together by customer notes, proposals, and contracts. - Fragmented past solutions (lifecycle messaging, product recommendations, sales automations, customer data, onboarding) existed because "the underlying technology forced them to be" fragmented. - Over winter break, CEO **Ivan** built a video game and returned "convinced that software engineering could be applied to many problems that were previously unwieldy or too costly." (As stated by Liu; not independently verified.) - Agentic technology increased execution ability and problem breadth, so previously "unsolvable spaghetti could now be sorted." ## Problem Statement - Notion's business moves between **self-serve growth** and **sales assist**; customers move between the two motions. - Customers experience one journey, but internal support comes from **disconnected systems** — marketing, sales, and customer ops each look at the customer independently. - Processes were "rife with human error" and imposed cognitive burden; reps' strength is "sussing out human signals," not managing systems — context switching reduced customer time. ## Goal and Vision - Build a **single decisioning system** spanning both motions, helping decide the customer's next step cohesively. - Vision: **programmable, proactive, and continuous**. ## Initial Challenges (as stated) - **No single source of truth**: data spread across Salesforce, Gong, Outreach, ZoomInfo, and more; product usage in Snowflake; a decade of key context in notes and meeting docs. - Employees were already using MCPs and agents, but in "single department mode," making holistic tooling hard. - **Roadblocks to automation**: - *Data quality*: conflicting systems of record, wrong contacts tied to accounts — "one bad mapping was enough to lose trust" of a rep. - *Data latency*: each vendor added a hop, causing action on stale data — "automating on yesterday's world." - *Structured vs. unstructured data*: critical facts (e.g., "the champion just left," "don't contact this customer again," "blocked in legal") lived in notes; an automation that couldn't see them "could do something catastrophically wrong." ## Architecture - Team: CX, RevOps, product, engineering, sales. - Every workflow reduced to four questions: **What do we know? What should happen next? How do we execute safely? Did it work?** - Four layers: **Know** (trusted context), **Decide** (single next best step), **Act** (concrete action: lifecycle email, in-app nudge, rep task), **Learn** (feedback loop into decisioning). - Key addition: **humans and agents operate on the same loop** — agents do repetitive work at scale; humans provide judgment, nuance, approval, and own the customer relationship. Agents act "as another operator within the same system." ## Implementation Choices - **No direct agent-to-customer contact**: humans stay in the loop by default for sales-assist workflows; also a security decision — contact-sales form input treated as untrusted, so trust boundaries don't break down. - **Routing and eligibility as a first-class primitive**: rules consolidated in one place, consumed across codebase; a single classifier routes to prevent double sends. - **Own the context layer, rent everything else**: won't build email vendors or enrichment (uses Clay); won't outsource the context layer — "that's where our edge is." ## What Was Built - **Consolidated customer view**: - Snowflake computes truth: ingest from vendors, daily (sometimes real-time) transforms producing modeled versioned entities (accounts, contacts, workspaces, eligibility, facts) with ownership and timestamps. - DynamoDB serves truth: denormalized, key-addressable profiles queryable in milliseconds, plus persisted agent artifacts (research snippets, summarized notes, rolling summaries) keyed by the same IDs. - Data brought into Notion for combined structured/unstructured work — "we are using Notion to grow Notion." Internal GTM teams no longer need "seven tabs." - **Signal service**: a signal is a customer event important enough to change next steps — user-driven (AI limit hit, contact sales) or external (funding, hiring, tech-stack shifts) enabling proactivity. No signal → predictive engine sends lifecycle emails/in-app nudges toward adoption. - **Temporal workflows** (rented): each signal becomes a durable multi-agent workflow; Temporal handles retries, dedupes, and resuming from failures — one malformed transcript can't take down a batch. - Cold outbound example: research sub-agent, three scored email drafts, review agent picks highest score, loop improves drafts, lands as a sales task. - Post-call example: Gong transcript parsed, **MEDDICC** data extracted (metrics, economic buyer, decision criteria, plan, champion), grounded follow-up drafted. Every LLM step traced for evaluation. - **Learn layer**: every action is a decision log; outcomes thread back to decisions; engagement history wired back so the system decides to continue, advance, or pivot — enabling self-healing. ## Human–Agent Collaboration - Shared customer view: rep sees usage, activity, agent answers via context layer; Notion custom agents shareable for recurring workflows. - Prioritized task box with pre-researched email drafts; human adds "judgment and taste… sales secret sauce" but never starts from a blank slate. - Goal: **raise the floor for the whole team** — ramping reps learn signals, playbooks, and "what good follow-up looks like" without manual knowledge transfer. ## Build vs. Buy - Per-layer decision, not all-or-nothing: - Build: internal agents (cheaper and faster than most assume), the context layer. - Rent: orchestration, email, CRM, enrichment. - Context layer is Notion, built on "plain markdown — a language that agents are fluent in," with databases and hierarchies navigable by both agents and humans. ## Results (as claimed, with stated qualifications) - Liu explicitly notes: "It's very early for us… initial signs are promising." - Last 13 weeks: enterprise reps show increased qualified opportunities (no specific figure given). - Users receiving context-aware recommendations were **63% more likely to take the next step**. - Claimed takeaway: the thesis of a single know/decide/act/learn system "seems to be right so far." ## Stated Takeaways - **Before you build, shadow your best human** — the tab-switching chaos "was also the spec"; "if you encode a mediocre process you get a mediocre agent." - **Start with the most legible workflow** (documented and repeated); keep humans in the loop where risk exists. - **Model GTM as primitives** (entities, context, triggers, actions, eligibility rules). - **Be headless by default; design agents as operators, not just co-pilots** — otherwise you build two systems that drift apart. - Trajectory: humans are currently the primary consumers of GTM data with agents "helping at the edges"; soon agents become "primary first class consumers… moving from drafting to acting within guard rails." ## Unresolved Tensions / Qualifications Preserved - The project is ongoing: "We're still in the midst of it." - Results are early and unquantified in part (qualified opportunities increase without a figure; 63% figure stated without methodology). - Liu revised her own earlier position (marketing ops → distributed systems problem) — noted as stated. # Video Attribution & Provenance Record ## Video Identification - **Title:** AI in GTM at Notion — Flora Liu - **Video ID:** `01a15ca7-c2d6-7c9b-bd1f-52f06d1b5314` ## Speakers & Roles ### Primary (Sole) Speaker - **Flora Liu** — identified via video title and self-introduction - **Role:** Creator / presenter - **Self-described affiliation:** Engineer on the product growth team at Notion, now working on the GTM engineering team - Speaks in first person throughout; the entire transcript is her presentation ### Referenced Third Parties (Non-Speakers) - **Ivan** — Notion CEO, mentioned as having built a video game over winter break and returning convinced software engineering could apply to previously unwieldy problems (third-party claim by the speaker) - **Notion sales reps** — described but not speaking ## Provenance & Source Inventory ### Tools & Vendors Cited by Speaker - **Data/CRM stack (referenced as sources of customer data):** Salesforce, Gong, Outreach, ZoomInfo, Snowflake (data warehouse), DynamoDB (key-value store), Temporal (workflow orchestration, described as "something we rent"), Clay (enrichment service used, not built) - **Platforms:** Notion, Nooks (outbound sending referenced) ### Third-Party Claims & Metrics > "In the last 13 weeks, we are already seeing enterprise reps have increased qualification or qualified opportunities." > "Users who received context-aware recommendations were 63% more likely to take the next step." - These are the speaker's own claims about Notion's internal results; no external citation or verification source provided. ### Methodological Provenance - Speaker states reps' workflows were captured by **shadowing best reps** and encoding them as durable multi-agent workflows - Gong transcripts referenced as input data for follow-up workflows; **MEDDPIC** data extraction (metrics, economic buyer, decision criteria, plan, champion) cited as a framework ## Promotional Segments - **Notion self-promotion (implicit throughout):** The talk describes Notion's internal GTM system and repeatedly emphasizes Notion as the substrate/context layer - Notion platform described as "a collaborative brain for humans and agents" - "In a very literal sense, we are using Notion to grow Notion" - Closing takeaway names Notion as the shared human/agent layer - **No third-party paid promotion or sponsor segments detected** - No external products promoted; third-party tools (Clay, Temporal, Snowflake, etc.) are mentioned as used, not advertised ## Availability & Limitations - **Comment availability:** Not stated in supplied metadata or transcript - **Timestamps:** Not present in the transcript - **Uncertainty:** Video appears to be a conference/meetup-style talk; the venue/event is **not identified** in the source material - Transcript ends with `>> [music]`, suggesting a closing segment; no Q&A content included Well, first of all, hi everyone. I'm an engineer on the product growth team at Notion and now working on the GTM engineering team. A year ago, I would have told you that building a GTM system was a marketing ops problem. And today, I think it's one of the most interesting distributed systems problems that I've worked on. GTM at most companies involve a spiderweb of tools like what you see here, and they're stitched together by customer notes, proposals, contracts that are passed back and forth. Over the last few months, a small team and myself, um, we've been trying to turn this spider web into a unified GTM system. We're still in the midst of it, but we've learned a ton that I'd like to share with you today. So, this isn't really a new problem. We've been wrestling with pieces of it for years. Life cycle messaging, product recommendations, sales automations, customer data, and onboarding. But the solutions were fragmented because the underlying technology forced them to be. Then over the winter break, our CEO Ivan built spent it building a video game and he came back convinced that software engineering could be applied to many problems that were previously unwieldy or too costly. At the same time, our ability to execute skyrocketed with agentic technology and the breath of problems we could solve did too. the costly, time-consuming, and previously unsolvable spaghetti could now be sorted. So, what we found is that GTM had become a systems problem. That made us realize we could chip away at this holistically. In case you don't know, notion's platform is a collaborative brain for human and agents to think together. Over the years, we've evolved into a context layer for your company and AI agents can act on it. Notion's business moves between self-s serve growth and sales assist. Um, and customers move between these two motions all the time. The problem is that customers experience one journey, but internally it is supported by disconnected systems that don't actually talk to each other very well. These processes were rife with human error and put a lot of cognitive burden on our teams. For example, sales reps are probably not the strongest at managing systems, but their strength is in sussing out human signals during the buying process. So, every time they had to context switch between after a call, doing research, drafting follow-up, they were spending less time with our customers and customer problems. Most companies have separate systems for sales assist and productled growth. And this is actually also true for us. Marketing run runs on one set of tools, sales on another, customer ops on a third. But all of them are looking at a customer independently and making decisions separately. So what we set out to build is a single decisioning system that spans self-s serve growth and sales assist. and it can help the customer decide the next step so that everything is cohesive. Our vision is for this system to be programmable, proactive and continuous. When we started, we were faced with some challenges. There was so no single source of truth. So customer data was spread across Salesforce, Gong, Outreach, Zoom Info and many more. Product usage lived in Snowflake and a decade of the most important context lived in notes and meeting docs. Yes, our sales reps do use notion for that too. Notion employees were actively using MCPs and their own agents to solve problems already, but they were innovating within their own departments. So it was single player mode or you could say here single department mode. Marketing built tools for tool uh marketing sales built tools for sales and each tool served a tiny slice of that customer journey and it would make it really hard to create something that was more holistic. When we tried to automate across all of that we hit some roadblocks. First data quality conflicting systems of records wrong contacts tied to different accounts. One bad mapping was enough to lose trust for sales rep. Secondly, data latency. Every vendor added a hop and this lag was causing us to act on stale data and that meant we were automating on yesterday's world. Third, and this is a big one, structured and unstructured data. The most important facts about a customer were left in notes like the champion just left or don't contact this customer again. Um or they're blocked illegal. And so these are exactly the types of notes that help sales rep move forward and decide what to do next. And if an automation couldn't see it or process it, it could do something catastrophically wrong. So our project team consisted of CX, RevOps, product, engineering, sales. And after brainstorming together, we all kept finding the same patterns underneath that complexity. Whoops. Oh. 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? That became our architecture. So the system has four layers. Know a context layer we can trust about every customer. Decide, choose the single next best step for them. Third, fire act and fire a concrete action that could be a life cycle email um an inapp nudge or a task handed to a rep and then learn watch what happened and feed it back into the decisioning so that it's a loop. But this architecture is missing something important. The most important part is that humans and agents are operating on the same loop. Concretely, this means that the context needs to be displayed so that humans and agents can read and operate on it together. So you can see that they're working in the same system, but they might have different roles. Agents do the repetitive work at scale like gathering context, researching, drafting recommendations, and writing artifacts. Humans provide the judgment, adding nuance, deciding what to do next, and if a recommendation is correct. and owning the customer relationship. 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. Before we built the system, we made some choices about how we were going to implement this. Firstly, we deliberately chose not to let an agent talk directly to a customer. For sales assist workflows, humans stay in the loop by default and approve anything the agents do. The agents do the busy work. That decision that decision also has a security dimension too. If a prospect fills out a contact sales form online, we treat that as untrusted user input. And so trust boundaries don't break down, especially because there is an agent in the middle. Secondly, routing and eligibility became a first class primitive. Eligibility used to be scattered in all over the place. We had one check or rule in an email tool, another in sales and we pulled that all into one place so that these rules can be consumed across our codebase uh product sales engineering and these are like customer segmentations or signal signal definitions and then a single classifier will route what the customer should do and this will actually prevent double sends from our system and create very cohesive communication across And last but not least, we decided that it was very important to own the contact layer and we decided to rent everything else. Since we are a lean team, we will not build our own email vendor or enrichment services like Clay. We use Clay and we believe that we understood our customers the best. So we will not um give that away. So let's get into what we built. The first step was to gather a consolidated view of all of our customers. Snowflake, which is our data warehouse, is where we compute this truth. We ingest data from all the vendors in our GTM stack to Snowflake. We run daily transforms and in some cases real time to produce a small set of modeled versioned entities and these are accounts, contacts, workspaces, eligibility, and facts. And this also has clear ownership of what teams or uh tools they come from and like timestamps. Dynamob is our key value store and it's where we compute our truth or serve our truth. We publish a denormalized key addressable profile that agents can quickly query in milliseconds with no joins. We also persist agent uh persisted uh or generated artifacts and these are research snippets, summarized notes, rolling summaries and these unstructured data are also keyed by the same ids so that downstream systems can read all of this in one shot. So this data was normalized and of course we brought it into notion so that we could work with structured and unstructured data at the same time. So some of the data I showed you in the boxes earlier, there's like product usage data, there's activity log from across our vendor stack, and then we also have like unstructured data that like I mentioned that is most important for sales context with research reports and notes. And this turned out to be powerful for two reasons. First, our internal GTM teams didn't need to jump between many tools anymore. They could use notion itself, a tool they were already using to explore context, investigate investigate accounts, answer questions, and they could even take actions like sending to Nooks or um sending to outreach. This is a tool that they were very familiar with, and they didn't need to open seven tabs anymore. Secondly, because we weren't building an AI layer, um humans, workflows, and agents could all operate on the same source of truth. In a very literal sense, we are using notion to grow notion. The next primitive we decided that we needed was a way to turn customer events into actions. The unit here is a signal. A signal is a single customer event that's important enough to change what should happen next for a customer. Some are userdriven like a customer hitting their a AI limit or maybe they reached out to contact contact sales. But some of them are not user initiated at all which are these external signal examples I listed here like company raising funding, hiring signals or shift in their tech stack. Those external signals are what allowed us to be proactive instead of reactive. So this is the signal service that watches the customer profile, decides whether a single action is available, decides who should own that action, and then it emits a concrete task following the architecture I described before. And this task could be for a human or an agent. If there's a task for sales rep, that actually just lands in their notion database and they can quickly view it and act on it. What's what's interesting about the way we built our GTM systems is that if there is no signal about a customer, the marketing component of our system kicks in. We have a predictive engine that will recommend product features most relevant for that customer and it will send out life cycle emails and inapp nudges or multi-channel communication to drive a customer towards adoption automatically. So diving deep into a small slice of what happens when we decide what action should be emitted. Um this is for like the sales workflow and we shadowed our best reps to capture something that was the most repetitive part of our job and encoded it as a durable multi- aent workflow. Every signal becomes a workflow on temporal which is something we rent and a single run will touch enrichment web search draft generation and more. Each of these is a network call that could fail or rate limit. And so temporal lets us focus on writing the sequential logic for our GTM use cases while it will handle the retries, ddupes um and handling and going back to exactly where failures left off. and one malformed transcript can't take down the whole batch which was really important to us. So an example of a cold outbound signal for us will have a research sub agent do concurrent researches then it'll draft like an email and those emails uh there should be three of them so they're scored and then a review agent will pick the highest scoring one and make any updates if necessary. And this also operates on a loop um so that the email drafts are improved. And then when it's ready, this email draft will land in the sales task that is available for for them to act on. Um for more reactive signals after a follow-up call, the Gong transcript will come in. Our agent will parse the transcript and then um again it will extract the critical sales medpic data uh metrics economic buyer decision criteria plan and champion and draft a grounded followup for that. Every LLM step is traced so that we can evaluate quality and improve over time. The third layer is what turns this automation into a system that self-improves. Every action is a decision log and every outcome threads back to the decision that caused it. So the naive version of this is a data analyst coming in and trying to understand if the output of this could be better. The rebuilt version of this is wiring our engagement history back into the decision layer so that the system decides whether or not to continue a thread, advance to the next step or pivot. The system will continue to do that with the life cycle message performance history as well. So these verification loops are really critical so that the system can self-heal and continuously improve. Let's see how an agent and human work together in this shared customer view. In the customer view, a rep can come here and see the product usage, the recent activity and get an answer using that same data. They used to find all of this across many different tabs and now they can just come here each day. The rep can ask an agent and the agent will reply uh querying our context layer. We can also use notion custom agents which are sharable across companies to access this data context for recurring automated workflows. In the task view, a rep starts their day with an already prioritized task box and they already know how to move forward with accounts and contacts. And the email draft for an outreach task is already pre-ressearched and available for them to review. The human is still in the loop and actually adds their own judgment and taste um and sales secret sauce, but they're no longer starting from a blank sta slate. And this does more than one help one rep be productive. Um our goal is actually to raise the floor for the entire team. So a Neil sales rep coming in, they can learn the notion sales process, understand what signals are important to look for, um, understand which playbooks are effective, and basically know what good followup looks like. Reps who can are ramping can still learn from the patterns of the strongest reps without needing every lesson to be passed down manually. So, one of the questions that we came across along every step of the way is a classic question. Do we build or buy? And it's very tempting and trendy to say build everything. But what we found is that there are still key areas to build and rent access to at every single layer. Internal agents are actually cheaper and faster to build than most people assume. And so since we have the most data on our con on our data model um we build it there first and then we uh rented the generalizable parts later. So for us the build versus buy as a per layer decision. We will not build a lot of these tools like orchestration, email, CRM. Um vendors do that really well. We refuse to outsource the context layer because that's where our edge is. a generic tool can't capture all of our esoteric data models or workflows and we do not want that context layer to be something we can't um debug and so as I mentioned before that context layer is a notion it's built off of plain markdown a language that agents are fluent in and we have databases and hierarchies that they can navigate easily at the same time this is well designed for human um so this is what lets our engineers, agents, and GTM work off the same context. And this has all the data synced across sources. Ultimately, the reason to see if we can do all of this is to see if we could get a better throughput on deals. It's very early for us. We're still building this out, but the initial signs are promising. In the last 13 weeks, we are already seeing enterprise reps have increased qualification or qualified opportunities. And on the life cycle marketing side, users who received contextaware recommendations were 63% more likely to take the next step. This is the early days with a lot more features we want to build, but our thesis that us building a single system on no, decide, act, and learn seems to be right so far. A few key takeaways. um from entering entering this world as an engineer in the last six months is that before you build shadow your best human. I talked to many sales reps and when I opened uh when they opened their computers I saw how many tabs and tools they were navigating between and that was a chaos but it was also the spec and so if you encode a mediocre process you get a mediocre agent. Start with the most legible workflow. That's the one that's documented and repeated. And let humans stay in the loop on where there are risky possibilities. Model GTM as primitives, entities, context, triggers, actions, eligibility rules, and the alien world becomes a system you can engineer. Last but not least, be headless by default and design for agents as operators and not just co-pilots. If humans and agents can't read from the same substrate, you're basically building two systems that will eventually drift apart. For us, that layer is notion. Right now, humans are the primary consumer of GTM data and agents are helping at the edges. Soon, agents will become primary first class consumers within the system, moving from drafting to acting within guard rails by creating the best context and substrate for humans and agents to collaborate together. Now, you're setting up your team to sprint faster. Um, yeah, and feel free to contact me if you guys want to ask more questions. \>\> \[music\]