Decision Intelligence with Two New Specialized Models

The tenth and eleventh specialized Cortex models add a decision layer for fast, governed action

Enterprise AI does not need a large generative model for every step of every request. Many important moments are decisions: where work should go, whether an action needs approval, whether code appears vulnerable, or whether a proposed security fix is safe enough to continue through the workflow.

The first generation of enterprise AI products often treated every request as a generation problem. A user supplied context, a large model interpreted it, and the model produced a natural-language answer. That approach is useful when the work genuinely calls for explanation, synthesis, code generation, or open-ended reasoning. It is less efficient when the next step depends on a bounded operational judgment.

An enterprise platform encounters those judgments constantly. A request may need to be classified before it is allowed to start a workflow. A security observation may need triage before a full investigation is justified. A proposed action may require approval, while another can proceed through an established low-risk path. Asking the deepest model in the system to resolve every one of these questions adds latency and infrastructure demand without necessarily adding value.

Pervaziv AI is introducing two specialized models for those moments: Cortex Routing Decisions, the tenth model in the Cortex AI Model Ensemble, and Cortex Security Decisions, the eleventh.

Together, they establish a third model category in Cortex. Local models keep eligible work close to the user. Agent and backend models perform deeper reasoning, planning, execution, analysis, and verification. Decision models provide fast, structured judgments that help Cortex choose the right next step.

This extends the coordinating entry point introduced with Cortex Router, the control layer described in From Intent to Action with Three Cortex Routers, and the execution intelligence introduced in From Routing to Execution Planning with Cortex Planner. Routing connects a request to the right capability. Planning organizes the work. Decisions now make common control and security judgments faster, while preserving access to the richer Cortex specialists when the task requires them.

Why a dedicated decision layer now

As Cortex has expanded across local intelligence, specialist models, connected enterprise context, routing, planning, and governed execution, the number of useful paths through the system has grown. That is a sign of capability, but it also makes the quality of the control layer more important.

A single request may involve several distinct questions:

• Is this a direct action, a coding workflow, a lookup, a security task, or a conversational response?
• Is the requested action supported and sufficiently specified?
• Does the work require approval or carry elevated execution risk?
• Does the supplied code appear vulnerable, and what type of security concern is present?
• Is a proposed change clearly invalid, apparently safe, or uncertain enough to require deeper verification?

These are not all requests for generated content. They are decision points that determine which intelligence should be used next.

The dedicated Decisions category gives Cortex a way to resolve common bounded questions with a response designed for control systems rather than prose. It helps reduce time spent before useful work begins, avoids unnecessary use of larger specialists, and makes escalation an explicit product behavior instead of an improvised response.

This is also an important step in the maturity of the ensemble. Specialization is no longer limited to the visible task—coding, analysis, verification, or planning. Cortex now specializes the invisible decisions that coordinate those capabilities.

Three model categories, one Cortex experience

The Cortex AI Model Ensemble now spans three complementary categories:

These categories are not competing ways to run the same request. They are different forms of intelligence for different stages of work.

A decision model can resolve a bounded question quickly. An agent model can investigate ambiguity and produce a rich result. A local model can keep eligible interactions responsive and private. Cortex coordinates them so users do not have to select a model for every step.

The categories also create clearer responsibility boundaries.

Local models emphasize proximity. They are valuable when privacy, responsiveness, and access to local context matter most. Their role is not defined solely by size; it is defined by where eligible work can be handled and how closely that work can remain connected to the user’s environment.

Agent and backend models emphasize depth. They can reason across larger contexts, create plans, generate or modify code, explain findings, and produce evidence-bearing outcomes. Cortex LLM, Cortex Code, Cortex Planner, Cortex Analysis, and Cortex Verify belong to this broader class of specialist intelligence.

Decision models emphasize precision at the control boundary. Their output is intended to be interpreted as a bounded judgment: select a route, identify a risk class, assign a security category, or determine whether escalation is required. They are designed to help the system decide what should happen next, not to imitate the complete output of an investigative or generative specialist.

This separation makes the ensemble easier to govern. Each class can be evaluated against the kind of result it is expected to produce. A routing decision can be measured as a routing decision. A security classification can be evaluated as a classification. A detailed security analysis can still be judged by the quality and traceability of its findings.

Cortex Routing Decisions: the tenth specialized model

Cortex Routing Decisions turns an incoming request into a structured routing judgment. It helps Cortex determine whether the request should move directly to a supported action, enter a coding workflow, use connected enterprise or external information, invoke security capabilities, request clarification, or return a response without starting a larger workflow.

This model complements the three Cortex Routers rather than duplicating them. The broader routing layer coordinates access to models, enterprise search, and engineering skills. Cortex Routing Decisions focuses on the bounded judgment inside that experience: what kind of handling does this specific request require, and is the proposed route complete enough to use?

That additional precision matters because two requests that sound similar may require very different handling. “Show me the files in this directory” may map cleanly to a supported action. “Review the project and decide what should be changed” requires investigation and a broader workflow. “Find the service owner” may need connected enterprise context. “Is this patch safe?” belongs on a security path. The decision model helps Cortex distinguish these operational forms before committing resources to execution.

The model can also contribute signals about execution risk and whether approval is required. Those signals do not bypass policy. They give the Cortex control layer a faster way to apply existing permissions, validation, and workflow rules.

For common, well-defined requests, this replaces an unnecessary heavyweight generative pass through the existing Cortex Router path. For ambiguous requests, unsupported actions, or outputs that do not satisfy the surrounding controls, Cortex Router can continue through its established generative path. The result is a selective fast path rather than a weaker all-or-nothing replacement.

This distinction matters. A fast decision is valuable only when Cortex can trust its shape, scope, and confidence. The surrounding control layer remains responsible for validating that the proposed route is allowed and complete before any action proceeds.

It also makes routing more consistent across Cortex experiences. Users may begin work from an IDE, terminal, browser, or another supported surface, but the underlying intent should not change merely because the entry point changed. A dedicated routing decision provides a common judgment that the surrounding product can interpret within the permissions and context of that surface.

Routing performance without giving up the fallback

In a controlled same-host comparison across a broad held-out routing suite, Cortex Routing Decisions was evaluated across supported routing outcomes and direct actions. The evaluation measured both the quality of the selected path and the amount of work required to reach that judgment.

The median routing stage moved from a multi-second interaction to less than one-tenth of a second. That changes more than a benchmark chart. It makes routing feel immediate, reduces the delay before useful work starts, and leaves more accelerator capacity available for planning, generation, analysis, and verification.

The memory result is similarly important. The measured decision path required more than 60% less resident accelerator memory than the existing Router comparison. That gives deployments more flexibility to keep additional capabilities resident, serve more concurrent work, or reserve capacity for the larger specialists that need it.

The paired results show that this was not merely a latency improvement. Routing Decisions materially improved the combined routing-and-action result over the existing Router path across the held-out suite. It also maintained broad coverage across supported routing outcomes and actions.

The fallback remains part of the production design because aggregate quality does not make every individual decision equally safe. When a result is unsupported, incomplete, or uncertain, Cortex can use the established Cortex Router path instead of forcing the faster path to make a decision beyond its scope.

Benchmark results are workload-, configuration-, and hardware-dependent. They describe the measured test environment and are not a guarantee of performance in every deployment.

The result is significant because routing sits near the beginning of the interaction. A delay at that stage is experienced before investigation, planning, or execution can even begin. Reducing that delay improves the perceived responsiveness of the entire system, including workflows whose later stages still use a larger specialist.

Cortex Security Decisions: the eleventh specialized model

Cortex Security Decisions brings the same idea to recurring security judgments. It is designed for bounded questions such as whether code appears vulnerable, the likely security category and severity, whether exploitation conditions appear present, and whether a proposed patch satisfies a security validity check.

Security workflows contain many classification points before and between the deeper tasks. Teams need to separate likely vulnerabilities from benign patterns, distinguish one security family from another, prioritize issues by likely severity, and determine whether a proposed mitigation deserves immediate rejection, deeper inspection, or progression to verification.

Without a dedicated decision layer, even an initial triage question can require the same kind of heavyweight path used to produce a complete security review. Cortex Security Decisions gives the ensemble a faster front door for these recurring judgments.

These classifications can accelerate triage, prioritize attention, and prevent expensive specialist work from becoming the default for every low-risk or clearly classified case. They can also help Cortex identify when a request must be escalated to deeper analysis or verification.

The boundary is intentional. Cortex Security Decisions returns classifications, not the detailed findings, code-level evidence, exploit narratives, or verification record produced by the broader security ensemble. When evidence is required, Cortex Analysis remains the appropriate specialist. When a consequential patch needs an evidence-bearing verdict, Cortex Verify remains in the workflow.

The decision model therefore replaces heavyweight security inference where a structured classification is sufficient. It does not turn a fast classifier into an autonomous security authority.

That boundary protects both speed and trust. If the question is “which category best describes this code pattern?”, a classification may be the complete answer required by the workflow. If the question is “show exactly where the vulnerability occurs, explain the attack path, and provide evidence for remediation,” the work belongs with Cortex Analysis. If the question is whether a consequential patch can be accepted, Cortex Verify and the applicable human or policy controls remain part of the path.

Security Decisions can therefore reduce unnecessary work without reducing the standard applied to important work. It provides an efficient first judgment and a clear escalation point.

A faster security front door

The same-host security comparison used separate held-out Analysis and Verify suites. It measured shared classification responsibilities while preserving the richer findings and evidence contracts of Cortex Analysis and Cortex Verify.

In these measurements, the Security Decisions path used more than 60% less resident accelerator memory while handling the classification stage. The runtimes use different memory allocators, so this is an operational footprint comparison rather than an allocator-identical measurement.

Against Cortex Analysis, the decision path delivered approximately a 24× median latency improvement and more than 20× measured throughput. Against Cortex Verify, it delivered approximately an 11× median latency improvement and more than 10× measured throughput. Even the lower of those two results represents a major change in how quickly Cortex can answer a bounded security question.

The estimated energy reductions follow from the much shorter measured processing time and lower resource footprint. They are directional operating estimates, not universal power guarantees, but they show why specialized decision intelligence can matter at enterprise scale: repeated classification work no longer has to consume the same resources as a complete investigation or evidence-bearing verification.

The broader comparison also measured classification quality. Security Decisions improved shared vulnerability and severity classification over Cortex Analysis, while maintaining strong security-family classification. It also exceeded Cortex Verify on the shared Boolean patch-validity measure. These shared-label comparisons do not measure the richer evidence produced by the specialist models.

The selective policy is where classification quality becomes an operational result. On the held-out comparison suites, Security Decisions avoided downstream Analysis and Verify calls for carefully selected cases with no observed errors in those selected paths. Uncertain or apparently valid patches continued to Cortex Verify, while severity decisions lacking sufficient impact context escalated to Cortex Analysis.

When the remaining requests are charged for both classification and specialist escalation, the projected hybrid path still delivered material latency savings for both Analysis-oriented and Verify-oriented traffic. Performance measurements and security-quality qualification remain separate; a fast result enters the fast path only when its classification and policy conditions are also satisfied.

Those figures describe performance, not permission to skip evidence. Release qualification also evaluates classification quality, calibration, conservative escalation, and fallback behavior. Detailed findings, uncertain classifications, high-impact changes, and patch approval continue to use the appropriate specialist path.

This is the practical value of the decision layer: accelerate the common bounded judgment while retaining the depth of the security ensemble when the consequence demands it.

Performance compounds across the workflow

Routing and security decisions frequently occur before the most expensive part of a request. Improving those stages has a compounding effect: users reach the right capability sooner, unnecessary specialist calls are avoided, and the specialists retain capacity for requests that need deeper reasoning.

The measured improvements translate into three practical benefits:

• Faster time to action. A routing decision that completes in under 100 milliseconds can begin the next stage almost immediately instead of adding multiple seconds before work starts.
• Higher useful capacity. Double-digit to roughly 24× throughput improvements across the measured decision workloads allow the control layer to process substantially more classifications within the same period.
• More efficient model residency. More than 60% lower resident accelerator-memory demand frees capacity for Cortex Planner, Cortex Code, Cortex Analysis, Cortex Verify, and other specialists when they are actually required.

These gains are not based on lowering the standard for consequential work. They come from matching the amount of intelligence used to the decision being made. A bounded classification uses the decision layer. A complex investigation uses the specialist ensemble. Cortex preserves both paths and selects between them under policy.

At larger request volumes, this distinction becomes increasingly valuable. A system that sends every classification to the most resource-intensive model consumes capacity that could otherwise support investigations, remediation, and verification. Moving eligible decisions to a specialized path can reduce queueing pressure for the entire ensemble, not only for the individual request that takes the fast path.

The customer-visible result is a system that can feel faster while remaining deliberate. Common decisions return quickly. Larger tasks still receive the time and intelligence they require. The ensemble becomes more efficient because it is more selective, not because it omits the difficult parts of the workflow.

Which decision model has higher priority?

The numbering reflects launch order, not importance. Cortex Routing Decisions is the tenth model because routing is encountered early and broadly across requests. Cortex Security Decisions is the eleventh model because it adds a specialized security judgment layer.

Operational priority is contextual:

• Routing comes first in the request sequence because Cortex must determine what kind of work is being requested.
• Security takes precedence when risk is involved because a security signal can constrain, escalate, or stop the route that would otherwise be selected.

In other words, routing has broader reach, while security has higher authority within security-sensitive workflows. Cortex does not trade one for the other. It composes them according to the request and the organization’s controls.

Consider a request that appears to ask for a direct file change but includes a security-sensitive operation. Routing may identify the operational path, but the security judgment can still require escalation, approval, or deeper verification. The earlier routing decision does not outrank a later risk signal.

The same principle applies in the other direction. Not every request needs security analysis. Routing prevents the security path from becoming a universal tax on ordinary interactions, while still making it readily available when the request or context warrants it.

This is why priority should be understood as responsibility rather than rank. Routing is responsible for broad coordination. Security is responsible for constraining risk. Both are necessary to reach the right outcome efficiently.

From intent to decision to execution

The two new models make the relationship among Cortex routing, planning, and execution more precise.

1. Intent enters Cortex. The user asks a question or requests work through a supported Cortex experience.
2. Routing identifies the path. Cortex determines the capability, workflow, or specialist appropriate for the request.
3. Decisions resolve bounded judgments. Routing and security decisions provide structured signals about action class, risk, approval, vulnerability, severity, or patch validity.
4. Planning organizes complex work. When the request requires multiple steps, Cortex Planner creates a governed execution plan.
5. Specialists execute and produce evidence. Cortex Code, Cortex Analysis, Cortex Verify, and other ensemble capabilities handle the deeper work appropriate to their roles.
6. Policy validates progression. Permissions, confidence, output validity, and organizational controls determine whether the workflow proceeds, escalates, or asks for human input.

This architecture avoids using generative intelligence as a universal hammer. It also avoids the opposite mistake of asking a compact decision model to produce evidence or execution it was not designed to provide.

The progression can be short or long. A simple supported request may move from intent to a routing decision and then directly into an approved action. A security-sensitive change may move from routing to classification, then to detailed analysis, planning, implementation, and independent verification. Cortex can use only the stages that add value for the specific request.

That adaptability is central to the ensemble. A fixed pipeline would force every request through the same cost and latency. An unstructured collection of models would leave users or applications to assemble the path themselves. Cortex instead uses governed decisions to select an appropriate progression.

Four examples of the decision layer in practice

A clearly supported action. A developer asks Cortex to perform a precise, low-ambiguity workspace operation. Routing Decisions identifies the supported action and the surrounding control layer validates that it is permitted. The user avoids a multi-second generative routing step, and the requested work can begin sooner.

An underspecified engineering request. A user asks Cortex to “fix the project” without identifying the failure, expected result, or scope. Routing Decisions can identify that the request needs clarification or investigation rather than forcing it into a direct action. The fast path improves responsiveness without inventing missing intent.

A likely security issue. Code or a finding enters a security workflow. Security Decisions can classify the likely vulnerability family and severity, helping Cortex prioritize the next step. If the workflow requires locations, evidence, exploit reasoning, or remediation detail, the request continues to Cortex Analysis.

A proposed security patch. Security Decisions can identify an apparently invalid or uncertain patch early, preventing an unsupported approval. A consequential acceptance decision continues through Cortex Verify and the applicable controls. The decision layer shortens obvious cases while preserving independent verification for the cases that matter most.

These examples share the same pattern: the new models do not attempt to complete every kind of work. They make the next action clearer and faster.

Replacing model calls, not removing model depth

“Replacement” has a specific meaning in the Cortex decision layer. For eligible requests, a decision model replaces a slower generative inference step. It does not eliminate the specialist from the ensemble.

Cortex Routing Decisions can replace the existing generative routing pass within Cortex Router when the route is supported and validated. Cortex Security Decisions can replace an Analysis or Verify call when the workflow needs only a bounded classification and policy permits the early result.

The deeper models remain available for:

• Ambiguous or novel requests
• Detailed security findings and supporting evidence
• Remediation guidance and code changes
• Consequential patch verification
• Complex planning and multi-step execution
• Cases that fall outside the supported decision scope
• Results that do not meet confidence, calibration, or policy requirements

This cascade improves efficiency while preserving the richer capabilities customers already rely on.

It also allows adoption to be incremental. Organizations do not have to choose between the established specialist path and the new decision path. Eligible decisions can move to the faster route while existing controls continue to handle everything else. As measured coverage and confidence improve, more bounded cases can use the decision layer without redefining what counts as sufficient evidence.

That is a more durable replacement strategy than swapping one model for another across every request. Cortex replaces work at the level where the new capability is demonstrably appropriate.

Technical trust at the decision boundary

Fast decisions still need clear boundaries. Cortex uses its decision models for well-defined, lower-risk classification tasks and keeps deeper specialist intelligence available for complex, consequential, or uncertain work.

The goal is not automation for its own sake. It is to make routine decisions more consistent and immediate, so the larger ensemble can concentrate its reasoning on requests that genuinely need it. Teams receive a clear next step without having to manually select a model or trade away the context of the wider Cortex experience.

For security in particular, speed is never a substitute for evidence or review. The decision layer can help prioritize the next step, while higher-impact work continues through the safeguards and specialist review appropriate to the workflow.

This is how Cortex balances performance with responsibility: fast, bounded intelligence for common decisions; deeper expertise for novel, ambiguous, or consequential work. The result is a more predictable experience for developers and security teams, with expert judgment preserved where it matters most.

What this changes for customers

The decision layer is designed to improve the experience without adding another model-selection burden.

For developers, straightforward requests can begin sooner, with less time spent waiting for an initial route. For security teams, common classifications can move quickly while uncertain or consequential cases continue to the deeper specialists. For platform teams, lower per-request latency and memory demand can increase capacity for the work that genuinely requires generative reasoning.

Engineering leaders gain a more predictable path from intent to execution. They can use fast decisions for common traffic while preserving planning, review, and verification for work that changes software or affects production systems.

Security leaders gain a triage layer that can help focus specialist attention. The objective is not to generate fewer findings; it is to spend deeper analysis on the issues where detailed evidence and remediation guidance have the greatest value.

Infrastructure teams gain efficiency at the ensemble level. Lower memory demand and higher measured throughput for control decisions can reduce contention and improve utilization of the larger models already serving complex work.

End users gain the simplest benefit: less waiting before Cortex understands what should happen next. They do not have to know which category handled the request or manually select a fallback. The model ensemble remains behind one coherent Cortex experience.

The broader benefit is architectural. Organizations can reserve heavyweight intelligence for heavyweight work. Routine control decisions become faster and more predictable, while complex engineering and security outcomes remain grounded in specialist reasoning and evidence.

The next layer of the Cortex AI Model Ensemble

The Cortex ensemble began by separating different kinds of intelligence instead of forcing one model to do everything. The three Cortex Routers coordinated models, search, and skills. Cortex Planner added governed execution planning. Cortex Routing Decisions and Cortex Security Decisions now add a dedicated layer for fast, structured judgment.

That creates a clearer progression:

Local intelligence for private, responsive work. Agent and backend intelligence for deep reasoning and execution. Decision intelligence for fast, governed control.

With its tenth and eleventh specialized models, Cortex can resolve more requests at the appropriate level of cost and complexity while keeping the full ensemble available when depth, evidence, or human review matters most.

The goal is not simply to add more models. It is to make every model call more intentional.