Hace 3 semanas compartí en mi primer Show GN que estaba construyendo un firewall de 5 niveles, y mientras tanto les comparto la corrección del diseño + lo que realmente ya shippeé. Se perdió con 1 punto / 1 comentario, pero hubo avances así que lo publico una vez más.
▶ Corrección de 5 niveles → 4 niveles (PUSH / QUEUE / SILENT / AUTO)
El nivel "Call" se quitó y quedó en pausa. Lo decidimos con datos durante el PoC.
▶ Loop del agente end-to-end completado
Llega un correo solicitando una reunión → clasificación por nivel → Klorn revisa conflictos en el calendario → respuesta + borrador del evento de calendario → espera en PendingAction → aprobación del usuario con 1 clic → lanzamiento. Todas las acciones se firman con un hash del payload antes del lanzamiento, y si no hay coincidencia con ActionReceipt, no se pueden ejecutar.
▶ La parte que más tiempo tomó: prueba de invariante (menos de 100 líneas de código)
Una prueba que rompe el build si una acción como send_email se ejecuta sin aprobación del usuario. Si alguien elimina la verificación de aprobación → falla la prueba → falla el build → falla el despliegue. Saltarse esto simplemente no es una opción. Esa es la razón por la que "el agente no lo envía por su cuenta" deja de ser un mensaje de marketing y pasa a ser un hecho.
▶ También atrapé un bug real en producción
OpenRouter retiró el SKU de modelo :free, así que todos los ciclos autónomos morían con "404 No endpoints found". El failover existente solo manejaba 402 / 403 / 429. No cubría el caso de "el modelo desapareció". Metí una cadena de fallback multi-modelo para que, aunque muera un SKU upstream, el agente no se caiga.
▶ Midiendo retención Day 14+7
Tener 5 ICP activos es el criterio para pasar el PoC. Incluso una sola línea de feedback honesto es bienvenida.
▶ Video de 60 segundos: https://klorn.ai
▶ Código: https://github.com/k08200/klorn
Beta gratis + PRO aplicado automáticamente. De verdad gracias a quienes dejaron opiniones en el primer post.
3 comentarios
Una pregunta: quienes operan
agent/ SaaS, cuando unagentactuó sin la intención del usuario, ¿cuál fue el failure mode que vieron con más frecuencia?En mi caso, por frecuencia en operación:
:free, el ciclo también muere sin siquiera fallbackMe da curiosidad conocer los patrones de otras personas.
El caso 2 pasaba con frecuencia, y cuando usé eso como fallback, según el prompt ocurría el caso 1 y como consecuencia terminaba pasando el 3, jajaja.
Obvio, si siempre usas un modelo avanzado no pasaría eso, pero al final, para un servicio de cara al cliente, algo del nivel de Sonnet o superior sí resulta pesado..
Jaja, de verdad me identifico con ese orden. A mí también lo que más me pegó fue el #2, y cuando lo bajas a free, el prompt ya no encaja y también me pasó exactamente lo mismo de que aparezca el #1.
Por eso, en algún momento dejé de confiar en el modelo y, en cambio, sin importar si el modelo es barato o caro, o si lo retiran, bloqueé que el modelo pueda decidir enviar correos, borrar cosas o pasarlas a sistemas externos. Eso siempre sale solo con aprobación humana. Lo único que corre en automático son cosas reversibles, como clasificación, marcar como leído o briefings.
Así, aunque el modelo haga drift, en el peor de los casos queda en "una propuesta rara que yo veo y rechazo", no en "una respuesta que ya se fue". El #1 no se termina propagando hasta el #3.
El #2 lo manejo detectando a diario los 404 del SKU free con una revisión del catálogo y desviándolo con una cadena de fallback, pero dejé fijo solo el clasificador en flash de pago. A mí también me pesa usar algo nivel Sonnet completo de cara al cliente... así que gasto plata solo en clasificación, dejo en free la parte de generar propuestas, y hago que la compuerta de aprobación se coma el riesgo.
Al final, creo que la clave fue no poner costo y seguridad en el mismo eje. El modelo puede ser barato, pero la compuerta no puede serlo.