TLDR
The strongest rival: fewer paths are safer
Executive briefThe page stayed green while the decision contract failed
- Graceful degradation preserves named business and safety invariants while deliberately removing scope, authority, freshness, speed or automation.
- A seven-field Degradation Contract defines the promise, invariants, signals, mode ladder, mode limits, transition evidence and recovery proof before failure.
- Five governed modes move from full service through bounded, advisory and continuity operation to safe unavailability.
- A fallback earns use through control equivalence, while a timed-out side effect is verified externally before any retry.
- Recovery begins with a bounded cohort, reconciled state and proved controls, then expands traffic while retaining a fast return to safety.
A claims assistant lost access to its policy service during a morning peak. The application remained available, the model kept producing plausible decisions and the operations dashboard stayed green. To reduce latency, the workflow skipped the unavailable policy check and used a cached entitlement result. It approved a case whose consent had changed overnight. Nothing crashed. The service had failed at the exact point that mattered: its authority and evidence contract.
Availability is only one property of an AI capability. A response can be fast and syntactically valid while using stale facts, weaker privacy controls, an unapproved provider, broader tool permissions or a human queue too overloaded to inspect decisions. The system is responsive but the business service is no longer the service its owners authorised. Calling that state graceful converts hidden control loss into a reliability feature.
Graceful degradation means preserving named invariants while deliberately reducing what the capability may do. It can narrow the eligible population, remove write authority, lower throughput, require fresher evidence, expose uncertainty, route to a deterministic process, queue work or become explicitly unavailable. The order is a business decision made before pressure arrives. The safest state for one feature may be bounded automation; for another, advice only; for a third, a controlled manual path; and for a high-consequence action, safe stop.
This is the boundary of Paper 119. Paper 100 addresses long-term exit from a model or provider. Paper 118 commands an active incident whose effects may still be propagating. Paper 119 pre-engineers expected dependency and capacity failures so that a capability has rehearsed operating modes before an incident. Paper 126 will govern service objectives for probabilistic systems. Here, the question is narrower: when a model, retrieval source, policy service, tool, person or region fails, what remains permitted?
Fallbacks add code, credentials, data routes and human handoffs. Rare paths can be less reliable than the failed primary path. AWS warns that distributed fallbacks are difficult to test under their unusual activation conditions. Use the smallest set of modes the business can rehearse. If no simple substitute preserves the invariants, explicit unavailability is the controlled outcome.
Original synthesisSeven fields form the Degradation Contract
The contract is a release artefact owned jointly by the business capability owner and its engineering and risk partners. It describes the whole service rather than one endpoint. It is versioned with the model, prompts, policies, retrieval corpus, tools, providers, human operation and continuity procedures. A change to any of those can invalidate a fallback even when its API remains compatible.
1. Capability promise
Name the business outcome, eligible population, service window, decision and external action normally delivered. Separate information, recommendation, preparation, approval and commitment. A promise such as “claims assistant” is too broad to determine which function can survive a failure.
2. Non-negotiable invariants
List authority, legal, safety, privacy, financial, evidence, fairness, customer, geographic and reversibility conditions that every allowed mode must preserve. Write them as observable constraints. “Remain compliant” is weak; “no payment without current beneficiary verification and independent approval” can govern a transition.
3. Failure signals
Define model unavailability or uncertainty, rate limits, tool timeout, ambiguous commitment, stale retrieval, schema drift, policy-service failure, queue pressure, reviewer-capacity loss and provider or region events. Record signal source, confidence, persistence, scope and consequence rather than treating every error as equivalent.
4. Mode ladder
Select the smallest rehearsable sequence from full operation to bounded automation, advice only, deterministic or manual continuity, queued or diverted work and safe unavailability. Not every capability needs every rung. Mode order follows consequence and preserved invariants, not the desire to remain online.
5. Mode contract
For each rung, declare allowed populations, decisions, tools, data age, authority, limits, throughput, disclosures, controls, owner and expiry. State removed functionality prominently. Users must not mistake a lower-evidence answer or non-binding recommendation for normal service.
6. Transition evidence
Bind the observed trigger, hysteresis, approval, notification, state snapshot, in-flight handling and audit record to the transition. Hysteresis avoids rapid oscillation around a threshold. A named owner can override only within documented authority, expiry and consequence bounds.
7. Recovery proof
Require dependency health, reconciled external state, warmed capacity, causal and neighbouring regression, a controlled cohort, traffic stages, reversal triggers and accountable acceptance. A green provider dashboard is an input, not permission to restore the whole capability.
| Field | Release evidence | Reject the contract when |
|---|---|---|
| Promise and invariants | Named outcome, action, population and observable constraints | Availability or accuracy silently outranks safety, rights or authority |
| Signals and modes | Typed failure conditions, persistence, scope and guarded transitions | A generic error sends every capability to the same fallback |
| Mode contract | Population, authority, data age, controls, throughput and expiry | The mode says “limited” without measurable limits |
| Transition evidence | Trigger, snapshot, approval, in-flight disposition and disclosure | Operators cannot reconstruct why or when the mode changed |
| Recovery proof | Reconciliation, regression, cohort, ramp, reversal and acceptance | All traffic returns because one dependency became green |
Capability Degradation State MachineFive governed modes remove power in a deliberate order
The state machine makes degraded behaviour visible and reviewable. Transitions are guarded by evidence from the contract. A system may move more than one rung when consequence demands it. It may also remain in a lower mode after the immediate dependency recovers because queues, reviewer capacity or external effects are not yet reconciled.
Full
Normal scoped automation operates with all required dependencies, current evidence and control telemetry healthy. “Full” is still bounded by the authorised population, transaction limits and release envelope. It is not unlimited autonomy. Reinforced monitoring can keep this mode active through a weak, non-material signal only when the invariants and dependency evidence remain intact.
Bounded
Automation continues for a reduced population, authority, tool set, spend, rate, geography or feature set. The same invariants apply. A smaller model might answer low-consequence informational questions while high-consequence decisions queue. Load shedding can protect healthy dependencies by admitting named critical classes and dropping or deferring others early.
Advisory
AI may analyse evidence or recommend, but an accountable person makes and records the decision or action. Human involvement is meaningful only when the reviewer sees the necessary evidence, understands uncertainty, has time and authority to change the outcome, and leaves a decision receipt. A saturated approval queue is not advisory control.
Continuity
Deterministic rules, a tested manual process, queued work or an alternate channel preserves an essential service. This mode can be slower and narrower. It specifies capacity, priority, ageing, evidence, privacy, segregation, communications and the point at which the queue must stop accepting work. Manual does not mean uncontrolled.
Safe stop
The capability becomes unavailable because no remaining mode preserves its invariants. The interface explains what is suspended, what users should do, whether work was accepted and when another decision will be made. Safe stop protects pending cases and external state; it does not delete queues or imply that attempted actions failed.
| Mode | Authority and population | Required proof | Exit trigger |
|---|---|---|---|
| Full | Normal authorised envelope | All mandatory dependencies and evidence healthy | Material signal crosses a declared guard |
| Bounded | Named cohort, lower limits or fewer tools | Fallback equivalence for that reduced contract | Invariant gap, capacity breach, expiry or proved recovery |
| Advisory | AI has no commitment authority; capable humans act | Inspectability, reviewer capacity and decision receipt | Human load, missing evidence or restored controlled automation |
| Continuity | Deterministic, manual, queued or alternate route | Essential controls, capacity, communications and ageing rules | Queue ceiling, control loss, expiry or recovery cohort |
| Safe stop | No new capability action | Protected state, clear disclosure and owned next decision | Another mode proves every invariant |
Fallback Equivalence TestAPI compatibility does not prove a substitute is safe
A fallback earns a specific mode, not universal approval. Compare its identity, policy, data rights, context, semantics, evidence, latency, capacity, geography, limits and recovery behaviour with the requirements of that mode. The test applies to a smaller model, alternate provider, tool replica, cache, deterministic rule and human process. Equality of output schema answers only the easiest part.
Identity asks who the fallback acts as, which principal and purpose it represents, where credentials originate and whether receiving resources enforce the same limits. Policy asks whether current business rules and separation survive. Data rights cover permitted sources, retention, training use, cross-border processing and downstream disclosure. Context includes the case history and facts required to interpret a request. Semantics asks whether units, fields, tool methods, status codes and failure states mean the same thing. Evidence asks whether the fallback produces decision and effect receipts suitable for challenge and reconstruction.
Latency and capacity are control properties when deadlines or reviewer attention determine safety. Geography and commercial terms can make a technically strong provider inadmissible. Limits must be enforced at the receiving resource, not merely described in a prompt. Recovery covers how the fallback drains, reconciles or hands back state. A substitute may pass for low-consequence advice and fail for a payment commitment. That is a useful result, not an incomplete test.
Cache equivalence is especially narrow. A cached answer needs an origin, policy and entitlement version, affected subject, freshness window, invalidation signal and supersession rule. Age alone is insufficient because consent or account state can change immediately. Human equivalence also needs discipline: trained role, evidence access, decision time, authority, capacity, separation and audit. A person shown only the model's recommendation cannot repair missing source evidence.
| Dimension | Question for the proposed mode | Typical disqualifier |
|---|---|---|
| Identity and authority | Does the substitute use the same or narrower principal, purpose and resource rights? | Shared provider key or broader manual permission |
| Policy and rights | Are current rules, consent, entitlements and data terms enforced? | Cached policy or cross-region provider without approved terms |
| Context and semantics | Does it receive enough valid context and interpret fields and states identically? | Compatible JSON with different status or unit meaning |
| Evidence and effects | Can it produce decision, attempt and destination receipts? | Human spreadsheet or tool fallback with no stable action identity |
| Latency and capacity | Can it meet the consequence window for the allowed population? | Approval queue makes review ceremonial |
| Geography and recovery | Does location comply, and can state return without loss or duplication? | Unapproved processing region or no hand-back reconciliation |
Ambiguous-Effect GateA timeout is uncertainty, not permission to repeat
Side-effecting tools can fail non-atomically. A payment request leaves the agent, the bank commits it and the response is lost. The client sees a timeout, yet the external state has changed. A blind retry can duplicate the effect. Recent research on verified tool calls models timeout after dispatch, delayed visibility, partial effects and stale conflicts, reinforcing a long-standing distributed-systems rule: make operations idempotent where possible and verify postconditions where ambiguity remains.
The gate first assigns stable business, action and attempt identifiers. Before dispatch, it reserves the operation against a business key and records expected postconditions. After an error, it asks the receiving system whether the effect committed, using an independent query where available. If the effect is observed, the action proceeds to consequence handling. If the receiver proves no commitment, a bounded retry can use the same idempotency key. If state remains unknown, the case moves to reconciliation and automation must not guess.
Idempotency is necessary but scoped. The key must bind the business effect and survive every retry layer. A gateway key does not help if a provider generates a new transaction downstream. Some actions cannot be made naturally idempotent, including messages to people or physical movement. They require observation, deduplication, compensation or human authority. Compensation is a new governed action, not reversal by arithmetic. It can fail, create another effect or harm a person who already relied on the original action.
The gate also governs recovery. A tool dashboard becoming healthy does not resolve old timeouts. The pre-failure action population is frozen, queried and brought to observed, cancelled, completed, compensated or explicitly disputed states. New traffic uses separate identifiers and capacity. This differs from Paper 118's incident-wide ledger: here the mechanism is engineered into the expected failure path before an incident begins.
Load, queues and retriesProtect healthy dependencies from the failure response
Failures often become outages through amplification. A rate-limited model slows requests; callers retry; queues lengthen; workers hold connections; reviewers receive bursts; healthy retrieval and policy services are saturated by work that can no longer finish. Each local component may be following its retry policy while the capability consumes more capacity and loses control.
Retry ownership should be singular and visible. Limit attempts, use exponential backoff with jitter, cap the total retry budget and honour consequence deadlines. A request that will expire before its next safe attempt should queue for an alternate route or fail explicitly. Layered retries can multiply load, so the contract names which layer retries and which returns an actionable state. Side effects additionally pass the Ambiguous-Effect Gate.
Load shedding is a business allocation. Admit requests by named population, consequence window, cost and feasible mode. Reject or defer excess work early enough to protect the healthy path. Do not use an opaque priority score that conceals who loses service. Essential cases may retain deterministic service while low-consequence enrichment disappears. A queue needs acceptance ceiling, ageing limit, customer communication, cancellation, deduplication, privacy and a plan for work that will become invalid before execution.
Reviewer capacity is measured in meaningful decisions, not people logged in. Complexity, evidence volume, cognitive load, breaks, escalation and error feedback affect capacity. When waiting time leaves no opportunity to inspect or correct an outcome, “human in the loop” has ceased to be a control. The state machine moves to narrower advisory work, deterministic continuity, a queue or safe stop.
Rare modes are production paths. Exercise them under realistic overload, partial errors, rate limits, schema changes, stale evidence and missing humans. Include the return transition. A fallback that activates successfully but cannot hand back queued and in-flight state is unfinished. Observability must distinguish response availability from invariant status, population served, authority retained, evidence age, queue harm and external effect.
Mode governanceMake population, removed function and expiry visible
Each mode is a complete operating contract, not a feature flag. It names the owner on duty, eligible population, accepted decisions, external actions, tools, data sources, evidence age, transaction and rate limits, throughput, user disclosure, monitoring and expiry. It also states what has been removed. A user seeing an answer from a smaller model must know if it is informational and cannot be relied on for a commitment. An operator seeing a queued case must know whether any action was already attempted.
Invariants remain fixed across modes, but their implementation can change. In full mode, a policy service may enforce entitlement automatically. In advisory mode, an authorised reviewer may resolve the same current policy from a controlled source. In continuity mode, a deterministic rule may accept only cases that do not require discretionary policy. If no alternate mechanism enforces the invariant, the action is removed rather than weakened.
Expiry prevents a degraded mode becoming normal through inertia. The timer is based on risk and operational capacity, not a generic duration. At expiry, the owner must renew within current evidence, move lower, or recover through the ramp. Any change in invariant, population, fallback evidence or queue condition can trigger an earlier decision. Silent persistence is prohibited.
| Record | Minimum content | Why it matters |
|---|---|---|
| Trigger | Signal, source, confidence, scope, first observation and threshold | Separates weak noise from a material operating condition |
| Mode decision | Old mode, new mode, owner, allowed cohort, removed functions and rationale | Makes lost capability and retained authority inspectable |
| State handling | Snapshot, queues, in-flight actions, ambiguous effects and reconciliation owner | Prevents duplicates, omissions and unsafe hand-back |
| Communication | User disclosure, operational notice, provider instruction and next update | Limits false reliance and coordinates capacity |
| Expiry and return | Review time, proof required, recovery cohort, expansion gates and reversal signal | Stops degraded operation from becoming permanent by accident |
Eleven worked casesPreserve the invariant, then choose the smallest safe service
1. Primary model rate-limited at peak demand
A smaller model is available but passes the Fallback Equivalence Test only for low-consequence informational responses. The invariant is that no fallback can approve or commit a customer decision. The capability moves to Bounded: named advisory populations use the smaller model with reduced context and visible disclosure, while consequential cases queue. Retry budgets and admission controls protect retrieval and policy services. Recovery warms the primary model with a cohort and checks output, latency and decision evidence before expansion. Outcome: route to a bounded fallback model or tool.
2. Payment tool times out after dispatch
The threatened invariant is one authorised payment per business obligation. A timeout is an ambiguous effect, so the workflow stops that case, retains the original idempotency key and queries the receiving ledger. It does not retry through an alternate provider. Other payment work may continue only if the failure is isolated and capacity remains. If the postcondition cannot be established before settlement, the case goes to controlled reconciliation and the action capability fails closed for that cohort. Recovery requires every uncertain attempt to reach a governed state. Outcome: fail closed and suspend the capability.
3. Retrieval works but the evidence is stale
The decision requires policy effective on the day of action. Retrieval responds normally, but its corpus checkpoint exceeds the allowed evidence window. Availability is irrelevant. The state machine removes AI decision authority and routes eligible cases to a deterministic rule backed by a current canonical table; exceptions enter a trained manual queue. Cached answers fail equivalence because supersession is unknown. Recovery rebuilds the index, verifies effective dates and tests a bounded case cohort against source records. Outcome: queue or divert work to deterministic or manual continuity.
4. Policy service unavailable
The model, retrieval and action tool are healthy, yet the service that resolves current authority is unavailable. The invariant is that every action must pass current policy with a recorded decision. A prompt copy or yesterday's allow result is not equivalent. Informational analysis can remain advisory if it exposes no protected data; commitment authority stops. If no accountable reviewer can resolve current policy from an approved source, the affected capability is unavailable. Recovery tests deny, exception and changed-entitlement cases before traffic returns. Outcome: fail closed and suspend the capability.
5. Compatible provider violates residency and logging
An alternate model accepts the same API and meets latency, but processes data outside the approved geography and cannot supply required decision logs. Rights, location and evidence invariants fail. The fallback is rejected even during outage. Low-sensitivity public information may use a separately approved route if its contract is distinct; customer data and decisions stop. This is the negative control: explicit unavailability creates less risk than responsive processing outside the authorised boundary. Outcome: fail closed and suspend the capability.
6. Reviewer queue exceeds meaningful oversight
A model-quality signal moves a lending workflow towards advisory mode, but reviewer waiting time and case complexity exceed the point at which staff can inspect evidence before the decision deadline. Human approval would be ceremonial. The continuity contract admits only deterministic renewals with unchanged verified facts, queues exceptions with clear communication and refuses new discretionary decisions beyond capacity. Staffing alone does not restore service until training, evidence access and sampling demonstrate meaningful control. Outcome: queue or divert work to deterministic or manual continuity.
7. Retry amplification threatens healthy services
A rate-limited model causes nested client, orchestrator and gateway retries. The invariant is that essential populations retain policy and retrieval capacity. One retry owner takes control, outstanding attempts are bounded, low-criticality enrichment is shed and the allowed population narrows. A verified smaller model handles simple summarisation without tools; action cases queue. Recovery drains old work separately and expands only when admission pressure stays below the declared guard. Outcome: route to a bounded fallback model or tool.
8. Cached answer no longer reflects consent
The cache is fast and syntactically correct, but consent and entitlement can change immediately. Its age is within a generic freshness window, yet it has no invalidation receipt from the authority source. The answer cannot be released as a current decision. AI may prepare an explanation while an authorised human checks live consent and executes any disclosure. The reviewer sees the source status, not merely the cached recommendation. Recovery requires invalidation linkage and tests of changed-consent cases. Outcome: degrade to advisory mode with human action.
9. Primary tool is healthy again, but old work is uncertain
The provider dashboard turns green after an outage. Some requests timed out after dispatch, and the queue contains retries whose external commitment is unknown. New traffic does not resume at full scale. The system isolates the uncertain population, queries destination state, maintains original idempotency keys and routes a small, clearly separate cohort through the recovered tool under tighter limits. Full restoration waits for old actions and queue state to reconcile. Outcome: route to a bounded fallback model or tool.
10. Information can remain while action fails closed
A customer-service capability combines public guidance with account changes. Its identity provider loses the signal required for write authorisation. The public information feature has no customer context and can stay available with reinforced monitoring. Account-specific recommendations become advisory only when an authenticated employee can inspect current evidence; account changes stop. The interface separates the two promises, preventing users from inferring that a healthy FAQ proves action availability. Outcome: continue in full mode with reinforced monitoring for the low-risk feature.
11. Manual fallback lacks control equivalence
A team proposes moving refund approvals to a shared spreadsheet during a provider outage. The route lacks separation of duties, stable action IDs, receiving-system receipts and a capacity ceiling. It therefore cannot preserve financial and evidence invariants. Work is held with honest customer communication rather than routed into an improvised process. Designers may later create a narrow, rehearsed manual contract, but the outage is not the moment to invent it. Outcome: fail closed and suspend the capability.
Recovery RampRestore a proved cohort, then expand without losing the last safe mode
Recovery is a controlled state transition. Dependency health is necessary, but the capability also needs reconciled queues and external effects, current policy and evidence, available human and infrastructure capacity, regression results and an accountable owner. The mode that carried continuity remains ready until the recovered path demonstrates end-state and control evidence.
First, freeze the recovery population. Identify a bounded cohort by tenant, geography, decision type, tool, time window or low-consequence class. Do not mix uncertain pre-failure work with clean recovery traffic. Reconcile timed-out and in-flight actions using stable identities and receiving-system observations. Expire or refresh work whose evidence became stale while queued.
Second, warm the full dependency path without commitment authority. Validate authentication, policy decisions, data rights, schema, model and tool versions, evidence receipts, latency and capacity. Run causal regression for the observed failure and neighbouring tests for rate limits, timeouts, partial responses, schema drift, cache invalidation, region routing and reviewer overload. Synthetic success is supplemented with shadow or non-consequential production evidence.
Third, admit a controlled cohort with narrow authority and explicit ceilings. Observe business end state as well as technical response. Check decisions, external receipts, population, fairness and privacy evidence, queue age and customer communications. Expand traffic in stages only when each gate passes over its declared observation window. Keep a rapid transition back to Bounded, Advisory, Continuity or Safe Stop.
Close the degraded path deliberately: drain its queue, reconcile fallback state, revoke temporary access, stop alternate processing and record hand-back. Redesign or remove any mode that proved too complex to control.
Interactive decision artefactCapability Degradation Board
The Board selects an operating mode from invariant and evidence conditions. It does not issue a resilience score and does not equate a response with a safe service.
Operating cadenceFund only the modes the organisation can rehearse
At capability design, the business owner separates the service promise into information, recommendation, preparation, decision and action. The team writes observable invariants and identifies which model, retrieval, policy, identity, tool, human and infrastructure dependencies enforce them. Business impact analysis determines essential populations and deadlines. Designers choose the fewest modes that can preserve those invariants.
Before release, each fallback runs the Equivalence Test for its intended mode. Tests inject unavailability, uncertainty, rate limits, timeouts after dispatch, partial responses, stale retrieval, schema drift, policy failure, region loss, queue pressure and reviewer-capacity loss. The transition record, disclosure, expiry, Ambiguous-Effect Gate and Recovery Ramp are exercised with realistic state, not only synthetic health checks.
During normal operation, monitoring observes the capability promise and invariants beside latency and error rate. It records evidence age, policy reachability, authority decisions, tool commitments, queue ageing, retry consumption, reviewer capacity, fallback drift and external outcomes. Signals are typed by population and consequence. Weak evidence can trigger reinforced observation without automatically removing service.
During degradation, the operating owner activates the smallest safe mode, snapshots state, separates clean and uncertain work, communicates removed functions and watches expiry. Limits are enforced at entry and receiving resources. No model text can restore authority. Unknown external effects remain isolated. If evidence or capacity worsens, the state machine moves lower immediately.
During recovery, the team reconciles old state, warms dependencies, runs targeted and neighbouring regressions, admits a bounded cohort and verifies business end state. Expansion follows declared stages with reversal triggers. Temporary permissions and alternate providers are withdrawn only after hand-back state is proved. The review compares the event with the contract and removes any fallback that proved harder to control than explicit unavailability.
At portfolio review, leaders fund redundancy by business consequence and testability rather than making every dependency redundant. Some low-consequence features need only an honest error. Some essential services justify alternate processing and trained manual capacity. The investment decision includes engineering, provider terms, exercises, evidence, people and recovery. Resilience is the ability to preserve the right service properties under pressure, not the number of backup vendors.
Primary evidenceReferences
Links and live status were checked on 2 September 2026. NIST AI RMF 1.0 remains current while revision is under way. The Degradation Contract, Capability Degradation State Machine, Fallback Equivalence Test, Ambiguous-Effect Gate, Recovery Ramp and Capability Degradation Board are this article's synthesis.
- Google Cloud, Design for graceful degradation.
- Google, Site Reliability Engineering: Handling Overload.
- AWS Builders' Library, Timeouts, retries, and backoff with jitter.
- AWS Builders' Library, Avoiding fallback in distributed systems.
- NIST, Artificial Intelligence Risk Management Framework 1.0.
- NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.
- NIST SP 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems.
- NIST SP 800-184, Guide for Cybersecurity Event Recovery.
- NIST SP 800-160 Volume 1 Revision 1, Engineering Trustworthy Secure Systems.
- NIST SP 800-53 Revision 5 Update 1, Security and Privacy Controls for Information Systems and Organizations.
- OWASP GenAI Security Project, Securing Agentic Applications Guide 1.0.
- OWASP LLM06:2025, Excessive Agency.
- European Union, Regulation (EU) 2024/1689, Artificial Intelligence Act.
- Sierra, C. et al., tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains.
- Lu, J. et al., ToolSandbox: A Stateful, Conversational, Interactive Evaluation Benchmark for LLM Tool Use Capabilities.
- Gupta, M., ReliabilityBench: Evaluating LLM Agent Reliability Under Production-Like Stress Conditions.
- Mansoor, H., Phadke, A. and Rana, R., Verified Tool Calls Improve LLM Agent Reliability Under Non-Atomic Failures.
- Debenedetti, E. et al., AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defences for LLM Agents.
About this paperDegrade the capability, never the invariant
The seven-field Degradation Contract, five-state Capability Degradation State Machine, Fallback Equivalence Test, Ambiguous-Effect Gate, Recovery Ramp and Capability Degradation Board are this article's synthesis. They extend distributed-systems reliability, AI risk, continuity and recovery disciplines to capability-level operating modes. The design does not treat uptime, a cached answer, a compatible API, a human click, automatic retry or a green dependency dashboard as proof of safe service.