Este es un post sobre por qué un atajo razonable terminó en una arquitectura distinta. Si estás explorando cómo meter un agente en tu CRM, lo que sigue te ahorra meses.
El punto de partida razonable
A finales de 2024 el plan era simple: tomar GoHighLevel, conectar un LLM por API, y dejar que un agente leyera leads, redactara follow-ups y actualizara el pipeline. Es lo que hace cualquiera con buenas intenciones y un sprint disponible. Funciona en demo. No funciona en producción.
El problema no es el modelo. Es la fundación.
Tres supuestos que castigan al agente
Los CRMs clásicos están diseñados para humanos. Esa premisa atraviesa todo: el esquema de datos, el shape de las APIs, los patrones de auditoría. Cuando metes un agente encima, los tres se rompen al mismo tiempo.
Datos inconsistentes. Cada cuenta cliente en GoHighLevel hereda los custom fields que el operador ha decidido. No hay taxonomía. Los pipeline_stage se llaman distinto en cada subaccount, los tags son cadenas libres, los notes mezclan markdown con texto plano. Para un humano leyendo es trivial inferir contexto. Para un agente es una pesadilla de normalización por workspace.
APIs incompletas para uso agentic. La v2 API de GHL (LeadConnector) está hecha para integraciones programáticas tradicionales: paginación inestable, rate limits opacos por endpoint, eventos de webhook que llegan a veces y a veces no. Un agente que decide en función de "¿hay un mensaje nuevo de este lead?" tiene que tolerar esa incertidumbre. Construir resiliencia encima del CRM cuesta el doble que construirla dentro.
Trazabilidad débil. El AI Act europeo (Reg. 2024/1689) clasifica como sistemas de "limited risk" buena parte de los productos que automatizan comunicación comercial. Eso obliga a transparencia operativa, registro y explicabilidad. GHL guarda histórico como timeline plano: notas, mensajes, tareas. No registra qué contexto vio el agente en cada decisión, ni qué política aplicó. Si el agente se equivoca con un cliente, no hay forma de reconstruirlo.
El experimento que cambió la arquitectura
Probamos las dos versiones del mismo producto con cinco operadores GHL durante seis semanas.
La versión A — agente leyendo y escribiendo a través de la API de GHL — alcanzó un techo bajo. El agente proponía drafts decentes pero llegaba al 60-65% de precisión en clasificación de intención. La razón: el contexto que cada lead tenía en el CRM era pobre o estaba en campos no estructurados. El agente no podía construirse una mejor representación; tenía que reusar la del humano.
La versión B — capa intermedia que normalizaba contexto, mantenía memoria propia y registraba todas sus acciones en un log inmutable — pasó del 87% en la cuarta semana. El agente leía sus propias notas estructuradas, no las del humano. Y cuando se equivocaba, podíamos auditar exactamente por qué.
La diferencia no era el modelo. Era la fundación.
Lo que cambia cuando construyes desde el agente, no para él
Hay cuatro decisiones que tomas distinto cuando el agente es el operador principal.
Memoria como ciudadano de primera clase
No es un append-only de notas. Es memoria por lead, por cuenta y por workspace, con compactación automática y embeddings para retrieval. El agente reconstruye contexto en milisegundos, sin que un humano se lo prepare. Esto solo se construye bien si lo decides desde la arquitectura inicial; añadirlo después significa duplicar la mitad del modelo de datos.
Aprobaciones explícitas, no modales pegados
Cada acción del agente que toca el mundo exterior pasa por un estado: proposed, approved, rejected, expired, executed. La aprobación es UX nativa. El operador puede auto-aprobar por reglas declarativas ("aprueba follow-ups en horario laboral si el lead está en stage X"). Esto convierte el handoff humano-agente en una cola predecible, no en un bombardeo de notificaciones.
ActionLog inmutable
Append-only. Cada decisión del agente queda registrada con el contexto que vio, la política que aplicó, lo que propuso, lo que se ejecutó y el resultado. Sin posibilidad de edición. Cuando el regulador europeo pregunta "demuéstreme la trazabilidad", no improvisas — exportas el log.
Multiagente con roles, no un solo agente todopoderoso
Un agente que hace de SDR, nurturer, closer assistant y compliance al mismo tiempo es ingeniería frágil. Frente a un caso ambiguo, su política se contradice consigo misma. Roles especializados con handoff explícito y memoria compartida son más predecibles, más auditables y más fáciles de mejorar uno a uno.
Por qué esto importa más allá de GHL
GoHighLevel es un caso particular pero la lección es general. HubSpot, Salesforce, Pipedrive — todos arrastran décadas de decisiones orientadas a humano. Sus APIs son frágiles, sus datos heterogéneos, su trazabilidad débil. Quien construya productos agentic sobre ellos sin una capa intermedia agent-native va a chocar contra los mismos techos.
La oportunidad no está en "ponerle IA a un CRM". Está en construir la capa donde los agentes operan, conectada a múltiples CRMs por adaptadores (overlay), o sin CRM externo (standalone). Esa capa es lo que llamamos GaaS — Generativa Agent as a Service.
Lo que construimos a partir de ese descubrimiento
CloserGaaS empieza en el wedge de operadores GHL porque es donde la fricción de adopción es más baja y el dolor más cuantificable. Pero la arquitectura no está atada a GHL. Tiene tres capas:
- Adaptadores de CRM (read/write hacia GHL primero; HubSpot, Pipedrive, Salesforce después).
- Capa agentic con memoria, políticas, multiagente con roles, aprobaciones nativas, ActionLog.
- CRM nativo opcional para operadores sin CRM externo (modo standalone).
El producto que ves hoy es el resultado de tirar a la basura el primer prototipo y aceptar que la fundación importa más que el modelo. La diferencia entre un asistente caro que rellena campos y un operador que mueve el negocio está casi entera en las cuatro decisiones de arriba — no en el LLM.
Si tu producto agentic está atascado en un techo de calidad que no entiendes, mira la fundación antes de cambiar de modelo.
Lecturas relacionadas
- Los 3 workflows de GoHighLevel que un agente reemplaza primero — qué automatizaciones manuales sustituye un agente y por qué.
- Multi-CRM por diseño vs IA bolted-on — la decisión arquitectónica que define la categoría.
- ActionLog inmutable: cumplir el AI Act sin frenar el roadmap — registro de decisiones del agente que el regulador europeo va a exigir.
¿Estás explorando GaaS para tu agencia GHL o equipo B2B? Únete a la waitlist — los foundational pilots están abiertos en cohortes de 10.