From the outside, it may seem that the Salesforce world currently revolves exclusively around Agentforce and autonomous agents. Presentations, keynotes, and roadmaps paint a picture of systems that independently understand context, make decisions, and achieve business goals without our constant intervention. Meanwhile, the daily reality for many teams is much more grounded: fixing legacy Flows, cleaning up data, and paying off technical debt left behind years ago.
This gap between vision and reality is striking today. And yet, even when working in this “maintenance mode,” it is hard not to notice that something fundamental in the way we design systems is beginning to shift. One of the first places where this change becomes visible is in the analyst’s toolkit—specifically, the classic User Story.
From Designing Paths to Designing Intent
For years, the User Story has been a solid foundation for implementation teams. It helped describe a user’s need, define scope, and design a predictable path from point A to point B. Process diagrams, validations, business rules, and acceptance criteria enclosed everything in a tight, deterministic framework.
This model worked perfectly in a world of systems that reacted exactly as they were programmed. A click triggered an action. A condition led to a specific result. Every step was pre-planned.
Today, this is increasingly proving to be insufficient.
In AI-driven systems, we are no longer just designing paths. We are designing behavior. And this fundamentally changes how we describe requirements.
To illustrate the contrast:
- Then: “As a user, I want the system to send email template #5 to the customer once the ‘Refund’ checkbox is checked.”
- Now: “Act as a returns coordinator. If the customer expresses frustration, offer them a discount on their next purchase. If the communication is neutral, inform them of the standard procedure based on current stock levels.”
In the second case, we are no longer interested in a single button or a specific template. We are describing intent, context, and the expected manner of the system’s reaction. This isn’t a semantic detail; it’s a paradigm shift.
Behavioral Specification Instead of a Step-by-Step List
With this shift, the documentation itself begins to look different. Elements that were previously secondary, or entirely absent from classic User Stories, are now taking center stage.
We are seeing the rise of guardrails—clearly defined boundaries for system behavior. These aren’t just exceptions in logic, but principles such as: “The system should never promise 24-hour delivery for oversized products” or “Do not escalate the case if the customer has already received compensation within the last 30 days.”
Parallel to this, the importance of context is growing. The system doesn’t make a decision based on a single field or status, but on interaction history, communication tone, previous decisions, and data coming from various channels. Describing this within the classic “As a user, I want…” structure is becoming difficult and increasingly imprecise.
In practice, we are more frequently trying to describe business rules in natural language in a way that is understandable not only to a developer but also to the technology meant to interpret them. This requires a different level of precision and a new way of thinking about requirements.
User Stories Aren’t Disappearing, But They Are No Longer Enough
This isn’t a manifesto about the end of the User Story. It remains an excellent tool where we are designing deterministic processes, forms, validations, or classic automations. The problem arises when we try to use that same tool to describe a system meant to interpret a situation and make decisions under conditions of incomplete information.
In such cases, a classic User Story describes too small a fragment of reality. It focuses on the interaction while ignoring the behavior; on the action rather than the intent; on a single scenario instead of a spectrum of possible reactions.
That is why we increasingly need something more: specifications that define the system’s role, its decision-making boundaries, its way of reacting to context, and its business priorities. Not instead of the User Story, but alongside it.
Evolution of the Craft, Not a Revolution
Even if we are currently focused on maintaining existing processes and are far from deploying autonomous agents, this way of thinking is slowly permeating our daily work. It’s visible in conversations with stakeholders, in expectations for “intelligent” features, and in the growing frequency of describing systems in terms of behaviors rather than just functions.
This isn’t yet the new standard for requirements analysis. But everything indicates that without this shift in our approach, AI-component projects will either be overly constrained by rigid logic or too unpredictable to truly support the business.
This means that, sooner or later, this topic will move from visionary slides directly into our backlogs. And when that happens, the classic User Story may prove to be a good starting point, but no longer a sufficient tool for describing what we truly expect from modern systems.
