Run broader validation campaigns, understand results faster, and scale AI-assisted engineering with greater confidence.
The previous Cortex Cloud release introduced managed validation and runtime security for AI-generated software. Cortex Cloud 1.5 builds on that foundation by expanding from individual validation runs to coordinated engineering campaigns across multiple repositories.
Teams can now evaluate broader product changes from one place, follow progress over time, compare results, and retain the evidence needed to understand what happened. The release also improves workload reliability, reproducibility, and isolation as more jobs run concurrently.
The result is a stronger operational layer for organizations applying AI across real software systems—not only isolated prompts, individual files, or demonstration projects.
Cortex Cloud 1.5 helps teams move from asking whether one change passed a test to understanding how AI-assisted development performs across an entire product. It connects validation outcomes with source identity, execution history, performance, resource usage, and estimated cost, giving both developers and engineering leaders a more complete view of the work.
Validate connected products, not only individual repositories
Production software rarely lives in a single repository. A feature may span an application, API, shared library, deployment configuration, and supporting infrastructure. Testing each component independently can miss the interactions that determine whether the overall product is ready.
Cortex Cloud 1.5 introduces multi-repository benchmark campaigns for these connected systems. Teams can launch a coordinated set of checks, monitor active work, stop campaigns when priorities change, and return to previous runs without reconstructing the original test manually.
This provides a clearer way to answer broader engineering questions:
- Did a change improve results across the product?
- Which repositories completed successfully?
- Where did execution slow down or fail?
- How does the latest campaign compare with an earlier release?
- What did the work consume in time, resources, and estimated AI cost?
Instead of assembling answers from disconnected jobs, logs, and dashboards, teams receive a consolidated view of the campaign and its results.
This is especially valuable when AI-generated changes cross service boundaries. A modification that appears successful in one repository may still introduce incompatibilities elsewhere. Coordinated campaigns make those broader effects easier to discover before release.
Campaigns also give teams a natural unit for organizing repeated evaluations. A campaign can represent a release candidate, a model comparison, a platform upgrade, a dependency change, or a larger modernization effort. The individual repositories retain their own results, while the campaign provides the shared context required to understand the product-level outcome.
Move from isolated tests to repeatable benchmarks
A single successful test run can demonstrate that a workflow works once. A benchmark program provides evidence that it continues to work across repositories, releases, and changing development conditions.
Cortex Cloud 1.5 makes repeated evaluation easier to operate. Teams can revisit previous campaigns, examine their outcomes, and use the same product-level view to assess later changes. This supports a more disciplined approach to adopting new AI models, development agents, validation strategies, and infrastructure.
For example, an organization evaluating a new coding model may want to understand more than whether it generated working code. It may also want to compare completion rates, validation time, resource consumption, and estimated cost across a representative group of projects.
Similarly, a team updating a shared development platform may need to know whether the change improves one repository while causing slower builds or new failures elsewhere.
By organizing these evaluations as campaigns, Cortex Cloud turns scattered test activity into comparable engineering evidence. Teams can make decisions based on results across their actual software portfolio instead of relying only on demonstrations or isolated examples.
Turn benchmark history into engineering context
A test result is more useful when its context is preserved.
Cortex Cloud now retains stronger links between results, repository versions, validation inputs, and execution records. Teams can revisit a campaign and understand which source state was evaluated rather than relying on a branch or label that may have changed since the run.
This improves comparison between releases and helps teams investigate regressions with greater confidence. Historical campaigns become reusable engineering evidence rather than temporary status updates.
The benchmark experience also presents practical measurements such as turnaround time, test outcomes, resource use, and estimated AI cost. These signals help engineering leaders understand not just whether a campaign passed, but how efficiently it completed and where further investment may be useful.
Over time, this creates a more meaningful record of software and AI performance. Teams can observe whether validation is becoming faster, whether particular projects regularly consume disproportionate resources, and whether newer workflows are producing better outcomes for their cost.
History also helps separate a one-time incident from a recurring pattern. A slow campaign may reflect an external dependency or an unusual repository state. Repeatedly slow results may point to a broader opportunity to improve the project, the validation workflow, or the resources assigned to it.
Improve completion without hiding failures
Repositories differ widely in how they prepare and run their tests. Missing dependencies, incomplete caches, unavailable tools, and undeclared assets can prevent useful validation before the actual test suite begins.
Cortex Cloud 1.5 improves preparation so more supported projects can reach meaningful execution. The platform checks that required resources are available before offline validation begins and can apply limited recovery when a recognized preparation issue can be addressed safely.
These improvements are designed to increase successful completion without making failures less visible. Preparation work is recorded separately from repository tests and cannot be mistaken for a passing product result.
When a problem cannot be corrected safely, Cortex Cloud stops and reports the blocking condition. This avoids wasting time on repeated attempts that have little chance of producing a different result.
The practical benefit is greater reliability with clearer accountability. Teams spend less time interpreting generic failures and more time addressing the condition that actually prevented progress.
This balance is important for trustworthy automation. Automatically fixing everything can conceal meaningful problems, while refusing to handle routine preparation issues creates unnecessary friction. Cortex Cloud focuses on bounded assistance: helping supported workloads progress when the required action is understood, while preserving failure when human review is the appropriate next step.
Support a broader range of real projects
Enterprise software portfolios are rarely uniform. Some repositories contain modern application stacks, while others rely on older tooling, specialized test frameworks, browser-based checks, or project-specific assets.
Cortex Cloud 1.5 improves how managed validation prepares for these differences. The selected test suite remains the source of truth, while preparation adapts to the requirements declared by the project and its validation plan.
This makes Cortex Cloud more useful across mixed portfolios without turning validation into an open-ended attempt to infer every possible repository behavior.
The platform also keeps preparation and testing distinct. A successful environment check does not count as a successful repository test, and a preparation repair does not change which suite was selected. Teams can therefore benefit from improved compatibility without weakening the meaning of the final result.
For organizations, this reduces the amount of custom operational work required before repositories can participate in broader campaigns. More projects can be evaluated through a consistent managed experience, while their individual test expectations remain intact.
Diagnose blocked work more quickly
Distributed validation can fail at several points: while preparing an environment, retrieving an allowed dependency, building an artifact, starting a workload, or running the selected checks.
Cortex Cloud 1.5 improves the evidence retained around these failures. Instead of presenting every unsuccessful operation as an undifferentiated build error, the platform provides more useful context about the affected phase and operation.
This helps teams distinguish between a repository problem, a temporary external condition, a policy restriction, and an incomplete execution environment. It also reduces unnecessary retries when the available evidence indicates that the same attempt would fail again.
The platform remains careful about how it describes causation. A blocked connection or unavailable dependency may coincide with a failed command without necessarily being its only cause. Cortex Cloud preserves the relevant evidence while avoiding conclusions that the underlying data cannot support.
For developers, the outcome is simpler: less time searching through unrelated logs and a faster path to the next useful action.
For platform teams, better diagnostics make recurring issues easier to identify across repositories. If several campaigns encounter the same class of preparation or execution problem, teams can prioritize a shared improvement rather than troubleshooting each run independently.
Strengthen isolation as workloads scale
Running more jobs concurrently requires stronger boundaries between them.
Cortex Cloud 1.5 improves the separation of build data, cached dependencies, execution resources, and network activity. Each job operates within a controlled environment intended to prevent one workload from unintentionally influencing another.
The release also applies tighter controls while repositories prepare and build their software. These protections limit access to protected infrastructure and help preserve separation between concurrent jobs without preventing the public resources that supported builds legitimately require.
Build resources are scoped more carefully to their owning jobs, and recovery processes are better able to identify resources created by interrupted work. This reduces the chance that abandoned state will affect later validation.
For customers, the benefit is straightforward: broader validation capacity with stronger workload boundaries and more predictable results.
Isolation also improves the quality of comparisons. If one job can reuse unrelated state or influence another workload, apparent performance improvements may not reflect the repository itself. Stronger separation helps ensure that campaign results represent the work being evaluated rather than accidental conditions left behind by another run.
Compare results with greater confidence
Cortex Cloud captures more of the evidence required to explain and reproduce a run. This includes the identity of the evaluated source, relevant build inputs, execution settings, and resulting reports.
That evidence helps teams determine whether two campaigns truly tested comparable inputs. It also improves investigation when results differ across releases, environments, or points in time.
A reproducible result is not simply a stored pass or fail status. Teams need to know what was tested, under which conditions, and which outputs were produced. Cortex Cloud 1.5 strengthens that connection without requiring developers to manage the underlying execution records themselves.
The goal is not to produce more logs for their own sake. It is to retain the information that makes a result understandable after the original run has finished.
This becomes increasingly important as AI contributes to more development work. When a generated change succeeds, teams need evidence that it passed the intended checks. When it fails, they need enough context to determine whether the issue came from the change, the project, or the execution environment.
Cortex Cloud makes that evidence part of the managed workflow rather than an afterthought.
Understand performance and spending together
Technical validation is only one part of operating AI-assisted engineering at scale. Teams also need to understand how long work takes, how much capacity it consumes, and whether the resulting improvements justify their cost.
Cortex Cloud 1.5 brings these signals closer together. Engineering teams can use detailed results to investigate failures, while leaders can evaluate campaign progress, turnaround time, resource use, and estimated AI spending through the same operating model.
This makes benchmark campaigns useful beyond release qualification. They can support model evaluation, workflow comparison, platform planning, and decisions about where AI produces the greatest engineering value.
A faster result is not automatically better if it produces lower-quality changes or increases downstream failures. A more capable model may not be the right choice for every repository if it significantly increases cost without improving completion. Cortex Cloud provides the context teams need to consider these tradeoffs together.
The objective is not to reduce every engineering decision to a single score. It is to make the important signals visible so organizations can define success according to their own priorities.
Bring Cloud execution into the wider Cortex workflow
Recent Cortex releases introduced governed workflows, coordinated work, and stronger ways to manage AI activity across development surfaces. Cortex Cloud 1.5 extends that direction into managed execution.
A workflow can move from planning and review into Cloud-backed validation while preserving its identity and supporting evidence. Results can then return to the wider product experience, where developers and engineering teams can inspect the outcome.
This creates continuity between AI-assisted development and the systems responsible for validating the resulting work. Developers do not have to treat Cloud execution as an unrelated testing environment, while organizations gain a clearer boundary between interactive assistance and managed workloads.
The result is a more complete path from a requested change to reviewable, reproducible evidence.
That continuity also helps organizations maintain governance without adding unnecessary manual coordination. Review and approval remain meaningful parts of the workflow, while Cloud execution provides the capacity and controls required to perform broader checks.
A managed foundation for broader AI engineering
Cortex Cloud began by providing a managed destination for AI-generated software to be built, tested, and examined more safely. Cortex Cloud 1.5 expands that foundation into a coordinated system for evaluating connected products.
Teams can move from testing one repository at a time toward running broader campaigns across the software they operate. They gain a clearer view of progress, performance, cost, failures, and historical results while Cortex Cloud manages the execution environment behind them.
Developers benefit from fewer avoidable preparation failures and more useful diagnostics. Platform teams gain stronger isolation and more consistent execution. Engineering leaders receive clearer evidence for comparing outcomes, capacity, and spending.
Together, these improvements create a practical path from individual AI-assisted coding tasks to repeatable, organization-level engineering workflows.
Cortex Cloud 1.5 is designed for teams that want AI development to move faster without losing operational control, workload separation, or confidence in the result.
