AI-Agenten: Architektur & Patterns

Von LLM zu Agent | ReAct-Pattern | Function Calling | Production-Ready Design

Technische Fundierung statt Tool-Listen

AI-Agent-Architektur: LLM + Tools + Memory

Der fundamentale Unterschied zwischen Chat-LLM und autonomen Agents

Ein AI-Agent ist mehr als ein LLM (Large Language Model). Die Architektur kombiniert drei Komponenten: Reasoning Engine (LLM), Tool Use, und Memory/State Management.

Architektur-Komponenten

1. Reasoning Engine (LLM)

Funktion: Entscheidungsfindung, Planung, Sprachverständnis

Technisch: Transformer-basiertes LLM (Text-in, Text-out)

Beispiel: User fragt "Wann ist mein nächstes Meeting?" → LLM interpretiert Intent → plant Action (Kalender abfragen)

2. Tool Use / Function Calling

Funktion: Ausführung von Aktionen in der realen Welt

Technisch: LLM generiert Function Calls (JSON), System führt aus

Beispiel: LLM entscheidet "get_calendar_events()" → System führt API-Call aus → gibt Ergebnis an LLM zurück

3. Memory / State

Funktion: Kontext über Turns hinweg, History, Intermediate Results

Technisch: Conversation Buffer, Vector DB für Long-Term Memory

Beispiel: Agent merkt sich "User fragte nach Meetings" → nächster Turn kann sich darauf beziehen

Chat-LLM (nur Reasoning)

Text Generation (Q&A, Summarization, Translation)
KANN NICHT: APIs aufrufen
KANN NICHT: Datenbanken abfragen
KANN NICHT: Externe Systeme triggern

Use Case: Content Creation, Ideation, Analyse

AI-Agent (Reasoning + Tools + Memory)

Alles, was Chat-LLM kann
PLUS: API-Calls (HTTP, GraphQL, RPC)
PLUS: Database Queries (SQL, Vector Search)
PLUS: Workflow Orchestration (Multi-Step Actions)

Use Case: Automation, Customer Support, Data Processing, Task Execution

Key Insight: Agent ist keine neue Model-Architektur

Ein Agent ist kein neues Modell. Es ist ein architekturelles Pattern: LLM + Tool-Calling-Protocol + Execution Environment. Jedes moderne LLM kann als Agent fungieren, wenn es Function Calling unterstützt.

Function Calling: Wie Tool Use funktioniert

OpenAI Function Calling, Anthropic Tool Use, Technical Protocol

Function Calling ist das Protokoll, das LLMs erlaubt, externe Functions/Tools aufzurufen. Technisch: LLM generiert strukturierte Function Calls (JSON), die Orchestration-Engine führt sie aus und gibt Ergebnisse zurück.

Function Calling Protocol (Beispiel)

1. Tool Schema definieren (Developer)

{
  "name": "get_calendar_events",
  "description": "Retrieve upcoming calendar events for a user",
  "parameters": {
    "type": "object",
    "properties": {
      "user_email": {"type": "string", "description": "Email of user"},
      "days_ahead": {"type": "integer", "description": "Number of days to look ahead"}
    },
    "required": ["user_email"]
  }
}

2. LLM generiert Function Call

{
  "function_name": "get_calendar_events",
  "arguments": {
    "user_email": "user@example.com",
    "days_ahead": 7
  }
}

3. Orchestration Engine führt aus

// Engine calls actual function
const result = await getCalendarEvents("user@example.com", 7)
// Returns: [{event: "Client Call", date: "2026-01-05", time: "14:00"}]

4. Result zurück an LLM

// LLM erhält:
{
  "function_result": [{
    "event": "Client Call",
    "date": "2026-01-05",
    "time": "14:00"
  }]
}

5. LLM generiert finale Antwort

"Ihr nächstes Meeting ist am 5. Januar um 14:00 Uhr: Client Call"

Tool-Kategorien

System Tools

• HTTP Request (API Calls)

• Database Query (SQL, NoSQL)

• File Operations (Read, Write)

• Webhook Trigger

Domain Tools

• Calendar Integration

• CRM Access

• Project Management

• Communication (Email, Chat)

Custom Tools

• Internal APIs

• Legacy System Integration

• Custom Business Logic

• Proprietary Data Sources

ReAct Pattern: Reasoning + Acting

Wie Agents iterativ denken und handeln

ReAct (Reasoning + Acting) ist das dominante Pattern für Agent-Architekturen. Der Agent alterniert zwischen Thought (Reasoning über nächsten Schritt) und Action (Tool Use), bis die Task gelöst ist.

ReAct Execution Loop

User Input

"Finde alle offenen Bug-Tickets für Projekt Alpha und erstelle eine Zusammenfassung"

Thought 1

"Ich muss erst die Bug-Tickets aus dem Projekt-Management-System abrufen"

Action 1

get_project_issues(project="Alpha", status="open", type="bug")

Observation 1

[{id: 123, title: "Login fails", priority: "high"}, {id: 124, title: "UI glitch", priority: "medium"}, ...]

Thought 2

"Ich habe 12 offene Bugs. Jetzt muss ich eine strukturierte Zusammenfassung erstellen"

Action 2

generate_summary(issues=..., format="grouped_by_priority")

Final Answer

"Projekt Alpha hat 12 offene Bugs: 3 high-priority (Login fails, ...), 5 medium-priority (...), 4 low-priority (...)"

ReAct vs Chain-of-Thought (CoT)

Chain-of-Thought (CoT)

Pattern: Reasoning only, keine Actions

Use Case: Math, Logic, Multi-step Reasoning ohne Tool Use

"Let's think step by step: First X, then Y, therefore Z"

ReAct (Reasoning + Acting)

Pattern: Thought → Action → Observation iterativ

Use Case: Tool-based Tasks, Information Retrieval, Multi-step Actions

"I need to query DB → Action → Got result → Next step..."

Structured Outputs: Reliability durch Schema-Enforcement

JSON Schema, Pydantic Models, Type-Safe Agent Outputs

Structured Outputs erzwingen, dass LLM-Outputs einem definierten Schema folgen (z.B. JSON Schema). Kritisch für Production-Ready Agents: Kein Text-Parsing, kein Error Handling für malformed Outputs.

Unstructured Output (Problematisch)

"Die E-Mail ist dringend. Absender ist Max Mustermann (max@example.com). Es geht um Projekt Alpha."

Parsing erforderlich (Regex, String Matching)
Format-Varianz → Fehleranfällig
Kein Type-Safety

Structured Output (Zuverlässig)

{
  "urgent": true,
  "sender": {
    "name": "Max Mustermann",
    "email": "max@example.com"
  },
  "project": "Alpha"
}

Kein Parsing nötig → direkt verwertbar
Garantiertes Format → keine Fehler
Type-Safe für Downstream-Prozesse

JSON Schema Definition

{
  "type": "object",
  "properties": {
    "urgent": {
      "type": "boolean",
      "description": "Whether the email is urgent"
    },
    "sender": {
      "type": "object",
      "properties": {
        "name": {"type": "string"},
        "email": {"type": "string", "format": "email"}
      },
      "required": ["name", "email"]
    },
    "project": {
      "type": "string",
      "enum": ["Alpha", "Beta", "Gamma"],
      "description": "Project name if mentioned"
    }
  },
  "required": ["urgent", "sender"]
}

Technisch: LLM-Provider enforcen dieses Schema auf Token-Level (Constrained Decoding). Output ist garantiert valid JSON conform Schema.

Anwendungsfälle für Structured Outputs

Classification Tasks

• E-Mail Triage (urgent/normal, category)

• Lead Scoring (score, quality, confidence)

• Content Moderation (is_safe, categories[])

Extraction Tasks

• Invoice Data (amount, date, vendor, line_items[])

• Resume Parsing (name, skills[], experience[])

• Entity Recognition (persons[], locations[], dates[])

Production-Ready Agent Patterns

Reliability, Error Handling, Observability

Error Handling & Retry

Tool Execution Failure

Problem: API Timeout, Rate Limit, 500 Error

Pattern: Exponential Backoff Retry (2s, 4s, 8s). Nach 3 Retries → Fallback oder Human-in-Loop

LLM Hallucination

Problem: Agent generiert invaliden Function Call

Pattern: Schema Validation vor Execution. Bei Fehler → LLM korrigieren lassen (Self-Correction Loop)

Infinite Loop

Problem: Agent stuck in Thought → Action Loop

Pattern: Max Iterations Limit (z.B. 10). Bei Überschreitung → Abort + Log für Debugging

Human-in-the-Loop (HITL)

Confidence Threshold

Agent gibt Confidence Score. Wenn < Threshold → Human Review

if (confidence < 0.8) { createTicket(human_review_needed) }

Approval Gates

Kritische Actions (z.B. Geld senden) erfordern Human Approval

Agent plant Action → pausiert → Mensch approved → Execution

Audit Trail

Alle Agent-Actions loggen für Compliance & Debugging

Timestamp, User, Action, Input, Output, Latenz, Cost

Observability & Monitoring

Execution Metrics

• Latenz (TTFT, Total Time)

• Tool-Call-Count pro Run

• Success Rate (completed vs failed)

Cost Tracking

• Token Usage (Input + Output)

• Cost per Run ($ / Execution)

• Tool API Costs (wenn charged)

Quality Metrics

• User Feedback (Thumbs Up/Down)

• HITL Intervention Rate

• Retry Rate (Error Recovery)

Cost Control & Optimization

Max Token Limits

Verhindert runaway Agents (endlose Loops kosten $$)

max_tokens_per_run: 10000 // Hard Cap

Model Routing

Einfache Tasks → Cheap Model, Complex Reasoning → Premium Model

Classification → Fast/Cheap, Multi-Step Planning → Slow/Smart

Caching

Repeated Context (System Prompt, Tool Schemas) → Cache

90% Kosten-Ersparnis bei wiederholtem Context (Prompt Caching)

Praxis-Beispiel: Customer Support Agent

End-to-End Architektur mit ReAct Pattern

Ein vollständiger Support-Agent der E-Mails triaged, relevante Daten aus CRM/Knowledge Base holt, und automatisiert antwortet. Strukturiert nach ReAct Pattern.

Trigger: E-Mail Event

• Webhook/IMAP Listener triggered by incoming email

• Extract: sender_email, subject, body

• Initiate Agent Workflow

Thought: Analysis & Planning

"I need to classify this email and retrieve customer context"

• Agent analysiert Intent (Classification)

• Entscheidet: Welche Tools needed? (CRM Lookup, KB Search)

• Plant Multi-Step Execution

Action: Tool Calls (Parallel)

get_customer_by_email(email="customer@example.com")

search_knowledge_base(query="How to reset password")

→ Orchestrator führt parallel aus (Performance-Optimierung)

Observation: Tool Results

Customer Data:

{name: "Max M.", tier: "Premium", last_contact: "2026-01-01"}}

KB Article:

"To reset password, visit /reset-password and enter email..."

Response: Structured Output

{
  "answer": "Hello Max, to reset your password, visit...",
  "category": "account_help",
  "priority": "medium",
  "requires_human": false,
  "confidence": 0.92
}

Execution: Send Email / Create Ticket

• if (requires_human == false) → send_email(answer)

• if (requires_human == true) → create_support_ticket()

• Log für Analytics: category, latenz, cost, confidence

Key Takeaways

Agent = LLM + Tools + Memory. Keine neue Model-Architektur, sondern ein orchestriertes System aus Reasoning, Tool Use und State Management.

ReAct ist das dominante Pattern. Thought → Action → Observation iterativ, bis Task gelöst. Alternativ: Plan-and-Execute für komplexere Tasks.

Structured Outputs sind kritisch. JSON Schema Enforcement verhindert Parsing-Fehler und macht Agents production-ready.

Reliability durch Patterns. Error Handling (Retry, Fallback), Human-in-Loop (Confidence Thresholds), Observability (Metrics, Logging).

Cost Control ist essentiell. Max Token Limits, Model Routing, Prompt Caching – sonst werden Agents schnell teuer.

Bereit für Production-Ready AI-Agents?

Wir helfen Ihnen, zuverlässige AI-Agents zu designen und zu implementieren – von Architektur-Design bis Deployment und Monitoring.

Kostenlose Agent-Beratung Agent-Lösungen ansehen