Name the behavior before asking for code
Consider a report worker that sometimes fails while reading source data. You want an agent to add retries. “Make it robust” leaves too much undecided: which failures are temporary, how many attempts are allowed, and what does the client see while work is retried?
Start with the system map from the previous article. It separates request acceptance, report generation, and result retrieval. State which relationship should change and which promises should still hold.
Add bounded retries for temporary source-data failures in the report worker. Keep the same job identifier. Do not retry authorization or invalid-input errors. Explain the job states visible to the client, identify the files you expect to change, and propose tests before editing.
Read the live retry sequence as a review checklist
In the embedded model, follow Bounded retry of a temporary input failure. The failure occurs while reading Source Data, before report output is written. Retry scheduling is recorded against the existing job, with an attempt budget and a due time. A waiting client continues to ask about that job; scheduling another attempt does not create a second request.
The branches distinguish a temporary error with budget remaining from a permanent error or an exhausted budget. Ask the agent to point to the code that makes each classification and to the state transition that records the outcome. An in-memory counter is not durable evidence after a process restart. A timer that keeps a worker occupied is also a different design from persisted due work.
Completion remains guarded by the current claim. That guard helps prevent a stale worker from overwriting a newer state; lease expiry alone does not prove the old worker stopped. The example assumes a repeatable source read and a stable result key. An implementation that adds billing, email, or another external write needs a separate side-effect and recovery analysis.
Live model · Sequence view
Review against the existing flow
The report API accepts a job; the worker generates a result; the API exposes job status to the client. A retry feature changes the worker-to-job relationship. It should preserve the API's acceptance promise and the client's authorization boundary.
Explore scenarios in this model
These links open the same public model in a selected view. They do not change its source.
Open this viewer on its own ↗ if the frame is unavailable. The explanation remains readable without the viewer.
Exploration is local to your viewer. Reload or Reset view returns to the source layout.
Keep a small evidence ledger
For each promised behavior, record the changed symbol, a check that can expose a violation, and its result. For example: temporary input failure followed by success should preserve one job ID; a permanent error should stop after one classified attempt; exhaustion should expose a terminal state; competing claims should permit only the valid owner to finalize. A passing happy path says little about the other three.
If code and model disagree, resolve the decision explicitly. Update the model when a justified implementation choice changes the contract, or fix the implementation when it violates the agreed behavior. Ask the agent to report the remaining uncertainty before calling the change complete. The diagram is shared review context, not a replacement for code inspection or executed checks.
Ask the agent to mark assumptions
A diagram provides context, but it does not prove what the repository does. Ask the agent to locate the code that accepts a job, changes its status, and authorizes retrieval. Require file references for those claims.
If the agent assumes that generation is safe to repeat, stop and inspect that assumption. The worker might send an email, charge a provider, or append a second output. Put the uncertainty beside the affected relationship, then resolve it from code and tests.
- Known: the API returns a stable job identifier, with a code reference.
- Proposed: temporary failures return the job to a waiting state.
- Unresolved: two workers may claim the same job at the same time.
Review the changed flow, then the patch
Ask for a short sequence covering the first failure, the next attempt, and the exhausted-attempt case. Compare that sequence with the original acceptance and retrieval flow. The client should not need a new job identifier merely because the worker tried again.
Now inspect the patch. Check where the retry count is stored, how a job is claimed, and which errors are classified as temporary. A fluent explanation can describe behavior that the code never implements, so trace each important claim to a change or a test result.
Request evidence for the promise
Use a few checks that could disprove the proposed behavior: a temporary failure followed by success; a permanent failure that is never retried; an exhausted job with a visible terminal state; and two workers competing for the same job. Record which checks ran and which remain untested.
Update the map when the implementation is accepted. Keep the decision and the evidence together so a future author or agent can see why the boundary works that way. The result is a reviewable change, not just a larger amount of generated code.