TL;DR: `colme-2` es la evolución de `colme-1`. Menos dependencia de prompt magic, más decisiones movidas al sistema, mejor base para tools, memory, batching, handoff y control operativo real.
No es un cambio cosmético ni una pantalla nueva. Es un cambio de arquitectura para que los agentes de Whaapy sean más operables en producción.
Por qué `colme-1` ya no bastaba
`colme-1` nos permitió operar agentes reales, integrar RAG y construir una primera generación útil del producto. Pero también nos mostró dónde estaba el techo.
Demasiadas reglas críticas vivían en prompts.
Los loops de tools y los edge cases eran más frágiles de controlar.
Las conversaciones largas encarecían demasiado el contexto.
La UI podía exponer settings sin enforcement real en runtime.
Inspirado en OpenClaw, construido para Whaapy
OpenClaw nos dio primitives de runtime. Whaapy construyó encima la capa de producto y operación que importa para negocios reales.
Lo que aporta OpenClaw
- compaction automática
- truncamiento de outputs de tools
- hooks del ciclo del agente
- tools con catálogo explícito
- memory y búsqueda híbrida
- mejor tolerancia a fallos
Lo que construye Whaapy
- backend como control plane
- gateway privado como execution plane
- tools conectadas a operaciones reales
- handoff y pausa humana integrados al soporte
- routing por motor v2/v3
- aislamiento por negocio y contrato compatible con dashboard
Un agente de negocio no puede depender solo de que el modelo recuerde las instrucciones correctas en el momento correcto.
La idea central de `colme-2` es mover decisiones críticas desde el prompt hacia mecanismos explícitos del sistema: routing, tools, pausa, handoff, split y control de ejecución.
Cómo está construido
`colme-2` separa claramente el plano de control del plano de ejecución.
Flujo del sistema
v2
colme-1 / runtime legacy
v3
colme-2 / gateway runtime
Backend como control plane
- configuración del agente
- estado de conversaciones
- pausas y handoffs
- analytics y envío final
Gateway como execution plane
- construcción de prompt
- resolución de modelo
- llamado de tools
- guardrails y métricas
Qué cambia en la práctica
Tools más confiables
El runtime está mejor preparado para usar herramientas con catálogo explícito, guardrails y menos dependencia de instrucciones ambiguas.
Control operativo real
Pausa humana, control global, control por conversación y handoff ya no son solo UX; forman parte del sistema.
Mejor manejo del canal
Batching, split de respuestas y contexto de pausa reflejan cómo se comporta WhatsApp en el mundo real.
Base más estable para escalar
Mejor separación de responsabilidades, mejor control de contexto y mejor punto de partida para costo, observabilidad y rollout.
`colme-1` vs `colme-2`
| Dimensión | colme-1 | colme-2 |
|---|---|---|
| Base runtime | Servicio legacy del agente | Gateway v3 inspirado en OpenClaw |
| Filosofía | Más prompt-driven | Más system-driven |
| Tools | Integradas, pero más frágiles en orquestación | Runtime preparado para tools y guardrails explícitos |
| Routing | Camino legacy | Bifurcación real por aiEngine |
| Batching | Existente, pero periférico | Parte del flujo v3 real |
| UI | Settings históricos mezclados | UI más honesta con enforcement real |
Lo más importante: confiabilidad operativa
No queríamos solo un agente que respondiera bien cuando todo sale bien. Queríamos un agente que siguiera siendo útil cuando el caso real se vuelve desordenado.
`colme-1` nos enseñó a construir un agente útil.
`colme-2` nos obligó a construir un sistema confiable.
Inspirado en OpenClaw, sí. Pero moldeado por los problemas reales que vimos operando agentes para negocios dentro de Whaapy.
`colme-2` ya forma parte de la nueva arquitectura v3 y convive con `colme-1` mientras hacemos la transición de forma gradual.