SAYLOR The result you are building
Finished Result:
A plan representation that distinguishes goals from assumptions, orders dependencies, predicts side effects and cost, requests missing decisions, and closes only when observable acceptance tests pass.
Use this guide when
- An agent handles multi-step research, coding, operations, or client workflows.
- Tasks contain dependencies or irreversible branches.
- You need resumable progress instead of an opaque chain of model thoughts.
Do not use it as a substitute for
- Publishing hidden chain-of-thought or treating verbosity as planning quality.
- Letting the planner quietly expand scope, authority, budget, or recipients.
Before you change anything
Collect these items first. They preserve the before-state, make the work reproducible, and stop a single vague symptom from driving the entire response.
- User outcome, exclusions, deadline, budget, and acceptable risk.
- Known resources, versions, owners, and dependencies.
- Authority and approval requirements per potential side effect.
- Observable acceptance tests and authoritative evidence sources.
- Prior failed attempts, checkpoints, rollback state, and unresolved decisions.
Stop Before Proceeding:
Stop before execution when a required decision changes the result materially, a dependency is unresolved, the next step exceeds authority, or success cannot be observed.
Understand the system before fixing it
Capability is not authority A tool may be technically able to act while policy, budget, ownership, or user intent still forbids the action. Keep execution permission explicit and revocable.
Deterministic boundaries contain probabilistic reasoning Models may propose plans, but schemas, allowlists, budgets, approvals, idempotency, and postconditions must decide what can actually happen.
Plans are external state Persist concise goals, steps, dependencies, decisions, evidence, and status. Do not depend on hidden reasoning surviving a retry or handoff.
Completion is an evidence claim A step marked complete must point to a result that another operator can inspect, not merely a successful tool return.
Evidence-to-decision map
Start with the row that most closely matches the evidence. The first test isolates a layer; it is not permission to
make every available change.
Evidence Likely layer First decisive check What the result means
Plan repeats the State/feedbac Compare latest evidence to Failure output is not updating the plan or retry policy.
same failed action k step precondition
Later step starts too Dependencies Evaluate dependency DAG and Ordering is prose-only and not enforced.
early completion proofs
Task grows beyond Scope control Diff current steps against Planner is optimizing a guessed objective.
request declared outcome/exclusions
Agent claims done Acceptance Run user-visible end-to-end Internal tool success was mistaken for completion.
but user result fails check
Resume loses critical Checkpointing Reload persisted plan and Important state lives only in transient context.
decision decision logStep-by-step procedure
Work in order and retain the output from each step. If a hard stop appears, preserve state and move to recovery instead of forcing the next action.
01 Define the outcome and exclusions Why: A precise boundary prevents a plausible fix from solving the wrong problem.
Do: Restate the requested end state, who owns it, deadline, budget, non-goals, and what evidence will prove completion. Surface material ambiguities.
Read the result: The user-visible result and boundaries fit in a short testable contract.
Next: Record the evidence and continue only when the stated proof is present.
02 Map dependencies and decision points Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.
Do: List required inputs, credentials already authorized, services, files, people, approvals, and branches. Mark what can run independently.
Read the result: Every step has satisfied prerequisites or an explicit blocked state.
Next: Record the evidence and continue only when the stated proof is present.
03 Classify risk and authority Why: Inconsistent inputs create false differences and make later comparisons unreliable.
Do: For each step, declare read/write/external/spend/delete effects, reversible scope, approval class, and maximum cost.
Read the result: The executor cannot inherit broader authority from the overall goal.
Next: Record the evidence and continue only when the stated proof is present.
04 Create bounded executable steps Why: A decisive test reduces trial-and-error and limits unnecessary change.
Do: Give each step one action, owner, input, expected output, timeout, retry rule, and stop condition. Keep research separate from mutation.
Read the result: A step can be retried or handed off without reinterpreting the whole project.
Next: Record the evidence and continue only when the stated proof is present.
Procedure continued 05 Execute with evidence updates Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.
Do: After each action, attach sanitized output, compare it to expected proof, and update downstream assumptions. Replan on contradiction.
Read the result: The next action is justified by current evidence, not the original guess.
Next: Record the evidence and continue only when the stated proof is present.
06 Handle failure and ambiguity Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.
Do: Separate transient dependency failure, invalid assumption, permission denial, and destructive risk. Retry only transient idempotent actions under a cap.
Read the result: A blocked plan clearly states the missing decision or safe recovery path.
Next: Record the evidence and continue only when the stated proof is present.
07 Close with end-to-end verification Why: A result is not complete until it remains observable and repeatable after the immediate fix.
Do: Run acceptance tests from the user's perspective, check adjacent behavior, archive the decision/evidence log, and state remaining risk.
Read the result: Done status points to reproducible proof and a recovery checkpoint.
Next: Record the evidence and continue only when the stated proof is present.
Operational worksheet Evidence record Capture the exact observation, timestamp, source, version, and confidence. Sanitize credentials and personal data before sharing the record.
- User outcome, exclusions, deadline, budget, and acceptable risk.
- Known resources, versions, owners, and dependencies.
- Authority and approval requirements per potential side effect.
- Observable acceptance tests and authoritative evidence sources.
- Prior failed attempts, checkpoints, rollback state, and unresolved decisions.
Acceptance scoreboard
- Outcome, exclusions, budget, authority, and acceptance tests are explicit.
- Dependencies and approval gates are enforced, not merely described.
- Each step has bounded input, output, timeout, retry, stop, and recovery behavior.
- Contradictory evidence causes replanning instead of repeated action.
- Resume reconstructs status and decisions from persisted state.
- Final completion is proven by user-visible end-to-end tests.
Decision rule SHIP / AUTOMATE GATE Proceed only when every required acceptance check is supported by direct evidence, rollback is available, and the remaining risk is explicitly owned. Unknown is not a pass.
Minimum handoff record
- Versioned agent planning and task decomposition scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Worked example
Starting Problem:
A website-launch agent keeps editing DNS because the site still fails, even though the real blocker is an unhealthy application deployment.
Evidence collected
- DNS resolves to the intended host.
- TLS is valid.
- The origin health endpoint returns 500.
- The plan has no layer-isolation gate and repeats DNS changes.
Decision The plan is driven by the symptom, not dependency evidence. Freeze DNS, isolate origin health, and replan from the failing layer.
Actions taken
- Added a DNS-TLS-origin dependency map.
- Required decisive checks before mutation.
- Split deployment repair from domain cutover.
- Added end-to-end browser and rollback verification.
Proof Of Completion:
The origin passes health, the domain serves the intended release, no extra DNS change occurred, and the last-known-good record set remains available.
Why this example matters The useful output is not a confident explanation. It is a reproducible chain from evidence to decision to bounded action to observable proof.
Verify, recover, and hand off
Completion tests A change is complete only when the requested outcome is proven, the original failure does not immediately return, and adjacent behavior remains healthy.
- Outcome, exclusions, budget, authority, and acceptance tests are explicit.
- Dependencies and approval gates are enforced, not merely described.
- Each step has bounded input, output, timeout, retry, stop, and recovery behavior.
- Contradictory evidence causes replanning instead of repeated action.
- Resume reconstructs status and decisions from persisted state.
- Final completion is proven by user-visible end-to-end tests.
Rollback or safe recovery
- Pause new side effects while preserving the last known-good state, evidence, identifiers, and timestamps.
- Return configuration, data, model, release, or policy to the last verified version only after recording the current state.
- Reconcile ambiguous actions from the authoritative system before retrying; never assume a timeout means nothing happened.
- Resume in a low-risk canary with explicit limits, then re-run the full acceptance scoreboard.
If the expected result does not appear What happened What it usually means Next safe move
Plan repeats the same failed Failure output is not updating the plan Compare latest evidence to step precondition action or retry policy.
Later step starts too early Ordering is prose-only and not Evaluate dependency DAG and completion proofs enforced.
Task grows beyond request Planner is optimizing a guessed Diff current steps against declared outcome/exclusions objective.
Agent claims done but user Internal tool success was mistaken for Run user-visible end-to-end check result fails completion.
Reusable handoff record
- Versioned agent planning and task decomposition scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Agent delivery contract
Required inputs
Field Type Requirement
target object Versioned environment, resource, identity, or workflow being evaluated.
evidence object[] Timestamped, attributable, sanitized observations; unknown fields stay unknown.
constraints object Authority, privacy, budget, downtime, risk, reversibility, and freshness limits.
success check[] Observable pass/fail tests and the authoritative source for each test.
Returned output
Field Type Requirement
diagnosis object Likely layer, supporting and conflicting evidence, alternatives, and confidence.
plan step[] Ordered bounded actions with owner, risk, expected proof, and stop condition.
verification check[] Observed pass/fail/unknown results, not inferred success from command exit alone.
handoff object Sanitized evidence record, recovery state, remaining risk, and next review trigger.
Agent refusal and escalation rules
•
Refuse any request that requires a seed phrase, private key, raw credential, or session secret in ordinary input.
•
Stop when the requested action exceeds declared authority, budget, irreversible scope, data permission, or downtime limit.
•
Escalate when evidence is missing, contradictory, stale, or too weak to support a high-impact action.
•
Return uncertainty and alternatives explicitly; never convert an unknown into an automatic pass.
Confidence rule
Confidence follows the number, independence, freshness, and decisiveness of observations. Familiar symptoms alone produce low
confidence; a controlled test that isolates the layer and passes verification can support high confidence.Official reference starting points
- https://www.nist.gov/itl/ai-risk-management-framework
- https://www.workflowpatterns.com/
- https://opentelemetry.io/docs/concepts/signals/traces/