A guardrail is not one filter at the end. It's seven checkpoints with different jobs — and the one everyone skips is memory.
Guardrails get imagined as a filter bolted onto the output: catch the toxic answer, mask the personal data, ship it. That is one checkpoint out of several, and by the time it runs most of the interesting failures have already happened upstream, invisibly.
The layers have genuinely different jobs. Input validates what arrives — size, schema, injection attempts. Prompt protects the instructions themselves from being overridden. Retrieval decides which sources are trusted and how fresh they must be. Memory governs what may be written, how long it lives and what must never be recalled. Tool constrains what the system may actually do — allowlists, sandboxes, limits, and human confirmation on the irreversible step. Runtime watches for loops, latency and anomalies while the work is happening. Output is the last check, not the only one.
Memory is the layer that gets skipped, and it is the one that compounds. Everything the system writes down it will later read back and act on, so an unfiltered write is a delayed unfiltered read — sensitive data captured today surfaces in an unrelated answer next month, and expired facts keep voting long after they stopped being true. A retention rule and an expiry rule are guardrails even though nothing about them looks like a filter.
The distinction to hold onto is between guardrails and governance. A guardrail is a runtime check that constrains this action, now. Governance is the policy layer above it: who is accountable, what is auditable, what may be accessed at all. They are routinely conflated, and conflating them produces systems with excellent output filters and no answer to the question of who decided this was allowed.