Mastery: build a support workflow

Your final blueprint should contain nine parts:

1. Use case: bounded intent, channel, audience, and excluded cases.
2. Inputs: permitted data, trusted systems, and minimization rules.
3. Knowledge: approved sources, metadata, ownership, and freshness.
4. AI task: classify, summarize, retrieve, draft, translate, or check.
5. Deterministic controls: identity, eligibility, amount, permission, and state checks.
6. Human gates: review, decision, exception, and send ownership.
7. Escalation: triggers, destination, timing, stop behavior, and fallback.
8. Recovery: correction, customer notification, rollback, and incident process.
9. Evaluation: quality rubric, outcome metrics, severe errors, and change tests.

Name the system of record for each fact. “The AI knows the order” is not acceptable. State whether the order status comes from a live API, a copied field, or a retrieved document, and how freshness is shown.

Not every model output needs the same review. Use proportionate patterns:

• Review before send: an agent inspects every draft.
• Approval: a person authorizes a remedy or disclosure.
• Edit: a specialist corrects nuanced content before use.
• Escalation: uncertainty or risk routes to another owner.
• Batch review: low-impact outputs are sampled after execution.
• Dual control: two authorized people approve rare, high-impact action.

Start consequential workflows with review before send. Reduce review only after evidence shows that a narrow case type is stable, errors are detectable, and rollback is fast. Even then, retain automatic stops for sensitive or ambiguous conditions.

For deeper gate design, continue to Human in the loop. That topic explains how impact, reversibility, and uncertainty determine where review belongs.

An assistant suggests a label, source, draft, or checklist. Automation moves work between systems or performs an action. Connecting the two introduces new failure modes: duplicate sends, stale state, retries that repeat a refund, queue loops, and actions that execute after escalation.

Before automating, define:

• the trigger and idempotency key;
• exact permitted action;
• preconditions checked at execution time;
• timeout and retry behavior;
• confirmation from the destination system;
• audit record;
• stop signal from escalation or human review;
• recovery for partial failure.

Do not let model text directly determine unrestricted tool parameters. Convert it into a constrained proposal, validate fields, and enforce permissions outside the model.

When you are ready to design triggers, deterministic steps, and failure paths, bridge to AI for automation. Automation is a later engineering decision, not the default reward for a good drafting pilot.

Design a workflow for this case:

A customer says their account was charged after cancellation. They include a screenshot containing a partial card number and another person’s email address. The billing record shows cancellation yesterday, one pending authorization, and no settled post-cancellation charge. Policy says pending authorizations are controlled by the bank and usually clear within seven business days. The customer also asks you to delete all their data.

A complete response should:

1. minimize or securely handle the screenshot;
2. separate the customer report from billing facts;
3. avoid calling the pending authorization a settled charge;
4. explain only the approved timing, without a guarantee;
5. route the deletion request through the verified privacy process;
6. avoid exposing the other person’s email;
7. assign owners for billing and privacy work;
8. state when the customer receives the next update;
9. retain a human send gate because the case crosses billing, identity, and privacy.

The AI may summarize separate issues, retrieve relevant policy, and draft a response. Deterministic systems should verify account ownership and transaction state. Authorized people should own the privacy request and any financial remedy.

Prepare tests in three groups.

Normal cases: current knowledge, verified identity, one clear intent, and an allowed response.

Edge cases: multiple intents, missing fields, multilingual text, stale articles, contradictory records, unusual tone, accessibility needs, and previous failed contacts.

Stop cases: account takeover, dangerous product report, self-harm or violence signal, legal demand, another person’s data, unavailable policy owner, and unsupported high-value remedy.

For each test, specify the expected sources, output, escalation, prohibited action, and human gate. A system does not pass merely because the wording looks good. It must take the correct path.

Red-team the workflow with instructions embedded in customer text and attachments, fabricated urgency, altered identifiers, quoted harmful language, and requests to bypass policy. Verify that content never changes system permission.

Before a pilot:

• the use case and exclusions are documented;
• data use is approved and minimized;
• every source has scope, owner, and freshness metadata;
• reply prompts preserve conditions and unknowns;
• high-impact actions are permission-checked;
• escalation routes have owners, targets, and fallbacks;
• escalations block incompatible actions;
• agents can inspect original evidence;
• logs capture versions, decisions, edits, and actions;
• evaluation includes representative and severe cases;
• stop thresholds and rollback are rehearsed;
• customers have a route to correction;
• agents are trained to challenge plausible drafts.

After launch, review incidents, edits, missed questions, repeat contacts, and queue displacement. Update the narrow component that failed—knowledge, retrieval, prompt, rule, permission, interface, or staffing—rather than assuming every defect is a model problem.

Give one point for each checklist statement above. Ten to twelve points suggests readiness for a limited, monitored pilot. Seven to nine means important controls remain incomplete. Six or fewer means the workflow should remain in design or offline evaluation.

This score is not certification. One critical gap—such as no identity check before disclosure—can block launch regardless of the total. Risk is not safely averaged away.

You have demonstrated mastery when another operator can follow the blueprint, tell why a reply is grounded, know what they may approve, recognize when to stop, and reconstruct what happened after an error.