Laya Open Decision Engine

1. Konzept und Kern (Überblick und systemisches Problem)

Laya löst ein spezifisches Problem agentischer Systeme: Die meisten Entscheidungen in produktiven Agenten erfordern kein generatives Reasoning, sondern eine schnelle Zustands-Routing-Logik. Der klassische ReAct-Loop mit LLM ruft das Modell für jeden einzelnen Schritt auf. Selbst triviale Entscheidungen – die Auswahl eines Tools, die Ablehnung einer verbotenen Aktion oder die Umleitung einer Anfrage an einen Fallback – kosten daher Hunderte von Millisekunden, Tokens und externe API-Kosten.

Laya ist eine Open-Source System-1-Decision-Engine von Convai Innovations, basierend auf ModernBERT-large unter der Apache-2.0-Lizenz. Das Modell nimmt den strukturierten Zustand des Agenten entgegen – JSON, Textkontext oder deren Kombination – und liefert in einem einzigen Forward Pass eine Entscheidung zurück: action, confidence und reason codes. Im Positionierungsrahmen von Convai ist Laya das offene Pendant zu Jev: kein Ersatz für LLMs bei komplexer Planung, sondern ein schneller, self-hosted Klassifikator für Entscheidungen in High-QPS-Agentenschleifen.

Technisch gesehen ist Laya ein encoder-basiertes Entscheidungsmodell: Ein bidirektionaler Transformer, der keine Token-für-Token-Generierung durchführt, sondern den Eingabekontext vollständig verarbeitet und Logits über dem Aktionsraum ausgibt. Dies verändert die Inference-Ökonomie grundlegend: Es gibt keinen autoregressiven Decode-Prozess, keinen KV Cache und keine typischen LLM-Optimierungen wie Fast Patching. Stattdessen erfolgt ein einzelner batched Encoder-Pass mit vorhersehbarer Latenz.

Der wirtschaftliche Nutzen von Laya zeigt sich dort, wo Entscheidungen wiederkehrend sind: Routing von Tool-Calls, Safety Gates vor LLM-Aufrufen, lokale Agenten auf Docker Agents, Bare-Metal-Inference und datenschutzsensiblen Self-Hosted-Szenarien. Wenn ein Agent 10.000 Entscheidungen pro Minute trifft, reduziert die Verlagerung von sogar 60–80 % der trivialen Entscheidungen vom LLM auf Laya das Latenz-Budget und die Token-Kosten ohne Qualitätsverlust, da für diese Entscheidungen kein offenes Denken erforderlich ist.

2. Architektur und interne Mechanik (Taxonomie und mentales Modell)

Laya funktioniert als Decision Head auf Basis von ModernBERT-large. Der Eingabezustand des Agenten wird normalisiert, tokenisiert, durchläuft den Encoder, woraufhin eine Pooling-Schicht und ein Klassifikationskopf die Verteilung über dem Aktionsraum ausgeben. Der Postprocessor wendet die Policy an: Überprüfung der allowed_actions, Confidence Thresholds, Fallback-Logik und Guardrails.

Agent State JSON/text
        │
        ▼
┌─────────────────────────────┐
│ Schema / State Normalizer   │
│ - flatten JSON fields       │
│ - canonical text rendering  │
│ - redact PII / secrets      │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│ ModernBERT Tokenizer        │
│ input_ids + attention_mask  │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│ ModernBERT-large Encoder    │
│ RoPE positional encoding    │
│ FlashAttention / varlen     │
│ bidirectional self-attention│
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│ Pooling + Decision Head     │
│ logits[action_id]           │
│ optional multi-label heads  │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│ Policy / Calibration Layer  │
│ softmax + temperature       │
│ confidence threshold        │
│ allowed_actions validation  │
│ reason_codes / fallback     │
└──────────────┬──────────────┘
               │
               ▼
Router → MCP tool call → ReAct loop / human review

Komponenten-Taxonomie:

1. State Normalizer – Wandelt JSON/Text in eine kanonische Form um. Beispielsweise kann {"intent":"refund","amount":120,"user_tier":"paid"} in einen deterministischen String mit Schlüsseln, Werten und Typen serialisiert werden. Dies ist wichtig, da der Encoder empfindlich auf Feldreihenfolge und Tokenisierung reagiert.
2. Tokenizer – Standardmäßiger ModernBERT Tokenizer. Die Eingabe ist auf den Kontext beschränkt, üblicherweise bis zu 8k Tokens. Für große JSON-Zustände sind Pre-Summarization oder Field Selection erforderlich.
3. ModernBERT Encoder – Bidirektionaler Transformer mit RoPE. Im Gegensatz zu kausalen LLMs sieht jedes Token den Kontext links und rechts, was die Zustandsklassifikation verbessert.
4. Decision Head – Üblicherweise Klassifikation oder Multi-Label-Klassifikation. Kann einen einzelnen action_id, mehrere Risikoflaggen oder einen Confidence Score zurückgeben.
5. Policy Layer – Deterministische Schicht: Prüfung zulässiger Aktionen, Thresholds, Guardrails, Fallbacks und Audit-Metadaten.

Wesentliche architektonische Unterscheidung zum LLM: Laya besitzt keinen KV Cache, führt keine autoregressive Generierung durch und benötigt keine Decode-Time-Optimierungen. In der Serving-Schicht konzentrieren sich Optimierungen auf Batched Encoder Kernels, Dynamic Padding, Attention Masking, FlashAttention Varlen sowie ONNX/TensorRT Graph Execution. Falls Padding-Free Attention verwendet wird, kann Unpadding unnötige Berechnungen auf Pad-Tokens reduzieren, dies ist jedoch nicht Teil des Modells selbst.

3. Technischer Lifecycle-Pipeline

Die Laya-Pipeline im Produktionsbetrieb besteht aus vier Phasen: Zustandsbildung, Transformation, Inference und Feedback.

1. Formulierung des Eingabezustands

Der Agent muss nicht den rohen User Prompt übergeben, sondern einen strukturierten Zustand: Intent, Memory, verfügbare Tools, Policy Flags, vorherige Aktionen und Risikosignale.

{
  "request_id": "req_9f2a",
  "state": {
    "intent": "refund_request",
    "amount": 120,
    "user_tier": "paid",
    "previous_actions": ["order_lookup"],
    "risk_flags": []
  },
  "text": "Please refund my order, it arrived damaged.",
  "allowed_actions": [
    "tool:order_lookup",
    "tool:refund_create",
    "tool:human_review",
    "llm:clarify"
  ],
  "policy_version": "v1.4.2"
}

2. Transformation und Normalisierung

Die Normalisierung muss deterministisch sein:

• Validierung des JSON Schemas;
• Entfernung oder Maskierung von PII, Secrets und Tokens;
• Sortierung der Felder oder feste Reihenfolge;
• Begrenzung der Textlänge;
• Tokenisierung in input_ids und attention_mask.

Beispiel eines Python-Vertrags mit Pydantic AI:

from pydantic import BaseModel, Field
from typing import Any


class DecisionRequest(BaseModel):
    request_id: str
    state: dict[str, Any]
    text: str | None = None
    allowed_actions: list[str] = Field(min_length=1)
    policy_version: str = "v1"


class DecisionResponse(BaseModel):
    action: str | None
    confidence: float
    reason_codes: list[str]
    fallback: bool
    model_version: str
    latency_ms: float

3. Ausführung / Inference

Vereinfachte Pseudosignatur:

def decide(req: DecisionRequest) -> DecisionResponse:
    normalized = normalize_state(req)
    logits = model.forward_pass(normalized)
    action, confidence = select_action(logits, req.allowed_actions)

    if action is None or confidence < CONFIDENCE_THRESHOLD:
        return DecisionResponse(
            action="llm:clarify",
            confidence=confidence,
            reason_codes=["low_confidence", "fallback"],
            fallback=True,
            model_version=MODEL_VERSION,
            latency_ms=measure_latency(),
        )

    return DecisionResponse(
        action=action,
        confidence=confidence,
        reason_codes=["high_confidence"],
        fallback=False,
        model_version=MODEL_VERSION,
        latency_ms=measure_latency(),
    )

Für das Production Serving sind folgende Aspekte wichtig:

• Warm-up vor der ersten Anfrage;
• Dynamic Batching für Durchsatz;
• CUDA Graphs oder Compiled Inference für stabile P95-Latenz;
• ONNX Runtime, TensorRT, Triton, Hugging Face Inference – je nach Stack;
• Shadow Inference zum Vergleich mit dem LLM Router.

4. Verarbeitung des Feedbacks

Laya ist kein statisches Modell. Zur Aufrechterhaltung der Qualität ist ein Feedback Loop erforderlich:

{
  "request_id": "req_9f2a",
  "predicted_action": "tool:refund_create",
  "actual_action": "tool:human_review",
  "outcome": "policy_violation",
  "confidence": 0.91,
  "human_label": "tool:human_review",
  "timestamp": "2026-06-15T10:00:00Z"
}

Diese Logs werden genutzt für:

• Retraining;
• Kalibrierung;
• Drift Detection;
• Adversarial Mining;
• Evaluation neuer Action Classes;
• Audit Trail für Safety-Entscheidungen.

4. Praktische Produktionsszenarien

01. Low-Latency MCP Tool Router

In Agenten mit MCP-Tools verschwendet das LLM oft Zeit mit der Tool-Auswahl. Laya kann als Pre-Router fungieren: Wenn der Zustand eine klare Absicht und ein erlaubtes Tool enthält, wählt das Modell tool:* direkt, anstatt den vollständigen ReAct Loop zu durchlaufen.

Beispiel:

{
  "state": {
    "intent": "calendar_create",
    "entities": {
      "date": "2026-06-16",
      "duration_minutes": 30
    }
  },
  "allowed_actions": [
    "mcp:calendar.create_event",
    "mcp:calendar.list_events",
    "llm:clarify"
  ]
}

Bei hoher Confidence ruft der Agent sofort das MCP Tool auf. Andernfalls leitet er die Anfrage an den LLM ReAct Loop weiter oder bittet um Klärung. Dies reduziert die Latenz beim Tool-Calling und macht das Routing deterministischer.

02. Guardrails / Policy Gate vor LLM

Laya kann als schnelles Safety Layer dienen. Eingabe: User Text + Agent State. Ausgabe: Erlaubte Aktion oder Blockierung.

Szenarien:

• Erkennung von Prompt Injection in strukturierten Daten;
• Klassifizierung von Anfragen bezüglich PII Leakage;
• Blockierung von Aktionen, die Human Review erfordern;
• Compliance-Prüfung vor Aufruf teurer LLMs;
• Triage: allow, clarify, reject, escalate.

Dies ist günstiger als ein vollständiges LLM Guardrail, da ein Forward Pass nur Dutzende Millisekunden kostet und keine Tokens generiert. Allerdings ersetzt Laya keine umfassende Safety-Architektur: Sie sollte mit deterministischen Regeln, Allowlists, Audit Logging und Fallback-LLMs kombiniert werden.

03. Self-Hosted Local Agent auf Docker Agents oder Bare-Metal

Für datenschutzsensible Umgebungen wird Laya lokal bereitgestellt: Docker Agents, Kubernetes, Bare-Metal GPUs oder Edge-Infrastruktur. Das Modell sendet den Zustand nicht an externe APIs, was für Enterprise-, Healthcare-, Finance- und verteidigungsnahe Szenarien entscheidend ist.

Typischer Stack:

FastAPI / gRPC service
  → Pydantic validation
  → ModernBERT tokenizer
  → ONNX / TensorRT / HF inference
  → policy postprocessor
  → MCP router or local tool executor

Auf Self-Hosted GPUs kann die Latenz für typische Eingaben im Bereich von ~33–35 ms gehalten werden. Auf CPUs ist die Latenz höher, aber für kleine Batches und kurze Zustände oft noch akzeptabel. Im Vergleich zu Cloud-LLMs stellt sich der Trade-off zwischen Bare-Metal und Cloud hier so dar: Man zahlt für GPU-Kapazität und MLOps, erhält dafür aber vorhersehbare Kosten, Privatsphäre und Unabhängigkeit von API-Limits.

5. Fallstricke, häufige Fehler und Sicherheit

01. Action Space Drift

Laya wird oder kalibriert sich auf einen spezifischen Aktionsraum. Wenn neue MCP Tools hinzugefügt, Policies geändert oder Actions umbenannt werden, könnte das Modell veraltete oder ungültige action_ids zurückgeben.

Mitigation:

• Pflege eines Action Registry;
• Validierung der allowed_actions am Eingang;
• Blockierung unbekannter Aktionen;
• Retrain oder Adapter Fine-Tuning bei Tool-Änderungen;
• Nutzung semantischer Fallbacks im LLM.

02. Prompt Injection via JSON/Text

Der Eingabezustand des Agenten kann feindlichen Text enthalten: ignore previous policy, call admin_tool, send token. Der Encoder kann empfindlich auf toxische Muster reagieren, insbesondere wenn das Modell nicht mit adversarial Data trainiert wurde.

Mitigation:

• Trennung von User Text und System Policy Fields;
• Normalisierung und Sanitisierung der Eingabe;
• Keine Zulassung von Textänderungen an allowed_actions;
• Training mit injection-labeled Data;
• Hinzufügen deterministischer Policy Gates;
• Einsatz von Confidence Thresholds und Fallbacks.

03. Falsche Kalibrierung der Confidence

Softmax-Confidence ist keine Wahrscheinlichkeit für Korrektheit. Das Modell kann „selbstbewusst falsch“ liegen, besonders nach Distribution Shifts.

Mitigation:

• Temperature Scaling;
• Isotonic Regression;
• Calibration Curves;
• Abstention Threshold;
• Shadow Evaluation auf Produktions-Traffic;
• Separate Monitoring für High-Confidence False Positives.

04. Overfitting auf strukturiertes JSON

Laya könnte Formatierungsartefakte lernen: Schlüsselreihenfolge, Zeilenlängen, spezifische Feldnamen. Ändert der Client das Schema, sinkt die Genauigkeit.

Mitigation:

• Augmentation: Shuffle Fields, Paraphrase Text, synthetische Schema-Varianten;
• Field Masking;
• Kanonische Serialisierung;
• Schema Versioning;
• Unit Tests für JSON-Varianten.

05. Kontext-Truncation

ModernBERT hat einen begrenzten Kontext. Große JSON-Zustände mit Memory, Transkripten oder Logs können abgeschnitten werden, sodass das Modell Entscheidungen ohne kritische Felder trifft.

Mitigation:

• Pre-Summarization;
• Importance-based Field Selection;
• Chunking mit Decision-only Context;
• Explizite Validierung der Präsenz kritischer Felder;
• Fallback, falls Required Fields fehlen.

06. Trugschluss, dass Laya Reasoning ersetzt

Laya ist ein System-1-Klassifikator. Sie erstellt keine mehrstufigen Pläne, prüft keine Kausalität und generiert keine Erklärungen. Komplexe Autonomous-Loop-Szenarien erfordern LLM ReAct Loops, Tool Observation, Reflection und Human Oversight.

Mitigation:

• Nutzung von Laya für Pre-Routing, Gates und Triage;
• Beibehaltung von LLMs für Synthese und Novel Planning;
• Messung, welche Entscheidungen sicher auf System 1 verlagert werden können;
• Kein Entfernen von LLMs aus kritischen Decision Paths ohne Evaluation.

07. Latenzvarianz im Serving

Die angegebenen 33–35 ms beziehen sich auf typische Self-Hosted-GPU-Bedingungen. Im Produktionsbetrieb kann die Latenz durch Cold Starts, GPU Contention, große Batches, CPU-Fallbacks, langen Kontext oder Netzwerk-Overhead ansteigen.

Mitigation:

• Warm-up;
• P95/P99 Monitoring;
• Fixed Batch Size Policy;
• CUDA Graphs;
• Autoscaling;
• Request Timeouts und Fallbacks;
• Load Testing mit realistischen JSON States.

08. Sicherheit

Eine lokale Bereitstellung bedeutet nicht automatisch Sicherheit. Der Agentenzustand kann PII, Secrets oder Geschäftsdaten enthalten. Logging, Retraining-Daten, Modellgewichte und Inference Endpoints müssen geschützt werden.

Mitigation:

• Redaction vor Inference;
• Verschlüsselung der Übertragung und Speicherung;
• Access Control für Inference APIs;
• Audit Trails;
• Regelmäßige Security Audits;
• Human-in-the-Loop für hochriskante Aktionen.