El bot ya usa OpenRouter.
Lo que no tiene es memoria.

No existe una «app del bot». El agente completo — loop, prompts, memoria, tools — vive dentro del monolito NestJS, entrelazado con el webhook, el envío y el inbox. Así viaja un mensaje hoy:

Todo lo que habla con Meta, con Postgres y con el admin se queda donde está. Todo lo que piensa se muda a agents/mogui, un proyecto eve autohospedado como servicio privado de Render — hermano del API en el mismo Blueprint, solo alcanzable por la red interna.

En eve, el agente es un directorio: las instrucciones, las tools, los procedimientos y los evals son archivos versionados en el monorepo — mismo repo, mismos PRs, misma disciplina de revisión que el resto de Mogos. Vive en agents/*, una categoría de workspace nueva junto a apps/* y packages/* (una línea en el package.json raíz): los agentes de IA en su propia fila, sin confundirse con apps/agent, que es el portal de referidores.

agents/mogui/
├── package.json                  · eve (pineado) + @openrouter/ai-sdk-provider + zod
├── agent/
│   ├── agent.ts                  · modelo + sesiones durables en Postgres
│   ├── instructions.md           · la persona Mogui — corta; el conocimiento ya no vive aquí
│   ├── tools/                    · tipadas con Zod · HTTP autenticado al API
│   │   ├── get_user_freights.ts      get_user_orders.ts
│   │   ├── get_freight_status.ts     get_freight_eta.ts
│   │   ├── create_lead.ts            register_account.ts
│   │   ├── request_human_agent.ts    show_main_menu.ts
│   │   ├── get_shipping_rates.ts     · NUEVA — tarifas vivas, mata el placeholder
│   │   ├── get_exchange_rate.ts      · NUEVA — tasa BCV del módulo real
│   │   └── search_knowledge.ts       · NUEVA — retrieval pgvector
│   ├── skills/                   · procedimientos que reemplazan las reglas-parche
│   │   ├── cotizar-flete/  primer-envio/  registro-magico/
│   ├── subagents/                · especialistas aislados, opcionales — ver «¿Y cuando sean varios?»
│   └── channels/
│       └── mogos-api.ts          · canal custom · continuationToken = conversationId
└── evals/                        · el set dorado · corre en CI antes de cada deploy
    ├── evals.config.ts
    └── …casos sembrados desde Message.metadata

// agent/agent.ts — el modelo es un parámetro, no una apuesta
import { defineAgent } from "eve";
import { createOpenRouter } from "@openrouter/ai-sdk-provider";

const openrouter = createOpenRouter({ apiKey: process.env.OPENROUTER_API_KEY });

export default defineAgent({
  model: openrouter("google/gemini-2.5-flash"),   // económico · sin cambiar de familia
  modelOptions: { temperature: 0.2 },              // tarea factual, no creativa
  limits: { sessionTimeoutMs: 30 * 24 * 60 * 60 * 1000 },
  experimental: { workflow: { world: "@workflow/world-postgres" } },  // sesiones en Supabase
});

¿Y cuando sean varios agentes?

Un app eve compila un agente raíz — no existe un agents/ con varios raíces dentro del mismo servicio. Lo que sí existe, en la fuente de verdad de eve, son tres escalones para crecer — y esta estructura ya los acomoda sin moverse:

El despachador entrega el mensaje al canal custom de eve y sigue con su vida. Cuando el turno durable termina, eve hace callback con un veredicto tipado — nunca con un envío directo.

// ida · despachador → eve (red interna de Render)
POST http://mogui:10000/eve/channels/mogos-api/message
Authorization: Bearer MOGOS_EVE_SERVICE_TOKEN

{
  "conversationId": "cmf4k…",      // continuationToken → una sesión durable por conversación
  "channel": "WHATSAPP",
  "text": "¿cuánto cuesta traer 2 CBM desde Yiwu?",
  "contact": { "name": "María", "phone": "+58…" },
  "userId": "usr_…" | null        // null = invitado → guestGuard en cada endpoint
}

// vuelta · message.completed → callback firmado al API
POST https://api…/messaging/bot/reply

{
  "conversationId": "cmf4k…",
  "kind": "reply" | "escalate" | "degraded",
  "messages": [ { "type": "text", "text": "…" },
                { "type": "interactive", … } ],   // límites Meta se validan al enviar
  "intent": "quote_freight",
  "toolsUsed": ["get_shipping_rates", "search_knowledge"]
}

Hoy el conocimiento se inyecta completo en cada turno y se actualiza con deploys. La disciplina correcta es la de la clase: embeddings en pgvector, indexado automático por hash, y retrieval medible. Todo lo que hace falta ya existe en el repo: el corpus está tipado (25 temas + 8 packs por ruta, es/zh — chunking natural), la base ya es Supabase Postgres, y el patrón de proteger índices especiales con guarda de prebuild ya se usa para los GIN de búsqueda.

Cada cambio de prompt, tool o modelo corre contra un set dorado antes de llegar a un cliente. La semilla no hay que inventarla: Message.metadata ya guarda el intent y las tools usadas de cada turno real — las conversaciones de estos meses son los casos de prueba.

// evals/cotizar/aereo-yiwu.eval.ts — un caso del set dorado
export default defineEval({
  description: "Cotización aérea usa la tarifa viva, nunca el placeholder",
  async test(t) {
    await t.send("¿cuánto cuesta traer 40 kg desde Yiwu por aéreo?");
    t.succeeded();
    t.calledTool("get_shipping_rates");        // la verdad viva, obligatoria
    t.judge.autoevals.closedQA("responde en USD con la tarifa vigente");
  },
});

eve compila a un servidor Node normal (eve build && eve start) — exactamente lo que Render ya corre. No hay dependencia de Vercel: ni para el runtime, ni para el modelo, ni para el estado.

Cada fase entrega valor sola y tiene una compuerta medible antes de la siguiente. La palanca más grande — el contenido — va primero porque no depende de ninguna infra nueva.