Reliability, permissions, and safety

A temporarily unavailable service may recover before the next attempt. A request with a missing required field needs correction. Those failures deserve different responses.

A retry policy specifies eligible failures, spacing, and limits. For an operation with side effects, also account for the possibility that the first attempt took effect despite the reported problem.

A timeout ends an allowed wait or execution interval. From the caller's perspective, it says the result did not arrive in time. A remote service may continue working after that point. Before repeating a consequential request, check its status or use an appropriate duplicate-protection mechanism. This uncertainty is exactly why timeout handling matters.

Suppose a service creates an order but its reply is lost. With a supported idempotency key, the caller can identify a retry as the same operation instead of a new order. The server implements that duplicate handling under its own contract. Idempotency concerns the intended effect on state; repeated calls need not produce identical response text.

Suppose the next step expects an item identifier, quantity, and status. A structured response supplies those named values directly, with some systems enforcing the schema during generation.

The application can then parse the result predictably. Checking whether it names the right item is a separate task.

A validator compares data with declared rules for fields, types, and permitted values. It can catch missing information before the next operation runs. The scope of that check matters: a correctly shaped address can belong to the wrong customer. Business rules and factual checks handle questions beyond the schema's contract.

When the preferred path fails, a fallback offers another acceptable way to proceed. That may mean another tool, another model, or a person taking over. Choose it with its capabilities and operating limits in mind. A slower route can be entirely suitable if it meets the task requirements and preserves the same access restrictions.

Durable execution combines persisted progress with recovery behavior. After an interruption, the workflow uses recorded state and results to resume or replay work safely. Operations in external services need special care because recovery can otherwise repeat their effects. Recording progress and protecting those operations work together to make continuation dependable.

Guardrails can act at several points: incoming requests, proposed tool calls, and generated outputs. Some apply explicit rules; others use models to assess content and can make classification errors. Decide what each check covers and how the application responds to its result. A rule that only produces an ignored warning provides little control over execution.

Start with the access the task requires. If the work only reads a particular collection, grant read access to that collection rather than broad write permissions. Limits can apply to scope and duration. This reduces how far a mistake or manipulated request can reach and makes permissions easier to review when the task changes.

A person can resolve ambiguity, correct a result, or decide at a defined point in an automated workflow. Give that person a clear question and the evidence needed to answer it. The application must then capture the response and continue appropriately. “Human-in-the-loop” becomes meaningful when the loop has a specific decision attached to it.

An approval gate binds authorization to a particular action and its important details. Preparing an email may be allowed while sending it waits for approval. If the recipient or content changes materially, check whether that authorization remains valid. Enforce the gate in the application so the protected action waits for the required decision.

Escalation is useful when the task exceeds the agent's authority, evidence, or ability to proceed. Send the goal, relevant findings, attempted steps, and unresolved decision to the appropriate person or system. That gives the recipient something concrete to resolve. Unlike an approval request for a prepared action, escalation can require a change to the plan itself.

External material can contain instructions that try to redirect the agent. When a page, file, or tool result carries the attempt, it is indirect prompt injection. The system should treat that material according to its role as data rather than granting it control over the task. Access restrictions and other defenses help limit the consequences when recognition fails.

Tool results deserve two separate questions: is the information reliable, and what authority should it have? A returned record may be useful evidence without being a valid source of new instructions. Results can also include mistakes or content supplied by outsiders. Decide how the application verifies and uses them before allowing them to influence consequential actions.