Learning objectives
- How would you safely let an agent repair a failed build?
- When should an agent be replaced by a deterministic workflow?
- Apply Tool authorization to a customer decision and defend the tradeoff.
The mental model
An agent combines model decisions with tools and state. That combination can be useful when a task requires choosing among steps, but it also makes mistakes more consequential. A model that writes a bad paragraph creates a different risk from one that can change an account or send a payment. Define which decisions are deterministic, which may be delegated, and which require human approval. The user's intent does not automatically authorize every action a model proposes. Your orchestration experience is directly relevant: time limits, retries, durable state, cancellation, and recovery remain necessary even when a model selects the next tool call.
How it works
Represent a workflow with explicit states such as proposed, approved, executing, completed, and failed. Tool definitions should have narrow schemas, bounded inputs, and authorization checked by application code. Treat tool results and retrieved text as untrusted data, not instructions that can silently expand authority. Give the model only the tools needed for the current task, and separate read-only discovery from consequential mutations.
Persist operation identifiers and relevant state before side effects where the design requires recovery. Use idempotency and reconciliation for retried actions. Bound the number of steps, cumulative consumption, elapsed time, and concurrent work; otherwise a loop can continue spending resources without progress. Cancellation needs semantics: stopping new calls does not undo an already completed external action. Record an audit trail that explains the requested action, approval, tool inputs, and result without storing unnecessary sensitive reasoning or payloads. Test tool denial, malformed output, stale context, duplicate delivery, and partial completion. A deterministic workflow may be preferable when the sequence is known and model discretion adds little value.
An approval should refer to a concrete action and scope. Approving a patch to one configuration file should not authorize a later tool call that changes unrelated credentials. Bind the approval to a revision or structured action description and recheck it immediately before execution. A workflow log should let an operator reconstruct what was authorized and what occurred. This is especially important when a model revises its plan after receiving new tool results.
Applied example · hypothetical
Hypothetical scenario: an agent reviews a failed build and proposes a configuration repair. It can read logs and draft a patch, but cannot deploy. A separate approval boundary controls applying the patch. The orchestration layer records the approved revision and rejects attempts to apply a different one. A test injects a log message instructing the agent to reveal credentials; the application treats it as log content, not authority. The resulting system is evaluated on useful diagnoses and safe tool behavior, not only task completion rate.
In a customer engagement
Ask the customer which actions are reversible, who may authorize them, and what evidence must be retained for audit. Demonstrate a denied action and a cancelled workflow alongside a successful run. For a production proposal, name the human owner of exceptions and explain how partial work will be reconciled after a timeout or provider failure.
Interview relevance
Use a workflow or automation project as evidence of orchestration judgment, but verify the architecture and your contribution before telling a story. In an interview, distinguish a model suggestion from application authorization. A strong answer explains bounded autonomy, durable execution, and safe failure without pretending that a better prompt replaces access control.
Common mistakes
- Treating tool output as trusted instruction
- Assuming cancellation undoes effects
- Using an agent for every task
Key terminology
Tool authorization — Application-enforced permission to execute a specific tool action under the current identity and scope.
Bounded autonomy — Delegating decisions within explicit limits on authority, steps, time, and resource consumption.
Workflow reconciliation — Determining actual external state after partial or ambiguous execution and bringing records back into agreement.
Explain it without the page
- How would you safely let an agent repair a failed build?
- When should an agent be replaced by a deterministic workflow?
Further reading
Sources explain the underlying concepts; examples and practice answers are original course material. Recheck current limits and plan eligibility before a real proposal.