AI is changing what “working software” means
AI is one of the first enterprise software categories where vendors can’t fully define what “it works” means before a customer ever logs in.
This isn’t malicious or deceptive. It’s simply a consequence of how generative AI operates.
The problem is that the traditional enterprise software sales motion hasn’t adapted to this new reality. When you buy traditional software, expectations are relatively straightforward: clicking button X produces Y and Z every time. The behavior is documented, the feature either exists or it doesn’t, and implementation is largely about configuration, integrations, and user enablement.
AI fundamentally changes that equation.
An AI system’s performance depends on the environment it operates in, the context it has access to, the quality of the underlying data, the prompts users provide, and the workflows it becomes a part of. Vendors don’t fully understand any of those variables until after the customer begins using the product.
Despite these dependencies, AI is still frequently sold in deterministic language:
“Generate meeting notes.”
“Automate your outbound.”
“Draft emails.”
The expectation becomes that the product will simply *work*. When reality proves more nuanced, customer-facing teams end up absorbing the gap between what was promised and what AI can reliably deliver in each customer’s unique environment.
To be clear, traditional software has never been perfectly deterministic. Integrations fail, configurations drift, and users make mistakes. But generative AI introduces an entirely new category of variability because the software itself is probabilistic.
There are countless reasons why AI breaks the traditional software model, but three matter more than the rest:
1. Probabilistic Generation
Traditional software is deterministic. Given the same inputs, it produces the same outputs. Generative AI doesn’t work that way.
Even with the exact same prompt, an LLM can produce multiple valid responses. One answer might be better structured. Another might capture nuance. A third might emphasize completely different details. None are necessarily “wrong.”
The core question shifts from “Did it work?” to “Was this output useful enough for this user in this context?”
That is a fundamentally different success criterion than enterprise software has historically been built around.
2. Context Dependence
An AI model doesn’t operate in isolation. Its output depends entirely on the information available to it: customer data, permissions, connected systems, conversation history, prompt quality, and workflow design.
Two companies can purchase the exact same AI product and have completely different experiences because their environments are different.
The model isn’t necessarily better or worse. The context is.
3. The Limits of Evaluations
Model evaluations (evals) are incredibly valuable, but they answer a different question than customers are asking. Evals measure how a model performs in controlled scenarios against predefined benchmarks.
Customers care whether the product helps them do their job inside their own messy environment. Those are not the same thing.
A model can score exceptionally well on internal evaluations while still producing outputs that fail a customer’s expectations—because those expectations are shaped by company-specific context and subjective definitions of quality.
Closing the GTM Gap
The biggest challenge in enterprise AI isn’t getting the model to work. It’s getting the customer to agree that it’s working.
That requires more than a better model. It requires a Go-To-Market (GTM) motion built for probabilistic software.
Here is how customer-facing teams need to adapt:
1. Shift discovery from features to context.
Sales teams must stop selling AI as a magic button and start selling it as a system. Discovery can no longer just be about "what features do you need?" It must become: "What data does this workflow rely on, and is that data clean enough for an AI to read?"
2. Redefine "Success" during Kickoff.
Customer Success cannot run traditional onboarding. They must explicitly educate the customer on the probabilistic nature of the tool. Set the expectation on Day 1 that tuning prompts, building context, and refining outputs is not a bug in the software—it is the reality of deploying AI.
3. Measure adoption through acceptance, not just execution.
If a user generates a draft but deletes the whole thing and rewrites it, the software successfully "executed," but it provided zero value. Product and CS teams must build telemetry and health scores around acceptance rates and usefulness, not just API calls or clicks.
Vendors who win this era of software won't just be the ones who build the smartest models. They will be the ones whose GTM teams actually help organizations integrate AI into how they already work, instead of expecting customers to adapt to how the model works.