Independent thinking. Documented progress.Field notes on working with AI

Learning path · intermediate

Decide what survives a provider failure

Move beyond retrying: identify shared dependencies, limit unsupported service, and define evidence for controlled recovery.

90–120 min · proposed study budget. Allow additional time for review. This is not a tested completion time or a certification.

Download Markdown

The output to keep

A dependency map, output-contract check, degraded-response card, and recovery decision with a bounded measurement plan.

Use public, teacher-authored or synthetic material only. Work offline in your own copy. This site has no submission or storage feature.

Published and revised: October 13, 2026 · Version 1.0.0

Move beyond retrying: identify shared dependencies, limit unsupported service, and define evidence for controlled recovery.

Goal and proposed time

Write an honest degraded-operation decision that preserves useful supported work without inventing successful failover.

Allow 90–120 minutes, including selected reading, making the outputs, and review. This is a proposed study budget, not measured completion time. Split the path across sessions if needed; stop at a checkpoint rather than rushing an evidence check.

Prerequisites and inputs

  • Understand request limits and the distinction between retry and a new action
  • Have read a basic tool contract; software implementation is optional and outside this path

Use only the linked guides and their public or synthetic fixtures. A text editor, calculator, and timer are enough. No provider connection, account change, publication, or outside communication is required.

Work through the path

1. Design recovery before retrying an uncertain action

Read the guide. Walk the uncertain-outcome state machine first. Explain why a timeout does not prove an action failed and why a new operation key can duplicate an effect.

Carry forward: A recovery note separating unknown writes from the capstone’s read-only provider outage.

2. Write a tool contract that can reject a bad request

Read the guide. Use the response-contract section to list the fields a replacement output must preserve. A syntactically valid response still needs applicable evidence.

Carry forward: A compatibility checklist with missing-result behavior.

3. Map an agent's permissions before it acts

Read the guide. Add a hypothetical provider switch as a separate proposed operation. Name the input data and receiving service; leave it blocked where authorization is absent.

Carry forward: A transmission boundary that cannot be cleared by technical success.

4. Make a cost, latency, and quality decision from a run log

Read the guide. Define what you would measure during normal, degraded, and recovered operation. Keep failed attempts and required stops in the ledger.

Carry forward: A blank run ledger and quality gates; no fabricated measurements.

Worked practice

Complete Keep a useful service when the provider disappears. Map shared dependencies, reject an unapproved or incompatible fallback, and preserve only the service that remains supportable.

When gateway G fails, both A and B lose their shared route. A still-valid static hours card can support a labelled limited response; it cannot establish a live seat count. Provider C’s different route does not solve its missing authorization or incompatible evidence fields.

Output

A dependency map, output-contract check, degraded-response card, and recovery decision with a bounded measurement plan.

Exit checks

  • Different provider names are not assumed to imply independent dependencies
  • Unknown action outcomes are reconciled before any proposed repeat
  • Authorization and fallback compatibility are separate gates
  • Partial service is labelled accurately; live facts are withheld when unavailable
  • Cost and latency stay unmeasured unless actual records exist

Decide what happens next

Keep the result when the checks pass. Revise a specific failed check in a new draft, preserving the first attempt. Hold any part that needs missing evidence or authority; an honest hold can complete this learning path even though the wider real-world task remains unfinished. Do not call an authored answer key an observed result.

IIEN means infer intent and extrapolate needs here: use it to notice a useful next question and label assumptions. It does not authorize new actions, expand access, or tune model weights.

Sources and scope

This is an editorial sequence of the linked existing guides. Their source sections support the individual methods; the sequence, checkpoints, and study budget are original teaching choices. This path does not claim certification, deployed capability, or measured performance improvement.

Plain text for manual copying

Keep the sequence connected

All Agentic Systems paths · Choose a different learning goal · Evidence and source policy