Enterprise LLM Architecture: Customer Support Orchestration

Das Problem: 3% Failure Rate trotz CRITICAL POLICY

Du baust einen AI-Support-Agent. Er soll Refunds unter $500 automatisch verarbeiten. Fuer alles darueber: Human Escalation.

Du schreibst ins System Prompt: "CRITICAL POLICY: NEVER process refunds exceeding $500." Alles Capslock, Fettung, Emphasis.

Die Realitaet: Bei 1.000 Refund-Requests verarbeitet dein Agent 30 mal Betraege ueber $500. 3% Failure Rate. Bei $847 pro Fehler: $25k Problem pro Monat.

Prompts sind keine Guardrails. Prompts sind Suggestions.

Pattern 1: Zero-Tolerance Compliance via Application-Layer Intercepts

Das Anti-Pattern: Prompt-basierte Policy Enforcement

Das Problem: LLMs sind probabilistisch. 'NEVER' bedeutet 'almost never'. Bei genug Requests passiert es trotzdem.

Das Pattern: Application-Layer Intercepts

Der Agent kann noch immer versuchen, process_refund($847) aufzurufen. Aber der Call erreicht nie das Refund-System. Der Intercept blockt deterministisch – 100% der Zeit, 0% Exceptions.

Implementierung:
class RefundInterceptor:
THRESHOLD = 500.00

def intercept(self, tool_call):
amount = tool_call['parameters']['amount']
if amount > self.THRESHOLD:
return {'action': 'escalate', 'reason': f'Amount ${amount} exceeds threshold'}
return tool_call # Allow execution

Model discretion is removed. Das ist der Punkt.

Pattern 2: Graceful Tool Failure

Das Anti-Pattern

Crashing Exceptions: Agent crashed beim API-Fehler.
Empty Strings: Agent halluziniert was '' bedeutet.

Das Pattern: Structured Error Responses

Jedes Tool gibt strukturierte Fehler zurueck:
{"isError": true, "errorCategory": "transient", "isRetryable": true}

Agent Response bei Error:
"Ich erlebe gerade eine Verzoegerung bei der Bestellabfrage. Bitte versuche es in ein paar Minuten nochmal, oder ich verbinde dich mit einem Spezialisten."

Der Effekt: Der Agent crashed nicht, halluziniert nicht, sondern kommuniziert transparent.

Pattern 3: The Escalation Handoff

Die zwei Trigger-Typen

Regel 1: 'I want a human NOW' = sofortige Eskalation. Keine Rueckfragen, keine Verzoegerung.

Regel 2: Bei komplexen Policy-Faellen erst Account-Kontext sammeln, dann eskalieren.

The Payload: Structured Summary

Anti-Pattern: Raw transcript dump (50+ turns, unstructured)

Korrekt: Strukturierte Summary:
customer_id: "CUST-847392"
root_cause: "Duplicate charges due to gateway timeout."
amount: "847.00 USD"
recommended_action: "Approve refund for 847.00 USD and notify customer."

Warum: Der Human Reviewer braucht 10 Sekunden um zu entscheiden, nicht 10 Minuten um 50 Turns zu lesen.

Pattern 4: Resuming Asynchronous Sessions

Das Problem: Stale Data nach Session-Pause

Das Modell sieht den alten tool_result im Kontext (Status PENDING) und gibt ihn selbstbewusst wieder – obwohl sich der Status laengst zu PROCESSED geaendert hat.

Die Loesung: Programmatic Filtering of tool_results

Beim Session-Resume: Alle tool_result-Nachrichten aus der History filtern.

def prepare_session_resumption(conversation_history):
return [turn for turn in conversation_history
if turn['role'] != 'tool_result']

Der Agent hat die Konversationshistorie (Kontext), aber keine veralteten Daten. Er muss aktiv neu abfragen → bekommt aktuelle Information.

Pattern 5: Tool Context Pruning

Problem: Typische API-Response hat 40+ Felder. Du rufst lookup_order 5x in einer Session auf. Das Context Window fuellt sich mit irrelevanten Daten.

Loesung: Application-Side Filtering vor der Rueckgabe an den Agent:

def prune_order_context(raw_response):
return {
'items': raw_response.get('items', []),
'purchase_date': raw_response.get('purchase_date'),
'return_window': raw_response.get('return_window'),
'status': raw_response.get('status')
}

40+ Felder → 4 Felder. Weniger Tokens, weniger Ablenkung, bessere Fokussierung.

Pattern 6: Compressing Long Sessions

Problem: 48-Turn-Sessions sprengen Context Limits.

Loesung: Narrative Summary fuer Resolved Issues + Verbatim fuer Active Issue.

Turn 1-15 (Refund, resolved) + Turn 16-32 (Subscription, resolved)
→ Zusammengefasst als Narrative Summary

Turn 33-48 (Payment Update, active)
→ Vollstaendig verbatim im Context

Der Agent kennt die History (Summary), bearbeitet das aktive Problem im Detail (Verbatim), Context Window bleibt manageable.

Takeaways fuer deinen Support-Agent

1. Prompts sind keine Guardrails. Application-Layer Intercepts blockieren deterministisch. CRITICAL POLICY im Prompt hat 3% Failure Rate.

2. Structured Errors, keine Exceptions. isError: true gibt dem Agent Handlungsspielraum.

3. 'I want a human NOW' = sofortige Eskalation. Keine Rueckfragen.

4. Escalation Payloads sind Summaries, keine Transcripts.

5. Session Resumption = Filter old tool_results. Alte Daten sind falsche Daten.

6. Long Sessions komprimieren: Narrative Summary fuer Resolved, Verbatim fuer Active.

Naechster Artikel: Developer Productivity – Scratchpad Pattern, Directed Codebase Exploration und Context Decay.