Temporary project instructions need an exit condition. Otherwise, an exception written for a migration can keep steering agents long after the migration ends.
Imagine a repository moving from a legacy invoice parser to a replacement. During the transition, agents should keep both implementations and test their outputs against the same fixtures. Six months later, the old parser is gone, but a project instruction still says to preserve it. The instruction is readable, versioned, and wrong.
APC is the portable context layer: project guidance lives in AGENTS.md and .apc/. APX is the daily-use runtime and tooling layer that works with that context. Portability makes an instruction available across tools; it does not make yesterday's exception correct today.
Make the condition visible
Consider this hypothetical addition to a repository's AGENTS.md:
Keep the legacy invoice parser. Run both parsers when changing invoice handling.
That leaves the next contributor guessing. Is the old parser a permanent compatibility requirement? A rollback mechanism? An unfinished experiment?
A more useful instruction records the temporary boundary:
While the invoice parser migration remains open:
- Keep the legacy parser available for rollback.
- Compare both parsers using the committed compatibility fixtures.
Retire this instruction when the migration owner accepts the replacement
and removes the legacy rollback path. Update this section in that same PR.
The second version does not automate the decision. It tells a reviewer what decision must happen before the instruction can disappear. The fixture names, owner, and acceptance record would need real project-specific references in an actual repository.
A calendar deadline alone is weaker. Reaching Friday does not prove the replacement works. A date can prompt a review; an observable project condition explains whether the exception still applies.
Keep the permanent rule separate
The lasting requirement might be “preserve invoice compatibility.” Running two parsers is only one temporary way to establish that compatibility.
Write those ideas separately. When the migration ends, remove the dual-parser procedure while keeping the compatibility requirement and its relevant tests. Otherwise, deleting the temporary instruction can accidentally delete the reason the team needed it.
This fits APC's definition of project context: information that remains meaningful across editors, machines, and runtimes. A temporary instruction can still be shared project guidance, provided its scope and retirement condition are explicit. Durability should mean maintained knowledge, rather than text that nobody touches again.
Review retirement alongside implementation
For a migration PR, I would add a short review question: which existing instructions become false if this change lands?
Check the root contract, relevant agent definitions, and reusable instructions that mention the old behavior. Follow references instead of searching only the file edited during implementation. If the migration is partial, narrow the instruction to the remaining legacy path and retain its exit condition.
The APX repository's engineering guide includes a related practice: comments describing migrations should change when those migrations finish or are abandoned. Applying that same maintenance habit to project guidance is a proposed review workflow, not a claim that APC or APX automatically detects stale instructions.
A useful completion note can stay small:
Legacy parser removed after acceptance.
Temporary dual-parser instruction retired.
Compatibility requirement and replacement tests retained.
That note explains why guidance changed without copying the migration's entire conversation into the repository.
Version control preserves old decisions when you need to investigate them. Active context should explain what applies now. Giving temporary instructions an exit condition helps the next agent tell the difference.
Explore the portable context format in Agent Project Context on GitHub.
Top comments (1)
A retirement condition should also have an explicit reviewer and a checkable signal. That turns cleanup into part of the migration’s definition of done: the same PR can remove the temporary rule only when the owner confirms the new invariant and the referenced compatibility tests still cover it.