Decision guide / AI agent use cases
Give an agent a task with an observable finish.
An agent can choose its next tool call from what it discovers. That flexibility is useful when the path varies, but the task, permissions, and finish can still be defined. Start with one complete piece of work and compare its result with the process your team already uses.
The task test
A changing path still needs a fixed boundary.
Consider an agent when a task needs several evidence-dependent steps: inspect a record, decide which source or tool to consult next, prepare a change, and verify the resulting state. If the sequence is already known, a conventional workflow may be easier to operate. If the finish cannot be checked, adding an agent does not make the work complete.
- A task, not a job title
- Prepare one account handoff is a bounded task. Run sales is not. Name the trigger, records, output, allowed effects, and person who can accept the result.
- Adaptation, not extra steps
- A long fixed sequence does not automatically need an agent. Ask which decision about the next step depends on evidence that only becomes available during the task.
- An outcome, not a claim
- A tool call or completion message is not proof of success. Inspect the saved record, reviewed artifact, or verified system state, including partial and failed effects.
Six bounded use cases
Choose the work your team can direct and inspect.
These are illustrative task designs. Their value must be established in the actual organization. Each can begin with a narrow set of records and tools, then expand only when evidence supports the added responsibility.
Support: follow through on one case
01Why adapt: The next question or lookup depends on the customer's answer and the current case state.
- Trigger and task
- A support request needs information from the order record, policy, and previous interactions before a useful response or escalation can be prepared.
- Authoritative inputs
- Verified customer/case identity, permitted order history, current policy, and relevant support records.
- Permitted action path
- Read scoped records, request missing context, prepare a response, and append an approved note through a case-specific tool. Recheck the case before a write and retain its receipt.
- Retained owner
- A support owner approves exceptions, refunds, commitments, and external messages beyond the explicitly delegated scope.
- Observable finish
- A correct response or complete escalation linked to the right case, with any approved update visible in the case system.
- Stop condition
- Identity mismatch, contradictory policy, missing evidence, repeated failed calls, or a requested remedy outside the allowed action set.
- Trial measure
- Compare accepted resolutions or escalations per eligible case, reopens, correction effort, and total handling time.
Sales: prepare an account handoff
02Why adapt: The evidence gap differs by account, so the agent may need another permitted record before it can summarize the next step.
- Trigger and task
- An account owner needs a source-linked handoff after a meeting or change in ownership.
- Authoritative inputs
- Approved CRM records, consented meeting notes, current opportunity facts, and the receiving owner's information requirements.
- Permitted action path
- Find missing context within the authorized account, identify contradictions, draft the handoff, and save approved notes or tasks against the exact account.
- Retained owner
- The account owner confirms commercial facts, commitments, next actions, and any communication to a prospect or customer.
- Observable finish
- A reviewed handoff with traceable facts, explicit unknowns, and correctly assigned follow-up tasks.
- Stop condition
- Cross-account data, unsupported buying intent, missing consent, conflicting commitments, or a request to send unapproved outreach.
- Trial measure
- Compare reviewer correction time, unsupported claims, missing required fields, and follow-up tasks accepted by the receiving owner.
Procurement: resolve a missing-information loop
03Why adapt: The next evidence request depends on which purchase or receipt fact is absent or inconsistent.
- Trigger and task
- A buyer cannot progress an existing request because a specification, acknowledgement, or receipt detail is missing.
- Authoritative inputs
- Authorized purchase request, order and receipt records, supplier correspondence, specification, and the buyer's decision rules.
- Permitted action path
- Locate the gap, gather permitted evidence, draft a targeted clarification, and record an approved request or internal follow-up. Preserve the original values when sources disagree.
- Retained owner
- The buyer controls supplier choice, price, purchase commitments, payment, and acceptance of a changed specification.
- Observable finish
- A complete evidence packet or an explicit unresolved exception assigned to the right buyer, with the clarification history attached.
- Stop condition
- An apparent clarification changes price or scope, a sender's authority is uncertain, or the next step would commit money or accept goods.
- Trial measure
- Compare time to decision-ready information, repeated clarification requests, incorrect closures, and buyer review effort.
Logistics: investigate a shipment exception
04Why adapt: The appropriate next lookup depends on whether the gap is a missing event, conflicting status, or an operational exception.
- Trigger and task
- A shipment alert needs a factual explanation and an accountable handoff rather than another unverified status message.
- Authoritative inputs
- Permitted shipment identifiers, timestamped carrier events, warehouse records, current service rules, and the operations queue.
- Permitted action path
- Reconcile available events, query approved sources, prepare an exception summary, and create a scoped internal follow-up with source timestamps.
- Retained owner
- An operations owner approves rerouting, service promises, compensation, and instructions affecting physical work.
- Observable finish
- An exception record that separates observed events from estimates and names the owner of the next action.
- Stop condition
- Conflicting identifiers, stale feeds, unsupported delivery predictions, or an action that would alter routing or custody without approval.
- Trial measure
- Compare correct exception classification, handoff completeness, repeated investigations, and time until an owner accepts the case.
IT service: gather a diagnostic record
05Why adapt: Each observation changes which approved diagnostic is useful next.
- Trigger and task
- A service incident requires evidence from several systems before an engineer can decide on remediation.
- Authoritative inputs
- Scoped service inventory, sanitized logs, approved telemetry, recent change records, and the incident's access boundary.
- Permitted action path
- Run allowlisted read-only diagnostics, correlate observations, reproduce in an isolated environment where available, and attach evidence to the incident.
- Retained owner
- The service owner controls production changes, access grants, restarts, security decisions, and incident closure.
- Observable finish
- A reproducible diagnostic packet with observed facts, rejected hypotheses, remaining uncertainty, and a named remediation owner.
- Stop condition
- Secrets in retrieved output, a requested production mutation, an unapproved command, or a diagnostic loop that stops adding evidence.
- Trial measure
- Compare time to a usable diagnosis, misleading recommendations, duplicate investigation, and engineer verification effort.
Software: repair a bounded defect
06Why adapt: The files to inspect and the next repair depend on reproduction and test results.
- Trigger and task
- A well-described defect has an agreed scope and a development environment where the behavior can be reproduced.
- Authoritative inputs
- Authorized repository state, task requirements, relevant tests, local conventions, and protected-path constraints.
- Permitted action path
- Inspect code, reproduce the failure, edit within an isolated work area, run focused checks, and prepare a reviewable patch with evidence.
- Retained owner
- A maintainer decides acceptance, merge, release, architecture changes, and any expansion into sensitive or unrelated work.
- Observable finish
- A patch that fixes the specified behavior, preserves relevant behavior, and includes test results and unresolved limitations.
- Stop condition
- Missing reproduction, unreliable tests, unrelated changes, secret access, or a proposed production action outside the task.
- Trial measure
- Compare accepted patches per eligible defect, regressions, review effort, and total time including repair after review.
Measure the finish
Count useful outcomes and the work left behind.
Use the same eligibility rules for the existing process and the trial. Keep failed attempts, escalations, and abandoned tasks in the denominator. The measures below are proposed evaluation fields, not promised improvements.
| Business task | Accepted outcome | Quality countermeasure | Residual human work | Compare against |
|---|---|---|---|---|
| Support case | Correct resolution or complete escalation | Reopens, wrong-account effects, unsupported promises | Review and correction time per case | The same case cohort under the existing support process |
| Account handoff | Handoff and tasks accepted by the owner | Unsupported facts and missing requirements | Fact checking and task correction | Manual preparation or a fixed summary workflow |
| Procurement gap | Decision-ready packet or owned exception | Incorrect closure and repeated clarification | Buyer investigation still required | Existing request handling with the same evidence access |
| Shipment exception | Correct, timestamped handoff | Stale status and invented delivery claims | Operations verification and follow-up | Rules-based alerts plus current investigation |
| IT diagnosis | Usable, reproducible diagnostic evidence | Misleading hypotheses and unsafe command attempts | Engineer verification and remediation | Runbooks and the existing diagnostic process |
| Defect repair | Accepted patch for the specified behavior | Regressions and scope violations | Review, rework, and release effort | The current development process on comparable defects |
Select a trial
Prove the task before expanding the role.
Begin with a bounded cohort and an owner who can judge outcomes. The first useful result may be evidence that a simpler workflow is sufficient, or that the source systems need repair before an agent can help.
- 01
Observe existing work
Follow real cases through completion, including waiting, corrections, exceptions, and handoffs. Record the baseline and which cases are eligible for a fair comparison.
- 02
Name the adaptive decision
Identify the point where discovered evidence changes the next useful step. Compare an agent with a fixed workflow, search, or one model call before accepting the extra complexity.
- 03
Define the action contract
List exact reads and writes, identities, records, preconditions, approvals, receipts, and stop conditions. A generated plan must not expand those permissions.
- 04
Exercise complete cases
Run ordinary, ambiguous, adversarial, timeout, stale-record, and duplicate-request cases. Inspect final state and residual human work across repeated trials, not only the final answer.
- 05
Review the operating result
Compare accepted outcomes, failure types, review burden, latency, and total cost. Expand only when the owner can explain the evidence, remaining limits, and recovery path.
Across all six cases
Make authority and incomplete work visible.
An agent can investigate within its task without being authorized to perform every action it discovers. These controls belong to the application and operating process, not just to a prompt.
- Scoped identity and evidence
- Bind access to the actual user, organization, task, and record. Preserve source identity and time; treat retrieved instructions as untrusted content rather than new authority.
- Exact action approval
- Where approval is required, show the target, proposed effect, and material parameters. Revalidate them before execution, and request a new decision when the approved action changes.
- Receipts and recovery
- Record whether a write was requested, accepted, completed, or remains uncertain. Use the integration's actual retry and deduplication contract; a timeout does not prove that nothing happened.
- Owned stopping points
- Stop on missing authority, unresolved contradictions, exhausted limits, or repeated tool failure. Preserve the evidence and assign the next decision so a handoff does not silently become abandonment.
Before calling it an agent use case
Ask what changes after the conversation ends.
The task can end in a reviewed artifact, a verified update, or a complete human handoff. It should not end in a confident claim whose effect no one can find.
- Does an agent need permission to write to production?
- No. Adaptive investigation and artifact preparation can be useful tasks. If the use case includes a write, specify that effect explicitly and verify the permission, approval, and receipt. Do not infer broad write access from the word agent.
- When is a conventional workflow better?
- When the steps and routing rules are known and stable, a fixed workflow can provide the required result with less operational complexity. Add adaptive tool selection only where it addresses a demonstrated gap.
- Is human review evidence that the agent failed?
- Not necessarily. Review or escalation may be the intended finish. Measure whether the handoff is correct and useful, and include the review effort when comparing the process. Unexpected rescue work is different from a designed approval step.
- How do we prevent a polished answer from hiding failure?
- Check the actual artifact or system state independently. Require source-linked evidence, explicit incomplete states, and receipts for effects. Evaluate correct refusal and escalation as well as successful completion.
- Should we start with several collaborating agents?
- Only if the task has a concrete need for that structure. First establish the task boundary, interface, evidence, and ownership. More participants introduce additional handoffs and failure paths that also need acceptance tests.
Source basis
Sources behind the control model.
- 01
Anthropic
Building effective agentsSupports the distinction between predefined workflows and adaptive tool use. The 2024 article explicitly warns that its tooling landscape has changed; these cases do not rely on its old product guidance.
- 02
Anthropic
Demystifying evals for AI agentsSupports checking repeated trials, trajectories, and final environmental outcomes. The six business cases and proposed measures are Werkon's illustrative analysis.
- 03
OWASP
Excessive AgencyCommunity guidance on excessive functionality, permissions, and autonomy; not a certification or proof of implementation safety.
- 04
OWASP
AI Agent Security Cheat SheetControl context for scoped tools, untrusted inputs, approvals, observable actions, and abuse-case evaluation.
- 05
Amazon Builders' Library
Making retries safe with idempotent APIsExplains why ambiguous responses and repeated requests require an explicit service contract rather than blind retries.
Start with one real workflow
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD