Engine (`@tedos/engine`)

@tedos/engine es el motor de ejecución de última milla: convierte modelos de IA en soluciones implementadas y confiables para cada cliente. El modelo es intercambiable; el valor es todo lo que lo rodea — evals, guardrails, un gate humano, conectores y deliberación.

La tesis en una línea: el modelo es intercambiable; el moat es la capa de fiabilidad que lo envuelve.

Principios de diseño

Servicio por fuera, producto por dentro. El cliente compra una implementación; el núcleo es reutilizable para que cada entrega sea más barata que la anterior.
Fuera de la capa de la API de Claude. El motor solo conoce una interfaz LLMProvider. El default es un modelo open-source (Ollama / vLLM); cualquier API es "solo otro provider".
El flujo manda, el modelo aporta el craft. Un playbook fijo (el experto) define el plan, no el modelo; el modelo redacta/clasifica dentro de pasos acotados.
La fiabilidad es el producto. Evals + reintentos + guardrails + un gate humano son lo que lleva un vertical de ~25% a ~95% de consistencia.
El humano decide lo importante. Las acciones de alto riesgo (enviar, cobrar) pasan por un gate humano; las decisiones se pueden deliberar en consejo.

Vista de capas

                         OBJETIVO del cliente
                                │
                     ┌──────────▼───────────┐
                     │     ORQUESTADOR      │  el flujo controla a los agentes
                     └──┬───────┬───────┬───┘
            plan ───────┘       │       └──────── fiabilidad + observabilidad
                                │
          ┌──────────────┬──────┴─────────┬──────────────────┐
          ▼              ▼                ▼                  ▼
     herram. conector  contenido        consejo           (gate humano)
                      (modelo + evals)  (deliberación)
          │              │                │
   ┌──────▼──────┐  ┌────▼─────┐    ┌─────▼──────┐
   │ CONECTORES  │  │ PROVIDER │    │   ROLES    │
   │ crm·whatsapp│  │ (modelo) │    │ (council)  │
   │ ·facturas   │  │ oss/mock │    │            │
   └─────────────┘  └──────────┘    └────────────┘

  VERTICAL (marketing | contable) = playbook + conectores + evals + prompt
  API HTTP + una COLA estilo pg-boss lo envuelven todo

Módulos (responsabilidad única)

Módulo	Rol
`provider.ts`	La frontera con el modelo — `LLMProvider` + un provider compatible con OpenAI (Ollama/vLLM) + un `MockProvider` determinista. Sin SDK de Anthropic.
`providerSelect.ts`	Elige el provider por entorno (modelo real si está configurado; mock si no).
`orchestrator.ts`	El corazón — recorre el playbook, ejecuta cada paso (conector / contenido / consejo), aplica reintentos, evals, guardrails y el gate, calcula la fiabilidad. Agnóstico al vertical y al modelo.
`planner.ts`	Toma el playbook del vertical y valida que cada paso apunte a una herramienta real. No usa el modelo.
`evaluator.ts`	Puntúa texto contra criterios (0..1 + fallos) — define "correcto".
`reliability.ts`	Guardrail PII, el predicado de gate humano, checkpoints, reintentos.
`observability.ts`	Un tracer — traza estructurada (eventos + resumen).
`roles.ts`	Roles como objetos runtime (`systemPrompt`, conectores permitidos, modelo).
`council.ts`	Un nodo de consejo / board-meeting — deliberar → opiniones + consenso + minutas.

Modelo híbrido

El mismo vertical corre en tres modos — solo cambia el LLMProvider:

local — Ollama, inferencia $0, datos en casa.
hosted — tu propio vLLM en la nube (compatible con OpenAI).
mock — determinista, sin red.

Conectores (producto, no flujo de trabajo)

El motor entrega conectores conscientes del tenant — CRM, WhatsApp (Meta / 360dialog), Google, HubSpot, GitHub, facturas. Cada tenant conecta sus propias cuentas vía un flujo OAuth de 3 patas (en apps/api, el plano de control), y el motor actúa con sus tokens, leídos de una bóveda de credenciales cifrada-por-tenant. "Tu Claude es tuyo, tu data es tuya" — solo se guardan los tokens (cifrados), nunca el contenido del cliente.

Los conectores son producto, nunca flujo de trabajo

Los conectores del tenant operan sobre los sistemas del cliente. Nunca se enrutan a través de los git-mechanics del flujo de trabajo, y la herramienta del flujo de trabajo nunca se enruta a través de un conector del tenant. Ver Build y flujo de trabajo → frontera kit ↔ engine.

Dónde encaja

El motor es el sustrato del futuro asistente por cliente (Capa 4 de Datos, memoria y asistente): el asistente es recuperación sobre el SoR

memoria a través de este motor — no se construye un nuevo motor.

Principios de diseño​

Vista de capas​

Módulos (responsabilidad única)​

Modelo híbrido​

Conectores (producto, no flujo de trabajo)​

Dónde encaja​