LangGraph y CRM: aprobación humana con una prueba en Python (2026)

LangGraph y CRM: aprobación humana con una prueba en Python (2026)

Antes de permitir que un agente cambie tu CRM, quiero comprobar qué ocurre al aprobar, rechazar y repetir una acción. Soy Javier Santos Criado, de Javadex. En esta guía, revisada el 1 de noviembre de 2026, presento un ejercicio propio con siete pruebas automáticas: utiliza LangGraph, un CRM simulado y datos sintéticos. No llama a un modelo ni modifica cuentas reales. Sirve para revisar el mecanismo de autorización, no para certificar una integración completa.

¿Cuál es el mejor control para un agente conectado al CRM en España en 2026?#

El mejor control inicial es limitar las operaciones y comprobar el estado del CRM después de cada decisión. Una confirmación en pantalla no demuestra que el sistema haya respetado el rechazo. Tampoco un registro de ejecución demuestra que el cambio haya llegado al contacto correcto. Necesitas verificar ambas partes: autorización y efecto.

Si quieres preparar un borrador, el primer alcance puede terminar antes de enviar o modificar datos. Si quieres que el agente proponga cambios en el CRM, muestra registro, campos y valores concretos antes de aprobar. No pidas al usuario aceptar una frase vaga como «actualizar cliente». La autorización debería referirse a una operación identificable.

La intención de esta página es estrecha: explicar y probar un punto de aprobación. Para decidir si un proceso merece un agente, utiliza qué son los agentes de IA. Para evaluar la entrega completa, consulta pruebas de agentes antes de producción.

Contrato de acciones permitidas, noviembre de 2026#

El contrato no lo decide el modelo. Lo define el sistema con el responsable del proceso. El modelo puede proponer una operación dentro de ese conjunto; no debería ampliarlo por una petición escrita en un documento o por una explicación convincente del usuario. Los límites deben aplicarse donde se ejecuta la acción, además de explicarse en las instrucciones.

En una integración real, la cuenta utilizada también necesita permisos adecuados. No conectes una cuenta administradora para después confiar únicamente en que el agente «se portará bien». Si solo necesita crear una nota, evalúa si puede trabajar con ese permiso. La guía de roles y permisos desarrolla esa separación.

LangGraph vs una función directa: qué aporta la pausa en 2026#

Una función directa puede validar una entrada y escribir el resultado en el mismo recorrido. Cuando necesitas esperar una decisión externa, aparece otra necesidad: conservar qué se propuso y continuar el caso correcto después de recibir respuesta. Ahí el punto de pausa se convierte en parte del proceso, no en una ventana añadida al final.

La documentación de interrupciones de LangGraph describe interrupt() y la reanudación mediante Command. El ejercicio utiliza ese mecanismo. La decisión de negocio, la autenticación y los permisos siguen siendo responsabilidad de la aplicación. No se obtiene un sistema seguro simplemente por importar una función.

No todo proceso necesita una pausa. Una consulta de solo lectura puede tener otros controles. Pero una escritura que compromete datos o una comunicación externa merece un tratamiento explícito. Diseña el nivel de autonomía por acción, no como un interruptor que convierte todo el agente en «autónomo».

Descargar y ejecutar el ejercicio propio#

El archivo completo del ejercicio contiene un CRM sintético, un grafo de aprobación y siete pruebas. Lo he verificado en el entorno de trabajo con Python 3.13 y langgraph==1.2.19. El resultado de esa ejecución fue siete pruebas superadas. Eso describe este archivo y sus condiciones, no la fiabilidad de LangGraph en cualquier aplicación.

Crea un entorno aislado e instala la versión indicada antes de ejecutarlo. No necesita claves de API, acceso al correo ni una cuenta de CRM. Su ejecución no crea leads ni escribe en sistemas comerciales. Puedes descargar también el requisito de versión para repetir la instalación.

1python3 -m venv .venv
2.venv/bin/python -m pip install langgraph==1.2.19
3.venv/bin/python langgraph-crm-approval-2026.py

El objetivo es observar el contrato. Primero se propone una operación sintética de cambio de estado. El grafo queda interrumpido y el registro mantiene su valor original. Después una respuesta puede aprobar o denegar exactamente la propuesta. Una huella diferente se rechaza; una acción fuera de la lista permitida no llega a ejecutarse.

La huella es una comparación del contenido de la propuesta, no una firma de identidad. En el ejercicio, la respuesta de aprobación se construye dentro de las pruebas. En producción necesitarías verificar quién responde, qué permisos tiene y a qué propuesta vigente se refiere. No reutilices la demostración como un servidor público de autorizaciones.

El punto de aprobación, con sus límites visibles#

La parte central puede expresarse así. El archivo completo añade validación de campos, grafo y pruebas; este fragmento solo muestra el recorrido entre propuesta y ejecución. No debe copiarse aislado como si incluyera autenticación, almacenamiento o control de concurrencia.

1def review(state):
2    action = state["action"]
3    digest = fingerprint(action)
4    answer = interrupt({"action": action, "fingerprint": digest})
5    if not isinstance(answer, dict) or answer.get("approve") is not True:
6        return {"outcome": "denied"}
7    if answer.get("fingerprint") != digest:
8        return {"outcome": "approval-mismatch"}
9    return {"outcome": crm.apply(action)}

Una aplicación real también debe validar la operación antes de llegar a la pausa. El ejemplo completo permite una sola operación sobre un registro sintético con un valor de destino definido. Si se pide borrar, trabajar sobre otro registro o utilizar otro valor, termina fuera de alcance. La prueba comprueba que no existe escritura en esas condiciones.

Mantén efectos externos fuera de pasos que puedan repetirse sin control. Al reanudar o recuperar un proceso, parte del recorrido puede volver a ejecutarse. La aprobación no elimina la necesidad de que una acción repetida sea reconocible y no genere un segundo efecto accidental.

Qué prueban los siete casos y qué no prueban#

Ninguna prueba mide calidad de un modelo, precisión de una clasificación ni compatibilidad con un CRM comercial. El sistema no contiene un LLM. La generación de la propuesta se simula para aislar el mecanismo de control. Si después añades un modelo, necesitarás evaluar esa capa además del recorrido ya probado.

Tampoco demuestra que dos procesos concurrentes no puedan aplicar una operación dos veces. El simulador mantiene un registro de acciones en memoria; una integración real puede necesitar una restricción única, transacción o mecanismo de idempotencia del destino. La arquitectura debe decidirlo y probarlo bajo sus condiciones reales.

Persistencia: una pausa no debe depender del portátil del autor#

El ejercicio utiliza memoria local para que sea fácil de ejecutar. Al cerrar el proceso pierde tanto los datos sintéticos como los checkpoints. Es una limitación deliberada y visible. No representa continuidad tras reinicio y no debe presentarse como prueba de recuperación duradera.

La documentación de persistencia de LangGraph distingue checkpoints asociados a un hilo y almacenamiento para información entre hilos. En producción, el responsable técnico debe elegir y operar la persistencia adecuada. El comprador necesita saber qué se conserva, dónde y cómo se recupera; no basta con escuchar que «tiene memoria».

Define una identidad para cada solicitud y distingue la identidad del hilo de la identidad de la acción externa. Un mismo caso puede proponer varias acciones en momentos distintos. Usar un identificador para todo sin explicar su ciclo de vida puede impedir distinguir una repetición de un cambio legítimo.

Cuando una aprobación caduca o cambia el contexto comercial, no la reutilices silenciosamente. El destinatario, los valores o el registro pueden haber cambiado desde que alguien pulsó aprobar. La aplicación debe tener una regla para volver a solicitar validación o comprobar que sigue siendo aplicable.

Pruebas que faltan antes de conectar un CRM real#

Añade también pruebas de los límites reales de la API: autenticación renovada, campos obligatorios, registros eliminados y cambios de versión. Si no existe un entorno de pruebas del proveedor, hay que acordar cómo ensayar sin introducir datos ficticios como clientes reales. No confundas un test de conexión con una validación del proceso completo.

Un registro de operación puede contener identificadores y estados suficientes para investigar sin copiar toda la información del cliente. Decide qué necesita ver la persona revisora y qué debe quedar reservado. Para la interfaz de aprobación, muestra los datos necesarios para decidir; para una alerta general, evita difundir contenido sensible.

Qué dicen los usuarios y dónde viajan los datos#

Esta guía no incorpora testimonios de clientes ni una encuesta de adopción. El ejercicio aporta evidencia de comportamiento del código. Para recoger evidencia de uso en tu empresa, pide a las personas responsables aprobar y rechazar propuestas de prueba, localizar el registro destino y explicar qué información les falta para decidir.

No midas solo cuánto tardan en pulsar un botón. Observa si reconocen el registro, entienden el cambio y detectan una propuesta desactualizada. Una pantalla que facilita aprobar todo sin revisar puede reducir fricción y empeorar el control. Las decisiones de interfaz deben apoyar la responsabilidad del proceso.

Antes de transmitir datos al modelo, dibuja el recorrido completo: aplicación, CRM, herramientas, modelo, registros y copias. La pausa de LangGraph no establece una residencia de datos ni un cumplimiento jurídico. Revisa esos requisitos con quienes sean responsables de privacidad y seguridad en la organización.

Encaje de una implementación y formación del equipo#

Mi trabajo en Javadex es diseñar y construir sistemas en código con un resultado acordado y comprobable. La modalidad se decide: puedo implementar mientras el equipo valida, construir junto a una persona del cliente o acompañar a un equipo que quiere construir. No asigno desarrollo al cliente por defecto ni vendo una herramienta concreta como requisito para todos los casos.

Una implantación no debe prometer resultados de negocio solo porque incluye controles técnicos. Las siete pruebas muestran un comportamiento acotado. La decisión de compra requiere además utilidad del proceso, datos y capacidad de operación. La guía de presupuesto de agentes amplía los costes que hay que contrastar con una propuesta vigente.

Preparar el caso para una revisión de encaje#

Describe el CRM que utilizas, la acción que quieres proponer y la que debe quedar prohibida. Añade quién puede aprobar y cómo reconocerías un resultado incorrecto. Con ese contexto puedes utilizar el formulario de cualificación. No incluyas credenciales ni datos de clientes en la primera consulta.

Para continuar, revisa guía de frameworks, MCP y herramientas de empresa, Claude Agent SDK, crear agentes personalizados, cómo trabajo con una empresa y formación de Claude Code. Cada recurso amplía una decisión diferente; el ejemplo de esta página no sustituye una evaluación de producción.

Cómo leer un fallo del ejercicio sin extrapolarlo#

Si una prueba falla al repetirla, conserva la versión instalada y la salida completa antes de modificar el código. Puede haber una diferencia de entorno, un cambio en la dependencia o una edición del archivo. No atribuyas automáticamente el resultado al modelo: este ejercicio no utiliza ninguno. Esa separación es parte de su utilidad.

En una implementación real, un fallo debería poder localizarse con el identificador del caso y la operación propuesta. Si el registro cambió y el proceso declara error, la recuperación necesita conciliar lo que sucedió antes de reintentar. Una petición sin respuesta no demuestra que el destino no haya escrito.

El ensayo también permite discutir qué información mostrar a quien aprueba. La propuesta debe ser suficientemente concreta para decidir, pero no exponer datos que esa persona no puede consultar. Puede ser necesario comprobar sus permisos en el momento de revisar, además de cuando se creó la solicitud.

No conviertas el resultado de las pruebas en una autorización indefinida. Añadir otro campo, otra operación o un nuevo destino cambia el contrato. Conserva una versión del conjunto anterior y amplía la evaluación con la capacidad nueva. De ese modo puedes distinguir una mejora deliberada de una ampliación de permisos que nadie había aceptado.

Preguntas frecuentes#

¿Cómo añadir aprobación humana con LangGraph en 2026?#

Puedes utilizar una interrupción y reanudar después de validar una decisión externa. La aplicación debe comprobar identidad, permisos, propuesta y efectos, además de configurar persistencia adecuada.

¿El ejemplo modifica un CRM real?#

No. Solo utiliza un registro sintético en memoria y no llama a modelos ni servicios externos. Las siete pruebas comprueban ese ejercicio acotado.

¿Aprobar una acción evita que se ejecute dos veces?#

No por sí solo. Hace falta reconocer la acción y tratar repeticiones y concurrencia en el destino. El simulador demuestra una deduplicación local, no una garantía transaccional de producción.

Fuentes y ejercicio revisados el 1 de noviembre de 2026. Resultado reproducido: siete pruebas superadas con Python 3.13 y LangGraph 1.2.19. No representa un caso de cliente ni una certificación de seguridad.