<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.4.8) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-nennemann-agent-cascade-prevention-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="Agent Cascade Prevention">Agent Failure Cascade Prevention and Rollback</title>

    <author fullname="Christian Nennemann">
      <organization>Independent Researcher</organization>
      <address>
        <email>ietf@nennemann.de</email>
      </address>
    </author>

    <date year="2026" month="March" day="06"/>

    <area>OPS</area>
    <workgroup>NMOP</workgroup>
    <keyword>cascade prevention</keyword> <keyword>circuit breaker</keyword> <keyword>rollback</keyword> <keyword>failure domain</keyword> <keyword>agent recovery</keyword>

    <abstract>


<?line 43?>

<t>This document defines protocols for preventing agent failures from
cascading across interconnected autonomous systems and standardized
mechanisms for real-time rollback of incorrect agent decisions.  It
specifies a circuit breaker protocol with well-defined state
transitions, failure domain isolation through bulkhead patterns, cascade
detection via error rate and latency analysis, and a distributed
rollback coordination protocol that walks the Execution Context Token
(ECT) DAG backwards to revert agent actions to a known-good state.
This document absorbs and supersedes the concepts introduced in earlier
AERR and ATD proposals.</t>



    </abstract>



  </front>

  <middle>


<?line 56?>

<section anchor="introduction"><name>Introduction</name>

<t>Autonomous AI agents increasingly operate in interconnected
multi-agent systems where a single agent's failure can propagate
through the network, causing widespread service disruption.  The IETF
gap analysis <xref target="I-D.nennemann-agent-gap-analysis"/> identified two
critical gaps in existing standards:</t>

<t><list style="symbols">
  <t><strong>Gap 2 (Cascade Prevention)</strong>: No standard mechanism exists for
containing failures within agent ecosystems.  When one agent fails,
dependent agents continue sending requests to the failing agent,
amplifying the failure across the system.</t>
  <t><strong>Gap 4 (Rollback)</strong>: No standard protocol exists for reverting
incorrect agent decisions.  When an autonomous agent misconfigures
a network device or makes an erroneous API call, there is no
interoperable way to undo the action or coordinate rollback across
multiple affected agents.</t>
</list></t>

<t>This document addresses both gaps by defining:</t>

<t><list style="numbers" type="1">
  <t>A circuit breaker protocol that stops failure propagation between
agents.</t>
  <t>Failure domain isolation mechanisms that contain blast radius.</t>
  <t>Cascade detection signals that identify propagating failures early.</t>
  <t>A distributed rollback protocol that coordinates state reversion
across multiple agents using the ECT DAG
<xref target="I-D.nennemann-wimse-ect"/>.</t>
</list></t>

<t>This specification absorbs and supersedes the concepts from the earlier
Agent Error Recovery and Rollback (AERR) and Agent Task DAG (ATD)
proposals, consolidating cascade prevention and rollback into a single
coherent protocol built on ECT infrastructure.</t>

<t>Design principles:</t>

<t><list style="numbers" type="1">
  <t>Agents that take consequential actions <bcp14>MUST</bcp14> be able to undo them,
or <bcp14>MUST</bcp14> declare them irreversible upfront.</t>
  <t>Failure containment takes priority over failure diagnosis.</t>
  <t>The protocol adds minimal overhead to the happy path.</t>
  <t>All cascade prevention and rollback actions are recorded as ECT
nodes, providing a cryptographic audit trail.</t>
</list></t>

</section>
<section anchor="terminology"><name>Terminology</name>

<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>

<?line -18?>

<dl>
  <dt>Circuit Breaker:</dt>
  <dd>
    <t>A mechanism that stops an agent from propagating requests to a
failing downstream agent, preventing cascading failures.  Modeled
after the electrical circuit breaker pattern used in microservice
architectures.</t>
  </dd>
  <dt>Failure Domain:</dt>
  <dd>
    <t>A bounded set of agents and resources within which a failure is
contained.  Failures within a domain <bcp14>MUST NOT</bcp14> propagate beyond the
domain boundary without explicit escalation.</t>
  </dd>
  <dt>Blast Radius:</dt>
  <dd>
    <t>The set of agents and systems affected by a single agent's failure,
determinable by traversing the ECT DAG forward from the failing
node.</t>
  </dd>
  <dt>Cascade Detection:</dt>
  <dd>
    <t>The process of identifying that a failure is propagating across
agent boundaries, using signals such as error rate spikes, latency
increases, and resource exhaustion patterns.</t>
  </dd>
  <dt>Rollback Coordinator:</dt>
  <dd>
    <t>An agent or orchestrator responsible for coordinating distributed
rollback across multiple agents in a workflow, ensuring consistency
and resolving conflicts.</t>
  </dd>
  <dt>Checkpoint:</dt>
  <dd>
    <t>An ECT node recording an agent's state hash before a consequential
action, providing a restore point for rollback.</t>
  </dd>
  <dt>Compensating Action:</dt>
  <dd>
    <t>An action that semantically reverses the effect of a prior action
when direct state restoration is not possible (e.g., deleting a
resource that was created, rather than restoring a pre-creation
snapshot).</t>
  </dd>
  <dt>Recovery Point:</dt>
  <dd>
    <t>The most recent checkpoint in the ECT DAG to which an agent or
workflow can be safely rolled back without violating consistency
constraints.</t>
  </dd>
</dl>

</section>
<section anchor="failure-cascade-prevention"><name>Failure Cascade Prevention</name>

<section anchor="cascade-model"><name>Cascade Model</name>

<t>When an agent fails in a multi-agent system, the failure can
propagate through multiple vectors.  The following diagram
illustrates a typical cascade scenario:</t>

<figure title="Failure Cascade Propagation" anchor="fig-cascade"><artwork><![CDATA[
  Agent A          Agent B          Agent C          Agent D
     |                |                |                |
     | request        |                |                |
     |--------------->|                |                |
     |                | request        |                |
     |                |--------------->|                |
     |                |                | request        |
     |                |                |--------------->|
     |                |                |                |
     |                |                |    FAILURE     |
     |                |                |<--- X ---------|
     |                |                |                |
     |                |  error/timeout |                |
     |                |<---------------|                |
     |                |                |                |
     |  error/timeout |                |                |
     |<---------------|                |                |
     |                |                |                |
     | [CASCADE: all agents impacted by D's failure]    |
     |                |                |                |
]]></artwork></figure>

<section anchor="failure-domain-taxonomy"><name>Failure Domain Taxonomy</name>

<t>Failures in agent ecosystems fall into the following categories:</t>

<dl>
  <dt>Agent-Local Failure:</dt>
  <dd>
    <t>A failure confined to a single agent instance (e.g., out-of-memory,
logic error).  The blast radius is limited to the agent itself and
its immediate callers.</t>
  </dd>
  <dt>Service Failure:</dt>
  <dd>
    <t>A failure affecting all instances of a particular agent service
(e.g., model endpoint unavailable).  The blast radius includes all
agents that depend on the failing service.</t>
  </dd>
  <dt>Infrastructure Failure:</dt>
  <dd>
    <t>A failure in shared infrastructure (e.g., network partition,
certificate authority unavailable).  The blast radius may span
multiple failure domains.</t>
  </dd>
  <dt>Semantic Failure:</dt>
  <dd>
    <t>An agent produces incorrect output without raising an error (e.g.,
misconfiguration, wrong decision).  This is the hardest category
to detect and may propagate silently through the DAG.</t>
  </dd>
</dl>

</section>
<section anchor="propagation-vectors-in-agent-ecosystems"><name>Propagation Vectors in Agent Ecosystems</name>

<t>Failures propagate through the following vectors:</t>

<t><list style="numbers" type="1">
  <t><strong>Synchronous request chains</strong>: An agent blocks waiting for a
failing downstream agent, causing its own callers to time out.</t>
  <t><strong>Shared state corruption</strong>: An agent writes incorrect data to a
shared store, causing other agents reading that data to fail or
make incorrect decisions.</t>
  <t><strong>Resource exhaustion</strong>: A failing agent consumes excessive
resources (connections, memory, compute), starving healthy agents.</t>
  <t><strong>Retry amplification</strong>: Multiple agents retry requests to a
failing agent simultaneously, overwhelming it further.</t>
</list></t>

</section>
</section>
<section anchor="circuit-breaker-protocol"><name>Circuit Breaker Protocol</name>

<t>Each agent <bcp14>MUST</bcp14> implement a circuit breaker for every downstream
agent it communicates with.</t>

<section anchor="states"><name>States</name>

<t>The circuit breaker has four states:</t>

<dl>
  <dt>CLOSED (normal):</dt>
  <dd>
    <t>Requests flow through normally.  The agent tracks the error rate
over a sliding window (default: 60 seconds).</t>
  </dd>
  <dt>OPEN (failure detected):</dt>
  <dd>
    <t>When the error rate exceeds the configured threshold (default: 50%
over the window), the breaker opens.  All requests to the
downstream agent are immediately rejected locally.  The agent
<bcp14>MUST</bcp14> emit an ECT with <spanx style="verb">exec_act</spanx> value <spanx style="verb">"circuit_breaker_open"</spanx>.</t>
  </dd>
  <dt>HALF_OPEN (recovery probe):</dt>
  <dd>
    <t>After a cooldown period (default: 30 seconds), the breaker
transitions to HALF_OPEN and allows a single probe request.  If
the probe succeeds, the breaker returns to CLOSED.  If the probe
fails, the breaker returns to OPEN with doubled cooldown
(exponential backoff, maximum 300 seconds).</t>
  </dd>
  <dt>CLOSED (recovered):</dt>
  <dd>
    <t>When a probe succeeds in the HALF_OPEN state, the breaker returns
to CLOSED and the agent <bcp14>MUST</bcp14> emit an ECT with <spanx style="verb">exec_act</spanx> value
<spanx style="verb">"circuit_breaker_close"</spanx>.</t>
  </dd>
</dl>

</section>
<section anchor="state-transition-rules"><name>State Transition Rules</name>

<figure title="Circuit Breaker State Machine" anchor="fig-circuit-fsm"><artwork><![CDATA[
                error_rate > threshold
  CLOSED ────────────────────────────────► OPEN
    ▲                                        │
    │  probe succeeds                        │ cooldown expires
    │                                        ▼
    └──────────────────────────────── HALF_OPEN
                                       │
                            probe fails │
                                        ▼
                                      OPEN
                                (cooldown *= 2,
                                 max 300s)
]]></artwork></figure>

<t>The following rules govern state transitions:</t>

<t><list style="numbers" type="1">
  <t>CLOSED to OPEN: The error rate over the sliding window exceeds
the configured threshold.  The agent <bcp14>MUST</bcp14> emit a
<spanx style="verb">"circuit_breaker_open"</spanx> ECT and reject all subsequent requests
to the downstream agent.</t>
  <t>OPEN to HALF_OPEN: The cooldown timer expires.  The agent <bcp14>MUST</bcp14>
allow exactly one probe request through.</t>
  <t>HALF_OPEN to CLOSED: The probe request succeeds.  The agent <bcp14>MUST</bcp14>
emit a <spanx style="verb">"circuit_breaker_close"</spanx> ECT and resume normal operation.
The error rate counters <bcp14>MUST</bcp14> be reset.</t>
  <t>HALF_OPEN to OPEN: The probe request fails.  The cooldown period
<bcp14>MUST</bcp14> be doubled (up to a maximum of 300 seconds).</t>
</list></t>

</section>
<section anchor="circuit-breaker-registration-and-discovery"><name>Circuit Breaker Registration and Discovery</name>

<t>Agents <bcp14>MUST</bcp14> expose circuit breaker state at a well-known endpoint:</t>

<figure><artwork><![CDATA[
GET /.well-known/cascade/circuits HTTP/1.1
]]></artwork></figure>

<t>Response:</t>

<figure title="Circuit Breaker Status Endpoint" anchor="fig-circuits"><sourcecode type="json"><![CDATA[
{
  "circuits": [
    {
      "downstream_agent": "spiffe://example.com/agent/router-mgr",
      "state": "open",
      "error_rate": 0.75,
      "window_s": 60,
      "last_failure_ect": "550e8400-e29b-41d4-a716-446655440099",
      "cooldown_remaining_s": 22
    }
  ]
}
]]></sourcecode></figure>

</section>
<section anchor="ect-integration"><name>ECT Integration</name>

<t>Each circuit breaker state change <bcp14>MUST</bcp14> produce an ECT node:</t>

<figure title="Circuit Breaker Open ECT" anchor="fig-cb-ect"><sourcecode type="json"><![CDATA[
{
  "jti": "cb-open-uuid",
  "exec_act": "circuit_breaker_open",
  "par": ["error-ect-uuid"],
  "ext": {
    "cascade.downstream_agent":
      "spiffe://example.com/agent/router-mgr",
    "cascade.error_rate": 0.75,
    "cascade.window_s": 60,
    "cascade.cooldown_s": 30
  }
}
]]></sourcecode></figure>

<figure title="Circuit Breaker Close ECT" anchor="fig-cb-close-ect"><sourcecode type="json"><![CDATA[
{
  "jti": "cb-close-uuid",
  "exec_act": "circuit_breaker_close",
  "par": ["cb-open-uuid"],
  "ext": {
    "cascade.downstream_agent":
      "spiffe://example.com/agent/router-mgr",
    "cascade.total_cooldown_s": 30
  }
}
]]></sourcecode></figure>

</section>
</section>
<section anchor="failure-domain-isolation"><name>Failure Domain Isolation</name>

<section anchor="blast-radius-containment-strategies"><name>Blast Radius Containment Strategies</name>

<t>Agents <bcp14>MUST</bcp14> implement the following containment strategies:</t>

<t><list style="numbers" type="1">
  <t><strong>Request rejection at the boundary</strong>: When a circuit breaker
opens, the agent <bcp14>MUST</bcp14> return a structured error to its callers
indicating that the downstream dependency is unavailable, rather
than propagating the failure.</t>
  <t><strong>Timeout enforcement</strong>: Agents <bcp14>MUST</bcp14> enforce timeouts on all
downstream requests.  The timeout <bcp14>MUST</bcp14> be shorter than the
caller's timeout to prevent timeout cascades.</t>
  <t><strong>Graceful degradation</strong>: When a non-critical downstream agent
is unavailable, agents <bcp14>SHOULD</bcp14> continue operating with reduced
functionality rather than failing entirely.</t>
</list></t>

</section>
<section anchor="domain-boundary-enforcement"><name>Domain Boundary Enforcement</name>

<t>Failure domains are defined by the workflow topology in the ECT DAG.
Each workflow (identified by the <spanx style="verb">wid</spanx> claim) constitutes a failure
domain.  Cross-workflow failures <bcp14>MUST</bcp14> be escalated through the HITL
mechanism <xref target="I-D.nennemann-agent-dag-hitl-safety"/> rather than
propagating automatically.</t>

<t>Agents at domain boundaries <bcp14>MUST</bcp14>:</t>

<t><list style="numbers" type="1">
  <t>Validate all incoming requests against the circuit breaker state
of their downstream dependencies before accepting work.</t>
  <t>Emit a <spanx style="verb">"circuit_breaker_open"</spanx> ECT when rejecting work due to
downstream unavailability.</t>
  <t>Report domain health status via the circuits endpoint.</t>
</list></t>

</section>
<section anchor="bulkhead-patterns-for-agent-pools"><name>Bulkhead Patterns for Agent Pools</name>

<t>When multiple workflows share a common agent pool, the pool <bcp14>MUST</bcp14>
implement bulkhead isolation:</t>

<t><list style="numbers" type="1">
  <t><strong>Connection limits</strong>: Each workflow <bcp14>MUST</bcp14> have a maximum number
of concurrent connections to the shared agent pool.</t>
  <t><strong>Queue isolation</strong>: Each workflow's requests <bcp14>MUST</bcp14> be queued
independently, preventing one workflow's backlog from blocking
others.</t>
  <t><strong>Resource quotas</strong>: Shared agent pools <bcp14>SHOULD</bcp14> enforce per-workflow
resource quotas (CPU, memory, request rate).</t>
</list></t>

</section>
</section>
<section anchor="cascade-detection"><name>Cascade Detection</name>

<section anchor="detection-signals"><name>Detection Signals</name>

<t>Agents <bcp14>MUST</bcp14> monitor the following signals for cascade detection:</t>

<dl>
  <dt>Error Rate:</dt>
  <dd>
    <t>The ratio of failed requests to total requests over a sliding
window.  An error rate exceeding the circuit breaker threshold
indicates a potential cascade.</t>
  </dd>
  <dt>Latency Spike:</dt>
  <dd>
    <t>A sudden increase in response latency (e.g., p99 latency exceeding
3x the baseline) indicates downstream congestion or failure.
Agents <bcp14>SHOULD</bcp14> track latency baselines using exponentially weighted
moving averages.</t>
  </dd>
  <dt>Resource Exhaustion:</dt>
  <dd>
    <t>Thread pool saturation, connection pool exhaustion, or memory
pressure above configured thresholds indicates that a cascade is
consuming resources.</t>
  </dd>
</dl>

</section>
<section anchor="propagation-tracking-via-ect-dag-analysis"><name>Propagation Tracking via ECT DAG Analysis</name>

<t>Orchestrators <bcp14>SHOULD</bcp14> analyze the ECT DAG to detect cascading
patterns:</t>

<t><list style="numbers" type="1">
  <t><strong>Error clustering</strong>: Multiple <spanx style="verb">"circuit_breaker_open"</spanx> ECTs
referencing the same downstream agent within a short window
indicate a shared dependency failure.</t>
  <t><strong>Depth-first propagation</strong>: Errors propagating along <spanx style="verb">par</spanx>
chains in the DAG indicate a synchronous cascade.</t>
  <t><strong>Breadth-first propagation</strong>: Multiple sibling nodes in the
DAG failing concurrently indicate a shared infrastructure
failure.</t>
</list></t>

</section>
<section anchor="alert-format-and-escalation"><name>Alert Format and Escalation</name>

<t>When cascade detection identifies a propagating failure, the
detecting agent <bcp14>MUST</bcp14> emit a cascade alert ECT:</t>

<figure title="Cascade Alert ECT" anchor="fig-cascade-alert"><sourcecode type="json"><![CDATA[
{
  "exec_act": "cascade_detected",
  "ext": {
    "cascade.pattern": "depth_first",
    "cascade.affected_agents": 4,
    "cascade.root_cause_ect": "error-ect-uuid",
    "cascade.blast_radius": [
      "spiffe://example.com/agent/a",
      "spiffe://example.com/agent/b",
      "spiffe://example.com/agent/c"
    ]
  }
}
]]></sourcecode></figure>

<t>Cascade alerts with more than 3 affected agents <bcp14>SHOULD</bcp14> trigger
HITL escalation per <xref target="I-D.nennemann-agent-dag-hitl-safety"/>.</t>

</section>
</section>
</section>
<section anchor="real-time-rollback"><name>Real-Time Rollback</name>

<section anchor="rollback-model"><name>Rollback Model</name>

<t>Rollback reverses the effects of agent actions by walking the ECT
DAG backwards from the point of failure to the nearest valid
recovery point.</t>

<section anchor="walking-the-ect-dag-backwards"><name>Walking the ECT DAG Backwards</name>

<t>The rollback process follows <spanx style="verb">par</spanx> references in reverse:</t>

<t><list style="numbers" type="1">
  <t>Identify the failing ECT node.</t>
  <t>Find the checkpoint ECT associated with the failing action
(referenced via <spanx style="verb">par</spanx>).</t>
  <t>Follow <spanx style="verb">par</spanx> references backwards to identify all downstream
actions that were caused by the checkpointed action.</t>
  <t>Issue rollback requests to each affected agent in reverse
topological order.</t>
</list></t>

<figure title="Rollback Order via DAG Traversal" anchor="fig-rollback-order"><artwork><![CDATA[
  Checkpoint A ──► Action A1 ──► Checkpoint B ──► Action B1
                                      │
                                      └──► Action B2

  Rollback order: B2, B1, B, A1, A (reverse topological)
]]></artwork></figure>

</section>
<section anchor="compensating-actions-vs-state-restoration"><name>Compensating Actions vs State Restoration</name>

<t>Rollback can be performed through two mechanisms:</t>

<dl>
  <dt>State Restoration:</dt>
  <dd>
    <t>The agent restores its state from the checkpoint snapshot.  This
is the preferred mechanism when the checkpoint contains a complete
state snapshot (verified via <spanx style="verb">out_hash</spanx>).</t>
  </dd>
  <dt>Compensating Action:</dt>
  <dd>
    <t>When state restoration is not possible (e.g., the action involved
an external API call), the agent executes a compensating action
that semantically reverses the original action.  Compensating
actions <bcp14>MUST</bcp14> be recorded as ECT nodes with <spanx style="verb">exec_act</spanx> value
<spanx style="verb">"compensate"</spanx>.</t>
  </dd>
</dl>

</section>
<section anchor="rollback-scope"><name>Rollback Scope</name>

<t>Rollback can be scoped to three levels:</t>

<dl>
  <dt>Single Agent:</dt>
  <dd>
    <t>Only the specified agent's checkpoint is rolled back.  No
downstream propagation occurs.</t>
  </dd>
  <dt>Sub-DAG:</dt>
  <dd>
    <t>The checkpoint and all downstream checkpoints in the sub-DAG
are rolled back.  This is the default when <spanx style="verb">cascade</spanx> is <spanx style="verb">true</spanx>.</t>
  </dd>
  <dt>Full Workflow:</dt>
  <dd>
    <t>All checkpoints in the workflow are rolled back and the workflow
is terminated.  This requires Rollback Coordinator authorization.</t>
  </dd>
</dl>

</section>
</section>
<section anchor="checkpoint-protocol"><name>Checkpoint Protocol</name>

<section anchor="checkpoint-creation"><name>Checkpoint Creation</name>

<t>An agent <bcp14>MUST</bcp14> create a checkpoint ECT before any consequential
action.  An action is consequential if it modifies external state
(network configuration, database records, API calls with side
effects).</t>

<t>A checkpoint is an ECT with:</t>

<t><list style="symbols">
  <t><spanx style="verb">exec_act</spanx>: <spanx style="verb">"checkpoint"</spanx></t>
  <t><spanx style="verb">par</spanx>: the ECT of the action being checkpointed</t>
  <t><spanx style="verb">out_hash</spanx>: SHA-256 hash of the agent's state snapshot</t>
</list></t>

<figure title="Checkpoint ECT" anchor="fig-checkpoint"><sourcecode type="json"><![CDATA[
{
  "jti": "ckpt-uuid",
  "exec_act": "checkpoint",
  "par": ["action-ect-uuid"],
  "out_hash": "sha256:...",
  "ext": {
    "cascade.reversible": true,
    "cascade.rollback_uri":
      "https://agent-b.example.com/.well-known/cascade/rollback",
    "cascade.target": "router-07.example.com",
    "cascade.description": "Update BGP peer configuration",
    "cascade.ttl": 86400
  }
}
]]></sourcecode></figure>

<t>The <spanx style="verb">cascade.reversible</spanx> field <bcp14>MUST</bcp14> be present.  If <spanx style="verb">false</spanx>, the
agent declares that this action cannot be automatically undone and
rollback requests <bcp14>MUST</bcp14> be escalated to a human operator via the
HITL mechanism <xref target="I-D.nennemann-agent-dag-hitl-safety"/>.</t>

</section>
<section anchor="checkpoint-storage-and-retrieval"><name>Checkpoint Storage and Retrieval</name>

<t>Checkpoint ECTs <bcp14>MUST</bcp14> be stored for at least the duration specified
by <spanx style="verb">cascade.ttl</spanx>.  Agents <bcp14>MUST</bcp14> store checkpoints in durable storage
that survives agent restarts.</t>

<t>Agents <bcp14>MUST</bcp14> expose a checkpoint retrieval endpoint:</t>

<figure><artwork><![CDATA[
GET /.well-known/cascade/checkpoints/{jti} HTTP/1.1
]]></artwork></figure>

<t>The response <bcp14>MUST</bcp14> include the checkpoint ECT and its verification
status (whether <spanx style="verb">out_hash</spanx> matches the current stored state snapshot).</t>

</section>
<section anchor="checkpoint-verification"><name>Checkpoint Verification</name>

<t>Before executing a rollback, the agent <bcp14>MUST</bcp14> verify the checkpoint
integrity:</t>

<t><list style="numbers" type="1">
  <t>Retrieve the checkpoint ECT.</t>
  <t>Verify the ECT signature chain (L2/L3).</t>
  <t>Verify that the stored state snapshot matches <spanx style="verb">out_hash</spanx>.</t>
  <t>Verify that the checkpoint has not expired (<spanx style="verb">cascade.ttl</spanx>).</t>
</list></t>

<t>If verification fails, the agent <bcp14>MUST</bcp14> reject the rollback request
and emit an error ECT.</t>

</section>
</section>
<section anchor="distributed-rollback-coordination"><name>Distributed Rollback Coordination</name>

<section anchor="rollback-coordinator-role"><name>Rollback Coordinator Role</name>

<t>For rollbacks spanning multiple agents (sub-DAG or full workflow
scope), a Rollback Coordinator <bcp14>MUST</bcp14> be designated.  The coordinator
is typically the orchestrator or the agent that initiated the
workflow.</t>

<t>The coordinator is responsible for:</t>

<t><list style="numbers" type="1">
  <t>Computing the blast radius by traversing the ECT DAG.</t>
  <t>Determining rollback order (reverse topological sort).</t>
  <t>Issuing rollback requests to each affected agent.</t>
  <t>Tracking rollback progress and handling failures.</t>
  <t>Emitting the final rollback completion ECT.</t>
</list></t>

</section>
<section anchor="two-phase-rollback-protocol"><name>Two-Phase Rollback Protocol</name>

<t>Distributed rollback follows a two-phase protocol:</t>

<t><strong>Phase 1: Prepare</strong></t>

<t>The coordinator sends a prepare request to each affected agent:</t>

<figure title="Rollback Prepare Request" anchor="fig-prepare"><artwork><![CDATA[
POST /.well-known/cascade/rollback/prepare HTTP/1.1
Content-Type: application/json
Execution-Context: <prepare-ect>

{
  "rollback_id": "urn:uuid:...",
  "checkpoint_id": "ckpt-uuid",
  "scope": "sub_dag"
}
]]></artwork></figure>

<t>Each agent <bcp14>MUST</bcp14> respond with either:</t>

<t><list style="symbols">
  <t><spanx style="verb">"prepared"</spanx>: The agent has verified its checkpoint and is ready
to roll back.</t>
  <t><spanx style="verb">"cannot_prepare"</spanx>: The agent cannot roll back (e.g., checkpoint
expired, irreversible action).</t>
</list></t>

<t><strong>Phase 2: Execute</strong></t>

<t>If all agents respond <spanx style="verb">"prepared"</spanx>, the coordinator sends execute
requests in reverse topological order:</t>

<figure title="Rollback Execute Request" anchor="fig-execute"><artwork><![CDATA[
POST /.well-known/cascade/rollback HTTP/1.1
Content-Type: application/json
Execution-Context: <rollback-ect>

{
  "rollback_id": "urn:uuid:...",
  "checkpoint_id": "ckpt-uuid",
  "phase": "execute"
}
]]></artwork></figure>

<t>If any agent responds <spanx style="verb">"cannot_prepare"</spanx> in Phase 1, the
coordinator <bcp14>MUST</bcp14> either:</t>

<t><list style="symbols">
  <t>Proceed with partial rollback (if the unprepared agent is not
on the critical path), or</t>
  <t>Abort the rollback and escalate to HITL.</t>
</list></t>

</section>
<section anchor="partial-rollback-handling"><name>Partial Rollback Handling</name>

<t>When a distributed rollback cannot be completed fully, the
coordinator <bcp14>MUST</bcp14>:</t>

<t><list style="numbers" type="1">
  <t>Roll back all agents that responded <spanx style="verb">"prepared"</spanx>.</t>
  <t>Record the partial rollback result in the ECT DAG.</t>
  <t>Emit an ECT with <spanx style="verb">exec_act</spanx> value <spanx style="verb">"rollback_complete"</spanx> and
<spanx style="verb">cascade.status</spanx> set to <spanx style="verb">"partial"</spanx>.</t>
  <t>Include the list of agents that could not be rolled back in
the <spanx style="verb">cascade.failed_agents</spanx> extension claim.</t>
</list></t>

</section>
<section anchor="conflict-resolution-during-concurrent-rollbacks"><name>Conflict Resolution During Concurrent Rollbacks</name>

<t>When multiple rollback requests target overlapping portions of the
ECT DAG:</t>

<t><list style="numbers" type="1">
  <t>The rollback with the broader scope takes precedence (full
workflow &gt; sub-DAG &gt; single agent).</t>
  <t>If scopes are equal, the earlier rollback request (by timestamp)
takes precedence.</t>
  <t>The losing rollback request <bcp14>MUST</bcp14> be rejected with an error
indicating the conflicting rollback ID.</t>
</list></t>

<t>Agents <bcp14>MUST</bcp14> implement idempotent rollback: receiving the same
<spanx style="verb">rollback_id</spanx> twice <bcp14>MUST</bcp14> return the same result without
re-executing the rollback.</t>

</section>
</section>
<section anchor="rollback-evidence"><name>Rollback Evidence</name>

<section anchor="ect-nodes-for-rollback-actions"><name>ECT Nodes for Rollback Actions</name>

<t>Each rollback action <bcp14>MUST</bcp14> produce ECT nodes for audit:</t>

<dl>
  <dt>Rollback Start:</dt>
  <dd>
    <t><spanx style="verb">exec_act</spanx>: <spanx style="verb">"rollback_start"</spanx>, <spanx style="verb">par</spanx> references the error ECT
that triggered the rollback.</t>
  </dd>
</dl>

<figure title="Rollback Start ECT" anchor="fig-rb-start"><sourcecode type="json"><![CDATA[
{
  "jti": "rb-start-uuid",
  "exec_act": "rollback_start",
  "par": ["error-ect-uuid"],
  "ext": {
    "cascade.rollback_id": "urn:uuid:...",
    "cascade.checkpoint_id": "ckpt-uuid",
    "cascade.scope": "sub_dag",
    "cascade.reason": "Upstream cascading failure"
  }
}
]]></sourcecode></figure>

<dl>
  <dt>Rollback Complete:</dt>
  <dd>
    <t><spanx style="verb">exec_act</spanx>: <spanx style="verb">"rollback_complete"</spanx>, <spanx style="verb">par</spanx> references the rollback
start ECT.</t>
  </dd>
</dl>

<figure title="Rollback Complete ECT" anchor="fig-rb-complete"><sourcecode type="json"><![CDATA[
{
  "jti": "rb-complete-uuid",
  "exec_act": "rollback_complete",
  "par": ["rb-start-uuid"],
  "out_hash": "sha256:...",
  "ext": {
    "cascade.rollback_id": "urn:uuid:...",
    "cascade.status": "completed",
    "cascade.state_hash_before": "sha256:...",
    "cascade.state_hash_after": "sha256:...",
    "cascade.cascaded": [
      {
        "agent": "spiffe://example.com/agent/monitor",
        "status": "completed"
      },
      {
        "agent": "spiffe://example.com/agent/classify",
        "status": "escalated"
      }
    ]
  }
}
]]></sourcecode></figure>

</section>
<section anchor="rollback-audit-trail"><name>Rollback Audit Trail</name>

<t>The complete rollback audit trail is captured in the ECT DAG:</t>

<figure title="Rollback Audit Trail in ECT DAG" anchor="fig-rb-audit"><artwork><![CDATA[
  error ECT
     │
     ▼
  rollback_start ECT
     │
     ├──► agent-A rollback_complete ECT
     │
     ├──► agent-B rollback_complete ECT
     │
     └──► agent-C compensate ECT
]]></artwork></figure>

<t>Status values for individual agent rollbacks: <spanx style="verb">completed</spanx>,
<spanx style="verb">partial</spanx>, <spanx style="verb">escalated</spanx>, <spanx style="verb">failed</spanx>.</t>

</section>
</section>
</section>
<section anchor="ect-integration-1"><name>ECT Integration</name>

<t>This document defines the following new <spanx style="verb">exec_act</spanx> values for use
in ECT nodes <xref target="I-D.nennemann-wimse-ect"/>:</t>

<texttable title="New exec_act Values" anchor="fig-exec-act-values">
      <ttcol align='left'>exec_act Value</ttcol>
      <ttcol align='left'>Description</ttcol>
      <c><spanx style="verb">circuit_breaker_open</spanx></c>
      <c>Circuit breaker transitioned to OPEN state</c>
      <c><spanx style="verb">circuit_breaker_close</spanx></c>
      <c>Circuit breaker transitioned to CLOSED state</c>
      <c><spanx style="verb">checkpoint</spanx></c>
      <c>State snapshot before consequential action</c>
      <c><spanx style="verb">rollback_start</spanx></c>
      <c>Rollback initiated for a checkpoint</c>
      <c><spanx style="verb">rollback_complete</spanx></c>
      <c>Rollback finished (with status)</c>
      <c><spanx style="verb">compensate</spanx></c>
      <c>Compensating action executed in lieu of state restoration</c>
      <c><spanx style="verb">cascade_detected</spanx></c>
      <c>Cascading failure pattern detected</c>
</texttable>

<t>This document defines the following new <spanx style="verb">ext</spanx> claims for failure
context:</t>

<texttable title="New ext Claims for Cascade Prevention" anchor="fig-ext-claims">
      <ttcol align='left'>Claim</ttcol>
      <ttcol align='left'>Type</ttcol>
      <ttcol align='left'>Description</ttcol>
      <c><spanx style="verb">cascade.downstream_agent</spanx></c>
      <c>string</c>
      <c>SPIFFE ID of the downstream agent</c>
      <c><spanx style="verb">cascade.error_rate</spanx></c>
      <c>number</c>
      <c>Error rate that triggered the circuit breaker</c>
      <c><spanx style="verb">cascade.window_s</spanx></c>
      <c>number</c>
      <c>Sliding window duration in seconds</c>
      <c><spanx style="verb">cascade.cooldown_s</spanx></c>
      <c>number</c>
      <c>Cooldown duration in seconds</c>
      <c><spanx style="verb">cascade.reversible</spanx></c>
      <c>boolean</c>
      <c>Whether the checkpointed action can be undone</c>
      <c><spanx style="verb">cascade.rollback_uri</spanx></c>
      <c>string</c>
      <c>URI for rollback requests</c>
      <c><spanx style="verb">cascade.target</spanx></c>
      <c>string</c>
      <c>Target system of the checkpointed action</c>
      <c><spanx style="verb">cascade.ttl</spanx></c>
      <c>number</c>
      <c>Checkpoint time-to-live in seconds</c>
      <c><spanx style="verb">cascade.rollback_id</spanx></c>
      <c>string</c>
      <c>Unique identifier for a rollback operation</c>
      <c><spanx style="verb">cascade.checkpoint_id</spanx></c>
      <c>string</c>
      <c>JTI of the checkpoint being rolled back</c>
      <c><spanx style="verb">cascade.scope</spanx></c>
      <c>string</c>
      <c>Rollback scope: single, sub_dag, full_workflow</c>
      <c><spanx style="verb">cascade.status</spanx></c>
      <c>string</c>
      <c>Rollback result status</c>
      <c><spanx style="verb">cascade.reason</spanx></c>
      <c>string</c>
      <c>Human-readable reason for the action</c>
      <c><spanx style="verb">cascade.pattern</spanx></c>
      <c>string</c>
      <c>Detected cascade pattern type</c>
      <c><spanx style="verb">cascade.affected_agents</spanx></c>
      <c>number</c>
      <c>Count of agents affected by cascade</c>
      <c><spanx style="verb">cascade.blast_radius</spanx></c>
      <c>array</c>
      <c>SPIFFE IDs of affected agents</c>
      <c><spanx style="verb">cascade.cascaded</spanx></c>
      <c>array</c>
      <c>Per-agent rollback results</c>
      <c><spanx style="verb">cascade.failed_agents</spanx></c>
      <c>array</c>
      <c>Agents that could not be rolled back</c>
      <c><spanx style="verb">cascade.state_hash_before</spanx></c>
      <c>string</c>
      <c>State hash before rollback</c>
      <c><spanx style="verb">cascade.state_hash_after</spanx></c>
      <c>string</c>
      <c>State hash after rollback</c>
      <c><spanx style="verb">cascade.description</spanx></c>
      <c>string</c>
      <c>Human-readable description</c>
</texttable>

</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<section anchor="rollback-weaponization"><name>Rollback Weaponization</name>

<t>Malicious agents could attempt to force unnecessary rollbacks to
disrupt workflows.  Mitigations:</t>

<t><list style="numbers" type="1">
  <t>Rollback requests <bcp14>MUST</bcp14> be authenticated via the ECT signature
chain.  Only agents whose ECTs appear in the same workflow DAG
(identified by <spanx style="verb">wid</spanx>) are authorized to request rollback.</t>
  <t>Rollback requests from outside the originating workflow <bcp14>MUST</bcp14> be
rejected with HTTP 403.</t>
  <t>Agents <bcp14>SHOULD</bcp14> implement rate limiting on rollback requests to
prevent denial-of-service through rollback flooding.</t>
  <t>The two-phase rollback protocol provides a prepare phase where
agents can validate the rollback request before committing.</t>
</list></t>

</section>
<section anchor="circuit-breaker-manipulation"><name>Circuit Breaker Manipulation</name>

<t>An adversary could attempt to manipulate circuit breaker state to
either prevent legitimate circuit breaking or force unnecessary
circuit breaks:</t>

<t><list style="numbers" type="1">
  <t><strong>False error injection</strong>: A malicious agent could emit false
error ECTs to trigger circuit breakers.  At L2/L3
<xref target="I-D.nennemann-wimse-ect"/>, ECT signatures prevent forgery.
Agents <bcp14>SHOULD</bcp14> verify that error ECTs reference valid <spanx style="verb">par</spanx>
values within their own workflow DAG.</t>
  <t><strong>Circuit breaker suppression</strong>: An adversary could attempt to
reset circuit breakers by sending successful probe responses.
Agents <bcp14>MUST</bcp14> only accept probe responses from the actual
downstream agent (verified via ECT identity binding).</t>
  <t><strong>Status endpoint abuse</strong>: The <spanx style="verb">/.well-known/cascade/circuits</spanx>
endpoint reveals system health topology.  This endpoint <bcp14>MUST</bcp14>
require authentication and <bcp14>SHOULD</bcp14> be restricted to agents within
the same administrative domain.</t>
</list></t>

</section>
<section anchor="checkpoint-integrity"><name>Checkpoint Integrity</name>

<t>Checkpoint state snapshots contain sensitive system state.  Agents
<bcp14>MUST</bcp14>:</t>

<t><list style="numbers" type="1">
  <t>Encrypt stored checkpoint state at rest.</t>
  <t>Reference checkpoint state via <spanx style="verb">out_hash</spanx> only in ECTs; <bcp14>MUST NOT</bcp14>
include checkpoint contents in ECT claims.</t>
  <t>Verify <spanx style="verb">out_hash</spanx> integrity before executing rollback to prevent
rollback to a tampered state.</t>
  <t>Enforce checkpoint storage quotas to prevent checkpoint flooding
attacks.</t>
  <t>Purge expired checkpoints (past <spanx style="verb">cascade.ttl</spanx>).</t>
</list></t>

</section>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<section anchor="registration-of-execact-values"><name>Registration of exec_act Values</name>

<t>This document requests registration of the following <spanx style="verb">exec_act</spanx>
values in the ECT exec_act registry:</t>

<texttable title="exec_act Value Registrations" anchor="fig-iana-exec-act">
      <ttcol align='left'>Value</ttcol>
      <ttcol align='left'>Description</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c><spanx style="verb">circuit_breaker_open</spanx></c>
      <c>Circuit breaker transitioned to OPEN</c>
      <c>This document</c>
      <c><spanx style="verb">circuit_breaker_close</spanx></c>
      <c>Circuit breaker transitioned to CLOSED</c>
      <c>This document</c>
      <c><spanx style="verb">checkpoint</spanx></c>
      <c>State snapshot before consequential action</c>
      <c>This document</c>
      <c><spanx style="verb">rollback_start</spanx></c>
      <c>Rollback operation initiated</c>
      <c>This document</c>
      <c><spanx style="verb">rollback_complete</spanx></c>
      <c>Rollback operation finished</c>
      <c>This document</c>
      <c><spanx style="verb">compensate</spanx></c>
      <c>Compensating action executed</c>
      <c>This document</c>
      <c><spanx style="verb">cascade_detected</spanx></c>
      <c>Cascading failure pattern detected</c>
      <c>This document</c>
</texttable>

</section>
<section anchor="registration-of-ext-claims"><name>Registration of ext Claims</name>

<t>This document requests registration of the <spanx style="verb">ext</spanx> claims listed in
<xref target="fig-ext-claims"/> in the ECT extension claims registry.  All claims
use the <spanx style="verb">cascade.</spanx> namespace prefix.</t>

</section>
<section anchor="well-known-uri-registration"><name>Well-Known URI Registration</name>

<t>This document requests registration of the following well-known URI
suffixes per <xref target="RFC9110"/>:</t>

<texttable title="Well-Known URI Registrations" anchor="fig-iana-uris">
      <ttcol align='left'>URI Suffix</ttcol>
      <ttcol align='left'>Description</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c><spanx style="verb">cascade/circuits</spanx></c>
      <c>Circuit breaker status</c>
      <c>This document</c>
      <c><spanx style="verb">cascade/rollback</spanx></c>
      <c>Rollback request endpoint</c>
      <c>This document</c>
      <c><spanx style="verb">cascade/rollback/prepare</spanx></c>
      <c>Rollback prepare endpoint</c>
      <c>This document</c>
      <c><spanx style="verb">cascade/checkpoints</spanx></c>
      <c>Checkpoint retrieval</c>
      <c>This document</c>
</texttable>

</section>
</section>


  </middle>

  <back>


<references title='References' anchor="sec-combined-references">

    <references title='Normative References' anchor="sec-normative-references">



<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname="S. Bradner" initials="S." surname="Bradner"/>
    <date month="March" year="1997"/>
    <abstract>
      <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
  <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="8174"/>
  <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC7519">
  <front>
    <title>JSON Web Token (JWT)</title>
    <author fullname="M. Jones" initials="M." surname="Jones"/>
    <author fullname="J. Bradley" initials="J." surname="Bradley"/>
    <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
    <date month="May" year="2015"/>
    <abstract>
      <t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7519"/>
  <seriesInfo name="DOI" value="10.17487/RFC7519"/>
</reference>
<reference anchor="RFC7515">
  <front>
    <title>JSON Web Signature (JWS)</title>
    <author fullname="M. Jones" initials="M." surname="Jones"/>
    <author fullname="J. Bradley" initials="J." surname="Bradley"/>
    <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
    <date month="May" year="2015"/>
    <abstract>
      <t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7515"/>
  <seriesInfo name="DOI" value="10.17487/RFC7515"/>
</reference>
<reference anchor="RFC9110">
  <front>
    <title>HTTP Semantics</title>
    <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
    <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
    <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
    <date month="June" year="2022"/>
    <abstract>
      <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
      <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="97"/>
  <seriesInfo name="RFC" value="9110"/>
  <seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>

<reference anchor="I-D.nennemann-wimse-ect" target="https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/">
  <front>
    <title>Execution Context Tokens for Distributed Agentic Workflows</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="I-D.nennemann-agent-dag-hitl-safety" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/">
  <front>
    <title>Agent Context Policy Token: DAG Delegation with Human Override</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>


    </references>

    <references title='Informative References' anchor="sec-informative-references">

<reference anchor="I-D.nennemann-agent-gap-analysis" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/">
  <front>
    <title>Gap Analysis of IETF Standards for Autonomous AI Agent Networking</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>


    </references>

</references>


<?line 914?>

<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>

<t>This document absorbs and supersedes concepts from the earlier Agent
Error Recovery and Rollback (AERR) and Agent Task DAG (ATD) proposals.
It builds on the Execution Context Token specification
<xref target="I-D.nennemann-wimse-ect"/> for DAG-based audit trails and the Agent
Context Policy Token <xref target="I-D.nennemann-agent-dag-hitl-safety"/> for HITL
escalation of irreversible actions.  The circuit breaker pattern is
adapted from microservice architecture best practices.</t>

</section>


  </back>

<!-- ##markdown-source:
[encoded data, 13298 characters]
zyV2gcO02Ln//wDbzfQ5qHoAAA==

-->

</rfc>

