Randall Newman, CPTO y cofundador de Satisfi Labs – Serie de entrevistas

Randall Newman, CPTO y cofundador de Satisfi Labs, es un líder tecnológico y de producto con amplia experiencia construyendo plataformas de IA, tecnología financiera y sistemas de alto rendimiento. Desde que cofundó Satisfi Labs, Newman ha desempeñado un papel central en la visión, el diseño y la ampliación de la tecnología de IA conversacional de la empresa, mientras supervisaba el desarrollo de productos, la arquitectura, los equipos de ingeniería y las integraciones estratégicas. Antes de Satisfi Labs, se desempeñó como Jefe de Producto en Satisfi Inc. y cofundó la empresa de marketing móvil Right On Mobile. En una etapa anterior de su carrera, Newman pasó más de 17 años en CIBC World Markets, donde ocupó cargos de alta dirección que abarcaban riesgo estratégico, negociación de alta frecuencia y arbitraje de acciones, combinando experiencia en trading cuantitativo con desarrollo tecnológico práctico.

Satisfi Labs es una empresa de IA centrada en desplegar agentes de IA especializados para deportes, entretenimiento, turismo, atracciones y otros negocios de experiencias en vivo. Fundada en 2016, la compañía ha evolucionado desde la IA conversacional y su Answer Engine hacia una plataforma agente diseñada para ayudar a las organizaciones a automatizar la asistencia a clientes, aumentar las conversiones de entradas y comercio, y extraer información de las conversaciones con los clientes. Sus agentes de IA pueden operar en más de 50 idiomas y conectarse con sistemas de venta de entradas, CRM, gestión de contenidos y otros sistemas empresariales para realizar acciones como vender entradas, escalar conversaciones al personal humano, recopilar información del cliente y ofrecer respuestas personalizadas. Satisfi Labs afirma que su tecnología ahora es confiada por más de 775 marcas, con integraciones y asociaciones que abarcan empresas como Ticketmaster, Simpleview, MappedIn, Ventrata y Vozzi.

Pasaste casi dos décadas en los mercados financieros, incluyendo la construcción de sistemas de negociación de baja latencia y la dirección de estrategias de trading de alta frecuencia en CIBC, antes de pasar al emprendimiento tecnológico y, finalmente, cofundar Satisfi Labs. ¿Qué lecciones de los sistemas operativos, donde la velocidad, la fiabilidad y la gestión de riesgos eran críticas, han influido más en la forma en que construyes agentes de IA de nivel de producción hoy?

El trading me enseñó que una buena idea y un buen negocio son dos cosas diferentes. Puedes identificar una oportunidad correctamente y aun así perder dinero porque tu ejecución es lenta, tus costos son demasiado altos o tus supuestos de riesgo son erróneos. La IA es lo mismo. La capacidad del modelo es un insumo. El negocio depende de si puedes convertir esa capacidad en un resultado repetible a un costo y riesgo aceptables.

Gestionar un libro de arbitraje de índices también enseña a mirar más allá de decisiones individuales. Un pequeño error repetido en una cartera se convierte en una exposición muy grande. Con la IA, puedes tener miles de agentes tomando decisiones individualmente razonables que, en conjunto, generan un problema. Todos dependen de los mismos datos erróneos, o todos reintentan el mismo servicio fallido. Debes gestionar el sistema, no solo la respuesta individual.

Y la velocidad solo importa cuando mejora el resultado. En el trading hubo momentos en los que los microsegundos eran decisivos. En IA, prefiero dedicar un segundo más a confirmar una transacción que entregar el resultado incorrecto al instante. La disciplina consiste en saber dónde la velocidad crea valor y dónde solo acelera un error.

La última lección es la que inició todo el negocio. La ventaja proviene de detectar una mala valoración antes que los demás. Creo que la mala valoración actual es que la mayoría de las empresas ven a los agentes de IA como una forma de reducir costos de soporte. En Satisfi Labs, los vemos como un canal de ingresos. En nuestros recintos deportivos, alrededor del 40 % de las conversaciones de los agentes se centran en entradas. Estos aficionados no vienen a quejarse. Llegan con dinero en mano, preguntando dónde sentarse. Encuentra lo que el mercado está valorando incorrectamente y ve a capturarlo. Es el mismo instinto que el negocio de arbitraje.

Satisfi Labs se fundó en 2017, mucho antes del actual auge de la IA generativa, y ha evolucionado desde el procesamiento contextual del lenguaje natural y la IA conversacional hacia una plataforma agente. ¿Cuáles fueron los mayores cambios arquitectónicos necesarios para pasar de sistemas diseñados principalmente para responder preguntas a agentes capaces de realizar acciones en nombre de los usuarios?

Pasamos una década construyendo miles de agentes de IA para más de 800 clientes empresariales, incluidos equipos de MLB/NFL, recintos de entretenimiento y organizaciones turísticas. El mayor cambio es que le estás otorgando al sistema autoridad, no solo información.

Si un asistente te indica qué entradas están disponibles, está proporcionando una respuesta. Si intercambia tus entradas, está modificando el inventario, los registros de clientes y potencialmente el dinero. Ahora necesitas saber quién autorizó la acción, qué ocurrió realmente y cómo recuperarse si el proceso se detiene a mitad de camino.

Por lo tanto, separamos el juicio del modelo de la autoridad para ejecutar. El modelo puede interpretar una solicitud y proponer el siguiente paso. Los sistemas subyacentes imponen permisos, reglas de negocio y límites de transacción. Una explicación persuasiva del modelo no puede anular esos controles.

También necesitas una distinción clara entre “el agente dijo que completó la tarea” y “el sistema empresarial confirmó la finalización”. No son lo mismo. Si una solicitud de compra se agota el tiempo, será mejor averiguar si la compra se realizó antes de intentarlo de nuevo.

Y estratégicamente, los modelos mejores no deberían obligarte a reconstruir tus controles de negocio. Quiero aprovechar cada mejora en razonamiento sin renegociar lo que el sistema puede hacer cada vez que se lanza un modelo nuevo.

El término “IA agente” ahora se aplica a una amplia gama de productos. Desde una perspectiva de ingeniería, ¿dónde trazas la línea entre un chatbot avanzado, un copiloto de IA y un agente de IA verdaderamente autónomo?

Yo haría una pregunta: ¿qué responsabilidad ha delegado realmente la persona?

Un chatbot brinda información. Un copiloto te ayuda a realizar el trabajo, pero tú sigues dirigiendo y aprobando los pasos importantes. Un agente autónomo tiene permiso para tomar algunas de esas decisiones por sí mismo mientras persigue un objetivo.

La interfaz no te indica cuál estás viendo. Un producto conversacional puede tener autonomía real detrás. Algo comercializado como agente aún puede requerir que una persona apruebe cada acción útil.

Para una empresa, la autonomía debe ser un acuerdo específico: este sistema puede ejecutar estas acciones, para estos usuarios, dentro de estos límites, y debe detenerse bajo estas condiciones. Eso es algo que realmente puedes probar y gobernar.

Yo tampoco haría de la autonomía máxima el objetivo. A veces el mejor producto formula una pregunta bien cronometrada y se encarga del resto. Eliminar esa pregunta hace la demostración más impresionante y el negocio menos seguro. El objetivo es eliminar el trabajo humano innecesario, no el juicio humano necesario.

Satisfi Labs lanzó recientemente Satisfi Forward, una práctica de ingeniería desplegada de forma adelantada. ¿Qué brecha observabas entre construir una plataforma de IA capaz y lograr que los agentes funcionaran de manera fiable dentro del entorno real de un cliente, que te llevó a crear este modelo?

La última milla se estaba convirtiendo en el cuello de botella. Una plataforma puede estandarizar mucho, pero no puede asumir que el negocio de cada cliente funciona de la misma manera. Su sistema de tickets tiene ciertas limitaciones. Su proceso de aprobación pasa por tres departamentos. Su definición de cliente potencial calificado difiere de la del siguiente cliente. Esos detalles deciden si la implementación es realmente útil.

Puedes comprar una plataforma lista para usar y armar una demostración que impresione a la gente. Comercializarla como una experiencia robusta para usuarios reales es diferente. Ahí es donde entran los ingenieros desplegados de forma adelantada. El trabajo de nuestro equipo en Satisfi Forward es entender el resultado, averiguar qué lo está bloqueando y construir los flujos de trabajo y las integraciones sobre la plataforma que lo hagan posible.

Pero establecemos límites claros en cada compromiso. Antes de construir, acordamos qué significa el éxito, quién es el propietario del proceso de negocio, qué depende del cliente y quién lo mantiene después del lanzamiento. De lo contrario, un proyecto de última milla se convierte en una obligación ilimitada. Y el compromiso no termina cuando el código se entrega. Termina cuando el flujo de trabajo funciona en la operación del cliente y alguien es responsable de mantenerlo en funcionamiento.

El código también se ha vuelto mucho más barato de producir, lo que hace que este modelo sea mucho más práctico que antes. Pero no veo a Satisfi Forward como un brazo de servicios añadido a un producto SaaS. Cada compromiso nos enseña cuál debería ser el próximo producto. Cuando tres clientes solicitan el mismo flujo de trabajo, eso no es una carga de soporte. Eso es la propia hoja de ruta, con clientes que pagan adjuntos. El antiguo modelo SaaS adivinaba las funciones y esperaba la evidencia. De esta manera obtenemos la evidencia primero y los ingresos mientras la recopilamos. Creo que así se construyen las empresas de productos en la era de la IA.

Tus agentes pueden conectarse con sistemas de tickets, plataformas de gestión de relaciones con clientes, sistemas de gestión de contenidos y otras fuentes de información en tiempo real. A medida que los agentes adquieren la capacidad de realizar transacciones y desencadenar acciones, ¿cómo equilibras el acceso a datos en tiempo real y la baja latencia con la fundamentación, la seguridad y las salvaguardas contra acciones incorrectas?

Primero, nunca permitiría que la velocidad compense una falla de seguridad. Algunos requisitos son restricciones. Optimizas dentro de ellas.

Luego distingues entre tipos de trabajo. Responder una pregunta sobre estacionamiento y completar la compra de un ticket no requieren la misma frescura de datos ni los mismos controles. Puedes almacenar en caché información estable. Cuando se manejan dinero, necesitas que el sistema de transacciones autoritativo confirme el precio, la disponibilidad y la finalización.

Los casos peligrosos son los que el sistema no sabe qué ocurrió. Un backend acepta una compra, pero la respuesta nunca llega. Si el agente asume un fallo y reintenta, terminas con dos compras. No es un problema de lenguaje. Es un problema de recuperación de transacciones.

Y mides la experiencia bajo las condiciones que realmente importan. La latencia promedio en un martes tranquilo no te dice casi nada. Si un evento se cancela por lluvia, de repente tienes miles de personas preguntando qué pasa con sus tickets, todas a la vez. Si solo planificas en torno al tráfico promedio por minuto, perderás la capacidad que necesitas en ese pico. Aprendí eso directamente de los sistemas de negociación.

También hay una decisión de costo aquí. No todas las solicitudes requieren el modelo más caro o una cadena de agentes. Utiliza el camino más sencillo que cumpla con el requisito y dedica el tiempo o cómputo adicional donde mejore materialmente la decisión. El usuario debe obtener un resultado honesto, incluida una declaración honesta de que algo no pudo ser confirmado.

Satisfi Labs describe un modelo en el que agentes especializados pueden operar juntos como una fuerza laboral de IA. ¿Cuáles son los problemas técnicos más difíciles involucrados en la orquestación de múltiples agentes especializados, particularmente en cuanto al enrutamiento, contexto compartido, decisiones conflictivas y la determinación de qué agente debe actuar?

La parte más difícil es mantener la responsabilidad a medida que distribuyes el trabajo.

Comienza preguntándote si realmente necesitas otro agente. A veces necesitas un especialista. Otras veces solo necesitas una llamada a una herramienta o un flujo de trabajo simple. Cada agente que añades es otra interpretación de la solicitud, otra dependencia, otro punto donde puede producirse un error. Y la cantidad de agentes que se ejecutan detrás de escena debería ser invisible para el usuario.

Cuando varios agentes están justificados, quiero que un solo agente sea responsable de la interacción. Los especialistas pueden proporcionar información o realizar trabajos delimitados. Un agente de emisión de entradas gestiona el inventario y los intercambios, un agente de atención al cliente gestiona las políticas. Pero alguien tiene que reconciliar los resultados y decidir si el usuario realmente obtuvo lo que buscaba.

El enrutamiento es difícil porque las personas no hacen preguntas en categorías ordenadas. Una solicitud puede involucrar a tres agentes. El sistema debe decidir: ¿puede uno manejarla, varios deben ejecutarse en secuencia, o debería preguntar al usuario una pregunta más antes de hacer cualquier cosa?

Lo mismo ocurre con el contexto. No envías todo a cada agente. Eso añade latencia, genera ruido y puede exponer información que un agente no necesita. Y la suposición de un agente no debe convertirse en un hecho solo porque se haya pasado al siguiente agente.

Si dos agentes discrepan, no quiero que discutan hasta que uno parezca más convincente. Debe haber un modelo de autoridad claro. El sistema de emisión de entradas establece la disponibilidad. La empresa establece la política de intercambio. Los datos en tiempo real superan a los datos en caché, las reglas de negocio superan el juicio del modelo, y si aún no se puede resolver, se le pregunta al usuario o se involucra a una persona. La parte difícil no es lograr que los agentes se comuniquen entre sí, sino poder reconstruir exactamente qué agente hizo qué y dónde recayó la responsabilidad.

Satisfi Labs se ha centrado cada vez más en medir a los agentes en función de los objetivos y resultados empresariales en lugar de métricas como el volumen de conversaciones. ¿Qué deberían medir realmente las empresas para determinar si un agente de IA está funcionando bien, y cómo evalúan la fiabilidad antes de permitir que un agente tenga mayor autonomía?

Comienza con el resultado empresarial, luego pregunta cuánto de ese resultado fue realmente causado por el agente.

Si alguien compra entradas después de hablar con un agente, eso no significa automáticamente que el agente haya generado la venta. Puede que haya comprado de todos modos. Cuando sea posible, se desean comparaciones controladas o una línea base creíble, no solo atribuir el crédito a la última interacción. Para un cliente de emisión de entradas, eso significa medir si el fan terminó con asientos, no si el agente respondió cortésmente. Para un recinto que intenta reducir las colas en la taquilla, significa medir lo que el agente resolvió antes de que alguien tuviera que hacer fila.

Luego analiza la economía de un resultado exitoso: costos del modelo, infraestructura, revisión humana, escaladas y el costo de corregir errores. Un agente que parece barato hasta que contabilizas a las personas que reparan su trabajo no es barato.

La fiabilidad necesita su propia tarjeta de puntuación. Finalización, exactitud, acciones no autorizadas, recuperación de fallas, calidad de escalada. No se promedia un incidente grave de privacidad dentro de una buena tasa de conversión.

Para mayor autonomía, exigiría evidencia sobre la clase específica de acción que se delega. Pruébalo, obsérvalo bajo supervisión, expándelo dentro de límites y mantén una forma de detenerlo. Una buena puntuación de precisión general no demuestra que el sistema esté listo para cada transacción. Y ten cuidado con los incentivos. A veces, involucrar a una persona es el resultado correcto. Si recompensas al agente solo por evitar transferencias, no te sorprendas si mantiene problemas que debería haber escalado.

Recientemente argumentaste que la IA de voz debe diseñarse en torno a resultados medibles en lugar de tratarse como otra interfaz para un chatbot existente. ¿Qué avances técnicos aún se necesitan antes de que los agentes de voz puedan convertirse en una interfaz principal para interacciones complejas y en tiempo real, particularmente en entornos como estadios, atracciones y eventos en vivo?

Muchos clientes preguntan, ¿pueden simplemente tomar la aplicación de chat e incorporar voz? Podemos. Pero eso no significa que sea una buena experiencia. La próxima mejora real no es una voz que suene más humana. Es una interacción que sobreviva a las condiciones en que realmente la gente la usa.

En un estadio, alguien habla sobre el ruido de la multitud, usa el nombre de un jugador desconocido, cambia de opinión a mitad de una frase y trata de terminar una compra antes de que se abran las puertas. El sistema debe manejar interrupciones, incertidumbre y retrasos del backend sin perder la tarea.

Preste especial atención a los detalles críticos. Malinterpretar una frase casual es una cosa. Malinterpretar el número de entradas o la fecha del evento es otra. El agente debe confirmar los detalles que cambian la consecuencia de la acción sin volver tediosa toda la conversación.

Y la voz no debería ser obligada a hacerlo todo. Comparar veinte opciones de asientos es mejor en una pantalla. Alguien podría comenzar escribiendo, subir al coche y querer mantener la misma conversación hablando. El sistema debe preservar ese contexto y usar voz, texto y elementos visuales según lo que mejor se ajuste al momento.

Algunas de estas cosas necesitan mejores modelos. Muchas requieren una mejor integración y diseño de interacción. Esperar un avance no solucionará un flujo de trabajo que se diseñó alrededor del texto y luego se lee en voz alta. Yo evaluaría el progreso de esta manera: ¿las personas completan la tarea con precisión, con menos esfuerzo, bajo condiciones reales?

A medida que los agentes pasan de proporcionar información a vender entradas, recopilar datos de clientes, personalizar experiencias e interactuar con sistemas operacionales, ¿cómo deberían las empresas determinar qué decisiones puede tomar un agente de forma autónoma y cuáles siempre deben requerir supervisión humana?

Se trata de gestión de riesgos. Si esto se sale de control, ¿qué daño puede causar? ¿El agente abre una puerta que no puede cerrar?

La reversibilidad es una prueba inicial útil, pero también hay que considerar la exposición total. Un reembolso puede ser pequeño y reversible. Diez mil reembolsos incorrectos antes de que alguien se dé cuenta es un problema diferente. Necesita límites tanto en acciones individuales como en la actividad acumulada del sistema.

Si la acción es de bajo riesgo y reversible, otorgue más autonomía: actualizar una preferencia, verificar un pedido, retener un artículo. A medida que aumentan las consecuencias, añada confirmación o aprobación. Una compra podría requerir que el cliente confirme el precio. Un reembolso grande podría necesitar la firma de un empleado. Una amenaza de seguridad se escala de inmediato. Y algunas decisiones deben quedarse simplemente con una persona, punto.

El consentimiento del cliente y la aprobación de la empresa son cosas diferentes, por cierto. Que un cliente confirme una compra no autoriza al agente a eludir la política de la empresa. Que un empleado apruebe una excepción no significa que el cliente haya aceptado un cargo.

Los límites deben ser aplicados por los sistemas que ejecutan la acción, no solo descritos en un prompt. No se le da a un agente acceso amplio y luego se confía en que un prompt le indique que sea cuidadoso. Y cuando se requiere a una persona, proporciónele suficiente contexto para tomar una decisión real. Dar a alguien cientos de aprobaciones sin información es crear un sello de goma, no supervisión. Dirija la atención humana donde reduzca riesgos significativos. No la disperse en cada interacción.

Mirando hacia el futuro, ¿espera que tecnologías como el Protocolo de Contexto de Modelo y la comunicación agente‑a‑agente cambien fundamentalmente la forma en que se construyen los sistemas de IA empresarial, pasando de agentes aislados a ecosistemas en los que los agentes pueden descubrir herramientas, intercambiar contexto y coordinar acciones entre empresas y plataformas?

Creo que los protocolos son un medio para un fin. MCP brinda a las aplicaciones de IA una forma común de acceder a herramientas y contexto. Los protocolos agente‑a‑agente gestionan la cooperación entre agentes. Eso es valioso. No debería ser necesario crear una integración personalizada cada vez que un agente necesita una herramienta. Es similar a lo que hicieron las API para las integraciones de software.

Pero un formato común no significa que dos empresas estén de acuerdo sobre lo que significa una acción, quién puede autorizarla o qué ocurre cuando falla. El hecho de que un agente pueda descubrir una herramienta no implica que deba estar permitido usarla. Aún hay que resolver identidad, permisos, confianza y responsabilidad. Si un agente le pide a otro que haga algo y sale mal, ¿quién asume esa decisión?

Esto es lo que realmente cambia, según mi opinión. Hoy, un recinto tiene un sitio web y una aplicación. En unos años, tendrá un agente con el que negociarán otros agentes. El asistente personal de un fan solicita al agente del recinto dos asientos a cierto precio, más un pase de estacionamiento, y toda la transacción ocurre entre los dos agentes. Encontrar las capacidades adecuadas es el paso fácil. Conocer la autoridad de gasto del cliente, confirmar el precio combinado y manejar el caso en que las entradas se confirmen pero el estacionamiento falle, esos son los problemas reales.

Y no creo que operar un agente automáticamente le entregue la relación con el cliente. Eso hay que ganárselo. Pero tampoco creo que los recintos entreguen estas transacciones a una empresa de búsqueda o a un mercado de entradas. Nuestro objetivo en Satisfi Labs es ser el agente que representa al recinto en esa economía, el suficientemente fiable como para que una empresa ponga su nombre en él. Todo lo que hemos construido en torno a la fiabilidad, los permisos y la responsabilidad es lo que nos gana ese asiento.

Gracias por la excelente entrevista; los lectores que deseen saber más deberían visitar Satisfi Labs.