Why the next AI shift may require deeper system changes than most SaaS companies expect
7 min read
A Familiar Kind of Shift
Lately, I’ve been spending more time digging into what this emerging agentic era may mean for software, product design, and engineering leadership. I’m writing this as an engineering leader who has lived through several major shifts in software and is trying to spot the pattern early enough to ask better questions.
From my early days building e-commerce solutions to my later leadership of enterprise SaaS platforms, I’ve watched software undergo several major architectural and operating model shifts.
Teams moved from tightly coupled systems to more modular designs, from on-premises environments to cloud platforms, and from slower release cycles to continuous delivery.
None of those changes were simple tooling upgrades. Each one required organizations to rethink the system beneath the product: architecture, interfaces, operational discipline, team design, and the investments needed to support a different way of working.
The move into an agentic era may be another shift of that size.
When Software Starts Carrying the Workflow
Part of what has my attention is that the broader market seems to be landing in a similar place. I’ve seen it through the AI literacy work I’ve done with engineers, and I’m seeing it in my own workflow as well, where I now use sub-agents and agent-swarming patterns to help with software development tasks.
That kind of workflow is also becoming more common as people experiment with platforms like OpenClaw and other multi-agent systems that act on a user’s behalf to automate complex, multi-step workflows.
AWS has described agentic AI as a shift in how work is defined, who does it, and how decisions get made. OpenAI’s practical guide describes agents as systems that can accomplish tasks on a user’s behalf using tools and orchestration. McKinsey is also treating this as a discussion of workflow and operating model redesign, with organizations rethinking how humans and AI agents work together to create value.1
That’s why I don’t see this as just another feature discussion. For engineering leaders, product leaders, and companies building SaaS and other digital solutions, the bigger question is what parts of the current system may need meaningful reinvestment. Similar to earlier transitions to cloud, services, CI/CD, and stronger observability, this shift may require changes well below the interface.
Many products were built on a simple assumption: the human user carried the workflow forward. The user searched, clicked, entered information, made decisions, and moved the process from one step to the next.
In an agentic era, some of that work may be shared with or delegated to software agents. Once that starts happening, the design assumptions underneath the product start to shift. Workflow boundaries matter more. Business capabilities need to be exposed more cleanly. Permissions, audit trails, and escalation paths become more central to the product’s design.
That does not mean the human disappears from the workflow. In many cases, the opposite may be true. Just as engineering teams still need a human in the loop to review agent-generated code or changes before trusting them in production, consumers and end users will often still need to stay in the loop for important transactions, approvals, and commitments.
When money, risk, trust, policy, or accountability are involved, human confirmation still matters.
Trust Will Build in Stages
That trust shift will probably happen in stages.
Users are unlikely to hand agents broad authority overnight. More likely, they will start with narrower, lower-risk tasks and clear boundaries: compare options, watch inventory, reorder familiar items, or complete a purchase only within preapproved rules.
As trust grows, the scope may expand. In a few high-friction use cases, such as scarce ticket releases or other time-sensitive purchases, demand for agent help may appear quickly. Those same cases also show how fast fairness, identity, and platform rules can become part of the product design problem.2
Asynchronous Work Changes the Design
That also changes the shape of the interaction. As agents take on more of the work, the relationship between the user and the software may become more asynchronous.
The user may kick something off, walk away, and come back later when the system needs a decision, an approval, or a clarification. At that point, the product starts to look less like a simple request-and-response experience and more like a long-running workflow with checkpoints, pause states, and resumable steps.3
That has implications for state, timing, and transaction design. What exactly is waiting for approval? How long is that approval valid? What changes while the user is away? What happens if they never respond? Those questions matter a lot more when agents are allowed to keep moving while the human is doing something else.
The Real Investment Sits Below the Interface
For SaaS and digital product companies, this feels a lot like another modernization wave.
The visible AI layer will get most of the attention, but much of the harder work likely sits lower in the stack. Structured data becomes more strategic. APIs and callable workflows matter more. Governance and auditability need to get stronger. Platform engineering and developer experience matter even more when humans and agents are expected to work inside the same system.
That also changes the investment conversation.
If this shift is real, organizations should be thinking beyond models, demos, and surface-level AI features. They should be asking whether the underlying system is actually ready. Is product and workflow data reliable enough for software to act on safely? Are important actions buried inside brittle screens, or are they exposed through secure, policy-aware interfaces? Can the system show what an agent attempted, what context it used, what controls applied, and when a human stepped in? Can it preserve state cleanly when a workflow pauses and resumes later? Can it show the user what is pending, what has already happened, and what will expire if no one responds? Those are architecture questions, but they also reach into product design and the operating model.4
What Leaders Should Be Asking Now
For engineering leaders, the next roadmap conversation may sound familiar. Some of the most important work may not look flashy from the outside. It may live in service boundaries, internal platforms, policies-as-code, telemetry, security controls, workflow redesign, and the mechanics of durable state. That can be hard to explain in the short term. It was hard to explain during earlier cloud and modernization efforts, too. Even so, those investments often created the conditions for future speed, reliability, and adaptability.
Product leaders should be working through a parallel set of questions. Which customer or user problems are genuinely improved by agent participation? Which decisions still need to stay human? Where does trust start to get fragile? What evidence would show that the experience is actually better? Which steps can happen asynchronously without confusing the user or weakening accountability?
My takeaway, at least for now, is pretty straightforward. This feels less like a temporary interface trend and more like another platform and operating-model transition.
The companies that adapt well will probably be the ones that see this as a real systems shift. They’ll experiment, but they’ll also take an honest look at where their systems are brittle, too manual, hard to see through, or too tightly coupled to support what comes next.
For leaders like me, this makes it a research, architecture, and strategy topic all at once.
A good place to start is below the interface: workflow clarity, data quality, API maturity, permissions, auditability, observability, evaluation discipline, and the way state is managed when work pauses and resumes.
If the industry is moving toward software that can increasingly participate in execution, then engineering leaders, product leaders, and SaaS companies should be asking the same question:
What will it take to redesign our systems for that future responsibility?
I’d be curious how other engineering and product leaders are thinking about this shift.
Poking Holes
I invite your perspective on my posts. What are your thoughts?.
Let’s talk: phil.clark@rethinkyourunderstanding.com
References
- Agentic AI as a systems shift – AWS, “Operationalizing Agentic AI Part 1: A Stakeholder’s Guide” (March 11, 2026); OpenAI, A practical guide to building agents; McKinsey, “The agentic organization: Contours of the next paradigm for the AI era” (September 26, 2025). These support the idea that agentic AI changes how work is defined, how it gets done, and how humans and AI agents work together inside a redesigned operating model.
- Trust will likely build in stages – Visa, Earning Consumer Trust in the Age of Agentic Commerce; FTC, “BOTS Act compliance: Time for a refresher?” These support the idea that consumers want control and transparency, and that high-friction cases like ticketing quickly raise fairness, identity, and platform-rule questions.
- Asynchronous agents require durable state and pause/resume workflow design – AWS Lambda Durable Functions documentation and launch post. These support the idea that long-running workflows need checkpoints, callbacks, waits for external events, and state that survives interruptions.
- System readiness, governance, and operating-model reinvestment – AWS, Operationalizing agentic AI prescriptive guidance; OpenAI, A practical guide to building agents. These support the argument that companies need more than models and demos: they need interoperability, governance, orchestration, and production readiness in the system beneath the interface.