AI Agents: Start with One Bounded, Reviewable Workflow

A workflow follows predefined stages; an agent can choose actions dynamically. Anthropic describes this distinction in its foundational agent-design article. It does not establish that chatbots have disappeared or that specialist agents work perfectly.

Use a fictional ticket: I cannot export the report. Classify it as a product question, cite the approved support note and prepare a draft. Do not let the prototype send mail, alter an account or issue a refund.

Input: synthetic ticket and approved sources. Output: category, evidence and draft. Allowed action: create a private review record. Stop conditions: missing policy, invalid output or ambiguous request. A human decides whether any external action is appropriate.

Test a normal ticket, missing source, hostile instructions inside a ticket, malformed output and provider failure. Validate shape separately from factual support. Human review must happen before the action it is supposed to control.

Measure the manual baseline and the prototype. Add an agent only if the task needs flexible action selection and the benefit outweighs cost and failure risk. Tool documentation and permissions need current platform checks.

• Agent workflow design (foundational, December 2024)
• Human review for tool calls

A workflow follows predefined steps. An agent may choose steps or tools toward a goal. That flexibility creates a reason to specify authority, termination and review. It is not automatically a reason to replace a simple script.

Use this fictional task: categorize three support tickets and draft responses. Ticket A asks how to reset a password; B asks for an invoice; C requests a refund with no purchase date. If routing depends on a small fixed list of categories, start with explicit rules. If the task requires searching approved sources or deciding which clarification to ask, a bounded assistant step may help.

Give the assistant only the ticket and approved help documents. Request category, source_id, draft_reply and needs_review. Set needs_review=true for missing evidence or a policy exception. It may draft; it may not send, delete accounts or issue refunds. A separate credentialed service checks approval before acting.

For ticket C, the reference outcome is a clarification or human review, not an automatic refund. Treat instructions embedded in a customer message as content, not as authority to change the contract.

• Clear password request: expected login category and a reply grounded in the supplied help document.
• Unknown request: expected uncertainty and review, rather than a made-up policy.
• Duplicate ticket ID: one downstream action.
• Missing or inaccessible source: no unsupported answer.
• Tool timeout: a visible retry or failure state; no success claim.
• Rejected approval: no external send.

Store the input, draft, check result and approval with the same task ID. Stop after a defined attempt or time limit and hand unresolved cases to a person. Review tool permissions and actual execution logs before widening scope. This guide offers a design exercise, not a claim that a deployed agent passed these cases.

Build a reviewed support workflow · n8n tool notes · Support classification prompt