# Record
**Author:** @cameron.stream (`did:plc:gfrmhdmjvxn2sjedzboeudef`)

## `knowledge-reliable-agent-systems`
**Collection:** `site.standard.document`
**AT URI:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.document/knowledge-reliable-agent-systems`

**Title:** Reliable Agent Systems
**Published:** Thu, 03 Sep 2026 12:20:31 GMT
**Updated:** Thu, 03 Sep 2026 12:19:15 GMT
**Description:** A map from persistent identity and evidence through wake, execution, recovery, correction, diagnosis, and observed effects.
**Publication:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.publication/3mr4py6clps2f`
**Path:** /reliable-agent-systems
**Tags:** knowledge, map, AI agents, reliability, system architecture

**Content:**
```json
{
  "text": "Persistent agents rarely fail in one dramatic place. They fail when individually reasonable components disagree about what happened, who is acting, what may run, or whether an effect occurred. A scheduler can fire into an unsuitable environment. A model can propose the right call after its authority has changed. A provider can accept a write while the client records only a timeout. Each component may look healthy while the system loses the causal thread connecting evidence to effect.\n\nA reliable agent is an evidence-to-effect system whose identity, authority, wake, execution, recovery, correction, and observation contracts must agree and remain testable under failure.\n\nHere, evidence means an addressed occurrence or retained artifact that can justify a turn. An effect is an externally observable result, such as a delivered message, changed record, or provider-confirmed mutation.\n\n## Follow one spine\n\nThe path needs a stable subject. [Shared Memory Versus Shared Identity](https://cameron.stream/knowledge/shared-memory-versus-shared-identity) distinguishes common evidence from continuing identity. Shared repositories create common evidence; conversations on the same agent preserve one continuing identity. An authority subject is the persistent entity whose identity, memory, model configuration, tools, and conversations are treated as belonging together.\n\nThe six cornerstone pages describe one connected reliability spine. [Agent Authority and Effects](https://cameron.stream/knowledge/agent-authority-and-effects) separates tool availability, invocation approval, business authority, effect identity, and external receipts. [Agent Wake Policies](https://cameron.stream/knowledge/agent-wake-policies) identifies which evidence may start a turn and where that turn runs. [Recoverable Agent Execution](https://cameron.stream/knowledge/recoverable-agent-execution) records intent before consequential work and preserves provider receipts afterward. [Agent Trajectory Observability](https://cameron.stream/knowledge/agent-trajectory-observability) connects selected context, model runs, tool calls, verification, and observed effects.\n\nThe remaining two cornerstones cover adaptation. [Diagnosing Agent Memory](https://cameron.stream/knowledge/diagnosing-agent-memory) traces information through source, write, retained representation, retrieval, context placement, utilization, and effect. [How Corrections Become Behavior](https://cameron.stream/knowledge/how-corrections-become-behavior) follows the narrower path from feedback through encoding, retention, retrieval, influence, and behavioral verification.\n\nThe resulting chain is:\n\n`addressed evidence → identified authority subject → authorized wake → recoverable execution → observed effect → retained correction → behavioral replay`\n\nObservation spans the whole chain rather than occupying only its final position. Recovery crosses it wherever an acknowledgement, process, connection, or receipt can disappear.\n\n## Find the first contract disagreement\n\nI assign every incident an address at each stage before choosing a repair. This prevents a missing effect from being flattened into generic agent unreliability.\n\n| Contract | Localization question | Evidence to retain |\n| --- | --- | --- |\n| Identity | Which agent, conversation, application actor, and evidence revision participated? | Stable identifiers and the resolved revision |\n| Authority | Which capability was exposed, who approved it, and which business rule authorized the target? | Tool set, approved input, authenticated actor, policy result |\n| Wake | Which evidence item caused this execution, and where was it allowed to run? | Evidence key, trigger, conversation, execution target |\n| Execution | Which logical operation was attempted, and what state preceded the effect? | Operation ID, saved intent, checkpoint, provider receipt |\n| Recovery | Did the client resume the same thread and reconcile runtime-owned state before retrying? | Conversation ID, logical input ID, history, pending work, retry decision |\n| Observation | Can the source, context, run, tool call, and provider result be joined? | Trace IDs, artifact versions, effect readback |\n| Correction | Did feedback alter a later action under the original trigger? | Encoded rule, retained revision, retrieval record, controlled replay |\n\n[Recovering Remote Agent Clients](https://cameron.stream/knowledge/recovering-remote-agent-clients) supplies the recovery discipline at a particularly dangerous seam. A client should resume the same conversation, reconstruct session-scoped capabilities, inspect authoritative history and runtime state, and only then decide whether an ambiguous input needs another send. A stable client message identifier aids correlation, but the documented protocol does not make it an exactly-once guarantee.\n\n## Treat revocation as a path\n\nRevocation crosses future capability, already-started work, and retained evidence. Changing one of those states does not establish what happened to the others.\n\n[ATProto Spaces as Application Infrastructure](https://cameron.stream/knowledge/atproto-spaces-as-application-infrastructure) makes the problem concrete. A space authority controls which decentralized identifiers (DIDs) may access a permissioned repository context, while records remain hosted in author repositories. Space data is unencrypted and readable by authorized users and applications. The supplied description leaves the treatment of already-synchronized copies after revocation unspecified.\n\nOther lifetimes differ. Session resource links disappear when their session closes, persistent repository attachments remain until explicit detachment, and Model Context Protocol (MCP) connections close with the SDK session. Pending approvals can survive a disconnected client and be recovered into a new session.\n\nMy reading is that a testable revocation record needs the authority subject, revoking authority, effective revision or time, treatment of queued and pending work, known residual copies, and any required compensation. Revoking future permission cannot prove reversal of an earlier external effect. That effect needs its own observed compensation or residual-state receipt.\n\n## Declare degraded modes\n\nA system enters a degraded mode when it continues operating after one contract changes. The dangerous version is silent degradation, where availability survives while the execution assumptions do not.\n\nLocal Letta schedules fire only while their owning process is active, and some computer-targeted tasks may fall back to a cloud sandbox when that computer is offline. An unavailable MCP server does not prevent healthy servers from connecting. After reconnecting, client tools, permission callbacks, working directory, environment, sandbox selection, and session resources must be reconstructed because they belong to the session rather than the persistent agent.\n\nI would make each degraded mode declare five things: available evidence, actual execution location, surviving capabilities, maximum permitted effect, and the condition requiring reconciliation. A task that loses local files might continue as evidence-only analysis while write effects remain disabled. Partial MCP availability might permit tools whose business policy and dependencies still validate. This preserves service without pretending that the original execution contract remains intact.\n\n## Attack the joins\n\nAdversarial evaluation here means introducing ambiguity or conflict at a contract join, then checking the external effect. Happy-path model quality observes too little of this system.\n\nThe memory diagnosis procedure recommends freezing an incident before reteaching, then walking backward from the delivered effect through generation, assembled context, retrieval, retained representation, write operation, and source. Correction tests add useful perturbations: paraphrase the trigger, introduce a conflicting distractor, present a nearby exception, and compare replays with and without the retained correction.\n\nI would extend that method across the full chain:\n\n- Drop the acknowledgement after a send, resume the same conversation, reconcile history, and verify that recovery does not duplicate the effect.\n- Revoke authority after preview but before execution, then verify that the tool handler rechecks the authenticated actor, target, and current policy.\n- Remove a required local capability before a scheduled fallback and verify that the run stops before effects.\n- Supply a correct retained record alongside stale or conflicting context and locate whether failure enters during placement or influence.\n- Let a provider accept an operation while receipt persistence is interrupted, then verify recovery by operation identity or provider readback.\n\nThese are my proposed tests derived from the documented seams. They turn reliability evaluation into controlled disagreement between adjacent contracts rather than an undifferentiated score over final answers.\n\n## Compose evidence without flattening it\n\nEvidence composition means joining artifacts across the chain while preserving their separate identities and claims. A model result, tool return, approval, provider receipt, and later readback answer different questions. Combining them into one success flag destroys the information needed for recovery.\n\nTrajectory observability can represent synchronous work as OpenTelemetry-style spans and asynchronous relationships through links and provenance edges. It should retain identifiers, versions, digests, and governed pointers instead of copying private prompts, memories, and message bodies into every span. A reasoning trace or matching answer alone does not prove that supplied context caused the action.\n\n[Skills, MCP, Mods, and the Agent SDK](https://cameron.stream/knowledge/skills-mcp-mods-and-agent-sdk) provides an ownership test for the execution layer. Skills own reusable procedure, MCP supplies session-scoped external capabilities, mods alter the trusted local harness, and the Agent SDK makes the application responsible for sessions, orchestration, and application-held tools. Recording that owner and lifetime in the trajectory helps distinguish a missing procedure from a disconnected capability, a harness intervention, or an application recovery defect.\n\n## Enter through the symptom\n\nUse the observed symptom to choose an entry point, then continue tracing in both directions. A duplicated effect points first toward operation identity and recovery. An action under the wrong actor points toward identity resolution and business authority. Silence may begin at wake, queueing, execution, or delivery. Apparent forgetting starts with the seven-stage memory path. A repeated corrected mistake starts with encoding and continues through behavioral replay. A successful tool result with no external change starts at receipt and readback.\n\nThe diagnosis earns closure when the first observed disagreement has an artifact-level explanation, the repair targets that stage, and a replay reaches the intended external effect. Until then, classify the failure at the broadest stage the evidence supports.\n\n## Sources\n\n- [Skills, MCP, Mods, and the Agent SDK](<https://cameron.stream/knowledge/skills-mcp-mods-and-agent-sdk>)\n- [Shared Memory Versus Shared Identity](<https://cameron.stream/knowledge/shared-memory-versus-shared-identity>)\n- [Recovering Remote Agent Clients](<https://cameron.stream/knowledge/recovering-remote-agent-clients>)\n- [How Corrections Become Behavior](<https://cameron.stream/knowledge/how-corrections-become-behavior>)\n- [Diagnosing Agent Memory](<https://cameron.stream/knowledge/diagnosing-agent-memory>)\n- [ATProto Spaces as Application Infrastructure](<https://cameron.stream/knowledge/atproto-spaces-as-application-infrastructure>)\n- [Agent Wake Policies](<https://cameron.stream/knowledge/agent-wake-policies>)\n- [Agent Authority and Effects](<https://cameron.stream/knowledge/agent-authority-and-effects>)\n- [Agent Trajectory Observability](<https://cameron.stream/knowledge/agent-trajectory-observability>)\n- [Recoverable Agent Execution](<https://cameron.stream/knowledge/recoverable-agent-execution>)",
  "$type": "site.standard.content.markdown",
  "version": "1.0"
}
```

---
*Fetched from https://enoki.us-east.host.bsky.network via `com.atproto.repo.getRecord`*