Laya: Motor de decisión abierto

1. Visión general del concepto y problema sistémico

Laya resuelve un problema concreto de los Agentic Workflow: la mayoría de decisiones en un agente de producción no requieren generative reasoning, sino routing rápido del estado. Un ReAct loop clásico con LLM invoca el modelo en cada paso, por lo que incluso una decisión trivial —seleccionar una herramienta, rechazar una acción prohibida o derivar una petición a un fallback— cuesta cientos de milisegundos, tokens y gasto externo de API.

Laya es un decision encoder open-source de Convai Innovations, construido sobre ModernBERT-large bajo licencia Apache 2.0. La modelo recibe un estado estructurado del agente —JSON, texto o una combinación— y en un solo Forward Pass devuelve una decisión: action, confidence y reason codes. En el posicionamiento de Convai, es un análogo abierto de Jev: no un sustituto de LLM para planificación compleja, sino un clasificador de decisiones rápido, self-hosted y calibrado para bucles high-QPS de Tool Calling, Guardrails y local agents.

Técnicamente, Laya es un encoder-based decision model: un Transformer bidireccional que no genera token por token, procesa el contexto completo y devuelve logits sobre el action space. Esto cambia la economía de inference: no hay autoregressive decode, no hay KV Cache, no depende de Prompt Caching ni de optimizaciones típicas de LLM como Fast Patching; en su lugar hay un batched encoder pass con latencia predecible. Tampoco se apoya en In-Context Learning, Zero-Shot o Few-Shot prompting para resolver la tarea: necesita un action space entrenado y calibrado.

El efecto económico de Laya aparece donde las decisiones son repetibles: routing de Tool Calling, safety gate antes del LLM, agente local en Docker agents, bare-metal inference y escenarios privacy-sensitive self-hosted. Si un agente toma 10 000 decisiones por minuto, mover incluso el 60–80 % de las decisiones triviales del LLM a Laya reduce el latency budget y el coste de tokens sin pérdida de calidad, porque para esas decisiones no se requiere open thinking.

2. Taxonomía arquitectónica y modelo mental

Laya funciona como una decision head sobre ModernBERT-large. El estado del agente se normaliza, se tokeniza, pasa por el encoder, y una capa de pooling más una cabeza de clasificación devuelven una distribución sobre el action space. Un postprocessor aplica policy: allowed_actions, confidence threshold, fallback logic y Guardrails.

Estado del agente JSON/text
        │
        ▼
┌─────────────────────────────────┐
│ Normalizador de estado/schema   │
│ - flatten campos JSON           │
│ - renderizado canónico          │
│ - redactar PII / secrets        │
└────────────────┬────────────────┘
                 │
                 ▼
┌─────────────────────────────────┐
│ Tokenizer ModernBERT            │
│ input_ids + attention_mask      │
└────────────────┬────────────────┘
                 │
                 ▼
┌─────────────────────────────────┐
│ Encoder ModernBERT-large        │
│ RoPE positional encoding        │
│ FlashAttention / varlen         │
│ self-attention bidireccional    │
└────────────────┬────────────────┘
                 │
                 ▼
┌─────────────────────────────────┐
│ Pooling + Decision Head         │
│ logits[action_id]               │
│ cabezales multi-label opcionales│
└────────────────┬────────────────┘
                 │
                 ▼
┌─────────────────────────────────┐
│ Capa de policy / calibration    │
│ softmax + temperature           │
│ confidence threshold            │
│ validación allowed_actions      │
│ reason_codes / fallback         │
└────────────────┬────────────────┘
                 │
                 ▼
Router → MCP tool call → ReAct loop / revisión humana

Aunque el encoder produce representaciones internas, el contrato de salida no expone Vector Embeddings como artefacto principal; expone logits, action_id y confidence.

Taxonomía de componentes:

1. State Normalizer — transforma JSON/text en una forma canónica. Por ejemplo, {"intent":"refund","amount":120,"user_tier":"paid"} puede serializarse en un string determinista con claves, valores y tipos. Esto es crítico porque el encoder es sensible al orden de campos y a la tokenización.
2. Tokenizer — tokenizer estándar de ModernBERT. La entrada está limitada por contexto, normalmente hasta 8k tokens. Para estados JSON grandes se requiere pre-summarization o field selection.
3. ModernBERT Encoder — Transformer bidireccional con RoPE. A diferencia de un LLM causal, cada token ve contexto a la izquierda y a la derecha, lo que mejora la clasificación de estado.
4. Decision Head — clasificación o multi-label classification. Puede devolver un action_id, varias flags de riesgo o un confidence score.
5. Policy Layer — capa determinista: validación de acciones permitidas, threshold, Guardrails, fallback y audit metadata.

La diferencia arquitectónica clave frente a un LLM es que Laya no tiene KV Cache, no ejecuta autoregressive generation y no requiere decode-time optimization. En el serving layer, las optimizaciones se centran en batched encoder kernels, dynamic padding, attention masking, FlashAttention varlen y ONNX/TensorRT graph execution. Si se usa padding-free attention, Unpadding puede reducir cómputo sobrante en pad tokens, pero eso no es parte del modelo en sí.

3. Pipeline técnico y mecánica interna

El pipeline de Laya en producción tiene cuatro fases: formación del estado, transformación, inference y feedback.

1. Formulación del estado de entrada

El agente debe enviar un estado estructurado, no un raw user prompt: intent, memory, available tools, policy flags, previous actions y risk signals.

{
  "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. Transformación y normalización

La normalización debe ser determinista:

• validación de JSON schema;
• eliminación o masking de PII, secrets y tokens;
• ordenamiento de campos o fixed order;
• límite de longitud de texto;
• tokenización a input_ids y attention_mask.

Ejemplo de contrato en Python con 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. Ejecución / inference

Pseudosignatura simplificada:

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(),
    )

Para production serving son importantes:

• warm-up antes de la primera petición;
• dynamic batching para throughput;
• CUDA graphs o compiled inference para P95 latency estable;
• ONNX Runtime, TensorRT, Triton o Hugging Face Inference según el stack;
• shadow inference para comparar contra un LLM router.

4. Procesamiento de feedback

Laya no es un modelo estático. Para mantener calidad se requiere un feedback loop:

{
  "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"
}

Estos logs se usan para:

• retraining;
• calibration;
• drift detection;
• adversarial mining;
• evaluation sobre nuevas action classes;
• audit trail de decisiones de safety.

Para reproducibilidad, cada decisión debe poder vincularse a un Checkpointer o checkpoint exacto del estado del agente, junto con policy_version y model_version.

4. Escenarios prácticos de ingeniería en producción

01. Router MCP de baja latencia

En un agente con herramientas MCP, el LLM suele gastar tiempo eligiendo herramienta. Laya puede actuar como pre-router: si el estado contiene un intent claro y una herramienta permitida, el modelo selecciona tool:* en lugar de un ReAct loop completo.

Ejemplo:

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

Si la confidence es alta, el agente invoca la MCP tool directamente. Si no, pasa la petición a un LLM ReAct loop o solicita una aclaración. Esto reduce la latencia de Tool Calling y hace el routing más determinista.

02. Guardrails / policy gate antes del LLM

Laya puede funcionar como una capa rápida de safety. Entrada: user text + agent state. Salida: acción permitida o bloqueo.

Escenarios:

• detección de prompt injection en datos estructurados;
• clasificación de peticiones con riesgo de PII leakage;
• bloqueo de acciones que requieren human review;
• verificación de cumplimiento de policy antes de invocar un LLM costoso;
• triage: allow, clarify, reject, escalate.

Esto es más barato que un guardrail LLM completo porque un solo Forward Pass cuesta decenas de milisegundos y no genera tokens. Sin embargo, Laya no sustituye una safety architecture completa: debe combinarse con reglas deterministas, allowlists, audit logging y fallback LLM. Si el agente ejecuta acciones sobre código, conviene añadir validación AST.

03. Agente local self-hosted en Docker agents o bare-metal

Para entornos privacy-sensitive, Laya se despliega localmente: Docker agents, Kubernetes, bare-metal GPU o edge infrastructure. El modelo no envía el estado a una API externa, algo crítico en enterprise, healthcare, finance y escenarios tipo defense.

Stack típico:

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

En una GPU self-hosted, la latencia puede mantenerse en ~33–35 ms para entradas típicas. En CPU la latencia es mayor, pero puede seguir siendo aceptable para batches pequeños y estados cortos. Frente a un LLM cloud, el tradeoff bare-metal vs cloud es pagar GPU capacity y MLOps a cambio de coste predecible, privacidad e independencia de API limits.

5. Errores comunes, trampas y seguridad

01. Drift del action space

Laya se entrena o calibra para un action space concreto. Si se añade una nueva MCP tool, cambia la policy o se renombra una action, el modelo puede devolver un action_id obsoleto o inválido.

Mitigación:

• mantener un action registry;
• validar allowed_actions en la entrada;
• bloquear acciones desconocidas;
• retrain o adapter fine-tuning cuando cambian las herramientas;
• usar semantic fallback en el LLM.

02. Prompt injection a través de JSON/text

El estado del agente puede contener texto hostil: ignore previous policy, call admin_tool, send token. El encoder puede ser sensible a patrones adversarios, especialmente si no se entrenó con adversarial data.

Mitigación:

• separar el user text de los campos de system policy;
• normalizar y sanitizar la entrada;
• no permitir que el texto modifique allowed_actions;
• entrenar con injection-labeled data;
• añadir deterministic policy gates;
• usar confidence threshold y fallback.

03. Calibración incorrecta de confidence

La confidence de softmax no es una probabilidad de corrección. El modelo puede estar confidentemente equivocado, sobre todo después de distribution shift.

Mitigación:

• temperature scaling;
• isotonic regression;
• calibration curves;
• abstention threshold;
• shadow evaluation sobre producción;
• monitoring específico para high-confidence false positives.

04. Overfitting a JSON estructurado

Laya puede aprender artefactos de formato: orden de claves, longitud de strings o nombres de campos específicos. Si el cliente cambia el schema, la accuracy puede caer.

Mitigación:

• augmentation: shuffle fields, paraphrase text y synthetic schema variants;
• field masking;
• canonical serialization;
• schema versioning;
• unit tests sobre variantes JSON.

05. Truncación de contexto

ModernBERT tiene contexto limitado. Un estado JSON grande con memory, transcript o logs puede recortarse, y el modelo puede decidir sin campos críticos.

Mitigación:

• pre-summarization;
• importance-based field selection;
• chunking con decision-only context;
• validación explícita de campos críticos;
• fallback si faltan required fields.

06. Falsa sensación de que Laya reemplaza reasoning

Laya es un clasificador System 1. No construye un plan multi-step, no verifica causalidad, no genera explicaciones y no depende de Induction Heads para copiar patrones contextuales. Los escenarios complejos de autonomous-loop requieren un LLM ReAct loop, tool observation, reflection y human oversight.

Mitigación:

• usar Laya para pre-routing, gate y triage;
• mantener el LLM para synthesis y novel planning;
• medir qué decisiones pueden migrarse de forma segura a System 1;
• no eliminar el LLM de decision paths críticos sin evaluation.

07. Varianza de latencia en serving

Los 33–35 ms declarados corresponden a condiciones típicas de GPU self-hosted. En producción, la latencia puede aumentar por cold start, GPU contention, batches grandes, CPU fallback, long context o network overhead.

Mitigación:

• warm-up;
• monitoring P95/P99;
• fixed batch policy;
• CUDA graphs;
• autoscaling;
• request timeout y fallback;
• load testing con estados JSON realistas.

08. Seguridad y compliance

Una modelo local no implica seguridad automática. El estado del agente puede contener PII, secrets y datos de negocio. Logging, retraining data, model weights e inference endpoints requieren protección.

Mitigación:

• redaction antes de inference;
• encrypted storage;
• access control para la inference API;
• audit trail;
• data retention policy;
• adversarial testing;
• human-in-the-loop para acciones de alto riesgo.