why I keep my own data out of my agents

I built NORD to run my company. It works. It has been running my operation for months. A year into building it, I went to answer a simple question, could someone else run this, and the answer was no. Not because the logic was too complex. Because the whole thing was welded to me.

I can show you exactly how welded. I can search my own name across the system and get hundreds of hits. My name, my company, my email, sitting inside agent definitions, inside skills, inside the rules the agents follow. My business context was baked into the routing. My preferences were baked into the prompts. If I handed the repository to another person, it would still introduce itself as me.

That is the problem I want to talk about, because it is not specific to agent systems. It shows up any time operator data leaks into system logic. It just happens to be brutal in an agent system, where the operator data ends up everywhere by default.

When operator data lives inside the agent files, three things break.

The first is portability. The system cannot be run by anyone but you. You cannot hand it to a teammate, you cannot ship it to a customer, you cannot even keep a clean public version of it, because your private details are threaded through the parts you would want to share.

The second is secrets. If credentials live in the same files as the agent logic, every agent can see them, they land in your version history the first time you are not careful, and they surface in transcripts when an agent references the file. Rotating one becomes a hunt across the whole system.

The third is modularity. When your name and your context are hardcoded in twenty places, changing a fact means editing twenty files. Miss one and the system contradicts itself. The data drifts out of sync with itself, and you spend your time chasing the drift.

The obvious fixes do not work.

Find and replace does not work. Swapping my name for a placeholder across the system just spreads the coupling to every file that had the placeholder. The data is still living in the wrong place. I have only made it harder to see.

Keeping secrets in a separate file does not work on its own either. If the agent definition still points at that file, or still assumes it can read it whenever it wants, the boundary is already broken. A wall you can walk through at any time is not a wall.

What actually works is moving all of it out. In the rebuilt version of NORD, everything specific to me lives in one place, off to the side, kept out of version control. My identity, my voice, my preferences, my business context, and my secrets. The agents themselves hold generic logic with placeholders where an operator's details would go. At runtime the system fills the placeholders with my values and hands the finished thing to the agent. The agents never reach into my data directly. They receive what they are given.

Secrets get a harder boundary than the rest. They are not part of the general context every agent can see. They are held apart and released only when a specific task genuinely needs one, through a path built for exactly that. An agent does not carry my keys around just in case. It asks for the one it needs, when it needs it, and that request is something I can see.

I keep the boundary honest with a test. The system is not allowed to contain my identifying details inside the agent, skill, or rule files. If my name or my details show up somewhere they should not, the check fails. The separation is not a habit I am trusting myself to maintain. It is enforced.

Here is why I went to the trouble. A system tangled with your personal data is not a product. It is a personal rig. You can run it, and no one else can. The moment the operator data is separated out, the same system becomes something another person can pick up, drop in their own details, and run as themselves. Nothing about the logic changes. They are not running a customized copy of my setup. They are running the same system, as them.

The separation pays off long before anyone else touches it, though. Because adding a fact is now a single edit in a single place, the system picks it up everywhere without me touching a line of logic. Add a new detail about how I want something done, and every agent that renders my context sees it on the next run. No hunt, no drift, no twenty files.

The principle underneath all of this is older than agents. Keep your system logic separate from the data that identifies one operator. Anyone who has built multi-tenant software has lived it. It is easy to forget when the operator is just you and the system is something you built for yourself, because in that case the coupling costs you nothing on day one. It costs you the day you want the thing to be more than yours. If you are building something you want to outlive your own use of it, separate the two from the start. Pulling yourself out of a system later is a lot more work than keeping yourself out of it in the first place.