One set of rules for every coding agent

One instructions file per vendor

Each agent looks for project instructions in a file of its own, with its own name and its own conventions. That isn't a design flaw. Every agent needs a way to load instructions at the start of a session, and a file in the repository is the simplest one.

The rules in those files, though, are facts about your product: how errors are handled, which library formats dates, what must never appear in a log, how a database migration is written, which words the product uses. None of that changes when you switch agents. The format belongs to the vendor. The content belongs to you.

The first copy is fine. The second is a copy and paste. By the third, the files have drifted. Someone tightens a rule in one file after an agent got it wrong, and the other agents keep following the old version. Nobody notices until two agents make the same mistake in different ways.

You will mix agents anyway

There are good reasons to use more than one coding agent. Agents differ in what they handle well: one may hold up better in a long debugging session, another may produce cleaner interface work, a third may be the one included in a plan you already pay for. Picking the agent per task is a reasonable thing to do.

Projects also change agents over time, as models improve and prices move. If your rules live in one agent's file, every switch is a migration and every mix is a fork. The rules end up shaped by the tool rather than by the product, and trying a different agent carries a cost it shouldn't.

Mixing happens inside a single feature too. A plan written by one agent, built by a second and reviewed by a third is a sensible arrangement, but only if all three read the same rules. Otherwise the reviewer flags what the builder was told to do, and the builder follows a rule the planner never knew.

Instructions files grow until they stop working

Even with a single agent, the one-file approach wears out. Rules accumulate after mistakes, one paragraph at a time, and almost never leave. The file grows long, and every session loads all of it, whatever the task.

So the rule about database migrations is read by an agent fixing a button label, and the rule that matters for this task sits somewhere in the middle of the file, competing with everything else for attention. Long instructions dilute themselves. Contradictions creep in, and when two lines disagree the agent picks one without telling you which.

A rule that applies everywhere is loaded everywhere, and that is right for very few rules. Most rules apply to one part of the product: an area of the code, a kind of change, a step of the work.

Rules as records, handed out per task

What works is to treat each rule as a record of its own rather than a paragraph in a file. A rule says what it requires, why, and where it applies: which part of the product, which kind of change. Written once, in one place, it can be read by any agent and changed in one edit.

A rule written this way is also easier to judge. “Handle errors properly” can't be checked by anyone. “Every failure a person sees carries an error code with one message, and the cause goes to the log” can be checked by a reviewer, by a second agent and often by a script. The more precise the rule, the less it depends on the agent reading it in the right frame of mind.

Then hand rules out per task. Before a task starts, assemble the rules that apply to what it touches and give it those. The migration rule goes to the migration task, the interface rules go to the interface work, and the button fix gets the handful of rules that apply everywhere.

Keep that always-on set small: how to ask a question, what never to do, where to write results. And where a machine can check a rule, write the check as well as the sentence. A rule that is verified holds. A rule that is only stated holds while the agent remembers it.

The agent's own instructions file then shrinks to a pointer: connect here, and read your rules there. It stops being the place where your product's rules are kept.

Same rules, any agent

Once the rules live outside the agents, mixing agents gets cheap. One agent debugs, another designs, a third reviews, and all three work from the same rules. Moving to a new agent means connecting it, not porting a file.

Review gets simpler too. An agent reviewing another agent's change checks it against the same rules the author read, so a disagreement is about the change, not about two versions of the rules. And when a rule turns out to be wrong, you fix it once and every agent has the fix at its next task.

It also turns the choice of agent into a question you can answer with evidence. When every agent works from the same rules, differences in the result come from the agent, not from what it was told, so comparing two agents on the same kind of task tells you something real.

Where ctxflows fits

In ctxflows your rules live in the library, written once and versioned like everything else there. Before each node of a workflow runs, a context step hands the task the rules that apply to it, along with the records and docs it needs, so no agent reads the whole set to fix a label.

Any coding agent connects over MCP and reads the same rules. The free engine runs Claude Code, Codex, Cursor, Gemini CLI or Grok unattended on your machine, and you can mix them per task: one for debugging, another for design, the same rules for both. One set of rules for every agent instead of one per vendor. Each agent can do only what you allow, and every change is recorded: who made it, when and why.