Chapter C51 · Interactive Course
Reliable actions over several steps
Retries, idempotency, permissions, sandboxes, handoffs, checkpoints.
Core Learning Concept
Recover the partial run from evidence of what actually happened. Inspect external state before repeating writes, preserve identifiers for supported idempotent retries, and reconcile local edits. Keep permissions and ownership narrow. Finish with a concrete review point that exposes the remaining action and its consequences.
What You’ll Learn in This Chapter
-
A retry can repeat a side effect
Identify an operation that needs outcome checking before retry.
A side effect changes something outside the immediate calculation, such as sending a message or creating a record. If a request times out, the action may have completed even though its response was lost. Inspect state or use a supported safe-retry mechanism before repeating the operation.
-
Idempotency makes repeats safer
Explain a stable operation identifier in a toy retry.
Idempotency means repeated application has the same intended effect as one application under the operation’s contract. Some APIs support an idempotency key that identifies one logical action across retries. Reuse the same key for that action and follow the service’s rules; a new key may create a new operation.
-
Read and write permissions differ
Select only the access needed for a task.
Read permissions allow inspection; write permissions allow changes. A task that only needs availability does not necessarily need event deletion. Match access to the work and recognize when a new step needs additional authority. Permissions constrain possible effects even when the model’s requested action is mistaken.
-
A sandbox limits execution reach
Identify an enforced boundary in a supplied setup.
A sandbox restricts execution through enforced boundaries, such as permitted files, network access, or process capabilities. Written instructions guide behavior but are not the same enforcement mechanism. Inspect the configured restrictions and their documented limits. A sandbox does not automatically isolate every shared external service.
-
Subagents need narrow handoffs
Specify one independent task and return format.
A subagent is another agent assigned a portion of the work. Its available context and tools depend on the host, so provide the material, concrete question, constraints, and expected result explicitly. Bounded assignments make the returned evidence easier to combine and reduce assumptions about what the delegate already knows.
-
Parallel work can conflict
Recognize overlapping writes before delegation.
Concurrent agents can conflict when they edit shared files or depend on changing interfaces. Some hosts isolate checkouts; others share a filesystem. Establish ownership and coordinate shared contracts before parallel changes. Separate files do not guarantee independence when one change affects how another component behaves.
-
Humans need usable checkpoints
Choose a review point with concrete artifacts.
A usable checkpoint shows the concrete result and the action awaiting a decision. Before an external commitment, present the relevant content, destination, and consequences. The reviewer needs something inspectable, not only a plan. Existing authorization may already cover routine steps; the checkpoint should match the actual decision.
-
Recover a partial run
Inspect a timed-out write, overlapping edits and a missing result, and choose one recovery for each without assuming the final state.
-
Trace one agent task
Inspect a toy file-search agent that reads a workspace, calls a tool, sees an error and changes its next step, and read its proposed change before accepting it.