It doesn't restart from zero every session.
Two different jobs, kept as separate systems on purpose: standing project instructions describe how the agent should behave, loaded automatically every single turn with no request needed. Everything else on this page is what the agent has actually learned from working in a given repository — corrections it's been given, and failures it's already run into — carried forward into every future session against that same project, not just remembered for the rest of today's conversation.
Standing project instructions
A project can carry its own rules file — checked in this order, first match wins: KRYEX.md, AGENTS.md, or .kryexrules, so a repository already using a different agentic tool's convention is picked up with zero setup. Capped at 8,000 characters, with a clear truncation note if a file runs longer than that.
Global
One file, machine-wide — how you always want things done, in every repository. Edited from Settings.
Root
The active repository's own file, loaded into every turn's system prompt for that project.
Nested
A subdirectory can carry its own instructions, applied only when a change actually touches that subtree — the closest file to the change wins, same “more specific wins” rule Skills use.
Global and root instructions are both applied at once, unconditionally — one is machine-wide habits, the other is this project's own conventions, and neither overrides the other. Editing the file — by hand or by asking the agent to update it — is not a special write path: it goes through the identical approval gate as any other file change, so a rule can't be silently rewritten without the same sign-off a normal edit requires.
Remembered corrections
A correction given once should hold for every session after it, not just the rest of today's conversation
An agent told 'don't do X' mid-session behaves correctly for the rest of that conversation — and then forgets entirely the next time anyone opens a new session against the same project, repeating the exact same mistake a second, third, or tenth time.
Every real denial paired with feedback on a gated action is recorded as a durable, per-project rule, and re-applied to every future turn against that same project, in every session — not just the one it happened in. Short, non-generalizable feedback ('no', 'cancel') is filtered out rather than stored, and the same correction given twice reinforces one entry instead of piling up duplicates.
A developer denies a write with the feedback 'never touch the migrations folder directly — always go through the migration tool.' Weeks later, in a brand-new session, the agent reaches for the same folder directly and is redirected before it happens, without anyone having to repeat the correction.
A team's accumulated corrections become durable, project-scoped behavior — genuinely learned, not re-taught every time someone opens a new conversation.
Capped at 30 rules per project, with the least-reinforced rule evicted first if the cap is reached — a correction given once and never repeated ages out before one the team keeps needing to reinforce.
It doesn't retry a strategy already proven not to work
A genuinely new session shouldn't blindly repeat a failure a previous session already exhausted
Long agentic sessions can get stuck repeating the same failing approach. Even when a session eventually recovers or the developer starts over, a brand-new conversation against the same project has no memory of what was already tried and confirmed not to work — and can walk straight back into it.
When the same failure genuinely recurs enough times to be a confirmed dead end — not a one-off — it's recorded per project, and every future session against that project, new conversation or not, carries the same warning in its own context from the start.
One session spends real time discovering that a particular build flag conflicts with the project's config and consistently fails. A completely separate, later session — no shared history, no shared memory of that conversation — starts already aware of the dead end, and doesn't have to rediscover it the hard way.
A confirmed failure is learned once, for the project, not re-learned by every future session that happens to wander into the same corner.
Capped at 20 recorded failures per project, oldest and least-relevant evicted first.
Checkpoints before anything risky
Before a genuinely risky action — a destructive edit, delegating a subtask — the agent saves a snapshot of what it was about to do and why. If it later gets stuck, recovery doesn't mean continuing to feed the model an already-polluted, stuck trajectory: it reinjects the original goal into a clean context alongside that checkpoint's own reason, so the agent restarts from a clear, correct understanding of what it was actually trying to do — not from whatever confusion accumulated while it was stuck.
Stated honestly: these are real, structural mechanisms for two specific, documented recurring-failure classes — not a claim that the agent can never repeat any mistake under any circumstance. Each one exists because a real incident showed exactly this failure happening, and each is verified against that exact scenario, not a hypothetical one.