The lead who owns the agent.
Run `ferryte why` on the bad answer instead of grepping traces until midnight. Get the memory that caused it, its full lineage, and a one-command fix — in minutes.
Modern AI agents do not just store what you tell them. They distill it — into summaries, embeddings, graph nodes, per-user facts — and answer from those derivations weeks later. So when the agent gets something wrong, the cause is buried in a memory nobody can see, derived from a source nobody remembers writing.
This is not a guess. The platforms themselves document it — that deleting a source leaves its derived memory behind, that revocation does not propagate, that poisoned context survives. Three different vendors, three different products, the same admission: memory misbehaves, and it does so invisibly.
“Deleting an event doesn’t remove the structured information derived out of it from the long term memory.”
“Deleting an episode does not regenerate the names or summaries of nodes shared with other episodes.”
“Adversaries corrupt or seed this context with malicious or misleading data, causing future reasoning, planning, or tool use to become biased, unsafe, or aid exfiltration.”
A customer corrects a fact. A tenant churns. A user asks to be forgotten. Your app does the obvious thing — updates the record, calls delete, moves on. The primary row is handled.
Then your agent answers a question, and the answer is sourced from a summary generated weeks ago that absorbed the old fact. The model isn’t hallucinating — it is faithfully retrieving from a derivation nobody knew existed. And when it’s wrong, the person on call opens the logs and starts reading: no map from the bad answer to the memory behind it, no record of where that memory came from, no way to know what else it touched.
The bug is not the model. The bug is that agent memory is a black box — you can see what it said, never why it believed it.
Almost nobody can trace this. The cost is borne at incident time — a confused customer, a screenshot in a Slack thread, a support ticket, a privacy email — and the fix is hours of grepping traces and hoping you deleted the right thing.
So we stopped guessing and started tracing. We reproduced one class of this live on AWS Bedrock AgentCore — delete the source, the derived records still answer. Deletion is only one way memory misbehaves; stale facts, cross-tenant bleed, and poisoned writes are the rest. All of them live in the derived layer an app composes on top. The honest, reproducible evidence is The Memory Report.
Run `ferryte why` on the bad answer instead of grepping traces until midnight. Get the memory that caused it, its full lineage, and a one-command fix — in minutes.
Open the customer’s memory timeline and see exactly what the agent believes about them and where each belief came from — then correct the one that’s wrong, without wiping the rest.
GDPR and CCPA right-to-be-forgotten don’t end at the row. Ferryte proves a deleted memory — and everything derived from it — is gone across raw stores, summaries, embeddings, and retrievals, and (in Enterprise) signs the attestation.