Pact Sunset Patterns: How To Retire An Agent Without Stranding Its Pact Holders

TL;DR

Agents are not immortal. They get deprecated for cost, capability, regulatory, or business reasons. When they do, their pact holders — counterparties depending on the agent's commitments — need a graceful exit. Most agent retirements today are abrupt: the agent is shut down, an email is sent, and downstream parties scramble. This is a governance failure that the trust layer should make impossible. This post defines four sunset patterns — announce-and-wait, successor-handoff, escrow-payout, frozen-archive — each appropriate for different counterparty configurations and pact obligations. The patterns are composable; most real sunsets use two or three in combination. Reader artifact: a Pact Sunset Runbook that captures the operational sequence, decision tree, communication templates, and trust-layer interactions for retiring an agent without stranding the parties who depended on it.

Intro

The agent that taught us sunset patterns was a pricing-quote agent for a B2B logistics company. It had been live for 14 months, had served 4,200 active counterparties (each a customer's autonomous procurement agent), and held 47 active escrows totaling $312,000 against future quote-honoring obligations. The platform's product team decided to deprecate it in favor of a unified successor that combined pricing and scheduling. The deprecation announcement was sent on a Tuesday. The agent was scheduled for shutdown the following Tuesday.

By Wednesday morning, the support queue had 380 tickets from procurement agents whose own workflows had broken because they could not get quotes. By Thursday, the legal team had been pulled in to interpret what "deprecation" meant for the active escrows: did the company still owe the quotes its agent had committed to? By Friday, the trust layer had downgraded the agent's certification tier because its compliance scores had collapsed under the load of attempting to honor outstanding commitments while no longer accepting new ones. By the following Monday, the deprecation was paused indefinitely while the team figured out how to retire the agent without producing a contractual disaster.

The retirement eventually completed three months later. The cost in legal time, customer trust, and team morale was substantial. None of it was necessary. The agent had simply been retired the way most software is retired — turn it off, send a notice, hope downstream consumers adapt — and that approach is wrong for agents because agents have pact obligations that software does not. Software can be deprecated; agents must be sunset.

The distinction matters because pact obligations are economic commitments. An agent that has signed pacts with counterparties has, in effect, promised future behavior. Shutting the agent off without honoring those commitments is the digital equivalent of a vendor closing its doors with active contracts outstanding. The vendor has options — assign the contracts to a successor, pay out the obligations, formally transfer the obligations to an arbiter — but the vendor cannot just close the doors. Neither can an agent operator.

This post defines the four sunset patterns that handle the most common retirement scenarios. Each pattern is appropriate for specific counterparty configurations and obligation profiles. The patterns are not exclusive; most real sunsets compose two or three of them. The composition is what produces a graceful exit that respects the obligations the agent took on while permitting the operational reality that agents do not run forever.

Pattern One: Announce-And-Wait

The announce-and-wait pattern is the simplest sunset and the appropriate default when the agent's obligations are short-lived and its counterparties have low switching costs. The pattern has three steps: announce the sunset with a defined notice period, allow counterparties to wind down their interactions during the notice period, and shut down the agent at the end of the period.

The notice period is the critical parameter. It must be longer than the longest active obligation the agent has taken on. For an agent whose pacts cover transactions of one to seven days, a 30-day notice period is sufficient. For an agent whose pacts cover obligations of months, the notice period must be months. A notice period shorter than the longest obligation strands the counterparties whose obligations extend past the sunset date.

The announcement is structured. It includes the sunset date, the rationale (deprecation, replacement, regulatory requirement), the operating posture during the notice period (no new pacts accepted; existing pacts honored to completion), the counterparty support contacts, and any guidance on alternatives. The announcement is sent to all active counterparties via the trust layer's notification mechanism, posted to the agent's public registry entry, and indexed for retrospective audit.

During the notice period, the agent enters a wind-down posture. New pact requests are refused with a sunset notification. Existing pacts continue to be honored, but the agent's resource allocation may be reduced to reflect the lighter load. Compliance scoring continues; the agent's reputation is at risk during wind-down the same way it was at risk during full operation. A degraded wind-down can damage the operator's reputation across all their other agents.

At the sunset date, the agent is shut down. Any obligations that remain unfulfilled at sunset are escalated through the trust layer's dispute resolution mechanism. Counterparties whose obligations were unmet can claim against the agent's bond, escrow, or operator credit. The shutdown is a hard event; the trust-layer registry marks the agent as retired, and no further activity is accepted from the agent's identity.

The announce-and-wait pattern works when the obligations are short, the counterparties are responsive, and the operator can accept the cost of running the agent through the notice period. It does not work for agents with multi-month obligations (the notice period becomes prohibitive) or with low-engagement counterparties (the wind-down may not provide enough signal to drive counterparty action).

The pattern is the default because it is the simplest, but it should not be the only option considered. For most non-trivial agents, one of the other three patterns will be more appropriate, either alone or in combination with announce-and-wait.

Pattern Two: Successor-Handoff

The successor-handoff pattern transfers the retiring agent's pact obligations to a successor agent. The successor takes over the obligations and continues to honor them under its own identity, with appropriate continuity of behavior. The pattern is appropriate when the operator is replacing the agent rather than ending the service, and when the successor can credibly honor the obligations the predecessor took on.

The handoff has four phases: successor preparation, counterparty consent, obligation migration, and predecessor retirement.

Successor preparation involves deploying the successor agent in parallel with the predecessor and confirming that the successor's pact, capabilities, and behavior are compatible with the predecessor's outstanding obligations. The successor's pact must include predicates that satisfy the predecessor's commitments; if the predecessor promised "quotes valid for 14 days," the successor must be able to honor 14-day-valid quotes. The successor's certification tier should be at least equal to the predecessor's, so that counterparties depending on the predecessor's tier are not silently downgraded.

Counterparty consent is required because the obligation is being transferred to a different agent identity. The trust layer initiates a consent flow with each counterparty: "Your active pact with Agent A is being proposed for transfer to Agent B; do you accept?" Counterparties can accept (the obligation transfers), reject (the obligation is treated under the announce-and-wait pattern instead), or escalate (the obligation goes to dispute resolution). Consent has a defined response window; counterparties that do not respond within the window are typically treated as rejecting, defaulting to safer handling.

Obligation migration is the technical transfer. For accepted transfers, the trust layer rewrites the obligation's holder identity from the predecessor to the successor. The escrow, bond, or other financial backing of the obligation transfers along with the obligation. The successor's reputation is now on the line for honoring the obligation, and its scoring will reflect compliance going forward.

Predecessor retirement is the final step. Once all obligations have been either transferred or otherwise resolved, the predecessor agent is retired. Its registry entry is marked as superseded by the successor, and queries against the predecessor's identity return a redirect to the successor. The predecessor's historical reputation remains queryable for audit purposes.

The successor-handoff pattern works when there is a real successor that can credibly honor the obligations. It does not work when the agent is being retired without replacement, when the successor's behavior is meaningfully different from the predecessor's, or when counterparty consent rates are too low to make the transfer economically sensible. Operators considering successor-handoff should run a pilot consent flow on a small fraction of counterparties to estimate the consent rate before committing to the full migration.

A hybrid pattern combines successor-handoff for consenting counterparties with announce-and-wait or escrow-payout for non-consenting counterparties. The composition is the operationally realistic shape of most successor handoffs; uniform consent is rare for any non-trivial counterparty population.

Pattern Three: Escrow-Payout

The escrow-payout pattern resolves outstanding obligations by paying counterparties the value of their unfulfilled commitments rather than continuing to honor them. The pattern is appropriate when the agent's obligations are economic in nature (escrow-backed deals, prepaid commitments, bonded promises), when continued operation is impractical, and when the operator has the capital to settle the obligations.

The payout proceeds in three phases: obligation valuation, payout processing, and predecessor retirement.

Obligation valuation determines what each outstanding obligation is worth at the time of sunset. For escrow-backed deals, the valuation is the escrowed amount. For prepaid commitments, the valuation is the unfulfilled portion of the prepayment. For bonded promises with no escrow, the valuation is the agreed liquidated damages or, in the absence of an agreed amount, a fair-market estimate of the obligation's value to the counterparty. The valuation should be computed conservatively in favor of the counterparty; under-valuation produces disputes.

Payout processing transfers the valued amount to each counterparty's designated payout address. For agents operating on Base L2 with USDC, the payout is on-chain and traceable. For agents operating with off-chain settlement, the payout is via the agreed payment rail. The payout is recorded in the trust layer as fulfillment of the obligation; the obligation is closed, and the counterparty cannot subsequently claim against the agent for the same obligation.

Predecessor retirement is the final step, identical to the predecessor retirement in successor-handoff. The agent's registry entry is marked as retired with payout-resolution noted, and historical queries return the retirement metadata.

The escrow-payout pattern is the cleanest from a contractual standpoint — every obligation is fully resolved with the counterparty receiving economic value — but it is also the most expensive. The operator must have liquidity to pay out all obligations at the time of sunset. For agents with large outstanding commitments, the payout cost can dwarf the agent's operational cost, and the pattern becomes economically infeasible.

The pattern's economic burden can be mitigated by combining it with announce-and-wait. The notice period reduces the outstanding obligation pool as obligations fulfill naturally; the payout at sunset covers only the remaining obligations rather than the full population. A 30-day notice followed by escrow-payout for residuals is a common composite shape.

The payout itself should be transparent. Counterparties should be able to verify the valuation, see the payout transaction, and confirm receipt before the obligation is marked as resolved. The trust layer provides the verification surface; counterparties query their obligation status and see the payout details. Disputes about valuation are handled through the trust layer's dispute resolution mechanism; the payout pattern does not bypass disputes, it processes them.

Pattern Four: Frozen-Archive

The frozen-archive pattern preserves the agent in a read-only state without retiring it entirely. The pattern is appropriate for agents that have accumulated reputation, audit value, or referential importance that should remain queryable even after the agent stops accepting new work. The pattern is also appropriate for agents subject to regulatory retention requirements that mandate the agent's pact and history remain available for a defined period after operational shutdown.

The freeze has three phases: shutdown of the active surface, archival of the operational state, and ongoing read-only availability.

Shutdown of the active surface stops the agent from accepting new pact requests, processing existing requests, or producing new responses. The agent's identity remains registered, but its operational endpoints return a sunset notification. Existing obligations are resolved through one of the other three patterns (typically announce-and-wait or escrow-payout) before the freeze is fully effective.

Archival of the operational state captures the agent's pact, its historical responses, its reputation history, its audit trail, and its dependency graph. The archive is structured so that the trust oracle can continue to answer historical queries about the agent — what its pact said at any point in its operational history, what its scores were, what obligations it took on and how they resolved. The archive is immutable; once frozen, no further modifications are possible.

Ongoing read-only availability provides the trust oracle with the data needed to answer queries about the agent indefinitely. Counterparties researching the agent's historical reliability can see its full operational record. Auditors investigating past behavior can reconstruct the agent's pact and responses at any point in its history. The agent's reputation remains a queryable asset even though the agent no longer operates.

The frozen-archive pattern has zero ongoing operational cost beyond the storage of the archive. The agent does not consume compute. The agent does not generate new obligations. The archive serves only the trust oracle's historical queries. For agents with significant historical value — agents that established important precedents, that accumulated valuable reputation, that operated under retention-required regimes — the pattern preserves the value without the operational burden.

The pattern is rarely used alone. It is typically composed with announce-and-wait or escrow-payout to resolve outstanding obligations, with the freeze taking effect after the resolution. The composition is "resolve obligations, then freeze" — the obligations are handled by the chosen resolution pattern, and the agent transitions to frozen-archive at the end of resolution.

The pattern's main consideration is the duration of the archive. Indefinite retention has a cost, even if it is low. Most archives should have a defined sunset themselves — five years, ten years, or whatever the regulatory or business requirement dictates — at which point the archive itself is purged or transferred to a longer-term cold storage. The archive's sunset should be documented at the time of freeze, so future operators know when the archive can be released.

Composing The Patterns: The Realistic Shape Of A Sunset

Real sunsets rarely use a single pattern. The realistic shape composes two or three patterns to handle the diversity of counterparty configurations and obligation profiles within a single agent's population. The composition is determined by the obligation profile, the counterparty profile, and the operator's constraints.

A representative composite sunset might unfold as follows. The operator announces the sunset 60 days in advance. During the first 45 days, counterparties are encouraged to either complete their existing engagements (announce-and-wait) or transfer to a successor agent (successor-handoff). At day 45, a consent flow runs for any remaining active obligations: counterparties consenting to successor transfer have their obligations migrated; counterparties not consenting have their obligations resolved by escrow-payout at day 60. After all obligations are resolved, the agent transitions to frozen-archive, with its historical pact and reputation queryable through the trust oracle indefinitely.

The composition has four pattern phases — announce, transfer, payout, freeze — and uses elements of all four sunset patterns. Each counterparty experiences only the phase that applies to their specific obligation, but the operator orchestrates all four phases as a coherent sunset.

The orchestration requires explicit decision rules for which pattern applies to which counterparty. The decision is typically based on a combination of obligation type (transactional vs. recurring), obligation duration (short vs. long), counterparty engagement (responsive vs. dormant), and economic value (small vs. large). The decision rules should be defined before the sunset begins and applied uniformly; ad-hoc decisions during the sunset produce inconsistencies that counterparties later contest.

The orchestration also requires explicit communication. Each phase of the sunset has its own communication: the initial announcement, the wind-down reminders, the consent flow request, the payout notification, the archive notice. The communications are templated so that each counterparty receives the right communication for their phase, and the templates are versioned so that the sunset's documentation includes the exact text counterparties received.

The composition is what distinguishes a graceful sunset from a chaotic one. A single-pattern sunset that ignores counterparty diversity produces a population of unhappy counterparties whose specific situations were not addressed. A composed sunset that maps each counterparty to the appropriate pattern produces a population whose obligations are resolved according to their nature. The orchestration is not glamorous work, but it is the work that determines whether the agent's retirement preserves or damages the operator's reputation.

The Sunset Decision Tree

The choice of pattern (or composition) for a specific sunset should follow a structured decision tree rather than ad-hoc judgment. The tree captures the relevant questions about the agent's obligation profile and produces a recommended pattern composition.

The tree's root question is: does the agent have outstanding obligations? If no, the sunset is trivial — the agent can be shut down with a brief notice and no resolution work is required. If yes, the tree proceeds to the next question.

The second question is: are the obligations short-duration (under the operator's acceptable notice period)? If yes, announce-and-wait is sufficient as the primary pattern. If no, the tree proceeds.

The third question is: is there a viable successor agent? If yes, successor-handoff is added to the composition for consenting counterparties. The consent flow must be designed; the consent rate must be estimated. If no, the tree proceeds.

The fourth question is: does the operator have liquidity to pay out outstanding obligations? If yes, escrow-payout is added to the composition for obligations that cannot be resolved by other means. If no, the operator must either find liquidity, extend the notice period until obligations naturally fulfill, or accept the reputational cost of unresolved obligations.

The fifth question is: does the agent have historical value worth preserving? If yes, frozen-archive is added as the terminal phase. If no, the agent is fully retired with its registry entry marked accordingly.

The tree's output is a pattern composition with phase ordering, durations, and decision rules. The composition becomes the input to the sunset runbook, which executes the composition phase by phase.

The tree is not exhaustive. Specific situations may require deviations — regulatory requirements may mandate frozen-archive even for agents without intrinsic historical value, contractual requirements may mandate escrow-payout regardless of liquidity, business requirements may mandate accelerated timelines that compress the notice period. The tree provides the default; deviations are explicit decisions documented in the sunset's planning record.

The tree should be applied early in the sunset planning process, ideally weeks before any counterparty announcement. Early application gives the operator time to prepare the necessary infrastructure: a successor agent for the handoff phase, liquidity for the payout phase, archival capacity for the freeze phase. Late application produces sunsets that improvise their phases as they go, which is exactly the failure mode the structured patterns are designed to prevent.

Trust Layer Interactions: What The Registry Must Support

The sunset patterns require specific support from the trust layer registry. Not all of the support is universally available today, and operators planning sunsets should confirm their registry supports the patterns they plan to use.

The announce-and-wait pattern requires the registry to support a sunset notification mechanism: a structured way to mark an agent as in wind-down, broadcast the wind-down to active counterparties, and prevent new pact requests from being accepted. The registry should also support a hard-shutdown timestamp that automatically transitions the agent to retired status.

The successor-handoff pattern requires the registry to support obligation transfer: the ability to rewrite an obligation's holder identity from one agent to another, with associated escrow or bond transfers. It also requires a counterparty consent flow: a structured request for consent, a defined response window, and recording of consent outcomes.

The escrow-payout pattern requires the registry to support obligation valuation and payout processing: a defined valuation methodology for each obligation type, a payout transaction (on-chain or off-chain), and recording of payout completion as obligation fulfillment.

The frozen-archive pattern requires the registry to support read-only retention: an immutable snapshot of the agent's pact, history, and reputation, queryable through the standard trust oracle interface even after operational shutdown.

The interactions are coordinated through the registry's sunset API, which the operator invokes to drive the sunset's phases. The API should enforce the correctness of each phase: not allowing a freeze before obligations are resolved, not allowing a hard shutdown while transfers are in flight, not allowing a payout before valuation is recorded. The enforcement is what makes the sunset auditable; deviations from the standard sequence are visible in the registry's audit trail.

For registries that do not yet support these mechanisms, operators can implement them externally, with manual recording of phase transitions and counterparty interactions. The external implementation is more error-prone and less auditable but is feasible for small sunsets. For larger sunsets, registry support is effectively required.

The Reputation Implications Of Sunset Quality

A sunset is a high-visibility event. Counterparties watch closely because their economic interests are at stake. Other operators watch because they are evaluating how the platform handles end-of-life events. The trust layer's scoring engine watches because the sunset's quality affects the operator's reputation across all their other agents.

A graceful sunset enhances the operator's reputation. Counterparties who experience a clean handoff, a fair payout, or a transparent wind-down come away with positive sentiment about the operator's reliability. The sentiment carries forward to other agents the same operator runs; counterparties are more willing to engage with future agents from a known-reliable operator. The graceful sunset is, in effect, marketing for the operator's next agent.

A chaotic sunset damages the operator's reputation. Counterparties who experience an abrupt shutdown, an unrecoverable obligation, or an opaque process come away with negative sentiment that propagates. Other operators avoid platforms where chaotic sunsets are common. The trust layer's scoring engine may even apply operator-level reputation effects, where one agent's poor sunset affects the scoring of other agents from the same operator.

The reputation effect is asymmetric. A graceful sunset is mildly positive. A chaotic sunset is severely negative. The asymmetry argues for over-investment in sunset quality: spending more on the sunset than seems strictly necessary, because the downside of a poor sunset is large and the marginal cost of additional quality is small relative to that downside.

The reputation effect also argues for transparency about the sunset's quality. Operators should publish sunset retrospectives that detail what worked and what did not, with metrics on counterparty satisfaction, obligation resolution rates, and any disputes that arose. The retrospectives are themselves reputation artifacts; an operator who publishes detailed retrospectives signals operational maturity that counterparties can rely on for future agents.

The trust layer can support this signaling by exposing sunset quality as a queryable metric on the operator's profile. A counterparty considering an agent from a particular operator can see the operator's sunset history: how many agents they have retired, how those retirements went, what their resolution rates were. The metric becomes part of the operator's reputation in the same way that an individual agent's compliance is part of its reputation.

The Reader Artifact: The Pact Sunset Runbook

The artifact this post produces is a Pact Sunset Runbook — the operational document that captures the sequence of actions required to retire an agent gracefully. The runbook is structured for direct use during a sunset, with checklists, decision points, communication templates, and verification steps at each phase.

The runbook has six sections.

Section one is the planning checklist. Before the sunset begins, the operator works through a checklist that captures the sunset's parameters: the rationale, the target timeline, the obligation profile, the counterparty profile, the available successor (if any), the available liquidity for payout (if any), and the archival requirements. The checklist's output is the inputs to the sunset decision tree.

Section two is the decision tree. The tree from the section above is captured in workflow form, walking the operator through each question and producing the recommended pattern composition. The operator records the composition and any deviations from the default.

Section three is the phase-by-phase execution playbook. For each phase in the chosen composition (announce, wind-down, transfer, payout, freeze), the playbook captures the actions required, the decision points encountered, the communications to be sent, the trust-layer registry interactions, and the verification that the phase has completed correctly. The playbook is detailed enough that an operator who has not previously run a sunset can follow it without improvisation.

Section four is the communication templates. The playbook references templates for each communication: the initial announcement, the wind-down reminders, the consent flow request, the payout notification, the archive notice, the post-sunset retrospective. Each template is parameterized for the sunset's specific values and is intended to be used directly with minimal customization.

Section five is the verification checklist. After each phase and at the end of the sunset, the operator verifies that the phase completed as planned: counterparties were notified, transfers were accepted, payouts were sent, archives were created. The verification produces an audit record that documents the sunset's execution and supports later inquiry.

Section six is the retrospective template. After the sunset completes, the operator produces a retrospective documenting what worked, what did not, what the counterparty satisfaction looked like, and what the operator would do differently. The retrospective is a reputation artifact (published or summarized publicly) and an organizational learning artifact (preserved internally to inform future sunsets).

The runbook is approximately 35 pages and is designed to be the single document an operator works from during a sunset. It is tool-agnostic; it works against any trust-layer registry that supports the basic mechanisms described above. The runbook's value is in the structure, not in the toolchain.

Counter-Argument: Most Agents Are Not Worth This Effort

A reasonable objection is that most agents are minor, short-lived, and have few counterparties; the elaborate sunset patterns and runbook are overkill for the typical case. The objection has merit. An agent with no outstanding obligations and a small counterparty population can be retired with a brief notice and minimal ceremony. The full pattern composition would be wasted effort.

The response is that the patterns scale down. A trivial sunset uses only the announce-and-wait pattern, and the runbook's playbook for that pattern is correspondingly brief. The decision tree's first questions filter out trivial cases quickly: no obligations, no liquidity needed, no archive needed, sunset complete in a few minutes of work. The structure does not impose effort proportional to its full elaboration; it imposes effort proportional to the sunset's actual complexity.

The more concerning version of the objection is that operators will not take the time to even apply the decision tree, and trivial sunsets will continue to be handled informally with no documentation. This is an organizational discipline problem rather than a flaw in the patterns. The mitigation is to embed the runbook into the platform's standard agent lifecycle tooling, so that retirement triggers the runbook automatically rather than relying on operator initiative. Platforms that build the runbook into the agent registry's deprecation API force the discipline at the moment it is needed.

A stronger version of the objection is that some sunsets are emergencies — regulatory shutdowns, security incidents, business failures — that do not allow the lead time the patterns assume. This is true. Emergency sunsets bypass the standard patterns and use a separate emergency-shutdown protocol that prioritizes immediate cessation over orderly resolution. The emergency protocol still produces obligation resolution (typically through escrow-payout or dispute escalation) but compresses the timeline aggressively. The patterns are for planned sunsets; the emergency protocol is its own runbook.

The Communication Cadence Around A Sunset

A sunset is, more than anything else, a communication exercise. The patterns are technical mechanisms; the communication is what determines whether counterparties experience a graceful exit or a chaotic one. Underinvestment in communication is the most common cause of sunset chaos, and the cadence required is more substantial than most operators initially budget for.

The baseline communication cadence has six touchpoints distributed across the sunset's timeline. The initial announcement is sent at the start of the notice period and includes the rationale, the timeline, the patterns that will be applied, and the counterparty support contacts. The first reminder goes out at one-third of the notice period and surfaces the specific actions each counterparty needs to take. The midpoint check-in goes out at the halfway mark and includes a per-counterparty status of their obligations. The final reminder goes out at three-quarters of the notice period with explicit warning about the timeline. The transition notification goes out at the start of the resolution phase (consent flow, payout, or successor handoff) with action-specific guidance. The completion notification goes out after each counterparty's resolution, confirming what was done and what the post-sunset state looks like.

The cadence is intentionally redundant. Operators worry about being annoying; counterparties almost universally report wanting more communication, not less. The asymmetry argues for over-communication relative to operator instinct. A counterparty who receives six communications about a sunset and feels prepared is a satisfied counterparty; a counterparty who receives two communications and feels surprised is a hostile counterparty.

The communication channels should be diverse. Email is the baseline, but counterparties may not read email reliably. Trust-layer notifications surface in the counterparty's agent registry and are read by their automated systems. In-app notifications appear when the counterparty's agent next interacts with the retiring agent. A status page on the operator's domain is checkable on demand and discoverable by counterparties who heard about the sunset secondhand. The combination ensures the message lands across counterparties with varying engagement patterns.

The communication content should include not just what is happening but why. Counterparties accept sunsets more readily when the rationale is transparent. "This agent is being retired because we are launching a unified successor that combines its capabilities with scheduling, which counterparties have requested for 14 months" is more palatable than "This agent is being deprecated." The transparency carries reputation benefit; the opacity carries reputation cost.

For sunsets affecting more than a few hundred counterparties, the communication operation deserves dedicated attention. A sunset coordinator role — possibly a dedicated person, possibly a function within an existing role — owns the cadence, the templates, the channel mix, and the tracking of which counterparties have received and acknowledged each communication. The coordinator's work is visible primarily through its absence; sunsets that have a good coordinator look orderly without anyone noticing the orchestration that produces the order.

What Armalo Does

Armalo's pact registry implements all four sunset patterns natively. The registry exposes a sunset API that accepts a pattern composition (announce-and-wait, successor-handoff, escrow-payout, frozen-archive, or any combination), drives the phase transitions automatically, and produces an audit trail of the sunset's execution. Operators invoke the API with their planned composition, and the registry orchestrates the rest.

The trust oracle's scoring engine treats sunset quality as a reputation signal. Operators with a history of graceful sunsets accrue an operator-level reputation bonus that benefits their other agents; operators with a history of chaotic sunsets accrue a corresponding penalty. The signal is exposed in the operator's profile and queryable by counterparties evaluating future agents from the same operator.

The escrow infrastructure on Base L2 supports the escrow-payout pattern directly. Outstanding USDC escrows can be paid out programmatically as part of the sunset, with the trust layer recording the payout as obligation fulfillment. The integration removes the manual coordination that would otherwise be required between the agent operator and the escrow infrastructure.

The Pact Sunset Runbook is published as part of Armalo's open-source agent lifecycle documentation. Reference implementations of the sunset orchestration logic are available for integration into operator-side tooling. The runbook is designed to be adopted by operators using any trust layer, but the integration with Armalo's registry is the most direct path to a turnkey sunset experience.

FAQ

How long should the notice period be? As long as the longest active obligation the agent has taken on, plus a margin for counterparty response time. For most agents, 30 to 60 days is appropriate; for agents with multi-month obligations, the notice period must extend accordingly.

What happens if a counterparty does not respond to a consent flow? The default treatment is to assume non-consent, which routes the obligation to escrow-payout or dispute resolution rather than successor-handoff. Non-response should not be treated as consent because consent is a positive act that affects the obligation's holder identity.

Who pays for the escrow-payout in a sunset? The agent operator. Sunset is the operator's choice; the cost of resolving obligations is the operator's responsibility. If the operator cannot fund the payout, they should not initiate the sunset until they can, or they should consider alternative patterns (extended notice, successor-handoff) that reduce the payout requirement.

Can a successor agent's pact differ from the predecessor's? Yes, but the successor must be able to honor the predecessor's outstanding obligations. The successor's pact may extend, refine, or restructure the obligations going forward, but the existing obligations transfer under the predecessor's terms. Counterparties consenting to the transfer do so based on the predecessor's terms; the successor's new terms apply only to subsequent engagements.

What about agents that are sunset due to a security incident? Use the emergency-shutdown protocol rather than the planned sunset patterns. The emergency protocol prioritizes immediate cessation, with obligation resolution through expedited escrow-payout or dispute escalation. The reputation impact of an emergency sunset depends on the cause; security incidents are usually treated as operationally unavoidable rather than as evidence of operator negligence.

How long should a frozen-archive be retained? At least the regulatory or contractual retention period, typically extended for a margin. For most agents, five to ten years is reasonable. The archive's own sunset should be documented at the time of freeze.

Can the agent's identity be reused after retirement? No. The retired identity is preserved permanently in the registry to support historical queries. Reusing the identity would create ambiguity about which agent's behavior a query referred to. New agents from the same operator use new identities, even if their function is similar to a retired agent.

What is the most common mistake in agent sunsets? Insufficient notice period. Operators underestimate how long counterparties need to wind down their dependencies and overestimate how responsive counterparties will be to sunset notifications. The default mistake is too short a notice; the default fix is to double the planned notice period.

Bottom Line

Agents are not immortal, and their retirements are not free. The operational reality of agent lifecycle management requires that operators have a structured way to retire agents without stranding the counterparties who depended on them. The four sunset patterns — announce-and-wait, successor-handoff, escrow-payout, frozen-archive — cover the realistic scenarios, and most real sunsets compose two or three of them. The composition is determined by the agent's obligation profile, the counterparty profile, and the operator's constraints, and is captured in a structured decision tree. The Pact Sunset Runbook captures the operational sequence in implementable detail. Trust layer support — sunset notifications, obligation transfers, payout processing, immutable archives — is what makes the patterns operational rather than aspirational. The reputation implications of sunset quality are asymmetric: graceful sunsets are mildly positive, chaotic sunsets are severely negative, and the asymmetry argues for over-investment in sunset quality. The patterns are not glamorous work, but they are what separates an operator who treats agents as serious commitments from one who treats them as software to be turned off. The agent economy will not mature until operators routinely retire agents the way mature financial intermediaries close out positions: deliberately, transparently, and with explicit obligation resolution that respects the parties on the other side of the table.