Agentic workflows with human approval

An agent is a model that plans and then acts through tools: searching, reading records, drafting changes, calling APIs. The value comes from acting, and so does the risk. A production design decides which actions run automatically, which need a person, and how every step is recorded.

The business problem

Operations teams spend hours on repetitive cases such as account changes, refunds, access requests and ticket triage. A prototype agent handles them well in testing, but nobody is willing to let it change real systems without controls, approvals and an audit trail.

Constraints

• Actions on systems of record must be reversible or approved.
• Least-privilege access for every tool the agent can call.
• Regulated decisions may require a named human approver.
• Cost and latency per case must stay below the manual process.

Architecture

TriggerTicket, email, form or event

Agent orchestrator

• Plan · break the case into steps
• Context · retrieve records and policies the caller may see
• Tools · scoped, typed calls through the AI gateway
• Draft · proposed action with evidence and reasoning
• Risk check · policy rules score the action
• Memory · case state kept outside the model

• Low riskExecuted automatically, logged
• Medium riskSent to a human for approval
• High risk or unclearHanded to a person with the draft

Observability

• Traces per case
• Tool calls and errors
• Approval and override rates
• Cost per case
• Time to resolution
• Audit trail

Human in the loopFor medium- and high-risk actions

1. DraftAgent prepares the action and its evidence
2. PolicyRules confirm who must approve
3. ReviewApprover sees sources, reasoning and the exact change
4. DecideApprove, edit or reject
5. ExecuteTool call with the approver recorded
6. LearnOverrides feed evaluation and policy updates

Every action records who or what decided, and why

Key decisions and trade-offs

• Risk tiers, not one rule: classify actions by impact and reversibility; automate the low tier first and widen it as evidence builds.
• Tools as narrow, typed APIs: no general database or shell access; each tool does one thing with its own permission scope.
• State outside the model: case state and plans are stored in the workflow engine, so runs can be resumed, audited and replayed.
• Evaluation before autonomy: replay historical cases and compare outcomes with human decisions before enabling automatic execution.
• Clear ownership: a named business owner for each workflow, approving changes to prompts, tools and policies.