Un paso antes de todo lo que sale hacia afuera.
Así se pondría VoBo en el flujo que 30X nos describió: agentes en Python, aprobación por Slack y HubSpot solo como registro.
Recorre los caminos solo · elige uno para fijarlo
1Agente de 30X
Propone la acción con una herramienta (Python, tool calling o MCP).
2Puerta de salida
La herramienta consulta a VoBo antes de ejecutar. Las llaves de salida viven solo aquí.
3VoBo
Reglas en código + JEV, ≈ 0,4 s. Si no responde bien, la acción no sale.
PERMITIR
Sale: correo, WhatsApp, redes o el cambio en HubSpot.
PEDIR VOBO (o falla)
No sale aún. Aviso en Slack; decide una persona.
BLOQUEAR
No sale. El agente recibe las razones.
- Registro de cada decisión: request_id + ID de HubSpot.
Una sola puerta, dentro de la herramienta del agente
Las herramientas de salida (correo, WhatsApp, redes, HubSpot) llaman a VoBo antes de ejecutar. La consulta no depende de que el agente decida preguntar.
Las llaves viven solo en la puerta
Los agentes no tienen las credenciales de HubSpot ni de WhatsApp: todo lo que sale pasa por el mismo punto auditable.
Falla cerrada
Si VoBo no responde, tarda o devuelve algo inválido, la acción no sale y espera a una persona. Probado contra servidores caídos y colgados.
Un solo modelo, con lo mínimo
JEV es el único modelo y solo ve el texto que va a salir, el tipo y el canal. Sin otro LLM y sin datos de las personas.
Qué está construido y qué no.
- Puerta de salida MCP en Python
- Construida y probada contra la demo con MCP Inspector (PERMITIR, PEDIR VOBO y BLOQUEAR) y con Claude Desktop como agente de ejemplo.
- Aviso a Slack de lo que pide VoBo
- Probado contra un Slack de prueba.
- Ejecución en HubSpot y WhatsApp
- Ejemplo, no conectado a los sistemas de 30X.
- Registro en HubSpot
- Solo diseño: no se escribe en ningún CRM.
Código y detalle: puerta de salida MCP · guía de integración.
