LLM & Agentic AI

An AI Copilot Inside a Business Process

Follow a support ticket from an authorized draft to a human-approved update, and stop the write when the proposal is rejected or invalid.

Reference architecture - illustrative, not a client deployment

Follow a support ticket from assisted drafting to an approved system update.

Complexity
Intermediate
Drawing
Supplied
  • Agentic AI
  • Human-in-the-loop
  • Customer support
  • Business process

Overview

This reference architecture is illustrative. It is not a record of a client deployment.

A support copilot can draft a reply and propose a ticket change. The draft is not a completed write. The path is fixed: load the ticket under the employee's identity, retrieve only permitted knowledge, propose a reply and action, validate business rules, then wait for a person. Anthropic calls that shape a workflow, because code chooses the path, and treats ticket updates as actions that still need human oversight.

A concrete example

A customer asks for a replacement after a laptop fails during the warranty window. The copilot retrieves the warranty article the signed-in agent may see and proposes a reply plus a status change. Rules reject the update if the warranty field is missing or the status is not allowed. If the rules pass, the support agent sees the exact fields that would be sent. Approval issues one idempotent update. The audit record stores the business system's outcome and a correlation id. The customer reply goes out only after that outcome is confirmed. A rejected proposal never calls the update.

Common misconception

"The assistant already updated the ticket because the reply sounds final." A suggestion is not an execution. Microsoft's orchestration guidance says a mandatory human gate should pause the flow and persist state until the person responds, and that approval can be limited to sensitive operations. The recorded outcome comes from the business system, not from the model's sentence.

Diagram & Walkthrough

Choose a declared scenario and step, or select a component by pointer, touch or keyboard. Playback starts only when you press Play and pauses when this panel leaves the screen.

100%
An AI Copilot Inside a Business Process A support ticket is grounded in authorized knowledge, turned into a proposal, checked against business rules, approved by a support agent and only then used to update the CRM, record an audit event and send a confirmed response. Invalid or rejected proposals are escalated to a person. An AI Copilot Inside a Business Process A suggestion becomes a business action only after validation and human approval. SUPPORT CONTEXT SUGGESTION AND CONTROLS BUSINESS EXECUTION Question +access context Authorized evidence Suggested reply+ action Validatedproposal Approved idempotentupdate Outcome +correlation ID Confirmed response Rejected proposal Invalid or uncertain action Support ticket+ identity DATA Authorized knowledgeretrieval DETERMINISTIC Response + actionproposal MODEL · DRAFT ONLY Business rules+ validation DETERMINISTIC Support-agentapproval HUMAN DECISION ✓ Human escalation STOP · REVIEW Audit trail DATA · RECORDED CRM update EXTERNAL · CONFIRMED ✓ Customerresponse EXTERNAL ✓ Flow legend Data · main path Control Feedback Rejected / blocked The model drafts; rules validate; a person approves; confirmed system outcomes are recorded.

Main walkthrough, step 1 of 6: Load the ticket. idle.

Main walkthrough

The primary path through this reference architecture.

Active parts: Support ticket + identity, Authorized knowledge retrieval

Text walkthrough

This vertical reference remains readable without the interactive controls.

  1. 01Load the ticket

    The ticket is read with the signed-in employee's access context. The customer's wording is not the identity.

    Active parts: Support ticket + identity, Authorized knowledge retrieval

  2. 02Draft with authorized evidence

    The model drafts a reply and a proposed action from the authorized passages only.

    Active parts: Authorized knowledge retrieval, Response + action proposal

  3. 03Validate business constraints

    Deterministic rules check the proposed fields before any person is asked to approve them.

    Active parts: Response + action proposal, Business rules + validation

  4. 04Request approval

    The support agent sees the validated proposal, including the exact fields a write would send.

    Active parts: Business rules + validation, Support-agent approval

  5. 05Update the system of record

    Approval releases one idempotent update. The audit trail records the confirmed outcome and correlation id.

    Active parts: Support-agent approval, CRM update, Audit trail

  6. 06Respond or escalate

    A confirmed update can produce the customer reply. A rejected or invalid proposal escalates instead, with no write.

    Active parts: CRM update, Customer response, Support-agent approval, Business rules + validation, Human escalation

Connections

  • Question + access contextSupport ticket + identity to Authorized knowledge retrievaldata
  • Authorized evidenceAuthorized knowledge retrieval to Response + action proposaldata
  • Suggested reply + actionResponse + action proposal to Business rules + validationdata
  • Validated proposalBusiness rules + validation to Support-agent approvalcontrol
  • Approved idempotent updateSupport-agent approval to CRM updatecontrol
  • Outcome + correlation IDCRM update to Audit traildata
  • Confirmed responseCRM update to Customer responsedata
  • Rejected proposalSupport-agent approval to Human escalationcontrol
  • Invalid or uncertain actionBusiness rules + validation to Human escalationcontrol

Components

Support ticket + identitydata

The customer request plus the signed-in employee's identity. The identity is established by the application, not by text in the ticket.

Responsibilities

  • Carry the customer request
  • Carry the trusted employee identity

Inputs

  • Support ticket
  • Authenticated employee session

Outputs

  • Question and access context

Risks

  • Trusting a name typed into the ticket
  • Acting on a stale ticket version
Authorized knowledge retrievaldeterministic

Retrieves only articles and records the employee is allowed to see. Retrieval does not update the ticket.

Responsibilities

  • Apply the employee's access scope
  • Return source references with the passages

Inputs

  • Question and access context

Outputs

  • Authorized evidence

Risks

  • A filter that trusts caller-supplied group names
  • Stale or out-of-scope articles
Response + action proposalmodel

Drafts a customer reply and a suggested ticket action. The proposal has no permission to write the system of record.

Responsibilities

  • Draft from the authorized evidence
  • Propose an action as data, not as an execution

Inputs

  • Authorized evidence

Outputs

  • Suggested reply and action

Risks

  • A confident draft that exceeds the evidence
  • Instructions hidden in the ticket or the article
Business rules + validationdeterministic

Checks the proposed fields against allowed values, required data and policy. A fluent reply does not pass this gate.

Responsibilities

  • Reject missing or disallowed fields
  • Pass only a structurally valid proposal onward

Inputs

  • Suggested reply and action

Outputs

  • Validated proposal
  • Or an invalid-action signal

Risks

  • Rules that check tone instead of the fields that will be written
  • A gap that lets an unexpected status through
Support-agent approvalhuman

The support employee accepts or rejects the exact update. Approval is the human decision, not a second model vote.

Responsibilities

  • Show the fields that will be sent
  • Record accept or reject before any write

Inputs

  • Validated proposal

Outputs

  • Approved update
  • Or a rejected proposal

Risks

  • Approval fatigue
  • A dialog that hides the action arguments
CRM updateexternal

The system of record applies one approved, idempotent update and returns the outcome. The model does not declare success.

Responsibilities

  • Apply only the approved change
  • Return a confirmed outcome

Inputs

  • Approved idempotent update

Outputs

  • Confirmed outcome
  • Correlation id

Risks

  • A retry that duplicates a non-idempotent write
  • A timeout whose outcome is still unknown
Audit traildata

Stores the confirmed outcome and correlation id from the system of record, tied to the person who approved the change.

Responsibilities

  • Record who approved what
  • Record the system's outcome rather than the draft

Inputs

  • Outcome and correlation id

Outputs

  • Durable audit event

Risks

  • Logging the proposal instead of the confirmed write
  • An audit gap when the update fails
Customer responseexternal

Sends the customer reply only after the system of record confirms the update.

Responsibilities

  • Send the reply that matches the confirmed outcome

Inputs

  • Confirmed response

Outputs

  • Customer-visible reply

Risks

  • Sending a reply before the write is confirmed
  • Promising a change the system did not apply
Human escalationhuman

A person takes the case when the proposal is invalid or rejected. No system-of-record update runs on this path.

Responsibilities

  • Receive the failed or rejected case
  • Continue without an unapproved write

Inputs

  • Rejected proposal
  • Or an invalid action

Outputs

  • Human-owned next step

Risks

  • Escalating without the reason
  • A later retry that bypasses the failed gate

Scenario reference

Proposal rejected

Do not execute an unapproved action.

  1. 01Offer the validated proposal

    The person reviews a proposal that already passed the business rules.

    Active parts: Business rules + validation, Support-agent approval

  2. 02Stop when the person rejects it

    Rejection escalates the case. The system of record is not called.

    Active parts: Support-agent approval, Human escalation

Validation failed

Route unsupported or unsafe proposals to a person.

  1. 01Check the suggested action

    Rules inspect the suggested reply and action before any approval dialog.

    Active parts: Response + action proposal, Business rules + validation

  2. 02Escalate the invalid action

    An invalid or uncertain action goes to a person. It does not continue to approval or the update.

    Active parts: Business rules + validation, Human escalation

Design Decisions

  • Retrieve knowledge with the employee's access context before the model drafts.
  • Validate proposed fields in deterministic code before asking a person to approve them.
  • Show the exact arguments and require a human decision before the system-of-record write.
  • Make the approved update idempotent, and audit the confirmed response.
  • Escalate when validation fails or the person rejects the proposal.

Risks & Trade-offs

Ticket text and retrieved articles can carry instructions that try to widen the action. An approval screen that hides fields invites a blind accept. Retrying a write that is not idempotent can duplicate the change. If the business system times out, the outcome is unknown. Human review catches policy exceptions; it does not prove the article is current.

When to Use / Not Use

Use this pattern when support staff need a draft and a constrained update inside a process the organization already owns. Do not use it for unsupervised clinical or hiring decisions, or for any write that policy forbids without a recorded human decision. If the reply is a fixed template and the update is a rules lookup, skip the model.

Sources

Related