More than 30 improvements keep sources, repository context, active AI work, and engineering outcomes connected as software changes.
Software work rarely begins with a blank file.
A developer may start with a security advisory, a customer issue, a pull request, product documentation, or several browser tabs that disagree with one another. Before changing code, the team has to understand what is true, what is current, and which parts of the software may be affected.
That investigation often becomes disconnected from the work that follows.
Sources remain in browser history. Notes lose their links. Repository branches move forward. A useful finding becomes outdated without anyone noticing. When implementation begins, the reasoning behind the change may exist only in a conversation or in one person’s memory.
The latest Cortex improvements focus on keeping those pieces connected.
Research can retain its sources. Findings can stay associated with the relevant software. Important source updates can prompt another look. Approved context can move into an engineering workflow. Users can redirect active work before it goes too far in the wrong direction. Validation and review can remain connected to the outcome.
Together, these capabilities create a living link between research and code.
Give research a durable home
Many investigations involve more than one page.
A security issue may reference an advisory, a package release, a repository discussion, and a proposed fix. A product problem may involve customer feedback, documentation, application behavior, and several related code changes.
Ordinary chat is useful for exploring this information, but a transcript is not always the best place to maintain the evidence behind a decision.
Cortex Evidence Workspaces provide a durable place for approved sources, notes, claims, comparisons, and deliverables. Teams can keep the material behind an investigation together instead of rebuilding the same context each time the work resumes.
Cited Research Briefs preserve the connection between a finding and the sources that support it. Readers can understand where a conclusion came from without searching through the original conversation.
Multi-Source Analysis makes it easier to compare information across selected pages and engineering sources. When two sources disagree, Cortex can surface the conflict instead of quietly combining them into a confident but misleading summary.
This matters because disagreement is often the useful part of an investigation.
Documentation may describe the intended behavior while the current software does something else. An advisory may apply to one release but not another. A proposed fix may address the visible symptom without resolving the underlying issue.
Making those differences visible gives teams a better starting point for action.
Keep research current
A research brief can be accurate when it is written and outdated a day later.
A pull request receives another commit. A dependency publishes a corrected advisory. Documentation changes. A repository moves to a different implementation. The original conclusion may still be valid, but the team should not have to assume that nothing important has changed.
Cortex helps highlight important source updates connected to an investigation.
Updated Decision Briefs help teams revisit their findings as new information arrives. Existing conclusions can be reviewed in the context of the latest evidence without forcing the entire investigation to begin again.
This makes research more practical for work that continues over time. Teams do not have to choose between trusting an old report and rebuilding everything from scratch.
They can focus on what changed and decide whether the original conclusion still holds.
Turn evidence into something teams can use
Research creates value when it supports a decision.
Cortex can turn an Evidence Workspace into a concise brief for developers, security teams, reviewers, or engineering leaders. Reports can be exported into familiar formats when the work needs to become part of a broader review.
Evidence Trust Indicators provide additional context around important findings. A team can see whether supporting information is current, whether sources conflict, and whether a conclusion needs more evidence.
This does not replace human judgment. It helps people see where judgment is needed.
A claim supported by current sources is different from an inference based on incomplete information. A disagreement between two approved sources deserves different treatment from a routine documentation update.
By making those distinctions visible, Cortex helps teams spend review time where it matters.
Carry the finding into the code
The handoff from research to implementation is where context is often lost.
A developer reads a report, opens the repository, searches for the affected code, and translates the findings into a new request. Important constraints can disappear during that transition.
Cortex Research-to-Code Handoff carries approved findings into the engineering environment while preserving their connection to the original evidence.
The handoff can remain associated with the intended repository and requested area of work. This reduces the risk of applying a valid idea to the wrong project or part of the codebase.
Evidence-Linked Outcomes extend that connection after implementation begins. Validation, review, and completion information can remain associated with the investigation that started the work.
A team can move from source material to a proposed change without losing the reasoning in between.
Work from the right version of the software
Software context changes continuously.
A branch advances. A dependency is upgraded. A function moves. A previously relevant file is replaced. Research that refers to an earlier version may still be useful, but it should not be treated as if nothing changed.
Cortex helps teams work from the right code version and find relevant engineering context faster.
Understanding Change Impact helps identify related areas of the software before implementation begins. This gives developers a clearer view of how far a proposed change may reach.
It also helps avoid overly narrow fixes. A change that appears local may affect another service, a shared interface, a validation rule, or a dependency elsewhere in the project.
Understanding those relationships early is more useful than discovering them after a failed check or review.
Bring source and license context into the decision
AI-assisted code still needs the same care as any other software contribution.
Source Context for Proposed Changes helps teams consider relevant origin and attribution information before accepting a change. License-Safe AI Changes allow organizations to apply their normal review policies.
When attribution is relevant, Attribution Context can remain connected to the decision.
These capabilities are not intended to make automatic legal judgments. They help surface information a team may need before code enters a repository.
Developers remain responsible for reviewing the change. Cortex makes the surrounding context easier to find and harder to overlook.
Keep delivery reviewable
Generating code is only one part of completing engineering work.
Controlled Change Gates help teams require appropriate checks before work advances. The expectations can reflect the repository, the type of change, and the organization’s normal development process.
Review-Ready Pull Requests can carry the purpose of the change, relevant evidence, and the checks performed afterward.
Merge Readiness provides a clearer view of whether the expected work has completed. Reviewers can see what passed, what failed, and which decision is still outstanding.
Cortex also helps keep AI work within team controls. The product can present the capabilities available to each user without exposing the internal complexity behind those decisions.
A clear record of decisions remains available throughout the process. Teams can understand what was requested, which evidence informed the work, what changed, and which checks supported the outcome.
Guide work while it is running
Longer tasks rarely proceed exactly as first described.
A developer may discover another requirement after execution begins. A reviewer may ask the team to avoid a particular file. New evidence may narrow the request. An instruction that made sense a minute ago may no longer be relevant.
Restarting the whole task is wasteful. Letting it continue unchanged can be worse.
Live Response Steering lets users guide Cortex while work is running.
Users can add information, update an in-progress request, or cancel queued input that is no longer needed. These controls remain separate from stopping the entire task.
That distinction matters. Correcting direction should not require discarding useful progress.
Cortex also keeps completion status aligned with the actual work. Users receive a clearer indication of whether a task finished, stopped, failed, or still needs attention.
Continue after interruptions without reconstructing everything
Connections drop. Applications restart. Validation fails. A proposed correction may need another attempt.
Cortex improves the ability to resume interrupted work without asking users to recreate the task from memory.
Drafts and relevant context can be restored. Guided Recovery After Failed Checks carries useful findings into the next attempt so Cortex can respond to the problem instead of repeating the same approach.
Validation Against Expected Checks keeps testing connected to the requirements of the software. Cortex can use the checks selected for the work instead of treating every changed file as an isolated artifact.
Safe Code Preparation keeps formatting and preparation separate from proof of success. Preparing a change does not mean that the software passed its tests.
Cortex also confirms consequential actions before reporting completion. If an external action did not succeed, the experience should not imply that it did.
30 improvements across the Cortex experience
The latest Cortex work spans six connected areas.
Research that stays grounded
- Evidence Workspaces
- Cited Research Briefs
- Multi-Source Analysis
- Conflict Detection
- Research That Stays Current
Evidence that moves work forward
- Updated Decision Briefs
- Exportable Decision Briefs
- Evidence Trust Indicators
- Research-to-Code Handoff
- Evidence-Linked Outcomes
Safer software decisions
- Work from the Right Code Version
- Find Relevant Engineering Context Faster
- Understand Change Impact
- Source Context for Proposed Changes
- License-Safe AI Changes
- Attribution Context
Reviewable delivery
- Controlled Change Gates
- Review-Ready Pull Requests
- Merge Readiness
- Keep AI Work Within Team Controls
- Maintain a Clear Record of Decisions
Control while work is running
- Live Response Steering
- Update In-Progress Requests
- Cancel Queued Changes
- Accurate Completion Status
Reliable completion and continuity
- Resume Interrupted Work
- Guided Recovery After Failed Checks
- Validation Against Expected Checks
- Safe Code Preparation
- Confirm Actions Before Reporting Completion
Research and code should not drift apart
The path from a source to a software change is usually longer than it appears.
A team has to gather information, compare claims, understand the code, decide what should change, perform the work, run the right checks, and review the outcome.
Each handoff creates an opportunity to lose context.
Cortex reduces that loss by keeping research, repository context, active work, and engineering outcomes connected.
A team can begin with a question, preserve the evidence behind its findings, notice when important information changes, carry the relevant context into the code, guide the work as it proceeds, and return with an outcome that remains understandable afterward.
That is the value of a living link between research and code: less reconstruction, fewer unsupported assumptions, and a clearer path from what a team learns to what it decides to change.
