AI Engineer World's Fair 2026
Building GTM AI Agents: Lessons from Deploying to 6,000 Users — Sait Izmit, Snowflake
Read the talk
Building GTM AI Agents: Lessons from Deploying to 6,000 Users
Sait Izmit explains how Snowflake’s internal go-to-market assistant earned trust through narrow scope, phased rollout, sustained activation, frequent rearchitecture, and a production-log feedback loop.
From a talk by Sait Izmit
At a glance
Ideas worth remembering
Evaluate against the questions users will actually ask—even when the current agent lacks the required data—and prefer a smaller set of highly reliable answers over broad, mediocre coverage.
Separate rollout gates: use a pilot to establish quality, a beta to find workflow-critical coverage gaps and prove retention, and general availability to begin organizational activation.
Measure trial and retention separately. If users try the assistant and leave, improve the product; if they never try it, invest in demonstrations, enablement, leadership sponsorship, and adoption measurement.
Expect successful data chat to become ordinary. Continue into workflow automation, team-built capabilities, and personalization instead of treating the initial launch as a finished product.
Build with the current stack while preserving room to rearchitect. Production use revealed needs for CI/CD, evaluations, skills, progressive disclosure, memory, scheduling, and additional interfaces that the original design did not predict.
Treat logs as product infrastructure: classify real questions, find recurring gaps and frustration, create new enablement material or features, and feed those improvements back into the assistant.
Test what sellers will ask, including what the agent cannot answer
The central product risk is nondeterminism combined with an unrestricted interface. A free-form chat box invites users to ask anything. Izmit’s working model is that the first five answers determine whether a user returns; after a bad first impression, winning that user back may require ten times as much effort, if it remains possible at all. His team treats quality as P(-1): the prerequisite before the rest of the product work matters.
Before trying the early assistant, Izmit mapped Snowflake’s sales process into a spreadsheet of 150 questions. Engineers objected that the agent did not have the data needed for many of them. That objection was precisely why the test mattered: the evaluation represented the questions sellers would actually ask, rather than the questions the current implementation was designed to pass. The first run reached 50% accuracy.
The result led to a sharp scope decision. The team preferred answering 50 questions at 95% accuracy over attempting 100 at 70%. Narrower coverage made the product less impressive on paper, but gave early users a better chance of seeing several reliable answers in a row. Once that trust existed, users could ask for more capability instead of dismissing the whole system.
That restraint did not prevent later scale. Izmit says 60% of the connected data arrived after launch, over the following six or seven months. By the time of the talk, the assistant contained 15 semantic views, 85 tables, and 3,000 columns, plus five or six MCP connections and close to 20 skills. Coverage followed trust rather than preceding it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Each launch phase answers a different question
Because early interactions carry so much weight, Snowflake did not expose the assistant to everyone at once. The rollout separated three questions that teams often blur together: Is the system accurate? Does it cover enough daily work to become useful? Will users return after trying it?
The pilot used AI-native employees who were willing to tolerate rough edges and provide detailed feedback. Its purpose was quality: find failures, improve accuracy, and smooth the experience before less-forgiving users arrived. After a few weeks, the team moved to a 10% beta of 600 people.
The beta tested whether the assistant was a real minimum viable product. Requests to connect more data were not all treated equally; concentrations of similar requests indicated missing information required by recurring workflows. The team also measured retention rather than relying only on question volume. It moved to general availability after weekly active-user retention exceeded 70%, giving it evidence for quality, sufficient coverage, and repeat use. Snowflake’s companion article, From Pilot to 6,000 Users, expands on this rollout and its change-management work.
Use eager AI-native users to prove accuracy and remove rough edges.
Each phase validates a different condition before the assistant reaches a larger audience.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
After general availability, adoption becomes the bottleneck
General availability exposed a different failure mode. Two weeks after a launch, leaders could see low usage and conclude that the product was weak. Izmit’s counterexample was a graph showing that only 20% of the organization had tried it. A user who tries the product and does not return signals a product problem. A user who never spends five minutes trying it signals an activation problem.
Activation took months and consumed 60–70% of Izmit’s time. The work included joining sales meetings, giving demonstrations, building adoption dashboards by team, securing sponsorship from sales leaders, and asking managers to encourage participation. These activities raised the number of people who had actually experienced the assistant; only then could the team focus on increasing usage among activated users.
Izmit estimates that without this effort, usage might have reached only about half its eventual level. His warning to engineers is practical: deployment is not the end of product delivery. If enablement, leadership support, measurement, and post-launch demonstrations are missing, a technically sound agent can fail before enough people use it to judge its quality.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
“Talk to your data” quickly becomes ordinary
Four to six months later, success created another problem. At first, users celebrated being able to query company data without waiting up to two weeks for analyst help. After that behavior became habitual, the same users began comparing the assistant with newer AI products and asking why it could not perform additional tasks. Izmit calls this the collapsing wow factor: a capability changes behavior, becomes the baseline, and stops feeling innovative.
The roadmap therefore moves through increasingly consequential forms of assistance:
- Talk to your data: Replace dashboard hunting and routine analyst queues with direct questions.
- Automate my workflows: Use MCP-connected integrations to monitor inboxes and Slack channels, track customer questions, draft replies into Gmail for review, and support outreach workflows.
- Let teams build: Give go-to-market groups the ability to create their own skills, dashboards, applications, alerts, and automations instead of waiting in an IT backlog or purchasing another SaaS tool.
- Hyper-personalize: Adapt tools and outputs to individual sellers and to the evolving context of their customers and contacts.
The stages also change the user’s role. Data chat makes the seller a questioner; connected workflows make the seller an orchestrator; team-built tooling turns domain users into capability authors. Izmit argues that stopping at the first stage invites replacement because the initial breakthrough becomes expected within months. This is a directional product judgment rather than a measured switching-rate result, but it explains why the roadmap cannot freeze after a successful launch.
Answer questions across fragmented business information.
Each successful capability becomes normal and creates demand for the next layer of work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Launch with today’s stack, then expect to replace parts of it
Izmit contrasts this iteration with enterprises that keep testing frameworks while waiting for a perfect architecture. Waiting avoids visible technical debt, but also avoids the production learning needed to discover the real system. Snowflake’s initial deployment was deliberately plain: nine pages of agent instructions, a couple of Cortex Analyst tools and semantic views for structured data, a Cortex Search service for unstructured data, and instruction versions managed in a Google Doc. That was the system released to 6,000 people.
Production pressure then supplied the architecture roadmap. The team added CI/CD and evaluation infrastructure with unit and routing tests. As business processes outgrew the main instruction document, it introduced a skill library. MCP connections expanded available tools but required more orchestration instructions, which eventually pushed the team toward progressive disclosure. User memory, task scheduling, and a Slack interface followed as the product moved beyond one chat screen.
By the time of the talk, roughly 80% of the original PRD and architecture diagram no longer matched the deployed system. Izmit estimates that 60–70% of sprint work adds features or improves quality, while 30–40% rearchitects the product around new technology. The tradeoff is explicit: moving early creates recurring migration work, but waiting six or nine months for a supposedly final design sacrifices user learning and may leave competitors three or four months ahead.
The recommendation is not to ignore architecture. It is to avoid investing as though today’s agent interfaces, instruction format, memory system, and integration patterns will remain stable. Build enough structure to operate safely and learn, then preserve the ability to replace the parts that production proves inadequate.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Conversation logs turn usage into product and enablement work
Izmit’s final technical recommendation is to invest in logs. At the time of this section, he cites 1.2 million accumulated questions and about 40,000 more each week. LLMs classify those interactions into topics, subtopics, and representative examples. Doing this economically at scale is itself a data-science problem, but the result is a structured picture of what users are trying to accomplish.
The log analysis supplements rather than replaces interviews. It exposes unanswered requests, recurring feature gaps, repeated questions, and visible frustration with poor answers. Those signals tell the product team where quality or coverage is failing in real workflows instead of relying solely on planned evaluations or whoever volunteers for an interview.
For sales enablement, the same data shortens another loop. After a product launch, teams might otherwise interview around 100 sellers per week to discover changing questions and missing knowledge documents or battle cards. Izmit says he can query classified logs and see those patterns within minutes. The team can then ingest material from Confluence, Jira, Slack, and PRDs, generate enablement documents and battle cards, and feed the resulting knowledge back into the assistant.
Logs also reveal coordination opportunities. Different sales teams may approach the same accounts from separate angles without knowing about one another; the platform can detect the overlap and notify them. Izmit’s claimed “hockey stick” comes from reuse: the first capabilities require the platform and data foundation, while later features can build on existing classification, integrations, and feedback paths. The talk does not quantify that growth curve, so it is best understood as an operating pattern rather than a measured exponential law.
His closing synthesis keeps four disciplines together: quality over coverage, activation after launch, continuous movement beyond the fading wow factor, and fast construction on a stack expected to change. Feedback loops connect them. They show what users ask, where trust breaks, which workflows deserve expansion, and what knowledge should return to the system.
About 40,000 new interactions arrive each week.
Real questions become structured signals, new knowledge, and improved future answers.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The platform centralizes data access, UI, and guardrails
An audience question asks whether Snowflake Intelligence was a layer beneath the assistant or the assistant itself. Izmit explains that the product had recently been renamed Snowflake CoWork and describes it as a no-code agent platform for business users. Components such as Cortex Analyst and Cortex Search come with the platform, reducing the amount of application scaffolding the internal team must build itself.
Snowflake made a strategic choice to bring first-party data, third-party data, Salesforce records, call transcripts, and other sources together in Snowflake. Agents can then inherit role-based access controls instead of creating an unrelated authorization system for every data source. CoWork also supplies the chat interface, allowing teams to deploy agents without writing UI code.
The platform does not eliminate curation. Izmit closes by emphasizing control over which data sources agents can use, along with security guardrails around their behavior. That final qualification matters: no-code deployment lowers the implementation cost, while curated access and inherited permissions remain necessary to keep an enterprise agent within the organization’s intended data boundaries.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Sait Izmit’s Snowflake article expands on launch phases, scope, activation, post-launch product ownership, and reported adoption and ROI for the GTM AI Assistant.
Related talks
- 3 ingredients for building reliable enterprise agents
Harrison Chase similarly connects valuable enterprise work with deterministic workflows, observability, evaluation, and controls that reduce the risk of agent actions.
- Agents Need Feature Flags
This talk extends the phased-rollout lesson into runtime controls for prompts, tools, models, memory, autonomy, canaries, and rollback.
- Enterprise Agents Have a Structure Problem - Ishita Daga, Tesla
Ishita Daga develops the data-side complement to Izmit’s quality-first approach: curated semantic layers, authoritative business definitions, current sources, and production feedback loops.
Read the complete timestamped transcript
- 0:01
[music]
- 0:12
>> Hi everyone. So, I think I'm one of the
- 0:14
last speakers that is standing between
- 0:16
you and the long weekend.
- 0:18
So, I hope I can get your energy levels
- 0:19
up.
- 0:21
Um so, I'm responsible for our internal
- 0:22
AI tools for our sales team.
- 0:25
And the reason I'm here today is indeed
- 0:27
like we launched our internal
- 0:28
go-to-market assistant
- 0:30
uh in September last year.
- 0:32
It answered more than 1 million
- 0:34
questions so far. We have roughly
- 0:35
answered 40,000 questions a week.
- 0:38
Um and we are the customer zero for a
- 0:40
lot of Snowflake products. So, this is
- 0:42
built on Snowflake co-work.
- 0:45
Um and I meet a lot of customers every
- 0:47
week. Okay? So, I meet a lot of
- 0:49
enterprises, Fortune 500 companies, and
- 0:51
then they're all trying to build similar
- 0:53
things, and they all struggle, right?
- 0:55
So, and then I end up like having this
- 0:56
discussion with them all the time. Like
- 0:58
they ask like how did you guys do it?
- 1:00
And then we share our best practices.
- 1:02
So, I will try to share some of those
- 1:03
things with you.
- 1:04
Uh I'm told that I need to have some
- 1:06
code in my presentation. I don't, but I
- 1:08
will try to show you at least some
- 1:09
architectural diagrams just to make it
- 1:11
more interesting for the engineering
- 1:12
audience.
- 1:13
Uh but let's jump into it.
- 1:15
Um
- 1:16
I think before we start like I think I
- 1:17
already I was watching the other
- 1:18
presentations like I think everyone
- 1:19
tries to give their interpretation of
- 1:21
like you know, why are we even building
- 1:24
things for go-to-market. Okay? So, this
- 1:26
is how I explain it to family and
- 1:27
friends.
- 1:28
So, let's take Snowflake. Okay? So, we
- 1:30
are a company of like, you know, close
- 1:32
to 10,000 people.
- 1:34
So, if you look at that or our
- 1:35
organization, almost half of our
- 1:37
basically workforce is sales, right? And
- 1:39
what are they responsible for? They're
- 1:41
responsible for revenue generation.
- 1:43
What do they struggle with? And I into I
- 1:46
talked to a lot of customers. It's very
- 1:48
common. You know, everyone's data is
- 1:49
siloed. We work with a lot of
- 1:51
first-party data, a lot of third-party
- 1:52
data. It's all locked down in these like
- 1:54
SaaS tools and things like that. And
- 1:56
literally we have for example like reps
- 1:58
who are using 15 different tools, not
- 2:00
because they love the UI of those tools,
- 2:02
because every tool has a different data
- 2:03
point, and then they end up stitching
- 2:05
all of that together in spreadsheets and
- 2:06
running it there, right?
- 2:08
And the data is endless. Like we have
- 2:10
reps who have 1,000 accounts assigned to
- 2:12
them, 1,000 customers.
- 2:15
They have to stay on top of their recent
- 2:16
news, what's happening with their
- 2:17
consumption, did they get in support
- 2:19
tickets recently, what was their latest
- 2:21
earning results, everything. There's no
- 2:23
It's not a single human on this planet
- 2:25
that can stay on top of that much data.
- 2:27
And then they need to do that 30 times,
- 2:28
40 times a day, right?
- 2:31
So, what does AI offer for them?
- 2:33
It offers that data democratization. No
- 2:35
more like 1,000 dashboards, right? No
- 2:37
more access to analysts. Like you know,
- 2:39
um it offers automation possibilities
- 2:41
for them, right? It frees up their
- 2:43
inbox. It offers tool consolidation. No
- 2:46
longer 15 different tools that I need to
- 2:48
work for.
- 2:50
And that brings productivity savings. It
- 2:52
frees up your time, right? You can use
- 2:53
that time on other things. It helps you
- 2:55
become a better seller. You're more
- 2:56
effective with your customers. And that
- 2:58
translates to business results. You can
- 3:00
cover more of your book, you know, you
- 3:02
can have better win rates, uh you can
- 3:05
have shorter deal cycles, and ultimately
- 3:07
what everyone cares about, you can get
- 3:08
incremental revenue. Okay, so that's the
- 3:10
reason why I'm I'm working for, you
- 3:12
know, making the go-to-market
- 3:13
organizations more effective.
- 3:16
But, there's a catch. These are
- 3:18
non-deterministic systems,
- 3:20
right?
- 3:21
And I run into this problem every time
- 3:24
with users.
- 3:25
I see many, many, many AI projects
- 3:27
failed,
- 3:28
and then it fails on this principle.
- 3:31
User trust is earned extremely hard and
- 3:34
is lost overnight,
- 3:37
right?
- 3:38
So, at the end what you're doing is
- 3:39
you're putting a free-form chatbot
- 3:41
there,
- 3:43
right? And people will come in and they
- 3:44
will ask any question they can think of.
- 3:47
If they like what they see in the first
- 3:49
five questions, they come back.
- 3:52
If they don't like what they see, it's
- 3:53
10 times more effort for you to win them
- 3:55
back, if you can ever win them back.
- 3:57
Right?
- 3:58
So, we have a saying in our team, we say
- 4:01
quality is P minus one.
- 4:03
Right?
- 4:04
And that's basically we take that very,
- 4:06
very seriously.
- 4:08
So, one of the things that we really
- 4:10
cared about is when I first joined the
- 4:12
team,
- 4:13
you know, the team had all these like
- 4:14
data sources connected from our top
- 4:16
dashboards. We they had a knowledge
- 4:17
assistant built into it and so on. We
- 4:19
had three lines of agent instructions.
- 4:22
And then before I even tried the agent,
- 4:24
I opened a spreadsheet, I took the sales
- 4:25
process, I wrote down 150 questions.
- 4:28
And then the sales our engineering team
- 4:30
was like, "What are you doing? We don't
- 4:31
have that data in the agent."
- 4:33
I was like, "It doesn't matter. These
- 4:34
are the questions your sellers are going
- 4:35
to ask."
- 4:36
Right? And then we run our test, 50%
- 4:39
accuracy, you know, like everyone's
- 4:40
depressed and so on. So, we said, "Okay,
- 4:42
let's make sure that we don't go for
- 4:44
coverage, but we go for quality." Right?
- 4:47
We don't want to try to answer 100
- 4:48
questions and get them 70% right. We
- 4:50
want to answer 50 questions, but get
- 4:52
them 95% right. Right? Because with that
- 4:55
you get a first impression, good first
- 4:56
impression, you build a trust with them.
- 4:58
And then rather than being in that boat
- 5:00
of, "Oh, this thing doesn't work."
- 5:02
people are like, "Oh, this thing is
- 5:03
awesome. Can I get more of that?"
- 5:05
Right?
- 5:06
So, we started small and 60% of the data
- 5:09
we actually added after the launch,
- 5:11
after the 6-7 months post launch. Today,
- 5:14
if you look into our agent, I mean, it's
- 5:16
not a small agent. We have 15 semantic
- 5:18
views, 85 tables, 3,000 columns of data.
- 5:22
We have like five to six different MCP
- 5:23
connections on it. You know, close to 20
- 5:26
skills connected to that and so on and
- 5:27
so on.
- 5:28
Right? So, it's a huge system that we
- 5:30
are managing in here.
- 5:33
And then you cannot just launch these
- 5:34
things to everyone, right? So, we said
- 5:36
that, "Look, we need to do this in a
- 5:37
controlled way because we want to make
- 5:39
sure that we earn that first five
- 5:40
questions. We don't want to burn our
- 5:42
bridges in that first five questions."
- 5:44
Right? So, that's why with every product
- 5:46
we do, we do a face launch.
- 5:49
The first one is a pilot. The goal of
- 5:51
the pilot is to prove the accuracy,
- 5:52
prove the quality, right? You get your
- 5:55
top, you know, AI native folks in the
- 5:59
organization who are eager to work with
- 6:01
you, give you feedback, improve the
- 6:02
product, make sure that you got the
- 6:04
rough edges through that, right? And
- 6:07
then after a couple of weeks, you come
- 6:08
to a point where it looks like, okay,
- 6:10
those rough edges are more smoother now.
- 6:12
Okay? Then you go into your better
- 6:14
launch. We do 10% better, right? With
- 6:16
600 people.
- 6:17
There you are looking at do I truly have
- 6:20
an basically a minimum viable product?
- 6:22
Is the MVP really there, right? And what
- 6:25
will happen is that you will start
- 6:26
getting tons of requests. Can you
- 6:27
connect this data? Can you connect that
- 6:29
data and everything? And then you are
- 6:30
looking at like where are the actually
- 6:32
the concentrations happening? Because
- 6:34
that means that if you don't get those
- 6:35
things in, you don't truly have an MVP,
- 6:37
right? Then it's not going to work for
- 6:39
their daily workflows.
- 6:41
And then at this stage, you're also
- 6:42
trying to prove are they coming back?
- 6:45
Right? So, the things that we really
- 6:47
track there
- 6:48
is basically like, okay, how many
- 6:50
questions they're asking and everything,
- 6:51
but what is the retention rate? So, we
- 6:54
exited for example that at like more
- 6:55
than 70% retention rate that the weekly
- 6:57
active users were coming back. Okay, now
- 6:59
we're in a good place, right? We have
- 7:01
confidence on the accuracy, we have on
- 7:03
the confidence of the basically the
- 7:04
coverage of the product we have, and
- 7:06
people are coming back. Okay, now let's
- 7:08
go to GA, and then you launch through
- 7:10
the GA. And then you have your next
- 7:12
problem.
- 7:13
So, I know that this is a technical
- 7:14
conference, but this is also where a lot
- 7:16
of these products fail.
- 7:18
It's basically how do you drive change
- 7:20
management? So, you launch your product,
- 7:22
you are 2 weeks into the launch, and
- 7:24
then you are here. And all your
- 7:26
management is like disappointed or
- 7:28
frustrated. Why aren't people using
- 7:30
this? Why are numbers are real low?
- 7:32
Right? And I show them this graph.
- 7:35
I say that only 20% of your basically
- 7:37
organization actually tried the product.
- 7:40
I cannot do anything. This is not the
- 7:42
product's fault if people are not even
- 7:43
taking 5 minutes to try try the product.
- 7:46
Right? If they try it and if they don't
- 7:48
come back, okay, that's my problem.
- 7:50
Right? But if they don't try it, then we
- 7:52
have another problem.
- 7:53
So, the first and I've been, you know,
- 7:55
I've seen this with many many sales
- 7:57
organization in my past life as well and
- 7:58
so on. Usually this is a couple of month
- 8:00
process. And then you significantly
- 8:03
invest in basically change management,
- 8:05
in activation. I will spend 60 70% of my
- 8:08
time in sales meetings, giving demos,
- 8:10
building dashboards, which teams
- 8:12
adopted, you know, shaming the like the
- 8:14
managers whose team is actually doing
- 8:15
good, getting sponsorship from sales
- 8:18
leaders to basically like make sure that
- 8:19
they you know, they push their people to
- 8:21
try these things and so on. And then
- 8:23
ultimately that gets your blue line up
- 8:24
and then your questions are start coming
- 8:26
up and then your focus can shift into,
- 8:29
okay, how do I drive more depth?
- 8:31
Right?
- 8:32
And I want to really really emphasize
- 8:33
this because if you hadn't done this,
- 8:35
we would probably be doing, you know,
- 8:38
half of where we are today. So, this is
- 8:39
a very very important part. And then as
- 8:42
engineers, if you spend all your effort,
- 8:43
you want to have a good product, make
- 8:45
sure that the activation and the change
- 8:46
management is like lined up, like post
- 8:49
launch of the product as well.
- 8:52
Now, you run into another issue. Okay,
- 8:54
you are let's say that four to six
- 8:56
months down the road. Right?
- 8:59
What happens is you successfully
- 9:00
launched the product. You are first like
- 9:02
rockstars in the company.
- 9:04
Right? People literally show you on the
- 9:05
corridor like, "Hey, your product is
- 9:06
awesome. We can talk to our data now. We
- 9:09
don't need to wait on the queue to like,
- 9:11
you know, get access to like analysts to
- 9:13
answer our questions in every 2 weeks
- 9:14
and so on. Right?" And after a couple of
- 9:16
months, they start coming back to you
- 9:18
with frustrations. Say, "I cannot do
- 9:19
this in the product anymore. Right? I I
- 9:21
would like to I mean, I saw this other
- 9:23
AI product that does this and so on."
- 9:25
This is what I call the collapsing of
- 9:26
the wow factor.
- 9:28
Okay? So, initially you are cool,
- 9:30
but then
- 9:32
and that becomes a habit, right? You
- 9:33
basically change their habit and it
- 9:35
becomes standard for them. Now, you need
- 9:37
to raise the bar again.
- 9:38
So, the journey that we usually see with
- 9:40
the sales teams is like you start with
- 9:42
talk to your data. How do we get you out
- 9:44
of those like, you know, hundreds of
- 9:45
dashboards situation, dependency to the
- 9:47
analyst, and then first we'll basically
- 9:49
like democratize the data for you so
- 9:51
that you can basically talk to your
- 9:52
data.
- 9:54
Then the next wave comes with all the
- 9:56
MCP connections, right? All the
- 9:57
integrations that you are building.
- 9:59
Now it becomes like automate my
- 10:01
workflows.
- 10:02
We literally have now sellers who are
- 10:03
going to use our agent basically to
- 10:05
monitor their inbox, they monitor their
- 10:07
Slack channels, you know, keep track of
- 10:09
all the customer questions coming about
- 10:11
like product questions, uh use the agent
- 10:13
to draft responses that save that in
- 10:15
Gmail, review them afterwards like send
- 10:17
those things out, right? Or they
- 10:19
automate their like outreach workflows
- 10:20
and so on. Okay, that's great. Now I
- 10:22
became an orchestrator, right? I'm
- 10:24
basically automating my workflow
- 10:25
workflows.
- 10:27
Then the next thing you see start
- 10:28
happening is teams, they get these like,
- 10:31
you know, tool democratization, this
- 10:33
empowerment coming to them, right?
- 10:35
Because historically a lot of these
- 10:36
go-to-market teams, they have been
- 10:38
always in the backlog of someone,
- 10:40
backlog of of an IT team or like trying
- 10:42
to get a SaaS budget to learn and get a
- 10:44
vendor on board to actually like enable
- 10:46
something.
- 10:47
And now all of a sudden
- 10:48
they're able to build team skills.
- 10:50
They're able to build like, you know,
- 10:51
the custom dashboards that are basically
- 10:53
like fully, you know, optimized for what
- 10:55
their team needs. Are able to like
- 10:57
deploy applications, automations,
- 10:59
alerts, and things like that, right?
- 11:02
And then the comes the phase of
- 11:03
hyper-personalization,
- 11:05
right? Everyone is able to now like get
- 11:07
everything personalized for them, not
- 11:09
only for themselves, but also for their
- 11:10
customers with living context of
- 11:12
customers, contacts, and things like
- 11:13
that.
- 11:14
I think the main message I want to give
- 11:15
here is
- 11:18
if you just do the first stage,
- 11:20
and if you just wait there,
- 11:22
you will get disrupted in a month or
- 11:23
two,
- 11:24
right? Because now you already raised
- 11:26
their expectations, that already became
- 11:28
a baseline, and then they will find
- 11:29
another product that does better than
- 11:31
you, and right now the switch is very
- 11:33
easy. They're going to just switch over
- 11:34
night. Okay? So, you need to keep
- 11:36
iterating. You need to keep that wow
- 11:38
factor, and I cannot just rely on the
- 11:40
fact that, you know, what I built so far
- 11:41
is going to stay cool forever.
- 11:45
And the next thing is, how do you deal
- 11:47
with basically the changing technology?
- 11:49
So, I talked to a lot of customers.
- 11:52
And then, you know, it sometimes you run
- 11:53
into these customers, big enterprises,
- 11:55
very big brands. And then they are still
- 11:57
trying to purchase that perfect
- 11:58
architecture.
- 12:00
They're trying to like test different
- 12:01
frameworks. They're trying to see how
- 12:03
the, you know, the technology is
- 12:04
maturing and everything and so on. But,
- 12:06
the thing that they don't do is they
- 12:08
don't build, and then they don't launch,
- 12:10
and they don't learn.
- 12:11
Right? All these blue boxes that you see
- 12:13
here, those are all the things we added
- 12:15
after the launch.
- 12:17
Right? When we literally first launched
- 12:18
the agent, it was a nine-page long agent
- 12:21
instructions.
- 12:23
It was couple of Cortex analyst tools,
- 12:25
semantic views. It was a Cortex search
- 12:26
service for our unstructured data. And
- 12:29
we were managing the agent instructions
- 12:30
versions out of a Google Doc. That's how
- 12:32
we launched it. To 6,000 people. Right?
- 12:35
Now we realized, okay, it's not going to
- 12:37
work out. Let's figure out CICD. It's
- 12:38
not going to work out. Let's figure out
- 12:40
our basically eval infrastructure with
- 12:41
all the like the unit test, routing
- 12:43
test, and everything. Right? Then we
- 12:45
start basically like coming to a point
- 12:47
where, for example, we were creating all
- 12:49
these like business processes and
- 12:50
workflows. We couldn't fit them into the
- 12:52
agent instructions anymore. And then the
- 12:54
skills came, and we were like, "Oh,
- 12:55
perfect. Let's build a skill library."
- 12:57
You know, then the MCPs came. Perfect.
- 13:00
But now, like we have to put bunch of
- 13:01
other instructions to basically
- 13:02
orchestrate that, we hit the limits on
- 13:04
the agent instructions. What do we do?
- 13:06
Okay, let's do the progressive
- 13:07
disclosures.
- 13:08
Right? And then user memory comes, task
- 13:11
scheduling comes. We want to go beyond
- 13:12
the chat screen and then, you know, chat
- 13:14
interface and start doing the Slack
- 13:15
interface and things like that. If I
- 13:17
look at the PRD and the architectural
- 13:19
diagram we wrote in the beginning of the
- 13:20
project, if I compare to this
- 13:22
architecture we have now, 80% of it It
- 13:25
match.
- 13:26
Okay? So, like if you look at our
- 13:28
sprints,
- 13:29
like maybe 60-70% of the work we are
- 13:32
doing is adding new features, improving
- 13:34
quality, and all kind of things.
- 13:36
But 30-40% of the work is that we are
- 13:37
constantly re-architecting with the new
- 13:39
technology.
- 13:41
So, this is a time where like you need
- 13:42
to get your hands dirty, you need to run
- 13:43
with the new technology, and then you
- 13:46
shouldn't be like, you know, too much
- 13:47
tied to your architecture. You should be
- 13:49
okay to like pivot very easily, so that
- 13:51
you can basically double on down on
- 13:52
these like new capabilities and things
- 13:54
like that.
- 13:55
And then the longer you wait, the more,
- 13:57
you know, you lose towards your
- 13:58
competition, because if your competition
- 14:00
is doing these kind of things like 3-4
- 14:02
months ahead of you, right? That means
- 14:04
that they're also getting more
- 14:05
customers.
- 14:08
Um last thing is I would really, really
- 14:11
recommend investing in your logs. Okay?
- 14:14
Because they create the basically the
- 14:15
feedback loop.
- 14:17
So, first of all, technically it's very
- 14:19
fun. Okay? So, you basically use LLMs to
- 14:21
like classify your logs and things like
- 14:23
that. As I said, like we have 1.2
- 14:25
million questions, we get 40,000
- 14:26
questions every week. It's technically
- 14:28
very fun, you know, how you do that at
- 14:30
scale without breaking the bank and so
- 14:32
on. You know, our data scientists love
- 14:33
working on those things, and then they
- 14:35
really experiment with new things.
- 14:37
But as a result of that, what we get is
- 14:39
we get a very extremely detailed
- 14:41
breakdown of topics and, you know,
- 14:43
things that we are having. I'm just to
- 14:44
showing you the top category
- 14:45
categorization level there, but then
- 14:47
basically we are able to track like, you
- 14:49
know, what kind of questions they are
- 14:50
asking. We are able to break down each
- 14:52
of those categories to subcategories,
- 14:54
you know, they are able to get like
- 14:56
detailed example questions, this and
- 14:57
that, and so on.
- 14:59
All good, but how do we use that? Then
- 15:01
we start creating the basically the
- 15:02
feedback loops.
- 15:03
Right? I know, I mean, I still
- 15:05
interview, of course, users, but now I
- 15:07
see in real time what my feature gaps
- 15:09
are.
- 15:09
I'm clearly seeing what people are
- 15:11
asking and we are not able to answer or
- 15:12
where we have a like a quality issue,
- 15:14
where they are swearing at the agent or
- 15:16
like at repeating their question, so
- 15:17
that we see where to improve.
- 15:20
For sales enablement is a goldmine.
- 15:22
Let's say that we launch a new product.
- 15:25
Usually, you know, they would need to
- 15:26
interview maybe 100 sellers a week to be
- 15:28
able to understand like how basically
- 15:30
the you know, the topics are changing
- 15:32
where there's gaps in terms of like
- 15:33
knowledge documents, battle cards. I see
- 15:35
that in real time in a minute or two by
- 15:37
just asking an element question. And
- 15:39
then we can then, you know, connect to
- 15:40
Confluence, we can connect to Jira, we
- 15:42
can connect to Slack channels, we can
- 15:44
ingest the PRDs, and in couple of
- 15:46
minutes we can actually like, you know,
- 15:47
generate battle cards, sales enablement
- 15:49
document and then feed it back into the
- 15:50
agent.
- 15:51
Right? I mean, you cannot do that kind
- 15:53
of a like a feedback loop with humans,
- 15:55
right? So then you we can basically
- 15:56
automate these kind of things.
- 15:58
Um within the sales organization, there
- 16:00
will be different teams that are good
- 16:01
trying to connect each other. They are
- 16:03
trying to maybe target similar accounts
- 16:04
from different angles. They don't know
- 16:06
about each other. We do. We are now able
- 16:08
to ping them. And then we are able to
- 16:10
basically do matchmaking.
- 16:11
Right? I'm just giving you couple of
- 16:13
examples, but this is also one of those
- 16:15
areas where like you start building your
- 16:17
AI platform, you start building your
- 16:19
architecture.
- 16:20
The first features are difficult to get
- 16:22
out. The next ones are easy. And then
- 16:25
once you start tapping into your logs,
- 16:26
this this like hockey stick exponential
- 16:29
thing actually starts happening and it's
- 16:30
magical.
- 16:34
So, if you were to take a couple of
- 16:36
things from this talk,
- 16:38
like quality over coverage.
- 16:40
I'm very, very like religious about
- 16:42
this.
- 16:43
If you go for the coverage,
- 16:45
you are going to shoot yourself in the
- 16:46
foot.
- 16:47
Okay?
- 16:49
Change management. A lot of engineers
- 16:51
doesn't think about this, right? A lot
- 16:53
of these AI initiatives, they don't fail
- 16:56
because there's an issue with the
- 16:57
technology, there's an issue with that
- 16:58
as assuming you did the first one,
- 16:59
right? Right? So, they fail actually in
- 17:02
activation.
- 17:04
So, make sure that you have a plan for
- 17:06
that, especially in larger organizations
- 17:08
where we are dealing with like 6,000
- 17:09
go-to-market users, right?
- 17:12
Um again, don't forget this concept of
- 17:14
collapsing law factor.
- 17:16
You cannot stay where you are. You
- 17:18
cannot just say that, "Hey, I did an
- 17:19
innovation. I'm going to surf that for a
- 17:21
year."
- 17:23
You know, every time people are happy,
- 17:24
you should be paranoid. You should be
- 17:25
like, "Okay, what am I going to show
- 17:27
them in a month or two now?"
- 17:29
How do I basically keep that excitement
- 17:30
going on?
- 17:32
Right?
- 17:33
Build fast with today's stack. Like,
- 17:34
don't try to invest in these like high,
- 17:36
you know, super like plat, you know,
- 17:39
architectures and have these like 6 9
- 17:41
months of long projects and things like
- 17:43
that. How do you turn around these
- 17:44
things in weeks, days, and so on?
- 17:47
And just be comfortable with the fact
- 17:48
that you are constantly going to be
- 17:49
re-architecting. That's fine.
- 17:51
Right?
- 17:53
Just don't over-invest in the current
- 17:54
architecture. Just make sure that you
- 17:56
keep your like flexibility out there.
- 17:58
Um and then the feedback loops. I think
- 18:00
that's what kind of like gives you
- 18:01
really that like, you know, the
- 18:03
incremental part of like that hockey
- 18:04
stick exponential part of the thing.
- 18:06
Um we constantly publish like blog
- 18:08
posts, I mean, where we kind of like try
- 18:10
to have our, you know, learnings shared
- 18:12
with uh our customers and so on. Like,
- 18:14
we have blog posts on like how we do
- 18:16
agent instructions, how we do our
- 18:17
structured data with semantic views, you
- 18:19
know, how we basically build our
- 18:20
rack-based like knowledge assistants,
- 18:22
the non-technical side of the story,
- 18:24
like how do you derive change
- 18:25
management, and so on. So, feel free to
- 18:27
check those.
- 18:28
Um and yeah, I think that's the end of
- 18:31
my talk.
- 18:33
Okay.
- 18:36
>> We have time for one question.
- 18:39
Okay, there you go.
- 18:47
>> Thanks for the talk. Um I don't know if
- 18:49
you already said this, but I saw in the
- 18:51
the titles of the articles Snowflake
- 18:53
Intelligence. Is that an underlying
- 18:56
context or layer that the tool or system
- 18:59
you built was on top of, or was that
- 19:02
the tool itself or something else?
- 19:04
>> Yeah, Snowflake Intelligence, we renamed
- 19:06
that to Snowflake Co-work a couple of
- 19:08
weeks ago in our summit. That's
- 19:09
basically our no-code agent platform
- 19:11
that we basically build have available
- 19:13
for our business users.
- 19:16
I mean, the advantage of that is that
- 19:17
all of these tools are on like, you
- 19:18
know,
- 19:19
you know, Cortex analyst or Cortex
- 19:22
search or Cortex sense, a lot of those
- 19:23
things are basically comes out of the
- 19:25
box.
- 19:26
We made a strategic choice for our
- 19:27
internal thing where we said that,
- 19:29
"Look, it is important that we bring all
- 19:31
our data together." And we do that in
- 19:32
Snowflake. We bring all the first-party,
- 19:34
the third-party data, all the Salesforce
- 19:36
data, everything, the call transcripts,
- 19:37
and so on, all together. And then these
- 19:39
agents then can basically basically
- 19:41
inherit a lot of the role-based access
- 19:43
controls and so on. And I literally can
- 19:46
deploy these agents without writing a
- 19:47
single line of code, right?
- 19:49
And then, you know, you don't need to
- 19:51
worry about the UI, the chat UI comes
- 19:53
out of the box, and so on. And then we
- 19:55
have been the customer zero of that like
- 19:56
internally to build this ourselves. And
- 19:58
then, you know, our customers are able
- 19:59
to go and then build similar things
- 20:02
basically on Snowflake over platform as
- 20:04
well. And it comes with the guardrails
- 20:05
and things where you don't really need
- 20:07
to worry about them going very, you
- 20:09
know,
- 20:10
crazy on, you know, what data sources to
- 20:13
do things, and so on. So we are able to
- 20:14
do a lot of curation. We are able to do
- 20:16
a lot of security guardrails in there as
- 20:18
well.
- 20:21
Thank you.