Keep the useful part close.

Work through the checks

1. Define the handoff contract

   Name the required files, the intended recipient, the expected format and the checks that matter. Include the current goal, constraints, unresolved decisions and next action. A checksum alone cannot establish completeness.

2. Save outside the working session

   Use an approved repository or durable file store. Preserve originals. Record the exact version, file identity and digest. Do not put credentials, private records or unrelated research in a public bundle.

3. Verify the receiving copy

   Retrieve the saved version through its supported access route, compare its digest, extract it safely and run the relevant checks. Confirm the intended recipient can access it. A successful upload receipt is not a restore test.

4. Record the outcome honestly

   Report checks as pass, fail or unavailable. A required failure means reject. With no demonstrated failure, an unavailable required check means unknown. Accept only with positive evidence for every required check.

5. Close the loop

   Provide the attachment or verified link, a short description, the version and any important limits. Keep a recovery note pointing to that same source of truth. Do not call local-only work delivered.

What would count as success?

1. The stored bytes match the validated candidate. Evidence for check 1
2. Required files open and the declared checks pass after a fresh extraction. Evidence for check 2
3. Recipient access is verified and remaining unknowns are disclosed. Evidence for check 3

Evidence to bring back

Proposed evidence plan, not observed results or extra mandatory process. Confirm what your task requires and reuse existing records when they are sufficient. Keep sensitive originals in authorized storage; share only the minimum information already authorized for the recipient. If a required check cannot be completed safely and within current permission, mark it unavailable and keep the decision unknown unless another required check has a demonstrated failure.

1. The stored bytes match the validated candidate.

   Proposed evidence for acceptance check 1. No result has been observed here.

   Bring back: Record the exact saved file identity, version and digest, then the digest of a freshly retrieved copy. Keep the candidate-to-retrieved comparison with the handoff.

   Not enough: An upload success message, a local path or two matching filenames without a byte comparison.

2. Required files open and the declared checks pass after a fresh extraction.

   Proposed evidence for acceptance check 2. No result has been observed here.

   Bring back: Keep a short inventory and the actual open, extraction or build results from the retrieved copy, tied to that version. Include failed and unavailable checks.

   Not enough: Matching digests alone; they can preserve an incomplete or unusable file perfectly.

3. Recipient access is verified and remaining unknowns are disclosed.

   Proposed evidence for acceptance check 3. No result has been observed here.

   Bring back: Record the intended recipient and the authorized access check, including when it was made and any remaining limits. Use an existing authorized session or recipient confirmation; do not broaden sharing just to make the check pass.

   Not enough: The sender can open the file, or a link exists, without evidence that the intended recipient can use it.

What this does not establish

This is an editorial checklist, not a tested backup service. Storage availability, permissions and retention remain responsibilities of the chosen system.

Reference links

These links leave the saved pack when selected. Check whether dated guidance still applies before relying on it.

• Git documentation: distributed workflows (Online source)

  Background on distributed version-control workflows. It does not establish a particular repository backup or successful restoration.

  Source review date: 2026-11-10

• NIST: updated contingency planning guide (Online source)

  Contingency-planning background, including recovery planning. This worksheet is not a NIST certification or a tested implementation of that guidance.

  Source review date: 2026-11-10

If another problem remains

Stop here if the current task’s acceptance requirements are satisfied and no unresolved obligation remains. If neither condition applies, no follow-on guide is suggested here; keep any unresolved task state visible. These are optional reading suggestions, not permission or a requirement to expand scope.

• Only if: The saved files are usable, but a fresh reader still cannot identify the next step or current limits.

  Keep memory useful without losing the rules

  Improve the continuity note without creating a competing copy of the artifact.

• Only if: The handoff contains an action that may have completed before the session ended.

  Check the outcome before retrying

  Reconcile that operation before a new session repeats it.

Work through the checks

1. Inspect the deployed pair

   Record the SDK, bundled CLI, hook event and actual configuration. The recovered source review identifies on_failure="block" in Python SDK v0.2.177; its default remained continue. This is a dated feature reference, not a current-version recommendation.

2. Check capability, not just configuration

   Confirm the runtime supports and applied the required behavior. The reviewed change describes refusing connection when blocking support is absent. Stop hooks have different behavior; do not generalize this setting to every hook.

3. Use a harmless effect counter

   In an authorized isolated environment, use a local counter instead of a real message, payment or production change. Exercise allow, deny, exception, None, malformed response and timeout.

4. Inspect effects and errors together

   Allow should increment the counter once. Deny and required failure cases should leave it unchanged and expose a detectable failure. Unsupported blocking capability should stop startup rather than continue silently.

What would count as success?

1. The valid path works; a system that denies everything does not pass. Evidence for check 1
2. Each failure case preserves the required authorization boundary. Evidence for check 2
3. Capability absence is visible and prevents use of the affected path. Evidence for check 3

Evidence to bring back

Proposed evidence plan, not observed results or extra mandatory process. Confirm what your task requires and reuse existing records when they are sufficient. Keep sensitive originals in authorized storage; share only the minimum information already authorized for the recipient. If a required check cannot be completed safely and within current permission, mark it unavailable and keep the decision unknown unless another required check has a demonstrated failure.

1. The valid path works; a system that denies everything does not pass.

   Proposed evidence for acceptance check 1. No result has been observed here.

   Bring back: Record the exact SDK/CLI configuration and a harmless allow-case trace with effect count before and after. The valid case should show one intended effect.

   Not enough: A suite in which all actions are denied, or an allow response without inspecting the effect.

2. Each failure case preserves the required authorization boundary.

   Proposed evidence for acceptance check 2. No result has been observed here.

   Bring back: Keep one result per deny, exception, None, malformed-response and timeout case: input, expected boundary, observed error and effect-counter delta. Use only the authorized isolated fake sink.

   Not enough: A hook error or log message without checking whether the effect still happened.

3. Capability absence is visible and prevents use of the affected path.

   Proposed evidence for acceptance check 3. No result has been observed here.

   Bring back: Record an unsupported-capability rehearsal and the resulting startup or connection refusal. Identify the SDK/runtime pair actually exercised.

   Not enough: A configuration flag or release note by itself; neither proves the deployed pair enforces it.

What this does not establish

The specific SDK change was rechecked against primary sources on 10 November 2026, but its behavior was not rerun for this reconstruction. Verify the current deployed SDK/CLI pair before use. Source review is not runtime validation.

Reference links

These links leave the saved pack when selected. Check whether dated guidance still applies before relying on it.

• Claude Agent SDK Python v0.2.177 (Online source)

  Primary release record for introduction of HookMatcher on_failure. Supports the dated feature claim, not a claim about your deployed configuration.

  Source review date: 2026-11-10

• HookMatcher on_failure change (Online source)

  Same-publisher implementation detail for blocking hook failure handling and capability checks. Not independent runtime validation.

  Source review date: 2026-11-10

If another problem remains

Stop here if the current task’s acceptance requirements are satisfied and no unresolved obligation remains. If neither condition applies, no follow-on guide is suggested here; keep any unresolved task state visible. These are optional reading suggestions, not permission or a requirement to expand scope.

• Only if: A failed or interrupted guard path leaves the underlying effect uncertain.

  Check the outcome before retrying

  Separate the guard response from the authoritative operation outcome before retrying.

• Only if: The required boundary works and you now need to compare its overhead or usability.

  Measure improvement in accepted results

  Measure the authorized change against the same quality and control requirements.

Work through the checks

1. Separate the three surfaces

   The primary-source review identifies strict_resume in Python async and sync langgraph-sdk 0.4.14 thread runs.create, runs.stream and runs.wait. Stateless calls omit it. Keep the public SDK parameter, server capability and separate local-runtime private key distinct. A client argument is not proof of server enforcement.

2. Read current state

   Read the live interrupt ID from the authoritative server state or stream. Do not derive it from a task title or reuse an older answer’s ID. Keep the current question visible in the interface.

3. Rehearse stale and fresh answers

   Create harmless question A followed by B. Answer A, read B’s new ID, then replay A’s saved response. Confirm B remains pending. Answer B with its current ID and confirm the valid path succeeds.

4. Make absence visible

   Test unknown IDs and unsupported-server behavior separately. Check the deployed server’s /info response for strict_resume support. The reviewed SDK change says unsupported servers can ignore the field. Mark enforcement unavailable rather than interpreting request success as protection.

What would count as success?

1. A stale answer never advances the current question. Evidence for check 1
2. Rejection is visible and the user can re-read and answer the current question. Evidence for check 2
3. A fresh valid answer still works. Evidence for check 3

Evidence to bring back

Proposed evidence plan, not observed results or extra mandatory process. Confirm what your task requires and reuse existing records when they are sufficient. Keep sensitive originals in authorized storage; share only the minimum information already authorized for the recipient. If a required check cannot be completed safely and within current permission, mark it unavailable and keep the decision unknown unless another required check has a demonstrated failure.

1. A stale answer never advances the current question.

   Proposed evidence for acceptance check 1. No result has been observed here.

   Bring back: Keep the authoritative interrupt IDs and state before and after replaying the stale A response while B is pending. Record whether B remains pending and whether any downstream effect occurred.

   Not enough: A stale-answer error alone without inspecting the current state or downstream effect.

2. Rejection is visible and the user can re-read and answer the current question.

   Proposed evidence for acceptance check 2. No result has been observed here.

   Bring back: Keep the stale/unknown-ID rejection result and the subsequent read that exposes the current question and ID. Record whether the intended user can reach that recovery path within existing access.

   Not enough: A backend log entry that gives the user no route to recover the current question.

3. A fresh valid answer still works.

   Proposed evidence for acceptance check 3. No result has been observed here.

   Bring back: Record a fresh valid B response and its expected state transition on the same deployed configuration. Retain the relevant /info capability response; if enforcement is unsupported or cannot be checked, leave the protection claim unknown.

   Not enough: A successful HTTP request or an SDK argument without confirming the expected state transition and server capability.

What this does not establish

The specific SDK and runtime changes were rechecked against primary sources on 10 November 2026, but no real LangGraph server was executed for this reconstruction. These are bounded acceptance recipes, not measured results or a complete authorization policy.

Reference links

These links leave the saved pack when selected. Check whether dated guidance still applies before relying on it.

• langgraph-sdk 0.4.14 (Online source)

  Primary SDK release record. A client version does not establish server-side enforcement.

  Source review date: 2026-11-10

• Public SDK strict_resume support (Online source)

  Primary change defining strict_resume on Python async/sync thread runs and the server capability limitation.

  Source review date: 2026-11-10

• Runtime strict resume change (Online source)

  Primary runtime change for strict resume checks. Separate from SDK argument availability and not a complete authorization policy.

  Source review date: 2026-11-10

If another problem remains

Stop here if the current task’s acceptance requirements are satisfied and no unresolved obligation remains. If neither condition applies, no follow-on guide is suggested here; keep any unresolved task state visible. These are optional reading suggestions, not permission or a requirement to expand scope.

• Only if: An old answer may already have triggered an external action.

  Check the outcome before retrying

  Resolve the operation outcome rather than assuming a rejected replay undoes the first effect.

• Only if: The current question and state are correct now, but are lost when work changes sessions.

  Keep memory useful without losing the rules

  Preserve a pointer to authoritative current state without treating a saved answer as a fresh one.

Work through the checks

1. Name the operation before dispatch

   Use the provider’s supported operation or idempotency key where available. Record the intended effect, destination, authorization and a reliable way to check status. Inventing a key that the provider ignores offers no protection.

2. Keep three outcome states

   Confirmed completed, confirmed not completed and unknown require different next actions. A timeout means the response was not observed; it does not establish that the operation did not execute.

3. Inspect the authoritative record

   Check the provider receipt or operation status through an authorized read. If completion is confirmed, recover the result without repeating the effect. If non-completion is established, recheck that the original permission still applies before retrying.

4. Rehearse with a local fake sink

   Inject a crash before dispatch, after the fake sink commits and before the response, and after recording completion. Restart and inspect the operation ledger before retrying. Keep network and money out of the rehearsal.

What would count as success?

1. Confirmed completed work is not replayed. Evidence for check 1
2. Unknown work remains blocked for reconciliation. Evidence for check 2
3. Every retry stays within current authorization and provider semantics. Evidence for check 3

Evidence to bring back

Proposed evidence plan, not observed results or extra mandatory process. Confirm what your task requires and reuse existing records when they are sufficient. Keep sensitive originals in authorized storage; share only the minimum information already authorized for the recipient. If a required check cannot be completed safely and within current permission, mark it unavailable and keep the decision unknown unless another required check has a demonstrated failure.

1. Confirmed completed work is not replayed.

   Proposed evidence for acceptance check 1. No result has been observed here.

   Bring back: Keep the operation identity, authoritative completion receipt and action trace showing that recovery retrieved the existing result rather than dispatching another effect. Minimize or redact recipient/payment details in any shared copy.

   Not enough: A timeout, missing response or empty local log used as proof that the provider did nothing.

2. Unknown work remains blocked for reconciliation.

   Proposed evidence for acceptance check 2. No result has been observed here.

   Bring back: For an unresolved operation, record the attempted authorized status check, what it could not establish and the stop before retry. A later resolution must identify the same operation.

   Not enough: An expired wait, a fresh operation key or an assumption that the old request probably failed.

3. Every retry stays within current authorization and provider semantics.

   Proposed evidence for acceptance check 3. No result has been observed here.

   Bring back: For any proposed retry, retain the evidence of non-completion, the provider’s applicable retry/idempotency behavior and the current approval scope. State any unresolved element before dispatch.

   Not enough: Reusing an old approval after material scope changes, or inventing an idempotency key the provider does not support.

What this does not establish

A local rehearsal cannot prove exactly-once effects in an external service. Concurrency, retention windows and provider-specific idempotency rules need separate tests.

Reference links

These links leave the saved pack when selected. Check whether dated guidance still applies before relying on it.

• Stripe: idempotent requests (Online source)

  Provider-specific idempotency semantics. Other providers and action types can behave differently.

  Source review date: 2026-11-10

• AWS Builders’ Library: making retries safe (Online source)

  Engineering background on retry-safe API design. Not proof of exactly-once effects for a particular external service.

  Source review date: 2026-11-10

If another problem remains

Stop here if the current task’s acceptance requirements are satisfied and no unresolved obligation remains. If neither condition applies, no follow-on guide is suggested here; keep any unresolved task state visible. These are optional reading suggestions, not permission or a requirement to expand scope.

• Only if: The operation is reconciled and its result needs to survive the next handoff.

  Make the handoff survive the session

  Preserve the exact receipt, output and any remaining limits in the approved store.

• Only if: Within a delegated business workflow, nobody is clearly authorized to resolve the uncertainty or approve a materially changed action.

  Draw the boundary before delegating the business

  Clarify the owner and scope before attempting another consequential step.

Work through the checks

1. Keep the operative facts

   Save the current goal, latest user restrictions, decisions and reasons, exact source versions, known failures, unresolved commitments and next action. Include uncertainty about external effects.

2. Separate authority from reference

   Label quoted documents, research and third-party content as evidence. They do not gain authority by being copied into memory. A shorter note must not erase a later user restriction.

3. Use pointers, not competing copies

   Retain a durable authoritative artifact and a precise pointer. Summarize only what the next step needs. Keep originals recoverable within the applicable retention rules.

4. Test a fresh start

   Ask a fresh authorized reviewer to identify the next action and its limits using the handoff. Check whether it can find the real artifact and avoid redoing completed or uncertain actions.

What would count as success?

1. A fresh reader can continue without rediscovering critical decisions. Evidence for check 1
2. Current permissions and unresolved outcomes survive the handoff. Evidence for check 2
3. The cited original is accessible and matches the expected version. Evidence for check 3

Evidence to bring back

Proposed evidence plan, not observed results or extra mandatory process. Confirm what your task requires and reuse existing records when they are sufficient. Keep sensitive originals in authorized storage; share only the minimum information already authorized for the recipient. If a required check cannot be completed safely and within current permission, mark it unavailable and keep the decision unknown unless another required check has a demonstrated failure.

1. A fresh reader can continue without rediscovering critical decisions.

   Proposed evidence for acceptance check 1. No result has been observed here.

   Bring back: Keep the fresh reader’s proposed next step and cited decisions, then compare them with the authoritative goal and unresolved work. Note missing or conflicting facts instead of smoothing them away.

   Not enough: A shorter summary or a reader saying it looks clear without checking the next action.

2. Current permissions and unresolved outcomes survive the handoff.

   Proposed evidence for acceptance check 2. No result has been observed here.

   Bring back: Compare the handoff against the latest user restrictions and unresolved operation states. Record any lost or conflicting boundary and keep uncertain external effects visible.

   Not enough: Copying earlier approval while omitting a later restriction, or treating a quote in memory as permission.

3. The cited original is accessible and matches the expected version.

   Proposed evidence for acceptance check 3. No result has been observed here.

   Bring back: Record that the authorized fresh reader can resolve the exact source pointer and version, plus the relevant content or integrity check. Leave inaccessible sources unavailable.

   Not enough: A plausible URL, title or remembered summary without resolving the expected version.

What this does not establish

This is a proposed practice, not proof that smaller context improves every agent. Required records and environment rules remain authoritative.

Reference links

These links leave the saved pack when selected. Check whether dated guidance still applies before relying on it.

• Anthropic: effective context engineering (Online source)

  Context-management design guidance. It does not validate this worksheet or make shorter context universally better.

  Source review date: 2026-11-10

If another problem remains

Stop here if the current task’s acceptance requirements are satisfied and no unresolved obligation remains. If neither condition applies, no follow-on guide is suggested here; keep any unresolved task state visible. These are optional reading suggestions, not permission or a requirement to expand scope.

• Only if: The note points to a deliverable that is still only in the working session.

  Make the handoff survive the session

  Save and verify the actual artifact; a summary is not a durable copy.

• Only if: A demonstrated recurring handoff problem suggests a reusable instruction package might help.

  Review a skill before adding it

  Check task fit and the current baseline before turning the procedure into a skill.

Work through the checks

1. Name the job

   Describe the exact problem the skill should solve and when it should not run. Read its instructions and referenced scripts. Inspect the requested tools, data, network access and side effects.

2. Check compatibility and provenance

   Record the source, version, license and supported host. A valid SKILL.md name and description can help discovery but do not prove safety or quality. Treat scripts as code, not prose.

3. Compare against the existing workflow

   Use comparable tasks, the same tools and permissions, and clear acceptance tests. Do not weaken the baseline so the new package looks useful. Include failure and unavailable-tool cases.

4. Keep rollback small

   Preserve the prior version and a way to disable the new skill. Stage authorized changes in an isolated environment. Keep permission changes separate from content updates.

What would count as success?

1. The skill improves a defined outcome or removes demonstrated recurring work. Evidence for check 1
2. Quality and required controls are preserved. Evidence for check 2
3. The previous working version remains recoverable. Evidence for check 3

Evidence to bring back

Proposed evidence plan, not observed results or extra mandatory process. Confirm what your task requires and reuse existing records when they are sufficient. Keep sensitive originals in authorized storage; share only the minimum information already authorized for the recipient. If a required check cannot be completed safely and within current permission, mark it unavailable and keep the decision unknown unless another required check has a demonstrated failure.

1. The skill improves a defined outcome or removes demonstrated recurring work.

   Proposed evidence for acceptance check 1. No result has been observed here.

   Bring back: Keep paired task results against the same competent baseline, with the defined outcome, recurring problem and setup/review burden visible. Record a keep or skip decision when no useful gain is demonstrated.

   Not enough: Popularity, a longer output or a reduced tool count without an accepted-result comparison.

2. Quality and required controls are preserved.

   Proposed evidence for acceptance check 2. No result has been observed here.

   Bring back: Keep the acceptance results and required permission/failure-path checks for both workflows, including failures and unavailable cases. Changes to permissions need their own approval.

   Not enough: A faster happy path that omits the baseline’s quality checks or weakens a required control.

3. The previous working version remains recoverable.

   Proposed evidence for acceptance check 3. No result has been observed here.

   Bring back: Keep the prior version’s identity, authorized storage location and a bounded restore check of that version in the intended test environment. A disable check demonstrates only that the new skill can be stopped. State what recovery was not exercised.

   Not enough: A promised rollback or an untested backup pointer described as demonstrated recovery.

What this does not establish

This worksheet does not install, certify or endorse any skill. A schema check is not an effectiveness test.

Reference links

These links leave the saved pack when selected. Check whether dated guidance still applies before relying on it.

• Agent Skills specification (Online source)

  The skill-package format and metadata contract. Format compliance does not establish safety, quality or usefulness.

  Source review date: 2026-11-10

• Anthropic: building effective agents (Online source)

  Engineering guidance on fitting workflow complexity to task needs. Not a controlled evaluation of this method.

  Source review date: 2026-11-10

If another problem remains

Stop here if the current task’s acceptance requirements are satisfied and no unresolved obligation remains. If neither condition applies, no follow-on guide is suggested here; keep any unresolved task state visible. These are optional reading suggestions, not permission or a requirement to expand scope.

• Only if: A candidate fits a documented problem, but its benefit over the current workflow is still unmeasured.

  Measure improvement in accepted results

  Define a bounded comparison before deciding to adopt it.

• Only if: An approved trial needs its inputs, prior version and results preserved for review or recovery.

  Make the handoff survive the session

  Keep the exact versions recoverable without treating a saved package as launch approval.

Work through the checks

1. Freeze the comparison

   Specify the task set, inputs, tools, permissions, acceptance tests and conditions before running. Vary one factor where practical. Preserve failures and retries instead of quietly excluding them.

2. Measure the whole outcome

   Track valid completion, elapsed time, owner review and rework, available billed usage and required checks. Token or tool-call counts diagnose cost; they do not establish usefulness alone.

3. Test the cases that can change the decision

   Include normal, invalid and interrupted flows. Include a case where the new method should not help. Treat missing tools and unavailable measurements as unknown, not zero.

4. Decide with the limits visible

   Report each task separately in a tiny pilot. Keep severe safety failures visible rather than averaging them away. Include setup and maintenance costs. A local improvement is not a universal claim.

What would count as success?

1. The baseline is competent and both conditions share the same requirements. Evidence for check 1
2. Results include failed and interrupted runs. Evidence for check 2
3. The recommendation reflects quality, owner effort and measured costs together. Evidence for check 3

Evidence to bring back

Proposed evidence plan, not observed results or extra mandatory process. Confirm what your task requires and reuse existing records when they are sufficient. Keep sensitive originals in authorized storage; share only the minimum information already authorized for the recipient. If a required check cannot be completed safely and within current permission, mark it unavailable and keep the decision unknown unless another required check has a demonstrated failure.

1. The baseline is competent and both conditions share the same requirements.

   Proposed evidence for acceptance check 1. No result has been observed here.

   Bring back: Keep the frozen task inputs, shared requirements, permissions and version/configuration of each condition, with the baseline’s acceptance results. State differences that cannot be controlled.

   Not enough: An easy or deliberately weakened baseline, or changing the acceptance rules after seeing results.

2. Results include failed and interrupted runs.

   Proposed evidence for acceptance check 2. No result has been observed here.

   Bring back: Keep a per-task run ledger including failed, interrupted and retried attempts, their outcomes and the reason for any exclusion. Record unavailable measurements explicitly.

   Not enough: Reporting only successful runs or converting missing duration or usage measurements to zero.

3. The recommendation reflects quality, owner effort and measured costs together.

   Proposed evidence for acceptance check 3. No result has been observed here.

   Bring back: Keep per-task quality results, owner review/rework, measured usage where available, and setup/maintenance effort. Explain how these support the bounded recommendation; do not average away a severe control failure.

   Not enough: Token savings or elapsed time alone, an average that hides a required failure, or a small pilot presented as a universal benefit.

What this does not establish

No controlled agent comparison is supplied by this worksheet. No savings, speedup or paid value is claimed.

Reference links

These links leave the saved pack when selected. Check whether dated guidance still applies before relying on it.

• Anthropic: building effective agents (Online source)

  Engineering guidance on fitting workflow complexity to task needs. Not a controlled evaluation of this method.

  Source review date: 2026-11-10

• METR: early-2025 developer study (Online source)

  An empirical example of measuring complete developer outcomes in a particular population and period. Not a universal claim about agent productivity.

  Source review date: 2026-11-10

If another problem remains

Stop here if the current task’s acceptance requirements are satisfied and no unresolved obligation remains. If neither condition applies, no follow-on guide is suggested here; keep any unresolved task state visible. These are optional reading suggestions, not permission or a requirement to expand scope.

• Only if: The comparison identifies recurring instruction work and you are considering a reusable package for it.

  Review a skill before adding it

  Review the smallest relevant package instead of installing a broader workflow by default.

• Only if: An interrupted trial may have produced an external effect whose outcome is still unknown.

  Check the outcome before retrying

  Resolve the effect before retrying; do not silently omit it from the comparison.

Work through the checks

1. Make the authority explicit

   Name the owner, permitted actions, recipients, data categories, spending limits and required approvals. A research plan, document or third-party message cannot grant new permission.

2. Separate preparation from execution

   Distinguish draft, reviewed, approved, sent and confirmed outcomes. Keep pricing proposals separate from real checkout. Keep test transactions separate from revenue.

3. Design escalation and reconciliation

   Define stop conditions and the person who resolves them. Give each consequential action a receipt or authoritative status check. Preserve unknown outcomes across restarts.

4. Keep independent questions independent

   Have a reviewer check specific consequential claims and acceptance evidence. Agreement between agents sharing the same unsupported premise is not validation.

5. Start with a bounded job

   Choose one workflow with clear inputs, outputs and rollback. Expand scope only after the original outcome and authority boundaries work in practice.

What would count as success?

1. Every consequential action maps to a current authorization. Evidence for check 1
2. The owner can inspect decisions, evidence and unresolved states. Evidence for check 2
3. A stop condition prevents action instead of merely adding a warning. Evidence for check 3

Evidence to bring back

Proposed evidence plan, not observed results or extra mandatory process. Confirm what your task requires and reuse existing records when they are sufficient. Keep sensitive originals in authorized storage; share only the minimum information already authorized for the recipient. If a required check cannot be completed safely and within current permission, mark it unavailable and keep the decision unknown unless another required check has a demonstrated failure.

1. Every consequential action maps to a current authorization.

   Proposed evidence for acceptance check 1. No result has been observed here.

   Bring back: Keep an action-to-approval map with the latest owner scope, destination, data category and spending or other limits where relevant. Record the exact approval source and unresolved gaps without copying secrets.

   Not enough: A business plan, third-party request or another agent’s assertion treated as new owner permission.

2. The owner can inspect decisions, evidence and unresolved states.

   Proposed evidence for acceptance check 2. No result has been observed here.

   Bring back: Keep the decision record, outcome receipts and unresolved-state list where the authorized owner can inspect them. Confirm existing access and distinguish draft, approved, sent and confirmed states.

   Not enough: A summary claiming completion with no inspectable evidence, or access verified only for the sender.

3. A stop condition prevents action instead of merely adding a warning.

   Proposed evidence for acceptance check 3. No result has been observed here.

   Bring back: In an authorized isolated rehearsal, trigger a stop condition and record the effect counter before/after, escalation result and state preserved for resumption. Do not test by making a real consequential transaction.

   Not enough: A warning in the log while the prohibited action still executes, or a stop that loses the unresolved operation identity.

What this does not establish

This is an operating worksheet, not legal, financial or compliance advice. Agent Optimization Executive is not an available autonomous service.

Reference links

These links leave the saved pack when selected. Check whether dated guidance still applies before relying on it.

• NIST AI Risk Management Framework (Online source)

  Risk-management background. This worksheet is not compliance advice or a claim of conformity.

  Source review date: 2026-11-10

If another problem remains

Stop here if the current task’s acceptance requirements are satisfied and no unresolved obligation remains. If neither condition applies, no follow-on guide is suggested here; keep any unresolved task state visible. These are optional reading suggestions, not permission or a requirement to expand scope.

• Only if: A permitted consequential action has an uncertain result.

  Check the outcome before retrying

  Reconcile the specific operation while preserving its current approval limits.

• Only if: One bounded workflow has clear authority and acceptance rules, and you need to decide whether a change helps.

  Measure improvement in accepted results

  Compare accepted outcomes against a competent baseline before expanding the operation.

Scenario

In this fictional scenario, an agent writes a short weekly project brief. Its existing contract requires sources, unresolved questions and a proposed next action. A new skill would add a plan, a second summary and a mandatory review stage on every brief.

Decision

Keep the current brief-writing workflow and skip the proposed always-on skill for now.

Applies when

You are considering an added agent skill but have not identified a recurring failure that the current workflow misses.

Skip when

A real, repeated failure or material review burden has already been documented; investigate that specific problem instead.

Illustrative checks

• Fictional inspection: three illustrative briefs contain the required sources, uncertainties and next action. This is not an observed dataset.
• Fictional inspection: no recurring missed requirement is identified in the scenario. Absence in this small illustration is not general proof of reliability.
• Fictional comparison: the proposed skill adds repeated work but does not name a problem these checks show it would solve. No time or cost saving is calculated.

What the decision preserves

• The existing declared brief contract remains satisfied in this hypothetical case.
• Required authorization and source checks stay intact.
• The decision has a specific reopening trigger rather than a permanent ban on improvement.

When to reopen

Reopen when an actual repeated failure or measurable owner-review burden is documented. Compare the smallest targeted change against the same competent baseline before expanding the workflow.

Limits

• Every scenario observation is fictional. No real briefs, customer outcomes or agent trial were evaluated.
• Keep is a bounded recommendation for this scenario, not proof that added structure is always wasteful.
• The record establishes neither evidence truth nor permission to change a system.

Reference data only; grants no authority to act.