What you will learn
JSON contracts, Dispatch, Deadlines, Idempotency, Error taxonomy.
Engineering the capability
A tool runtime translates a proposed call into validated application behavior. Separate tool selection, argument validation, authorization, execution, and observation formatting. Never dispatch arbitrary names through dynamic evaluation. Use an explicit registry and make each tool responsible for domain-specific checks.
Return structured observations that distinguish not found, denied, unavailable, and successful results. A generic “failed” string encourages pointless retries. Define which errors are retryable and a shared deadline for the whole task. A timeout on a mutation is ambiguous: the remote action may have completed even though its response was lost.
Idempotency requires durable coordination, not only a key attached to a request. Store or delegate the key so repeated execution refers to the same operation. Reconcile uncertain outcomes before attempting another side effect.
Worked case
A create-ticket request times out after the server commits it. Retrying without an operation key creates a duplicate. Repeating the same key should return the original result or reconcile its status. The model should see “operation pending” rather than being encouraged to invent a new ticket request.
Put it into practice
Continue with the next lab: implement a guarded tool registry. Build the artifact, record the failure cases, and explain the tradeoff before moving on.