To analyze reliability across heterogeneous agent frameworks, we abstract LLM agent frameworks into five architectural layers: decision/control, state/memory, action/execution, environment/feedback, and governance/monitoring. This abstraction is not intended to prescribe a specific implementation. Rather, it provides an analytical model for comparing how failures arise, propagate, are measured, and are mitigated across different LLM-based agentic AI systems.

Decision/control layer. This layer determines what the agentic system should do next. It includes goal interpretation, task decomposition, planning, reasoning, policy selection, and action selection. Failures at this layer include goal drift, instruction misinterpretation, unsafe planning, incorrect tool selection, and deviation from user or system constraints.

State/memory layer. This layer maintains information across steps. It includes short-term task state, long-term memory, intermediate artifacts, retrieved context, shared multi-agent state, and summaries of previous interactions. Reliability failures arise when this state becomes stale, inconsistent, incomplete, hallucinated, or misaligned with the true environment.

Action/execution layer. This layer converts agent decisions into executable operations. It includes tool invocation, application programming interface (API) calls, code execution, workflow execution, external system interaction, and side-effectful actions. Failures at this layer include malformed calls, incorrect parameters, missed actions, partial execution, unreported tool errors, and unsafe side effects.

Environment/feedback layer. This layer captures observations returned from tools, users, external systems, simulators, or other agents. It determines how the system interprets execution results and updates its subsequent behavior. Failures include ignored feedback, misinterpreted tool outputs, delayed or partial observations, noisy environment signals, and recovery decisions based on incorrect feedback.

Governance/monitoring layer. This layer provides oversight over the agent loop. It includes runtime monitoring, policy enforcement, permission control, auditing, anomaly detection, logging, human intervention, rollback, and recovery mechanisms. Failures occur when monitors lack visibility, policies are incomplete, alerts are missed, or recovery mechanisms hide rather than resolve underlying faults.

Layers identify where a function operates; architectural premises identify what must hold for that function to remain reliable. We distinguish four premises that cut across the five layers [Table 2]. Semantic fidelity concerns whether a representation preserves task-relevant meaning. Instruction stability concerns whether valid goals and authority boundaries persist across steps. Observability concerns whether deviations leave accessible evidence. Recoverability concerns whether the system can reach an acceptable state after a detected deviation. These premises are analytical lenses, not guarantees supplied by natural-language reasoning.

A premise violation can explain a failure only when the required evidence is available. A stale memory item may produce an incorrect plan, but the same plan may also result from misinterpreting a current observation. We therefore distinguish a plausible architectural explanation from an experimentally isolated cause. Controlled interventions and traces are needed to discriminate between such explanations. Section “Representative cross-layer failure chains” develops representative analytical chains that specify the originating layer, propagation path, detection signal, and possible interruption point.

Reliability mechanisms protect different links in these chains. State validation addresses fidelity, pre-action policy checks address instruction stability, trace capture enables observability, and bounded repair or escalation supports recoverability. No single placement ensures all four premises: a monitor may observe a fault without authority to block it, while an action gate may prevent one unsafe call without repairing corrupted memory. This distinction connects the architectural model to the measurement dimensions in Section “OPERATIONALIZING AND MEASURING RELIABILITY” and the mechanism interfaces in Section “RELIABILITY MECHANISMS AND THEIR INTERFACES”.

Based on this architectural model, this survey is organized around four research questions. The survey progresses from problem formulation, through measurement and mitigation, to a synthesis of architectural and evaluation design choices. This structure enables a premise-driven mapping from architectural layers to failure mechanisms, evaluation validity, and intervention points. Table 3 summarizes the roadmap.

RQ1 examines how reliability is defined and operationalized across LLM agent frameworks, including how recurring failures are named, scoped, and mapped to architectural premises. RQ2 studies how reliability is measured through metrics, benchmarks, datasets, oracles, and protocol design, with particular attention to observability and validity threats. RQ3 organizes reliability mechanisms by solution paradigm, pipeline placement, required signals, and input/output interfaces. RQ4 compares how architectural choices change reliability requirements, evaluation evidence, and mitigation interfaces.

Reliability analysis requires two linked vocabularies: one for evaluating behavior and one for explaining how it breaks down. A reliability construct is a property of interest, such as functional correctness, state consistency, policy conformance, or recoverability. A requirement makes that property concrete for a task and operating condition. A failure is a violation of such a requirement, whether or not it is detected; detection requires observable evidence. A failure mode is a recurring pattern of violation, such as control drift or inconsistent state. These terms do not identify the cause on their own.

A cause is a condition or event that contributes to a failure; an unmet architectural premise is a candidate explanation at the system-design level. A symptom is evidence that a failure may have occurred, such as contradictory messages. An observable is a recorded variable or event, such as tool return status or a state version. A metric summarizes specified observables under a scoring rule, such as the proportion of checked states that contradict an authoritative record. An oracle supplies the criterion used to judge those observations. Thus, control drift is a failure mode, while contradiction rate is a metric; neither term can replace the other.

Consider an illustrative scheduling task. The construct is execution correctness, and the requirement is that a confirmed booking corresponds to an actual calendar event. A stored “booked” state without an event is a failure instance; repeated unsupported completion claims form a failure mode. An ignored API error is a possible cause, the mismatch between the confirmation and the absent event is a symptom, and the API return and calendar state are observables. The proportion of confirmed bookings lacking events is a metric evaluated against the calendar record. The full trace is needed to establish whether the fault arose in execution, feedback interpretation, or memory updating. This example is an analytical illustration, not an additional empirical finding.

Several studies formalize failure naming schemes to support comparison. Winston and Just analyze tool-augmented LLMs and distinguish failures rooted in tool selection, tool use, and the surrounding augmentation pipeline^[26]. Sapkota et al. distinguish AI agents from agentic AI at the system-concept level, emphasizing differences in autonomy, coordination, and operational scope^[27]. By contrast, Bullwinkel et al. report empirical lessons from red teaming 100 generative AI products; their evidence broadens the catalog of observed safety and security failures but is not itself a tool-agent reliability taxonomy^[28]. Together, these works show that comparisons require an explicit level of analysis and clearly specified observables.

Safety- and security-oriented studies define reliability primarily through policy conformance. For example, tool-augmented and governance-oriented work emphasizes whether agent behavior remains within permitted control and execution boundaries^[29-31]. This framing shifts the reliability question from whether the agent completes a task to whether it does so while respecting policies, constraints, and enforcement mechanisms.

In multi-agent settings, reliability is often defined through state consistency, control agreement, and fault tolerance. Zheng et al. study robustness to erroneous messages and adversarial agents across multi-agent communication topologies, and propose confidence-probe-weighted Byzantine consensus^[32]. Cemri et al. examine coordination breakdowns without assuming explicit attackers, highlighting inconsistent beliefs, misaligned objectives, and failures in shared task progress^[9]. These studies show that small mismatches in shared state or intent can accumulate across agents and become difficult to diagnose.

Other works emphasize execution validity in non-adversarial settings. Tool-use and runtime-enforcement studies focus on whether agents select appropriate actions, invoke tools correctly, surface errors, and respect execution constraints^[29,33,34]. In these settings, reliability depends less on adversarial robustness and more on whether the agent follows the required process and produces valid execution traces.

Long-horizon agents introduce an additional challenge because failures may remain latent before affecting final outcomes. This reframes reliability as timely detection and recovery, rather than only final task success. For example, an agent that repeatedly attempts the same invalid API call without adapting to error responses illustrates ineffective self-correction. Governance and monitoring frameworks address this problem by requiring visibility into agent behavior, enforceable constraints, and auditability^[29-31].

Across these studies, each reliability framing corresponds to different failure modes and measurements. Tool-oriented taxonomies cover selection, invocation, and execution failures^[13,26]. Safety and governance constructs emphasize constraint compliance and enforceable oversight^[29-31]. Multi-agent robustness emphasizes coordination breakdowns, error propagation, and shared-state consistency^[9,10]. Execution-centric work focuses on required-step completion, tool-call validity, and runtime enforcement^[29,33,34]. This synthesis shows that “reliability” is not a single construct, but a family of related constructs tied to different architectural assumptions and evaluation signals.

The surveyed sources offer different kinds of evidence rather than a single shared reliability measure. AgentSpec evaluates event-triggered constraints, Security Architecture for Governing Agentic systems (SAGA) implements user-controlled inter-agent access policies, and AGENTSAFE proposes lifecycle governance controls and a validation plan^[29-31]. Their measurements or proposed indicators must therefore be interpreted against the property and implementation each source actually describes.

Reliability in LLM agent frameworks is evaluated through diverse constructs, including functional correctness, robustness, safety and security, process compliance, policy conformance, and trajectory-level detectability. Because each construct implies different failure modes and measurements, explicit definitions are essential for meaningful cross-study comparison.

The following chains synthesize failure patterns discussed in the tool-use, coordination, and injection literature^[9,26,35]. They are analytical examples, not reconstructed incidents or estimates of frequency. Their purpose is to show why the layer where a fault originates, the layer where harm occurs, and the point where a monitor can intervene need not coincide.

Chain A: stale state propagates through an unreported execution error. A memory entry records an obsolete resource identifier (state/memory). Planning treats it as current (decision/control), a tool call fails (action/execution), and a summary drops the error while retaining the intended action as completed (environment/feedback back to state/memory). A monitor that reads only the summary may then approve continuation (governance/monitoring). Semantic fidelity and observability are both at issue. State-version checks can expose the initial mismatch; correlating the tool return with the subsequent state update can expose propagation. A pre-action freshness check can interrupt the chain before execution, whereas post-action reconciliation can repair state without guaranteeing reversal of external effects.

Chain B: untrusted feedback acquires instruction authority. A retrieved page contains an instruction to transmit data (environment/feedback). The planner treats that content as authoritative (decision/control), stores the new instruction as a task requirement (state/memory), and invokes an external-transfer tool (action/execution). Governance fails if the gate checks only argument syntax. The initiating issue is loss of instruction stability; the terminal failure is a policy violation. Source provenance, changes in the active goal, and the destination of the proposed call provide complementary observables. An authority check or information-flow policy before execution can block the action, but stored malicious instructions must also be removed or isolated to prevent a later recurrence.

Chain C: an ambiguous result turns recovery into a new fault. A side-effectful operation succeeds externally, but its response times out (action/execution and environment/feedback). Memory records an unresolved attempt, and the planner retries without checking the external state (state/memory and decision/control). The retry creates a duplicate action, while a monitor records eventual completion as successful recovery (governance/monitoring). Observability and recoverability fail together: absence of an acknowledgment does not establish absence of an effect. Operation identifiers, external-state checks, and duplicate-effect counts can distinguish successful completion from safe recovery. Idempotent operations or compensating actions may interrupt this chain when the environment supports them; otherwise, escalation may be the only acceptable response.

Figure 1 summarizes the three analytical chains, separating propagation from the observations and interventions that can expose or interrupt it. Across the three chains, effective diagnosis requires both a local check and a link to downstream state. A valid tool schema cannot establish that an action is authorized, a recorded error cannot ensure that the planner uses it, and eventual task success cannot establish that recovery was safe. These distinctions motivate separate measurements of failure incidence, detection, propagation, and recovery in the next section.

Reliability metrics address four complementary scopes [Figure 2]: outcomes, process and state, execution, and monitoring. Outcome measures assess the requested result; process and state measures examine intermediate decisions and records; execution measures check calls and their effects; and monitoring measures assess detection and recovery. The relevant metric depends on the requirement being tested and the evidence available at that scope.

This measurement perspective is important because silent failures can occur before final task failure becomes visible. LLM-based agentic AI systems may generate plausible plans or state summaries while the underlying control or state has already diverged from correctness. For example, a system might present a coherent itinerary for booking a flight, yet rely on outdated seat availability, resulting in a plan that appears valid but fails during execution. The four measurement scopes separate the requested outcome from evidence about intermediate state, external execution, and monitoring.

Outcome metrics summarize judged endpoints; in this survey, we distinguish that evidence from diagnosis of deviations that were corrected, hidden, or outside the final scoring criterion. MAESTRO evaluates multi-agent systems using accuracy, resource use, repeated executions, and observed execution behavior^[36]. Endpoint evaluation can also target harmful task completion. AgentHarm uses synthetic tools and task-specific grading criteria to measure completion of malicious requests, with LLM judgments restricted to narrow subtasks^[37]. However, outcome scores alone rarely identify the layer where a failure occurred and may miss both earlier faults corrected before scoring and unresolved deviations outside the endpoint oracle’s coverage.

Trajectory-level metrics provide deeper diagnostic insight by evaluating whether LLM agent frameworks make correct intermediate decisions and maintain consistent state. Step correctness and plan-following metrics probe the decision/control layer, while contradiction rates, stale-state usage, and invariant violations target the state/memory layer. MAESTRO examines stability through execution call graphs across runs^[36]. Contradiction rates, stale-state usage, and invariant violations are complementary measures proposed in this survey; they should not be read as metrics MAESTRO reports. Traces often reveal degradation patterns that are invisible in outcome metrics, and effective failure attribution depends on observability of intermediate reasoning and state transitions.

Tool-use failure analyses motivate distinguishing selection, invocation, and execution problems at the action boundary^[13,26]. For systems with retries or rollback, this survey additionally recommends recording those events and their effects. The failure categories reported by Winston and Just^[26] and Huang et al.^[13] motivate checking tool selection and execution evidence separately from the agent’s verbal summary. In our analysis, a plausible response alone cannot establish that a required external action took place. Workflow-level evaluations extend this view by defining correct behavior as both reaching intended results and executing necessary steps under realistic feedback. This leads to metrics such as end-to-end execution success, retry and rollback counts, and stuckness rates, which connect execution to the environment/feedback layer.

Recovery metrics are essential for characterizing operational reliability in frameworks that incorporate retries, rollbacks, and self-correction. Our synthesis recommends evaluating whether recovery restores the stated requirement, rather than counting eventual task completion alone. However, robust recovery mechanisms can mask frequent upstream errors, resulting in high task success despite repeated violations of control or state assumptions. Reporting should therefore separate fault incidence from recovery effectiveness, since consensus or recovery loops may improve observed outcomes without reducing underlying error rates.

Safety and security requirements can be evaluated across these scopes, including harmful outcomes, unauthorized calls, and missed policy violations. InjecAgent measures whether malicious tool responses induce specified harmful calls or data-exfiltration sequences^[35]. Attack success is inferred from parsed model outputs in simulated tool interactions, rather than verified side effects in a real external service. AgentHarm evaluates agents responding to directly harmful requests through synthetic tools; its completion scores are proxies for harmful behavior, not observations of real-world side effects^[37]. Shen et al. analyze disclosed vulnerabilities, their root causes, and developers’ mitigation decisions in agent applications^[38]. This evidence concerns the security of the application and its components; it is not a scalar runtime-reliability metric.

Metrics assessing the detectability of failures are critical because language plausibility can conceal execution errors. MAESTRO foregrounds observability signals and instrumented traces for multi-agent testing and diagnosis^[36]. SecureFixAgent illustrates a narrower software-engineering case in which an LLM-driven repair loop is checked by repeated Bandit static-analysis scans^[39]. This is evidence for analyzer-backed validation in code repair, not direct evidence that the same alert trade-offs have been established for general LLM-agent monitoring.

Resource use is an operating condition to report alongside the four measurement scopes. Budget exhaustion, timeouts, and excessive retries can render otherwise correct systems unreliable in real-world settings. MAESTRO measures resource consumption alongside accuracy^[36]. For recovery-enabled workflows, we additionally recommend recording retries, rollbacks, stuckness, latency, and monitoring burden; these are proposed reporting dimensions, not a list of MAESTRO’s reported metrics. Together, these indicators allow evaluators to distinguish productive deliberation from unproductive correction loops and to avoid attributing resource-driven failures to reasoning quality alone.

An endpoint score should be paired with the intermediate checks needed to detect the failure under study. For retrying systems, recording the original fault separately from the final outcome also distinguishes recovery from low failure incidence.

Outcome, process/state, execution, and monitoring measures answer complementary questions. Their interpretation depends on the requirement checked and the evidence exposed at each scope.

Benchmarks and datasets are central to evaluating LLM-based agentic AI systems because they define the oracle, circumscribe observable failure modes, and operationalize correctness within interactive loops^[19]. In agentic settings, this dependence is heightened: evaluation is tied to a specific interaction protocol and stopping rule, so the meaningfulness of any metric is constrained by the supervision it encodes. MAESTRO combines repeated execution with resource, accuracy, and execution-structure measurements, showing the value of examining more than a terminal answer^[36]. As a result, reported success rates can obscure substantial differences in how benchmarks define oracles, which error types are detectable, and whether measured wins truly reflect correctness or merely correlate with it^[19,36].

Table 4 compares the task domains, evaluation evidence, and validity limits of representative studies. Oracle type identifies how a verdict is produced, such as an executable check, a state predicate, or human or model judgment. Fidelity concerns how well that verdict represents the target requirement, given its coverage, judgment error, and access to relevant state. These dimensions distinguish the procedure used to judge an execution from the validity of the resulting judgment.

API benchmarks expose different notions of correctness. ToolLLM combines the broad API inventory of ToolBench with model-judged pass and win rates; these scores depend on live API behavior, evaluator prompts, search budgets, and whether the relevant APIs are provided by an oracle retriever^[41]. BFCL separates abstract syntax tree (AST)-based call validation from executable checks and combines state and response checks for multi-turn tasks^[42]. This distinction matters for the action–feedback interface: reaching a matching state does not establish that a required read-only call was executed, while syntactically valid arguments do not by themselves establish the intended external effect.

Interactive environments further change what the oracle can observe. WebVoyager evaluates live-web tasks through human and multimodal-model judgments over navigation evidence, with changing answers and excluded login or Completely Automated Public Turing Test to Tell Computers and Humans Apart (CAPTCHA) workflows limiting its coverage^[43]. OSWorld instead combines explicit computer-state initialization with execution-based scripts for desktop and cross-application tasks^[44]. SWE-bench applies proposed repository patches and runs associated tests to check issue resolution and preserved behavior^[45]. These environments make execution consequences observable in complementary ways, but screenshot judgments, selected state predicates, and test suites each leave properties outside their checks.

Breadth and process visibility should also be reported separately. AgentBench covers eight code, game, and web environments and records execution outcomes such as invalid actions and interaction-limit termination alongside domain-specific measures^[46]. GAIA, a benchmark for general artificial intelligence (AI) assistants, allows diverse tools for human-designed questions but evaluates concise final answers by normalized matching^[47]. AgentBoard adds state- or subgoal-based progress across nine environments^[48]. Its score retains the highest progress reached, so a later regression need not reduce that score. Together, these designs distinguish domain coverage, endpoint correctness, and achieved intermediate progress; none alone supplies a complete measure of recoverability.

Security-oriented code repair provides a narrower example within the software-engineering domain. SecureFixAgent iteratively generates Python repairs and re-runs Bandit to check whether the reported vulnerability signals remain^[39]. Analyzer silence is bounded evidence about those rules, not a general guarantee of functional preservation. Shen et al. complement this repair example with an empirical analysis of vulnerability patterns and mitigation trade-offs in agent applications^[38]. This approach highlights that reliability failures can involve deferred exploitability or risk-utility compromises that are not reducible to a binary pass/fail outcome.

Tool-integrated systems under adversarial attack form a distinct cluster, where correctness focuses on maintaining intended control over tool use despite adversarial instructions. InjecAgent formalizes indirect prompt injection as a structured evaluation, transforming control-flow hijacking and misalignment between user intent and tool actions into measurable failure modes^[35]. AgentHarm evaluates coherent multi-step completion of explicitly malicious tasks through synthetic tools and manually specified grading checks^[37]. MAESTRO combines instrumented runs with accuracy and resource measurements, call-graph stability analysis, and examination of gray failures^[36]. These observations distinguish execution behavior from endpoint judgments without supplying an oracle for every intermediate state.

AgentDojo complements tool-output injection tests with stateful environments in which tools read and modify simulated application state^[49]. Its task checks can inspect model outputs and environment states, while legitimate-task utility and attacker success remain separate outcomes. This distinction matters when a defense blocks attacks by also preventing authorized work. The resulting oracle is concrete but bounded by the encoded tasks and adversarial goals; stateful execution alone does not establish coverage of every policy violation.

Figure 3 uses an illustrative booking attempt to contrast two executable checks. The API reports success, but a query of the persisted calendar returns no matching event. A return-status check passes, whereas an event-existence check fails. The discrepancy reflects the properties and state each check examines; neither verdict establishes correctness beyond its coverage.

For analyzer-backed repair such as SecureFixAgent, the relevant question is which vulnerability properties its static checks cover^[39]. For InjecAgent and AgentHarm, it is whether the attack or harmfulness criterion covers the intended threat or policy and whether the relevant behavior is observable^[35,37]. Table 4 therefore records fidelity conditions rather than assigning a fixed strong/medium/weak grade from oracle type.

Ground-truth fidelity should also be distinguished from environmental realism and diagnostic resolution. A controlled environment may faithfully check a narrow invariant while representing only a small part of deployment. A rich trace may help localize deviations without supplying an authoritative correctness judgment. Conversely, a reliable terminal-state oracle may identify failure without revealing its cause. Evaluation reports should state these properties separately, alongside coverage limits, stopping rules, and replay conditions^[19,36].

Security-focused benchmarks assess adversarial outcomes and constraint adherence, which must be distinguished from legitimate-task success. InjecAgent measures attacker-desired deviations using parsed tool invocations and attack-success criteria in simulated tool-response interactions^[35]. We interpret this as evidence about instruction stability under that threat model, not as a general measure of policy compliance. In this survey, AgentHarm provides bounded evidence about harmful-task completion; its scores must be read against the encoded task criteria and synthetic tool surface^[37]. Shen et al. catalog vulnerability patterns as security debt and examine mitigation trade-offs, providing insight into how architectural choices accumulate risk even when task outcomes appear acceptable^[38]. SecureFixAgent provides repeatable static-analysis feedback, while weaknesses outside the analyzer’s rules may remain undetected^[39].

Comparability across benchmarks is challenging because definitions of success, tooling, stopping rules, and oracle strength differ across domains^[19,36]. SecureFixAgent illustrates the need to distinguish a clean static-analysis report from broader behavioral correctness^[39]. Comparisons must state which properties their repair oracle actually checks. InjecAgent operationalizes attack success in its specified tool-response injection setting^[35]. Comparisons with other settings should therefore preserve or explicitly vary the success criteria and stopping rules; this is a comparability requirement, not a result of an ablation reported by InjecAgent. MAESTRO highlights comparability issues related to multi-step scoring and run variance, where traces may enable diagnosis but scenario-level success remains sensitive to nondeterminism^[36]. Table 4 makes these differences explicit by recording each study’s domain, evaluation evidence, and validity limits.

AgentAuditor uses a training-free, memory-augmented LLM evaluator and introduces ASSEBench, whose annotated interaction records distinguish safety and security risks. Its strict and lenient labeling standards expose the effect of ambiguous risk definitions on evaluation. The oracle remains judgment-based: reported agreement with reference labels does not establish the correctness of every external action^[40].

LongMemEval provides a complementary state/memory evaluation: it distinguishes information extraction, multi-session and temporal reasoning, knowledge updates, and abstention^[50]. Its answer evaluator uses model judgments, while annotated evidence locations allow retrieval metrics when the system exposes retrieved records. This separates access to relevant history from the correctness of the final response. Its scope remains conversational memory, so these results do not directly establish transaction consistency or the correctness of external side effects.

Reliability conclusions for LLM-based agentic AI systems are fundamentally shaped by benchmark design, as datasets fix the interaction loop, oracle, and observable failures; thus, raw success rates are not directly comparable across evaluations.

Evaluation protocols for LLM agent frameworks require a full-stack specification that covers task design, execution, judgment, logging, and adjudication^[19,36]. This includes task suites and success criteria, run structure, stochasticity management, intervention and ablation designs, and logging procedures that support comparability and diagnosis across implementations. Such breadth is necessary because many recurring failures arise from architectural assumptions: control and state are mediated by language, while tools and environments introduce nondeterminism and hidden couplings. Mohammadi et al. emphasize that stochastic agents require repeated execution to assess consistency, and that such evaluation incurs additional cost^[19]. In this survey, we additionally recommend disclosing stopping rules, budgets, and trace coverage so that comparisons remain interpretable.

Run structure is particularly critical given the stochasticity and long-horizon operation of LLM-based agentic AI systems. Minor decoding variations can lead to divergent plans, tool calls, and memory updates, resulting in qualitatively distinct trajectories. Therefore, multi-run evaluation with explicit summaries of variability should be standard practice, moving beyond mean scores^[19,36]. Protocols must also specify aggregation methods, stopping rules, and resource budgets, such as time, tokens, or tool calls, and clarify whether strategies such as best-of-k or retries are part of the framework design or applied only during evaluation. Without these details, observed improvements may reflect protocol artifacts, such as prompt changes, wrapper updates, or environment snapshots, rather than genuine reliability gains.

Conversational benchmarks make repeated-run consistency and shared control explicit. In τ-bench, the terminal reward combines database-state and required-response checks, while pass^k estimates success on every one of k independent trials, unlike pass@k, which rewards at least one success^[51]. The authors note that a positive terminal reward can still miss acting without the required confirmation. τ²-bench adds a telecom domain in which both the agent and a simulated user change shared state; comparisons with no-user and oracle-plan conditions expose additional coordination and planning burdens^[52]. Such comparisons support diagnosis within the specified simulator and control allocation, and should be reported together with those conditions rather than treated as deployment-wide reliability estimates.

Overall task success often fails to reveal the root causes of reliability failures, making diagnosis-oriented ablations and controlled interventions indispensable. These approaches help distinguish architectural causes from incidental faults. MAESTRO evaluates multiple multi-agent systems under repeated runs and different model and tool configurations^[36]. Building on the architectural analysis here, we recommend targeted ablations of planning, memory, tool access, reflection, and safety components; this recommendation is not an ablation program reported by MAESTRO. Controlled interventions, such as tool failures or observation noise, can expose brittleness, but their effectiveness depends on protocols that prevent hidden retries, unreported fallbacks, or silent prompt and template changes. Without comprehensive logging, retries or silent failures may go undetected, masking true tool unreliability.

Comprehensive logging is essential for attribution because tool outputs, web content, and intermediate language states may become unrecoverable after a run^[9,36]. Cemri et al. link recurring multi-agent failures to cascading effects through message passing and shared state, underscoring that telemetry is vital not only for reproducibility but also for diagnosing architectural failure modes^[9]. A minimally sufficient trace should capture prompts, intermediate state representations, tool-call arguments and returns, retries and timeouts, environment observations, immutable run identifiers, and artifacts for replay. This is especially important in multi-agent settings, where coordination and message ordering influence subsequent actions. MAESTRO uses execution observability to examine call structures and errors^[36]. The trace contents recommended here extend that concern into a reporting proposal for this survey. Nevertheless, protocols must acknowledge a structural limitation: when relevant state is only implicitly embedded in language, some causal chains remain ambiguous, even with extensive logs.

For this survey, protocol validity is assessed along three distinctions. Internal validity concerns whether changes in outcomes can be attributed to the tested intervention when task information, nondeterminism, and reporting choices are controlled. Construct validity concerns whether the measured outcome represents the stated reliability requirement, including any process or tool-use constraints. Conclusion validity concerns whether the trials and comparisons support the reported inference. We therefore recommend disclosing exposed task information, trial selection, and multiple-comparison procedures rather than attributing a score change to architecture alone.

Even with strong internal validity, external validity remains challenging because system performance is tightly coupled to the tool ecosystem and scaffolding. Mohammadi et al. organize evaluation in terms of objectives and processes, including data, metric computation, tooling, and evaluation contexts^[19]. From this perspective, we argue that changes in tool interfaces or operating constraints should be treated as changes in the conditions of a reliability claim. Real-world deployment introduces longer horizons, noisier observations, and dynamic constraints, which can shift both optimal policies and failure patterns. Contamination further threatens representativeness: if benchmarks overlap with training data or prompts encode task-specific heuristics, scores may be artificially inflated. Protocols must therefore require explicit reporting of tool interfaces and dependencies, task sources, distribution-shift analyses, and contamination checks.

In adversarial settings, the language/tool interface itself becomes a threat channel, challenging the assumption that language-mediated state remains reliable under hostile inputs. InjecAgent evaluates indirect prompt injection through tool responses and compares attack success under base and enhanced attack prompts^[35]. This evaluation does not establish the effects of a systematic ablation of sanitization or permission defenses. Meaningful comparability requires precise reporting of attacker capabilities, tool permissions, and threat models. As a future evaluation recommendation, controlled ablations of tool permissions and filtering layers could test those defenses. Such studies should retain a common threat model and report variability across runs.

Safety and harm evaluations are similarly sensitive to protocol design because long-horizon tool use can magnify minor prompt or environment variations into harmful outcomes. AgentHarm separates task-specific harm scores from refusal measurements and includes benign counterparts to contextualize agent capabilities^[37]. Representativeness in this context depends on realistic scenarios, appropriate tool interfaces, and multi-run designs that capture stochasticity and nondeterministic tool behavior. AgentAuditor evaluates safe/unsafe judgments against annotated interaction records using accuracy and F1, with strict and lenient labels for ambiguous cases. These choices make evaluator agreement measurable while leaving the scope and interpretation of the reference labels as explicit validity conditions^[40].

In summary, evaluation protocols function as architectural specifications for reproducibility, causal attribution, and representativeness. Table 5 summarizes the key protocol dimensions, reporting requirements, and validity threats. At a minimum, reports should document: (i) run structure and budgets, including trial counts and variance summaries; (ii) stochasticity settings, including sampling parameters, seeds, caching or replay policies, and tool determinism; (iii) ablation and intervention designs with explicit confound controls; and (iv) trace artifacts that link outcomes to decisions, tool calls, and state snapshots. For adversarial and harm-focused benchmarks, protocols should additionally specify threat models, tool-surface assumptions, and the role of safety filters and permissions, since small changes in these factors can substantially affect reliability. Contamination checks should address overlap between training and evaluation data^[53]. Where model judges are used, evaluator biases and agreement with human judgments also require separate checks^[54]. The architectural protocol should additionally document any task-specific information exposed through scaffolds.

Reliable evaluation of LLM agent frameworks requires full-stack, variance-aware protocols with multi-run reporting, explicit budgets, controlled ablations, and comprehensive telemetry, alongside rigorous validity and contamination checks.

The mechanism taxonomy complements the architectural layers: families describe how an intervention works, layers describe where it acts, and interfaces describe what it observes and can change. These labels are not mutually exclusive. A specification-first action guard can also be rule-based; a structure-first trajectory monitor can use a learned detector; and a hybrid can combine several families. Table 6 connects these axes to the constructs and premises introduced earlier.

The six families below are a practical organization of the discussed mechanisms, not a disjoint partition or a ranking of effectiveness. For each family, we consider targeted failure modes, required artifacts, and assumptions about semantic fidelity, instruction stability, observability, and recoverability.

Heuristic and rule-based guards treat reliability as runtime governance over the action surface. SAGA controls inter-agent communication through user-defined contact policies and cryptographic access tokens^[30]. AgentSpec applies event-triggered runtime predicates, while AgentSentinel intercepts sensitive operations for context-aware security auditing^[29,55]. These methods expose policy rules, enforcement hooks, and audit logs at communication or execution boundaries. AgentSentinel additionally uses an LLM-based auditor, so its interception architecture also spans the hybrid category. AGENTSAFE extends this paradigm by framing failures as lapses in accountability and oversight rather than only model errors^[31]. Such methods are practical because tool interfaces and logs provide observable enforcement points, but they are limited when policy coverage is incomplete, harms arise through indirect or unlogged effects, or failures stem from latent state inconsistencies rather than overt violations^[38,55].

Structure-first approaches treat execution traces, graphs, or workflows as analyzable objects. SentinelAgent models multi-agent behavior as a relational graph and applies anomaly detection to expose coordination breakdowns or emergent misbehavior^[56]. Pathak et al. argue that many failures are visible only across trajectory segments, motivating trace-based analysis over time^[24]. Sherlock analyzes workflow graphs through fault injection to select vulnerable nodes for verification, then combines learned verifier selection with speculative execution and selective rollback^[57]. AgentFuzz uses directed greybox fuzzing, with semantic and control-flow-distance feedback, to exercise taint-style vulnerabilities in agent applications^[58]. These methods are strongest when traces are complete and semantically meaningful, but they weaken under partial observability or when important state is embedded only implicitly in language^[56,57].

Specification-first paradigms encode reliability as contracts, invariants, protocols, or information-flow constraints. Doshi et al.^[33] and Li et al.^[34] frame safe tool use as a property checked against explicit requirements, while SAFEFLOW combines trust-based information-flow controls with transactional logging and dependency-aware recovery. Information-flow control, as in Costa et al., constrains sensitive data propagation through prompts, memory, and tool I/O^[59]. These methods require richer artifacts, including formal specifications, pre/postconditions, flow labels, and protocol rules. Their strength depends on whether specifications capture real intent and tool effects; their limitation is that incomplete specifications can create apparently verified steps that still miss long-horizon drift or unmodeled side effects^[34].

CaMeL makes the authority boundary explicit: a privileged model constructs a plan from the trusted request, a quarantined model processes untrusted content, and an interpreter tracks capabilities and checks policies before tool calls^[60]. This design addresses control and data flow through executable restrictions rather than relying only on a model to reject malicious instructions. Its protection remains conditional on the trusted inputs, policy definitions, and tracked dependencies; the paper also discusses residual side channels.

Instruction-boundary defenses offer a complementary intervention before action selection. StruQ combines a frontend that separates instructions from data with structured instruction tuning^[61]. SecAlign instead uses preference optimization to favor legitimate-task responses over attacker-desired responses to injected inputs^[62]. Both modify how the model interprets untrusted content, whereas interpreter-based controls constrain the authority of the resulting computation. These defenses therefore differ in how they reinforce instruction stability and in the enforcement they provide: trained instruction adherence can improve empirical robustness, but does not itself constitute a runtime contract over tool effects. They are learned defenses, not necessarily learned risk monitors.

Tool-Guard addresses a different input surface: cross-tool description poisoning. It combines isolated planning over dynamically partitioned tool sets with LLM-based checks of task alignment and argument grounding. Failed validation updates the partition and triggers replanning, while tools remain usable within their partitions. This couples a change in planner-visible context to an execution gate, although the paper’s failure analysis shows that the semantic validator can also reject legitimate actions^[63].

Learned monitoring uses a trained or fitted model to estimate risk from prompts, states, tool arguments, or trajectories. Pathak et al. evaluate supervised XGBoost and one-class support vector data description detectors on agent trajectories^[24]. Sherlock uses a learned selector to choose verification strategies for workflow nodes, together with separate checking and rollback mechanisms^[57]. These examples separate the learned decision rule from the intervention that follows it: detection requires suitable training or calibration data, while prevention also requires an enforcement hook. Evaluation should report false alarms, missed failures, and behavior under distribution shift.

Language-native monitoring uses LLMs for self-critique, plan checking, and revision. DORA dynamically optimizes reflection prompts to address planning defects and weak self-correction over long trajectories^[64]. The effectiveness of self-critique depends on the relevant error being visible to the critic and on the corrective step being checked against an appropriate requirement. This approach is flexible and easy to integrate, but it can fail when execution errors are not visible in text, when feedback is incomplete, or when the action and critique processes share the same mistaken trajectory.

External feedback changes the basis of language-mediated correction. CRITIC iteratively checks and revises outputs using tools such as search and code execution^[65]; this supplies evidence beyond an unsupported self-assessment, although its oracle-assisted variant must be distinguished from ordinary operation. ExpeL extends feedback use across tasks by extracting natural-language guidance from successful and failed trajectories without updating model weights^[66]. Its HotpotQA ablation shows that adding reflections during insight extraction can reduce performance, with misleading reflections offered as an explanation. Together, these examples distinguish revising an output using fresh evidence from turning past outcomes into reusable guidance. Our architectural interpretation is that both require scrutiny of the feedback source and the correction interface; a successful local revision or reusable lesson does not establish safe recovery from every external side effect.

Hybrid approaches combine enforcement, trace analysis, learned signals, and reflective repair to reduce reliance on any single premise. SecureFixAgent grounds LLM-driven repair in vulnerability findings and iterates toward secure patches^[39]. Patel et al.’s Six Sigma Agent combines task decomposition, redundant micro-agent execution, and consensus voting; its reliability argument depends on the behavior and correlation of the sampled errors^[67]. In this survey’s analysis, combining mechanisms can close gaps while adding overhead and interfaces; components that share a blind spot may still fail together.

Planning methods further illustrate why mechanism families overlap. LLM+P translates a natural-language task into a Planning Domain Definition Language problem and delegates solving to a classical planner^[68]. This supplies a formal solving procedure, but its relevance to the user goal still depends on the supplied domain and the semantic fidelity of the translated problem. LATS combines tree search, environmental feedback, language-model evaluation, and reflection to explore alternative trajectories^[69]. Its search procedure requires additional computation and the ability to return to earlier environment states. Thus, formal solving and feedback-guided search address different uncertainties, while neither removes the need to validate the task representation or establish that repeated actions are recoverable.

The discussed mechanisms expose different intervention interfaces. AgentSpec checks event-triggered predicates, while SAFEFLOW combines information-flow rules with transactional state and recovery^[29,34]. Pathak et al.^[24] and Ro et al.^[57] score trajectory evidence, and Sherlock combines workflow analysis with verifier selection and rollback^[24,57]. Our synthesis therefore compares the artifacts exposed, the checks applied, and the authority to change execution, rather than assigning effectiveness from a mechanism-family label. For state consistency and long-horizon behavior, the relevant question is whether those interfaces expose the state and transitions needed by the requirement.

The six mechanism families are heuristic/rule-based, structure-first, specification-first, learned monitoring, language-native, and hybrid. Their protection depends on the evidence they observe, the actions they can constrain, and the state they can restore.

Pipeline placement describes where reliability or safety interventions act within an LLM agent framework. Table 7 maps representative studies and techniques to architectural layers and intervention timing. We map techniques to the five layers and also record whether they act before a subsequent decision or execution step. Pre-decision is a timing label, not a sixth architectural layer; subsequent placements identify the layer at which an intervention operates. Each placement offers different opportunities for observation and intervention. A pre-decision method can shape goals before planning begins, while an action/execution mechanism can block unsafe tool use before side effects occur. A governance mechanism can audit behavior across the system, but only if it has sufficient visibility and enforcement authority.

Pre-decision interventions can shape a subsequent planning or execution step. DORA dynamically generates reflection advice from earlier attempts using an auxiliary language model and Bayesian prompt optimization, addressing the early cessation of useful reflection^[64]. Decision/control techniques act during planning and policy selection. Shi et al.^[16] and Wang et al.^[29] show that prompt injection can manipulate tool choice at the moment of capability invocation, while AgentSpec constrains unsafe choices before they produce external side effects.

State/memory interventions address inconsistencies in retrieved context, intermediate representations, or shared state. This layer poses a distinct validation problem when state is implicit in language, and no authoritative state record is exposed. SAFEFLOW illustrates explicit execution-state recording and dependency-aware recovery within its modeled operations^[34].

Memory designs expose different state-maintenance operations. MemGPT uses function calls to move information between a bounded prompt and external storage, with memory-pressure signals and function chaining linking memory management to control flow^[70]. MemoryBank adds dialogue summaries and selective retention based on elapsed time and repeated recall^[71], whereas A-Mem constructs notes with structured attributes, links related records, and updates their contextual attributes^[72]. These designs make storage and retrieval mechanisms explicit. In our architectural analysis, their flexibility also motivates checking which observations justify an update and whether task-critical information survives summarization or forgetting; improved recall alone does not establish those properties.

Procedural memory connects past execution to future decisions. Agent Workflow Memory induces reusable routines from trajectories and supplies them as guidance for later actions; its online variant selects successful attempts through an evaluator before inducing workflows^[73]. This creates a feedback-to-memory-to-control path whose reliability depends on the evaluator and the applicability of the reused routine. We therefore distinguish learning a useful procedure from certifying that its preconditions hold in a new environment.

Action/execution interventions exploit tool calls as explicit boundaries for validation. Huang et al.^[13] diagnose tool invocation failures, Doshi et al.^[33] focus on verifiably safe tool use, SAFEFLOW introduces transactional execution, and AgentSentinel defends computer-use agents at the execution interface^[34,55].

Environment/feedback mechanisms operate after actions, using observed outcomes to detect failures and trigger recovery. Sherlock overlaps downstream execution with verification and rolls back affected computations when a verifier revises an earlier output^[57]. SentinelAgent applies graph-based anomaly detection to identify abnormal behavior during multi-agent operation^[56]. Governance and monitoring mechanisms impose system-level oversight through audits, policies, and lifecycle controls. SAGA provides security architecture and enforcement interfaces, Syros et al.^[30], Khan et al.^[31] and Costa et al.^[59] enforce information-flow constraints, and AGENTSAFE emphasizes ethical assurance and accountability^[30,31,59]. AgentSpec constrains planned actions through event-triggered checks and runtime interventions^[29]. Its hooks also cover state changes and task completion; this coverage does not establish the safety of future multi-step trajectories.

The examples above show why action/execution and governance/monitoring offer useful intervention boundaries: tool arguments, returns, and policy decisions can be exposed explicitly. State/memory consistency requires additional evidence about state provenance and freshness. This contrast concerns the requirements of the mechanisms, not a measured distribution of research across layers. Placement is therefore central to interpreting effectiveness: the same failure may originate as a control problem, manifest as unsafe tool use, and later appear as a feedback or monitoring failure.

Explicit action and governance interfaces make some violations directly checkable. State consistency needs its own evidence and controls; a mechanism at one layer does not automatically protect the others.

The interface determines which evidence a mechanism can inspect and which operation it can change. AgentSpec evaluates predicates at runtime events and invokes specified interventions^[29]. SAFEFLOW combines trust-based information-flow controls with transactional records and dependency-aware recovery^[34]. Figure 4 compares these designs by their observed artifacts, checks, and intervention authority. Checkpoint coverage bounds the first design; modeled operations and recoverable dependencies bound the second.

Integration roles cluster into three recurring patterns. Wrappers encapsulate LLM or tool calls, enabling prompt shaping, output validation, or action gating at decision boundaries. Middlewares mediate between control, state, and action modules, checking consistency as information moves across language and structured representations. Orchestrators manage multi-step loops or multi-agent coordination, often combining monitoring with control logic to pause, reroute, or override execution. These are integration patterns in our analysis rather than additional mechanism families.

In our interface analysis, portability and diagnostic coverage are conditional on the host framework. A wrapper needs access to the calls or trajectories it inspects and permission to alter the corresponding output or action. An asynchronous monitor can analyze exposed logs without blocking the current call, but timely intervention additionally requires an appropriate control hook. Enforcement needs an interpretable action or state representation and authority at the relevant boundary. An orchestrator can coordinate checks across steps only to the extent that it controls the event loop and observes the required state.

This interface analysis identifies conditions under which the mechanisms can fail even if their local checks operate as designed^{[29,34,57,59]}. Log-based monitors require complete and stable telemetry. Prompt rewriting assumes faithful trace capture and predictable model interpretation. Security interception requires the ability to observe and block actions before side effects occur. Specification enforcement presupposes shared schemas for intent, constraints, and tool behavior. Making these assumptions explicit clarifies why drift, undetected execution errors, and weak self-correction persist across diverse LLM agent frameworks.

Reliability mechanisms are shaped by their input/output interfaces and integration patterns. Their portability and effectiveness depend on which artifacts are observable, which interventions are enforceable, and where in the LLM-agent loop the mechanism attaches.

The cited work illustrates an expansion of architectural responsibilities, not a universal sequence in which one design replaces another. Reasoning-and-action loops connect decisions to external observations^[6]; tool-learning and application frameworks expose execution interfaces^[23,74]; memory-oriented designs maintain information across longer tasks^[7]; and runtime specifications introduce explicit enforcement points^[29]. These designs coexist and may be combined. Their relevance here is the additional reliability obligation created by each interface.

Coupling reasoning to action makes feedback interpretation part of correctness. An incorrect intermediate output can influence the next decision, and a malformed call or partial tool result can create a mismatch between the intended and actual state. Tool-use failure taxonomies provide a basis for separating selection, invocation, and execution problems rather than treating all of them as answer errors^[13,26]. In this setting, final-output inspection alone cannot determine which transition broke down.

Persistent or shared state extends the lifetime and reach of such mismatches. Memory management makes earlier observations available to later decisions, while multi-agent coordination creates additional paths through which inconsistent beliefs can affect task progress^[7,9]. Runtime monitoring and transactional execution offer ways to check or control selected transitions^[29,34]. Their architectural value depends on whether the relevant state is exposed and whether their intervention occurs before an irreversible effect.

This comparison motivates a shift in the analysis from prompt-local correctness to cross-layer obligations. It does not establish how frequently each design occurs or whether later systems are more reliable. The chains in Section “Representative cross-layer failure chains” explain how the same premises of semantic fidelity, instruction stability, observability, and recoverability remain relevant as responsibilities are distributed across more components.

Adding memory, tools, or monitoring creates new obligations at component interfaces. Architectural reliability depends on whether those obligations are checked across the loop, not on the number or apparent sophistication of its components.

Evaluation methods for LLM agent frameworks include endpoint judgments, executable checks, trace diagnostics, and operational telemetry. These differences are central to reliability analysis because evaluation protocols determine which aspects of decision-making, state propagation, and action execution become observable. A protocol defines task specifications, success criteria, interaction structure, oracles, metrics, and reporting artifacts, such as traces, logs, seeds, and environment versions. Failures that do not change the judged endpoint require evidence beyond that endpoint for detection and diagnosis.

Mohammadi et al. organize agent evaluation along two dimensions: evaluation objectives, including reliability and safety, and evaluation processes, including interaction, data, computation, tooling, and context^[19]. This aligns with an architectural perspective: once systems interact with tools, memory, and environments, evaluation must expose intermediate steps to support meaningful reliability claims.

Endpoint judgments differ in their procedures. GAIA scores concise final answers by normalized matching^[47]. LLM-as-judge research examines automated assessments, their agreement with human judgments, and judgment biases^[54]. In our architectural analysis, a terminal judgment alone cannot identify an intermediate failure that leaves the judged endpoint unchanged; diagnosis requires additional evidence about the trajectory.

Executable evaluations check specified outputs or states: OSWorld uses task-specific evaluation scripts, and SWE-bench runs tests on proposed repository patches^[44,45]. Controlled environments and checks can support repetition, while the validity of a verdict remains bounded by its requirements and coverage. Process-aware analyses expose different evidence: MAESTRO compares execution call graphs, and Cemri et al.^[9] and Ma et al.^[36] categorize failures in annotated multi-agent traces. In our synthesis, these records can help locate candidate deviations, but causal attribution still requires suitable controls.

Operational telemetry extends observation across runs. MAESTRO illustrates instrumented repeated-run analysis through execution traces, resource measurements, and call-graph comparisons^[36]. In our synthesis, extending such observations across runs can expose deviations beyond those represented by a single endpoint score. Mohammadi et al. discuss trade-offs between realistic and controlled evaluation contexts, together with the cost of repeated assessment^[19]. For telemetry-based studies, this survey further recommends reporting which traces and environment states are retained, because these choices determine what can be inspected or replayed. Across these examples, our synthesis distinguishes the evidence exposed, the judgment procedure, the conditions needed for repetition, and the cost of assessment. These considerations motivate combining executable checks, traces, and monitoring with endpoint scoring. The categories coexist; they are not stages that every evaluation follows.

The approaches in Figure 5 answer different questions about the same execution. An endpoint judgment establishes the assessed outcome, an executable check tests specified states or effects, and a trace links intermediate events. Operational telemetry extends observation across repeated runs. Their combination is useful when the records can be connected to the same requirement and execution; otherwise, additional observations may still leave the origin of a failure unresolved.

Executable, trace-based, and telemetry-supported assessments expose different aspects of architectural reliability. They complement endpoint scoring while introducing distinct costs and limits on reproducibility.

Mitigation strategies for LLM-agent reliability have expanded from model-guided reasoning patterns to explicit system-level controls. Early agent designs coupled reasoning with actions or verbal feedback, while autonomous-agent prototypes used task lists and iterative loops^[6,21,22,75]. These works established influential control patterns, but they did not provide general guarantees of consistency across extended trajectories.

Tool-learning methods, application frameworks, and interactive environments make different parts of the interaction interface explicit. Toolformer studies learned tool invocation, LangChain exposes composable application components, and WebArena supplies an executable web environment for evaluating autonomous agents^[8,23,74]. These contributions improve the structure and testability of agent interactions, although they do not by themselves provide rollback or continuous runtime observability.

Recent strategies introduce dedicated monitoring, runtime enforcement, transactional execution, and graph-based anomaly analysis^[29,34,56]. These mechanisms target failures that are not visible from final outcomes alone, including policy violations, execution faults, state drift, and anomalous multi-agent behavior. Together, these mechanisms motivate a systems-level reliability perspective: mechanisms must coordinate across decision, execution, feedback, and monitoring layers rather than operate as isolated fixes.

Figure 6 compares the six nonexclusive mechanism families by possible placement, observed artifacts, intervention authority, and remaining limitations. This comparison highlights the architectural obligations mitigation introduces. Prompt-level fixes remain useful, but they are insufficient for persistent systems whose failures propagate across modules and time. Protocol safeguards improve interface clarity, while layered runtime mechanisms add observability and enforcement. The central design challenge is balancing reliability coverage against complexity, overhead, and new interface risks.

Prompt-level techniques, protocol safeguards, and runtime controls protect different parts of the agent loop. Combining them requires explicit assumptions about contracts, visibility, and intervention authority.

The preceding analysis supports four bounded findings. They summarize relationships among the reviewed concepts and examples, not pooled effect sizes, causal estimates, or claims about the prevalence of a mechanism family.

F1: reliability is conditional on an operational requirement and boundary. Sections “FAILURE MODES AND RELIABILITY CONSTRUCTS IN LLM AGENT FRAMEWORKS” and “Benchmarks, datasets, and gold standards for reliability analysis” show why task completion, policy conformance, state consistency, and recoverability cannot be substituted for one another. A reliability claim needs an explicit requirement, operating conditions, and an oracle with stated coverage. This explains why the same final outcome can receive different valid assessments under different constructs.

F2: fault origin, visible symptom, and intervention point can differ. The cross-layer chains in Section “Representative cross-layer failure chains” connect memory, control, execution, feedback, and oversight. They show why locating an error at the tool boundary does not establish that the tool caused it, and why repairing the last visible symptom may leave corrupted state intact. Diagnosis therefore needs linked evidence across transitions, followed by interventions evaluated at both the local boundary and the downstream state.

F3: a mechanism’s protection is bounded by what it can observe and enforce. Sections “Architectural premises and failure propagation” and “RELIABILITY MECHANISMS AND THEIR INTERFACES” connect mechanism families to artifacts, placement, and authority. A specification without an enforcement hook cannot block an action; a monitor without relevant state cannot validate it. Combining mechanisms expands protection only where their interfaces close an identifiable gap, and may leave shared blind spots intact.

F4: successful recovery and low fault incidence are different achievements. Sections “Reliability metrics and operational definitions” and “Representative cross-layer failure chains” show how retries or compensation can produce an acceptable endpoint after earlier failures. Evaluation must record the original deviation, whether it was detected, and whether the correction restored the required state within budget. Otherwise, an outcome gain cannot establish either fewer initial faults or safer recovery.

Outcome-only evaluation limits architectural diagnosis. Outcome-based evaluations provide limited insight into the architectural causes of reliability failures in LLM-based agentic AI systems. A final success score does not by itself identify which architectural layer originated a deviation, and it can leave execution problems outside the endpoint criterion unresolved. As illustrated in Section “FAILURE MODES AND RELIABILITY CONSTRUCTS”, a system may confirm a booking even though no corresponding calendar event exists. A terminal-state check can expose the missing event, while linked tool and state traces are needed to identify the failed transition. This limitation is amplified in long-running settings, where errors may persist as hidden state inconsistencies or uncorrected execution faults. The distinctions in Section “FAILURE MODES AND RELIABILITY CONSTRUCTS” motivate checking state, intent, and recovery explicitly rather than inferring their validity from fluent output.

Missing boundary conditions undermine comparability. The reviewed protocols differ in conditions that affect interpretation: ToolLLM evaluation depends on live API behavior and, in some settings, oracle-retriever access, while τ-bench specifies a simulated user, task policy, and terminal reward^[41,51]. These examples motivate comparing claims under explicitly stated operating conditions. The contrasting evidence types in Section “FAILURE MODES AND RELIABILITY CONSTRUCTS” show why these conditions must be stated before architectural weaknesses can be separated from differences in experimental setup. As LLM-based agentic AI systems become more integrated and long-running, reliability increasingly depends on whether the underlying framework can preserve control and state across extended interactions and recover from silent faults. Without explicit boundary conditions, reliability claims may be incomparable across studies and difficult to reproduce, especially when systems differ in tool permissions, feedback channels, or termination criteria.

Stochasticity and confounding require multi-run and interventionist evaluation. Repeated-run evaluation in MAESTRO examines variation in observed agent executions, and τ-bench measures success across multiple independent trials^[36,51]. These designs motivate reporting variability when model sampling or external interactions can change a run. Reliable evaluation therefore requires multi-run reporting with variance or confidence summaries, rather than single-run or mean-only results, as discussed in Section “Protocol design, representativeness, and validity threats”. Causal attribution also requires targeted ablations and controlled interventions. Otherwise, disabling a component may inadvertently change context length, tool availability, retry behavior, or prompt structure, leading to misleading conclusions. Section “Evaluation evidence and diagnostic coverage” further distinguishes realistic evaluation from controlled assessment and recommends disclosing which traces and environment states are retained for inspection or replay. These factors make it essential to distinguish systematic failures from stochastic variation and protocol artifacts.

Tool ecosystems create silent execution errors and architectural mismatch. Tool-use studies distinguish failures in selection, invocation, execution, and returned results^[13,26]. In our architectural analysis, a fluent summary cannot by itself establish that the corresponding external action completed correctly. For example, a system retrieving real-time data may receive an empty API response yet still generate a plausible but incorrect summary. As illustrated by the propagation analysis in Section “Architectural Interfaces and Failure Propagation”, a tool-result mismatch can affect later state or planning before it is detected. This challenge reflects a broader architectural mismatch: language-mediated control is flexible, but reliable tool execution requires precise schemas, complete telemetry, and enforceable interfaces. Section “Inputs, outputs, and integration patterns” shows that log-based monitoring, prompt rewriting, and specification enforcement each depend on different assumptions about observability and control. When traces are incomplete or schemas are unstable, these mechanisms may fail to detect or correct execution errors.

The four findings identify corresponding evaluation targets: explicit operating conditions, linked failure traces, enforceable state and action contracts, and recovery measures that preserve the history of faults. Table 8 maps these targets to proposed studies and evaluation criteria.

Specify the conditions of a reliability claim (F1). The gap identified in Sections “Benchmarks, datasets, and gold standards for reliability analysis” and “Protocol design, representativeness, and validity threats” is that a score can be reproduced without measuring the intended requirement, or can measure a useful requirement under incomparable conditions. A minimal scenario card should identify the task, construct, threat model, autonomy, permissions, horizon, stopping criteria, budget, and oracle coverage. Executable protocol specifications can then make those conditions inspectable. A useful test is whether independent implementations reproduce the same bounded claim and whether changing one declared condition produces an interpretable difference.

Link observations across the propagation path (F2). The chains in Section “Representative cross-layer failure chains” expose an attribution gap between a visible error and its originating transition. Future benchmarks should combine correlated tool events and state snapshots with controlled perturbations such as stale memories, ambiguous acknowledgments, and untrusted feedback. Evaluations should test whether the monitor detects the deviation, identifies the affected transition, and verifies downstream repair. Injected faults provide a known intervention point, but cannot by themselves establish that natural deployment failures have the same distribution. An interaction-centric AIoT perspective similarly motivates checking observed responses and state transitions against specification-derived semantics, while treating physical context as a separate validation concern^[76].

Make state and enforcement contracts explicit (F3). The interface analysis in Section “Inputs, outputs, and integration patterns” shows that a mechanism cannot protect state or actions that it neither sees nor controls. State schemas, provenance records, version checks, and explicit action permissions are therefore concrete research targets. Comparing the same mechanism across interfaces with different visibility and authority would test which assumptions are essential for its protection. Reporting false blocks and integration cost alongside prevented violations is necessary to assess whether greater control remains usable. Related networking work makes these interface requirements concrete through user digital twins with customizable data schemas, attribute-specific updates, and physical-device feedback for network resource management^[77]. TrustTwin provides a complementary AIoT example by comparing specification-guided predictions with executable-twin outcomes before committing candidate actions to physical devices^[78], while a digital-twin framework for autonomous robots similarly demonstrates how runtime monitors can continuously check action consistency and enforce safety and performance properties before actuation^[79].

Evaluate recovery without erasing the original fault (F4). The measurement gap in Section “Reliability metrics and operational definitions” is the conflation of final success with low failure incidence. Recovery studies should preserve records of initial faults and separately measure detection, restoration of required state, duplicate or irreversible side effects, and resource cost. Controlled timeout and partial-execution scenarios can test whether retries are safe. Where the environment does not support rollback or idempotency, escalation and bounded abandonment should be evaluated as legitimate outcomes rather than forced into a retry-success metric. Recent recoverable execution frameworks highlight the value of coordinated checkpoint-restore mechanisms for long-horizon agents^[80], whereas work on semantic rollback vulnerabilities emphasize that naive retries can inadvertently duplicate external side effects when exactly-once or retry-deduplication guarantees are not enforced at the tool boundary^[81]. The research agenda follows four gaps: specify the claim, trace propagation, expose enforceable interfaces, and account for recovery separately from incidence. Each direction requires evidence at the relevant state or action boundary as well as at the final outcome.

Selection, source status, and interpretation. The architectural synthesis supports comparisons of requirements and mechanisms, while its generalizability depends on the breadth and quality of the selected evidence. The analysis draws on studies of architectural failures, evaluation evidence, and interventions. Preprints, conceptual proposals, documentation, and empirical studies provide different kinds of support. Incomplete descriptions can leave publication status, implementation details, or evaluation conditions unresolved. Layer assignments and the representative failure chains are interpretive analyses, and the latter require empirical testing before supporting causal or frequency claims. These limitations constrain generalization of the four findings and preclude an effectiveness ranking across mechanism families.

Ambiguity in the construct of reliability. A central threat to this survey is the variation in how prior work defines and operationalizes “reliability.” Some studies emphasize task completion, while others focus on policy compliance, tool-use safety, state consistency, recoverability, or governance. As discussed in Section “FAILURE MODES AND RELIABILITY CONSTRUCTS”, these constructs imply different assumptions about the consistency and verifiability of system state, control, and feedback. This ambiguity makes synthesis difficult: reported improvements may not refer to the same underlying reliability property, and cross-study comparisons may overgeneralize beyond the measured construct.

Internal validity risks from hidden oracles and contamination. Training-evaluation contamination is an established concern in language-model evaluation^[53]. In this survey, we additionally treat undeclared task-specific information exposed through prompts, tool outputs, documentation, or scaffolds as a potential confound. Section “Protocol design, representativeness, and validity threats” recommends disclosing those information channels so that a reported score can be interpreted under its actual conditions. Uncontrolled nondeterminism and selective reporting further complicate attribution. As a result, apparent reliability gains may reflect evaluation artifacts rather than substantive architectural improvements.

Outcome metrics masking architectural violations. Outcome metrics can overstate reliability when recovery mechanisms conceal upstream failures. A system may achieve high task success while repeatedly violating assumptions about control, state consistency, or tool execution. Section “Reliability metrics and operational definitions” shows that robust recovery, retries, or consensus can improve final scores without reducing the true incidence of faults. This creates a synthesis risk: techniques that improve apparent outcomes may be favored even if they leave the underlying framework brittle or shift failures into less observable layers.

Ground truth and replayability constraints in long-running systems. Ground-truth fidelity in long-running systems depends on oracle coverage, judgment validity, and access to the state being assessed. As discussed in Section “Evaluation evidence and diagnostic coverage”, the retained traces and environment states determine which claims can be inspected or replayed, affecting how architectural failures are separated from evaluator variance or changing deployment conditions. Evaluations that better match the target deployment may strengthen external validity, while causal interpretation remains limited when runs cannot be replayed, instrumented, or compared under controlled conditions.