How AI Graph Engineering Revamps Customer Service, Approvals, and Content Production

From R&D to Business Process Engineering

The previous installment covered Graph engineering for the R&D pipeline; this article shifts the focus to business‑side workflows that affect the entire company—customer service, approval, and content production.

Goodhart’s Law as a Design Pitfall

When a single metric is pushed aggressively, it stops reflecting the true business goal. An example shows a support team raising ticket‑resolution rate from 70% to 95% while renewal rate drops 20% because the AI “closes” tickets without actually solving them. The remedy is to attach every optimization metric with a counter‑metric and an immutable anchor that AI cannot manipulate.

Optimization metric : the KPI the AI tries to improve (e.g., automatic ticket‑resolution rate).

Counter‑metric : a human‑centric measure that checks the real impact (e.g., user‑satisfaction score).

Anchor : an external, audit‑able reference (e.g., manual random‑sample verification).

Scenario 1 – Customer‑Service Routing

Problem: a mid‑size SaaS company receives ~500 daily inquiries; 70% are repetitive, causing agents to waste time.

Graph design:

Classification node decides the question type (FAQ, billing, technical, complex).

FAQ, billing, and technical nodes retrieve answers or run diagnostics.

Human node handles complex cases.

Reply node generates the final response.

Monitoring node checks Goodhart risk by comparing claimed resolution with confidence and satisfaction.

from typing import TypedDict, Optional
from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI

llm_fast = ChatOpenAI(model="gpt-4o-mini", temperature=0)
llm_good = ChatOpenAI(model="gpt-4o", temperature=0.3)

class CustomerServiceState(TypedDict):
    ticket_id: str
    user_message: str
    user_id: str
    question_type: str  # faq / billing / technical / complex
    confidence: float
    retrieved_answer: Optional[str]
    billing_info: Optional[dict]
    diagnosis_result: Optional[str]
    human_summary: Optional[str]
    final_reply: str
    need_human: bool
    resolution_claimed: bool
    satisfaction_score: Optional[int]
    goodhart_risk: Optional[str]

Monitoring metrics (three‑level loop):

Optimization: automatic processing rate.

Counter: user‑satisfaction rating (1‑5).

Anchor: weekly random audit of 50 tickets to verify true resolution.

If automation rises while satisfaction falls, the system is “shutting down” users; only when all three metrics improve together is the change genuine.

Scenario 2 – Multi‑Level Approval

Problem: a purchase request must pass department manager → finance → CEO, often taking 3‑5 days; many rejections are due to incomplete materials.

Graph design includes:

Pre‑check node that validates description length, amount positivity, attachment presence, and travel‑request specifics.

Route node that selects approval level based on amount.

AI analysis node (gpt‑4o‑mini) that provides risk assessment and suggestions.

Three HITL approval nodes (level 1‑3) that pause for human decisions.

Execute node that creates the purchase order; reject node that records reasons.

Post‑approval routing that waits for all required approvers.

class ApprovalState(TypedDict):
    request_id: str
    applicant_id: str
    request_type: str  # purchase / travel / equipment
    amount: float
    description: str
    attachments: list[str]
    pre_check_passed: bool
    missing_items: list[str]
    approval_level: int  # 1 / 2 / 3
    required_approvers: list[str]
    ai_analysis: str
    approval_records: Annotated[list[dict], operator.add]
    final_status: str  # approved / rejected / pending
    rejection_reason: Optional[str]
    purchase_order: Optional[str]

Real‑world impact on a 200‑person company:

Material‑return rate dropped from 35% to 8%.

Average approval cycle fell from 3.2 days to 1.4 days.

Decision time per approver reduced from 15 minutes to 5 minutes (AI analysis).

Monthly API cost ≈ ¥200.

The speed gain stems mainly from pre‑check eliminating back‑and‑forth and from AI‑generated analysis that removes manual data gathering.

Scenario 3 – Cross‑Platform Content Production

Problem: an operations team must produce articles, short‑form notes, and micro‑posts each week; styles differ and content is duplicated.

Graph design:

Research node gathers background, key data points, and audience concerns.

Core‑content node synthesises a single core message, key selling points, and supporting data.

Platform nodes (WeChat, Xiaohongshu, Weibo) generate drafts in parallel, each respecting platform‑specific constraints.

Brand‑check node validates consistency with brand voice and flags issues.

Revise node loops back for human edits; publish node finalises the approved drafts.

class ContentProductionState(TypedDict):
    topic: str
    target_audience: str
    brand_voice: str
    research_notes: str
    key_data_points: list[str]
    core_message: str
    key_selling_points: list[str]
    platform_drafts: Annotated[list[dict], operator.add]
    brand_check_passed: bool
    brand_issues: list[str]
    revision_count: int
    approved_contents: dict
    publish_schedule: dict

Key insight: generate the core narrative first, then fan‑out to platform‑specific drafts, ensuring brand consistency through the audit node.

Common Design Patterns Across All Scenarios

AI handles efficiency, humans handle judgment. Repetitive or deterministic steps are automated; ambiguous decisions remain HITL.

Supervision loops outweigh optimization loops. Monitoring nodes verify that the metric being maximised still aligns with real business outcomes.

Immutable anchors are mandatory. Without an external reference (manual audit, financial record, user interaction data) the system drifts into metric‑gaming.

Implementation Priority Recommendations

Based on difficulty, expected ROI, and risk, the author suggests the following order:

Customer‑service routing – low implementation effort, high ROI (direct labor reduction).

Multi‑level approval – medium effort, medium ROI (faster cycles, fewer rejections).

Content production – medium effort, medium ROI (higher output, brand‑level quality control).

Takeaways

Goodhart’s Law is the biggest trap; mitigate it with “optimization + counter + anchor”.

Customer‑service graph: classification → conditional routing → monitoring node, with a confidence threshold of 0.6 for human hand‑off.

Approval graph: pre‑check, AI analysis, HITL approval nodes, reducer‑based record accumulation.

Content‑production graph: core‑first, parallel platform fans‑out, brand‑check, revise‑publish loop.

Universal rules: AI for speed, humans for judgment; supervision beats optimization; never omit an immutable anchor.