Your Traces Already Know What Broke. Your Agent Doesn’t., Memanto Blog

← Back to all posts<br>LANGFUSE

ON THIS PAGE<br>The obvious version of this integration is a disaster<br>One memory per signature, not per occurrence<br>Two ways in, one ledger<br>Path 1 — the CLI sync, starting with a look at your own data<br>Path 2 — two lines in your app<br>What a span can and cannot see<br>It runs next to your app, never through it<br>What your agent actually gets<br>The point is not the integration<br>Get started

CATEGORYEngineering<br>PUBLISHEDAugust 12, 2026<br>READ TIME9 min

Every team running agents in production eventually installs observability, and every one of them ends up with the same quietly absurd arrangement: a system that records, in perfect detail, exactly how the agent failed — and an agent that will never read a word of it.<br>Langfuse is very good at its job. Traces, spans, evaluation scores, latency distributions, per-call cost. When something breaks at 3am, the answer is in there. But the audience for that data is a human with a dashboard open. The agent that caused the failure has no idea any of it exists. Tomorrow it wakes up, plans from scratch, and walks into the same wall — while the dashboard faithfully records that it happened again.<br>That gap is the whole reason `langfuse-memanto` exists, shipped in Memanto v0.2.14 . Langfuse records what went wrong. Memanto remembers the lesson. This post is about the design decisions in between, because the naive version of this integration is a trap — and the trap is instructive.<br>The obvious version of this integration is a disaster<br>The tempting design is a firehose: subscribe to traces, write each failing one as a memory, done. It takes an afternoon and it destroys your memory store.<br>Memanto performs no deduplication on write — deliberately, because dedup-on-write means an LLM call on every save and a guess about what counts as "the same." So a firehose means one bad deploy writes four thousand near-identical memories overnight. Recall stops working, not because retrieval got worse, but because every query now returns forty variations of the same sentence and the one genuinely useful memory from last month is buried under them. You didn't give your agent a memory of the incident. You gave it a landfill with the incident somewhere inside.<br>The volume asymmetry is the core problem, and it is severe: observability is high-frequency by design, memory is high-signal by design. Anything that connects them has to be a reducer, not a pipe.<br>“A thousand occurrences of one failure is not a thousand lessons. It is one lesson, learned harder.<br>One memory per signature, not per occurrence<br>So the integration groups before it writes. Every observation is reduced to an error signature : the operation name, plus the message with its volatile parts — ids, numbers, emails, IPs, file paths, quoted strings — normalized away. Everything sharing a signature is one memory.<br>textLangfuse observations (thousands)<br>│ filter level=ERROR, your score rules, your latency/cost budgets<br>│ group signature = operation + normalized message<br>│ reconcile new → write · changed → update in place · same → skip<br>Memanto (dozens)Here is a real run against a live project. 812 observations became 2 memories:<br>textNamespace not found in generate-response error confidence 0.60<br>Slow: generate-response (anthropic.claude-sonnet-4-6) observationThe in that title is not a bug and not a truncation — it is the group's identity. The specific namespace that was missing changed 400 times; the fact that this operation fails on missing namespaces did not. The placeholder is what lets the variations collapse.<br>Occurrence count is not thrown away either — it becomes confidence . The formula is min(0.95, 0.60 + 0.15 × log₁₀(occurrences)), so a one-off scores 0.60, a hundred occurrences scores 0.90, and nothing ever reaches certainty. That curve is the point: seeing a failure once is weak evidence, seeing it a hundred times is strong evidence, and the difference between the hundredth and the thousandth occurrence is not worth much. A recurring failure does not write a second memory — it updates the existing one in place with the new count, the new last-seen timestamp, and the higher confidence.<br>And the whole reduction is rule-based . Regex normalization, a hash, a log curve. No LLM calls, no token cost, no nondeterminism in the thing that decides what your agent believes. An integration that summarizes your errors with a model is an integration that hallucinates into your memory store at scale.<br>Two ways in, one ledger<br>There are two paths into Memanto, and they exist because they see genuinely different things.<br>Live SDK handlerCLI syncSetup pip install langfuse-memanto + one lineAlready in memantoLatency SecondsWhen you run itRequires langfuse>=3 in your appNothing — reads the Langfuse APICaptures Errors, latencyEverything, including scores and cost<br>Most teams run both: the handler for instant error capture, and a periodic sync for the signals that only exist...