Roxy naci\u00f3 de una idea que nos entusiasmaba desde hac\u00eda tiempo: construir un agente de inteligencia artificial que pudiera fungir como administrador de Zherpa. No quer\u00edamos otro chatbot corporativo capaz de responder preguntas sobre la empresa o consultar una base de conocimiento. Quer\u00edamos que pudiera trabajar dentro de nuestros procesos, consultar informaci\u00f3n actualizada, interactuar con nuestros sistemas y ejecutar determinadas tareas administrativas bajo reglas, permisos y l\u00edmites definidos.<\/p>\n
La ambici\u00f3n iba m\u00e1s all\u00e1 de resolver una necesidad interna. Si logr\u00e1bamos construir una Roxy capaz de trabajar realmente dentro de Zherpa, podr\u00edamos aprender qu\u00e9 requer\u00eda un agente administrativo de verdad y, eventualmente, convertir ese conocimiento en una capacidad que pudi\u00e9ramos llevar a otras empresas.<\/p>\n
El proyecto reun\u00eda muchas de las disciplinas en las que llevamos a\u00f1os trabajando: arquitectura de procesos de negocio, Zoho, CRM, automatizaci\u00f3n, integraciones y desarrollo. A todo eso se sumaba una tecnolog\u00eda que estaba cambiando r\u00e1pidamente: modelos de lenguaje capaces de utilizar herramientas, agentes que pueden participar en procesos y protocolos como MCP, que empiezan a crear una forma estandarizada para que esos agentes se comuniquen con sistemas empresariales.<\/p>\n
As\u00ed que nos fuimos al laboratorio. Programamos en Node.js un servidor MCP para conectar ChatGPT con Zoho Books. Desarrollamos las herramientas que Roxy necesitaba para consultar informaci\u00f3n y ejecutar determinadas acciones. Investigamos APIs, autenticaci\u00f3n, permisos, reglas de negocio, validaciones, seguridad y mecanismos de supervisi\u00f3n humana. Cada avance abr\u00eda nuevas preguntas y cada respuesta requer\u00eda m\u00e1s investigaci\u00f3n, c\u00f3digo y pruebas.<\/p>\n
Invertimos muchas horas. Tambi\u00e9n muchos tokens. Nos equivocamos, corregimos, volvimos a probar y seguimos construyendo hasta conseguir algo que, desde el punto de vista de ingenier\u00eda, era fascinante: funcionaba. Roxy pod\u00eda comunicarse con Zoho Books y utilizar las herramientas que hab\u00edamos construido para trabajar con informaci\u00f3n real del sistema. Hab\u00edamos conseguido que un agente conversacional comenzara a convertirse en algo diferente: un agente capaz de interactuar con una plataforma empresarial.<\/p>\n
Como laboratorio de ingenier\u00eda y arquitectura, fue extraordinario. El problema apareci\u00f3 cuando dejamos de preguntarnos qu\u00e9 m\u00e1s pod\u00edamos lograr t\u00e9cnicamente y nos hicimos una pregunta bastante menos emocionante: \u00bfqui\u00e9n va a pagar por todo esto?<\/strong><\/p>\n Ser\u00eda incorrecto decir que construir aquella primera arquitectura de Roxy fue simplemente un error. Como ejercicio de ingenier\u00eda, investigaci\u00f3n y aprendizaje, fue tremendamente valioso. Necesit\u00e1bamos ensuciarnos las manos con MCP, entender c\u00f3mo se comportaban los agentes frente a herramientas reales, descubrir los problemas de autenticaci\u00f3n y permisos, experimentar con controles y comprobar qu\u00e9 sucede cuando un modelo deja de limitarse a generar texto y comienza a interactuar con sistemas empresariales.<\/p>\n Hay conocimiento que puedes obtener leyendo documentaci\u00f3n y hay otro que s\u00f3lo aparece cuando intentas hacer que las cosas funcionen. Nosotros necesit\u00e1bamos ambos. La satisfacci\u00f3n de lograrlo tampoco era trivial. Quienes disfrutamos la ingenier\u00eda conocemos perfectamente ese momento en el que algo que durante d\u00edas s\u00f3lo exist\u00eda como arquitectura, c\u00f3digo, errores y pruebas finalmente funciona. No considero que esas horas hayan sido desperdiciadas.<\/p>\n El error apareci\u00f3 en otro lugar. Apareci\u00f3 cuando comenzamos a mirar aquel desarrollo no solamente como laboratorio, sino como inversi\u00f3n de negocio. Si aquello iba a convertirse en una capacidad permanente de Zherpa y, eventualmente, en algo que pudi\u00e9ramos ofrecer comercialmente, entonces la evaluaci\u00f3n ten\u00eda que cambiar por completo.<\/p>\n Ya no bastaba con preguntar si pod\u00edamos construirlo. Hab\u00eda que preguntar cu\u00e1nto costar\u00eda terminarlo, mantenerlo, protegerlo y evolucionarlo; qu\u00e9 parte de esa infraestructura seguir\u00eda siendo necesaria dentro de uno o dos a\u00f1os; qu\u00e9 problema comercial resolv\u00eda; qui\u00e9n estar\u00eda dispuesto a pagar por \u00e9l y, sobre todo, qu\u00e9 retorno justificaba que Zherpa siguiera absorbiendo ese costo.<\/p>\n Fue entonces cuando otra pieza comenz\u00f3 a cambiar nuestra manera de ver la arquitectura.<\/p>\n Mientras profundiz\u00e1bamos en Roxy comenzamos a observar algo que para nosotros era mucho m\u00e1s importante que encontrar una funci\u00f3n nueva dentro de Zoho Books.<\/p>\n Durante a\u00f1os hemos trabajado con plataformas que incorporan capacidades de automatizaci\u00f3n y, m\u00e1s recientemente, inteligencia artificial. El modelo habitual consiste en que el propio software ofrece sus funciones de IA: asistentes, predicciones, generaci\u00f3n de contenido, automatizaciones inteligentes o agentes que viven dentro del ecosistema del fabricante.<\/p>\n Pero lo que empezamos a observar iba un paso m\u00e1s all\u00e1. Zoho no s\u00f3lo estaba incorporando IA y agentes dentro de sus productos. Estaba creando mecanismos para que otros agentes pudieran comunicarse con sus sistemas<\/strong>.<\/p>\n Esa diferencia puede parecer t\u00e9cnica, pero para nosotros es estrat\u00e9gica. No es lo mismo una plataforma que contiene inteligencia artificial que una plataforma dise\u00f1ada para participar en un ecosistema donde distintas inteligencias pueden utilizarla como sistema de trabajo. Zoho Books dispone actualmente de un servidor MCP para conectar la aplicaci\u00f3n con modelos y agentes compatibles, una se\u00f1al relevante para quienes dise\u00f1amos arquitecturas alrededor de su ecosistema.<\/p>\n Si esa direcci\u00f3n contin\u00faa desarroll\u00e1ndose, el papel de una firma como Zherpa cambia de una manera interesante: quiz\u00e1 no necesitemos construir y mantener tantos puentes propietarios para que nuestros agentes entren a Zoho, porque el propio ecosistema est\u00e1 comenzando a construir puertas para que los agentes puedan entrar de manera estructurada.<\/p>\n Eso modific\u00f3 nuestra perspectiva sobre Roxy. Hab\u00edamos empezado construyendo parte de la infraestructura necesaria para conectar un agente con Zoho. Mientras lo hac\u00edamos, comprendimos que Zoho estaba avanzando hacia una arquitectura en la que esa comunicaci\u00f3n podr\u00eda formar parte cada vez m\u00e1s de la propia plataforma.<\/p>\n No era simplemente que \u201cZoho ya hac\u00eda lo mismo que Roxy\u201d. Eso no habr\u00eda sido cierto. Lo importante era que estaba cambiando el lugar donde ten\u00eda sentido que nosotros invirti\u00e9ramos nuestro esfuerzo<\/strong>.<\/p>\n Tampoco salimos de esta experiencia pensando que hab\u00edamos descubierto una filosof\u00eda completamente nueva para Zherpa. Despu\u00e9s de tantos a\u00f1os implementando sistemas empresariales, siempre hemos sabido que antes de desarrollar hay que entender el proceso, estudiar la plataforma y aprovechar correctamente las capacidades existentes.<\/p>\n Lo que Roxy hizo fue obligarnos a aplicar ese principio con una disciplina mucho mayor en el contexto de la inteligencia artificial. La secuencia se volvi\u00f3 m\u00e1s clara. Primero tenemos que entender qu\u00e9 necesita realmente el negocio. Despu\u00e9s investigar hasta d\u00f3nde llega la plataforma existente y hacia d\u00f3nde est\u00e1 evolucionando. Luego configurar y aprovechar sus capacidades nativas. Despu\u00e9s integrar cuando existe una raz\u00f3n para hacerlo. Y s\u00f3lo cuando queda una brecha suficientemente importante, diferenciadora y econ\u00f3micamente justificable tiene sentido asumir el costo de desarrollar y mantener algo propio.<\/p>\n No cambiamos nuestra consultor\u00eda. La afinamos. Tampoco dejamos de experimentar. Al contrario: necesitamos experimentar m\u00e1s que antes porque las plataformas est\u00e1n evolucionando demasiado r\u00e1pido como para asesorar desde la teor\u00eda. Pero ahora tenemos m\u00e1s claridad sobre la frontera que separa el laboratorio de la inversi\u00f3n.<\/p>\n En el laboratorio podemos construir algo simplemente porque necesitamos saber si funciona y qu\u00e9 podemos aprender haci\u00e9ndolo. En el negocio necesitamos una raz\u00f3n adicional: alguien tiene que recibir suficiente valor de aquello como para justificar su costo<\/strong>.<\/p>\n Tiempo despu\u00e9s estaba contando esta historia al director general de una empresa cliente. No estaba presentando a Roxy como un caso de \u00e9xito ni tratando de maquillar el recorrido. Le expliqu\u00e9 que hab\u00edamos invertido muchas horas investigando y desarrollando capacidades para despu\u00e9s concluir que una parte de aquella arquitectura no deb\u00eda convertirse en infraestructura permanente.<\/p>\n Su reacci\u00f3n fue perfectamente razonable: \u201c\u00bfPero eso tambi\u00e9n les sucede a ustedes, que son los expertos?\u201d<\/p>\n La respuesta fue s\u00ed. Por supuesto que nos sucede. Y le contest\u00e9 algo que desde entonces me parece una buena explicaci\u00f3n de una parte del valor de nuestro trabajo: a nosotros probablemente nos sucede con mayor frecuencia de la que deber\u00eda sucederte a ti.<\/strong><\/p>\n No porque equivocarse sea deseable ni porque debamos celebrar una mala inversi\u00f3n. Nos sucede porque para nosotros explorar forma parte del trabajo. Tenemos que probar tecnolog\u00edas antes de recomendarlas, entender nuevas capacidades de Zoho, experimentar con agentes, descubrir sus l\u00edmites, construir prototipos y averiguar qu\u00e9 ideas sobreviven cuando dejan la presentaci\u00f3n comercial y entran a un proceso real.<\/p>\n Eso tiene un costo. Lo pagamos en horas de especialistas, investigaci\u00f3n, desarrollo, infraestructura, pruebas y, cada vez m\u00e1s, tokens. Algunas veces tambi\u00e9n lo pagamos con c\u00f3digo perfectamente funcional que terminamos descartando porque aprendimos que no ten\u00eda sentido convertirlo en una obligaci\u00f3n permanente.<\/p>\n Ese costo de exploraci\u00f3n forma parte de nuestro negocio. Una parte del valor de nuestra experiencia consiste precisamente en que nuestros clientes no tengan que volver a pagarlo desde cero<\/strong>.<\/p>\n Roxy nos ayud\u00f3 tambi\u00e9n a separar dos inversiones que con frecuencia se mezclan. La primera es el costo de descubrir. Experimentas, pruebas alternativas, construyes prototipos y aceptas que parte de ese trabajo terminar\u00e1 descart\u00e1ndose. Su retorno es conocimiento. En una empresa como Zherpa, ese conocimiento tiene valor porque mejora las decisiones posteriores y se acumula en nuestra pr\u00e1ctica.<\/p>\n La segunda inversi\u00f3n es completamente distinta: decidir que aquello que descubriste debe convertirse en producto, infraestructura o capacidad permanente. En ese momento ya no basta con que algo sea t\u00e9cnicamente interesante. Hay que saber qui\u00e9n lo necesita, qu\u00e9 problema resuelve, cu\u00e1nto est\u00e1 dispuesto a pagar por resolverlo, qu\u00e9 costos recurrentes tendr\u00e1, cu\u00e1nto mantenimiento requerir\u00e1 y qu\u00e9 alternativas existen.<\/p>\n Un prototipo puede ser un \u00e9xito extraordinario de ingenier\u00eda y un p\u00e9simo negocio. No existe contradicci\u00f3n entre ambas afirmaciones. Nuestro primer Roxy nos dio mucho valor como laboratorio. El error habr\u00eda sido interpretar autom\u00e1ticamente ese \u00e9xito t\u00e9cnico como evidencia suficiente para seguir invirtiendo comercialmente en toda la arquitectura que hab\u00edamos construido.<\/p>\n El criterio aparece precisamente al saber cu\u00e1ndo dejar de admirar que algo funciona y comenzar a preguntar si alguien deber\u00eda pagar por que siga existiendo.<\/p>\n Lo que nos ocurri\u00f3 con Roxy puede suceder hoy con una facilidad extraordinaria en pr\u00e1cticamente cualquier organizaci\u00f3n. La inteligencia artificial est\u00e1 reduciendo radicalmente la fricci\u00f3n necesaria para desarrollar software. Podemos describir una aplicaci\u00f3n y generar c\u00f3digo en minutos. Podemos crear interfaces, estructuras de datos, integraciones, automatizaciones y prototipos con una velocidad que hace pocos a\u00f1os habr\u00eda requerido equipos completos durante semanas.<\/p>\n Es una transformaci\u00f3n extraordinaria y nosotros mismos la aprovechamos todos los d\u00edas. Pero alrededor de esa capacidad se est\u00e1 formando tambi\u00e9n una narrativa comercial muy seductora: ahora puedes construirlo todo. Puedes construir tu propio CRM, tu ERP, tus aplicaciones internas, tus agentes, tus automatizaciones y tu software exactamente como lo necesitas.<\/p>\n Y t\u00e9cnicamente cada d\u00eda resulta m\u00e1s dif\u00edcil decir que eso es falso. Claro que puedes. La pregunta que falta es si deber\u00edas<\/strong>.<\/p>\n Porque la inteligencia artificial est\u00e1 haciendo mucho m\u00e1s barato producir c\u00f3digo, pero todav\u00eda no ha eliminado el costo empresarial de ser propietario de lo que construyes. Alguien seguir\u00e1 teniendo que mantener ese CRM, proteger sus datos, administrar permisos, resolver excepciones, actualizar integraciones, documentar decisiones, garantizar continuidad y entender por qu\u00e9 fue dise\u00f1ado de determinada manera.<\/p>\n Un ERP generado r\u00e1pidamente sigue teniendo que sobrevivir a la operaci\u00f3n real de una empresa. Un CRM construido con IA sigue teniendo que gestionar duplicados, perfiles, auditor\u00eda, integridad de datos, automatizaciones, APIs, seguridad y a\u00f1os de cambios en el proceso comercial. La demostraci\u00f3n puede construirse en d\u00edas; la responsabilidad de poseerla puede durar a\u00f1os.<\/p>\n No creo que exista necesariamente mala intenci\u00f3n detr\u00e1s del entusiasmo actual. Estamos viviendo un cambio tecnol\u00f3gico extraordinario y es natural que fabricantes, plataformas, desarrolladores y proveedores quieran mostrar todo lo que ahora es posible.<\/p>\n El problema aparece cuando la demostraci\u00f3n de capacidad se convierte en recomendaci\u00f3n de negocio. Que una inteligencia artificial pueda generar un CRM no significa que una empresa deba convertirse en fabricante de CRM. Que pueda crear un peque\u00f1o ERP no significa que tenga sentido asumir durante a\u00f1os la responsabilidad de mantenerlo. Que podamos desarrollar un agente para una tarea tampoco significa que no exista ya una capacidad nativa, una integraci\u00f3n o una soluci\u00f3n m\u00e1s sencilla para resolverla.<\/p>\n La industria tecnol\u00f3gica siempre ha tenido incentivos para vendernos lo nuevo. La diferencia actual es que la IA no s\u00f3lo nos vende software: tambi\u00e9n nos vende la sensaci\u00f3n de que ahora nosotros mismos podemos fabricar todo el software que queramos. Eso puede ser enormemente liberador cuando existe una necesidad real. Tambi\u00e9n puede convertirse en una f\u00e1brica de complejidad innecesaria cuando no existe criterio.<\/p>\n Durante muchos a\u00f1os, el costo del desarrollo funcion\u00f3 como una barrera imperfecta. Construir era suficientemente caro como para que muchas empresas tuvieran que justificar la inversi\u00f3n antes de comenzar. Ahora esa barrera est\u00e1 disminuyendo. Necesitamos reemplazarla por otra: necesitamos disciplina.<\/p>\n Cuando recomendamos a un cliente que no desarrolle algo, desde fuera puede parecer que estamos haciendo menos trabajo. A veces incluso estamos renunciando a un proyecto que t\u00e9cnicamente podr\u00edamos ejecutar. Sin embargo, \u00e9sa puede ser precisamente la recomendaci\u00f3n de mayor valor.<\/p>\n El cliente no ve las horas que nosotros ya dedicamos a investigar una API que despu\u00e9s descartamos, el prototipo que construimos para descubrir sus l\u00edmites o el c\u00f3digo que funcionaba pero no justificaba convertirse en infraestructura. Tampoco ve todos los cambios de producto que hemos observado durante a\u00f1os y que nos ayudan a reconocer cu\u00e1ndo una plataforma probablemente terminar\u00e1 absorbiendo una capacidad que hoy parece requerir desarrollo propio.<\/p>\n Ve una recomendaci\u00f3n que puede tomar pocos minutos explicar: \u201cusa primero esto\u201d, \u201cno desarrolles todav\u00eda\u201d, \u201cespera a entender hacia d\u00f3nde est\u00e1 evolucionando la plataforma\u201d o \u201cesta parte s\u00ed conviene construirla; aquella no\u201d. El valor no est\u00e1 en la cantidad de palabras necesarias para expresar la recomendaci\u00f3n. Est\u00e1 en todo lo que tuvo que ocurrir antes para poder hacerla con fundamento.<\/p>\n Por eso la experiencia no puede medirse \u00fanicamente por cu\u00e1nto sabemos construir. Tambi\u00e9n debe medirse por nuestra capacidad para evitar que un cliente invierta dinero, tiempo y atenci\u00f3n en cosas que no deber\u00eda tener que poseer.<\/p>\n Roxy no nos ense\u00f1\u00f3 que deb\u00edamos abandonar el desarrollo propio ni que Zoho resolver\u00e1 todo. Tampoco cambi\u00f3 la esencia de nuestra manera de hacer consultor\u00eda. Nos dio algo m\u00e1s valioso: mayor claridad.<\/p>\n Entendemos mejor la direcci\u00f3n que est\u00e1 tomando la plataforma sobre la que llevamos a\u00f1os trabajando. Entendemos mejor qu\u00e9 significa dise\u00f1ar agentes que interact\u00faan con sistemas empresariales. Tenemos m\u00e1s experiencia real con MCP, herramientas, permisos y gobierno. Y, sobre todo, somos m\u00e1s disciplinados al separar aquello que merece experimentarse de aquello que merece convertirse en una inversi\u00f3n permanente.<\/p>\n Como ingenieros y arquitectos, seguiremos entrando al laboratorio. Queremos saber hasta d\u00f3nde podemos llevar estas tecnolog\u00edas y nos sigue produciendo una enorme satisfacci\u00f3n conseguir que algo nuevo funcione. Como empresarios, despu\u00e9s tendremos que hacer la pregunta inc\u00f3moda: \u00bfqui\u00e9n va a pagar por esto y por qu\u00e9 deber\u00eda hacerlo?<\/strong><\/p>\n Si no tenemos una respuesta suficientemente buena, el hecho de que podamos construirlo no convierte el proyecto en negocio. Eso fue lo que aprendimos con Roxy, y es una lecci\u00f3n que probablemente tendr\u00e1 cada vez m\u00e1s valor en un mundo donde construir cualquier cosa ser\u00e1 progresivamente m\u00e1s f\u00e1cil.<\/p>\n Roxy no desapareci\u00f3 despu\u00e9s de esta experiencia. El proyecto mejor\u00f3 precisamente porque dejamos de medir su futuro por la cantidad de cosas que \u00e9ramos capaces de programarle.<\/p>\n La primera etapa nos permiti\u00f3 entender qu\u00e9 deb\u00eda permanecer, qu\u00e9 conven\u00eda eliminar, qu\u00e9 pod\u00eda dejarse en manos de Zoho y d\u00f3nde s\u00ed existe una raz\u00f3n para incorporar inteligencia, orquestaci\u00f3n, integraci\u00f3n y gobierno propios. La arquitectura evolucion\u00f3, pero sobre todo evolucion\u00f3 nuestra comprensi\u00f3n del lugar que Roxy debe ocupar dentro del ecosistema.<\/p>\n Y el cambio que observamos en Zoho hace ese futuro todav\u00eda m\u00e1s interesante. Si la plataforma contin\u00faa evolucionando no s\u00f3lo para tener su propia IA, sino para poder conversar y trabajar con agentes externos, las posibilidades para construir capacidades empresariales sobre ella cambian profundamente. Nuestro trabajo ya no consiste necesariamente en fabricar todos los puentes, sino en dise\u00f1ar qu\u00e9 debe cruzar por ellos, con qu\u00e9 prop\u00f3sito, con qu\u00e9 permisos, bajo qu\u00e9 l\u00edmites y para producir qu\u00e9 valor.<\/p>\n As\u00ed que despu\u00e9s de muchas horas de laboratorio, investigaci\u00f3n, desarrollo, pruebas, errores, c\u00f3digo que sobrevivi\u00f3 y c\u00f3digo que no ten\u00eda por qu\u00e9 sobrevivir, una nueva Roxy est\u00e1 por salir muy pronto<\/strong>.<\/p>\n No es valiosa a pesar de todo lo que nos cost\u00f3 aprender para llegar hasta ella. Es mejor precisamente porque ese aprendizaje ya ocurri\u00f3. Y quiz\u00e1 \u00e9sa sea la forma m\u00e1s honesta de explicar lo que significa pagar por experiencia: nuestros clientes no necesitan financiarnos para descubrir cada camino desde cero. Una parte de ese costo ya la absorbimos nosotros explorando, construyendo, equivoc\u00e1ndonos y entendiendo por qu\u00e9.<\/p>\n Lo que ellos deber\u00edan recibir es el beneficio de ese aprendizaje convertido en mejores decisiones.<\/p>\nEl laboratorio hab\u00eda funcionado. La decisi\u00f3n de negocio era otra cosa<\/h2>\n
No descubrimos solamente nuevas funciones de Zoho. Descubrimos hacia d\u00f3nde parece dirigirse la plataforma<\/h2>\n
La experiencia no cambi\u00f3 nuestra consultor\u00eda; afin\u00f3 nuestra disciplina<\/h2>\n
\u201c\u00bfPero a ustedes tambi\u00e9n les pasa?\u201d<\/h2>\n
Hay una diferencia enorme entre el costo de descubrir y el costo de operar<\/h2>\n
Y ahora la IA est\u00e1 haciendo esa pregunta mucho m\u00e1s urgente para todas las empresas<\/h2>\n
El aparato comercial de la IA vende capacidad; la empresa necesita criterio<\/h2>\n
La experiencia tambi\u00e9n consiste en evitar inversiones que t\u00e9cnicamente podr\u00edamos ejecutar<\/h2>\n
Lo que realmente cambi\u00f3 con Roxy<\/h2>\n
Roxy est\u00e1 por volver, pero ahora sabemos mejor qu\u00e9 debe ser<\/h2>\n
\n