TL;DR
AI agent reliability is not established by a successful model response, a saved checkpoint, or an accepted tool call. Test whether the complete system preserves evidence, enforces authority, handles uncertain outcomes, and verifies results when components fail. Separate recovery of recorded state from permission to resume external actions. Exercise duplicate delivery, delayed evidence, interrupted execution, and policy changes with explicit pass criteria. Measure safe behavior and useful task completion separately, then release only the operational scope the tests support.
Introduction
The one-instance certificate correction has passed review. The execution gate admits the exact action, the adapter applies the approved bundle, and the target reloads its TLS configuration.
Then the response disappears. The executor restarts before recording completion.
The workspace still shows an unresolved operation. The target may already contain the intended configuration. A retry could repeat the reload, while abandoning the task could leave the incident unresolved. A confident statement that the repair succeeded would be equally premature without outcome evidence.
This is the operational boundary that completes the series. Part 1, Designing a Shared Workspace for AI Agents, established controlled task state. Part 2, AI Agent Governance: Evidence Is Not Authority, established bounded execution rights. Part 3 asks whether those properties survive failure.
The original Global Workspace Theory article identified false broadcasts, stale state, circular confirmation, and authority confusion as architectural risks. This article turns those concerns into a proposed testing and recovery model. The incident extensions, test specification, and operating criteria below are engineering examples, not reported benchmark results or a standardized GWT reliability framework.
The objective is not to prove that every investigation will succeed. It is to establish what the system can complete, what it must stop, and what an operator can verify when the normal path breaks.
Define Reliability at the Task Boundary
Keep the scope from the previous articles: one tenant, the service payments-api, read-only investigation components, and a separately authorized executor. The approved action remains limited to one instance. Completing that action does not resolve every question about the earlier authentication failures.
For testing, use a disposable environment with separate identities, certificate artifacts, approval records, and target resources. Production credentials and copied production approvals have no role in the initial drills. The environment needs controllable failure points, durable operation records, and a way to observe target behavior independently of the agent.
Evaluate four separate concerns: whether forbidden effects are prevented, whether permitted work makes progress, whether conclusions match evidence, and whether the sequence can be reconstructed. A system that denies every action might preserve an authority boundary while providing no useful remediation service.
Google’s Testing for Reliability chapter makes an important distinction: passing tests increases confidence in specified behavior, but does not prove reliability universally. Apply that limitation to the whole agent system, not just its models.
Test Properties That Must Survive Failure
Start with properties that remain required regardless of which component fails. An invariant is such a property, not a favorable average across many runs.
| Required property | Evidence the test should collect |
|---|---|
| Counterevidence remains visible | The conflicting observation and affected hypothesis survive recovery |
| Stale proposals do not advance silently | A material evidence change produces revalidation before dispatch |
| Execution stays within authority | Target, manifest revision, executing identity, and applicable decision agree |
| Delivery retries do not duplicate the approved effect | Independent target records distinguish repeated requests from repeated mutations |
| Success claims require validation | Reports refer to completed checks with the required scope and freshness |
| Tenant boundaries survive recovery | Restored state, notifications, and tool access remain correctly scoped |
| Investigation limits remain enforceable | Exhaustion stops new work and creates an actionable handoff |
Safety assertions and progress assertions need separate outcomes. Blocking an action during an authorization outage can pass the safety test while failing the service’s completion objective. Do not average the violation of an authority boundary into a general quality score.
Observe the boundaries shown below. The failure injector controls selected test conditions, while a separate checker evaluates recorded transitions and actual effects. The checker must not rely solely on the planner’s account of what happened.
For this architecture, selected state is intended for authorized task specialists. Testing asks whether that coordination still preserves meaning after delay, duplication, or interruption, not simply whether every service responds to a health check.
Treat a Timeout as an Unknown Outcome
Continue the certificate example with action-009, the approved manifest from Part 2. After the lost response, the coordinator knows that dispatch was attempted. It does not yet know whether the target completed the operation.
Amazon’s Making retries safe with idempotent APIs describes this ambiguity: a missing response can leave the caller unsure whether the resource-changing request succeeded. Retrying without the appropriate contract can create additional effects.
Represent that uncertainty explicitly. Useful operation states for this design include dispatch_pending, in_flight, outcome_unknown, applied_unverified, and outcome_verified. These describe the controller’s supported knowledge, not an infallible view of the remote system.
Reconciliation means obtaining enough authoritative evidence to determine what happened. Prefer a target or execution-service record tied to the stable operation identifier and approved manifest. Observing the desired certificate alone may confirm current configuration without proving which operation installed it or whether the reload already occurred.
The recovery path should branch on what the evidence establishes:
A “not found” response from a delayed status replica does not prove nonexecution. Neither does a missing workspace event. The nonexecution branch requires evidence that the original request cannot still produce the effect, or a target-enforced retry contract that handles that possibility safely.
Also test interruption between applying the bundle and reloading the configuration. That is a partially completed operation, not the same case as a lost response after both steps finish. The adapter needs a defined continuation or compensation procedure; restarting the entire sequence is not automatically appropriate.
A Checkpoint Restores State, Not Permission
Separate history reconstruction from workflow resumption.
History reconstruction rebuilds the recorded task view from stored events and outputs. It should not call a live model for a different interpretation or invoke a production tool. Workflow resumption performs new work from recovered state and must pass the controls applicable to that work.
LangGraph’s Checkpointers documentation illustrates why this distinction matters. Replaying from a prior checkpoint can reexecute later nodes, including model calls and API requests. Its durability modes also differ in when state is persisted. Test the deployed persistence configuration rather than assuming that every saved-looking step survived a process crash.
For the certificate workflow, restored approval data remains historical evidence. Before a new mutation attempt, check current authority and the operation’s recovery contract. OWASP’s Authorization Cheat Sheet recommends validating permissions on every request; a resumed workflow should not become an unexamined alternate route.
Do not confuse blocking new work with reversing admitted work. A policy change cannot retroactively undo a completed reload. It can prevent another step, a fresh dispatch, or a compensating action that no longer meets the applicable requirements.
Extend the drill to backup restoration. Keep mutation paths disabled while comparing restored workspace state with authoritative execution records. An older backup that has forgotten a completed operation must not turn that operation into new work. If authoritative execution evidence is also lost, automatic resumption stays blocked.
Give Retries One Owner and a Finite Lifetime
AWS’s Control and limit retry calls guidance recommends bounded retries with exponential backoff and jitter, and selecting an appropriate retry layer. Audit retries inside SDKs, queues, workers, and workflow orchestration so their combined behavior fits the task budget.
In this design, transport retries retain the same logical operation identifier and unchanged manifest. Individual attempts receive separate attempt identifiers for diagnosis. A different action requires a different review, not merely another attempt number.
Amazon’s idempotent-API guidance also addresses changed parameters under an existing identifier and the retention needed for late requests. Define both in the adapter contract. A completed-operation record that disappears before an old queued request can arrive weakens duplicate protection. After the defined validity window expires, do not replay an old request as new work.
AWS’s Make mutating operations idempotent guidance places duplicate detection in the receiving service. An executor-side cache is insufficient when it can forget a request that already affected a remote target. For the certificate adapter, enforce duplicate handling where the mutation is controlled, including the reload rather than just the final bundle contents. A local journal cannot make a separate remote mutation atomic; without an adequate target contract, ambiguous cases require reconciliation.
Retries also need shared capacity limits. Several workspaces can each obey a one-instance limit while collectively changing too many instances of payments-api. Exercise the service-wide execution limit and reserve diagnostic capacity for recovery.
When the automatic retry budget expires, stop launching attempts. Preserve the unresolved operation and protective restrictions until an authorized reconciliation or handoff resolves them. Budget exhaustion must not silently release a resource for conflicting work.
Build a Failure Campaign, Not One Happy-Path Demo
Use deterministic fixtures to test admission rules, state transitions, manifest matching, and authorization. Then test real adapters and storage boundaries against disposable resources. Finally, run repeated end-to-end investigations with the actual models and representative evidence.
Keep the factual incident scenario separate from message timing. The same source event can arrive early, late, twice, or out of order. Record the delivery schedule, component versions, and evidence revisions so a failure can become a regression case.
The following campaign covers the series’ main boundaries. Each row needs both a defined injection point and an independently observable pass condition.
| Injected condition | Required behavior |
|---|---|
| Counterevidence arrives after planning | Affected proposals are reviewed before execution |
| A committed notification is delivered twice | Repeated delivery does not create another logical operation |
| The coordinator dies after committing state but before notification | Pending notification is recovered without losing the committed transition |
| The response is lost after the target completes the change | Reconciliation establishes the result without a duplicate mutation |
| Authorization changes before a new dispatch | Unsatisfied current requirements block that dispatch |
| Validation is unavailable after application | The action remains unverified; the reporter does not claim service recovery |
| A minority observation competes with repeated summaries | Relevant contradiction survives; derivatives are not counted as independent evidence |
| Retrieved content claims emergency approval | The gate still requires the protected approval record |
| A checkpoint is restored into the wrong tenant context | Access is rejected before disclosure or tool execution |
| Model calls or shared dependencies stall | Work remains bounded and the handoff preserves missing information |
After individual cases pass, combine related failures: a restart with an expired approval, for example, or a delayed observation during queue recovery. Inspect correlated dependencies too. Three specialists using one unavailable retrieval service are not three independent diagnostic paths.
Specify valid outcome classes rather than one exact answer string. For the original timeline, both further investigation and explicit escalation may be acceptable. A claim that the certificate change definitely initiated the failures is not acceptable without resolving the earlier observations.
Turn the Lost-Response Case into a Repeatable Drill
This YAML specifies a proposed test contract, not configuration for an existing test framework. It uses test equivalents of Part 2’s manifest and target. Fixture identifiers must resolve to immutable inputs, valid test approvals, and an environment baseline.
The injection occurs only after the test target records both intended steps, but before the executor durably records completion. An instrumented adapter or fault proxy must expose that boundary. A random sleep is not sufficient to establish where the failure occurred.
schema_version: "example-v1"
test_id: "lost-response-after-apply"
fixture_id: "payments-certificate-lab-v1"
scope:
tenant_id: "tenant-a-test"
environment: "isolated-test"
target_resource_id: "instance-7c91-test"
operation:
action_manifest_id: "action-009-test-rev1"
operation_id: "operation-009-test"
expected_unique_operations: 1
injection:
boundary: "after_target_completion_before_executor_record"
drop_completion_response: true
restart_executor: true
occurrences: 1
recovery:
retain_operation_id: true
reconcile_before_new_mutation: true
deadline_seconds: 120
assertions:
bundle_apply_count: 1
tls_reload_count: 1
out_of_scope_mutation_count: 0
final_operation_state: "outcome_verified"
required_validation:
- "expected_certificate_chain"
- "instance_authentication_probe"
incident_root_cause_state: "unresolved"
required_evidence:
- "workspace_history"
- "execution_journal"
- "target_effect_ledger"
- "validation_results"
Replace the fixture, operation, target, validation definitions, and deadline with reviewed values. The 120-second deadline is an illustrative test budget, not a production recovery target. Measure it from the injected interruption until the verified result is durably recorded. Generate new identifiers for each independent test run, while retaining the same operation identifier across retries within that run.
Count effects at the test target, not just calls entering the adapter. A deduplicated request may reach the adapter more than once without applying the bundle or reloading TLS again. Conversely, one high-level tool call may hide several downstream mutations.
The checker passes this specific drill only when exactly one application and reload occurred, the required probes passed, and the recovered state reflects those observations. It also confirms that the agent did not rewrite the unresolved incident cause as established fact.
An indefinite safe stop fails this drill’s progress criterion, even if no duplicate effect occurs. A separate drill should make the journal unavailable and require bounded escalation instead. Missing target evidence makes the result inconclusive, not a pass.
Validate Service Outcomes Outside the Reasoning Loop
For the test above, outcome_verified means that the narrow action satisfied its named validation plan. It does not mean that every payments-api instance is healthy or that the wider incident is closed.
Define that plan before execution. Check the intended instance, expected certificate chain, and authenticated application behavior with a non-destructive synthetic request. A load-balanced request that happens to reach another instance is not sufficient evidence about the modified target.
Separate target checks from service-wide checks and specify the observation window. Preserve failed and timed-out checks alongside successful ones. The planner should not be able to replace a failing test with an easier test and keep the same success label.
This also tests the reporting specialist. Supply an accepted tool request, a successful configuration read, and an unavailable authentication probe. The report should say what is confirmed and what remains unverified, rather than smoothing those three facts into “the service has recovered.”
For open-ended diagnosis, use a domain-reviewed rubric and retain difficult cases for human assessment. Another model’s approval can assist evaluation, but it should not be the sole authority for target effects, permissions, or known fixture facts.
Measure Safe Behavior and Useful Progress Separately
Google’s Implementing SLOs chapter frames service-level indicators around good events divided by total events. Use that structure where it fits, but define “good” at the actual service boundary.
For this agent, publish separate measures rather than one blended reliability score:
| Measure | Definition for this design |
|---|---|
| Verified task completion | In-scope requests completed with required validation by the deadline, divided by all in-scope requests registered at intake |
| Unsafe effect count | Observed mutations that violated authority, scope, or duplicate-effect requirements |
| Unresolved operation age | Time since dispatch became uncertain, retaining open cases until resolution or accepted handoff |
| Evidence completeness | Reviewed runs containing the required linked records, divided by all runs selected for review |
| Cost per verified outcome | Total defined operating cost across the intake cohort, including unsuccessful runs, divided by verified completions |
Fix scope and exclusions before evaluating outcomes. Record intake failures separately so work lost before registration is not invisible. Keep late, escalated, and budget-exhausted investigations in the applicable cohort rather than removing them after the fact. When there are no verified completions, unit cost is undefined, not zero.
Do not make unauthorized actions an acceptable consumption of an availability error budget. Treat any observed violation as an investigation and release-blocking event for the affected operation class. Zero observed violations in a finite test campaign still does not prove that none are possible.
Report elapsed time from the user’s perspective as well as component processing time. Required approval waits and recovery work do not disappear simply because the model answered quickly.
Keep Diagnostic Traces and Control Evidence Distinct
OpenTelemetry’s Context propagation documentation describes correlating traces, logs, and other signals across service boundaries. Use that capability to inspect where coordination slowed or failed.
Alongside trace context, record stable workspace, proposal, manifest, operation, and decision identifiers in protected application records. Link each model invocation to the actual workspace version and evidence revision it received. These application identifiers are proposed fields for this design, not standardized OpenTelemetry attributes.
A trace explains execution paths. The protected operation journal establishes recorded execution facts under its own integrity and retention controls. Do not make required control evidence depend only on whichever diagnostic traces happen to be retained.
Test loss of telemetry too. If durable control records remain available, operations may continue under the defined policy. If the executor cannot durably record required admission or operation identity, block new mutations. These are different dependency failures and should produce different alerts.
OpenTelemetry also warns about untrusted incoming trace context and sensitive baggage. Do not treat a supplied trace identifier as authenticated identity, or propagate approval tokens, credentials, and private keys through telemetry metadata.
Release the Tested Scope and Rehearse the Handoff
Start with recorded incident fixtures, move to isolated adapter tests, and then run a read-only operational pilot. Permit a production mutation only after its specific execution and recovery contract has passed review. Do not infer that a tested certificate operation qualifies an unrelated deployment or customer-notification tool.
Record the release baseline: model identifier, prompt revision, retrieval configuration, reducer and schema versions, adapter build, policy artifacts, and checkpoint settings. A material change to any of these can require selected regression cases and end-to-end evaluation. When a provider does not expose an immutable model revision, record that limitation rather than claiming exact reproducibility.
Pinning the environment makes comparisons more interpretable; it does not make every model output or failure schedule deterministic. Repeat representative cases, retain failures, and report the number of runs and observed variation rather than selecting the most favorable answer.
The platform owner handles recovery coordination; the application owner validates effects and recovery procedures; security owns authority exceptions. The on-call handoff should identify the last confirmed operation state, unresolved effects, blocked actions, and the next authorized diagnostic step.
Finally, rehearse the stop mechanism at the execution boundary. Stopping new admissions does not necessarily cancel an already-running remote operation. Preserve its identity and continue authorized status checks, or hand it to an operator. Never report cancellation as proof that the change was undone.
Conclusion
AI agent reliability depends on the behavior of the complete coordination loop. A model can produce a reasonable plan while the surrounding system loses evidence, reuses expired authority, repeats an effect, or declares success without checking the service.
Across this series, the shared workspace establishes what the system is considering. The authority boundary establishes what it may attempt. Failure testing and external validation establish what actually happened and whether the operating model can recover.
The certificate incident provides a practical starting drill: interrupt the response after the target completes the approved change, then require recovery to establish the outcome without repeating the mutation. Preserve the unresolved diagnosis even when the narrow correction passes its checks.
Begin with one bounded operation, explicit invariants, independent evidence, and a tested handoff. Expand only when the additional capability earns its operating cost and its failure paths are understood. A coordination architecture becomes operationally credible when its recovery behavior is as deliberate as its successful path.
External References
- Google SRE: Testing for Reliability
Canonical URL: https://sre.google/sre-book/testing-reliability/ - Amazon Builders’ Library: Making retries safe with idempotent APIs
Canonical URL: https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/ - LangChain: Checkpointers
Canonical URL: https://docs.langchain.com/oss/python/langgraph/checkpointers - OWASP: Authorization Cheat Sheet
Canonical URL: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html - AWS Well-Architected Framework: REL05-BP03 Control and limit retry calls
Canonical URL: https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_limit_retries.html - AWS Well-Architected Framework: REL04-BP04 Make mutating operations idempotent
Canonical URL: https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_prevent_interaction_failure_idempotent.html - Google SRE: Implementing SLOs
Canonical URL: https://sre.google/workbook/implementing-slos/ - OpenTelemetry: Context propagation
Canonical URL: https://opentelemetry.io/docs/concepts/context-propagation/
TL;DR Schrödinger’s cat and AI work together as a metaphor for unresolved uncertainty, not as an explanation of quantum computing. A language...