Why your agent keeps "fixing" code back to the old way — and what actually stops it

Why your agent keeps "fixing" code back to the old way: and what actually stops it

By Mike Schreiber

Imagine this hypothetical change: you replace an old billing serializer, but deliberately preserve its export column order because an accounting importer depends on it. Later, an agent proposes a cleanup that sorts those columns alphabetically. The patch looks tidy. It also reverses a decision you meant to keep.

Before blaming memory, ask what the agent could actually establish: Was the choice recorded? Was its reason explicit? Did the record apply to this file? Was it an approved decision or merely a suggestion?

The practical response is to make decisions explicit, separate them from observations, and review potentially conflicting edits before accepting them. More context alone is not the whole workflow.

Start by diagnosing the missing information

Use these three questions to inspect a reversal:

• Was the decision missing? “Keep the existing order” appeared in a conversation, but not in the instructions supplied for this task.
• Was the reason missing? The record described a preference without explaining the compatibility requirement.
• Was the authority unclear? An old convention, an observed implementation, and a new proposal all looked equally authoritative.

Do not assume instruction files are inherently temporary. Claude Code documents CLAUDE.md as persistent instructions read at every session start. Cursor describes rules as persistent, reusable context. Codex builds an instruction chain at startup. These are useful mechanisms, not evidence that another tool forgets everything. (Claude Code memory, Cursor rules, Codex instructions)

The question to test is narrower: did the relevant, current decision reach this task, and did the proposed patch respect it?

Step 1: Write a decision, not just a command

For each intentional exception, write down the choice, rationale, scope, approval, and condition for revisiting it. This is a suggested recording template, not a claim about required product fields.

For the hypothetical billing project:

Decision: Preserve the existing CSV column order.

Reason: The accounting importer maps values by position.

Scope: src/billing/export.ts and its compatibility tests.

Approval: The project owner approved this constraint.

Revisit when: The replacement importer has been validated and the owner approves migration.

Compare that with “Do not modernize exports.” The scoped version permits unrelated cleanup and tells a reviewer what evidence would justify a change.

Ask the agent to restate the constraint before editing: “Explain which part of your proposed patch could affect export compatibility.” Treat that answer as a check on understanding, not proof that the eventual patch is correct.

Step 2: Separate decisions, observed work, and proposed notes

Keep these categories visibly distinct:

| Category | Hypothetical example | What it establishes | |---|---|---| | Human decision | “Keep column order until migration is approved.” | An agreed constraint | | Observed work | “The commit changed the serializer; the compatibility test passed.” | What happened, not why it was authorized | | Proposed note | “Consider switching to named-field imports.” | An idea awaiting review |

A passing test does not establish business approval. Existing code does not prove someone deliberately selected its behavior. An agent's summary should not turn either into a human decision.

In Hark, decisions are never approved automatically at any trust level. Under Standard, agent proposals are reviewed, while repository facts backed by a commit, pull request, or release are accepted as observed. Other trust levels permit additional automatic acceptance, but conflicts with accepted decisions always go to review. Automatically accepted items are labeled “Auto-approved,” not presented as a person's approval. (Hark working with agents)

For this workflow, review proposed decision wording before treating it as authoritative. Ask whether it captures your actual choice or merely the agent's interpretation.

Step 3: Put stable guidance and current decisions in appropriate places

Keep durable conventions concise. Claude Code recommends session-wide facts in CLAUDE.md, multi-step procedures in skills, and narrowly scoped instructions in path-scoped rules. Its conditional rules use a paths field to match relevant files. (Claude Code memory)

A hypothetical stable convention might be “Run compatibility tests when changing export behavior.” A current decision might be “Preserve this export layout until the importer migration is approved.” Do not leave contradictory versions scattered across your instructions.

Hark's documented model separates stable repository context from living state and composes them into an agent brief. Its working guidance calls for reading the brief before work and recording decisions and completed work during the session. (Hark working with agents)

Use a concrete opening prompt:

Read the project brief before editing. Identify the accepted decisions relevant to this task. Keep observations and proposed changes separate. If the requested implementation conflicts with a decision, ask before proceeding.

Step 4: Add an edit-time checkpoint where supported

Hark's early-access Claude Code mod fetches the compact brief at session start and restores agreed decisions, non-goals, blockers, and the next action after compaction. Before an edit to a file covered by an agreed decision or non-goal, its decision guard shows the decision and rationale and offers Allow or Stop. The check runs locally; nothing about the edit is sent. (Hark mod guide)

To install the documented repository version, run these commands inside Claude Code:

/plugin marketplace add Hark-Studio/hark-mod

/plugin install hark-memory@hark

The mod requires Claude Code 2.1.287 or newer. Create a pairing code through Connections → Access keys → Claude Code preset, have the agent exchange it, and store the returned key in the plugin's sensitive configuration, never in chat. (Hark Claude Code setup)

Open configuration and link the repository using your actual project code instead of the example:

/plugin configure hark-memory@hark

mkdir -p .hark && echo V-012 > .hark/project

Start a session in the project and run /hark brief. Without a project file or key, the mod stays idle and sends nothing. (Hark mod guide)

For the hypothetical export change, use Stop if the proposed edit would violate the approved compatibility constraint. Then request an alternative that preserves column order. Do not interpret the checkpoint as an automatic judgment of correctness: you still decide whether the edit is appropriate.

This mod is Claude Code only. Cursor and Codex use their documented connections and Hark's hooks alongside it; do not assume those connections provide the mod's edit-time guard. (Hark mod guide)

Step 5: Replace decisions explicitly when requirements change

Suppose the hypothetical importer migration is now validated. Do not simply add “Use the new column order” beside the old instruction. Ask the owner to approve the replacement, identify the earlier decision, and update any conflicting repository guidance.

Hark's agent guidance says accepting a candidate can return suggested earlier decisions to replace. Calling supersede_decision requires explicit IDs and the user's approval in the current chat. Suggested replacement is not permission to retire an agreed constraint. (Hark working with agents)

Then review the patch and relevant tests against the newly approved requirement.

Step 6: Verify the next session, not just this one

Start a fresh session and ask for the relevant constraint before requesting code. Hark's setup guide uses this exact kind of verification: call get_agent_brief for the project and ask the incoming session to identify the recorded constraint. This checks the shared project record, not a transfer of chat history. (Hark setup from your repo)

At shutdown, the Claude Code mod sends a short summary of files touched, commits, test results, and closing notes, then drafts a handoff for review. Sessions without changes write no handoff. Review that draft for unsupported claims of approval. (Hark mod guide)

Troubleshooting and boundaries

The brief is missing. Check the configured key, project file, and required Claude Code version. The guard asks too often. Narrow decision scope to the relevant area or path. These are the mod's documented troubleshooting checks. (Hark mod guide)

The agent still proposes the old pattern. Compare the accepted decision with all instructions supplied for the task. Remove stale wording, clarify the rationale, and inspect the patch rather than accepting a verbal assurance.

You need guaranteed enforcement. Do not treat this workflow as a security boundary. The mod documents that requests time out and network requests do not block prompts, edits, or exits. Keep code review and tests in place. (Hark mod guide)

The work contains secrets. The mod does not send file contents, diffs, prompts, or transcripts. However, closing-note cleanup is best effort: a secret written in plain prose could be sent. Keep sensitive material out of closing notes. (Hark mod guide)

FAQs

Should instruction files be removed?

No. Keep them focused and current. Persistent instructions remain a documented mechanism for project guidance. (Claude Code memory)

Can an agent approve its own Hark decision?

No. Decisions are never approved automatically, regardless of trust level. (Hark working with agents)

Does recording the reason guarantee a correct patch?

No. Use the reason to guide review, then inspect behavior and tests. A recorded decision is a constraint to check, not proof of compliance.

Sources

• Claude Code: Memory
• Cursor: Rules
• Codex: AGENTS.md instructions
• Hark: Working with agents
• Hark: Claude Code connection
• Hark: Claude Code mod
• Hark: Set up from your repo