Category: Sponsored Content

Most companies don’t actually struggle to ship software anymore. AI made that part fast. What they struggle with is releasing what they built with any real confidence in it. That gap between shipping fast and trusting what you shipped is what I’ve been calling quality debt at conferences all year, and it’s the same gap UiPath is trying to close with Test Cloud, its agentic software testing platform. I spent time in three UiPath sessions on it and want to walk through what actually held up, what I pushed on, and where I think this lands for engineering leaders.

Industry Background

The UiPath take on the state of testing is that organizations are still constrained by lengthy regression cycles, heavy manual effort, brittle automation, and the cost of maintaining fragmented tools. Even where automation exists, much of the broader testing process can remain manual, consuming budget and engineering capacity that CIOs could otherwise direct toward innovation. UiPath presented a maturity model ranging from ad hoc manual testing to continuous, AI-assisted testing. Its argument is that many organizations remain concentrated in the earlier stages: unstructured manual testing at the bottom, then scripted UI automation with thin API and mobile coverage, then automation genuinely integrated into the SDLC where shift left actually happens, then automation scaled across apps and teams, and finally continuous testing with AI tuning it in real time.

Here’s the part that makes this urgent instead of theoretical. AI is compressing development cycles, so code changes are shipping weekly or even daily now instead of monthly. QA teams, by comparison, are still operating in what amounts to an earlier era, doing waterfall or Agile or DevOps work at a pace that hasn’t caught up. The gap between how fast code moves and how fast anyone can test it is widening, not narrowing, and that widening gap is quality debt showing up in real time.

Company and Technology

UiPath didn’t start as a testing company. It started in robotic process automation, and Test Cloud runs on that same engine rather than being a bolted-on acquisition. UiPath has an established global enterprise customer base, and Test Cloud builds on the same underlying automation platform.

UiPath was named a Leader in the 2025 Gartner Magic Quadrant for AI-Augmented Software Testing Tools. Alongside that, UiPath emphasizes an open AI approach, with support for leading model providers and bring-your-own-model options, rather than tying the testing platform to a single model vendor.

Product Specifics

One of the most important workflows shown in the showcase brought together Test Manager for test management and traceability, Studio for building test automation, Orchestrator for managing and executing automated tests, and Insights for analytics and reporting.

The demo started with a requirement pulled from a fictional banking app called UiBank. Clicking “Optimize coverage” analyzes the requirement, plus any screenshots or documentation you’ve attached, through an AI model, which comes back with a list of gaps the requirement’s author probably missed — things like unspecified email formats or missing character limits. A human reviews each suggestion and decides whether to add it, and, when the relevant integration is configured, approved changes can sync back to Jira or ADO. From there, generating test cases follows a similar pattern: provide the relevant context and instructions, then review the generated output. Organizations can govern which approved models are available and use bring-your-own-model configurations when their architecture, security, or provider requirements call for it. Data handling and retention depend on the selected configuration and should be validated against the applicable product and model-provider policies.

Where this got genuinely interesting was the robots versus agents distinction, and one of the other delegates on the call pushed UiPath on exactly the right question here: why spend tokens on agentic reasoning for a task that should just run the same way every time? The UiPath answer is that both options exist on purpose. A robot follows the exact steps in a test case and predefined logic, and conventional deterministic test automation does not require LLM inference for every execution step, making it the efficient choice for stable, repeatable regression scenarios. An agent reasons through each step and can adapt if the workflow shifts, which is the better fit when you’re testing something for the first time or don’t want to build a script at all. In the demonstration, agent-led execution took longer than deterministic automation because it reasoned through the steps dynamically. The actual difference will vary by scenario, application, environment, model, and workflow complexity.

The Healing Agent can recover from certain runtime disruptions, including selector changes, blocking overlays, and load-timing problems. Issues it cannot resolve can be surfaced for human review.

The most ambitious piece is Agent Builder and Maestro. Agent Builder lets you build a specialized agent conversationally, describing its goal and the data it needs, and in the demo that meant standing up a “data retriever” agent that could pull specific customer records out of a banking application on request. Maestro then orchestrates all of it — robots, agents, and humans — into a single end-to-end workflow, with the option to insert a human checkpoint anywhere you want one before the process continues. UiPath frames this as heading toward a largely autonomous SDLC testing cycle, with humans checking in at key points rather than running every step. I pushed on how a company would actually learn to design one of those combined agent, robot, and human workflows without just guessing. UiPath pointed to its professional services organization and certified partners as important parts of designing and implementing more advanced agent-and-automation workflows.

The economics differ by execution pattern. Deterministic automation does not require an LLM call for every test step, while agentic capabilities can consume platform capacity or other metered entitlements depending on the feature and commercial model. Organizations using their own models may also incur costs under their model-provider agreements.

Test Cloud is offered as Public Test Cloud, operated by UiPath, and Private Test Cloud, deployed through Automation Suite and operated by the customer. The private option supports customers that need greater infrastructure control or data residency. Specific FedRAMP and air-gapped requirements should be validated against the relevant edition and release.

Conclusion

What I actually like here is that UiPath isn’t pretending agents should replace deterministic test automation. Deterministic automation is best suited to stable, repeatable work — the boring regression runs that should behave the same way every time — while agents are better suited to tasks that require interpretation, adaptation, or reasoning: first-pass testing, ambiguous workflows, or scenarios where maintaining predefined automation is impractical. That’s the right instinct, and it lines up with where I think quality work needs to go generally: spread across the people and tools actually building the thing, not stacked entirely on one team checking it at the end. The remaining question is how easily a team without an established quality operating model can design and govern these combined agent, automation, and human workflows. UiPath offers services, partners, training, and platform capabilities to support that transition, but customers should still evaluate how much external guidance their implementation will require. If you’re already thinking seriously about where quality ownership sits in your org, Test Cloud is worth putting on your shortlist.

UiPath FUSION is scheduled for September 22–25, 2026, at the Wynn Las Vegas.

A static alert at 80% CPU or a two-second response time threshold is an absolute judgment applied to a system that operates in relative terms. However, traffic patterns shift by hour, day, and season. Deployments alter performance baselines. External dependencies introduce latency profiles that no team fully controls. A fixed number stops being a reliable signal the moment conditions drift from when they were configured, and in production, conditions drift continuously.

The result is a detection gap that most IT teams know intimately. The alert fires, the incident channel opens, and somewhere upstream a user has already filed a support ticket. AI-driven application performance monitoring (APM) addresses this by shifting from fixed judgment to continuous inference. ML models establish behavioral baselines for every monitored signal, accounting for seasonality, deployments, traffic patterns, and surface deviations as they emerge rather than after they have crossed a threshold set months ago.

Why Static Thresholds Fail at Scale

Static thresholds measure absolute values rather than meaningful change. A web application serving 5,000 requests per minute on a Tuesday afternoon is healthy. The same number during a quiet weekend window may represent a significant anomaly. A static threshold cannot distinguish between them because it has no concept of expected behavior.

In distributed systems, the problem compounds further. A latency spike in one service may produce error rate increases downstream 30 seconds later. A connection pool approaching saturation may generate P99 increases that are individually below threshold but collectively indicative of an impending outage. IT teams end up with either excessive noise from thresholds set too sensitively, or blind spots from ones set too conservatively. Either way, alert fatigue sets in and critical notifications get discounted alongside the routine ones.

What ML Changes About Detection

ML models evaluate a metric against a probabilistic model of what it should look like given the current time, traffic volume, deployment history, and seasonal patterns. An anomaly is not a value that exceeded a threshold but a value that is statistically inconsistent with established baseline behavior. A checkout latency of 1,800ms may be normal during a peak traffic window following a promotional campaign. However, the same value at baseline traffic with no recent deployments is a genuine signal.

The model doesn’t evaluate whether a metric is high, instead it judges whether it is behaving differently than it should—a distinction with considerably higher diagnostic precision. It suppresses routine fluctuations that pollute threshold alerting while surfacing the statistically meaningful deviations that precede user-impacting incidents. A model aware of day-of-week patterns will not alert on the predictable Monday morning spike that has occurred every week for a year, but will alert when that spike arrives 40% larger than historical norms suggest.

From Detection to Diagnosis

Early detection is only the first part of the problem. In systems with hundreds of services, determining what changed and why can consume more time than the fix itself. Causal AI addresses this by determining not just which metrics changed, but which changed first and which are downstream consequences. A memory leak in a connection pool may produce correlated increases in response time, error rate, and query latency across multiple services. Simple correlation surfaces all of them; causal analysis identifies the origin and directs the investigation there. Now, engineers arrive with a prioritized hypothesis rather than an open-ended list of affected components.

OpManager Nexus illustrates this approach through its Zia AI engine, which applies robust principal component analysis (RPCA) and matrix sketching algorithms to identify deviations against seasonally benchmarked values. Domain-aware ML then correlates related alerts within a 10-minute window into a single consolidated problem, so teams receive one actionable notification with clear context rather than hundreds of individual alerts for the same incident.

From Diagnosis to Autonomous Action

Identifying the root cause is not the end of the incident workflow. Once a problem is understood it still needs to be acted on, and that action carries its own risk in complex environments. Runbooks get skipped under pressure. Remediation steps vary between engineers. However, the same causal intelligence that locates a problem can also drive consistent, governed response.

The emerging model is AI agents: purpose-built automations that operate within defined guardrails, follow approved solution documents, and execute remediation tasks without requiring an engineer to drive each step manually. The governance layer matters as much as the automation itself.

The MCP has emerged as a structural approach here, providing a standardized interface through which agents access observability data, reference approved guidance, and execute tasks within enterprise-defined controls. OpManager Nexus’ recent additions in this space include customizable AI agents with configurable guardrails, MCP-based agentic workflows, and orchestrated remediation through structured runbooks with approvals and traceability built in. The result moves incident response from a sequence of manual steps toward a governed, repeatable workflow that behaves consistently regardless of who is on call.

What This Means for DevOps Teams

The practical implication for on-call engineers is a change in how investigation begins and how resolution proceeds. Without AI-driven monitoring, the alert fires and the engineer examines dashboards, forms hypotheses, and tests them sequentially until the root cause surfaces, a process that can take 30 minutes to several hours. With causal AI the alert fires earlier and arrives with a diagnosis, and with agentic workflows the first remediation steps may already be underway before the engineer opens a terminal.

Mean time to recovery (MTTR) is the metric this affects most directly. Early customers have reported filtering out close to 90% of alert noise while significantly improving SLA adherence. Earlier detection, faster diagnosis, and governed automated response compound into a structural change in how IT operations handles failure, not an incremental one.

The shift is not automatic, as ML models require sufficient historical data and agents require careful scoping to operate safely in production. But the direction is clear. The question is no longer whether AI belongs in APM but how far into the incident life cycle it should reach.