Shifting Mindset: SaaS to AI

Agentz Founders May 5, 2026

Six years ago when we started building Agentz.ai using NLP and NLU, considered an AI solution at the time, it was still essentially a SaaS product. Good for its time.

Then LLMs arrived and the more I worked with them in production, the more I realized I had to unlearn some of how I was thinking about building AI solutions.

Quite commonly, AI solutions are built with a SaaS design mindset. That is understandable. SaaS earned thirty years of trust by being predictable. You define the rules, users learn the interface, the system follows instructions. Configurability is a good example, workflow builders, toggle switches, setup screens, these are familiar and they feel safe. But they are the wrong abstraction for AI.

To be fair, natively AI design patterns are not perfect yet either. That gap is part of what keeps pushing teams back toward familiar SaaS patterns. It is the safer path when the alternative is still being figured out.

When I started searching to see if others were experiencing a similar shift in thinking, I found there is already a term for it. The Sparkle Button Problem. Nobody seems to know exactly who coined it but it resonated immediately. Apple understood a version of this when it removed the keyboard from the phone, then the home button, then the headphone jack. Each time it traded familiarity for something architecturally better.

The specific problem with carrying SaaS design patterns into AI is that AI is fundamentally context-sensitive in ways that rule-based systems never were. A small change in context shifts the prompt or prompt sequence in ways that can produce entirely different behaviour. My co-founder Arun Kumar can tell you about the hours we spent fine tuning a prompt only to find another edge case waiting on the other side.

That is not a bug you fix once. It is the nature of the technology. In a SaaS system you write a rule. Do A in condition X, do B in condition Y. The system follows it. In an AI system you cannot enumerate every condition. The model fills the gaps. That is its power. But if the architecture around it is built like SaaS, with rigid flows and configuration screens generating generic prompts, you constrain the model where it is strong and expose it where it is sensitive.

The right question is not how to configure a solution. The right question is how does it handle what it was not explicitly trained on. Those sound like the same question. I used to think they were too. They are not. One is about control surfaces. The other is about what happens between them.