But all of that was still about shaping conversation. The model reads a prompt, generates an answer, and someone (human or system) says good or bad.

Now I want to describe the next leap, and this post is about that. It is about what happens when you take the model out of that box and put it somewhere it can actually do things. Run commands. Click buttons. Fail at tasks and try again. Because here’s the thing nobody says clearly enough:

The moment a model can take actions, you can train it on experience.

That’s a different kind of signal entirely. And it’s where the next wave of improvement is coming from.The big picture is actually pretty intuitive once you see it. So let me try to lay it out.

Why environments matter more than prompts

A text-only chatbot is trained on what good answers look like. You show it examples of good writing, good explanations, good code, and it learns to produce more of the same. The feedback is essentially aesthetic — does this look right? Does it sound right?

An agent in an environment is trained on what success looks like. It can run a command and see if the command worked. It can edit a file, rerun the tests, and find out whether the bug is actually fixed. The feedback isn’t aesthetic anymore, it’s functional. Did the thing actually work?

That distinction is everything. And precisely the reason why the AI industry is suddenly obsessed with containerized benchmarks and tool-use evaluations. Not because benchmarks are fun, but because testable environments are training substrates. They produce exactly the “how to do things” data that the internet never had a reason to create.

Let me walk you through a few concrete examples, because this is one of those things that’s much easier to understand with specifics.

Terminal tasks: real work, packaged and testable

If you want to see what the cutting edge of agent evaluation looks like, Terminal-Bench 2.0 is a good place to start. It’s a benchmark of 89 tasks set in real terminal environments, inspired by the kind of work actual engineers and sysadmins do. Set up a server, configure a database, debug a networking issue, that sort of thing.

What makes it interesting for our story is that each task comes with comprehensive tests to verify the final system state. The grading is automated. Either the server is configured correctly or it isn’t. Either DNS resolves or it doesn’t.

Frontier models and agents scored under 65% overall on these tasks, which tells you we’re not in “solved problem” territory. And here’s a number that still makes me do a double-take: in extreme cases, agents ran for up to two hours, made hundreds of model calls, and burned through nearly 100 million tokens on a single task.

A hundred million tokens on one task. That’s not “write a nice answer.” That’s “keep going until the job is actually done, or give up trying.” The long-horizon, keep-banging-on-it quality of the work is what makes it both hard and useful as a training signal.

Code tasks: unit tests as the reward function

If terminal tasks are “ops work,” SWE-bench is “engineering.”

The idea behind SWE-bench Verified is beautifully simple: take real GitHub issues from real open-source projects, with real test suites, and ask the model to fix them. The benchmark includes 2,294 instances in the full set and 500 in the human-validated “Verified” subset.

Why does this matter for the “getting smarter” story? Because unit tests are an automatic reward function. The model generates a patch. The tests run. If they pass, that trajectory gets reinforced. If they fail, they get discouraged. No human needed in the loop.

This is how AI coding starts to look less like generating text and more like training a policy. The model isn’t just producing code that looks plausible. It’s producing code that works, and learning from the differences.

Web tasks: harder than you’d think

At this point you might assume that if a model can use a terminal and write code, surely it can navigate a website. Click some buttons, fill out some forms, and find some information. Not so fast.

That five-to-one gap on web navigation is a useful gut-check. Agent doesn’t mean solved. Navigating a real website requires spatial reasoning, state tracking, and knowing what a page means even when the layout changes and current models still struggle with all of that.

But that gap is also an opportunity. Every failed web task is a training signal. Every successful one is a demonstration of what good behavior looks like. The gap between 14% and 78% is where the next round of improvement will come from.

RL for tool use: learning to orchestrate

Once a model can take actions in an environment, the reinforcement learning framing becomes natural. The state is what the agent sees: terminal output, web page content, tool responses. The actions are what it does: run a command, click a button, edit a file. The reward is whether the task succeeded.

Bespoke Labs published a nice write-up on using RL to improve multi-turn tool use, showing meaningful gains on a tool-use benchmark with a relatively small amount of data.

The specific numbers matter less than the pattern: put the model in an environment where success can be checked, then let it learn by trial and error.

There’s a catch though and it’s important to address it. Without carefully designed rewards and constraints, RL can go sideways fast. The model finds weird shortcuts, games the metric, or explores aimlessly. The trick is not “do RL.” The trick is “do RL in environments where success is well-defined and the rewards don’t have loopholes.” That’s hard to get right, and it’s a big part of why this stuff is progressing steadily rather than overnight.

Test-time compute: the think harder knob

Here’s one more piece that ties together everything from Part 1 and Part 2.

You can make a model perform better by letting it spend more compute when answering a hard question. Generate several candidate answers. Run checks against each one. Backtrack if something looks off. Pick the best result.

OpenAI has been explicit that their reasoning models improve with more time spent thinking at inference. It’s like the difference between blurting out the first thing that comes to mind versus pausing, working through the problem, and double-checking before you commit.

In product terms, this means: if the question is easy, respond immediately. If it’s hard, slow down and be careful. That single design decision is responsible for a lot of the “it suddenly got way smarter” feeling people have been reporting.

Memory, Part 2: the missing piece for real work

In Part 1, I described memory as personalization. The system remembers your preferences and facts about your life. That’s useful for casual conversations and everyday questions. But for agents doing real work, memory becomes something different. It becomes “state”.

If you want an agent that can help you with a project over days or weeks, it needs to remember: what files it touched last time, what constraints you care about, what the plan was, what already failed. Without that continuity, every conversation starts from zero, and the agent is useless for anything that takes longer than a single chat session.

This is why memory is shipping across every major platform right now: not as a nice-to-have, but as the thing that makes agents viable for actual work.

Open AI - ChatGPT

Saved memories + chat history reference. Temporary Chat mode available for sessions you don’t want stored.

Google - Gemini

Temporary Chats with their own retention policies. Google’s take on the same tradeoffs.

Anthropic - Claude

Optional, editable memory with incognito mode. For developers: an explicit memory tool agents can read and write across sessions.

Under the hood, all of these systems work roughly the same way: extract interesting things from the conversation, store them, retrieve relevant ones later, and inject them into context. It’s not fundamentally different from a developer keeping notes in a project README. But it’s the thing that transforms a stateless function call into something that feels like a collaborator.

Robotics: same loop, harder data

Everything so far has been digital: terminals, code repos, web pages. The environments are virtual, and running another thousand trials costs electricity but not much else.

Robotics is the same intellectual story, but with a crucial practical difference: the environment is the physical world, and data is expensive to collect.

You can’t just spin up another container. You need a physical robot, a physical workspace, and real time. This is why robotics research is obsessed with datasets and demonstration pipelines. The bottleneck isn’t the algorithm, it’s the data.

A few examples of how the field is tackling this:

Open X-Embodiment (the RT-X project) assembled a dataset of over one million real robot trajectories spanning 22 different robot embodiments. This is the robotics equivalent of “scale the dataset and train a generalist” — same instinct as large language models, just applied to physical manipulation.

RoboCat, from DeepMind, made the self-improvement loop explicit. Their blog describes a five-step process: collect 100 to 1,000 demonstrations of a new task, fine-tune the model, let it practice about 10,000 times to generate more data, add that data back into training, and train the next version. That is reinforcement learning in the most literal, tangible sense: practice, measure, improve, repeat.

RT-2, also from DeepMind, took a different angle. They trained a model that learns from both web data and robotics data, essentially asking: can the language understanding you get from reading the internet transfer to controlling a robot arm? The robot demonstration data was collected with 13 robots over 17 months in an office kitchen environment. Seventeen months of 13 robots making lunch. The patience required is staggering, and it’s also why progress in robotics feels slower than progress in software — the feedback loop just takes longer to close.

The loop that makes people say “exponential”

Now step back and look at the whole picture.

When people say AI progress is accelerating, what they’re reacting to is the closing of a feedback loop:

1. The model can take actions - use a terminal, write and run code, navigate a web page, and move a robot arm.

2. Success can be measured automatically - tests pass, tasks complete, and rubrics are satisfied. No human needed in the loop.

3. Successful trajectories become training data. The model learns from what actually worked

4. Better training data produces a better model, which generates even better trajectories on the next round.

5. Go back to step 1. Each generation bootstraps the next one

If that loop gets cheap, fast, and mostly automated, progress feels non-linear, because it is. Each generation bootstraps the next one.

There are real brakes on this, and they’re worth being honest about. Evaluation is hard to get right, bad metrics produce bad models. Reward hacking is real. Models find creative ways to game benchmarks without actually being useful. Safety constraints add friction, intentionally. And in the physical world, everything moves at the speed of atoms, not bits.

But the direction is clear. We’re going from:

Models that talk → Systems that act → Systems that learn from acting

And that’s the deepest reason they keep getting smarter

What this looks like in practice: sales as an RL environment

Everything I’ve described so far shares a structure. There’s an environment. The agent takes actions. Outcomes are measurable. The loop closes.

The pattern holds outside software too. Take sales. A sales call is an environment. The rep asks discovery questions, handles objections, creates urgency, tries to close. The outcome is measurable: did the deal advance, did the stakeholder engage and you don’t need a human to label it. The CRM and the next call tell you.

This is exactly the loop we’re building at AmpUp. Here how it maps:.

Observe. Every call gets processed through LLM extraction. We score behaviors from a dynamic ontology of hundreds of possible patterns, customized per customer and industry. We extract deal intelligence, stakeholder signals, coaching moments, and reusable techniques. Every interaction produces structured data, not just text.

Recommend. Before the next call, the system pulls from four memory systems. What happened on prior calls. What the org has learned across hundreds of deals. What playbook moves work at this stage. What this specific rep needs to improve. After the call, it produces an updated deal state, coaching on specific moments, and the single highest-impact next action.

Measure. Did the rep follow the advice? Did the deal move? Did the behavior improve? Every outcome gets linked back to the recommendation that preceded it. Revenue lift analysis is the reward signal. Which behaviors actually correlate with deals moving forward?

Learn. Behaviors that predict wins get promoted in coaching. Strategies that don’t move deals get deprioritized. The playbook grows with every call. Top performers’ best questions, objection handles, and closing techniques get extracted, cleaned up, and made available to every rep on the team. When a senior seller leaves, their expertise stays.

The insight is the same one that makes SWE-bench work for code. You don’t need humans in the loop to generate the reward signal. Deal advancement is the unit test. The CRM is the test runner.

The models aren’t getting smarter by reading more sales books. They’re getting smarter by influencing the sales behavior of real sellers. Observing real calls, measuring what moves deals, and building organizational memory that compounds with every interaction.

The 30-second version, if you read both parts

Part 1: The internet is the base layer. The real training signal is now human feedback, expert judgment, and structured preferences - a multi-billion-dollar industry. Memory adds a personal layer on top.

Part 2: When models can use tools and operate in environments with testable outcomes, their successes and failures become training data. That creates a self-reinforcing loop. The same story is playing out in code, web tasks, and robotics — just at different speeds.

The models aren’t getting smarter by reading more Reddit.

They’re getting smarter by doing things, failing, and trying again with increasingly good taste about what “good” looks like.

Not so different from the rest of us, really.

This is Part 2 of a two-part series. If you missed it, Part 1: How LLMs Keep Getting Smarter covers RLHF, the alignment supply chain, and why expert data is worth billions.

“How does this thing keep getting smarter when the internet is full of nonsense?”

It’s a great question. And if you go looking for the answer, you’ll find yourself neck-deep in research papers about reinforcement learning from human feedback, constitutional AI, reward modeling, and a dozen other terms that each require their own dedicated time. I end up spending a lot of time in these rabbit holes in order to keep an up-to-date understanding of where the tech is and where it’s going.

This post is my attempt to climb back out and explain what I found.

A quick recap

In 2023, I wrote a four-part series breaking down how ChatGPT works: Transformers, embeddings, attention, the whole engine. If you haven’t read it, the short version is: these models learn to predict the next word by reading enormous amounts of text, and the Transformer architecture is what makes that work at scale.

That story hasn’t changed. Transformers are still the engine. But the engine isn’t the interesting part anymore. What’s changed dramatically is everything around the engine. How the models get shaped after training, who’s doing the shaping, and why the whole operation now involves PhD-level experts getting paid $125 an hour to tell a model it’s wrong.

My friend didn’t need a lecture about attention heads. He needed someone to explain the new stuff. So that’s what this blog tries to do.

From pre-training to post-training

If you read my 2023 series, you can skip this. If you didn’t, a base language model is trained to predict the next word. You then feed it the entire internet, let it read billions of sentences, and eventually it builds a surprisingly rich internal model of how language works. Facts, style, reasoning patterns: it absorbs all of it, along with plenty of garbage, because the internet is full of it.

That’s pretraining. It gives the model raw capability.

Then comes a second phase, which is post-training. It’s where you take that capable-but-chaotic base model and shape it into something that behaves like an assistant, something that follows instructions, is helpful, avoids saying terrible things, and generally acts like a product instead of a weird autocomplete engine.

In 2023, I treated post-training as a footnote. But it’s 2026, and post-training is arguably the story.

Three dials, and only one of them is obvious

When my friend says that LLMs are getting smarter, he’s reacting to improvements that come from turning three knobs. Most people only know about the first one.

Dial 1: Throw more compute at training. This is the obvious one: bigger models, more GPUs, and longer training runs. But the nuance people miss is that the compute isn’t just going into pretraining anymore. A serious chunk now goes into reinforcement learning after pretraining. OpenAI has been unusually direct about the fact that their reasoning models improve with more “train-time compute”, and they’re talking about the RL phase, not just reading more on the internet.

Dial 2: Better data but not more internet. This is the part most people miss entirely, and it’s where the money is flowing. I’ll spend a lot of time on talking about this in this blog.

Dial 3: Think harder at inference time. Even without changing the model, you can get better answers by letting the system spend more time on harder problems such as generating multiple candidates, checking its own work, backtracking when something doesn’t look right. OpenAI calls this “test-time compute” and describes performance improvement as the model is given more time to think. If the question is easy, answer fast. If it’s hard, slow down and verify. That single product decision changes how smart the system feels to a user.

Keep these three dials in your head. Everything else described in this blog is basically an implementation detail for Dial 2.

RLHF: turning human taste into a training signal

Most people have a vague sense that RLHF - Reinforcement Learning from Human Feedback exists. Few have internalized what it does and why it matters so much.

Here’s the setup. You have a base model that can generate text. You show it a prompt, and it produces several possible answers. Then you ask a human: Which of these is better? The human picks one. Do this thousands of times, and you have a dataset of human preferences, not correct answers in a textbook sense, but a record of what humans actually prefer when they read these outputs.

Now here’s the clever part: once you have enough of these preference rankings, you can train a separate model that predicts what humans would prefer. And once you have that preference model, you can use it to train the actual language model at scale, without a human in the loop for every single example.

The canonical description of this pipeline comes from OpenAI’s InstructGPT work. The paper lays out three steps: supervised fine-tuning (humans write good answers), preference data collection (humans rank model outputs), and optimization (train the model to produce the kind of outputs humans prefer). They started with 40 contractors doing the labeling.

Forty people. That’s it. And from that modest beginning, they got a result that should permanently change your intuition about how these systems work:

A 1.3-billion-parameter model, after alignment, was preferred by humans over the 175-billion-parameter base GPT-3. The small model, roughly 130 times smaller, trained with feedback, beat the giant model trained without it because it had better post-training data.

This is the single most important intuition in modern AI: pretraining gives a model capability, but post-training gives it behavior. And behavior is what people actually experience.

This then became an industry overnight

Let me walk you through a few examples, because I think economics tells the story better than any technical paper.

Surge AI went from being a relatively unknown data labeling company to, according to Reuters reporting, generating over $1 billion in revenue and seeking to raise up to $1 billion at a valuation above $15 billion. That’s the market telling you exactly how valuable high-quality training signals have become.

Scale AI had a cautionary moment. When Meta took a large stake in Scale, Google reportedly planned to cut ties, largely due to concerns that the Meta involvement could expose proprietary AI plans. OpenAI followed suit, which means: the prompts, rubrics, and failure cases used to train a model are now treated as strategic intellectual property. Your training data pipeline is your secret sauce, and you don’t want it anywhere near a competitor.

Handshake, a college recruiting platform pivoted into data labeling and, according to Lenny’s Newsletter, was on track to blow past $100 million in annual recurring revenue in 12 months. Why? Because they had a network of domain experts: something the AI labs desperately needed. Handshake’s CEO told Business Insider that the industry is shifting from generalist labelers to specialized STEM experts, with people earning $100 to $125+ per hour on the platform.

Mercor raised $350 million at a $10 billion valuation, doing something similar that is connecting AI labs with domain experts for training data.

The Verge wrote a good overview tying all of these companies together, and the picture it paints is striking: the most valuable data in AI is no longer text scraped from the web. It’s structured expert judgment. If this feels like a weird twist in capitalism, that’s because it is. The scarce resource in AI is no longer compute or data in the traditional sense. It’s the structured expert judgement - It’s people who can tell the model when it’s wrong and explain why.

So why doesn’t it become “garbage in, garbage out”?

This is the question my friend was really asking, and by this point, you can probably see the answer.

The internet is the base layer. It gives the model vocabulary, world knowledge, and a general sense of how language works. But the internet is not what shapes the product you interact with. That layer comes later.

What you’re experiencing is that the product is shaped by feedback: human preferences, expert rubrics, test results, and carefully designed reward signals. That’s why a model trained on the whole internet can produce something that feels thoughtful and careful instead of sounding like a random Reddit thread.

A simple way to think about it is: Pretraining is the clay. Post-training is the sculpting.

The internet taught LLMs what things are, not how to do things

There’s a deeper point here that I think most people haven’t considered. Starting in the late ‘90s, we created massive incentives for people to put content online through ads, social capital, and commercial intent. If you had something to say, or something to sell, or something to promote, the internet gave you a reason to publish it. And all of that content became the training data for the first generation of LLMs.

But think about what kind of knowledge the incentive structure produced. It was overwhelmingly descriptive. What is the capital of France? What year did World War II end? What are the symptoms of diabetes? How does photosynthesis work? The internet is spectacularly good at declarative knowledge — facts, explanations, opinions, descriptions of how the world is.

What’s mostly missing is procedural knowledge - how you actually do things. How do you do your taxes when you’re a freelancer with income in two states? How do you build a marketing campaign for a B2B SaaS product with a $50K budget? How does a doctor actually work through a differential diagnosis when a patient presents with vague symptoms? Even when people write “how-to” guides, they tend to stay abstract. The messy, step-by-step, judgment-heavy process of doing real work rarely makes it onto a blog post, because there’s no incentive to publish it, and it’s hard to articulate anyway.

This is why LLMs are remarkably good at expository writing: essays, summaries, explanations but have been much less impressive at actually doing things the way humans do them. The training data was lopsided.

What’s starting to change

What’s changing as we bring LLMs into the flow of real work: coding, data analysis, customer support, research. They’re starting to observe and participate in procedural tasks. Every time an agent writes code and runs it, debugs an error, navigates a workflow, or helps someone through a multi-step process, that interaction is generating exactly the kind of procedural data that was absent from the original internet. Slowly, that data is building up. And it’s going to make these systems dramatically more useful.

It’s also, frankly, a little scary from an employment perspective.

If the first generation of LLMs could write like us, the next generation is learning to work like us. My default view is it’ll work out better as these tools tend to make individuals more capable rather than replacing them entirely but it’s a transition worth thinking about honestly.

This also sets up Part 2 of this series, where we’ll look at how agents operating in real environments are generating this kind of procedural data at scale and why that changes the pace of improvement.

Memory: the reason it feels like it’s learning you

Now let’s talk about the part that makes people say “it’s getting to know me.”

If you use ChatGPT, Claude, or Gemini regularly, you’ve probably noticed they remember things across conversations. Your preferences, facts about your life, things you’ve told them before. It feels like the model is learning.

What’s actually happening is less magical than it sounds and more practical than most people think.

Memory is almost never the model changing its weights. The underlying neural network itself is the same for everyone. What’s different is a per-user layer on top . A useful way to think about it like the model is an application, and memory is your personal config fileIn practice, memory systems tend to remember two categories of things:

Preferences. Things like “use simple language,” “stop using em dashes,” or “when you link my LinkedIn in a post, make it sound natural, not like a press release.” These seem trivial, but they’re incredibly high-leverage because they remove friction from every future conversation.

Personal context. Information that changes how responses should be tailored. Things like “I have a 13-year-old daughter who’s interested in coding” or “I asked about how to prep her for USACO.” A single fact like that changes how the assistant answers dozens of future questions, from programming language recommendations to summer camp suggestions.

Under the hood, most memory systems work roughly the same way: extract candidate memories from conversation, store them as structured text (sometimes with embeddings for retrieval), fetch relevant ones when you start a new chat, and inject them into the context. That’s it. Not consciousness, not a learning brain. Just retrieval plus context injection.

That said, memory is legitimately controversial. There’s a real tension between “this is useful” and “I didn’t realize it was keeping a file on me.” That tension is worth taking seriously. But if the goal is to understand why these systems feel like they’re improving over time, the framework is pretty clean:

Pretraining gives the model language.

Post-training gives it behavior.

Memory gives it you.

Where this is headed

Everything I’ve described so far is about shaping the model’s responses through feedback, expert data, and personal memory.

In Part 2, the story takes a turn. The model stops being just a chatbot. It becomes something that can act, run code, browse the web, use tools, operate in real environments. And when it can act, something interesting happens: its successes and failures become a new kind of training data.

That’s the feedback loop that has people using words like “exponential.”

We’ll get into it next.

This is Part 1 of a two-part series. Part 2: How LLMs Went From Chatbot to Coworker covers tool use, autonomous coding, web agents, robotics, and why the learning loop is about to get a lot faster.

For the first time in human history, we have two kinds of heirs to teach. Biological ones — children, apprentices, the next generation of people who will carry what we built into a future we won’t see. And now digital ones: AI systems that are, in a very real sense, inheriting our accumulated knowledge, our judgment, our institutional memory.

We’ve spent thousands of years developing sophisticated machinery for teaching biological heirs. We invented schools, apprenticeships, residencies, and mentorship. We understood, at a bone level, that knowledge transmission requires time, struggle, failure, and consequence. You cannot hand someone a textbook and call them a surgeon.

But here’s the point - We are not thinking nearly carefully enough about what we’re teaching our digital heirs. And we are actively dismantling the machinery for teaching our biological ones — at the exact moment we need both.

The Real Leverage - The Twenty Years Spent Behind the Tool

Here are some personal data points. Right now, with Claude Code, I can produce what would have taken me and ten engineers working together. I have twenty years behind me — ML teams at Google running fifty experiments a quarter against a ten-billion-dollar revenue base, CTO of ThoughtSpot scaling to a four-and-a-half-billion-dollar valuation, and now building AmpUp, a sales brain that learns from every customer interaction. With Claude Code, I am thinking harder than I ever have and producing more than I ever could. The leverage AI gives me is real and it is extraordinary.

That is not a brag. It is the setup for the most uncomfortable question I know how to ask.

The tool is powerful in my hands because of everything that came before it. Twenty years of experiments - some successes like spotting the bug before it reached production, closing deals by multi-threading, building architecture that scaled and just as many failures: wrong decisions, models that broke in production, deals I should not have lost, products I should not have built. Twenty years of taking chances, some that paid off, many that didn’t. The AI amplifies what is already there. Every experiment I have run, every risk I have taken, every success and failure I have lived through, that is the substrate the tool is operating on.

Take away the substrate and you do not get ten-engineer productivity. You get something that moves fast and breaks things in ways you do not notice until it is expensive.

So the question is not how powerful this tool can make a senior person. We are answering that in real time. The question is: are you building any path for someone to accumulate twenty years?

The answer, right now, is almost nobody and the numbers are starting to show it.

PwC’s internal slides show entry-level audit hiring falling 39% by 2028. Across all Big 4s, graduate job postings are down 44% year over year. In Big Tech, entry-level roles have been cut in half compared to pre-pandemic levels. Unemployment among recent college graduates has risen 50% since 2022 — while overall youth unemployment held flat.

The jobs did not disappear. They were never created. If one senior person with AI does what eleven used to do, you do not need ten juniors to support them. No one making these decisions is irrational — they are optimizing the metrics that exist. It is locally rational, company by company, quarter by quarter. It is collectively catastrophic, and we are deep into it.

The Vanishing Apprentice: The Junior Wasn’t Cheap Labor. They Were the Curriculum.

Here is what gets lost in the efficiency calculation. The junior was not a cost to be optimized. The junior was a learning organism in a critical developmental window and the work they did, messy and imperfect as it was, served a purpose that had nothing to do with output.

The bad calls, the lost deals, the code that does not scale, the architecture decision that haunts a codebase for three years — that is not waste. That is the curriculum. Senior salespeople got good by being terrible junior salespeople first. Senior engineers got good by writing bad code for three years and having someone senior explain exactly why it was bad. Senior physicians got good by doing residencies, by seeing ten thousand patients under supervision, by making the hard call at 3am and being wrong sometimes and understanding why.

There is no other path we have ever found. Every apprenticeship model in every field requiring deep judgment is built on the same foundation: you must be allowed to fail consequentially, under guidance, long enough to develop instinct.

Instinct is not something you can download. It is something you build, slowly, through the specific kind of suffering that comes from caring about outcomes and getting them wrong.

If you think this is a sales and engineering problem, consider medicine. The oldest apprenticeship model we have — the one we made into law because we understood it was non-negotiable. Now imagine AI handles the diagnostic work that residents currently do. The pattern matching, the differential diagnosis, the routine interpretation. It may be better than a tired resident at 3am. Malpractice exposure goes down. Efficiency goes up. Run that logic for a decade. One day you need judgment — real judgment, built from ten thousand hours of supervised failure — and you look around the room, and the room is full of people who never got the reps.

But some are taking note. And what they’re doing is worth paying attention to.

The Founder Who Said No and Built His Own Rules

A founder I know banned new grads from using AI for coding for their first three months. No exceptions. My first instinct was that it sounded reactionary — the kind of rule that comes from someone who learned on hard mode and wants everyone else to suffer the same way out of nostalgia for suffering.

Then I thought about it.

He was protecting the period where you are supposed to struggle, make errors and learn from it. When you go to the patient’s room ten times, look at the chart with a different lens, until it all clicks as one cohesive story and the diagnosis clears. Where you write the bad code and a senior engineer explains exactly why it is bad and you feel the specific embarrassment that means you will never make that mistake again.

That friction is not inefficiency. It is the actual learning, the curriculum. He felt it before he could fully articulate it, and he built a rule around the feeling.

And to be clear: AI can explain, suggest, and critique. It is a remarkable tutor in many ways. But without stakes — without a world that pushes back and lets things die — the learning stays brittle. Understanding without consequence does not produce instinct. It produces confidence without depth, which is in some ways more dangerous than ignorance.

What Else Gets Lost When the Junior Leaves the Room

There is a second problem hiding inside the first one, subtler and in some ways more dangerous.

Junior people were not just learning. They were bringing a perspective the organization hadn’t yet homogenized. The analyst who asks the question nobody else asked — not because they are trying to be clever, but because they genuinely don’t know it’s not supposed to be asked. The SDR who tries the unconventional pitch because they haven’t learned the conventions yet. The engineer who builds it the wrong way because nobody told them the right way, and occasionally the wrong way turns out to be better.

The junior’s outsider perspective — still forming, not yet shaped by institutional gravity — is something you cannot simulate by adjusting a temperature parameter. And you are eliminating it at exactly the moment you most need people who can see what the system cannot see about itself.

And here is the inversion that should keep you up at night: the way AI gets smarter is exactly the way humans get smarter. Exposure to real problems, action, consequence, correction. which means AI is currently sitting in the apprentice seat. Doing the entry-level work. Accumulating the reps. Getting better every quarter. The human junior is watching from outside the building, updating their LinkedIn, wondering what they did wrong.

In reality, they did not do anything wrong. The seat was quietly reassigned while everyone was looking at something else.

The Common Thread: AI and the Apprentice Learn Exactly the Same Way

There is a principle underneath all of this that applies equally to humans and to AI, and it is the one I keep returning to.

Learning requires consequence. Not information. Not access. Consequence.

But consequence does not mean pain, it is that learning requires feedback your mental model did not predict. The junior engineer who ships the feature and watches it break under real load learns something no amount of code review could have taught them — not because it hurt, but because the gap between their mental model and reality was suddenly, undeniably visible. That is the consequence that matters. It is epistemic, not emotional.

AlphaGo did not get good by reading about Go. It played millions of games against itself, in environments where moves produced outcomes and outcomes updated the model. Your junior SDR does not get good from sales methodology PDFs. They get good from losing deals and sitting with the question of why — because the loss surfaces the assumption they did not know they were making.

This is equally true for the AI models that are actually getting better. The models making the most interesting progress are not the ones with more data. They are the ones in real environments — terminal bench, strategy games, physics simulators — taking actions, observing consequences, updating. That is not a coincidence. The architecture of learning is the same whether the learner is biological or digital.

Both broken apprenticeships have the same root and the same solution.

What Founders Can Actually Do: Moving the Curriculum, Not Losing It

The solution is further along than most people realize —The curriculum does not have to disappear. It has to move. And the tools to move it already exist.

Build deliberate simulation environments. AI roleplay for sales training was the crude first version — stiff, unconvincing, easy to game. But the technology has moved fast. A real simulator generates varied, adversarial, realistic scenarios; gives the learner an actual action space where choices matter; produces consequences(the deal dies, the system breaks, the stakeholder turns hostile)and delivers a structured debrief so you understand not just what happened but what you missed and why.

You can now build that for the entire buying committee behind the closed doors you will never actually be in. The CFO who always kills it on ROI. The champion who goes dark in week three for reasons you will not understand until it is too late. The procurement officer who appears in the final hour with requirements nobody mentioned. The competitor who shows up sideways in the last conversation before the decision. You can give a junior rep five hundred consequential reps before they ever touch a real account. The same logic applies to engineering: simulating production incidents, performance constraints, feature requests with hidden tradeoffs, systems that work locally and fail at scale.

The instinct that used to take three years of real experience can start forming in months of deliberate simulation. Fidelity is everything: A simulator that’s too easy just teaches you to win easy simulations. Make it uncomfortable. Make it honest. This is what we are doing at AmpUp for sellers.

But simulation alone is not enough. We also need structural commitments: protected junior roles that exist specifically for development, not just output. Funded apprenticeships. Policy incentives that make it rational for companies to invest in the next generation even when the quarterly math says not to. The curriculum can move into simulation, but it cannot live there entirely. At some point, the reps have to be real, and someone has to be willing to absorb the cost of letting a junior be junior.

Capture the junior’s arc, not just the seniors’ wisdom. The workflows being automated right now—and the judgment being encoded into your prompts and processes—come almost entirely from your most senior people. The junior’s arc isn’t making it in—not into your systems, not into your processes, not into the organizational layer that will outlast any individual.

Think of it like this: a child raised only on the wisdom of elders, never allowed to fall down and figure out how to get up, does not actually inherit the full culture. It inherits a curated version of it—confident, capable within the known distribution, and missing something it does not know it is missing: the unknown unknowns.

That is the internal AI layer that most companies are currently building. Unlike a foundation model trained on the breadth of human output, your internal systems will only ever know what your people taught them. Right now, that represents only a thin slice of what your people actually know.

What We’re Leaving Behind and What We Are Actually Inheriting

Hawkins worried about what AI would carry forward after we are gone. I am worried about what we are teaching right now and what we are forgetting to teach the humans alongside it.

If AI is genuinely the vessel for what we have built — carrying our accumulated knowledge past the firefly flash of our civilization — then what we put in the vessel is everything. A digital heir that learned by doing, by consequence, by failure and recovery, by the full arc of how expertise actually develops, carries something richer and more durable than one that learned only from what the last generation wrote down when they were already wise. The same is true of the human heirs working beside it.

Simulation is part of the answer. Building real consequence environments for both humans and AI deliberately, at scale, as a design priority — is work that needs to start now and will take a decade to get right. But it is not the whole answer, and the people who need to be working on this problem are not yet working on it with anywhere near enough urgency.

We need more minds on this. Not just AI researchers. Not just HR leaders. Founders, educators, policymakers, anyone who understands that the arc from junior to senior to the kind of senior who builds the next generation — that arc is not optional infrastructure. It is the infrastructure. And it needs to start earlier than we think, in the formative years of education, empowering kids to learn faster in consequence-rich, engaging environments that build instinct for the real world without the real world’s costs

The future is not just being automated. It is being inherited. And right now we are not leaving much worth inheriting.

We gave AI the apprentice seat. The human junior is still outside the building. We need to bring them back in, before there is no one left who remembers what the seat was for.

Welcome to the SaaSpocalypse.

I’m not going to sugarcoat this. If you’re running a traditional SaaS company — one that sells access to software on a per-seat, per-month basis — you are in serious trouble. In early February 2026, nearly $2 trillion in software market capitalization evaporated. Atlassian dropped 35% in a single week. Salesforce, ServiceNow, Intuit — all cratered. Traders at Jefferies coined the term “SaaSpocalypse” and described the selling as “get me out” style.

Satya Nadella said it plainly: SaaS applications are “essentially CRUD databases with a bunch of business logic,” and that business logic is migrating to the AI tier. When the CEO of the company that defined the modern software industry tells you the model is dying, you should listen.

But here’s what I want to tell you that nobody else is saying: the SaaSpocalypse isn’t about AI replacing your software. It’s about you running a software company when you need to be running an AI company. Those are fundamentally different things. And the journey from one to the other is the hardest transformation you’ll ever make — harder than going from on-prem to cloud, harder than going from perpetual licenses to subscriptions.

I know because I’ve made that journey. Four times — at Microsoft, Google, ThoughtSpot, and now AmpUp. More on that in a moment.

The Five Stages of SaaSpocalypse Grief

Before I tell you what to do, let me tell you where you probably are. Every SaaS CEO I talk to is somewhere on this spectrum:

Denial. “We already have AI features. We added a chatbot last quarter.” Bolting AI onto your SaaS product is like putting a spoiler on a minivan and calling it a race car.

Anger. “This is just hype. Our customers aren’t going to switch.” You might be right — for the next 12 months. But the companies building AI-native alternatives are getting smarter every day, and your product is staying exactly the same.

Bargaining. “Maybe we can acquire an AI company. Or hire a Head of AI.” This is the most dangerous stage because it feels like action but it’s actually avoidance. You can’t outsource your way to becoming an AI company any more than Blockbuster could have outsourced its way to becoming Netflix.

Depression. “Our moat is gone. A teenager with Claude can replicate our core product in a weekend.” Partially true — but code was never your real moat. Your understanding of your customer’s problem was.

Acceptance. “We need to fundamentally transform.” If you’re here, keep reading. This is where the real work starts.

I’ve lived this transformation four times — at Microsoft, Google, ThoughtSpot, and now AmpUp — and I’ve been on both sides of it. I’ve seen what doesn’t work (4–6 month AI cycles at Microsoft, like running a marathon in ski boots), what does work (shipping 50 experiments a quarter at Google against a $10B revenue base), and what happens when you’re doing AI before anyone believes in it (building a $4.5B company at ThoughtSpot starting in 2012). What I learned across all four: the transformation from SaaS company to AI company requires you to rethink nearly everything about how your company operates. Not “add an AI feature.” Not “hire a machine learning team.” Rethink everything.

SaaS Company vs. AI Company: It’s Not What You Think

Everyone is talking about “adding AI” to their product. That’s the wrong frame entirely. The difference between a SaaS company and an AI company isn’t whether you use machine learning somewhere in your stack. It’s a difference in DNA.

Here’s the simplest test I know: if you turned off every AI component in your product tomorrow, would your customers still pay? If yes, you’re a SaaS company with AI features. If no, you might actually be an AI company.

Gong without AI is still a call recording and CRM platform. Salesforce without AI is still a database with forms. Atlassian without AI is still a ticketing system. Turn off the AI and the product still works. The AI is decoration. Valuable decoration, maybe — but decoration.

AmpUp without AI is nothing. AmpUp (ampup.ai) is building a sales brain — a continuously learning engine that gets smarter from every customer interaction, every call, every deal. It prepares reps before every conversation, coaches them after, and compounds those learnings across the entire organization. There is no product without the AI. The AI doesn’t enhance the experience; the AI is the experience.

Apply the “turn off the AI” test to your own company. Be honest about what you find.

But the difference goes deeper than product architecture. It’s a different way of building, a different way of thinking, and a different way of making promises. And that last word — promises — is where the transformation has to start.

Step 1: Stop Selling Access. Start Making Promises.

The single most important shift in becoming an AI company isn’t technical. It’s about fundamentally changing what you offer your customers.

A SaaS company sells access. “Here’s a login. Here’s what you can do with our tool. Good luck.”

A better SaaS company sells capability. “Our platform enables you to manage your sales pipeline, track your metrics, and coach your team.”

An AI company makes a promise — a specific, measurable outcome it commits to delivering. “We will deliver X outcome in Y timeframe — and we’ll prove it.”

The progression from access to capability to promise is the entire SaaS-to-AI journey in three words.

And until you know what promise you’re making, nothing else matters — not your architecture, not your hiring plan, not your AI roadmap. The promise is the North Star that everything else serves.

At AmpUp, our promise is specific: we will bend the sales growth curve for your company so it is closing 30–100% more in incremental ACV in the next 6 months. That’s AmpUp’s promise — yours will be different. But the reason we can make that promise is because every interaction generates data about what works. Every pre-call briefing, every post-call debrief, every coaching moment feeds back into the system. We measure whether the rep’s behavior actually changed. We measure whether that change improved outcomes. And we compound those learnings across the entire organization.

Gong can’t make that promise. Gong sells access to a platform that records and analyzes calls. It’s a powerful tool. But it’s a tool. The customer is responsible for translating Gong’s insights into changed behavior and improved outcomes. That’s the gap between a SaaS company and an AI company.

So here’s your first step. Figure out what promise you can make to your customers. Not what features you can build. Not what access you can sell. What promise can you make? What outcome will you deliver?

Step 2: Rethink Your Engineering Culture

This is the part nobody wants to hear. But once you’ve committed to a promise, you’ll immediately realize your current engineering culture can’t deliver it.

Your SaaS engineering culture — the one that made you successful — is optimized for the wrong things. Your best SaaS engineers gather requirements, do principled design, anticipate worst cases, and ship polished, well-tested features. That discipline built your company. It’s also what will kill it.

Compare the mindsets:

At Google, my team didn’t build features. We built the infrastructure to run 50 experiments a quarter, measure them with statistical rigor, and ship the ones that moved the needle. That scaffolding was our real competitive advantage, not any single algorithm.

Your best SaaS engineers might be your worst AI engineers. The habits that made them great can actively work against them.

This doesn’t mean they can’t learn. But it means the transformation isn’t just strategic, it’s cultural and personal. You’re asking people to unlearn the instincts that made them successful.

One caveat: I’m not saying systems engineering discipline goes away. You still need reliable data pipelines, solid APIs, and infrastructure that scales. The AI engineering mindset lives on top of solid systems engineering, not instead of it. The mistake is when that’s the only mindset.

Step 3: Stop Building Features. Start Building Scaffolding.

You’ve made your promise. You’ve started shifting your engineering culture. Now here’s the tactical question: what should your engineers actually be building?

If I could give every SaaS CEO one piece of advice, it would be this: the most important code at an AI company isn’t the product. It’s the scaffolding around the product.

What do I mean by scaffolding? The measurement system that tells you whether your AI actually changed a customer’s outcome. The experimentation framework that lets you test 50 ideas a quarter instead of shipping 4 releases. The data collection pipeline that turns every user interaction into training signal. The evaluation infrastructure that tells you if your model is getting better or worse.

Think about what sits underneath Claude or ChatGPT. You see a chat box. A simple text input and a response. But underneath that tiny interface is one of the most sophisticated scaffolding systems ever built — RLHF pipelines, evaluation frameworks, measurement systems, data collection infrastructure, safety testing, red-teaming processes. The iceberg underneath the waterline is massive.

The visible product is 10% of the value. The scaffolding is the other 90%. Most SaaS companies have the iceberg upside down.

Fire your product roadmap. I mean it. A SaaS company has a 12-month roadmap with committed features. An AI company has a 12-month learning roadmap with hypotheses to test. Replace “Build Advanced Analytics Dashboard — Q3” with “Achieve 15% improvement in customer outcome X — Q3, via 20 experiments.”

Step 4: When Code Is Free, Taste Is the Edge

Here’s the most counterintuitive thing I’ll say in this entire blog: in the age of AI, the most valuable skill isn’t engineering. It’s taste.

Generating code is now essentially free. A capable developer with an AI coding assistant can produce in hours what used to take weeks. The barrier to building software has collapsed. Which means your competitive advantage can no longer be “we have good engineers who can build complex software.” Everyone can build complex software now.

So what’s actually scarce?

Product taste. The judgment to know what to build and, more importantly, what not to build.

Customer understanding. The deep, almost intuitive understanding of what your customer is actually trying to accomplish — which is often different from what they say they want.

Positioning. The ability to incept a concept in a customer’s mind. To create a category, name it, and own it before anyone else even realizes it exists.

Taste in AI product design. AI is brilliant 80% of the time and baffling 20% of the time, and the UX is what bridges that gap. At ThoughtSpot, we were radically data-poor and we learned that smoothing the jagged edge isn’t a technical problem. It’s a product taste problem. Thoughtful UX that sets the right expectations, fallback mechanisms that maintain trust, feedback loops that close the gap over time. That playbook works whether you have a billion data points or a thousand.

Look at why Claude is beating ChatGPT for a significant and growing segment of users. It’s not because Anthropic has a fundamentally better model. It’s because Anthropic has better taste. They understood a specific user deeply — the thoughtful knowledge worker who wants a thinking partner, not a parlor trick. That’s product taste plus customer understanding plus positioning. And it’s winning against a company with 10x the resources and a massive head start.

And this connects directly back to the promise. When you’re selling access, taste is a nice-to-have — users will tolerate clunky UX if the tool is useful. When you’re making a promise about outcomes, taste is existential. Because the AI will be wrong sometimes, and taste is what keeps the customer trusting your promise while the system learns.

When code is free and models are commoditized, the company with the best taste wins.

Step 5: Your Moat Is Your Rate of Learning

If I had to distill everything I’ve learned across Microsoft, Google, ThoughtSpot, and AmpUp into a single principle, it’s this: your moat is not your code, your data, or your brand. Your moat is your rate of learning.

The company that runs 50 experiments a quarter will crush the company that ships 4 releases a quarter, even if the second company has 10x more engineers and 100x more data. Because each experiment teaches you something. Each learning compounds. And over time, the gap becomes uncrossable.

This is what I lived at Google. We weren’t smarter than the Bing team at Microsoft. We weren’t working harder. We were learning faster. Our cycle time from hypothesis to result was days, not months. That compounding advantage is what made the difference.

Here’s how to think about it mathematically. If your company learns and improves 1% per week through rapid experimentation, and your competitor improves 1% per quarter through traditional releases, after one year you’ve compounded 68% improvement while they’ve compounded 4%. After two years it’s 180% vs. 8%. The gap is exponential, and it never closes.

I know this from the hard side too. At ThoughtSpot — a company that was AI-native from day one — we nearly got killed because our rate of learning about the market wasn’t fast enough. We missed the cloud migration wave by four years. We were selling a bundled stack (database + BI + AI) when customers were moving to unbundled best-of-breed. Both times, the signals were there. Customers were telling us. The data was visible. But we weren’t set up to learn from those signals fast enough and act on them. Rate of learning isn’t just about your models. It’s about everything.

That lesson is literally why AmpUp exists. Our mission is to increase your organizational velocity by two orders of magnitude — because I learned the hard way that being AI-native isn’t enough if you can’t learn fast enough to keep up with where your market is going.

Most SaaS companies don’t even have a “rate of learning” metric. They measure output, not learning.

The Hard Truth About the Journey Ahead

I want to be straight with you. This transformation is going to be brutal.

You will lose engineers who don’t want to work this way, who find comfort in careful design and polished releases.

You will have to rebuild your measurement infrastructure from scratch, because NPS scores don’t measure customer outcomes.

You will ship things that feel half-baked, because you’re optimizing for learning speed.

Your board will push back when you tell them you’re replacing the feature roadmap with a learning roadmap.

Your pricing model will have to change, because you can’t charge per seat when the AI is doing the work.

Your sales team will need to learn to sell promises instead of feature lists. That’s a completely different skill.

All of this is going to be uncomfortable. Most of it will feel like going backward before you go forward.

But the alternative is worse. Because the companies that figure this out — the ones that build the scaffolding, obsess over their rate of learning, develop the product taste to smooth the jagged edge, and have the courage to make real promises — those companies will eat your lunch. Not because they have better code, but because they have better feedback loops and they’re getting smarter every single day while your product stays exactly the same.

Five Principles, If You Remember Nothing Else

If this piece leaves you with anything, let it be these:

Your product is not your moat. Your rate of learning is. The company that compounds learning fastest wins — not the one with the most features, the most data, or the most engineers.

If you can’t articulate your promise, you don’t have one. Not what your product does. What outcome you deliver. If the answer is “we give customers access to a platform,” you’re still a SaaS company.

Build the scaffolding before you build the product. Measurement systems, experimentation infrastructure, feedback loops — these are the 90% of the iceberg that makes the 10% your customers see actually work.

The culture shift is harder than the technology shift. You’re asking people to unlearn the instincts that made them successful. That’s personal, not just strategic.

Learning velocity applies to everything — not just your models. Go-to-market, positioning, pricing, hiring. The companies that treat every function as an experiment will outlearn the ones that only experiment in the lab.

The SaaSpocalypse is real. The panic is justified. But panic without direction is just noise.

The path out isn’t “add AI features.” The path out is to become a fundamentally different kind of company — one that makes promises instead of selling access, one that builds scaffolding instead of features, one that measures outcomes instead of engagement, and one that treats its rate of learning as its most precious competitive asset.

In five years, the SaaS companies that survive won’t look like SaaS companies anymore. They’ll be learning machines that happen to sell software. The ones that don’t make that shift will still exist on paper — but they’ll be the next generation of legacy systems, waiting to be acquired for their customer lists.

You already know which stage you’re in.

The only question is whether you move before your customers do — or after.

Let me show you how.

The SKO Hangover

Let’s picture a typical SKO - The Annual Sales Kick-Off. Spanning three days, it typically looks like this:

Day one: vision and celebration.

Day two: product and strategy.

Day three: competitive positioning, new messaging frameworks, objection handling, demo walkthroughs.

Your reps take notes. Everyone seems engaged. Leaders are elated. By the end of day three, everyone’s exhausted but energized. This year will be different.

Two weeks later

A rep walks into a discovery call. The prospect mentions a competitor feature. The rep knows they learned counter-positioning at SKO. It was a good session. But which session? What was the specific angle? Security or scalability?

They fumble through it. Make a mental note to review the deck later. But never do.

What we don’t realize is that the knowledge retention curve is savage. Research on the forgetting curve suggests that in the months following SKO, most of what was taught is gone. In my experience, by week four, maybe 15% of SKO content is still retrievable. By week eight, it’s close to 5%..

While we assume that the SKO influence will stay year long, the half-life of batch learning is brutally short.

Last week I wrote about diagnosis - Why systems can’t identify skill gaps that make reps look like kindergartners. The pushback I got:

“We’re already working on that. Why isn’t it working?”

Because even if you solve the diagnosis perfectly, you’re still trying to feed an ocean through a straw.

What you are doing is Broadcast Enablement while what you need is Predictive Enablement.

The Straw, the Ocean, and Why It Keeps Getting Worse

Your company sits on an ocean of knowledge that could matter in closing a deal - product features, competitive intel, customer stories, industry trends, pricing, persona insights.

And your rep has a straw. On a good week, they get an hour for focused learning. Most weeks, it’s just a five-minute gaps between meetings. Yet broadcast enablement keeps trying to pour the entire ocean through that straw. SKO packs in three days. QBRs, Slack channels, sales enablement sessions, and LMS modules add more.

The assumption is that if we push enough information, something will stick.

But it doesn’t. Most of it spills. When that happens, we tell ourselves the rep didn’t pay attention, didn’t practice enough, didn’t take enablement seriously. But the problem isn’t effort. It’s the underlying delivery model.

The straw was never designed to channel the ocean. It was meant to pull the right drop at the moment it matters. And that flaw in the model is becoming impossible to ignore.

Here are a few real life scenarios -

• A VP at a fast-growing company told me they spent three months building competitive enablement - battle cards, recorded training, practice scenarios. By the time it launched, three competitors had shipped major updates. The content was already outdated. They refreshed it. Three months later, it was stale again.

• At large enterprise companies, the delay is even worse. A feature launches. Engineering writes documentation. Product marketing translates it. Enablement builds curriculum. Content gets reviewed. Legal signs off. Training gets scheduled. Reps finally complete the modules. Basically - Six months from feature launch to field readiness.

Even flawless content is useless if it arrives after the customer conversation where it mattered. That’s not a content-quality issue. It’s a delivery-model issue.

And now the environment is accelerating because of AI.

Product cycles that once took quarters now take weeks. Competitive shifts that used to happen annually now happen monthly. Customer expectations jumped overnight because someone saw a demo on X. As that same VP put it, “We used to update positioning quarterly. Now it feels like it should be weekly.”

The ocean isn’t just large anymore. It’s constantly expanding. But the straw hasn’t changed. You can’t fix this by pushing harder. The model was never built for how reps actually learn today.

How Your Best Reps Actually Prepare

When enablement can’t deliver the right insight at the right moment, reps don’t wait. They adapt. The best reps quietly build their own system.

Here’s what your best rep is doing - (Remember Sarah from last week)Before every customer meeting, she spends 30-45 minutes on specific research. What does this company do? What are their strategic priorities? What problems are they likely facing? How does our product map to those problems? What objections should I anticipate? What customer stories will resonate?

She’s not pulling from some central repository. She’s synthesizing in real-time. Industry news, company earnings calls, LinkedIn activity, analyst reports, product launches, competitive moves.

Every meeting gets custom preparation. This works. But it’s not scalable. Most reps don’t do it because they can’t. They are instead spending time in back-to-back meetings, dealing with admin, trying to close deals.

That’s why reps like Sarah look like exceptions. Like they have some special talent. But really, they’ve just accepted that official enablement won’t help them, so they’ve built their own system.

That’s the real enablement problem.

The question isn’t “how do we get more reps to be like Sarah?” It’s “how do we automatically give everyone what Sarah has to build manually?

From Broadcast to Predictive: A Different Architecture

What if instead of pushing the ocean through the straw, you predicted which single drop the rep needs right now?

From - “Here’s everything you need to know about competitive positioning.”

To: “You have a meeting with a fintech company in 30 minutes. They’re evaluating you against Competitor X. Here’s the one positioning angle that’s worked in the last three deals with similar companies. Here’s the one objection they’ll probably raise and how to handle it. Here’s the one customer story that will resonate.”

Bite-sized. Contextual. Just-in-time.

This is Predictive Enablement.

It’s not just a feature. It’s a fundamentally different model for how sales teams learn and improve. Where broadcast enablement pushes content at reps hoping something sticks, Predictive Enablement does three things simultaneously:

1. Predicts what each rep needs for this specific moment

2. Learns from what actually works in real conversations

3. Coaches in the flow of work, when decisions matter

A GTM strategist puts it : “I should be able to say, ‘I’m meeting a CTO at a financial services company, help me prep,’ and get guidance based on what’s worked in similar conversations.”

Not a quarterly training. Not a 47-page deck. Help that shows up when it matters.

Why You Can’t Retrofit This

You can’t get to Predictive Enablement by adding AI to broadcast enablement. The architectures are fundamentally different.

Broadcast enablement is built for:

• Creating content once, distributing to everyone

• Quarterly update cycles

• Completion tracking as the success metric

• Generic best practices that work “on average”

Predictive Enablement is built for:

• Identifying the specific intervention each rep needs right now

• Continuous learning from actual outcomes

• Application and impact as the success metric

• Personalized guidance based on what’s working today

Different data models. Different feedback loops. Different paradigm.

Why Most “AI Enablement” Fail

Everyone’s talking about AI for sales prep. Most “AI enablement” today is just a chat interface on top of stale content. That’s a faster straw, not a different model.

The Hard Truth: Without proper architecture, you get AI slop at scale. Hallucinations. Generic advice. Confidently wrong recommendations.

Real Predictive Enablement requires what I call a Sales Brain — a deep context graph. It connects every customer conversation to what actually worked, CRM patterns, product knowledge mapped to personas, evolving competitive intelligence, win/loss analysis tied to specific plays, and individual rep skill profiles based on real performance.

The system must know:

• Who the rep is meeting (not just company name, but stage, persona, context)

• What the rep already knows (not what they completed in the LMS, but what they’ve demonstrated in actual conversations)

• What’s worked recently (not best practices from two years ago, but what’s landing right now in similar situations)

• What’s changing (competitive moves, product updates, market shifts that affect this specific conversation)

Then, synthesizing this into something consumable in five minutes - with guardrails. No net-new claims without human review. Internal sources cited with recency. Feedback loops from outcomes so the system learns what actually worked.

Without these constraints, you just get hallucinations at scale. And that’s not better than broadcast enablement - it’s just chaos, delivered faster.

How does Predictive Enablement Change Your Role

In simple words, Predictive Enablement changes the enablement team’s role from content factory to orchestrator.

You’re not manually building every training module. Not manually updating every battle card. Not manually assessing every rep’s skill gaps.

Instead, you’re setting the conditions for the system to learn and adapt: defining what “good” looks like, curating the knowledge sources, identifying the moments that matter, reviewing what the system surfaces, and watching patterns across the field.

The system does all the heavy lifting - synthesis, personalization, just-in-time delivery, and continuous learning from outcomes. You do the more important work - judgment calls, quality control, strategic direction.

Same small team. Massively different leverage.

Imagining this at Scale?

Imagine a three-person enablement team orchestrating personalized coaching for 500 reps in real-time. The system identifies which reps have financial services meetings this week and generates relevant briefs based on what’s worked in similar deals. The enablement lead reviews them, refines positioning, and approves. Reps get exactly what they need when they need it.

Or imagine the system flagging that reps are struggling with a specific objection showing up in 23% of calls. The enablement lead records a five-minute coaching video on how to handle it. The system surfaces it to reps before their next calls, where that objection is likely, and tracks whether it actually helped.

That’s the key: Predictive Enablement doesn’t just deliver content. It learns whether the intervention worked. It’s a self-evolving system.

How We Are Solving This at AmpUp.ai

At AmpUp.ai, we have spent more than a year solving this problem and built Predictive Enablement into the workflow for every rep with Atlas, our AI Sales Coach + Chief of Staff.

Meeting Prep Agent: Atlas knows everything about your prospect before you walk in. Account history, likely objections, stakeholder mapping, and winning plays—delivered automatically for each conversation. Sarah’s 45 minutes of research in seconds.

Practice Partner Agent: Atlas role-plays your toughest objections until you nail them. Trained on your actual buyers and their objections, it helps reps build muscle memory for winning before high-stakes calls.

Call Review Agent: Atlas catches what you missed and turns it into your next win. 100% coaching coverage. Every call reviewed, every rep coached, every moment captured. The system learns what worked and updates the model.

Together, they create that continuous loop: predict what you need, coach in the moment, learn what worked, and get better over time.

That’s Predictive Enablement in practice and that’s what we’re building at AmpUp.ai — happy to share what we’ve learned.

Same week, different conversations.

Last week, I watched Sarah - an enterprise AE prepare for a customer meeting like a chess grandmaster. She started with industry research, then company deep-dive, persona mapping, hypothesis building, and scenario planning.

“Great salespeople do the work outside the meeting,” she told me. “You’re anticipating anything that could happen.”

That same week, I heard three different sales leaders - A VP at a growth-stage company, a CRO at a late-stage startup, a GTM exec at a $25B software giant. All of them used nearly the exact same terms to describe their teams:

“Kindergarteners who need everything spoon-fed.”

“Coin-operated. Won’t do anything unless there’s immediate benefit.”

“No intrinsic motivation to learn.”

But here’s the thing: Both the scenarios can’t be true at the same time, but somehow they are.

The Analogy: The Hospital That Doesn’t Believe in Diagnosis

I’ve spent the last few months talking to a handful of sales leaders across growth-stage and enterprise companies. A strange pattern keeps showing up. Different markets, different products, different stages, but very similar enablement problems.

A GTM executive at that $25B enterprise software company (about 1,800 sellers; 3,500 field engineers) gave me the analogy that explained everything:

“We’re running enablement like a hospital that doesn’t believe in diagnosis. Twenty percent of patients struggle with one issue, so everyone gets that treatment. Thirty percent have something else? Everyone gets that treatment too. We keep adding medications without ever asking if THIS person needs THIS thing. The mortality rate stays high and we blame the patients.”

He calls it Peanut Butter Enablement - Basically spread everything across everyone and hope something sticks.

What really struck me is this company has all the right tools on papers:conversation intelligence, AI coaching, an Learning Management System(LMS), and a dedicated enablement team. And yet, as he put it “We genuinely don’t know who’s good at what.”

Last year their CRO spotted a critical gap. Their sellers were great talking to CIOs but couldn’t speak to line-of-business executives. So they invested/spent eighteen months building industry enablement. They partnered with every vertical team, created comprehensive materials, and integrated an AI coaching platform.

Then they mandated the training for all 1,800 people.

After all that work, they learned something uncomfortable.

“Many of them were already good at industry selling. We just didn’t know who.”

Think about Math for a second. If even 30% of those reps were already competent at industry selling, that’s 540 people who spent hours in training they didn’t need. Meanwhile, the 1,260 who actually needed help got the exact same generic content as everyone else. No personalization. No targeting. Just a very expensive hope that improvement would average out.

And what surprised me most is that this isn’t just an enterprise problem. The companies with the most resources are just as lost as the startups with spreadsheets.

What Happens When Your System Can’t Diagnose

Here’s a test: Without looking at quota attainment. Without asking managers to guess Just from observing behavior alone, can you tell me right now who’s in your team is struggling with:

• Deep discovery versus surface-level questions?

• Getting to economic buyers versus stuck with champions?

• Multithreading versus single-threading deals?

• Navigating procurement versus folding on first pushback?

• Industry conversations versus generic tech talk?

If you can’t answer these questions with confidence, you’re not really measuring sales skills. You’re measuring whether the sales reps still trust that enablement will help them.

~~~~

How Reps Learn When Systems Don’t Help Them

Here’s what Sarah has learned the hard way (the enterprise AE I watched):

Her Tuesday looks like this:

• 9am negotiation meeting with an enterprise healthcare account.

• 11am first discovery call with a fintech prospect.

• 1pm cold calling block across mixed industries.

• 3pm POC requirements review for retail.

• 4pm customer success check-in with manufacturing.

Five different contexts, five different companies. She needs to constantly do the context-switching between verticals, personas, and deal stages. And after every call, she is updating the CRM, sending the follow up emails, briefing internal stakeholders, and prepping for tomorrow’s meetings.

And in this chaos, Sarah learned a few things: battle cards go stale in three months. The LMS returns 1,500 unranked results when you search for anything useful. Role-play feels divorced from actual work. Training gets built for some mythical average rep who doesn’t exist.

So Sarah builds workarounds. She does her own research, finds top performers and asks them directly. She skips the official training because it’s failed her before.

To a manager who doesn’t see this work in the background(lets call it the invisible work), Sarah might look like someone going rogue, not following the process.But Sarah told me: “I love tools that help me get better. I’d use them all the time.I want AI coaching, role-plays, and personalized feedback.

She’s not resistant to learning. She’s just resistant to wasting time on things that don’t help.

That’s not kindergartener behavior. That’s sophisticated pattern-matching from someone who learned the system doesn’t support her.

When Coaching Becomes Random, Fear Becomes Rational

I’ve been selling for the first time in my career this year. The thing that surprised me most is that the biggest blocker isn’t knowledge, It’s actually fear.

Fear shows up camouflaged:

• “I don’t have the vertical expertise” which actually means fear of looking stupid

• “I was being nice to the customer” which actually means fear of losing the relationship

• “I didn’t feel comfortable pushing harder” which actually means fear of their reaction

This is where Sarah’s behavior starts to make even more sense. For instance, Sarah’s real advantage isn’t that she’s smarter than the other reps. It’s that she has confidence. She can qualify hard, get to power players, ask uncomfortable questions, and build champions who do the work for her even when she’s not in the room.

But that confidence came from somewhere. Early wins that build momentum. Good coaching at her first company. Safe practice environment where failure didn’t cost deals and doesn’t invite judgement.

Here’s the connection most sales leaders miss: when systems can’t diagnose problems, coaching becomes random. Random coaching often creates fear because reps can’t predict what “good” looks like.

And when reps stop trusting the system, something else quietly takes over: self-protection.

So they get cautious.

Generic enablement doesn’t address much when the real barrier is emotional. AI role-plays without context don’t build confidence. And battle cards don’t help when you’re scared to use them.

What looks like “no intrinsic motivation” from outside is actually learned helplessness from systems that promised transformation and delivered theater.

How System Failures Turn Into A Death Spiral

When enough reps start operating in self-protection mode, the problem stops being individual and becomes organizational. Each failed tool compounds the diagnosis problem and the rep starts believing: it. “maybe I’m the problem.”

Let’s take a look at how it pans out in reality.

That growth-stage VP? His reps are using Claude for call coaching. It’s a smart idea, but adoption is “inconsistent” because it’s not official. Only the experimenters found it.

The enterprise company? It has five different tools that don’t integrate. The CRO says:

“We spent a boatload. If someone gave us one platform that actually worked, there’s no shortage of dollars.”

But leadership hesitates because reps don’t make the most of the tools provided to them and makes it difficult for them to justify the investments.

And reps don’t use tools because they’ve been burned too many times. The cycle repeats and reinforces itself. Round and Round it goes.

If you can’t diagnose, you can’t really enable. You can only broadcast. And broadcasting is how organizations end up blaming individuals for outcomes the system quietly created.

The label sticks: kindergarteners.

The Uncomfortable Truth: It’s Not Talent, It’s Luck.

Here’s the part I often think about: Elite performers aren’t a different species.They’re often the people the system happened to work for in their early careers. They tasted early wins that built confidence before fear could calcify. They got good coaching when they started (rare, because managers are stretched). They had time to develop habits before pressure ramped up.

Everyone else? They get generic training, tools “on the side,” outdated content, and managers too busy to help them.

The difference isn’t talent. It’s luck. It’s the system’s randomness that happened to break in their favor. And that should bother you. Because here’s what a system with actual diagnosis would reveal:

Let’s go back to Sarah’s preparation ritual at the beginning of this post. That’s not just her being exceptional. That’s a learnable behavior pattern - remaining on top of the Industry research, company analysis, hypothesis building, and scenario planning. Those are discrete and coachable skills that you could identify and measure

But to enable this, you’d need to know who’s already doing them and who isn’t. Right now, you’re giving Sarah the same “how to prepare for meetings” training as to the rep who shows up cold to every call. One of them is wasting their time and the other is developing bad habits because they’re not being pushed.

Neither outcome is good.

What to Actually Do About this

I’m not saying hire better people or invest in more tools.I’m saying build systems that can diagnose.

Stop identifying the best rep based on quota attainment. Stop asking managers to estimate who’s good at what. Stop giving everyone everything and hoping it sticks. Stop the Peanut Butter Enablement.

Instead, start with something simple: track one behavioral signal this week. Not quota attainment. Not activity metrics. Pick one skill from that test above (multithreading, deep discovery, executive access) and just watch who actually does what it in their calls.

Don’t build a dashboard yet. Don’t buy a tool. Just notice the pattern.

That’s a diagnosis. Everything else follows from there.

The technology exists to do this at scale now. But until we deploy it properly, we’ll keep running hospitals that don’t believe in diagnosis. We’ll watch the mortality rate stay high and blame the patients. And we will keep on producing Kindergarteners and make the smart, competent, and capable people end up looking like they need to be spoon-fed.

Where does enablement break first in your org?

I’m collecting stories from sales leaders. Drop a comment or DM me on LinkedIn.

Next week: Why even companies who solve diagnosis still can’t make enablement work. You can’t feed an ocean through a straw, no matter how good your straw is.

The AI world has split into two camps. One says augment humans. The other says automate everything.

However, the debate itself is a trap as it treats augmentation and automation as competing strategies when one is actually the foundation for the other. This notion is built on an incorrect fundamental understanding of how AI actually learns.

Any organization often faces a big strategic choice on how to use AI:

• Conservation Path - A safe incremental approach that uses AI to augment workers and keeps humans in the loop

• Visionary Path - Go bold and automate entire functions that replaces humans and slashes costs

If you want AI to automate complex work, you need augmentation first. Not because it’s safer. Because that’s how AI actually learns. And no, you can’t skip steps.

“Automation is what happens after you’ve turned tacit judgment into transferable knowledge.”

How AI Actually Learns (The Inconvenient Truth)

In practice, AI learns complex work through three channels:

1. From existing documentation and datasets

Medical textbooks, research papers, documented procedures. Billions of lines of open source code with patterns and examples. This works when knowledge is already formalized and available at scale. It’s good for pattern matching, code generation from documented examples, and answering questions from textbooks.

2. From its own trial and error

Playing millions of chess games against itself. Generating and testing variations until it figures out what works. This works when mistakes are cheap, feedback is instant, and failure has no real-world consequences.

3. From observing expert humans

Learning it from the expert itself. For instance - how a master physician reasons through ambiguous symptoms or how a skilled negotiator reads a room and adjusts strategy.

For most valuable work, you need a combination of #1 and #3. And #3 is usually the limiting factor. Let me explain why.

Why Documentation Alone Isn’t Enough

Software development shows both the power and the limits of learning from documentation.

AI coding tools like Claude Code and Cursor work remarkably well because they trained on billions of lines of open source code. Common patterns, standard algorithms, framework usage, it’s all sitting there in GitHub repositories.It’s like learning to cook when you have access to every recipe ever written.

But even in the most documented domain, the most effective deployment of AI is still augmentation.

Developers make architectural decisions based on business requirements and handle novel problems that don’t match training patterns, and understand implicit requirements/ edge cases. The tools achieve 80%+ accuracy on standardized coding benchmarks precisely because those benchmarks test documented patterns. On truly novel problems, accuracy drops significantly.

Now look at domains where even less is documented.

Ask Tom Brady how he reads a defense pre-snap and he’ll give you some rules about safety positioning and linebacker depth. But the real magic is in ten thousand reps that taught him to see patterns he can’t fully articulate.

“We call this intuition. AI calls it missing training data.”

Your top sales performers have the same invisible expertise.

They know when a prospect’s “yes” is actually a “not now.” They read the room in a multi-stakeholder meeting, adjust their pitch mid-sentence, and have the sense when to push or pivot . They navigate complex buying committees, building relationships with the economic buyer while keeping the technical buyer engaged.

The expertise isn’t in databases. It lives in expert practitioners’ heads as patterns accumulated over years, skills built over hundreds of deals, not written in playbooks. Your CRM documents what happened. Your top reps know what to notice before it happens. That’s the gap documentation can’t fill.

Why Trial and Error Fails in High-Stakes Domain

“But wait,” you’re thinking, “can’t AI just learn by trying things and seeing what works?”

Sure. If you have unlimited time, money, and a high tolerance for catastrophic failure.

AlphaGo learned Go by playing itself 30 million times. Worked great. You know why? Because losing a game costs nothing. The stones don’t actually die. The territory doesn’t actually matter. It’s just bits flipping on a computer.

But you can’t let a car drive off a cliff 200 times to learn braking. You can’t let AI learn medicine by making mistakes on real patients.And you definitely can’t let it learn enterprise sales by burning through your pipeline.

We let the AI run 500 discovery calls before it learned not to pitch product features before understanding the customer’s actual problem.

Good news: it learned!

Bad news: your top 50 prospects are never returning your calls.

Simple rule: If failure is expensive, you don’t get to “let the model figure it out.”

The domains where automation would create the most value are precisely the domains where learning through trial and error would be criminally expensive. And in medicine, it would be literally criminal.

So How Does AI Actually Learn Complex Work?

If AI can’t learn from documentation and can’t learn from trial and error (too expensive), there’s only one option left:

It has to learn from expert humans. But here’s the catch: expert knowledge is mostly tacit. Experts can’t fully articulate what they know. They’ve internalized patterns through years of experience that they execute intuitively without conscious reasoning.

Remember Tom Brady? The same thing happens with your top sales rep, your best diagnostician, your master technician. They know more than they can explain.

This is where organizational learning becomes essential. Most sales enablement teaches what to say, but top performers succeed because they know what to notice.

To teach AI complex tasks, you first need to:

1. Observe experts in action across hundreds or thousands of real situations

2. Identify which behaviors actually drive outcomes (causal analysis, not just correlation)

3. Formalize those patterns so they can be taught

4. Validate the patterns work when transferred to others

5. Refine continuously based on results

Notice something? This is the exact same process needed to teach other humans.

The Sequencing Becomes Inevitable

Once you see this, the sequencing becomes obvious.

To automate medical diagnosis, you first need to extract diagnostic expertise from expert physicians. But once you’ve extracted it, you might as well use it to make average physicians better while you’re building toward automation.

In enterprise sales, the same logic applies. You need to identify how top performers qualify, navigate politics, handle objections, create urgency. But those insights are valuable as augmentation permanently, because high stakes buyers prefer human counterparts.

When your top rep knows exactly when to involve the CFO or recognizes that a “pricing objection” is really a “we’re not convinced yet” objection, that expertise is worth millions.

Extract it, Formalize it, Scale it.

That’s not a bridge to automation. That’s your competitive moat.

Your top performers are closing deals today using expertise the rest of your team doesn’t have. Every day you wait to extract and scale - that knowledge is revenue left on the table.

What This Actually Means For Sales Leaders

Sales leaders need to stop asking “should we augment or automate?”. Instead, they need to recognize there are two distinct patterns:

Pattern 1: Augmentation as the Bridge

This applies to domains like software development, customer support, and some operations. Here AI is deployed to help humans learn from top performers in order to extract/ formalize expertise and build the knowledge base. Generally, the economic value is retrieved at every stage with gradual increase in automation as trust and capability develop. This is a journey with a destination.

Pattern 2: Augmentation as the destination : This is useful for high stakes domains like enterprise sales, strategic consulting, complex negotiations. Here AI is deployed to help reps learn from your top 10% performers, extract what makes them successful and scale that expertise across your team. This is what will define your long-term competitive edge.

The difference:

In Pattern 1, augmentation is training wheels.

In Pattern 2, augmentation is the data flywheel.

~~~~~~~

For sales, the math is simple. Your top rep closes at 3x the team average. She reads buying committee dynamics, knows when to bring in solutions engineering, and anticipates procurement objections. That knowledge is worth millions—and it’s trapped in her head.

AI can observe what she does differently, and coach the rest of your team in real-time. That’s not a stepping stone.. That’s a sustainable competitive advantage.

What The Data Actually Shows for the Sales Team

The pattern is playing out across industries, but sales provides the clearest evidence:

Tools that help reps prepare, handle objections, and navigate complex deals create measurable impact. But full automation? Autonomous agent tools work well for high-volume SDR prospecting and qualification. They struggle in complex enterprise sales where deals involve multiple stakeholders, long cycles, and high-stakes negotiations.

The data backs this up. In recent enterprise pilots including a major automotive manufacturer and a leading data analytics platform, we witnessed:

• 30-70% improvements in key sales metrics. One pilot showed a 30% lift in win rates.

• Another identified four critical intervention points, each delivering 50-70% improvement in specific behaviors like objection handling and multi-threading.

These weren’t lab conditions. These were live deals over 6-9 month sales cycles with deal sizes in the high six figures.

So, why does augmentation work where automation struggles? Humans spent 200,000 years learning to judge people and about 50 years learning to judge complex technology. When you’re committing $2Mn over three years, your brain proxies the technology question through a people question: “Can I trust who’s selling me this?”

This isn’t a temporary limitation. It’s evolutionary wiring.

The Bottom Line For Your AI Strategy

To formulate your AI strategy, it’s important to understand who your top performers are, what they do differently, how to observe those behaviors at scale, and how to identify what actually drives outcomes - then transferring that expertise and measuring whether it improves results.

These aren’t software questions. They’re organizational learning questions. And most “AI agent” roadmaps are really learning roadmaps pretending to be automation plans.

You can’t automate expertise you haven’t extracted and formalized. The extraction happens through observation, pattern identification, validation. That process creates immediate value.

For sales leaders, this has clear implications. For instance -

• Your top performers’ expertise is your real competitive advantage

• Extracting and scaling that expertise drives immediate revenue (30-70% improvements)

• You’re not in a race against automation, you’re building sustainable advantages

The companies that move first build moats competitors can’t cross.

So the question isn’t whether to automate or augment. It’s whether you’re extracting expertise systematically and applying it intelligently. Sequential beats direct. Not because it’s safer but because it’s the only path that actually works.

At AmpUp, we’re proving this thesis in practice. Enterprise sales teams are seeing 30-70% improvements in win rates and deal velocity by extracting expertise from their top performers and scaling it across the team.

If you’re a sales leader wondering whether to augment or automate, the real question is simpler: What do your top 10% know that the rest of your team doesn’t? And how fast can you transfer it?

If you’re ready to stop theorizing and start measuring, let’s talk.

Book a conversation here!

The Preparation Cliff

We scored every call on preparation quality (1-5 scale).

Here’s what data showed:

Excellent preparation (5/5) creates a 6.8x multiplier on deal outcomes.

But here’s the uncomfortable truth:

High-quality preparation is functionally impossible at scale.

To prepare well for one call takes 30-45 minutes.

• Research the tech stack

• Map the competitive landscape

• Anticipate objections

When you’re running 6 calls a day, that math doesn’t work.

6 calls × 30-45 minutes = 240-270 minutes i.e. 4-4.5 hours of prep alone. Plus the calls themselves.

So preparation becomes triage.

You skim the website.

You glance at LinkedIn.

Hope for no surprise questions.

When prep takes 45 minutes, inconsistency isn’t a discipline problem. It’s a math problem.

And then they do.

Customer: “Have you worked with anyone in our space before?”

Rep: “I’m no real estate expert, but…”

The customer stops listening. Credibility drops instantly.

We found that in 40% of calls, the customer had to educate the rep on basic facts that 15 minutes of research would have covered.

This isn’t a discipline problem.

It’s an infrastructure problem.

What You Can Do (And Where It Still Breaks)

The following actions materially improve outcomes. But they still depend on individual discipline and memory—which means they don’t scale reliably.

These changes reduce friction and improve consistency.

But they still rely on reps remembering to do the right thing and best responses living in people’s heads.

We don’t have a training problem. We have a retention problem.

You can train your reps on these behaviors today. They’ll remember them for a week. By next month, the forgetting curve will wipe it out.

The scalable question isn’t how to train better—it’s how to stop relying on human memory entirely.

Sarah vs. Marcus

Sarah closed $1.4M last year.

Marcus closed $425K. Same manager, same product.

The gap isn’t talent. It’s pattern recognition.

Sarah knows what supply chain VPs care about because she’s had 50 conversations with them. She knows what “we need to think about it” means. She can read the room because she’s been in this room 200 times.

Marcus has been in this room 8 times. He’s guessing.

The old answer was:

“Marcus needs more reps.”

True, but unscalable. Useless. You can’t compress 18 months of learning into a workshop.

Every sales organization already has its playbook. It’s just scattered across thousands of forgotten conversations.

The question isn’t whether that knowledge exists. It’s whether you can access it before the next call.

Here’s How It Works

[9:15 AM] Sarah closes a deal using a specific reframe with a logistics VP. The system recognizes the pattern. It tags the moment, isolates the winning variable.

[2:30 PM] Marcus has a similar call with a different logistics VP. Instead of making him guess, the system surfaces: “Sarah faced this exact objection this morning. Here’s what worked. Practice it twice before your call.”

Marcus practices it. He enters the call with Sarah’s experience in his back pocket.

The deal advances.

Sarah’s 18 months just became Marcus’s 45 minutes.

The Infrastructure Gap

When we analyzed thousands of meetings across dozens of B2B companies, we found three systemic gaps that training alone cannot fix:

84% — Preparation Failure

Average prep score: 2.0/5. Only 5% achieve excellent prep. The math doesn’t work when good prep takes 30-45 minutes per call.

77% — Objections Unresolved

Only 780 of 3,300 objections fully resolved. 1,850 partially addressed, 680 dismissed. They don’t go away—they metastasize.

41% — Knowledge Gap Damage

Over 1,000 meetings where customers had to educate reps on their own industry. Credibility lost in seconds.

These aren’t training problems. They’re infrastructure problems.

Training vs Infrastructure

Training says: “Remember to ask about quantified pain.”

Infrastructure says: “The last three deals in this vertical stalled because we didn’t quantify pain. Here’s the question that worked.”

Training says: “Prepare better.”

Infrastructure says: “Here’s everything you need to know about this call, synthesized from 50 similar conversations, ready in 3 minutes.”

Training says: “Marcus will figure it out.”

Infrastructure says: “Here’s what Sarah already knows.”

Training hopes. Infrastructure enables.

Organizational Learning Velocity

The speed at which you can identify what’s working, prove why it’s working, and transfer it to everyone who needs it before the insight goes stale.

Most sales organizations optimize for hiring velocity—how fast can we add more Sarahs? But Sarah took 18 months to build her pattern recognition. You can’t hire fast enough to outrun that math.

Today’s competitive advantage doesn’t lie in adding headcount. It lies with the teams that optimize for learning velocity.

If you’re still running on quarterly training cycles and forecast reviews, you’re not competing anymore.

You’re just watching the gap widen.

The gap between your best rep and everyone else isn’t about talent. It’s about accumulated pattern recognition that lives in Sarah’s head and nowhere else.

Until now, the only way to transfer that knowledge was hope. Hope Marcus watches the recordings. Hope he absorbs the lessons.

But hope doesn’t scale.

Systems do.

If you believe your sales team should compound its learning instead of relearning the same lessons every quarter, that’s exactly what we’re building at AmpUp.

See how we clone your best rep →

Connect on LinkedIn →

The Countdown Before The Call

You have 18 minutes before the call.

You pull up LinkedIn. Three people joining.

• VP of Operations you’ve talked to twice.

• Director of IT you’ve never met.

• Someone from finance.

You open their website. Skim the About page. They’re a mid-market manufacturer. They make... industrial components?

You’re not entirely sure.

You check your CRM. Last call notes:

“Strong interest. Wants to see demo of reporting features.”

11 minutes now.

You open your deck. Find the reporting slides. Think about what questions they might ask. Hope the IT director doesn't go deep on security. You handled that objection brilliantly in training six months ago, but right now you can't remember if your data retention policy is 90 days or 180 days, or what exactly "encryption at rest" means to a non-technical buyer.

3 minutes.

You join the call. You’re not unprepared, exactly. You know your product. You’ve done this before. You’ll figure it out as you go.

And you do.

You demo the features. The conversation flows. The questions get answered. Everyone seems engaged, everything looks good.

You suggest a follow-up:

“Let’s touch base next week.”

They agree.

You hang up feeling okay. Not great, not terrible. Okay.

Three weeks later.

The deal is stuck with legal.

Four weeks after that, it’s dead.

You’ll never know exactly why.

“But I do.”

Because I’ve watched this exact pattern play out thousands of times across dozens of companies.

And what kills the deal isn’t what happened on the call.

It’s what didn’t happen in those 18 minutes before it.

The Invisible Patterns Most Sales Teams Miss

We’ve been analyzing sales calls for four months. Thousands of conversations across dozens of B2B companies.

Every call transcribed. Every moment tagged. Every objection categorized.

I thought I knew what we’d find. I spent a decade at ThoughtSpot watching sales teams scale from zero to over $150M. I thought I understood why deals fail.

I was wrong.

Deals don’t die in pipeline reviews. They die in 11-second moments.

The customer says something. The rep hears it. But doesn’t process it.

And three weeks later when the deal stalls, nobody can trace it back to that moment.

Until you can. Until you’ve tagged hundreds of instances of the same mistake across different reps, different calls, different customers.

Here’s what we found:

Deals die not from the things reps do wrong; but from the things they walk right past.

The $2 Million Nobody Heard

A Real Call, A Missed Signal

Call #47. Enterprise SaaS deal. Third meeting.

Eleven minutes in, the customer says:

“Yeah, we’re probably losing about two million a year to this inefficiency. Maybe more.”

Two million. They just handed the rep the number that makes price irrelevant.

The rep responds:

“Got it. Let me show you how the platform works.”

Then they proceed to demo features for the next twenty-three minutes.

Later, when pricing comes up and the customer says “That seems expensive,” the rep crumbles and immediately talks about discounts instead of value.

Why?

It’s not incompetence. It’s cognitive load.

In a live call, the human brain is juggling the demo, the clock, three video feeds and the next objection.

Working memory has four slots. By the time ‘2M’ arrives, those slots are already full.

The rep heard the signal. The brain just didn’t save it.

The signal vanished.

What the Rep Should Have Said Instead

When the customer said -

“We are probably losing about two million a year to this inefficiency. Maybe more.”

The right response wasn’t a demo.

It was a pause followed by a more prepared response.

Here’s what that moment could have sounded like:

“Did you say you’re losing roughly $2M per year? How are you calculating that number? If we could eliminate even half of that, what would that mean for your team?”

Instead of defending price later, the rep would be comparing against a $2M problem and not a line item in a budget.

This is what shifts the conversation from features to impact.

That 11-second moment changes the entire trajectory of the deal.

Why This Works

This isn’t about being clever in the moment.

It’s about freeing up enough mental bandwidth to recognize the signal when it appears and having a simple way to capture it before it disappears.

This is where preparation matters. Not because it’s “nice to have,” but because preparation offloads cognitive memory before the call starts.

If the sales rep had known the customer’s likely pain points beforehand, they wouldn’t have been scrambling.

They would have had the mental bandwidth to hear the signal and lock it in.

But they didn’t. Because in modern sales, preparation is broken.

Coming Up Next:

Part 2: Why Training Can’t Fix This (And What Can)

Discover why even the best training programs can’t solve systemic infrastructure problems—and what actually works to clone your top performers.

2025 was not just the year when AI models got dramatically better; it was also the year we learned how to use them properly.

• Models are increasingly commoditized

• Context prompts, retrieval, memory, reasoning, tools became the real leverage

• Reasoning models, agents, and memory systems are all ways of generating better context

• Fine-tuning fell out of favor; context engineering outperformed it

• Sales is one of the hardest real-time context problems, which makes it the right proving ground to solve

• AmpUp.ai is fundamentally a context engineering platform, not a voice or agent company

Introduction

Three years ago, I wrote a piece demystifying the conceptual stack behind ChatGPT . The response revealed something important: a massive group of practitioners was hungry for first-principles explanations of the shifts driving our industry.

This piece follows a different objective.

It’s about making sense of what happened in AI over the last twelve months, a year that fundamentally shifted where the action is.

If I had to summarize 2025 in one sentence:

We stopped obsessing over the model and started obsessing over context.

If you’re still thinking about AI primarily in terms of models, you’re already behind. The teams that trained the best models in 2023 are not the same teams winning in 2025.

The skill that mattered then (training) is not the skill that matters now (orchestration).

This piece explains:

• why that shift happened,

• what replaced the old paradigm, and

• what it means for anyone building with AI.

To understand why context became the bottleneck, we need to start with the moment models stopped being scarce.

The DeepSeek Wake-Up Call

January 2025. A Chinese AI lab called DeepSeek releases a model that matches frontier performance at a fraction of the assumed cost. The AI community had internalized a narrative: competitive models required billions of dollars, massive GPU clusters, resources exclusive to a handful of companies.

DeepSeek broke that narrative.

The key papers are DeepSeek-V2 (May 2024) and DeepSeek-V3 (December 2024). The technical ideas illustrate a broader point: cleverness can substitute for brute force.

Two ideas mattered:

• Multi-Head Latent Attention (MLA) attacked the memory bottleneck by compressing key/value vectors into a lower-dimensional latent space, reducing KV cache memory by over 90% while preserving quality. DeepSeek compressed these vectors into a lower-dimensional latent space, learning during training what information is essential to preserve. If original KV vectors are dimension d and you compress to dimension c where c << d, you reduce memory by a factor of d/c. They reported 90%+ compression while maintaining quality.

• Mixture of Experts (MoE) attacked the compute bottleneck by activating only a subset of parameters per token. DeepSeek-V3 has 671B parameters, but uses only ~37B per token at inference.

The combination meant DeepSeek trained competitive models for under $6 million.

This raised an uncomfortable question: if the model itself is commoditizing, what actually matters?

The model stays the same. The context gets better.

Most teams are still at Level 2. The frontier has moved.

Once models commoditized, the real innovation shifted to everything wrapped around them.

Breakthroughs of 2025

1. Reasoning Models: The Model Talking to Itself

The first major theme of 2025: reasoning models. OpenAI’s o1 arrived in late 2024. DeepSeek-R1 followed. Anthropic, Google, and others shipped their own.

The core idea: instead of outputting an answer immediately, the model generates a chain of reasoning first, then produces a final response based on that reasoning.

The technical roots of this idea stretch back several years but came together decisively in 2025.

• Chain-of-Thought Prompting (Wei et al., 2022) showed that explicitly asking models to reason step by step dramatically improved performance on multi-step tasks.

• Let’s Verify Step by Step (Lightman et al., 2023) demonstrated that training models to check intermediate steps increased reliability.

• Scaling LLM Test-Time Compute (Snell et al., 2024) formalized a new tradeoff: model capability depends not just on model size, but on how much computation you allow at inference time.

Here’s what took me a while to appreciate: reasoning is just the model generating its own context.

Reasoning models made LLMs appear smarter by making them patient.

When you ask a reasoning model a hard question, it writes itself a scratchpad. It breaks down the problem, considers approaches, catches its own errors. That scratchpad becomes context for generating the final output.

Consider a math problem: “A store sells apples for $2 each and oranges for $3 each. If I buy 5 pieces of fruit and spend $12, how many of each did I buy?”

A standard model might pattern-match and guess. A reasoning model generates:

Each line becomes context for the next. The model is having a conversation with itself, building up the information it needs.

This introduced test-time compute as a scaling axis.

Traditional ML says: to make a model smarter, train a larger model. Reasoning models suggest: let the model think longer.

For some problems, a smaller model reasoning 10x longer beats a 10x larger model that answers immediately. Model capability isn’t fixed. It’s partially a function of thinking time.

Reasoning models are not magic. On tasks where the correct abstraction is unknown, or where verification is impossible, longer chains often make things worse, not better. The model can reason confidently toward a wrong answer.

But for problems with checkable structure, the gains are real.

2. Training Reasoning: The Art of Building Environments

How do you train a model to reason well?

You can’t just show it examples of good reasoning. The model might mimic surface patterns without learning to think. And for many reasoning tasks, there’s no existing corpus of step-by-step solutions.

The answer that emerged, particularly in DeepSeek’s work, was reinforcement learning with a clever trick: focus on domains where you can verify the answer.

DeepSeek’s R1 model trained primarily on math and code. The reason is straightforward:

• In math, you can verify the solution

• In code, you can run the program.

The training loop: the model generates a reasoning chain and answer. Correct answers reinforce the reasoning. Wrong answers discourage it. Over iterations, the model learns what kinds of reasoning lead to correct answers.

What emerged without being explicitly programmed was fascinating. The model learned to backtrack at dead ends. It learned to verify its own work. It learned to try alternative approaches.

These behaviors weren’t hard-coded. They arose purely from the reinforcement signal.

Suprisingly the models trained on code and math got better at everything. The skills required to solve a math problem are the same skills required for complex instruction following in any domain: parse the request precisely, break it into steps, execute without skipping, check your work, correct errors.

A model that learns to work through a multi-step proof has also learned to work through a multi-step business analysis. The reasoning transfers.

This has a striking implication: RL training on verifiable domains may reduce the need for task-specific fine-tuning. If you want better legal analysis, you might not need legal data.

You need a model trained to reason carefully, then provide legal context. The reasoning is general; only the context is specific.

This connects directly to why context engineering became so powerful. When base models improved at following complex instructions, the leverage shifted.

You no longer needed to modify weights for domain-specific behavior. You just needed domain-specific context.

The limitation is real: this works for domains with checkable answers, less well for subjective tasks. Writing, analysis, creative work: you can’t just run a verifier.

For these, researchers turned to Constitutional AI and RLAIF, where another model provides feedback. Promising but messier.

3. Memory: Context That Persists

Language models historically suffered from amnesia. Every conversation started fresh.

2025 changed that.

OpenAI and Google shipped memory for ChatGPT and Gemini. These systems remember facts across conversations: your preferences, your context. For millions of users, AI assistants became meaningfully personal.

MemGPT (Packer et al., 2023) proposed treating memory like an operating system: fast working memory (the context window) plus slower archival memory (external storage). The system learns to move information between layers, loading relevant memories when needed.

Cognitive Architectures for Language Agents (Sumers et al., 2024) organized memory into types: episodic (what happened), semantic (what things mean), procedural (how to do things).

Anthropic’s Claude Skills took this further: users define reusable instructions that apply across conversations. You specify once (“use this coding style”) and it applies automatically. Same weights, different context, different behavior.

The weights stayed constant while the context evolved entirely.

Memory is another form of context engineering that persists context across time while keeping the model unchanged.

4. Agents: Context From the World

If reasoning is self-generated context and memory is persistent context, agents represent context gathered from the world.

An agent takes actions: searches the web, runs code, calls APIs. Each action produces information that becomes context for the next step.

ReAct (Yao et al., 2022) established the pattern: alternate between thinking and acting. Here’s a simplified example:

The model builds context through interaction with tools. Each action fills in information it didn’t have.

In 2025, agents became both more capable and more sobering. Anthropic released Claude with computer use. OpenAI shipped similar capabilities.

But Language Agents as Hackers (Yang et al., 2024) showed that even capable agents failed on multi-step tasks requiring genuine problem-solving. They could use tools but lacked strategic thinking over long horizons.

The pattern: agents work well for tasks with clear steps, recoverable errors, frequent feedback. They struggle with long-term planning, irreversible actions, ambiguous goals. Most “agent failures” are actually context failures—the agent had the wrong information at the wrong time.

Deep Research: Agents That Do Your Homework

The most ambitious agent applications fell under “Deep Research”: systems that conduct multi-step research autonomously, producing comprehensive reports.

OpenAI’s Deep Research, Google’s Gemini Deep Research, Perplexity, Grok DeepSearch all shipped in 2025. These aren’t simple RAG. They plan strategies, adapt based on findings, and orchestrate complex workflows.

Deep Research Architecture:

The Model Context Protocol (MCP) emerged as a standard for agents to discover and invoke tools dynamically. The best systems use RL to train agents end-to-end on output quality, not just individual steps.

For information-intensive tasks with clear objectives, autonomous research crossed into usefulness. They struggle with authentication, rapidly changing information, and tasks requiring genuine expertise. But they’ve automated information aggregation.

The End of Naive Fine-Tuning

In 2025, fine-tuning fell out of favor for frontier models. For most teams, it’s now a last resort, not a default.

Several things drove this.

First, frontier models got good enough that fine-tuning often degraded general capabilities.

Second, models got so large that fine-tuning became expensive and slow.

Third, context windows expanded from 4K to 128K, even 1M+. Instruction-following improved dramatically. This just means that if you can describe the task, no need to fine-tune models.

But for most teams: invest in context engineering infrastructure. The ROI is higher, and it transfers when you upgrade base models.

Anthropic illustrates this directly. Rather than fine-tuning Claude for every task, they built a “skills” system: curated instructions for specific domains loaded into context when relevant. Same weights, different context, different behavior.

Nothing changed in the weights. Everything changed in the context.

Voice: The Year It Actually Worked

Voice serves as the delivery layer for context engineering. But delivery matters: context that arrives 2 seconds late is useless. And voice captures richer input than text — tone, hesitation, the rambling that reveals what someone actually thinks.

Context engineering focuses on the right information to the model, while voice focuses on the right information to and from the human, fast enough to matter.

Voice interfaces became genuinely conversational in 2025. The target: under 500ms from when the user stops speaking to when they hear a response.

Two Architectures

Most voice agents use a pipeline: speech-to-text, then LLM, then text-to-speech. The alternative is end-to-end: audio in, audio out. GPT-4o was the breakthrough. Kyutai’s Moshi showed this wasn’t limited to closed models.

Both have tradeoffs. End-to-end preserves more information and achieves lower latency. Pipelines are more flexible: swap components, inspect intermediate text, debug easily. Most production systems still use pipelines.

Voice Quality

TTS improved along several dimensions. Emotional range: models learned to convey warmth, concern, excitement. Hume’s EVI explicitly optimized for emotional expressiveness. Prosody got natural: context-aware pacing and emphasis. Voice cloning matured: reasonable custom voices from minutes of audio.

Turn Detection and Interruption

Orchestration, rather than any single component, is the hardest problem.

Turn detection: knowing when the user finished speaking. Wait too long and it feels slow. Jump in early and you cut people off.

Interruption handling: agents now monitor for user speech while generating responses, stopping gracefully when interrupted.

Backchanneling appeared: the “mm-hmm” sounds that signal listening.

Frameworks like Pipecat, LiveKit Agents, and Vapi emerged to handle this orchestration, letting developers focus on conversation design.

Voice is about bandwidth. Text is high-effort, low-bandwidth. Voice is lower-effort, higher-bandwidth: ramble, think out loud, convey things that would take paragraphs. Voice captures the actual skill of verbal communication.

An Honest Assessment: Where AI Works, Where It Doesn’t

I’ve painted 2025 as a year of progress, and I believe that. But the ROI is concentrated in specific pockets.

Where AI works well:

[+] Tasks where success is verifiable (code that runs, math that checks)

[+] Tasks where errors are catchable and recoverable

[+] Tasks that augment humans rather than replace them

[+] Tasks where humans review before consequences happen

Where AI still struggles:

[−] Tasks requiring long-horizon planning

[−] Tasks where errors compound silently

[−] Tasks requiring common sense about the physical world

[−] Tasks where you need to know what you don’t know

The pattern: AI is most reliable with tight feedback loops. When you can check output, catch mistakes, and iterate, it works. When AI operates autonomously without supervision, problems accumulate.

Where This Converges: The Reason We Built AmpUp.AI

Once you see the world this way, a certain class of products becomes inevitable.

Sales is the perfect proving ground for context engineering because of its real-time, high-stakes nature.

Sales is a fundamentally verbal skill. Success depends on split-second synthesis: customer signals, product knowledge, competitive positioning. The gap between knowing what to do and doing it under pressure is where deals are won or lost.

Sales is the ultimate test-time compute environment. A rep has 200 milliseconds to process a “no” and figure out how to turn it into a “yes.” If the AI providing context has 2 seconds of latency, it’s useless.

If it doesn’t have the lived context of the last three meetings, it’s dangerous.

We realized that if we could solve context for the world’s most demanding verbal environment, we could solve it for anything.

That’s what we’re building at AmpUp. But the voice agents are only half the story.

AmpUp continuously analyzes sales calls and CRM interactions to extract structured signals across multiple levels:

• Meeting-level: objections raised, commitments made, risk signals surfaced

• Account-level: deal health, MEDDPICC gaps, competitive positioning

• Rep-level: skill patterns, strengths, and coaching priorities

• Org-level: behaviors that drive progression, where deals stall, what the market is signaling

This creates a hierarchical ontology of sales intelligence.

When a rep is about to join a call, we surface not just the notes but also the specific objections this prospect raised last time, how similar deals at this stage typically progress, what this rep specifically needs to work on, and what’s worked for top performers in comparable situations.

The context is structured, layered, and specific to this moment. That context then flows into two applications:

Pre-call preparation: Before a meeting, surface relevant account history, competitive intelligence, and suggested approaches. Not a generic brief. Specific context for this conversation, informed by patterns across thousands of similar interactions.

Deliberate practice: After analyzing call patterns, identify skill gaps and provide low-stakes voice practice against realistic scenarios. The scenarios aren’t generic. They’re generated from the actual objections this rep struggles with, the actual competitive situations they face, the actual gaps in their discovery process.

This works because it sits in the sweet spot:

• Real value: Practice helps, and context-aware practice helps more

• Voice is right modality: Sales is verbal; typing misses most of what matters

• Human in the loop: The point is to train the human, not replace them

• Context engineering as core: The entire platform is about extracting, organizing, and delivering the right context at the right moment

What Most AI Teams Still Get Wrong

After a year of watching teams build with these technologies, patterns emerge. The mistakes are consistent:

1. They optimize prompts instead of systems. A prompt is one piece of context. The retrieval pipeline, the memory architecture, the feedback loops—those determine whether the prompt even matters.

2. They measure accuracy instead of recoverability. In production, errors happen. What matters is whether users can catch them and the system can adapt. A 95% accurate system that fails silently is worse than an 85% accurate system with good error signals.

3. They deploy agents without feedback loops. An agent that can’t learn from its mistakes will keep making them. The best agent systems feed outcomes back into context for the next run.

4. They treat context as text, not state. Context goes beyond words in a prompt—it’s the evolving state of a conversation, a task, a user relationship. Managing that state is the hard engineering problem.

5. They chase model upgrades instead of context upgrades. Switching from GPT-4 to GPT-5 might give you 10% improvement. Fixing your retrieval pipeline might give you 50%. The leverage is asymmetric.

What’s Coming in 2026: The Context Engineering Era

For Builders: The Core Message

Focus on context. As models become increasingly commodity, the context system becomes the product.

The technology matured in ways that make it harder to dismiss and easier to use. The hard work of turning this into real value is still ahead.

The next generation of AI builders will call themselves context engineers rather than model trainers.

AmpUp Context Labs

Experience context engineering in practice. Same frontier model, three context configurations, three different capabilities.

Explore our Agents Now! - https://www.ampup.ai/context-is-all-you-need-agents

Not because reps sandbagged. Not because deals slipped. Because 58% of “committed” pipeline was missing clear buying signals from the customer.

That number isn’t a typo. That isn’t a forecasting problem.

It is fiction.

Forecasts fail not because reps lie, but because stories replace customer evidence. Here’s how revenue gets imagined into existence, and how to stop it.

The Scene That Repeats Every Quarter

It’s week 10. The CRO is on the forecast call, and Ryan is walking through his commit. He’s a solid performer who knows the product cold.

“This one’s solid,” Ryan says. “We had a great demo last week. The VP of Ops loved the ROI analysis. I’m meeting with procurement on Thursday, and then we should be wrapping up legal by the 28th.”

The CRO has heard this before. “What did the VP actually say about timeline?”

“He said they’re motivated to move quickly,” Ryan replies.

“Did he say why?”

“I mean... they’ve been dealing with this problem for a while.”

The CRO knows what this means. Ryan has built a story, a plausible sequence of events that ends in a signed contract. But the story exists in Ryan’s head, not in the customer’s words.

When we analyzed Ryan’s pipeline, 7 of his 12 “committed” opportunities were missing clear customer evidence for at least one of the three critical buying signals.

Across the team, the pattern held:

58% of committed pipeline had the same gap.

That is a $2.3M fiction masquerading as a pipeline.

The Inside View and the Outside View

Daniel Kahneman won a Nobel Prize for explaining why this happens. He showed that humans reason about the future in two fundamentally different ways—and we consistently choose the wrong one.

The Inside View: You construct a narrative by imagining the specific sequence of events that will lead to your outcome. You picture the procurement meeting, the handshake, the signature. The story feels real because you can see it.

The Outside View: You ask what actually happens to deals like this one. When you look at the data—Stage 3 opportunities with 30 days left and no procurement engagement—the failure rate is over 80%.

Ryan isn’t lying. His brain is doing what all human brains do: constructing a plausible story and mistaking it for a prediction.

The CRM showed a commit. The transcript showed a conversation.

Reps project problems onto customers based on title. They pattern-match vague statements into familiar scripts. Optimism feels productive. Evidence feels dangerous.

The Only Evidence That Matters

You can’t believe a deal into existence. Only the customer can say it’s real.

For a deal to exist — the customer has to express three things in their own words —

If any of these is missing, there is no deal.

The deal is already lost, you just haven’t admitted it yet.

Why This Is Brutal

The “three whys” leave you nowhere to hide. That pipeline you’ve been nursing? Half of it evaporates when you apply this standard honestly.

Reps resist this out of fear:

• Fear of hearing no.

• Fear of discovering sunk costs.

• Fear of asking a question that exposes a hole in their case.

But fear traps you in the “friend zone”—guaranteeing you waste resources on a prospect who likes you but will never buy.

The best sellers ask the uncomfortable questions early. They would rather hear “we’re not ready” in week two than suffer a slow “no” in week twelve.

The Real Problem Isn’t Skill, It’s Emotional Cost

Sales leaders see the problem and reach for the familiar solution: more training. Better frameworks. Tighter qualification criteria. MEDPIC. MEDDIC. BANT. The three whys.

But reps already know these frameworks. The issue isn’t awareness—it’s emotional labor.

When a rep asks “Why now?” and the prospect says “We’d like to figure this out,” the rep faces a choice:

Option A - Document the Truth. Watch the deal slip. Explain why a commit is now at risk.

Option B - Fill the gap with assumptions. Keep the CRM Green. Avoid discomfort.

Most reps choose Option B. Not because they’re dishonest, but because documenting uncertainty feels like failure when quota is breathing down their neck.

This is why training doesn’t fix it. You’re not fighting a knowledge problem.

You’re fighting human psychology under pressure.

The Gains Trap

Even when reps do ask “Why now?”, they accept weak answers because they sound plausible.

Customer says: “This is good for us, and the longer we wait, the less we get to capitalize on the gains.”

Rep hears: “Why now” ✓

But this is weak sauce. But gains don’t drive actions. Loss does. Humans are wired to avoid pain, not chase upside. Kahneman proved this—we’re 2-3x more motivated by loss aversion than gain seeking.

A real “Why now” sounds like this:

“We’re launching a major product next year. We’ll need to hire 20 new reps. If we don’t have a system to get them ramped faster, those reps will miss quota, we’ll miss the launch number, and I’ll be the one explaining to the board why we left $10M on the table.”

That’s not about gains. That’s about concrete, imminent, career-threatening loss.

The Mirror That Sets You Free

The hardest part isn’t knowing at to look for. It’s holding the mirror steady when your quota is screaming at you to believe.

This is where traditional training breaks down.

The only way to solve this is to remove the emotional friction.

AI does two things traditional training can’t.

First, it creates the first draft for you. You don’t have to agonize over admitting what’s missing. The system flags it neutrally: No cost quantified in transcript.

There’s no judgment. No confrontation. Just evidence.

Second, it challenges assumptions before they harden into commitments.
If a rep writes “Customer confirmed $500K pain” but the transcript only shows “This is costing us,” the system calls it out.

The story doesn’t make it into the forecast.

When every call is transcribed and analyzed, you can’t remember the conversation differently than it happened. Forecast calls stop being debates of opinion and start becoming discussions of evidence.

Practice That Transfers

But awareness alone doesn’t change behavior. You need repetition in context.

Traditional role-play is often a scheduled event disconnected from live deals. What changes behavior is practice that is bite-sized, highly personalized, and built in the context of a specific deal.

With AmpUp, the system knows Ryan’s patterns. For example, he backs off when it is time to press for commitment. Before his next call, Ryan practices that exact conversation. He sees how a top performer handled the same objection and tries the direct question out loud until it feels natural.

That’s how stories turn into evidence.

It’s been a while. If you’re still subscribed, thank you for your patience.

A lot has changed since I last wrote here. After twelve years at ThoughtSpot, most of my time now goes into a new company I started called AmpUp—we help sales teams close the gap between their best reps and everyone else. And somewhere along the way, I learned something about myself that I wish I’d understood decades earlier.

This post is about that lesson. It started as advice to a friend’s daughter, but it turned into something more personal.

—

A friend asked me for advice about her daughter, a second-year college student studying electronics. The daughter is anxious about the future—about what jobs will exist, what skills will matter, whether she’s on the right path. I found myself writing a longer response than I expected, because I’ve been thinking about this a lot.

Here’s what I’ve come to believe: For the better part of a century, we’ve lived inside a particular bargain. Go to school, go to college, get good grades, follow directions, and society will give you a safe place. A job. A trajectory. A life you can more or less predict.

That bargain is dissolving.

The Theater-to-Netflix Problem

Before mass media—before radio and television—if you wanted entertainment, you went to the local theater. That was the best anyone could do. Then technology made it possible to replicate human performance at near-zero marginal cost. Suddenly, for a few dollars, you could watch a billion-dollar production in your living room. Entertainment became a winner-take-all market almost overnight.

This is now happening to expertise. Engineering, medicine, law, financial advising, tax preparation—any domain where the core work involves applying established knowledge to routine problems is becoming compressible. Not disappearing. Compressing. A smaller number of people, augmented by AI, can do what used to require large teams.

If LLMs make it so that any routine task—anything that doesn’t require inventing new things—becomes easily automatable, then the remaining work shifts toward invention. Not just fundamental research, but entrepreneurial work: making bets, searching for niches, trying and failing and trying again until you land on something valuable. Having a sharp feedback loop so you fail fast and correct course. Being genuinely good at listening to people, asking real questions, synthesizing patterns no one has seen before.

The Comedian’s Career

A comedian can’t hide behind credentials. They walk on stage and either the room laughs or it doesn’t. They bomb, they adjust, they try again. They earn their place through repeated acts of vulnerability—not once, but every single night.

That used to be the exception. Artists and entrepreneurs lived that way while everyone else had the safety of defined roles and predictable advancement. Now that safety is dissolving. Your engineering career is becoming a comedy career whether you signed up for it or not.

The question isn’t whether you’ll face that exposure. It’s whether you’ll lean into it or spend years resisting the inevitable.

What I Got Wrong

I’m not writing this from some perch of having figured it out.

I spent years giving myself permission to stay comfortable. First there was the green card—I couldn’t take risks while my immigration status was uncertain. Then I became “the technical co-founder” at ThoughtSpot, which meant I had a lane. I stayed in that lane for twelve years, even when I sensed I had more to contribute in other domains—strategy, positioning, customer intuition. I told myself I was being responsible, playing to my strengths. Really, I was avoiding the harder work of developing judgment in areas where I wasn’t already good.

When I finally had the freedom to build something new, I tried to build everything—an agentic AI platform for anything and anyone. It felt expansive and safe at the same time. Safe because I never had to commit. I could stay in the realm of possibility, keep all doors open, avoid the exposure of saying “this is my bet, judge me on it.”

AmpUp exists because I finally made myself choose. Closing the gap between your best sales reps and everyone else. Not a platform for everyone. Not a solution for everything. A narrow lane where I could be wrong in a specific, measurable way.

That choosing was harder than any technical problem I’ve solved.

So What Does This Mean for a 20-Year-Old?

You don’t have to start a company. But you have to get specific about the future you want—even when you don’t have enough information to be certain. Especially then.

The method is: imagine the transformed version of a field you care about, then work backward to what skills and relationships matter today.

Healthcare: In ten years, routine diagnosis and treatment may be largely automated. The premium shifts to rare disease combinations, cases that don’t fit patterns, interpreting what’s happening with patients who fall between categories. And the irreducible core: being present with people in their most vulnerable moments. Machines can diagnose; they can’t hold a hand. If this interests you, maybe you study less anatomy and more pattern recognition, systems thinking, communication. You find the 50 doctors already working on the frontier of this and figure out how to be useful to them.

Finance: Basic analysis gets fully automated. The edge moves to judgment calls requiring synthesis of non-obvious signals—geopolitical intuition, founder psychology, cultural shifts that don’t show up in data yet. A student interested in this might study behavioral economics and history rather than just finance, seek out contrarian investors, and start writing publicly about patterns they notice. Building a track record of thinking, not just credentials.

Law: Contract work and legal research get commoditized. What remains is high-stakes negotiation, novel regulatory territory (AI governance, bioethics, space law), and situations where human judgment and trust are essential. A student might focus less on case law and more on understanding how new technologies create legal vacuums, then find the handful of lawyers actually working on frontier issues and offer to help them think.

Engineering: Implementation becomes cheaper. The premium shifts to problem selection—figuring out what to build, not just how. This means deeply understanding a domain rather than accumulating technical skills alone. The kid who spends a summer working at a trucking company and understanding their actual pain points may be better positioned than one who does another coding bootcamp.

Creative fields: Production quality gets democratized. Distinction comes from having a genuine point of view, building direct relationships with an audience, operating at the intersection of fields. The question isn’t “how do I get hired by a studio” but “what do I have to say that no one else is saying, and who specifically cares?”

The common thread: In every case, the move is from “acquire credentials in established category” to “develop a thesis about where value is moving, find the people actually working on that frontier, and make yourself useful to them.”

It’s less about entrepreneurship as starting-a-company and more about entrepreneurial thinking—treating your career like a search problem rather than an optimization problem.

More Alive, More Scary

I know this sounds hard. It is hard. The safe path was easier—you just had to follow the script. But here’s the thing: the safe path was also, in a way, a trap. A lot of people got stuck in systems that never pushed them to discover what they were actually capable of. They continued as cogs. There was never enough internal motivation or external force to try something unsafe.

The world that’s emerging will be harder. But it might also push more people toward greatness—because there’s no longer a comfortable middle to hide in.

The definition of work is going to shift—maybe as dramatically as it did when we went from breaking our backs on farms to typing on glass screens in air-conditioned rooms. To a farmer in 1924, what we call “work” today would look like sorcery. Or leisure.

But here’s what won’t change: we won’t just sit around in bliss. The hedonic treadmill guarantees new status games, new struggles. The question is whether you’re playing games you chose or games that were handed to you.

Make Your Choices Right

A mentor once told me: “We don’t make right choices. We make our choices right.”

I wish I’d understood that earlier. I spent years looking for the safe bet, the optimal path, the choice I couldn’t get wrong. That search was the trap. The real work was always on the other side of choosing—in the commitment, the iteration, the willingness to make whatever I chose into something worth having chosen.

The fear isn’t just “what if I don’t choose.” It’s “what if I choose wrong.” But that’s exactly what his words answer: there is no right choice waiting to be discovered. There’s only the choice you make and what you do with it.

I don’t have all the answers. This is a hypothesis. But it’s the one I’m betting on—for AmpUp, and for what I’d tell any young person navigating this moment.

Pick a lane. Make a bet. Then make that bet right.

—

If this resonated, I’d love to hear from you—especially if you’re a parent navigating this with your kids, or a young person figuring it out yourself. And if you’re curious about what I’m building at AmpUp, you can find us at ampup.ai.

Subscribe now