Managed Cloud Execution for Enterprise AI with Cortex Cloud

From connected intent to durable cloud execution across mobile, browser, and Visual Studio Code

Enterprise AI is moving from answering questions to helping people complete meaningful work.

That shift changes the role of the environment around the AI. A useful answer can be generated almost anywhere. Engineering work is different. It depends on source code, project state, development tools, permissions, compute, continuity, and a clear understanding of where an action is allowed to run.

Cortex Connect established a continuous experience across mobile, browser, and Visual Studio Code. It allowed a request to begin where the need appeared, remain visible across work surfaces, and reach the connected development workspace where the relevant project context lived.

Cortex Cloud takes that experience to the next level.

With this release, users can choose between Local execution and Cortex Cloud directly from the Cortex experience. Local keeps eligible work close to the connected development environment. Cortex Cloud extends the workflow into a managed cloud execution environment designed for durable, remote, project-aware work.

The choice is simple at the surface. Underneath, Cortex coordinates the intelligence, workflow state, project version, execution environment, progress, and result as one connected experience.

This is the base Cortex Cloud release: a foundation for cloud execution across Cortex, focused on continuity, control, and a clear path from user intent to completed work.

Cortex Connect created mobility; Cortex Cloud adds execution reach

The original promise of Cortex Connect was built around a practical observation: the place where a need appears is not always the place where the work should run.

A developer may identify an issue while reading documentation in a browser. An engineering leader may create a task from a phone. A team member may begin an implementation request in Visual Studio Code and later check its progress from another device. Cortex Connect keeps those moments joined through continuity of intent, progress, and control.

Its first execution model centered on the connected development workspace. That was an important step because it kept project-aware work grounded where the code, tools, and developer context already existed.

Cortex Cloud expands that model.

Now the execution destination can reflect the nature of the work and the user’s situation. A user can keep work Local when the connected machine is the appropriate environment, or choose Cortex Cloud when the task benefits from durable remote execution. The conversation remains in Cortex. The objective remains consistent. The execution environment can change without forcing the user to reconstruct the task.

This turns Cortex Connect into more than a bridge between screens. It becomes a connected execution layer spanning personal development environments and managed cloud capacity.

The progression is straightforward:

• Cortex Connect allows the experience to move with the user.
• Cortex Cloud allows eligible execution to move with the workflow.

Together, they support a more complete form of Enterprise AI: available wherever work begins, connected to the project that matters, and capable of continuing beyond the limits of a single open device.

A visible Local or Cortex Cloud choice

Powerful infrastructure is most useful when the product experience remains simple.

Cortex now presents a compact execution selector across Visual Studio Code, supported browsers, and mobile. Users can choose Local or Cortex Cloud without leaving the conversation or navigating through infrastructure settings.

Local execution is appropriate when work should remain on the connected development machine and use its available project environment. Cortex Cloud is appropriate when the user wants eligible work to continue in a managed remote environment.

The selected destination is clearly indicated across the experience. The control is available only within an authenticated Cortex session, and the product carries the selection with the request so the execution decision remains consistent as the workflow moves through the platform.

The simplicity of this control matters. Enterprise users should not need to configure the infrastructure behind each request. Cortex handles the managed cloud environment within the boundaries established for the organization and the workflow.

From the customer’s perspective, the interaction remains natural:

1. Express the objective in Cortex.
2. Choose Local or Cortex Cloud.
3. Follow progress in the same connected experience.
4. Review the result where it is most useful.

That is the product experience. The infrastructure exists to support it, not to become another system the user must operate.

Start in the browser or on mobile, run through Cortex Cloud

Cortex Cloud is especially important for the cross-surface workflows introduced by Cortex Connect.

Consider a developer reading a library migration guide in the browser. The developer recognizes a repetitive repository task that would be useful to run remotely. From the Cortex browser experience, the developer can describe the objective, choose Cortex Cloud, and start the workflow while the connected project provides the authoritative project relationship.

Or consider an engineering lead away from a desk. A project question arrives, and the lead uses Cortex on mobile to request a bounded engineering action. Rather than waiting to return to the workstation and manually recreating the request, the lead can choose Cortex Cloud and maintain visibility from the phone.

The same pattern works from Visual Studio Code. A developer already working in the project can choose the execution destination that best fits the moment. Local execution remains immediately available for work that belongs on the developer’s machine. Cortex Cloud provides a remote destination for eligible tasks that should continue in managed cloud infrastructure.

In each case, Cortex Connect provides the continuity between the user, the conversation, and the project. Cortex Cloud adds a durable place for execution.

The product does not treat browser, mobile, and Visual Studio Code as separate versions of Cortex. They are connected work surfaces participating in the same workflow. The user can initiate from one surface, observe from another, and return to the development environment for project review without moving prompts and status updates manually.

From the three Cortex Routers to an execution destination

Model Routing, Search Routing, and Skill Routing help Cortex connect a request with the appropriate intelligence, current public information, and focused engineering practices.

Cortex Cloud adds another dimension to that coordinated experience: where eligible work should execute.

These responsibilities are related, but they are not the same.

Model Routing helps Cortex identify the form of intelligence appropriate for the request. Search Routing helps determine when current public information should inform the work. Skill Routing brings relevant engineering guidance into the workflow. The Local or Cortex Cloud selection establishes the execution boundary chosen by the user.

Together, they create a more complete path from intent to outcome:

• The user describes what they want.
• Cortex coordinates the appropriate intelligence.
• Current information and relevant engineering practices can contribute when needed.
• The user selects the appropriate execution destination.
• Cortex carries the workflow into that environment while preserving progress and control.

This separation is valuable for enterprises. Intelligence can evolve without changing the user’s work surface. Search services can expand without redefining how a project is executed. Engineering practices can become more specialized without exposing their internal organization. Cloud capacity can grow without requiring every user to manage infrastructure.

The result is one Cortex experience with coordinated specialization underneath.

A high-level view of Cortex Cloud

Cortex Cloud is designed as a managed execution extension of the Cortex platform. At a high level, the product brings together six customer-facing engineering concepts.

1. A connected control layer

Cortex remains the consistent entry point across Visual Studio Code, browser, mobile, and DevSecOps. User identity, workflow ownership, execution choice, progress, and available actions stay coordinated through the platform.

Clients do not need to operate cloud infrastructure directly. They communicate through the same Cortex product layer that already coordinates conversations and workflows. This provides a stable product boundary as the execution platform evolves.

2. Durable workflow state

Cloud work should not depend on a chat window remaining open.

Cortex records the workflow state needed to continue an eligible task, associate it with the correct user and project, and restore meaningful progress after an interruption. A temporary connection loss, browser refresh, or change of device does not need to turn an active workflow into an unknown outcome.

This durability is central to the value of Cortex Cloud. Remote execution is not simply a local command moved to another machine. It is a workflow that remains identifiable, observable, and recoverable across the Cortex experience.

3. Revision-aware project handoff

Dependable cloud execution requires a clear definition of the project being used.

Cortex Cloud works from an exact committed project state rather than an ambiguous moving target. The connected development workspace establishes the project relationship, while Cortex checks that the source state is suitable for a cloud handoff.

This means uncommitted local changes are not silently treated as though they already exist in the cloud. If the working copy is not in an eligible state, Cortex stops the handoff and gives the user a clear opportunity to prepare the project first.

For the business, this creates a stronger basis for repeatability and review. For the developer, it reduces the risk that a remote result was produced from a different version of the project than expected.

4. Managed, isolated execution workspaces

Once an eligible workflow reaches Cortex Cloud, the platform prepares a dedicated execution workspace associated with the authorized project and workflow.

The cloud environment is separated from the user’s local machine and governed by platform controls. It receives only the scoped capabilities required for the approved task. Compute placement and worker selection remain platform responsibilities rather than user-facing configuration decisions.

This abstraction allows Cortex Cloud to support different deployment and capacity models over time while preserving one consistent product experience.

5. Remote execution capacity

Cortex Cloud separates the interactive client from the managed capacity used to perform the task. Eligible work can continue remotely, report progress, and return results through the Cortex platform.

This creates operational flexibility. Capacity can be managed centrally, work can continue without consuming the user’s active editor session, and organizations can apply their established access and availability policies. Cortex handles ordinary service interruptions without exposing infrastructure lifecycle details to the user.

6. Progress and result continuity

Cloud execution is useful only when users can understand what is happening.

Cortex carries meaningful workflow progress back into its existing task surfaces. Users can see whether work is being transferred, is active, needs attention, has completed, or could not proceed. If the connection is interrupted, the experience can restore the latest durable state when the user returns.

Completion is reflected consistently: active indicators stop, actions update, and the final result is connected to the workflow that produced it. Users do not need to infer completion from a stale spinner or repeat a request because one screen was closed.

The high-level Cortex Cloud workflow

The detailed mechanics of Cortex Cloud remain internal, but the customer-facing workflow can be understood in a few broad phases.

Intent and destination. The user expresses an objective through Cortex and chooses Local or Cortex Cloud. Cortex continues to apply the intelligence, search, and skill coordination appropriate to the request.

Project readiness. For project-aware cloud work, Cortex confirms that the user is authenticated, the project is connected, and the source state can be represented by a stable committed revision. This protects the boundary between uncommitted local work and remote execution.

Durable handoff. Cortex associates the objective with a durable workflow and carries the relevant execution context into the managed cloud environment. Workspace and compute selection happen automatically within the configured organizational boundaries.

Remote action. Cortex Cloud performs the eligible task in a scoped execution workspace. The environment is distinct from the user’s device, and the operation is associated with the correct user, workflow, project, and source state.

Progress and completion. Meaningful state returns through Cortex so the user can follow the work from Visual Studio Code, browser, mobile, or the DevSecOps Task Center. The final result remains tied to the originating workflow, and completed work follows the platform’s managed lifecycle.

Customers receive the value of durable, controlled cloud execution without being exposed to internal orchestration, service interfaces, or infrastructure implementation details.

Why a clean committed state matters

The requirement for a clean, committed project state is more than a technical prerequisite. It defines a trustworthy boundary between a developer’s private working copy and a remotely executed workflow.

A local workspace may contain experiments, generated files, partial edits, or changes that have not yet been reviewed by the developer. Automatically transferring that ambiguous state would make it harder to answer basic questions:

• What source version did Cortex use?
• Can another team member review the same starting point?
• Is the cloud result associated with work that actually exists in the repository history?
• Did the remote workflow include a local edit the developer did not intend to share?

By grounding a cloud handoff in a stable source revision, Cortex Cloud gives the workflow a clear point of reference. The user remains responsible for deciding when local work is ready to become part of that source state. Cortex is responsible for preserving the relationship between the workflow and the selected revision.

This is not intended to add friction. It is intended to make the cloud result understandable. In enterprise engineering, traceability begins with knowing what was acted upon.

Built for interruptions, not just ideal connections

Real enterprise workflows encounter interruptions.

A laptop sleeps. A browser reloads. A mobile connection changes networks. A user closes the chat panel and returns later. A temporary service interruption occurs while work is in progress.

Cortex Cloud is designed around durable workflow state rather than the assumption of one uninterrupted client connection. The active screen is a view into the work, not the sole owner of it.

That distinction enables several important behaviors:

• Workflow progress can be restored after reconnecting.
• The same task can remain visible across connected Cortex surfaces.
• Duplicate submissions can be handled consistently instead of creating uncertain parallel work.
• Cancellation and completion can be reflected as durable states.
• A user can distinguish between work that is active, completed, interrupted, or unable to start.
• Platform services can recover the workflow without requiring the user to repeat the original request.

These capabilities build directly on Cortex’s work in long-running AI reliability. As described in Delivering Long-Running Workflows Without Losing Context, dependable Enterprise AI must preserve the facts, constraints, decisions, and authoritative references that determine correctness while making room for new work.

Cortex Cloud applies the same broader principle to execution: preserve the durable state that determines what the workflow is, where it belongs, what project state it uses, and how the user can continue.

A more useful role for mobile

Mobile AI should not attempt to compress a complete desktop engineering environment into a small screen.

Its value is different. Mobile is an excellent surface for access, awareness, initiation, and timely control. Cortex Cloud makes those strengths more meaningful.

With Cortex Connect alone, a mobile request could reach a connected development workspace. With Cortex Cloud, eligible work can be directed to a durable managed execution environment while the user continues to follow the workflow from the phone.

This creates practical enterprise scenarios:

• An engineering lead can initiate a bounded repository task while away from the desk.
• A developer can monitor a longer-running workflow without keeping the editor in the foreground.
• A user can see when a cloud task completes and return to the project for review.
• A team member can respond to a workflow that needs attention without reconstructing its status from another device.

The phone remains a mobile control surface. Cortex Cloud supplies the execution reach that makes that surface useful for more than conversation.

A stronger role for the browser

The browser is where a large portion of enterprise context already lives: documentation, issue trackers, pull requests, knowledge systems, dashboards, customer systems, and operational tools.

Cortex in the browser helps users engage AI close to that context. Cortex Connect connected those moments to the development workspace. Cortex Cloud allows eligible execution to continue in managed infrastructure after the user identifies what needs to be done.

This reduces a common productivity tax. Without a connected experience, the user must copy information into a new tool, restate the project, choose an environment, reproduce the objective, run the work, and then manually carry the result back.

With Cortex, the browser can remain the place where the need is recognized. The connected project supplies the development relationship. Cortex Cloud supplies the remote execution destination. Progress and results remain part of the same workflow.

This is how Enterprise AI becomes more than a feature embedded in a webpage. It becomes a control layer connecting information with action.

Visual Studio Code remains central

Cortex Cloud does not reduce the importance of the developer environment. It makes the relationship between the developer environment and cloud execution more explicit.

Visual Studio Code remains the place where many developers understand project structure, make local changes, review diffs, use development tools, and decide when work is ready to share. Cortex Connect uses that environment to establish the trusted project relationship required for project-aware workflows.

The new execution selector gives developers a direct choice. Work can remain Local when the current workstation is the right destination. It can move to Cortex Cloud when managed remote execution better fits the task.

This supports a hybrid model rather than a forced migration:

• Local execution preserves proximity to the active development environment.
• Cortex Cloud provides durable remote execution capacity.
• Cortex keeps the conversation, workflow, and result connected across both.

Developers do not have to adopt a completely separate cloud interface or abandon their familiar editor. Cortex Cloud becomes another execution destination within the same product experience.

DevSecOps becomes the operational view

Cross-surface execution also requires a place where active and completed work can be understood at a broader level.

DevSecOps provides a Cloud Workflows experience within the Task Center. It presents customer-safe workflow state, including progress, outcome, region when applicable, available actions, and useful error guidance. It also provides a consistent place to refresh state, manage eligible workflow actions, and understand completed cloud activity.

This is especially valuable for users who work across several devices. The DevSecOps experience is not a separate control plane exposed to the customer. It is an authenticated product surface over the same durable Cortex workflow state.

That distinction keeps the experience coherent:

• Clients show the state relevant to the current conversation.
• The Task Center provides a broader workflow view.
• The Cortex platform remains authoritative for what actions are available.
• Cloud infrastructure stays behind the product boundary.

The result is visibility without infrastructure overload.

Business value: extending productive time without extending complexity

Cortex Cloud creates value at several levels of the organization.

For developers

Developers gain another execution option without leaving Cortex or learning a separate job system. They can choose the environment appropriate for the task, reduce dependence on the availability of one active editor session, and return to a result connected to the original objective and project state.

For engineering leaders

Engineering leaders gain stronger workflow continuity and visibility. Cloud work can be associated with users, projects, and durable states rather than existing as an opaque process on an individual laptop. This can make it easier to understand what is active, where intervention is required, and whether work completed.

For platform teams

Platform teams gain a foundation for centrally managed execution capacity. Organizational policy, regional availability, workload admission, and resource management can be applied behind a stable Cortex interface instead of being reimplemented independently in every client.

For enterprises

Enterprises gain a hybrid execution model that respects both developer-local work and centrally operated infrastructure. The organization can expand cloud capacity without turning every user into an infrastructure operator. Durable state, authenticated ownership, revision awareness, and lifecycle visibility create a better foundation for governed AI-assisted work.

For distributed teams

Distributed teams gain continuity across time zones, devices, and work locations. A workflow is less dependent on the device from which it began, while the final result remains connected to the responsible user and project.

The broader benefit is leverage. Cortex Cloud extends when and where AI-assisted engineering work can continue while keeping the user experience consistent.

Control without turning the product into infrastructure

Enterprise control does not require exposing every infrastructure decision to every user.

Cortex Cloud is designed to separate user intent from operational placement. The user chooses the execution boundary—Local or Cortex Cloud. The platform handles the managed details required to place eligible work, maintain its state, report progress, and complete its lifecycle.

At a high level, enterprise controls include:

• Authenticated access to cloud execution.
• Ownership boundaries for workflows and workspaces.
• Source revision checks before project-aware handoff.
• Organizational and regional policy enforcement.
• Capacity and usage controls.
• Auditable, content-conscious operational events.
• Managed retention and cleanup behavior.
• Clear failure states instead of silent fallback to a different execution destination.

That final point matters. If a user chooses Cortex Cloud, local project commands should not run merely because the cloud path is unavailable. The selected boundary is part of the user’s intent. Cortex either proceeds through the eligible cloud path or explains why it cannot.

This behavior strengthens trust. Convenience should not erase the distinction between a personal development machine and managed cloud infrastructure.

Designed to scale behind a stable experience

The base Cortex Cloud architecture separates the product-facing control layer from the managed execution capacity behind it.

This allows the cloud platform to evolve without changing how users interact with Cortex. Capacity can be matched to organizational demand while work and results remain connected to the durable task.

The engineering objective is not to expose a distributed system. It is to make the distributed system disappear behind a dependable product contract.

For users, the experience remains:

• One authenticated Cortex identity.
• One conversation and workflow history.
• One visible execution choice.
• One consistent view of progress and completion.

For operators, the platform creates room for capacity planning, service availability, observability, and lifecycle management.

This separation is what allows Cortex Cloud to grow without forcing the clients to be redesigned around every infrastructure change.

Operational visibility without exposing customer content

Cloud execution introduces legitimate operational questions. Is capacity available? Did the workflow start? Is it still active? Did it complete? Was it cancelled? Did an interruption require recovery? Which region handled the work? How much cloud activity is the organization using?

Cortex Cloud is designed to make those questions observable through bounded operational metadata rather than requiring raw customer code or conversation content to appear in ordinary platform reporting.

Useful signals can include workflow state, timestamps, region, resource usage, outcome category, retry guidance, and lifecycle events. These signals help operators understand service behavior while keeping the product focused on customer-safe visibility.

For business leaders, this supports clearer adoption and capacity decisions. For engineering teams, it reduces uncertainty around remote work. For platform operators, it provides a foundation for service health and usage management.

The principle is simple: make the operation visible without making customer content the monitoring surface.

Failure should be understandable

Remote execution can fail for many ordinary reasons: the project may not be in a transferable state, the connected workspace may be unavailable, organizational policy may not permit the requested destination, regional capacity may be unavailable, or the remote task itself may not complete successfully.

A trustworthy product should not compress all of those conditions into a generic error.

Cortex Cloud returns structured, customer-appropriate states through Cortex so the user can distinguish between preparation issues, availability issues, active work, cancellation, and terminal outcomes. Where a retry is appropriate, the experience can indicate that. Where the project must be prepared first, Cortex can explain the required action. Where an operation has already completed, the product restores that result instead of treating it as new work.

This approach improves both usability and supportability. Users receive clearer next steps. Support and operations teams receive more meaningful categories. The platform avoids ambiguous states in which the user cannot tell whether repeating a request will resume work or create another operation.

Cloud execution that respects user intent

One of the most important design principles in Cortex Cloud is that the execution target is explicit.

If the user selects Local, Cortex keeps eligible execution within the connected local environment. If the user selects Cortex Cloud, Cortex prevents that cloud-designated work from being dispatched as local workspace execution.

This makes the selector more than a visual preference. It represents an execution boundary.

The same principle applies when the user is not authenticated. Cloud execution choices are not presented as available actions outside an authenticated session. When authentication changes, the interface updates so a stale menu cannot imply that an unavailable destination remains usable.

These details may appear small, but they shape product trust. Enterprise users need confidence that the system will honor the selected environment consistently across devices and throughout the workflow.

Cortex Cloud and the evolution from answers to outcomes

The Cortex roadmap has followed a consistent direction.

The Cortex AI Model Ensemble brought specialized intelligence to different responsibilities. Cortex Router created a coordinated entry point. Cortex Planner added structure for larger objectives. The three Cortex Routers connected intent with models, current information, and engineering practices. Cortex Connect carried that coordinated experience across mobile, browser, and Visual Studio Code.

Cortex Cloud now extends the path into managed execution.

The value is not simply that code can run somewhere other than a laptop. The value is that the execution remains part of an enterprise workflow:

• It begins with an authenticated user and a clear objective.
• It remains connected to the relevant Cortex conversation and project.
• It uses a defined execution destination.
• It is grounded in a stable project state.
• It exposes meaningful progress across work surfaces.
• It produces a result tied to the workflow that requested it.

This is the difference between remote compute and connected Enterprise AI. Compute is a resource. Cortex Cloud turns that resource into a governed continuation of user intent.

A foundation for the next phase of Cortex

This base release focuses intentionally on the fundamentals: execution choice, durable handoff, managed cloud workspaces, remote capacity, cross-client progress, clear completion, and enterprise control.

Those fundamentals matter because advanced capabilities are only as dependable as the execution layer beneath them. Before expanding the kinds of work performed in Cortex Cloud, the platform needs a stable way to identify the user, connect the right project, preserve workflow state, honor the selected destination, manage compute, survive interruptions, and return a trustworthy result.

Cortex Cloud establishes that foundation. Cortex Cloud begins as a durable execution extension of Cortex Connect. It creates the managed environment through which new cloud capabilities can later participate in the same connected control layer.

What customers gain with the base Cortex Cloud release

The initial Cortex Cloud experience provides:

• A clear Local or Cortex Cloud execution choice.
• The ability to initiate eligible cloud work from Visual Studio Code, browser, and mobile.
• A managed execution destination connected to the Cortex workflow.
• Durable task state that does not depend on one open screen.
• Project-aware handoff grounded in a stable committed source revision.
• Automatic workspace and compute placement within organizational boundaries.
• Meaningful progress and completion state across connected Cortex surfaces.
• A Cloud Workflows view in the DevSecOps Task Center.
• Authenticated ownership and enterprise policy controls.
• Clear separation between local and cloud execution boundaries.
• Operational visibility designed around metadata rather than customer content.
• A scalable foundation for future cloud capabilities.

For individual users, this means more freedom to start, monitor, and complete work across devices. For teams, it means better continuity and visibility. For enterprises, it means an extensible control layer that can connect user intent with managed execution without exposing the complexity of the underlying infrastructure.

Cortex Connect, now with a cloud execution layer

Cortex Connect changed the question from “Which screen owns the conversation?” to “Where can the work be completed with the right context and control?”

Cortex Cloud expands the answer.

The right place may still be the developer’s local environment. It may now also be a managed cloud workspace designed to continue eligible work durably and return the result through Cortex. The user chooses the boundary. Cortex coordinates the experience.

Model Routing helps select the right intelligence. Search Routing brings in current public information when needed. Skill Routing applies relevant engineering practices. Cortex Connect keeps the user, project, and workflow joined across work surfaces. Cortex Cloud provides a new execution destination for the outcome.

One request can begin on mobile, browser, or Visual Studio Code. One connected workflow can carry the intent forward. One explicit choice can determine whether eligible work runs locally or in Cortex Cloud. Progress remains visible. The project remains grounded. The user remains in control.

That is the next level of Cortex Connect and the beginning of Cortex Cloud.