Mehr als Chatbots: deterministische, schema-validierte KI-Agenten

Ein produktiver KI-Agent ist kein Chatbot mit angeschraubten Tools. Ein Chatbot antwortet; ein Agent handelt — und Handeln gegen reale ERP-, CRM- und Zahlungssysteme verlangt dieselbe Vorhersagbarkeit, die Sie von jeder anderen Backend-Software erwarten würden.

Die kurze Antwort: Standard-Chatbot-Piloten scheitern, weil Prompt Engineering allein keine deterministischen Pfade garantieren kann. Ohne eine harte State Machine und strukturierte Input-/Output-Validierung wird ein konversationelles LLM bei jedem Workflow mit mehr als ein paar Abhängigkeiten irgendwann halluzinieren, den Ausführungskontext verlieren oder in eine endlose Tool-Calling-Schleife geraten. Die Lösung ist kein besserer Prompt — sie besteht darin, die Ausführung mit LangGraph-State-Machines einzuschränken und den Tool-Zugriff über das Model Context Protocol (MCP) zu standardisieren.

Warum erreichen konversationelle KI-Piloten nicht die Produktion?

Beim Aufbau von KI für mittelständische Unternehmen im DACH-Raum ist Konsistenz nicht verhandelbar. Wenn ein Agent eine Kundenbestellung anpasst oder ERP-Bestände abruft, kann er nicht auf einer „Best-Effort“-Konversationsbasis arbeiten. Das ist dieselbe Wand, an der die meisten Piloten kurz vor der Produktion scheitern — über die operative Seite davon haben wir in Warum KI-Piloten vor der Produktion scheitern geschrieben.

Traditionelle Single-Prompt-Agenten nutzen eine Schleife aus Thought → Action → Observation (das ReAct-Framework). Für einfaches Q&A ist das in Ordnung, doch es zerfällt schnell, sobald mehrere API-Abhängigkeiten existieren: Strukturell hindert nichts das Modell daran, zu schleifen, einen Schritt zu überspringen oder einen Tool-Call zu fabrizieren. Um Agenten zuverlässig zu machen, behandeln wir ihre Ausführung als endlichen Automaten — Übergänge zwischen Knoten werden von Code gesteuert, nicht von Prompt-Anweisungen.

Die deterministische Agenten-Architektur auf AWS

Für niedrige Latenz und skalierbare Infrastruktur hosten wir Agenten auf AWS Serverless — AWS Lambda für die Ausführung, Amazon DynamoDB für die State-Persistenz — und entkoppeln die Tool-Ausführung hinter dem Open-Source Model Context Protocol.

Als State-Chart organisiert, entspricht jeder LLM-Aufruf einem bestimmten Knoten im Graphen. Die Kanten zwischen den Knoten bestimmen anhand der strukturierten State-Daten, was als Nächstes geschieht, statt das Modell seine nächste Aktion dynamisch erfinden zu lassen.

Den State-Chart mit LangGraph aufbauen

Hier ist ein state-validierter Supervisor-Knoten in Python. Das Muster garantiert, dass der Agent nur dann in den nächsten State übergehen kann, wenn der aktuelle State die Schema-Validierung besteht.

Definieren Sie zunächst den gemeinsamen State mit Pydantic:

from typing import TypedDict, Annotated, Sequence, Literal
from pydantic import BaseModel, Field
from langchain_core.messages import BaseMessage

# Tool-Anforderungen auf Schema-Ebene
class TransactionVerification(BaseModel):
    transaction_id: str = Field(description="Must match exact format TXN-XXXXXX")
    requires_refund: bool = Field(default=False)
    audit_notes: str

# State des Ausführungsgraphen
class AgentState(TypedDict):
    messages: Annotated[Sequence[BaseMessage], "append"]
    verification_payload: TransactionVerification
    next_step: Literal["verify_payment", "escalate_support", "end"]

Definieren Sie dann den Validierungs-Knoten und verdrahten Sie das Routing:

from langgraph.graph import StateGraph, END

def supervisor_node(state: AgentState) -> dict:
    """Evaluate the request and pick the path from validated schema."""
    last_message = state["messages"][-1].content

    # Structured output binds the model to the Pydantic schema, so it
    # must return parseable state instead of conversational filler.
    try:
        structured_output = llm.with_structured_output(
            TransactionVerification
        ).invoke(last_message)

        return {
            "verification_payload": structured_output,
            "next_step": "verify_payment" if structured_output.requires_refund else "end",
        }
    except Exception:
        # Schema parsing failed — fall back to a safe human escalation path.
        return {"next_step": "escalate_support"}

def route_to_node(state: AgentState) -> str:
    return state["next_step"]

workflow = StateGraph(AgentState)
workflow.add_node("supervisor", supervisor_node)
# Add other operational nodes here...

workflow.set_entry_point("supervisor")
workflow.add_conditional_edges(
    "supervisor",
    route_to_node,
    {
        "verify_payment": "payment_execution_node",
        "escalate_support": "escalation_node",
        "end": END,
    },
)

app = workflow.compile()

Die Integration mit MCP standardisieren

Damit Agenten nicht eng an bestimmte Datenbank-Schemas oder API-Integrationen gekoppelt sind, nutzen wir das Model Context Protocol. MCP ist eine universelle Brücke, die den Agenten-Kern (das Gehirn) von den externen Diensten (den Händen) trennt. Statt individuellem Integrationscode pro Tool verbindet sich der Agent mit MCP-Servern, die Tools mit einem deklarierten Input-Schema bereitstellen:

{
  "name": "fetch_erp_inventory",
  "description": "Pulls current physical stock counts from the SAP ERP system",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sku": {
        "type": "string",
        "pattern": "^SKU-[0-9]{4}$"
      }
    },
    "required": ["sku"]
  }
}

Durch die Entkopplung dieser Schritte muss die Agenten-Schicht auf AWS Lambda die inneren Abläufe Ihres SAP oder CRM nicht kennen — sie verarbeitet nur die standardisierten JSON-Payloads, die der MCP-Tool-Vertrag definiert. Tauschen Sie das dahinterliegende System aus, behalten Sie den Vertrag bei, und der Agent bleibt unverändert.

Deployment und Kostenkontrolle auf AWS Serverless

Um Cold Starts zu minimieren und die Kosten zu optimieren, konfigurieren wir den Agenten auf AWS Lambda entlang dreier Achsen:

1. 01

   Provisioned Concurrency

   Halten Sie 1–2 Ausführungsinstanzen für latenzkritische, nutzerseitige Pfade warm, damit interaktive Sessions nie einen Cold Start abbekommen. Lassen Sie Hintergrundpfade on-demand, um günstig zu bleiben.

2. 02

   State-Persistenz in DynamoDB

   Persistieren Sie Konversations-State und Session-Memory in DynamoDB, statt teuren In-Memory-State vorzuhalten. Langlebiges Memory wird zu einem günstigen Key-Lookup, und jede Lambda-Instanz kann eine Session fortsetzen.

3. 03

   Schema-Validierung am Edge

   Weisen Sie fehlerhaftes JSON am AWS API Gateway ab, bevor es eine Lambda aufruft. Ungültige Requests verbrauchen nie nachgelagerte Compute-Leistung oder Modell-Tokens — der günstigste Request ist der, den Sie nie ausführen.

Zuverlässige Agenten-Plattformen entwickeln

Mit dem deterministischen Routing von LangGraph und den strukturierten Tools von MCP gehen Sie über fragile Proof-of-Concept-Chatbots hinaus zu Agenten, die vorhersagbar, sicher und wartbar sind — Operationen, die Sie einem Kunden oder einer ERP-Write-API vorsetzen können, ohne die Luft anzuhalten.

Wir konzipieren und liefern maßgeschneiderte, produktionsreife KI-Agenten-Systeme in unter 90 Tagen — mit EU-AI-Act-Konformität, die von Tag eins an eingebaut ist, statt vor dem Launch nachträglich angeschraubt zu werden.