Six Reference Patterns for AI-Enabled Business Automation

Why decision boundaries matter more than a list of examples

An AI component produces probabilistic output. A business process still needs deterministic authority: which records may enter, which action may occur, which evidence survives, and which person can accept an exception. NIST’s AI Risk Management Framework organizes this work around governing, mapping, measuring, and managing risk. Its Generative AI Profile adds risks such as confabulation, data privacy, information integrity, and human-AI configuration. Those concerns apply differently when a model drafts text than when an agent can change a customer record.

Start with the consequence of a wrong output. A reversible suggestion can enter a review queue. A write, message, deployment, entitlement change, or financial action needs a separate authorization boundary. “Human in the loop” is not a sufficient design description: identify the owner, the evidence shown to that owner, and what happens if no decision arrives.

Pattern 1: source-grounded drafting

Use this pattern to produce a first draft whose material claims can be traced to an approved source set. The model may organize, summarize, and explain; it does not create facts or publish the result.

• Allowed inputs: versioned policies, approved research, meeting notes with known provenance, product documentation, and a written brief. Record source URL or document ID, retrieval date, and relevant passage.
• Prohibited action: publication, external sending, silent addition of unsupported claims, or use of a source outside the approved collection.
• Human owner: the named editor or subject-matter owner who can verify both meaning and source fitness.
• Failure evidence: sentence-level source links, unsupported-claim flags, conflicting passages, missing-source markers, and the prompt/model/source-set version.
• Stop condition: stop and return an evidence gap when a material claim lacks support, sources conflict, the source is stale for the question, or the request requires knowledge outside the collection.
• Suitable implementation class: a retrieval-assisted drafting service with immutable source references, constrained templates, citation checks, and an editorial queue.

This pattern addresses confabulation by changing the workflow rather than pretending the model cannot be wrong. The draft should visibly distinguish quoted or sourced facts from editorial interpretation. Acceptance means the editor can reproduce the support for each consequential statement—not that the prose merely sounds plausible.

Pattern 2: classification to a review queue

Use classification when the machine can route work but should not decide the underlying business outcome. Examples include assigning an inbound request to a queue, tagging a document for review, or prioritizing a possible policy exception.

• Allowed inputs: the minimum fields needed for the approved label set, with restricted attributes removed unless their use is explicitly justified and tested.
• Prohibited action: automatic denial, approval, deletion, disciplinary action, eligibility decision, or customer-facing commitment based only on the predicted label.
• Human owner: the queue manager who owns label definitions, service rules, overrides, and downstream decisions.
• Failure evidence: original item, predicted label, confidence or score where meaningful, model/version, reviewer correction, subgroup or slice results where lawful and relevant, and queue aging.
• Stop condition: send to an unclassified or specialist queue when required data is missing, multiple labels are plausible, input is out of scope, or monitored error exceeds the approved tolerance.
• Suitable implementation class: a bounded classifier feeding a case-management queue, with deterministic routing rules, an override reason, and sampled quality review.

Do not convert a score directly into business authority. Test the entire routing system: label definitions, representative evaluation data, reviewer behavior, and the cost of delay or misrouting. NIST’s playbook emphasizes documenting knowledge limits, human oversight, testing, and monitoring; corrections from reviewers should become evaluation evidence rather than disappear into operational history.

Pattern 3: extraction with deterministic validation

Use extraction to turn unstructured material into a proposed structured record. The model finds candidate values; deterministic code decides whether the proposal satisfies the schema and business rules.

• Allowed inputs: approved document types, declared pages or fields, and only the data classes permitted for the destination system.
• Prohibited action: committing a record when required values are absent, ambiguous, internally inconsistent, or invalid under deterministic validation.
• Human owner: the operations or data steward who owns the target schema, exception queue, and correction policy.
• Failure evidence: document ID and hash, page or region reference, raw extracted value, normalized value, schema errors, rule failures, and reviewer correction.
• Stop condition: quarantine the item when a required field fails type, format, range, cross-field, duplicate, or reference-data checks; never invent a value to complete the record.
• Suitable implementation class: document parsing plus model-assisted extraction, followed by JSON Schema or typed validation, business-rule checks, and a review queue before writeback.

Separate syntax from meaning. A date can be valid syntax but impossible for the transaction; a vendor name can be readable but absent from the approved master. Preserve the source region so the reviewer can compare the proposal with the document. Measure field-level acceptance and correction reasons rather than reporting only whether the pipeline completed.

Pattern 4: retrieval with abstention

Use retrieval to answer from an authorized knowledge collection when “no supported answer” is an acceptable outcome. The system must be able to abstain instead of filling a gap with general model knowledge.

• Allowed inputs: the user question, access-controlled indexed content, document metadata, and a declared conversation window.
• Prohibited action: answering a material question without adequate retrieved support, exposing content the requester cannot access, or presenting model memory as collection evidence.
• Human owner: the knowledge owner who controls inclusion, freshness, permissions, and escalation to an expert.
• Failure evidence: query, filters, retrieved document IDs and passages, ranking scores where available, answer citations, access decision, and abstention reason.
• Stop condition: abstain when retrieval is empty, weak, contradictory, stale for the task, blocked by permissions, or unrelated to a material part of the answer.
• Suitable implementation class: permission-aware search or retrieval-augmented generation with citation enforcement, support thresholds, contradiction handling, and expert escalation.

An abstention should be useful: state what could not be established, identify the searched collection, and offer the correct escalation path. Evaluate unsupported-answer rate, citation correctness, permission isolation, and performance on deliberately unanswerable questions. A polished response unsupported by the retrieved material is a failed run.

Pattern 5: code or change suggestion with CI review

Use this pattern when AI proposes a code, configuration, infrastructure, or documentation change but the repository and delivery controls retain authority. The output is a diff on a non-protected branch—not a deployment.

• Allowed inputs: an approved repository scope, issue and acceptance criteria, relevant tests, dependency policy, and least-privilege read access to required context.
• Prohibited action: direct push to a protected branch, bypass of required review or status checks, secret access not needed for the task, production deployment, or self-approval.
• Human owner: the code owner or change owner accountable for design, security impact, merge, release, and rollback.
• Failure evidence: proposed diff, generation context, test and static-analysis results, dependency changes, review comments, failed checks, and provenance of generated artifacts.
• Stop condition: stop on failing tests, ambiguous acceptance criteria, out-of-scope files, a new privilege or dependency without approval, suspected secret exposure, or inability to explain the change.
• Suitable implementation class: a repository-scoped coding assistant that opens a pull request; protected branches, required reviews, CI checks, artifact signing or provenance controls, and a human merge remain outside the model.

NIST’s Secure Software Development Framework calls for security practices throughout software development, including protecting software from tampering and identifying and responding to vulnerabilities. GitHub documents protected-branch controls such as approving reviews and passing status checks before merge. These controls should be enforced by the platform; a prompt that asks an assistant to “wait for review” is not equivalent.

Pattern 6: agent and tool action with explicit approval

Use a tool-using agent only when multi-step planning adds real value and every consequential action has a machine-enforced approval boundary. Reading a catalog and drafting a proposed update are different permissions from changing the system of record.

• Allowed inputs: an allowlisted task, least-privilege tool schemas, approved resources, bounded working memory, and a policy that classifies actions by consequence.
• Prohibited action: any external write, message, purchase, publication, deletion, permission change, deployment, or irreversible step without explicit approval tied to the exact action arguments.
• Human owner: the business owner of the affected system; the approver must understand the action, target, changed fields, expected effect, and recovery path.
• Failure evidence: run and trace ID, tool name, proposed arguments, policy decision, approval identity and timestamp, tool result, side-effect identifier, and before/after state where permitted.
• Stop condition: stop when approval is denied, expires, or no longer matches the arguments; when a tool response is ambiguous; when the plan leaves the allowlist; after the action budget is reached; or when recovery evidence is unavailable.
• Suitable implementation class: an orchestrated agent with typed tools, read/write separation, policy enforcement, pause-and-resume state, explicit approval records, idempotency keys, and a small action budget.

The OpenAI Agents SDK documents a human-in-the-loop flow in which sensitive tool calls can pause execution for approval or rejection and later resume from stored run state. That mechanism is useful only if the application defines which calls are sensitive and validates the resumed action. Never approve a category such as “update CRM” in the abstract; approve the exact record, fields, values, and intended consequence.

Reference matrix: choose by the last safe machine decision

For implementation context, see Meditel’s AI automation hub, its guide to AI workflows and business impact, and the AI tools hub. These internal references add selection context; they do not replace the official risk and control sources below.

A common pilot gate for all six patterns

1. Freeze the contract: allowed inputs, prohibited actions, owner, evidence, stop condition, and implementation class.
2. Build an evaluation set: normal, ambiguous, incomplete, contradictory, restricted, adversarial, and out-of-scope cases.
3. Exercise the stop path: prove that abstention, quarantine, failed CI, denied approval, and expired approval prevent the next action.
4. Test permissions: a user or agent must not retrieve, propose, or execute beyond its role.
5. Test recovery: interrupt a run after a partial result and prove that an operator can determine what happened without repeating a consequence.
6. Record changes: re-evaluate after changes to data, prompts, models, tools, schemas, dependencies, policies, or access rules.

Reject the pilot if evidence exists only for successful demonstrations. Production readiness requires observable failure, enforced stopping, named ownership, and a recovery path. The appropriate implementation may still be a manual process when volume is low, exceptions dominate, source permissions are unresolved, or the human review burden exceeds the value of automation.

Primary and official sources

Verified August 7, 2026. Product and guidance pages can change; recheck them before implementation.

• NIST — AI Risk Management Framework program page
• NIST AI 100-1 — Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• NIST AI 600-1 — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
• NIST AI Resource Center — AI RMF Playbook
• NIST SP 800-218 — Secure Software Development Framework (SSDF) Version 1.1
• GitHub Docs — About protected branches
• OpenAI Agents SDK — Human-in-the-loop approvals