From Cloud Apps to Agentic Apps

Helping a major cloud platform understand — and prepare for — the shift from traditional cloud-native applications to agentic developer workflows.

Background image: images/00_hero.jpg
Eyebrow: UX RESEARCH · CASE STUDY

I saw the shift from cloud-native to agentic development before it was obvious — and built the research program that helped a large product organization reframe its strategy, retire a wrong assumption, and turn "better-together" integration bets from intuition into validated direction.

• My role: Lead UX researcher for the strategic "platform in the agentic era" thread — designing and running studies, founding a customer program, and synthesizing for product & leadership.

• Timeframe: 2023–2026 (agentic pivot concentrated in 2025–2026).

• Domain: Enterprise cloud platform-as-a-service — serverless functions, containers, app hosting — plus the AI/agent platform.

• Methods & skills: Expert & in-depth interviews · a recurring customer program · concept value testing · surveys · behavioral usability · competitive research · telemetry-based recruiting · JTBD framing · executive synthesis.

Where the platform sits in how agentic apps get built

For a decade, the platform I supported was optimized around a familiar unit of work: a request comes in, code runs, a response goes out. But developers were starting to build something categorically different — intelligent, agentic applications that reason over multiple steps, coordinate several agents, call different models, hold state, and take real actions. The strategic question I set out to help answer was deceptively simple: what do our services need to become when the unit of work is an agent, not a request?

Strong hypotheses, thin ground truth

I built this as a layered research program so it could speak to strategy and to shipping at the same time: deep qualitative interviews with practitioners building production agentic systems; a study of how developers choose platforms for agent-based work; concept value testing; surveys; and behavioral usability with the product teams. The spine that tied it together was a recurring customer program I founded.

A continuous customer-intelligence loop

The piece I'm proudest of is a recurring "builders show & tell" — a standing program that put expert developers directly in the room with the product managers who shape the roadmap, on a monthly cadence. I recruited participants partly from real product-usage signals, so we were learning from genuine early adopters. Instead of a one-time report, it created a durable feedback loop — one that ran across two cohorts and kept going even while I was on leave.

Production agentic systems, in the real world

Across interviews and live sessions, a recognizable pattern emerged for how teams assemble production agentic apps — combining event-driven logic, modular container deployment, hosted models, external tools, and state, under a layer of evaluation and governance. The diagram is a sanitized composite; it is not any single customer's architecture.

Five insights that reset the conversation

• Developers mix & match — per agent. They don't consolidate on one provider; they weigh performance, cost, fit, and velocity for each agent.

• Orchestration is stitched together. No single orchestrator fits every case; state, retries, and the gap to low-code are the recurring pain.

• The platform already has a clear split. Serverless functions for event-driven logic; containers for modular, multi-cloud deployment.

• Production readiness has a shape. Evaluation, observability, governance, and human-in-the-loop.

• Compute economics gate adoption. GPU cost is a first-order blocker.

• The opportunity is in the seams — between services, and between agents and the apps customers already run.

How findings turned into product bets

Because the work was a program rather than a set of one-off studies, its outputs landed as connected product direction — not scattered findings. Each insight mapped to a bet the research informed or validated, with the strongest single outcome being a strategy shift away from the single-provider assumption toward a mix-and-match, multi-model view.

What changed because of the work

3 core studies · 2 program cohorts · ~20 PMs per session · 1 strategy assumption retired.

The clearest outcome is that a strategic assumption was retired and replaced with a mix-and-match, multi-model posture for agentic app strategy. Beyond any single decision, the program gave product managers a durable, direct line to real builders, moved integration concepts from intuition to validated bets, and elevated the work to leadership through org-wide readouts and a research showcase.

Strategy and craft, across the stack

• 🔭 Strategic foresight — Spotting an emerging platform shift before it was obvious.

• 🧪 Mixed methods — Interviews, competitive research, concept testing, surveys, usability — matched to the decision.

• 🔁 Building programs — A standing customer-intelligence loop, not just a study.

• ⚙️ Technical fluency — Orchestration frameworks, state, compute economics, service integration.

• 🤝 Cross-functional influence — Aligning product, design, engineering, and leadership.

• 📣 Synthesis & storytelling — Turning complex feedback into clear, strategic guidance.

What it says about how I lead research

The lesson I carry is that research leadership is a posture, not a method. The highest-leverage thing I did wasn't any single study — it was reframing the question, and then building the mechanisms (deep studies and a standing customer program) that let a large, distributed organization act on an emerging need together. If I were doing it again, I'd claim ownership of the cross-team threads even earlier: in a period of rapid change, strategic research can quietly become shared execution unless someone insists on connecting each finding back to a decision. That connective tissue is the part of the craft I most want to keep sharpening.

This case study describes real work, generalized and sanitized for confidentiality. Company-, customer-, and product-specific details have been abstracted, and all figures are illustrative.