# Your agent's definition is not the source of truth Дата: 2026-07-04 Теги: agents, fde Источник: https://ponomar.art/notes/agent-role-drift/ > Three drifts between an agent's config and its code, a one-line fix that revived eight roles, and a $0.018 run that proved the layer alive — why agent definitions rot like documentation. --- I run a small orchestrator of eight "executive" agents, one per company function. Only one of them is genuinely developed — the CTO. When I opened its definition for the first time in weeks, I found three discrepancies between what the file claimed and what the agent actually does. Fixing the worst one took a single line. Proving the whole role layer was alive took one autonomous run that cost $0.018. Here is the uncomfortable frame behind those numbers: an agent's definition — its system prompt and its config — is documentation. And documentation rots at exactly the speed of the code underneath it. The three drifts, in order of loudness. The config named one model; the code called another. The definition claimed the agent "executes tasks through engineers" when in reality it runs a confined code loop: it reads and writes files itself, runs commands, makes a local commit. And the third, quietest one: the path to the personality file pointed at a directory that didn't exist. One extra segment in a path meant the identity layer silently failed to load — a stub was substituted instead. Not just for the CTO. For all eight agents at once. The fix was one line: remove the extra segment. One line brought the whole team's identities back. The rest was mechanical reconciliation — align the config with what the code actually does, and write down what had never been written at all: when this agent is invoked and what contract sits underneath it. A green gate before a pull request, review, a security check. Not "who I am" — an operating map: when, and with what. The role layer wasn't the only place drift had piled up. The same week I merged the skill layer of the same system: 48 skills that had split across two stores — a knowledge vault and an automation directory — with 20 of them diverged and 21 carrying broken frontmatter, collapsed into a single git source of truth. Two copies of anything is not redundancy. It's a guarantee that at least one copy is lying, and no error message will tell you which. But grounding the definition in code is only half the job. You can proofread a definition down to the last character and still not know whether the agent works. A role is verified by running it, not by reading it.
start DEFINITION CODE drift GROUNDING
The definition freezes, the code keeps moving — that's drift. Grounding converges them at the code; whether it works is shown by a run.
So I gave the agent a short spec in a disposable repository: create a file, commit it, there are no tests here — don't touch anything else. It opened a separate branch, wrote the file in four steps, made a local commit, and stopped. It didn't push and it didn't touch the main branch — because those boundaries are welded into the tools it operates with, not into prompt text where they can be ignored. The entire run cost $0.018. That commit — not the tidied-up config — is the proof that the role layer is alive. Why this matters for forward-deployed AI work. When you deploy agents inside someone else's live operation — a client team that doesn't share your context and won't read your prompts — definition drift isn't a hygiene issue, it's the trust budget. The client's engineers will diff what your agent's docs claim against what its commits show, and every mismatch you didn't catch first costs you standing you can't buy back. The forward-deployed loop is exactly the one above: ground the definition in what the system actually does, put the boundaries into tooling rather than wording, then prove the role with a cheap, metered, isolated live run. Knowing the run cost $0.018 is itself part of the proof — it means every run is metered, so autonomy has a price tag instead of a vibe. Client teams don't trust prompts. They trust commits, gates, and numbers. That's why I stopped treating prompts and configs as sources of truth. The source of truth is the code and a live run. Ground the definition in code, verify by running. Anything that doesn't execute is just nice text.