The Complete Guide to Building an AI Agent for Enterprise Sales: The 5 Compounding Systems

Let's start with what LLMs actually are, technically, because a lot of the confusion in the market starts here.

1. An LLM is stateless by design.

Every API call starts from zero. There is no persistent state between calls, no internal memory of the last conversation, no awareness of what happened yesterday. The model receives a prompt, generates a response, and that's it.

The next call has no inherent knowledge of the previous one. This is a deliberate architectural choice, one that makes LLMs scalable, but it has a direct consequence for anyone trying to build something on top of them.

2. Most AI products built on LLMs inherit this limitation.

They don't solve it. What they do instead is re-fetch context at the start of each call: pull the conversation history, inject it into the prompt, and let the LLM respond as if it has memory.

This works fine for a chatbot where the conversation is short and context is self-contained. It breaks down when you're trying to build something that genuinely learns over time.

[VIDEO CLIP: Jon on stateless LLMs and what that means for products built on top of them, ~60 sec | Episode 1, Q2]

‍

‍

1. Most AI products call what they ship "memory."

The problem isn't the word — it's that what they're actually shipping is history. There's a real difference between the two.

History is a transcript. It's a written record of what was said. Memory is something richer: context, trajectory, the external factors that were present in a given moment. Think about a childhood memory. You're not just recalling a sequence of words from a conversation. You're remembering what was happening on the playground, what the weather felt like, the emotional texture of that moment. Multiple data points come together to make it a memory rather than a record.

So what most AI products are doing is giving you a very sophisticated transcript. They're storing what you said and feeding it back. That's history. Memory requires understanding the context — the variables surrounding a situation, not just the words exchanged in it.

To build something that actually learns, something that can trace the reasoning about the trajectory of a deal over time, notice the behavioral shifts in how reps interact with the system, and connect a pattern you see in Q3 to something that happened in Q1, you need a fundamentally different data architecture.

To do this, we centralized all our operational data and built a separate data layer that specializes in time-series processing. The key design decision here: your operational data isn't static. It's always changing. A deal that was at 70% close probability on Monday, might be at 45% by Thursday. If you're training on or reasoning with that data, you need to be able to reconstruct what it looked like at any given point in time. You need to be able to rewind.

That time-series foundation is what makes it possible to analyze the actual velocity and trajectory of what's happening: not just the current state, but where things were, how fast they moved, and what was happening in the surrounding context when they did. That's the difference between a lookup and a memory.

If you want to build a system that genuinely learns from your sales data, this is the first major engineering problem you have to solve. Everything else depends on it.

[VIDEO CLIP: Jon on the distinction between memory and history, the playground analogy, ~45 sec | Episode 2, Q3]

‍