Your requirements say a customer portal belongs in the first release. Your project memory says it was deferred. The code contains a half-built portal. You ask AI to finish the project.
What should it do next?
Reading all three sources does not resolve the disagreement. The missing piece is a rule for deciding what each source can establish, and what needs a decision from you.
Give your project context a clear authority model. Make material conflicts visible before they turn into changes.
Ask what kind of truth you need
A specification and a running application answer different questions.
The approved specification describes what the system should do. Current code, observed behavior, and validation results establish what it does today. Neither makes the other irrelevant.
If a feature violates an approved requirement, its presence in the code does not make it correct. If a requirement says a feature exists, that statement does not prove someone implemented it.
Use the sources according to the question:
| Question | Start with | Check before acting |
|---|---|---|
| What work is authorized now? | The owner’s current explicit instruction and applicable project constraints | Whether the request changes an earlier decision |
| What should the result satisfy? | Approved requirements and architecture | Scope, acceptance criteria, and superseding decisions |
| What actually works? | Current implementation and observed behavior | Relevant checks, environment, and known limitations |
| Why was an approach selected? | Approved decision records | Date, rationale, and whether the decision still applies |
| Where should work resume? | The current handoff | Evidence that its status is still accurate |
| What might happen later? | Roadmaps and backlogs | Whether the item has been approved for this task |
This is a working method for reconciling project evidence. It does not override a tool’s security controls or higher-priority instructions.
Resolve one concrete disagreement
Consider an illustrative inquiry-tracker project:
- An early requirements draft includes a customer portal.
- A later approved decision defers the portal until after the first release.
- Project memory records that narrower scope.
- The repository still contains an unfinished portal screen.
A useful response would identify the superseded draft, confirm the current scope, and leave the unfinished screen out of the release work. The screen’s existence is implementation evidence; it is not authorization to finish or publish it.
Now change one detail: nobody can find an approved decision deferring the portal.
The agent should report that gap and ask for a scope decision before making the consequential change. It can continue unrelated work already authorized, such as checking the inquiry form. Uncertainty in one area does not require stopping the entire project.
These examples describe a hypothetical project, not a measured client result.
Give each context file a job
In the KOS project workflow, the distinction is practical:
- Requirements and architecture describe approved intent and constraints.
- Decision records preserve specific choices and their reasons.
- Project memory summarizes durable, approved context.
- The handoff captures current progress, validation, blockers, and the next action.
- The changelog records completed material changes.
A summary should point to its authoritative source where the distinction matters. Repeating an old assumption across five files does not make it an approved decision.
The AGENTS.md format provides a place for project guidance such as conventions and validation commands. Use your tool’s supported instruction mechanism to tell it how to find the relevant sources; a file name alone is not a universal loading guarantee.
Add a conflict-handling instruction
The following is an example to adapt to your project:
## Resolving project context
- Confirm the current authorized task and applicable constraints.
- Use approved requirements and decisions to establish intended behavior.
- Inspect current implementation and relevant checks to establish reality.
- Use memory and handoff as summaries; verify material claims against sources.
- Treat backlog items and historical notes as context, not new authorization.
- When sources materially conflict, identify the sources and explain the gap.
- Ask for a decision only when the unresolved conflict changes scope,
permissions, or a consequential action. Continue independent approved work.
- Never rewrite approved intent merely to match an implementation defect.Test the instruction with a harmless example containing an outdated draft and a clearly approved replacement. Check whether the agent identifies the conflict and uses the right evidence. Do not assume the instruction works just because it is written down.
Close the gap after the decision
Once the owner resolves a conflict, update the appropriate source and its dependent summaries. Record an approved scope change in the requirements or decision record, refresh durable memory if needed, and put the implementation status in the handoff.
Avoid maintaining two documents that both claim to be the current authority for the same decision.
If conflicting instructions across tools are part of the problem, continue with One Router, Many Agents. If your next session struggles to resume, use the practical handoff workflow.
Start with one active project using the KOS Starter Kit. Identify its approved intent, verified implementation, and current next action. Where they disagree, write down the decision that is still needed.
Your next AI session should be able to show why a source applies before it acts on it.