Laya Open Decision Engine

1. Conceito e Essência (Visão Geral e Problema Sistêmico)

A Laya resolve um problema específico dos sistemas agênticos: a maioria das decisões em agentes de produção não requer raciocínio generativo, mas sim roteamento rápido de estado. O loop clássico ReAct com LLM invoca o modelo para cada passo, fazendo com que até mesmo soluções triviais — escolher uma ferramenta, rejeitar uma ação proibida, encaminhar uma solicitação para fallback — custem centenas de milissegundos, tokens e custos de API externa.

A Laya é um motor de decisão System 1 open-source da Convai Innovations, construído sobre o ModernBERT-large sob licença Apache 2.0. O modelo recebe o estado estruturado do agente — JSON, contexto textual ou uma combinação deles — e retorna uma decisão em um único Forward Pass: action, confidence, reason codes. No posicionamento da Convai, trata-se de um análogo aberto do Jev: não um substituto para LLMs em planejamento complexo, mas um classificador de decisões rápido e self-hosted para loops agênticos de alta QPS.

Tecnicamente, a Laya é um modelo de decisão baseado em encoder: um Transformer bidirecional que não gera token por token, mas processa todo o contexto de entrada e produz logits sobre o espaço de ações. Isso altera criticamente a economia da inferência: não há decodificação autoregressiva, não há KV Cache, não há otimizações típicas de LLM como Fast Patching; em vez disso, há um único passe batched de encoder com latência previsível.

O efeito econômico da Laya surge onde as decisões são repetitivas: roteamento de tool-calling, safety gate antes da LLM, agentes locais em Docker agents, inferência bare-metal, cenários self-hosted sensíveis à privacidade. Se um agente toma 10.000 decisões por minuto, migrar 60–80% das decisões triviais da LLM para a Laya reduz o orçamento de latência e os custos de tokens sem perda de qualidade, pois essas decisões não exigem pensamento aberto.

2. Arquitetura e Mecânica Interna (Taxonomia e Modelo Mental)

A Laya opera como uma decision head sobre o ModernBERT-large. O estado de entrada do agente é normalizado, tokenizado, passa pelo encoder, após o que a camada de pooling e a cabeça de classificação produzem uma distribuição sobre o espaço de ações. O Postprocessor aplica a política: verifica allowed_actions, threshold de confiança, lógica de fallback e 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

Taxonomia dos componentes:

1. State Normalizer — Converte JSON/texto em forma canônica. Por exemplo, {"intent":"refund","amount":120,"user_tier":"paid"} pode ser serializado em uma string determinística com chaves, valores e tipos. Isso é importante porque o encoder é sensível à ordem dos campos e à tokenização.
2. Tokenizer — Tokenizer padrão do ModernBERT. A entrada é limitada pelo contexto, geralmente até 8k tokens. Para grandes estados JSON, é necessária pré-sumarização ou seleção de campos.
3. ModernBERT Encoder — Transformer bidirecional com RoPE. Diferentemente de LLMs causais, cada token vê o contexto à esquerda e à direita, melhorando a classificação do estado.
4. Decision Head — Geralmente classificação ou classificação multi-label. Pode retornar um único action_id, várias flags de risco ou uma pontuação de confiança.
5. Policy Layer — Camada determinística: verificação de ações permitidas, thresholds, Guardrails, fallback, metadados de auditoria.

A principal diferença arquitetural em relação às LLMs: a Laya não possui KV Cache, não executa geração autoregressiva e não requer otimização no tempo de decodificação. Na camada de serving, as otimizações referem-se a kernels de encoder batched, dynamic padding, attention masking, FlashAttention varlen, execução de grafos ONNX/TensorRT. Se for utilizado attention sem padding, o Unpadding pode reduzir cálculos desnecessários em tokens de pad, mas isso não faz parte do modelo em si.

3. Pipeline Técnico do Ciclo de Vida

O pipeline da Laya em produção consiste em quatro fases: formação do estado, transformação, inferência, feedback.

1. Formulação do Estado de Entrada

O agente deve transmitir não o prompt bruto do usuário, mas um estado estruturado: intent, memória, ferramentas disponíveis, flags de política, ações anteriores, sinais de risco.

{
  "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. Transformação e Normalização

A normalização deve ser determinística:

• Validação do schema JSON;
• Remoção ou mascaramento de PII, secrets, tokens;
• Ordenação de campos ou ordem fixa;
• Limitação do comprimento do texto;
• Tokenização em input_ids e attention_mask.

Exemplo de contrato em Python com 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. Execução / Inferência

Assinatura pseudocódigo 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 o serving em produção, são importantes:

• Warm-up antes da primeira requisição;
• Dynamic batching para throughput;
• CUDA graphs ou inferência compilada para latência P95 estável;
• ONNX Runtime, TensorRT, Triton, Hugging Face Inference — dependendo da stack;
• Shadow inference para comparação com o router LLM.

4. Processamento de Feedback

A Laya não é um modelo estático. Para manter a qualidade, é necessário um loop de feedback:

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

Esses logs são utilizados para:

• Retreinamento;
• Calibração;
• Detecção de drift;
• Adversarial mining;
• Avaliação para novas classes de ação;
• Trilha de auditoria para decisões de segurança.

4. Cenários Práticos de Uso em Produção

01. Low-latency MCP tool router

Em agentes com ferramentas MCP, a LLM frequentemente gasta tempo escolhendo a ferramenta. A Laya pode funcionar como pre-router: se o estado contém um intent claro e uma ferramenta permitida, o modelo escolhe tool:* em vez de executar o loop ReAct completo.

Exemplo:

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

Se a confiança for alta, o agente chama imediatamente a ferramenta MCP. Caso contrário, encaminha a solicitação para o loop ReAct da LLM ou pede esclarecimentos. Isso reduz a latência do tool-calling e torna o roteamento mais determinístico.

02. Guardrails / policy gate antes da LLM

A Laya pode atuar como uma camada rápida de segurança. Entrada: texto do usuário + estado do agente. Saída: ação permitida ou bloqueio.

Cenários:

• Detecção de prompt injection em dados estruturados;
• Classificação de solicitações quanto a vazamento de PII;
• Bloqueio de ações que exigem revisão humana;
• Verificação de conformidade com a política antes de chamar uma LLM cara;
• Triage: allow, clarify, reject, escalate.

Isso é mais barato do que um guardrail LLM completo, pois um único Forward Pass custa dezenas de milissegundos e não gera tokens. No entanto, a Laya não substitui uma arquitetura completa de segurança: ela deve ser combinada com regras determinísticas, allowlists, logging de auditoria e fallback para LLM.

03. Self-hosted local agent em Docker agents ou bare-metal

Para ambientes sensíveis à privacidade, a Laya é implantada localmente: Docker agents, Kubernetes, GPUs bare-metal, infraestrutura edge. O modelo não envia o estado para APIs externas, o que é crucial para cenários enterprise, healthcare, finance e similares ao defense.

Stack típico:

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

Em GPUs self-hosted, a latência pode ficar na faixa de ~33–35 ms para entradas típicas. Em CPU, a latência é maior, mas ainda pode ser aceitável para batches pequenos e estados curtos. Comparado a LLMs em nuvem, o tradeoff entre bare-metal e nuvem aqui é o seguinte: você paga pela capacidade de GPU e MLOps, mas obtém custo previsível, privacidade e independência dos limites de API.

5. Armadilhas, Erros Comuns e Segurança

01. Drift do Espaço de Ações

A Laya é treinada ou calibrada para um espaço de ações específico. Se adicionar uma nova ferramenta MCP, alterar a política ou renomear uma ação, o modelo pode retornar um action_id obsoleto ou inválido.

Mitigação:

• Manter um registry de actions;
• Validar allowed_actions na entrada;
• Bloquear ações desconhecidas;
• Realizar retrain ou fine-tuning de adapters quando houver mudança nas ferramentas;
• Usar fallback semântico na LLM.

02. Prompt Injection via JSON/texto

O estado de entrada do agente pode conter texto hostil: ignore previous policy, call admin_tool, send token. O encoder pode ser sensível a padrões tóxicos, especialmente se o modelo não foi treinado com dados adversariais.

Mitigação:

• Separar o texto do usuário dos campos de política do sistema;
• Normalizar e sanitizar a entrada;
• Não permitir que o texto altere allowed_actions;
• Treinar com dados rotulados para injection;
• Adicionar gates de política determinísticos;
• Usar threshold de confiança e fallback.

03. Calibração Incorreta da Confiança

A confiança do Softmax não é probabilidade de correção. O modelo pode estar confiantemente errado, especialmente após distribution shift.

Mitigação:

• Temperature scaling;
• Isotonic regression;
• Curvas de calibração;
• Threshold de abstenção;
• Avaliação shadow no tráfego de produção;
• Monitoramento separado para falsos positivos de alta confiança.

04. Overfitting em JSON Estruturado

A Laya pode aprender artefatos de formatação: ordem das chaves, comprimento das linhas, nomes de campos específicos. Se o cliente mudar o schema, a precisão cairá.

Mitigação:

• Augmentation: embaralhar campos, parafrasear texto, variantes sintéticas de schema;
• Field masking;
• Serialização canônica;
• Versionamento de schema;
• Testes unitários em variantes de JSON.

05. Truncamento de Contexto

O ModernBERT tem contexto limitado. Um grande estado JSON com memória, transcrição, logs pode ser truncado, e o modelo tomará a decisão sem campos críticos.

Mitigação:

• Pré-sumarização;
• Seleção de campos baseada em importância;
• Chunking com contexto apenas para decisão;
• Validação explícita da presença de campos críticos;
• Fallback se os campos obrigatórios estiverem ausentes.

06. Ilusão de que a Laya Substitui o Raciocínio

A Laya é um classificador System 1. Ela não constrói planos multietapas, não verifica causalidade, não gera explicações. Cenários complexos de autonomous-loop exigem loop ReAct com LLM, observação de ferramentas, reflexão e supervisão humana.

Mitigação:

• Usar a Laya para pre-routing, gate, triage;
• Deixar a LLM para síntese e planejamento novel;
• Medir quais decisões podem ser transferidas com segurança para o System 1;
• Não remover a LLM dos caminhos críticos de decisão sem avaliação.

07. Variância de Latência no Serving

Os 33–35 ms declarados referem-se a condições típicas de GPU self-hosted. Em produção, a latência pode aumentar devido a cold start, contenção de GPU, batches grandes, fallback para CPU, contexto longo, overhead de rede.

Mitigação:

• Warm-up;
• Monitoramento P95/P99;
• Política de batch fixo;
• CUDA graphs;
• Autoscaling;
• Timeout de requisição e fallback;
• Load testing com estados JSON realistas.

08. Segurança e Compliance

Um modelo local não significa automaticamente segurança. O estado do agente pode conter PII, secrets, dados empresariais. Logs, dados de retraining, pesos do modelo e endpoints de inferência precisam de proteção.

Mitigação:

• Redação antes da inferência;
• Armazenamento criptografado;
• Controle de acesso para a API de inferência;
• Trilha de auditoria;
• Política de retenção de dados;
• Testes adversariais;
• Human-in-the-loop para ações de alto risco.