Applied AI Portfolio · Agent 08

AI Decision Approval
Workflow Agent

A working HITL governance engine demonstrating how production AI systems should score confidence, apply policy thresholds, and route decisions to the right outcome — autonomously or via human review.

HITL Governance Confidence Scoring Escalation Logic Audit Trail Cloudflare Worker
3
Governance Tiers
≤800
Max Output Tokens
5
Scoring Factors
1
API Call / Decision

When Should AI Act Alone?

The central unsolved challenge in production AI deployment isn't model capability — it's governance. When should an AI act autonomously? When should it defer? When should it escalate urgently? Most teams either over-automate (introducing risk) or under-automate (eliminating the efficiency case entirely).

This agent demonstrates a principled approach: a confidence-scored, threshold-governed decision engine that classifies every incoming decision into one of three tiers — auto-approve, route to human, or escalate — based on a structured evaluation of risk factors.

The design is directly applicable to refund processing, content moderation, fraud triage, credit decisioning, and any workflow where AI judgment must be bounded by institutional policy.

Three-Tier Threshold Model

Every decision is scored 0.00–1.00 and mapped to a governance outcome based on fixed policy thresholds. Thresholds are not model hyperparameters — they are business policy decisions that belong in governance documentation, not in the prompt.

Confidence Range Outcome What Happens Human Involvement
0.85 – 1.00 Auto-Approve Agent executes decision autonomously. Logged to audit trail. None (unless override invoked)
0.60 – 0.84 Route to Human Case routed to appropriate human reviewer with context and SLA. Required within SLA window
0.00 – 0.59 Escalate Immediate senior review. Potential hold on action pending investigation. Required immediately
Design principle: The agent never sets its own thresholds. Confidence scoring reflects evidence quality; threshold application is a policy layer applied deterministically after scoring. These are two separate concerns and should be treated as such in any production system.

Multi-Factor Confidence Scoring

Each decision is evaluated across four scored factors. The agent weights these factors by their relevance to the specific scenario type — a fraud signal carries different factor weights than a routine refund request.

Factor What It Measures Example High Signal
Policy Alignment How closely the request fits existing policy rules Refund within policy window, valid receipt
Risk Level Financial, legal, or reputational exposure Low-value, precedented, reversible decision
Context Clarity Completeness and consistency of available information Full transaction history, verified identity
Precedent Match How closely the case resembles prior approved decisions Standard pattern, no anomalous signals

The composite confidence score is derived from the weighted combination of these factors. The agent produces a numeric score and explicit reasoning — making the decision auditable and explainable to any stakeholder.

Structured JSON Output + Governance Layer

The core technical pattern is constrained structured output — the model is instructed to return only a JSON object conforming to a defined schema. No prose, no markdown. The governance logic (threshold application, routing, SLA assignment) runs in the UI layer, not inside the model.

System Prompt (≤300 tokens) JSON-constrained output
You are an AI Decision Governance Engine. When given a business decision scenario, 
you MUST respond with valid JSON only — no prose, no markdown.

Output schema:
{
  "confidence": 0.00-1.00,
  "outcome": "AUTO_APPROVE" | "ROUTE_TO_HUMAN" | "ESCALATE",
  "decision_summary": "one sentence",
  "reasoning": "2-3 sentences explaining the score",
  "factors": [
    { "name": "string", "score": 0.0-1.0, "weight": "HIGH"|"MED"|"LOW" },
    ...
  ],
  "route_to": "string or null",
  "sla_hours": number or null,
  "action_required": "string describing what happens next"
}

Rules: confidence ≥0.85 → AUTO_APPROVE. 0.60–0.84 → ROUTE_TO_HUMAN. <0.60 → ESCALATE.
Key architectural decision: Threshold enforcement is implemented in JavaScript, not in the model's reasoning. This means thresholds can be updated via configuration without touching the system prompt — and any override is auditable without re-querying the LLM.

The agent routes through a Cloudflare Worker which handles authentication, rate-limiting, and keeps the Anthropic API key server-side. Multi-turn conversation history is maintained in the client for follow-up queries within a session.

What I Built and Why

01
Human Override Always Available
Every outcome — including auto-approvals — surfaces an override button. HITL governance means humans can always intervene. Auto-approval is a policy default, not a lock-out. Overrides are logged to the audit trail.
02
Audit Trail Built In
Every decision, routing event, and human action is timestamped and logged in-session. In production this feeds a governance database. It demonstrates to stakeholders that the system is accountable, not a black box.
03
Reasoning is Mandatory, Not Optional
The system prompt requires explicit reasoning alongside every confidence score. A score of 0.72 without explanation is useless for a human reviewer. Explained scores enable human calibration over time.
04
SLA Surfaced at Decision Time
When routing to human, the agent specifies an SLA in hours. This is derived contextually (fraud vs. routine refund carry different SLAs) rather than hard-coded — making the system adaptive to decision type.
05
Separation of Concerns
Scoring intelligence lives in the model. Threshold policy lives in application code. Routing rules live in configuration. These layers are kept deliberately separate so each can evolve independently without breaking the others.
06
Pre-built Scenarios as UX
The scenario selector demonstrates the governance model across its full range — auto, route, and escalate — making the agent self-documenting. Reviewers can see the system working across risk tiers without constructing test cases.

Why This Pattern Matters in Production

The AI decision approval pattern is one of the most consequential architectural choices a product team makes when deploying AI in enterprise workflows. Get it wrong and you face one of two failure modes: over-automation (AI acts where it shouldn't, creating liability) or under-automation (humans review everything, eliminating the ROI case).

This agent demonstrates that the right answer is a calibrated middle path — a governance layer that applies policy-driven thresholds to model-generated confidence scores, with a complete HITL layer sitting above it. It's a pattern directly applicable to fraud decisioning, claims processing, content moderation, credit underwriting, and any regulated domain where AI judgment requires institutional accountability.

As an AI product leader who has shipped at Wells Fargo and VF Corporation — environments where every automated decision carries regulatory weight — I built this agent to reflect the governance thinking that production deployments actually require, not a demo that ignores the hard parts.