Zum Hauptinhalt springen
tsecurity.de LIVE
Echtzeit-Radar & Feeds
Alle RSS Feeds
👥 Community & Social
Sichere ProgrammierungI upgraded three Flutter apps to API 36. Here is what actually broke(20.09.2026 um 17:37 Uhr)
Sichere ProgrammierungSite-Wide Structured Data and Social Graph Integration(20.09.2026 um 17:44 Uhr)
Sichere ProgrammierungExact Match Or Fuzzy Logic For OFAC? 1,400 Tests Changed My Mind.(20.09.2026 um 17:45 Uhr)
Sichere ProgrammierungWhat Makes You Trust an APK Download?(20.09.2026 um 17:47 Uhr)
Sichere ProgrammierungGood News For Backend And Devops Buddy(20.09.2026 um 17:50 Uhr)
Linux Tipps & HardeningBeginner Guide: What Is Linux Mint and Why It Is So Popular(20.09.2026 um 17:54 Uhr)
Sichere ProgrammierungI upgraded three Flutter apps to API 36. Here is what actually broke(20.09.2026 um 17:37 Uhr)
Sichere ProgrammierungSite-Wide Structured Data and Social Graph Integration(20.09.2026 um 17:44 Uhr)
Sichere ProgrammierungExact Match Or Fuzzy Logic For OFAC? 1,400 Tests Changed My Mind.(20.09.2026 um 17:45 Uhr)
Sichere ProgrammierungWhat Makes You Trust an APK Download?(20.09.2026 um 17:47 Uhr)
Sichere ProgrammierungGood News For Backend And Devops Buddy(20.09.2026 um 17:50 Uhr)
Linux Tipps & HardeningBeginner Guide: What Is Linux Mint and Why It Is So Popular(20.09.2026 um 17:54 Uhr)
Intelligence View
⚡ tsecurity.de Intelligence

Store the proof, not the moral

Reagiere als Erste:r — dein Feedback zählt!

The most useful idea I picked up from all those conversations was not a technique. It was a way of thinking about what a memory even is. Someone put it like this: a memory should hold proof, not a moral. I have been chewing on it ever since, because the more I sit with it the more it explains why agent memory goes wrong in the specific way it does.

Two things get tangled together every time an agent records a failure. There is the event, which is a fact about the past. On Tuesday, the agent tried approach X and it produced error Y. That happened or it did not. It is fixed, it is checkable, you could in principle go back and confirm it. And then there is the lesson, which is an inference drawn from the event. Therefore, do not use approach X. That is not a fact. It is a hypothesis about the future, and like any hypothesis it might be wrong, or it might stop being true later.

The trouble is that most memory I have seen stores the second thing and quietly drops the first. It keeps "do not use X" and throws away "because on Tuesday it broke with Y." Which feels efficient. The conclusion is what you act on, so why keep the messy event around.

Because once the lesson is cut loose from its evidence, you can never check it again. You are left with a rule and no way to ask whether the rule is still warranted, because the thing that warranted it is gone. The agent will keep refusing to use X long after the reason evaporated, and it cannot even tell you why, only that it knows not to. That is superstition, in the precise sense. A behavior that has outlived its justification and no longer remembers it ever had one.

It gets worse when you think about strength of evidence. A lesson learned from a single fluke and a lesson learned from twenty consistent failures look identical once they have both been compressed to "do not use X." The number of times it actually failed was part of the proof, and you threw that away too. So the agent gives a thing that failed once the same hard conviction as a thing that failed every time, because the only part it kept was the conviction.

This is, if you have not noticed, extremely human. We do it constantly. You get burned once by something, you form a rule, and then you defend the rule for years after you have forgotten the single incident that created it. The incident, if you still had it, would be checkable. You could ask whether it was ever representative, whether the thing that made it fail is even still around. The detached rule cannot be questioned that way, so it just sits there shaping your behavior, unfalsifiable. We carry a lot of orphaned morals and call them experience.

So what does holding proof instead look like. The event stays put, immutable, primary. It is what happened and the evidence that it happened, and nothing later is allowed to edit it. The lesson becomes a separate, derived thing hanging off the event, and that one is allowed to change. When new evidence shows up, you revise the lesson and leave the event alone. The event is the ground truth. The lesson is your current best reading of it, marked clearly as a reading, not a fact.

The honest catch is that this is more work, not less. More to store, more structure, and it does not make the hard decision go away. You still have to decide when a lesson should be revised, and that is a judgment nobody has automated cleanly. But, and this is the whole point, keeping the event around is what makes the judgment possible at all. Without the proof you cannot even have the argument about whether the moral still holds. You are just stuck with the moral.

There is a thread back to something I wrote about before. The cleanest reason to revise a lesson is an outcome, you acted on the rule and watched what happened. But most setups never capture outcomes, so the revision step has no trigger and the lessons quietly calcify. Keep the event and you at least preserve the option to revisit. Drop it and the calcification is permanent.

I do not think there is one correct schema for this. But I have started believing that any memory which only stores conclusions is building up a pile of rules it can never audit. So I am curious how others handle it. Do you keep the raw event separate from what you concluded from it, or do you store the conclusion and hope it stays right? I would like to know if anyone has found a clean way to let the lesson move while the evidence stays nailed down.

Ähnliche Beiträge
🔍 Verwandte News

Auch interessante Nachrichten Store the proof, not the moral

Thematisch verwandte Begriffe: Store, proof, moral · 6 Treffer

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Zum Aktualisieren ziehen
ZERO-DAY CVE-2026-93956 | A flaw has been found in olivier-ls PHP-FTS up to 1.1.2. Affected by thi…
Advisory →
TTS Reader • tsecurity.de Voice
tsecurity.de Icon
tsecurity.de App
Offline-Lesen, Eilmeldungen & 0ms Ladezeit

Installiere tsecurity.de direkt auf deinen Home-Bildschirm für das ultimative Vollbild-Magazinerlebnis ohne Browser-Leisten.

Nächster Beitrag
Themen-Radar & Intelligence Matrix
Echtzeit-Taxonomie nach Angriffsvektoren & Plattformen
Community Radar & Live Chat
Sentinel Bot online • Live-Stream
Dein Cluster: Security Explorer
Match:
lädt…
Verbindung zum Community-Stream wird aufgebaut...
Bearbeitungsmodus — Senden überschreibt deine Nachricht
Community-Puls — was gerade passiert
lädt…
Aktivitäten deiner Analysten
lädt…
Neues Thema oder Eilmeldung einreichen

Reiche interessante Links, Zero-Days oder Debatten ein. Die Community entscheidet per Upvote über die Veröffentlichung.

Heiß diskutierte Einreichungen
🔖 Gespeicherte Artikel
📂 Keine gespeicherten Artikel vorhanden.
Zurück Ziehen Vor
Links: vorheriger Artikel Rechts: nächster Artikel unten: schließen
News NIS-2 Frühwarnung Tier-1 Intel ⏱️ 3 Min vor 10 Min
Artikeldaten werden geladen...

Zurück: vorheriger Vor: nächster
↗ Original-Quelle
Social Reaktionen Deine Reaktion zählt
Einstufung & Relevanz-Poll 0 Stimmen
In sozialen Netzwerken teilen 1-Klick