crescō.
operō · la capa operativa
crescō · operō · diseño esencial

Sus productos,
con personal adentro.

Cada cliente de crescō tiene su código y su estándar visual. Le falta la tercera capa: agentes que operan su negocio sobre su propia data — que ellos mismos configuran, en su propia UI, sin que nadie despliegue nada. Eso es operō.

3.
pilares por cliente · dos existen
1.
cron para todas las rutinas
0.
deploys para crear una rutina
10¢
por conversación atendida
01el hueco

Dos pilares en pie, uno vacío.

El stack que crescō administra para cada cliente ya tiene el código y la matriz de diseño. Lo que no tiene es la capa que opera — la que trabaja cuando nadie está mirando.

✓ existe
el código
Su monorepo: API, admin, client, móvil. crescō lo construye y lo administra.
mogos/apps/
✓ existe
el estándar visual
La matriz de la que se estampa cada pantalla. Tokens, componentes, marca y voz.
mogos-design/
◌ el hueco
la capa operativa · operō
Agentes de negocio que leen su data, la vigilan, avisan y —con permiso— actúan.
mogos/apps/agents/
la fronterados fábricas que no comparten runtime

crescō también va a tener agentes. Son otra cosa. Confundirlos es el error que hace que un proyecto así se vuelva inmanejable.

agentes de crescōagentes del cliente · operō
qué hacenescriben códigooperan el negocio
sobre quérepos, PRs, tareasdespachos, facturas, pacientes
quién los configuraingenieros, en archivosel cliente, en su UI
runtimeClaude Codeeve
dónde viven.claude/agents/apps/agents/
cómo se cobraen velocidad y margencomo módulo del producto
02dónde vive

Una app más del monorepo.

operō no es una consola aparte de crescō: es una app del repo de cada cliente, al lado de api y admin. Dos carpetas en el mismo repo que se leen solas — .claude/agents es quien construye el software; apps/agents es quien opera el negocio.

mogos/ · el monorepo del cliente
mogos/
├── .claude/
│   └── agents/                    ← agentes de CÓDIGO · crescō · Claude Code
│
├── apps/
│   ├── api/                       NestJS + Prisma + Swagger  ──┐
│   ├── admin/                     Next.js :3001                │
│   ├── client/                    Next.js :3002                │
│   └── agents/                    ← operō · eve                │
│       ├── package.json                                        │
│       └── agent/                                              │
│           ├── instructions.md    el oficio base               │
│           ├── instructions/
│           │   └── encargo.ts     ← lo que escribió el cliente │
│           ├── channels/
│           │   ├── eve.ts         ← la consola (auth de mogos) │
│           │   └── slack.ts       ← @mención                   │
│           ├── connections/
│           │   └── mogos.ts       ← su propio API por OpenAPI ─┘
│           ├── tools/             la caja de herramientas
│           │   ├── create_routine.ts
│           │   ├── list_routines.ts
│           │   ├── update_routine.ts
│           │   └── delete_routine.ts   approval: always()
│           ├── skills/            los oficios (playbooks por área)
│           ├── schedules/
│           │   └── dispatcher.ts  ← el ÚNICO cron: * * * * *
│           ├── hooks/             la bitácora
│           ├── lib/
│           └── instrumentation.ts OTel a backend propio · día uno
│       └── evals/                 ← el gate de salida
└── packages/
la puertael agente no toca la base de datos

El agente se conecta al API que ya existe, por OpenAPI. Los monorepos de crescō ya exponen Swagger. Consecuencia: el agente hereda gratis todas las validaciones, reglas de negocio y permisos que ya están escritos. Entra por la misma puerta que las personas — y cada endpoint nuevo que crescō construye ya es una herramienta nueva sin escribir una línea de más.

03la anatomía

El oficio y el encargo.

Un agente de operō son dos cosas que viven en lugares distintos y cambian a velocidades distintas. Entender esta separación es entender el producto entero.

crescō lo forja · código
el oficio
qué es
herramientas, conexión, skills y políticas de aprobación
vive en
apps/agents/ — archivos en git
cambia con
PR → review → deploy
ejemplo
saber leer facturas y escribir recordatorios
el cliente lo escribe · datos
el encargo
qué es
nombre, instrucción, horario, destinatario, umbrales
vive en
filas en la base de datos del cliente
cambia con
hablando con el agente
ejemplo
«los lunes dime quién me debe más de 5 días»
la ley de operō
El cliente escribe el encargo.
crescō forja las herramientas.

Un agente nunca puede hacer más de lo que hay en su caja — por más que se lo pidas. El radio de daño lo define la caja, no el texto. Y el cliente nunca puede forjar herramientas: ese es el renglón que sostiene la factura.

04las rutinas

Una rutina no se arma. Se pide.

La tentación es un constructor de flujos con cajitas y flechas. Es el error: convierte una conversación en plomería. En operō el configurador es un agente — le hablas y te devuelve una tarjeta legible que apruebas.

nueva rutina
tú
todos los lunes quiero saber quién me debe
operō
entendido. te propongo esto:
cobros vencidos
lunes · 09:00 · #mogos-finanzas
facturas con más de 5 días sin conciliar
⌾ solo reporta — no le escribe a nadie
¿5 días está bien, o prefieres otro corte?
guardarajustar
un solo objetola tarjeta se ve igual en todas partes

La tarjeta de rutina es la misma en el listado, en la bitácora y en la notificación de Slack. Una rutina y su corrida hablan el mismo idioma visual. Eso es lo que hace el sistema legible sin manual.

cómo funcionalas rutinas son datos, no archivos

Este es el patrón que hace posible el self-service, y está documentado por eve como dynamic scheduling: las rutinas viven como filas en la base de datos del cliente, y un solo cron las despacha.

el despachador · una sola rutina real en todo el sistema
  la UI del cliente            la DB del cliente          apps/agents/
  ─────────────────            ─────────────────          ────────────
  crea · pausa · edita   →    tabla routines       →   dispatcher.ts
  una rutina                  tenant · encargo          cron: * * * * *
  hablando, sin formulario    cron · canal · estado     claimDue() con lease
                                                        receive() por fila

  at-least-once: un crash entre receive y complete puede re-despachar.
  Toda escritura es idempotente o va detrás de aprobación. Regla dura.
modo ensayotoda rutina nace sin manos

Corre de verdad, lee de verdad, y en vez de ejecutar muestra qué habría hecho. Es el antídoto al riesgo de peor asimetría: que el agente se equivoque donde el cliente lo vea. El cliente lo ve fallar en privado antes de que hable en público.

cobros vencidos · ensayo · 3 corridas
lun 09:00habría escrito a 4 clientesver
lun 09:00habría escrito a 2 clientesver
lun 09:00habría escrito a 7 clientesver
soltarle las manosseguir en ensayo
06las superficies

Por dónde habla.

Un agente sin superficie es un cron con pretensiones. Tres puertas, y cada una sirve para algo que las otras hacen mal: la consola es donde se configura y se aprueba, Slack es donde conversa el equipo, y WhatsApp es donde está la gente que nunca va a abrir una consola — el chofer, el cliente, el de la calle.

slackel equipo · @mención y aprobación con botones

Dos modos: la rutina que habla sola a su hora, y la pregunta directa. En los dos, el agente cita su fuente en vez de afirmar — es la diferencia entre un dato y una alucinación con confianza.

#mogos-despachorutina · 7:00
◍
operōagente7:00
Buenos días. El contenedor MSKU-4471 bajó anoche.
· 84 cajas recibidas, 71 ya montadas en flete
· 13 sin flete, de 6 clientes distintos
· la salida de mañana sigue en pie
Las 13 sin flete llevan 4 días en almacén. Tres son del mismo cliente.
fuente: GET /orders?containerId=… · leído hoy 7:00:04 · 84 registros
#mogos-finanzas@mención
JD
Johanna9:14
@operō ¿quién quedó debiendo del contenedor que llegó el lunes?
1 respuesta
◍
operōagente9:14
Seis clientes, $4.812 en total. El más viejo lleva 11 días.
Quiero mandarles el recordatorio de pago.
6 clientes · correo desde mogos · no toca el saldo
sí, mándalover la listaahora no
fuente: GET /payments/admin/pending · 9:14:02

Restricción que manda sobre el diseño: el agente no lee el historial del canal. Solo consume los eventos que le llegan. No es una simplificación — una app comercial no aprobada en el Marketplace de Slack queda limitada a 1 request/minuto para leer historial, así que un agente que «lee el hilo para entender» funciona en el Slack de crescō y se cae en el del cliente.

whatsappel número elige el oficio

Un solo número por cliente. Lo que cambia no es el número: es quién escribe. El teléfono entra por el canal, se busca en la tabla de usuarios del propio cliente, y se estampa como principal — principalId, tenantId, rol. Con eso, defineDynamic resuelve en session.started qué oficio despierta y qué herramientas tiene. Es el mismo patrón multi-tenant de la consola, con el teléfono en lugar de la sesión.

un número · cuatro agentes · lo decide quién escribe
                      +58 412 ··· MOGOS   un solo número
                              │
                       ¿quién escribe?
                              │
      ┌───────────────┬───────┴───────┬───────────────────┐
      ▼               ▼               ▼                   ▼
  el chofer      el cliente      el contador       un desconocido
  entregas        atención        conciliación       nadie
  solo lee        solo lee        solo lee          cero datos
  su ruta         sus cajas       sus cuentas       pasa a un humano
la regla del número
El número elige el oficio.
No otorga poderes.

Un teléfono se pierde, se presta, se clona. Por eso el número alcanza para saber qué mostrarte, pero nunca para escribir: todo lo que toca dinero, mueve una entrega o le manda un mensaje a un tercero se confirma en la consola, con una sesión de verdad detrás. El agente de WhatsApp lee, responde y propone. No ejecuta.

Ese último caso es el que hay que diseñar primero, no último. Un número desconocido no recibe datos de nadie — ni un tracking, ni un saldo, ni la confirmación de que un cliente existe. Escala a un humano y se calla. Es la diferencia entre un canal de atención y una fuga.

Lo que cuesta: responder dentro de la ventana de 24 horas es gratis. Iniciar fuera de ella exige plantilla aprobada. Eso no es una limitación que sortear: es lo que define el carácter del agente — responde mucho, interrumpe poco.

07la consola

Cuatro vistas, ninguna más.

Estampada con los tokens del cliente. Entra a su producto y ve su marca, no la de crescō.

01
Agentes
El catálogo de oficios disponibles. Encendido y apagado, y qué puede hacer cada uno.
02
Rutinas
Las suyas, con su estado: ensayo, activa o pausada. Se crean hablando.
03
Bitácora
Cada corrida: qué la disparó, qué leyó, qué hizo y qué pidió permiso.
04
Gasto
Consumo por agente, con tope configurable. Sin sorpresas a fin de mes.
estampadoun solo código, distinto acabado
operō · un solo código
↓↓↓
mogos
mogos-design/css/tokens.css
amedi
amedi-design/css/tokens.css
kenco
kenco-design/css/tokens.css
08lo que cuesta

El cómputo es el 1%.

Un agente de cara al cliente, 80 conversaciones al día. Presupuestado a Sonnet 5 a $3/$15 — el precio introductorio muere el 31 de agosto y cualquier propuesta firmada sobre el intro nace con el margen roto.

costo mensual · agente operativo
tokens del modelo · con Haiku filtrando: ~$120$232
cómputo · eve sobre Vercel$11
WhatsApp · plantillas fuera de ventana$17
supervisión humana · el 77%$850
total cargado$1.110 /mes
0,26 de un operador

Ese es el número para la reunión. El precio no se pone por tokens: se pone por horas humanas evitadas. Cuesta un cuarto de operador y cubre las horas que ningún operador cubre.

modalidadcosto cargadopreciomargen
instalación
conectar el API, forjar la caja		ingenieríaproyecto—
guardia
vigila y avisa, no escribe		~$77/mes$300–450/mes74–83%
operativo
atiende, actúa con permiso, 24/7		~$1.137/mes$3.000–4.500/mes62–75%

La suscripción crece sola cada vez que crescō le agrega un endpoint al cliente. Tres topes se ponen antes del primer contrato, no después del primer susto: cap de tokens por sesión (el default de eve son 40M — una sesión desbocada cuesta ~$120), alerta de gasto por cliente, y protección contra bucles por webhook.

09los riesgos

Lo que puede salir mal.

lo que hay que blindar antes de cobrarlo

Ninguno de estos es hipotético: todos salen de la documentación real de eve o del comportamiento verificado de las plataformas.

El agente alucina y el cliente lo ve
Un vigilante que se equivoca en privado cuesta diez minutos. Un agente que en el Slack de mogos afirma que un envío salió cuando no salió cuesta la cuenta — y en logística el error tiene consecuencias físicas.
condición de salida: ningún agente habla en el canal de un cliente sin suite de evals con gate duro en CI. Sin la suite no se despliega, aunque el demo funcione.
eve está en preview
De 0.11.4 a 0.27.6 en seis semanas — unas 16 versiones menores con breaking changes documentados, y sin fecha anunciada de GA.
versión pineada exacta (cero ^). Subir de versión es tarea explícita con evals verdes, nunca efecto secundario de un npm install.
Defaults permisivos
eve trae approval: never() por defecto: si no lo declaras, las herramientas ejecutan sin humano. Contradice frontalmente «la AI propone, las personas deciden». El egress del sandbox también es allow-all.
toda herramienta de escritura declara aprobación explícita. Ninguna se queda con el default, y se verifica en el eval.
El rate limit de Slack
Una app comercial no aprobada en el Marketplace queda limitada a 1 request/minuto para leer historial. Un agente que «lee el hilo para entender» funciona en el Slack de crescō y se cae en el del cliente.
se diseña sin leer historial, consumiendo solo los eventos que le llegan. Decisión de arquitectura, no de última hora.
Datos que salen del perímetro · amedi es salud
Los tokens de las conexiones viven en la infraestructura del runtime, y el tráfico del modelo pasa por el gateway salvo que se apunte directo a Anthropic.
antes de que un byte de amedi toque operō se decide por escrito qué sale del perímetro, con allowlist de egress por dominio. Es cláusula de contrato, no decisión de infraestructura.
Lock-in en la capa útil
El código es Apache-2.0 y se puede self-hostear, pero al hacerlo se pierden el cron (los schedules no disparan en un host HTTP-only), las microVM del sandbox y el dashboard de observabilidad.
instrumentation.ts exportando OTel a backend propio desde el día uno, para que la observabilidad no quede de rehén.
lo que todavía no está verificado — honestidad sobre el terreno
  1. Nadie ha corrido eve. Todo este diseño sale de los docs embebidos en eve@0.27.6. La durabilidad real, el parqueo de aprobaciones sin consumir cómputo y el comportamiento del sandbox son promesas de documentación. Un día de agente de juguete lo resuelve — es la fase 0.
  2. Las tarifas de WhatsApp para Venezuela salen de fuente secundaria. crescō ya opera WhatsApp Cloud API en producción: el rate card oficial está a veinte minutos dentro del Business Manager.
  3. La frase «the factory is the product» no se pudo verificar como cita de Rauch. Existe su tesis sobre AI software factories; la frase exacta no aparece. No usarla en un deck ni con un cliente.
  4. Las métricas de Vercel sobre eve («100+ agentes en producción», «92% de tickets resueltos solos») son marketing de un producto en preview, sin verificación independiente. No citarlas como evidencia de madurez.
10el plan

Seis fases, una sola apuesta a la vez.

Cada fase termina con algo que se puede mostrar y con una decisión tomada. Ninguna depende de que la siguiente funcione.

fase 0
El agente de juguete · 1 día
Correr eve de verdad. Confirmar durabilidad, parqueo de aprobaciones, defineDynamic y el despachador. Convierte este documento de apuesta a plan.
fase 1
El primer oficio, en un solo cliente
Un agente que solo lee y avisa — el resumen de despachos de mogos por Slack. Sin escrituras, sin UI. Prueba la conexión OpenAPI, el canal y la bitácora.
fase 2
Las rutinas como datos
Tabla routines + despachador + herramientas CRUD. El cliente crea su primera rutina hablando. Todo en modo ensayo.
fase 3
La consola
Las cuatro vistas, estampadas con los tokens del cliente.
fase 4
Soltar las manos
La primera herramienta de escritura, con aprobación obligatoria y evals con gate duro en CI.
fase 5
Estampar en el segundo cliente
La prueba de que operō es un producto y no un proyecto.
las diez decisiones tomadas
  1. operō vive en apps/agents/ del monorepo de cada cliente, no en una consola central de crescō.
  2. Los agentes de código de crescō no migran a eve. eve entra solo por la puerta nueva.
  3. El agente entra por el API del cliente, nunca por la base de datos.
  4. Las rutinas son datos; las herramientas son código. El cliente nunca forja herramientas.
  5. El configurador de rutinas es un agente, no un formulario.
  6. Toda rutina nace en modo ensayo.
  7. El tenantId viene del auth verificado, jamás del prompt.
  8. Ningún agente habla en el canal de un cliente sin evals con gate duro.
  9. Se presupuesta Sonnet 5 a $3/$15.
  10. La versión de eve va pineada exacta.