How we're building the first autonomous, self-learning GTM system for B2B SaaS
The Infinite Execution Paradox
Something strange has happened in go-to-market.
We've built tools that can spin up domains and send millions of emails. Products like Clay, Parallel, and Exa can index entire markets in hours. LLMs generate near-infinite personalized copy, scripts, and chat conversations. Generic orchestration tools wire events together in minutes.
Execution has become effectively infinite.
And yet, pipeline is harder than ever to build. Response rates are cratering. Buyers are drowning in noise. The best SDRs spend their days sifting through false positives while real opportunities slip through the cracks.
The paradox is this: we've solved the wrong problem.
We built infrastructure for doing more. We should have built infrastructure for knowing what to do.
The bottleneck is no longer execution. It's decision quality. Given virtually unlimited execution capacity, how do we allocate finite resources (e.g. human time, inbox space, ad dollars, brand capital) to the right accounts, at the right time, with the right plays?
This is the question Warmly was built to answer.
Part I: The AI Landscape: A Tectonic Shift
The First Wave: Static Data, Information Retrieval
The initial wave of enterprise AI applications targeted domains with a critical characteristic: the answer key exists and doesn't change much.
Look at where AI is winning today. The pattern is unmistakable.
Legal AI: Harvey raised $300M and is valued at over $1B. Why? Legal precedent is static. Case law from 1954 still applies today. The corpus is fixed. The task is retrieval and synthesis over documents that were written decades ago.
Code AI: Cursor has become the fastest-growing developer tool in history. Why? Programming languages have formal grammars. Code either compiles or it doesn't. Tests either pass or fail. There's a verifiable ground truth.
Medical AI: Perhaps the most developed category, with tens of billions flowing into companies tackling physician burnout, operational inefficiencies, and diagnostic accuracy. Abridge alone is worth more than most public SaaS companies. Anatomy doesn't change, drug interactions are catalogued, clinical guidelines are documented.
Customer Support: Sierra is winning this category by building AI agents that handle inquiries, resolve issues, and escalate appropriately. The problem space is bounded: product documentation is fixed, common issues follow patterns, resolution paths are well-defined.
Recruiting: Mercor is winning here through AI that screens candidates, conducts assessments, and matches talent to roles. Job requirements are structured, skills are enumerable, candidate evaluation follows established frameworks.
These companies are creating enormous value. But notice what they all have in common:
The answer key exists. The corpus is stable. The task is pattern matching.
The AI doesn't need to learn how medicine, law, coding, support, or recruiting works in real-time. It needs to retrieve and reason over information that was true yesterday and will be true tomorrow.
This is why RAG (Retrieval-Augmented Generation) became the dominant architecture. It works beautifully when:
- The answer exists somewhere in your corpus
- The corpus doesn't change much
- Retrieval quality is the binding constraint
But what happens when none of these conditions hold?
The Second Wave: Dynamic Environments, Continuous Learning
The next frontier of AI isn't information retrieval. It's dynamic reasoning in environments where the answer key is always changing.
Consider GTM:
- Your ICP shifts as your product evolves
- Competitive positioning changes quarterly
- Buyer personas vary by segment and market condition
- What worked last quarter may not work this quarter
- Every deal is different, and every company's GTM motion is unique
There's no static corpus to retrieve from. The "right" answer depends on context that didn't exist six months ago. The model needs to learn continuously from outcomes, not just retrieve from documents.
The companies that win this wave will build something fundamentally different: not AI that retrieves answers, but AI that develops judgment through continuous interaction with dynamic environments.
What Palantir Understood First
Before LLMs, Palantir competed with Snowflake and Databricks on data infrastructure. The market saw them as enterprise data platforms, expensive, complex, government-focused.
Post-LLMs, Palantir no longer believes they have any competitors.
Why? Because they made a different architectural bet.
Snowflake and Databricks optimized for SQL and query throughput: get raw data into tables, run fast analytical reads, ship dashboards and models on top. They built infrastructure for answering questions about data.
Palantir built an ontology, a world model where data is represented as objects, relationships, and properties. Nouns, verbs, adjectives. Named entities, typed relationships, constraints. Not tables and joins, but the way humans actually think about their domain.
When LLMs arrived, this ontology became the perfect interface. Models don't want a trillion rows. They want a structured, language-shaped substrate: something you can linearize into a coherent prompt, traverse, and act on.
The results speak for themselves: 30%+ year-over-year growth accelerating, 50%+ growth in U.S. Commercial, one of the fastest-growing enterprise software stocks.
The market is recognizing something important: ontology beats query optimization when AI is the consumer of your data.
Palantir proved the thesis. Now the question is: who builds the ontology for each vertical?
For government intelligence and defense, Palantir won. For GTM, the seat is empty.
The Two Clocks Problem
fTo understand why existing GTM tools can't fill this gap, you need to understand a fundamental architectural limitation. As Kirk Maple points out, every system has two clocks:
- The State Clock: what's true right now
- The Event Clock: what happened, in what order, with what reasoning
We've built trillion-dollar infrastructure for the state clock. Salesforce knows the deal is "closed lost." Snowflake knows your ARR. HubSpot knows the contact's email.
The event clock barely exists.
Consider what your CRM actually knows about a lost deal:
- The state: Acme Corp, Closed-Lost, $150K, Q3 2025
- What's missing: You were the second choice. The winner had one feature you're shipping next quarter. The champion who loved you got reorganized two weeks before the deal died. The CFO had a bad experience with a similar vendor five years ago, information that came up in the third call but never made it into any system.
This pattern is everywhere in GTM:
- The CRM says "closed lost." It doesn't say you were one executive meeting away from winning until their CRO got fired.
- The opportunity shows a 20% discount. It doesn't say who approved the deviation, why it was granted, or what precedent it set.
- The sequence shows 47% reply rate. It doesn't show that every reply came from companies with a specific tech stack you've never documented.
- The account is marked "churned." It doesn't say the champion left, the new VP has a competing vendor relationship, and the budget got reallocated to a different initiative.
The reasoning connecting observations to actions was never treated as data. It lived in heads, Slack threads, deal reviews that weren't recorded, and the intuitions of reps who've since left.
The Fragmentation Tax
Every organization pays a hidden cost for this missing layer. We call it the fragmentation tax: the expense of manually stitching together context that was never captured in the first place.
Different functions use different tools, each with its own partial view of the same underlying reality:
- Sales lives in Salesforce
- Marketing lives in HubSpot or Marketo
- Support lives in Zendesk or Intercom
- Product lives in Amplitude or Mixpanel
- Leadership lives in spreadsheets and dashboards
When a rep needs the full picture of an account, they open six tabs, cross-reference timestamps, ping three colleagues on Slack, and piece together a narrative that will be forgotten by next week.
The fragmentation tax compounds. As organizations scale, the tax grows faster than headcount. As AI automation scales, the tax becomes the binding constraint, because agents inherit the fragmentation of the systems they query.
Why This Matters for AI Agents
This gap didn't matter when humans were the reasoning layer. The organizational brain was distributed across human heads, reconstructed on demand through conversation.
Now we want AI systems to make decisions, and we've given them nothing to reason from.
We're asking models to exercise judgment without access to precedent. It's like training a lawyer on verdicts without case law. The model can process information, but it can't learn from how the organization actually makes decisions.
Data warehouses were built to answer "what happened?" They receive data via ETL after decisions are made. By the time data lands in a warehouse, the decision context is gone.
Systems of record were built to store current state. The CRM is optimized for what the opportunity looks like now, not what it looked like when the decision was made. When a discount gets approved, the context that justified it isn't preserved.
AI agents need something different. They need the event clock, the temporal, contextual, causal record of how decisions actually get made.
The Memory Problem: Why LLMs Can't Do This Alone
Even the most powerful AI models have a fundamental limitation: they can't remember.
LLMs process text in units called tokens. Every model has a maximum context window: the total number of tokens it can "see" at once. GPT-4o has 128K tokens. Claude 3.5 Sonnet has 200K. Gemini 2.0 has 1M.
This sounds like a lot. It isn't.
A single quarter of GTM activity for a mid-market company might include:
- 50,000 website visits with behavioral data
- 10,000 email sends and responses
- 500 call transcripts (averaging 5,000 words each)
- 2,000 CRM activity records
- 1,000 Slack threads about deals
- Thousands of enrichment data points
That's easily 10-50 million tokens, 100x more than even the largest context windows.
When context overflows, models either drop it (truncation) or compress it (summarization). Both approaches degrade the model's ability to learn from precedent, recognize patterns, make consistent decisions, and build institutional memory.
RAG (Retrieval-Augmented Generation) is the standard workaround: store documents externally, retrieve relevant chunks, stuff them into context. RAG works for static domains like legal research.
RAG fails for GTM because:
- The "relevant" context isn't obvious in advance. When deciding whether to prioritize Account A vs Account B, the retrieval problem is as hard as the decision problem itself.
- Temporal relationships matter. RAG retrieves documents, not timelines. It can't answer "did her engagement increase or decrease over the past month?"
- Identity resolution isn't automatic. RAG finds documents mentioning "S. Chen" and "Sarah" and "@sarah" and "[email protected]" but doesn't know they're the same person.
- Synthesis requires structure. Reasoning requires knowledge graphs, not document chunks.
- Features must be computed, not retrieved. "This account has 3+ buying committee members who visited the pricing page in the last 7 days" isn't a document to retrieve. It's a computation over structured data.
This is why the GTM Brain exists.
We're not replacing LLMs, we're giving them persistent, structured memory they can't build themselves.
The LLM brings reasoning. We bring memory.
The Context Graph Opportunity
Foundation Capital recently argued that the next trillion-dollar platforms won't be built by adding AI to existing systems of record, they'll be built by capturing decision traces, the reasoning that connects data to action.
They call this the context graph: a living record of decision traces stitched across entities and time, so precedent becomes searchable.
This insight is exactly right. But it's incomplete.
You can't capture decision traces without first solving the operational context problem: identity resolution, entity relationships, temporal state, the substrate that makes decision graphs possible.
And you can't build a general-purpose context graph that works for every domain. The companies that win will build domain-specific world models that encode how their particular category actually works.
For GTM, that means building a system that understands not just what happened, but why buyers buy, why deals die, what signals predict action, and how to allocate scarce resources against infinite opportunities.
That's what Warmly is building: the GTM Brain.
Part II: What Tesla Taught Us About Learning Systems
The Self-Driving Analogy
There's a reason Tesla's Full Self-Driving is the most instructive analogy for what we're building.
Like GTM, driving is a domain where:
- The environment is dynamic and unpredictable
- There's no static answer key, every situation is unique
- Decisions must be made in real-time under uncertainty
- The "right" action depends on context that changes constantly
- Human judgment is the baseline to beat
Tesla's approach to this problem offers a blueprint for building AI systems in dynamic domains.
Imitation Learning: Watching Humans Do the Work
Tesla's breakthrough wasn't building better sensors or more powerful computers. It was imitation learning at scale.
Here's how it works:
- Observe: Millions of Tesla vehicles capture how humans actually drive, like steering inputs, braking patterns, lane changes, reactions to unexpected events.
- Model: Neural networks learn to predict what a human driver would do in any given situation. Not what a rule-based system says they should do, but what they actually do.
- Simulate: Tesla built a massive simulation environment where AI can practice billions of driving scenarios without risk.
- Refine: When the AI makes a mistake in the real world, that edge case gets added to the training data. The system continuously improves.
- Verify: Before deploying updates, Tesla runs shadow mode, the AI makes decisions in parallel with human drivers, and the system compares outcomes.
The key insight: you don't program driving rules. You learn them from the accumulated experience of millions of human drivers.
World Models: The Simulation Advantage
Tesla's most important technical innovation isn't the neural network itself. It's the world model, a learned representation of how the driving environment behaves.
The world model enables simulation, prediction, and crucially, counterfactual reasoning. What would have happened if I had braked earlier? If I had changed lanes? This is how the system learns from near-misses, not just crashes.
The GTM Parallel
The GTM Brain applies the same architecture:
- Observe: Ingest every signal from the GTM environment like website visits, email engagement, CRM activities, call transcripts, product usage. Watch what human sellers do in response to these signals.
- Model: Learn the patterns that predict success. Which signals indicate buying intent? Which messaging resonates with which personas? Which accounts look like your best customers?
- Simulate: Before committing resources to an account, simulate the likely outcomes. What's the probability of conversion? What's the expected deal size? What's the optimal engagement strategy?
- Refine: When deals close or die, capture the outcome and feed it back into the models. Learn from every success and failure.
- Verify: Run the AI's recommendations in shadow mode against human judgment. Measure accuracy. Improve.
Just as Tesla doesn't hand-code driving rules, we don't hand-code GTM rules. We learn them from the accumulated experience of thousands of deals.
Why This Approach Wins
The imitation learning approach has three structural advantages over rule-based systems:
1. It handles complexity that can't be specified.
Driving has millions of edge cases. You can't write rules for all of them. But you can learn from how humans handle them.
GTM is the same. Every company has unique dynamics. Every buyer is different. Every deal is shaped by context that's impossible to anticipate. The only way to handle this complexity is to learn from experience.
2. It improves continuously.
Rule-based systems are static. Learning systems improve with use. Every mile driven makes Tesla's AI better. Every deal processed makes the GTM Brain smarter. The system compounds.
3. It captures tacit knowledge.
The best human sellers have intuition that they can't articulate. They "just know" which deals are real and which are tire-kickers. They "just know" when a champion is losing internal support.
This tacit knowledge is embedded in their behavior, even if they can't explain it. Imitation learning captures it by observing what experts do, not what they say.
Part III: The GTM Brain
Beyond RAG: A GTM-Native World Model
What the market needs is not an AI wrapper. Not another chatbot or "AI for your CRM."
It needs a stateful GTM decision system that:
- Ingests millions of buyer signals (website, CRM, product, intent, social)
- Resolves people and companies across tools using a proprietary identity graph
- Learns a temporal world model of your market, an ontology and knowledge graph custom-tailored to each company
- Computes mathematically grounded probabilities and expected values for every account and contact
- Exposes a Human Strategy Layer so leaders can steer the system
- Decides what to do next (or not do) under real constraints
- Orchestrates agents across web research, enrichment, buying committee mapping, inbound, outbound, and response
- Continuously improves itself via backtesting and simulation
It replaces both the GTM software stack and a large portion of the GTM people stack (e.g. SDRs, RevOps, Marketing Ops, researchers, analysts) with a single, self-learning engine.
The OODA Architecture
The GTM Brain operates as a closed-loop system:
Observe: Raw GTM events and data flow in continuously, like website visits, CRM activities, email engagement, product usage, intent signals, people moves, firmographics.
Orient: The system maintains a world model, an ontology of companies, contacts, signals, segments, and plays. Features are computed. Models generate predictions.
Decide: The Policy Layer maps state to actions (including the decision to do nothing) under real constraints (e.g. inbox limits, ad budgets, AE capacity, brand fatigue)
Act: Agents execute work such as research, enrichment, buying committee mapping, inbound chat, outbound sequences, response handling.
Learn: Every outcome feeds back into the system. Models improve. Policies adapt. The world model expands.
The Architecture Split
This system has a clear separation of concerns that makes it structurally different from pure LLM approaches:
- Models compute: State, weights, relationships, readiness, priority (deterministic)
- LLMs narrate: Recommendations, messaging angles, next best action (probabilistic)
- Summary stores remember: "Account XYZ looks like ABC; historically, do this" (persistent)
This matters because LLMs are expensive and weak at real-time sifting across huge context windows. They can't build and condense a world model in real-time. But they're brilliant at reasoning over a world model that's already built.
The GTM brain stores exactly the right context, primitives that model to the GTM world, rather than asking an LLM to reconstruct context from scratch every time.
Why "GPT Wrappers" Can't Do This
Here's the architectural reality that separates production systems from demos:
The inference-time trap: GPT wrappers try to build context at inference time. The agent queries multiple systems, stitches together data, reasons over it, and generates a response, all in one request. This approach has fatal flaws:
- Token consumption: Every request rebuilds context from scratch. Costs explode.
- Latency: Minutes to assemble context before reasoning can start. Real-time use cases become impossible.
- Hallucination: Model fills gaps when data is missing. 80% accuracy isn't acceptable for GTM decisions.
- Inconsistency: Different context windows produce different answers. Same question, different day = different prioritization.
- No learning: Context is discarded after each request. Can't improve from outcomes.
Our approach: pre-compute, store, serve
The context is computed, stored, and summarized ahead of time. When an agent needs to act, whether responding to a chat message or deciding which account to prioritize, it queries pre-computed state, not raw data. The reasoning happens at the edge, fast, with the right context already in memory.
You can't vibe-code this. A weekend hackathon can build a demo that queries your CRM and generates a personalized email. It cannot build an identity graph that resolves millions of signals to canonical entities, a temporal fact store that tracks state changes with validity periods, real-time streaming infrastructure, async job systems for multi-step workflows, summary stores that compress years of history, and feedback loops that connect outcomes to model updates.
This is production infrastructure. It takes years to build and battle-test.
The 100% Precision Primitive
Here's the insight that separates Warmly from everything else in the market:
When you want to automate GTM, it can't be 80% right. It needs to be 100% right, or at least better than a human, for full automation to be possible.
Most AI products get to 80% accuracy with 20% of the effort. That's enough to close a pilot. But production demands 99% or more, and that last stretch can take 100x more work.
So we build primitives, identity resolution, buying committee mapping, signal scoring, account prioritization, entity extraction, temporal reasoning, each designed to accomplish specific tasks with near-perfect precision.
These primitives are then composed into end-to-end workflows. When each component works at production quality, the whole system can run autonomously.
Part IV: Delight, Hard-to-Copy, Margin-Enhancing
Delight: The System Your Team Uses Every Day
The GTM Brain isn't a dashboard you check weekly. It's the operating system for revenue, the system you use every day to answer the fundamental question: "Who do I target right now, and what do I say?"
Every morning, it tells each rep:
"Here are the five accounts you should focus on today, ranked by expected value. Account A has three people on the buying committee actively researching solutions. Here's who they are, what they've looked at, and what message will resonate."
Every week, it tells leadership:
"Here's how the strategy is performing. Outbound to Series B fintechs is converting 40% better than Series A. The 'ROI calculator' play is underperforming, here's why. Three accounts are at risk of churning, here's what's happening and what to do about it."
Every quarter, it answers:
"What would happen if we shifted focus to enterprise? If we doubled outbound volume to healthcare? If we changed the ICP to include companies with 200+ employees?"
Current GTM tools create work. They require reps to manually log activities, update stages, write notes, and maintain data hygiene. The "user experience" is actually a data entry job disguised as software.
Warmly collapses this complexity.
Hard-to-Copy: The Context Graph Moat
The GTM Brain's defensibility comes from what accumulates inside it: decision traces.
Every time the system decides to prioritize an account, reach out to a contact, or hold back on an action, it generates a trace: what inputs were gathered, what features were computed, what policy was applied, what outcome resulted.
This enables the question that makes learning possible: "Given what we knew at that time, was this the right decision?"
Do this thousands of times. The weights get updated. Historical and in-production performance converge. Eventually the model achieves 90%+ accuracy. At that point, why would you rip it out?
These traces form a context graph, a structured, replayable history of how context turned into action. Over time, this graph becomes:
- A world model of your market: Which signals predict buying intent? Which messaging resonates with which personas? Which accounts look like your best customers?
- A source of precedent: When a similar situation arises, the system can query how it was handled before. What worked? What didn't?
- A simulation engine: Before taking action, the system can run counterfactuals.
Competitors can copy features. They can't copy the accumulated decision intelligence that lives inside the system.
Margin-Enhancing: Accessing the Services Market
Here's the market reality most GTM software companies miss:
The GTM software market is approximately $100B. The GTM services market, human labor for SDRs, AEs, RevOps, Marketing Ops, analysts, is approximately $400B.
Most GTM software reduces friction for existing workflows. It makes humans 10-20% more efficient. That's valuable, but it's fighting for a share of the software market.
Warmly replaces workflows entirely. That means we're accessing the services market, not just the software market.
The GTM Brain inverts traditional economics:
- SDRs: The research, prioritization, and initial outreach that SDRs do manually? Automated.
- RevOps: The workflow building, data cleaning, and reporting? Automated.
- Marketing Ops: The campaign logic, segmentation, and attribution? Automated.
This isn't 10% productivity improvement, it's 10x efficiency. Teams grow pipeline without growing headcount proportionally.
We're not selling seats. We're selling outcomes.
Part V: Why Now? The Confluence of Forces
The "Services as Software" Shift
AI will rewrite software economics by delivering outcomes rather than selling seats.
The old model: Pay $X per user per month for access to a tool. Hire people to use the tool. Hope they use it well.
The new model: Pay $X per outcome delivered. The software does the work. Humans supervise and handle exceptions.
The Infrastructure is Finally Ready
Building the GTM Brain required infrastructure that didn't exist three years ago:
- LLMs capable of reasoning: GPT-4, Claude 3, and Gemini 2 can understand context, make judgments, and generate quality output.
- Efficient inference: Test-time compute and model optimization have made it economically viable to run complex reasoning at scale.
- Identity resolution at scale: Graph databases, entity resolution algorithms, and data infrastructure can now handle the matching problem.
The Buyer Has Changed
B2B buyers don't want to talk to sales reps anymore. They want to self-serve. They want to research independently. They want to engage on their own timeline.
But they also want personalization. They want to feel understood. They want to interact with vendors who know their business, their challenges, their context.
These demands are contradictory, unless you have a system that can deliver personalization at scale without human intervention.
The Incumbents Can't Adapt
Traditional GTM systems were built for a world where humans did the work and software stored the records. Their architectures optimize for:
- Current state storage (not temporal reasoning)
- Human-driven workflows (not autonomous agents)
- Feature expansion (not outcome delivery)
- Per-seat pricing (not value capture)
Rebuilding these systems for an AI-native world would require gutting their core architecture. They can add AI features at the edges, but they can't become AI-native without breaking everything that makes them work.
This is the classic innovator's dilemma. The incumbents are too successful to change.
The Coexistence Reality
To be clear: CRMs survive. They remain the system of record for state, the canonical customer record, the opportunity pipeline, the contact database.
What we're building is different: the system of record for decisions.
We're not asking companies to rip out their CRM. We're adding the layer that makes the CRM, and every other tool in the stack, actually intelligent.
Part VI: The Organizational World Model
The Three Layers
The ultimate vision for the GTM Brain is to become what Palantir built for government intelligence: an organizational world model where data is represented the way humans actually reason about it.
The GTM Brain follows a three-layer architecture:
1. Content Layer (Evidence): Immutable source documents, the evidence trail. Emails, call transcripts, website sessions, CRM activities. Content is never edited, merged, or deleted. It's the canonical record of what was captured.
2. Entity Layer (Identity): What content mentions, such as people, organizations, places, products, events. This is where identity resolution happens. "Mike Torres" in an email, "M. Torres" in a meeting transcript, and "@miket" in Slack become the same person.
3. Fact Layer (Assertions): What content asserts, such as temporal claims about the world. Not just "the account is in-market" but "the account started showing intent on March 15" and "the intent signal weakened on August 3 when their budget got frozen." Each fact has a validity period, a status, and links to the entities and content it references.
The World Model Advantage
This three-layer architecture enables something traditional GTM tools can't do: simulation.
Want to know what would happen if you changed your ICP? Run a simulation over the ontology.
Want to understand why a certain segment isn't converting? Query the fact layer for patterns.
Want to predict which accounts will close this quarter? The model already has the features, it's been tracking them continuously.
The GTM Brain becomes a simulator for organizational physics: how decisions unfold, how buyer journeys progress, how signals predict outcomes.
This is what experienced sellers have that new hires don't, a mental model of how deals actually work. The GTM Brain makes that model explicit, queryable, and continuously improving.
The "Fixed Model, Expanding World" Insight
Many argue AI isn't transforming the economy because models can't learn on the job. Continual learning is hard, expensive, and brittle. That diagnosis is mostly right.
But it misses the point.
World models offer a different path: keep the model fixed, expand the world it reasons over.
If the world model keeps growing, capturing trajectories of state → action → outcome, a static model can behave as if it's learning. Not by updating weights constantly, but by performing better inference over richer evidence.
More trajectories mean better inference. Not because the model changed, but because the world model did.
This is why backtesting works. We can simulate how much qualified pipeline you would have captured had you followed our scoring model. You can see the historical counterfactual and the forward simulation.
Part VII: The Compounding Intelligence Moat
The Flywheel
Every customer that uses Warmly generates decision traces. Those traces improve the models. Better models deliver better outcomes. Better outcomes attract more customers.
This is a compounding advantage. The system gets smarter with use, not just for individual customers, but across the entire network.
The Integration Moat
The GTM Brain requires deep integration with customer systems (e.g. CRM, marketing automation, sequencing, enrichment, intent, product analytics, communication tools).
Each integration takes time to build and maintain. Each one creates switching costs. The more integrated the system, the harder it is to rip out.
But the real moat isn't the integrations themselves, it's what accumulates through them. The identity graph that resolves entities across systems. The signal history that enables temporal analysis. The decision traces that capture how the organization actually operates.
The Network Effect
Unlike most enterprise software, our system has cross-customer network effects:
- Identity resolution improves when we see the same person across multiple customers
- Signal patterns become clearer when we see how they play out across different deals
- Buying committee structures become predictable when we've seen thousands of similar companies
- Optimal messaging emerges from patterns across the entire customer base
Every customer makes the system better for every other customer. This compounds into something exponentially harder to compete with over time.
The Ground-Truth Data Moat
This is the unsexy moat that nobody in AI wants to talk about.
LLMs are inherently messy, probabilistic, and hard to debug. Data systems must be deterministic, auditable, and correct. But real-world data is never perfect. The art is managing the randomness and mitigating garbage over time.
Companies can't just immediately build a trustworthy, battle-tested system that produces robust company, contact, and signal data with correct waterfalls. It's taken us years to get right, trial by fire on where the breaking points are.
Take website de-anonymization. The time horizon for knowing if the data is correct can be months. But over time, we've built ways to manage the uncertainty. All data degrades over time. The moat is in managing that degradation.
Website visitors are our #1 signal: volume, accuracy, and richness of intent inside tracking who visits, when, and what they do.
The #1 predictor of becoming an opportunity: unique number of buying committee members visiting your website in the past 30 days.
For some companies, this is millions of visits per month. Triangulating state, ICP tier, and intent across that volume, then actioning appropriately, is a business in itself.
Get good data. Store it correctly. Manage it correctly. Then reap the rewards of agentic improvements.
Conclusion: The Decision Layer
The Story So Far
The problem: AI made GTM execution infinite, but pipeline is harder than ever to build. We solved the wrong problem, we built infrastructure for doing more, not for knowing what to do.
The diagnosis: Every system has two clocks. We've built trillion-dollar infrastructure for the state clock and almost nothing for the event clock. The reasoning that connects data to action was never treated as data.
The opportunity: The next trillion-dollar platforms will capture decision traces, the context graph that makes precedent searchable. But you need domain-specific world models.
The analogy: Tesla proved that dynamic, complex domains can't be solved with rules. You have to learn from accumulated experience. GTM has the same characteristics as driving.
The solution: The GTM Brain, a stateful decision system that ingests signals, resolves identities, builds a world model, computes expected values, decides what to do, executes through agents, and learns from outcomes.
The moat: Decision traces compound. Network effects accelerate. Switching costs lock in.
The vision: Every morning, it tells each rep what to do. Every week, it tells leadership what's working. Every quarter, it simulates strategic alternatives. The operating system for revenue.
The Bet We're Making
The debate right now is whether AI will transform enterprise software or just add features to existing categories.
Our answer: the next trillion-dollar platforms will be systems of record for decisions, not just data.
Traditional systems of record store current state. The GTM Brain stores decision intelligence: the reasoning that connects data to action, the traces that capture how choices were made, the world model that enables simulation and prediction.
CRMs don't go away. Warehouses don't go away. But neither of them can do what we do: capture the event clock, build the world model, and make AI agents actually intelligent about your business.
What We're Building
This is what Warmly is building. Not another tool in the GTM stack. Not a chatbot for your CRM. Not "AI features" bolted onto existing workflows.
The GTM Brain, a single, self-learning engine that:
- Sees every signal across your entire GTM surface area
- Resolves identities and builds the entity graph
- Captures decision traces and accumulates precedent
- Reasons over context that no other system can see
- Decides what to do (including when to do nothing)
- Executes through specialized agents
- Learns from every outcome
- Gets smarter every day
The companies that build this infrastructure will have something qualitatively different. Not agents that complete tasks, organizational intelligence that compounds. That simulates futures, not just retrieves pasts. That reasons from learned world models rather than starting from scratch every time.
The Path Forward
We're building the decision layer for GTM. And like Tesla learned with driving, like Palantir learned with intelligence analysis, the key is not to program the rules. It's to learn them from the accumulated experience of thousands of practitioners.
The event clock isn't just a metaphor. It's an architecture.
And we're making it operational.