De 5 horas a 13 segundos: un agente de prospección con guardarraíles

Durante años, prospectar una cuenta me tomaba una tarde. El 12 de octubre de 2026 vi a un proceso hacer el ciclo completo de preparación en trece segundos, con un gasto de dos centavos y medio de dólar, y detenerse solo antes del único paso que importa: enviar. Esto es lo que medimos, lo que construimos para que esa velocidad fuera tolerable y lo que pienso después de verlo.

Respuesta breve. Transgenia conectó a su agente de prospección, Aitana, con un worker local que corre con la Messages API de Claude y con un conector MCP acotado hacia el ERP. En dos ciclos reales, el worker leyó la base, decidió, creó un borrador vacío de correo masivo, lo releyó y liquidó su gasto: 13 y 15 segundos por ciclo, USD 0.045 en total, cero correos enviados. El mes anterior, el mismo canal comercial llevaba 48 días sin un solo envío porque cada paso dependía de una persona. La velocidad no es la noticia. La noticia es que fue tolerable solo porque el envío no está al alcance del agente, el presupuesto se reserva antes de pensar y cada afirmación tiene una lectura de vuelta. A eso le llamamos respeto a la inteligencia artificial.

Diagrama 1. El proceso manual de prospección en siete pasos, de elegir la cuenta a planificar los siguientes toques, con una estimación de minutos por paso que suma entre tres y cinco horas. — Diagrama 1. La tarde de prospección tal como la vivía el autor antes del piloto. Los minutos son una estimación personal, no telemetría; el total de tres a cinco horas por prospecto es la cifra que sirve de línea base en este artículo.

La tarde de cinco horas: cómo prospectaba una persona

Llevo la mayor parte de las ventas de Transgenia. Antes del piloto, prospectar una cuenta nueva era una tarde completa. Elegir la empresa y entender a qué se dedica. Buscar los correos y al decisor, que casi nunca está publicado. Hacer una llamada previa para confirmar que la persona existe y que el tema le incumbe. Redactar el correo. Curarlo: quitar adjetivos, verificar cada cifra, poner la firma correcta y los dos adjuntos que exige nuestra política. Enviarlo y registrarlo. Y planificar los siguientes toques, porque un correo sin seguimiento es un correo tirado.

A ojo de buen cubero, entre tres y cinco horas por prospecto. Lo digo con esa expresión a propósito: es una estimación personal, no telemetría, y así la tratamos en el resto del texto. Nadie midió esas tardes con un cronómetro. Lo que sí medimos, y con detalle, fue lo que vino después.

El problema de ese proceso no era su calidad. Era que solo ocurría cuando yo tenía la tarde libre.

Lo que decía nuestra telemetría en septiembre

Tenemos un agente de prospección desde mediados de 2026. Se llama Valentina en el código y Aitana en la firma comercial. Ya contamos en este blog cómo diseñamos su motion de demo y sus reglas duras. Lo que no habíamos contado es lo que pasó cuando la operación dependía de que una persona iniciara cada paso.

Nuestra bitácora semanal de revisión, que un agente de gestión escribe cada sábado a partir de los registros del sistema, marcó el canal comercial en rojo en las semanas 35 y 36. Los datos son nuestros y los citamos tal como quedaron escritos:

Cero envíos salientes durante toda la semana, dos semanas seguidas.
El último correo enviado fue el 21 de julio. Para el 7 de septiembre el silencio llevaba 48 días.
Un barrido de 92 leads curados, con teléfono, correo y sitio verificados, llevaba 24 días sin activarse.
El resumen sabatino no se había generado en diez semanas. El resumen de los lunes llevaba seis semanas bloqueado por una condición de un flujo de automatización.
El scoreboard de la meta del semestre marcaba 0 % de avance, con el 38.5 % del tiempo consumido.

Diagrama 2. Línea de tiempo del canal comercial entre julio y septiembre de 2026: última ola el 21 de julio, barrido de 92 leads el 14 de agosto sin activar, revisiones semanales en rojo el 29 de agosto y el 7 de septiembre, y el resumen sabatino sin correr diez semanas. — Diagrama 2. Lo que decía nuestra propia bitácora semanal antes del piloto. El agente existía y las plantillas estaban listas; lo que faltaba era que alguien iniciara cada paso. El silencio saliente llegó a 48 días.

Ese era el estado del arte de nuestra propia operación. Las plantillas existían. El emisor con supresión y tope diario existía. Las listas existían. El agente existía. Lo que no existía era un proceso que arrancara, hiciera su trabajo y se detuviera sin que alguien lo acompañara de principio a fin. Y como ese alguien era yo, y yo estaba vendiendo, el canal se quedó quieto.

Conviene decirlo sin adornos: un agente que necesita una persona para cada paso no es un agente. Es un formulario con buena redacción.

Por qué no bastaba con "encender" al agente

La reacción natural a ese diagnóstico es darle al agente permiso para actuar solo. Nos negamos, y la razón está en la historia técnica del runtime.

Valentina pasó por siete versiones antes de tocar un buzón real. La primera decisión fue de plataforma: una implementación propia sobre la Messages API, porque en la validación de aquel momento los agentes gestionados no estaban disponibles para nuestra organización. Después vino un runner que solo producía borradores con datos sintéticos. Luego un ledger con idempotencia por identificador de mensaje y un límite global de cinco intentos por persona. Luego el manejo de deferencias del proveedor de correo y la conciliación terminal. Luego el cierre fail-closed: cualquier código ambiguo se trata como fallo y no se reintenta. Luego un ledger durable en SQLite que sobrevive a reinicios y a dos procesos concurrentes. Y al final, la lectura de salud de un buzón IMAP, primero probada sin red con 219 pruebas automáticas y después ejecutada una sola vez en vivo.

Diagrama 3. Mapa de evolución del runtime de Valentina: decisión de plataforma, modo solo borradores, ledger e intentos, deferencias, cierre fail-closed, ledger durable, preparación de salud de buzón y salud real verificada el 12 de octubre. — Diagrama 3. Siete versiones antes de un solo correo. Cada paso se cerró con pruebas sin red; la única lectura real del buzón se hizo en modo de solo lectura y quedó registrada con su hash.

Esa única lectura en vivo, el 12 de octubre a las 00:13 hora de la Ciudad de México, se hizo sobre TLS 1.3 con certificado verificado, abrió la carpeta con el comando EXAMINE, que en el protocolo IMAP equivale a modo de solo lectura, y cerró sesión. Cuatro comandos registrados, cero mutaciones, evidencia guardada con su hash. No leyó un solo mensaje.

Cuento todo esto porque explica el estándar que después le exigimos al worker. Si para mirar un buzón sin tocarlo pedimos 219 pruebas y una autorización con frase exacta, para escribir en el ERP no íbamos a pedir menos.

La decisión de plataforma: un proceso local y finito

El 10 de octubre revalidamos la arquitectura contra la documentación vigente de Anthropic. La conclusión fue menos ideológica de lo que parece.

Los agentes gestionados de Claude, los que corren en la nube y tienen sesiones persistentes, conectan sus herramientas a través de servidores MCP con URL remota y autenticación por sesión mediante un almacén de credenciales. Es un diseño correcto para infraestructura publicada. Nuestras herramientas no están publicadas: el conector hacia el ERP corre en un contenedor dentro de una computadora de escritorio, sin puertos expuestos. Una conexión remota a localhost no existe. Antes de tener un gate remoto, persistente y autenticado, esa ruta no era un camino.

Las extensiones de escritorio, por su parte, son una buena superficie para que una persona trabaje con el agente, pero no son un puente de sincronización, y no les íbamos a entregar credenciales de envío.

Diagrama 4. Comparación de dos rutas: agentes gestionados en la nube, que requieren conexiones MCP con URL remota y autenticación por sesión y por eso no alcanzan servicios locales, frente a un worker local que usa la Messages API y el servidor MCP de la propia máquina. — Diagrama 4. Por qué elegimos un proceso local y finito en vez de un agente gestionado. No fue una objeción al producto: fue que nuestros servicios viven en una computadora, y una conexión remota a localhost no existe.

Elegimos lo aburrido: un proceso Node local, sin dependencias nuevas, que arranca cuando una persona hace clic, llama a la Messages API con un modelo fijo, usa el conector MCP local y termina. No es un servicio permanente. No se instala como tarea programada. No abre puertos. Si la computadora está apagada, no pasa nada, y eso también está documentado como límite.

Un ciclo que termina solo

El contrato del ciclo se escribió antes que el código, y lo dibujamos antes de implementarlo. Una persona inicia. El worker verifica identidad del ERP, fuente de credenciales autorizada y presupuesto. Revisa scoring, historial de toques, bajas y respuestas. Si falta evidencia o no hay audiencia elegible, termina en HOLD con un informe, y HOLD no se reintenta solo. Si hay audiencia, congela un lote inmutable y espera un VoBo humano, sin bucle de espera: el proceso simplemente termina y deja el lote listo. El envío, cuando ocurra, sale exclusivamente por el módulo de correo masivo del ERP, nunca por un SMTP del agente.

Diagrama 5. Ciclo operativo del agente: preflight, revisión de elegibilidad, HOLD con informe si falta evidencia, lote inmutable, espera de VoBo sin bucle, revalidación y despacho exclusivamente por el canal de correo del ERP, con conciliación de trazas al final. — Diagrama 5. El contrato del ciclo. La única transición que lleva a un envío pasa por un VoBo humano explícito y por una revalidación posterior. Todo lo demás termina en HOLD con informe, y HOLD no se reintenta solo.

El 12 de octubre corrimos dos ciclos reales y un tercero vacío.

El primero fue de solo lectura: dos inferencias, dos llamadas de conteo al ERP, un informe en disco y cese del proceso. Entre la reserva del presupuesto y su liquidación pasaron 15 segundos. Gasto calculado: USD 0.018.

El segundo fue el que importa. Con autorización explícita para una sola escritura, el worker creó una plantilla de correo masivo sin destinatarios, con un asunto que dice en mayúsculas que no debe enviarse, la releyó, contó los correos y las trazas asociadas, y encontró cero y cero. Dos inferencias, una escritura, 13 segundos entre reserva y liquidación. Gasto calculado: USD 0.026.

Diagrama 6. Secuencia del segundo ciclo real del worker: reserva de presupuesto, primera inferencia, llamada a la herramienta que crea el borrador, segunda inferencia, lectura independiente del borrador y liquidación del gasto, con trece segundos entre la reserva y la liquidación. — Diagrama 6. Los trece segundos, reconstruidos desde el ledger de presupuesto y el registro de uso por solicitud. Dos inferencias, una escritura, cero destinatarios y un gasto calculado de USD 0.026.

El tercer arranque fue el que más me tranquilizó. Lo lanzamos como ciclo diario: el worker buscó candidatos nuevos después de aplicar supresiones, historial de cinco toques y exclusiones del lote anterior, no encontró ninguno, y terminó sin hacer una sola inferencia, sin crear plantillas y con gasto cero. Un segundo clic el mismo día devolvió el resultado anterior con la bandera de repetición activada y el hash del ledger intacto.

Total de los dos ciclos con inferencia: USD 0.045 de un piloto autorizado de USD 20.

Los guardarraíles que hacen tolerable la velocidad

La parte que me interesa compartir no es la velocidad. Es la lista de cosas que decidimos antes de encender el proceso, porque son las que hacen que trece segundos no sean trece segundos de riesgo.

El presupuesto se reserva antes de pensar. Cada ciclo escribe una reserva de USD 5 en un ledger durable antes de la primera inferencia. Si la reserva no cabe en el tope del piloto, el proceso no arranca. Al terminar, liquida al consumo calculado con el uso de tokens reportado por la API y las tarifas públicas del modelo. Si el resultado es incierto, conserva la reserva completa y bloquea el siguiente ciclo hasta que una persona concilie. Los límites internos son explícitos: máximo ocho turnos de modelo, veinte llamadas al conector, 2,048 tokens de salida, tiempo de espera de 120 segundos y ningún reintento automático. El modelo está fijado y no hay fallback silencioso: si cambia el precio o el modelo, alguien tiene que cambiarlo a mano.

Diagrama 7. Modelo de presupuesto del worker: reserva de cinco dólares antes de cada ciclo, verificación contra el tope del piloto de veinte dólares, liquidación al consumo calculado con tarifas públicas, y conservación de la reserva completa si el resultado es incierto. — Diagrama 7. El dinero se reserva antes de pensar, no después. Si el worker no puede demostrar cuánto gastó, el ledger asume que gastó la reserva entera y bloquea el siguiente ciclo hasta que una persona concilie.

Un ciclo por día y un solo proceso a la vez. Un cerrojo local impide dos ciclos simultáneos. La fecha local decide si ya hubo un ciclo; un segundo arranque devuelve el resultado anterior sin gastar. Un día sin candidatos nuevos termina sin inferencia y sin borradores vacíos, porque un borrador vacío creado por rutina también es ruido en el ERP.

Diagrama 8. Guardarraíles de repetición: un cerrojo local impide dos ciclos simultáneos; un ciclo por fecha local; un segundo arranque el mismo día devuelve el resultado anterior sin gastar; y un día sin candidatos nuevos termina sin inferencia ni borradores. — Diagrama 8. Lo que pasó el 12 de octubre con el tercer arranque: sin candidatos nuevos, sin inferencia, sin gasto y sin plantillas vacías. Un segundo clic ese mismo día devolvió el resultado anterior, con el hash del ledger intacto.

El conector no tiene botón de enviar. El servidor MCP dedicado expone seis herramientas de lectura y dos de borrador: crear y editar únicamente los borradores que creó el propio ciclo, con un máximo de diez destinatarios. No existe herramienta de envío, de programación, de borrado ni de modificación de contactos. No es una política escrita en un documento que el agente podría ignorar: es una ausencia en el código. El envío lo hace una persona, desde el ERP, después de revisar el lote.

Diagrama 9. Las dos capas de herramientas del conector: seis de lectura, más la creación y edición de borradores propios con tope de destinatarios; y la lista de lo que el conector no puede hacer: enviar, programar, borrar ni modificar contactos. — Diagrama 9. El conector no tiene botón de enviar. No es una política escrita en un documento: es una ausencia en el código. La velocidad del worker se vuelve tolerable porque lo irreversible no está a su alcance.

Cada afirmación tiene una lectura de vuelta. El worker no reporta "creé el borrador". Relee el registro, verifica que esté en estado borrador, cuenta los correos y las trazas asociadas y escribe esos ceros en el informe. Nosotros repetimos esas lecturas con consultas independientes antes de dar el ciclo por bueno. Un informe de agente es una hipótesis hasta que alguien la contrasta.

Las reglas comerciales también son código. Máximo cinco toques por persona, contados entre campañas y canales. Un lote lógico por día. Texto breve y con evidencia, sin fabricar cifras. Un lead que ya es oportunidad o cliente no entra en prospección fría. Estas reglas existían en nuestras skills como texto; ahora algunas viven en la guardia previa a cada escritura, que falla cerrado si no puede verificar el historial.

Qué demostró el piloto y qué no

Nos obligamos a hacer esta distinción antes de escribir el artículo, porque es muy fácil confundir capacidad técnica con resultado comercial.

Diagrama 10. Dos columnas: lo que el piloto demostró, como capacidad técnica de leer, decidir, escribir un borrador y parar bajo presupuesto, frente a lo que no demostró, como una audiencia comercial nueva, un envío real o la operación sin la computadora encendida. — Diagrama 10. La distinción que nos obligamos a hacer antes de escribir este texto. Un borrador vacío creado por una máquina es prueba de capacidad técnica, no un lote comercial elegible.

Demostró que un proceso autónomo puede leer el ERP con herramientas acotadas, decidir, escribir un borrador propio, releer su escritura, reservar y liquidar presupuesto, y detenerse solo cuando no hay trabajo. Todo eso con evidencia: manifiestos, ledger, lecturas de vuelta y pruebas automáticas, 219 del runtime y 13 del worker.

No demostró una audiencia comercial nueva y aprobada: la base no ofrecía candidatos elegibles ese día sin relajar criterios, y no los relajamos. No demostró un envío real a un prospecto; no lo hubo. No demostró operar con la computadora apagada ni en un servidor remoto. No demostró recibir ni clasificar respuestas; la lectura de salud del buzón no es ingesta. Y no demostró que la clave del modelo tenga un límite global de gasto: el ledger limita a este worker, no a otros programas que usen la misma clave.

Un borrador vacío creado por una máquina es prueba de capacidad técnica. No es un lote elegible, y no lo presentamos como tal.

La comparación honesta: horas contra segundos

Quiero ser cuidadoso con la cifra del título, porque es la que más se va a repetir.

Las tres a cinco horas son una estimación personal por prospecto, de principio a fin, incluida la llamada y la planificación de los toques siguientes. Los 13 y 15 segundos son telemetría por ciclo, reconstruida desde el ledger de presupuesto y el registro de uso por solicitud. Un ciclo no incluye la llamada previa ni la decisión de enviar, y en estas pruebas tampoco incluyó una audiencia real. No estamos comparando lo mismo con lo mismo, y preferimos decirlo a que lo descubra un lector atento.

Diagrama 11. Comparación honesta: el trabajo humano por toque, de tres a cinco horas, frente al ciclo de máquina, de trece a quince segundos; en medio, la decisión humana de enviar, que se conserva a propósito como el único cuello de botella. — Diagrama 11. No comparamos lo mismo con lo mismo y lo decimos. Las horas son estimación personal por prospecto; los segundos son telemetría por ciclo. Lo que queda entre ambos, la decisión de enviar, es el cuello de botella que queremos conservar.

Lo que sí cambia, y cambia de verdad, es dónde queda el cuello de botella. Antes el cuello de botella era mi tarde. Ahora el cuello de botella es una decisión: revisar un lote congelado y dar un VoBo. Esa decisión toma minutos, no horas, y es la única que queremos conservar, porque es la única irreversible.

Cuando vi el informe del segundo ciclo sentí algo que no esperaba sentir frente a un archivo de texto. Sentí miedo. No porque el proceso hubiera hecho algo malo, sino porque hizo algo correcto más rápido de lo que yo podía observarlo. Esa sensación es la que da origen a la última sección.

Qué opinamos en Transgenia

Este artículo no es neutral y conviene decirlo. Nuestra postura, para que la contrastes con la de cualquier otro proveedor:

Hay que tenerle respeto a la inteligencia artificial. No temor ni veneración: respeto en el sentido operativo, el que se le tiene a cualquier sistema capaz de actuar más rápido de lo que podemos supervisar. Los resultados del piloto ameritan ese respeto, y la respuesta madura al susto que producen es ingeniería, no entusiasmo.
Los límites se escriben antes de encender, no después del primer incidente. Presupuesto reservado, ciclo por día, cerrojo, tope de destinatarios y ausencia de envío son decisiones previas. Un guardarraíl que se agrega después de un error ya costó ese error.
Un agente que necesita una persona en cada paso no es un agente. Lo aprendimos con 48 días de silencio. La autonomía correcta es la que hace todo lo reversible sola y se detiene ante lo irreversible.
Lo irreversible lo decide una persona con nombre. En Transgenia el VoBo de cada lote lo firma el director general. No es un comité ni una regla de probabilidad: es alguien que mira el lote y responde por él.
Un informe de agente es una hipótesis. Cada afirmación del worker se contrasta con una lectura independiente antes de aceptarse. Si no podemos verificarlo, lo marcamos como no demostrado, como hicimos arriba.
La velocidad sin evidencia no vale nada. Trece segundos son una cifra interesante solo porque el ledger, los manifiestos y las lecturas de vuelta existen. Sin ellos, serían trece segundos de fe.

Diagrama 12. Modelo de respeto operativo a la inteligencia artificial en cinco pasos: del susto inicial a los límites escritos antes de encender, la evidencia por cada afirmación, la delegación con VoBo humano y la confianza ganada que permite ampliar permisos por evidencia. — Diagrama 12. Nuestra tesis en un dibujo. Respetar a la inteligencia artificial no es temerle ni venerarla: es tratarla como a cualquier sistema que actúa más rápido de lo que podemos supervisar, con límites previos, evidencia y una persona en el paso irreversible.

Fuentes

Los hechos técnicos sobre productos y protocolos se apoyan en fuentes públicas. Las cifras del piloto y del canal comercial son de Transgenia: provienen de nuestra bitácora de auditoría interna del 10 al 12 de octubre de 2026 y de nuestras revisiones semanales de agosto y septiembre, y se indican como tales.

Anthropic, referencia de la Messages API: la API con la que el worker local hace sus inferencias, con límite de tokens de salida por solicitud.
Anthropic, Claude Sonnet 5.5: el modelo fijado en el worker.
Anthropic, precios públicos de los modelos: USD 2 por millón de tokens de entrada y USD 10 por millón de salida para Sonnet 5.5, tarifas con las que el ledger calcula el gasto.
Anthropic, Managed Agents y su conector MCP: los agentes gestionados conectan herramientas mediante servidores MCP con URL remota y autenticación por sesión; la razón de la decisión de plataforma.
Model Context Protocol: el estándar abierto del conector hacia el ERP.
RFC 9051, IMAP4rev2: el comando EXAMINE abre un buzón en modo de solo lectura, como en la lectura de salud del runtime.
RFC 8446, TLS 1.3: el protocolo con el que se hizo esa lectura.
SQLite, transacciones atómicas: el motor del ledger durable del runtime; sus transacciones son atómicas y durables incluso ante un corte de energía.
Transgenia, Agentes IA para ventas B2B en México: el motion de demo y las reglas duras que este piloto hereda.
Transgenia, Cómo operamos con agentes de IA gobernados: el modelo de borrador primero y VoBo.
Transgenia, telemetría del piloto (ciclos del 12 de octubre de 2026, ledger de presupuesto, manifiestos y lecturas de vuelta) y revisiones semanales del canal comercial (semanas 35 y 36 de 2026): registros internos de la empresa, citados sin identificadores de registros ni datos de contactos.

Preguntas frecuentes

¿El agente envía correos solo?

No. El conector que usa el worker no tiene herramienta de envío, programación ni borrado. Puede leer el ERP y crear o editar sus propios borradores con un máximo de diez destinatarios. El envío lo hace una persona desde el módulo de correo masivo del ERP, después de revisar el lote y dar un VoBo explícito.

¿Qué significa exactamente "13 segundos"?

Es el tiempo entre la reserva de presupuesto y su liquidación en el segundo ciclo real del worker, reconstruido desde el ledger y el registro de uso por solicitud. Incluye dos inferencias, una escritura de borrador y las lecturas de verificación. No incluye la llamada previa, la revisión humana ni la decisión de enviar.

¿De dónde salen las tres a cinco horas?

Es la estimación personal del autor sobre el proceso manual completo de prospección de una cuenta: investigar, conseguir correos, llamar, redactar, curar, enviar y planificar los siguientes toques. No es telemetría y el artículo lo indica cada vez que la usa.

¿Cuánto costó el piloto?

Los dos ciclos con inferencia sumaron USD 0.045 calculados con el uso de tokens reportado por la API y las tarifas públicas de Sonnet 5.5, de un piloto autorizado de USD 20 con tope de USD 5 por ciclo. El tercer ciclo, sin candidatos nuevos, costó cero. No es una factura ni una verificación de saldo de la cuenta.

¿Por qué no usaron un agente gestionado en la nube?

Porque los agentes gestionados conectan sus herramientas mediante servidores MCP con URL remota y autenticación por sesión, y nuestro conector hacia el ERP corre en un contenedor local sin puertos expuestos. Sin un gate remoto persistente y autenticado, esa ruta no existe. Elegimos un proceso local y finito que arranca con un clic y termina solo.

¿Qué pasa si el worker falla a mitad de un ciclo?

El diseño es fail-closed. Si el resultado es incierto, el ledger conserva la reserva completa de presupuesto y bloquea el siguiente ciclo hasta que una persona concilie. No hay reintentos automáticos ni fallback de modelo. Un cerrojo abandonado por una caída requiere confirmar que no hay proceso activo antes de recuperarlo a mano.

¿Esto ya funciona con la computadora apagada?

No. El worker necesita la computadora, Node y el contenedor del conector encendidos. No está instalado como servicio ni como tarea programada, y no hay despliegue remoto. Es una limitación conocida y documentada; migrarlo a un ejecutor remoto requiere primero un gate autenticado y una medición de capacidad.

¿Qué quieren decir con "respeto a la inteligencia artificial"?

Respeto operativo, no temor ni veneración: tratar a un sistema que actúa más rápido de lo que podemos supervisar con límites escritos antes de encenderlo, evidencia por cada afirmación y una persona que decide el único paso irreversible. Es la misma disciplina que se le exige a cualquier automatización con acceso a producción.

Sobre el autor y Transgenia

Efraín Carreón Ortiz es Director General de Centrum Transgenia, una boutique tecnológica mexicana, y lleva la mayor parte de las ventas de la empresa. Está acreditado con la insignia oficial Claude Code (Claude Partner Badge) emitida por Anthropic, verificable en Credly.

Transgenia es OpenAI Select Partner dentro del OpenAI Partner Network y partner registrado en el Claude Partner Network de Anthropic. Equipo: Víctor Estrada Bello, Chief PMO; Danild Johan Zambrana López, Chief Technology Officer; Jaime Lozano Castañeda, Chief Marketing Officer; Efraín Carreón Ortiz, Director General (Chief Executive Officer).

Hablemos: contacto@transgenia.org, WhatsApp +52 55 8034 0405, agenda de 15 minutos o la página de contacto.

Sigue leyendo

Agentes IA para ventas B2B en México: cómo diseñamos un SDR gobernado: el motion de demo, las reglas duras y la meta del semestre que este piloto hereda.
Cómo Transgenia opera con agentes de IA gobernados: el modelo de borrador primero y VoBo que exigimos a cualquier integración.
¿Quién integra Claude o ChatGPT con Odoo en México? Guía para contratar: qué exigir por escrito a cualquier proveedor, incluida Transgenia.
Inventario de infraestructura MCP: el mapa de conectores y permisos que hicimos antes de este piloto.
Qué aislar antes de probar un agente con una copia de Odoo: la prueba segura previa a cualquier escritura.
Publicamos MCP-Odoo-Tools: el servidor MCP de código abierto del que deriva el conector acotado.
Implementación de IA e integración con Odoo: la oferta y el formulario para solicitar una evaluación.