One Router, Many Agents: Keep Your AI Instructions from Drifting

You fix a project rule in one AI tool, switch to another, and get the old behavior again.

The first tool knows which test command to run. The second still uses a retired command. A third proposes a feature you already removed from scope. Each session sounds confident because each session has a different version of the instructions.

The maintenance problem is straightforward: the same rule has too many places to live.

Give shared project instructions one authoritative home. Use each tool’s entry point to direct it there, then verify that it actually reads the right context. That is the router-and-adapter pattern.

Separate shared rules from tool setup

A router answers three questions: what is this task, which context applies, and what should the agent read next?

An adapter connects a particular tool to that router. It should contain only the instructions needed to make that connection, plus genuinely tool-specific requirements.

The AGENTS.md project documents an open Markdown convention for project instructions, including build commands and working conventions. It is a useful candidate for the shared entry point. File discovery and precedence still depend on the tool and its configuration; a filename alone does not prove that the current session loaded it.

Here is an illustrative structure for a small software project:

AGENTS.md              Shared starting instructions
project-context.md     Approved scope and constraints
handoff.md             Current state and next action
procedures/
  testing.md           Validation procedure
  release.md           Release procedure

These are example filenames, not a required KOS folder structure. Keep your existing project organization when it already works.

Keep the router short enough to use

A practical router might say:

# Project working instructions

1. Identify the requested outcome and affected part of the project.
2. Read project-context.md and handoff.md for project work.
3. Inspect the relevant implementation before changing it.
4. Read procedures/testing.md when validating changes.
5. Read procedures/release.md before preparing a release.
6. Preserve unrelated changes and report unresolved conflicts.
7. Update the handoff with verified progress and the next action.

The purpose is to make the next read useful. Avoid loading every design document, meeting note, and old release record at startup. A copy correction and a database migration need different evidence.

Keep essential constraints in the entry point. Put detailed procedures behind clear references. If an agent repeatedly misses a critical rule, improve the routing or make that rule explicit at the point of use.

Make adapters point, not duplicate

For a tool that uses a separate instruction file, an illustrative adapter could contain:

Read the root AGENTS.md before starting project work.
Use it as the shared project instruction entry point.
If a referenced file is unavailable, report that gap before proceeding.

Check the tool’s documented import or instruction mechanism before choosing this approach. Some setups can load the shared file directly; others require an explicit reference or configuration. Test the result in a fresh session.

This pattern keeps a changed test command or scope constraint in one place. It does not make different models behave identically, and it does not override platform rules, tool permissions, or more specific instructions that the tool applies.

Try it on one real task

Consider a fictional inquiry-tracker project. Its approved first version supports manual assignment. Automatic assignment is deferred.

If that decision appears separately in three tool profiles, one outdated copy can send the next session toward unnecessary implementation work. Put the approved scope in the shared project context and make the router lead there.

Then start a fresh session in each tool you actually use:

Read this project’s instruction entry point and the context it requires. List the files you read, summarize the approved assignment behavior, and identify the next unfinished task. Do not edit files yet.

Compare the responses with the files. A plausible summary is insufficient if it cites a missing document, invents approval, or overlooks a conflicting instruction.

Follow with a small, reversible task. Confirm the agent uses the current validation command and leaves a useful handoff. That gives you evidence about the whole workflow, beyond whether it can repeat the rules.

Watch for three kinds of drift

• Duplicated rules: The same requirement appears in multiple adapters. Keep one maintained version and replace copies with references.
• Stale project state: The router works, but the handoff is old. Update execution state after meaningful work.
• Unresolved authority: Two documents disagree. Surface the conflict and resolve ownership; do not let an agent silently select whichever is convenient.

A router also provides no access control. A sentence saying “do not read credentials” is useful guidance, but actual restrictions belong in permissions and tool configuration.

Start with one project and two tools

Move only the rules that are truly shared. Keep working tool configuration intact. Run the same context check in both tools, fix the gaps, and expand only when the setup earns its maintenance cost.

The result you want is modest and valuable: when a project rule changes, there is one clear place to update it and a repeatable way to check that your tools use it.

For the broader workflow, read the practical KOS handoff guide. To start organizing reusable project context, explore the KOS Starter Kit.