Cascading failures don't start in your infrastructure. They start in memory.

Here is a scenario worth sitting with. An infrastructure agent misreads a utilization metric — a unit mismatch in a cloud cost API returns CPU load as an absolute number rather than a percentage. Services running at 70% appear to be running at 7%. The agent concludes that production is severely underutilized, writes that conclusion to persistent memory, and flags an optimization opportunity.

A downstream deployment agent picks up the plan, finds it policy-compliant, and scales down compute across multiple regions. A monitoring agent watches the post-deployment state and sees reduced alert volume, climbing utilization figures, apparent cost savings. It reports success. The planning agent updates its memory: consolidation confirmed as effective.

Several hours later, customer-facing services begin timing out.

The incident is now your problem to unwind — and the infrastructure problem is actually the easier half. The harder half is that the agent's memory still records the whole sequence as a success. If you restore the compute without touching the memory, the agent will re-propose the same changes on its next planning cycle and walk you back into the same state.

This is the core insight buried in OWASP's ASI08 (Cascading Failures): the initial fault is rarely what causes systemic damage. It's the propagation of that fault through persistent memory, delegated trust, and automated approval that turns a single bad datapoint into a multi-hour incident.

Why infrastructure rollback isn't recovery

Traditional distributed systems incident playbooks treat rollback as recovery. If you can restore the previous state, you've fixed the problem. In agentic systems, this assumption breaks down.

When an agent writes a conclusion to long-term memory — an optimization finding, a capacity baseline, a trust assessment of another agent — that conclusion doesn't expire when the conversation ends, when the triggering event is corrected, or even when the infrastructure is restored. It persists. And it influences every subsequent planning cycle that draws on it.

The OWASP guide describes this plainly: memory persistence is what distinguishes cascading failures in agentic systems from cascading failures in traditional distributed systems. Rolling back infrastructure without remediating the contaminated memory entries leaves the system able to re-enter the failed state on its own.

Recovery requires two things: restoring the infrastructure and identifying which memory entries were created or updated during the incident, marking them as untrusted, and either purging or quarantining them before the next planning cycle runs.

Without memory provenance — metadata recording which agent wrote each entry, from which inputs, at what confidence level — that second step is nearly impossible. You can't audit what you can't trace. You can't remediate what you can't identify.

The consistency problem no individual agent can solve

The OWASP analysis surfaces something else worth naming: in the scenario above, every individual agent did its job correctly. The planning agent analyzed the data it was given and drew a reasonable conclusion. The deployment agent executed an approved plan. The security agent checked the change against policy rules and found no violations. The monitoring agent reported accurately on the system state it could observe.

The failure existed between the agents, not within any of them.

No single agent had the information needed to catch it. The deployment agent didn't know the planning agent's utilization figures came from a bugged API. The security agent didn't know the blast radius of what it was approving. The monitoring agent couldn't see the requests being dropped before they reached degraded services — it could only report on what was still reachable. Each agent operated correctly within its slice of the system, and the system failed across the seams.

This is a consistency problem. The remedy OWASP proposes is a cross-agent consistency oracle: something that compares claims across agents and flags disagreements — a planning agent's utilization figure against the monitoring agent's traffic measurements, a deployment agent's record of region health against the load balancer's view of capacity.

A shared memory graph is what makes this structurally possible. When every agent reads from and writes to the same persistent knowledge store, contradictions don't have to be detected by a dedicated oracle with explicit comparison logic. They surface as conflicts in the graph: the planning agent's "services at 7% utilization" node sits alongside the monitoring agent's traffic data, and those two entries disagree. A system that checks for contradictions at write time — flagging new entries that conflict with standing records — catches these seams automatically rather than letting them widen into incidents.

Delegated trust as an amplifier

One more structural enabler the OWASP analysis identifies is worth pulling apart. Agents in multi-agent systems routinely act on the outputs of other agents without revalidating the original assumptions. This is deliberate — rechecking every upstream conclusion would undermine the efficiency that makes autonomous systems worth deploying. But it creates a specific failure mode: the authority to delegate a task gets conflated with certification that the task is based on sound inputs.

In the scenario, the deployment agent didn't independently verify the utilization claim because the planning agent's authority to issue the task was taken as implicit certification that the task was well-founded. These are two different claims. An agent can be fully authorized to request an infrastructure change while also being completely wrong about the reason for it.

Memory provenance is the lever here too. If every memory entry carries a lineage chain — this conclusion was derived from these inputs, which came from this tool response, which was generated at this timestamp — then an agent acting on an upstream conclusion can check how old that conclusion is, how many inference steps removed it is from a raw data source, and whether any of the intermediate claims have since been flagged. Delegated trust doesn't have to be blind. It can be proportional to the confidence the lineage metadata supports.

What Recordari provides

Recordari's audit log records every read and write with full attribution: which agent, which tool call, which arguments, which timestamp. That's the forensic foundation. After a cascade, the question "which entries were written or updated during the incident window?" has a concrete, queryable answer.

The node_kind model gives memory entries structural weight. A standing node — a durable, human-authored rule or constraint — carries a different trust signal than a finding filed by an autonomous agent mid-workflow. When an agent's cascade-produced "successful consolidation" entry conflicts with a standing node about capacity thresholds, the graph doesn't treat them as equivalent. The contradiction is visible and flagged.

What Recordari doesn't yet do — and this is worth being direct about — is automatic lineage tracking across multi-agent delegation chains, or real-time cascade detection. Those are on the roadmap, not shipped today. What exists today is the audit record and the standing node model: the forensic layer that makes post-incident remediation possible, and the anchor points that cascades have to contradict before they can take hold.

That's not a complete defense. But it's the foundation one has to be built on, and most teams don't have it yet.

---

References: OWASP Agentic AI Threats and Mitigations — ASI08: Cascading Failures — Triedman et al., Cornell Tech (2025) — Barbi et al., Tel Aviv University (2025)