# The bug is fixed. The next change brings it back.

The change is small. Remove a check, simplify the path, make the code faster. Then a retry creates the same order twice, and someone remembers why the check existed.

Your engineers should be able to improve the service and help colleagues understand it. Instead, the person who remembers the incident has to explain why the proposed change would bring it back.

## The guard looks unnecessary to someone who never saw the failure.

You lead a software team maintaining an order-processing service. An earlier incident showed that a retried request could create a duplicate order. The team added a check and a regression test.

The incident explanation lives in a review discussion and a closed ticket. Months later, a developer asks a different coding agent to improve the path.

The agent sees an extra check but does not have the history. It proposes removing it. A senior engineer catches the risk in review and has to reconstruct the incident to explain the objection.

Where the explanation gets lost:

1. Team fixes duplicate orders
2. Reason stays in a closed discussion
3. Agent proposes removing the guard
4. Reviewer rebuilds the history

## We’d give the agent the reason before it proposes the change.

We’d begin with one incident and the guard it produced. What failed, why was this fix chosen and which test proves the behavior the team wants to preserve?

The first useful improvement is to make that explanation retrievable at the start of the task. More code context alone does not tell the agent why a particular line matters.

## Save the failure, the decision and the test that belongs with it.

A connected agent could store this lesson in Korium with references to the incident and reviewed change:

> Retried requests previously created duplicate orders. Preserve the duplicate-prevention behavior when changing this path. Review the incident, the accepted fix and the regression test before proposing a replacement; a faster path still needs to handle retries correctly.

**Source:** The incident review, the accepted change and the regression test reference.

## The agent can improve the code without treating the old failure as a surprise.

At the start of the task, the connected agent searches Korium memory for earlier decisions. It can also use the code index to locate the relevant implementation in the indexed commit, then verify it against the current checkout.

With the reason and the code in view, it can propose a plan that preserves the behavior, instead of discovering the requirement during review.

A plan based on the saved explanation:

1. Read the incident and confirm which retry behavior must remain.
2. Find the current implementation and the existing regression test.
3. Make the change, test duplicate prevention and flag anything still unproven.

Skills and workflows can guide the implementation and checks. The agent must still inspect current code and run the relevant tests; a memory is not proof that the code is correct, and a person retains the release decision.

## Which parts of Korium help here?

Memory explains why the guard exists. Code lookup finds the implementation, skills guide the change and tests, and a workflow takes the work through review and saves what the team learned.

### Memory: Explain why a retry must not create a second order.

Korium:mem keeps the incident, the accepted fix and the reason duplicate prevention must survive the change. It gives the coding agent the history that reading a function alone may not reveal.

### Code: Find the code that implements the guard.

Korium:code points the agent to relevant symbols, files and line ranges in the indexed commit. The agent then checks those locations against the current checkout and reads the implementation before changing it.

### Skills: Give the agent a repeatable way to change and test the behavior.

We’d load the relevant coding and testing skills, adapted to the team’s standards. Those instructions guide how the agent preserves retry behavior, checks the regression test and reports anything it has not proved.

### Workflows: Connect the investigation, change, review and learning.

The workflow would order the work: read the incident memory, locate the code, use the skills, make and test the change, then bring it to human review. After acceptance, it includes saving the result and why this implementation replaced the earlier one.

What we’d set up with you: We’d connect the coding agent to memory, index the repository and adapt the skills and workflow to your tests and review process. Code lookup helps the agent find the implementation; it does not replace memory, current-source checks or test results.

## Experienced engineers can help with the next challenge.

When the team accepts a new implementation, save why it replaced the old one and which tests were run. Keep the original incident linked to that history.

The next agent can distinguish the requirement that still matters from an implementation the team has replaced. It starts from the latest reviewed understanding, not from whichever chat someone remembered to paste.

When the change plan already accounts for the incident, review can focus on whether the new approach is any good. A newer developer can learn from the reason and the test; an experienced engineer can help them make a better change instead of retelling the failure.

How we would check whether it helped:

- Review whether change plans account for known failure modes.
- Check whether reviews spend less time reconstructing incidents and more time evaluating the proposed change.
- Check that saved implementation decisions point to tests and identify what remains unverified.

## Bring the bug your team never wants to fix twice.

We’d trace it from the incident to the code and the next proposed change. Then we’d connect memory, code lookup and the checks your team already relies on.