Nos equivocamos para que tú no tengas que hacerlo: el verdadero valor de la experiencia

Roxy nació de una idea que nos entusiasmaba desde hacía tiempo: construir un agente de inteligencia artificial que pudiera fungir como administrador de Zherpa. No queríamos otro chatbot corporativo capaz de responder preguntas sobre la empresa o consultar una base de conocimiento. Queríamos que pudiera trabajar dentro de nuestros procesos, consultar información actualizada, interactuar con nuestros sistemas y ejecutar determinadas tareas administrativas bajo reglas, permisos y límites definidos.

La ambición iba más allá de resolver una necesidad interna. Si lográbamos construir una Roxy capaz de trabajar realmente dentro de Zherpa, podríamos aprender qué requería un agente administrativo de verdad y, eventualmente, convertir ese conocimiento en una capacidad que pudiéramos llevar a otras empresas.

El proyecto reunía muchas de las disciplinas en las que llevamos años trabajando: arquitectura de procesos de negocio, Zoho, CRM, automatización, integraciones y desarrollo. A todo eso se sumaba una tecnología que estaba cambiando rápidamente: 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.

Así 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ón y ejecutar determinadas acciones. Investigamos APIs, autenticación, permisos, reglas de negocio, validaciones, seguridad y mecanismos de supervisión humana. Cada avance abría nuevas preguntas y cada respuesta requería más investigación, código y pruebas.

Invertimos muchas horas. También muchos tokens. Nos equivocamos, corregimos, volvimos a probar y seguimos construyendo hasta conseguir algo que, desde el punto de vista de ingeniería, era fascinante: funcionaba. Roxy podía comunicarse con Zoho Books y utilizar las herramientas que habíamos construido para trabajar con información real del sistema. Habíamos conseguido que un agente conversacional comenzara a convertirse en algo diferente: un agente capaz de interactuar con una plataforma empresarial.

Como laboratorio de ingeniería y arquitectura, fue extraordinario. El problema apareció cuando dejamos de preguntarnos qué más podíamos lograr técnicamente y nos hicimos una pregunta bastante menos emocionante: ¿quién va a pagar por todo esto?

El laboratorio había funcionado. La decisión de negocio era otra cosa

Sería incorrecto decir que construir aquella primera arquitectura de Roxy fue simplemente un error. Como ejercicio de ingeniería, investigación y aprendizaje, fue tremendamente valioso. Necesitábamos ensuciarnos las manos con MCP, entender cómo se comportaban los agentes frente a herramientas reales, descubrir los problemas de autenticación y permisos, experimentar con controles y comprobar qué sucede cuando un modelo deja de limitarse a generar texto y comienza a interactuar con sistemas empresariales.

Hay conocimiento que puedes obtener leyendo documentación y hay otro que sólo aparece cuando intentas hacer que las cosas funcionen. Nosotros necesitábamos ambos. La satisfacción de lograrlo tampoco era trivial. Quienes disfrutamos la ingeniería conocemos perfectamente ese momento en el que algo que durante días sólo existía como arquitectura, código, errores y pruebas finalmente funciona. No considero que esas horas hayan sido desperdiciadas.

El error apareció en otro lugar. Apareció cuando comenzamos a mirar aquel desarrollo no solamente como laboratorio, sino como inversión de negocio. Si aquello iba a convertirse en una capacidad permanente de Zherpa y, eventualmente, en algo que pudiéramos ofrecer comercialmente, entonces la evaluación tenía que cambiar por completo.

Ya no bastaba con preguntar si podíamos construirlo. Había que preguntar cuánto costaría terminarlo, mantenerlo, protegerlo y evolucionarlo; qué parte de esa infraestructura seguiría siendo necesaria dentro de uno o dos años; qué problema comercial resolvía; quién estaría dispuesto a pagar por él y, sobre todo, qué retorno justificaba que Zherpa siguiera absorbiendo ese costo.

Fue entonces cuando otra pieza comenzó a cambiar nuestra manera de ver la arquitectura.

No descubrimos solamente nuevas funciones de Zoho. Descubrimos hacia dónde parece dirigirse la plataforma

Mientras profundizábamos en Roxy comenzamos a observar algo que para nosotros era mucho más importante que encontrar una función nueva dentro de Zoho Books.

Durante años hemos trabajado con plataformas que incorporan capacidades de automatización y, más recientemente, inteligencia artificial. El modelo habitual consiste en que el propio software ofrece sus funciones de IA: asistentes, predicciones, generación de contenido, automatizaciones inteligentes o agentes que viven dentro del ecosistema del fabricante.

Pero lo que empezamos a observar iba un paso más allá. Zoho no sólo estaba incorporando IA y agentes dentro de sus productos. Estaba creando mecanismos para que otros agentes pudieran comunicarse con sus sistemas.

Esa diferencia puede parecer técnica, pero para nosotros es estratégica. No es lo mismo una plataforma que contiene inteligencia artificial que una plataforma diseñada 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ón con modelos y agentes compatibles, una señal relevante para quienes diseñamos arquitecturas alrededor de su ecosistema.

Si esa dirección continúa desarrollándose, el papel de una firma como Zherpa cambia de una manera interesante: quizá no necesitemos construir y mantener tantos puentes propietarios para que nuestros agentes entren a Zoho, porque el propio ecosistema está comenzando a construir puertas para que los agentes puedan entrar de manera estructurada.

Eso modificó nuestra perspectiva sobre Roxy. Habíamos empezado construyendo parte de la infraestructura necesaria para conectar un agente con Zoho. Mientras lo hacíamos, comprendimos que Zoho estaba avanzando hacia una arquitectura en la que esa comunicación podría formar parte cada vez más de la propia plataforma.

No era simplemente que “Zoho ya hacía lo mismo que Roxy”. Eso no habría sido cierto. Lo importante era que estaba cambiando el lugar donde tenía sentido que nosotros invirtiéramos nuestro esfuerzo.

La experiencia no cambió nuestra consultoría; afinó nuestra disciplina

Tampoco salimos de esta experiencia pensando que habíamos descubierto una filosofía completamente nueva para Zherpa. Después de tantos años implementando sistemas empresariales, siempre hemos sabido que antes de desarrollar hay que entender el proceso, estudiar la plataforma y aprovechar correctamente las capacidades existentes.

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ó más clara. Primero tenemos que entender qué necesita realmente el negocio. Después investigar hasta dónde llega la plataforma existente y hacia dónde está evolucionando. Luego configurar y aprovechar sus capacidades nativas. Después integrar cuando existe una razón para hacerlo. Y sólo cuando queda una brecha suficientemente importante, diferenciadora y económicamente justificable tiene sentido asumir el costo de desarrollar y mantener algo propio.

No cambiamos nuestra consultoría. La afinamos. Tampoco dejamos de experimentar. Al contrario: necesitamos experimentar más que antes porque las plataformas están evolucionando demasiado rápido como para asesorar desde la teoría. Pero ahora tenemos más claridad sobre la frontera que separa el laboratorio de la inversión.

En el laboratorio podemos construir algo simplemente porque necesitamos saber si funciona y qué podemos aprender haciéndolo. En el negocio necesitamos una razón adicional: alguien tiene que recibir suficiente valor de aquello como para justificar su costo.

“¿Pero a ustedes también les pasa?”

Tiempo después estaba contando esta historia al director general de una empresa cliente. No estaba presentando a Roxy como un caso de éxito ni tratando de maquillar el recorrido. Le expliqué que habíamos invertido muchas horas investigando y desarrollando capacidades para después concluir que una parte de aquella arquitectura no debía convertirse en infraestructura permanente.

Su reacción fue perfectamente razonable: “¿Pero eso también les sucede a ustedes, que son los expertos?”

La respuesta fue sí. Por supuesto que nos sucede. Y le contesté algo que desde entonces me parece una buena explicación de una parte del valor de nuestro trabajo: a nosotros probablemente nos sucede con mayor frecuencia de la que debería sucederte a ti.

No porque equivocarse sea deseable ni porque debamos celebrar una mala inversión. Nos sucede porque para nosotros explorar forma parte del trabajo. Tenemos que probar tecnologías antes de recomendarlas, entender nuevas capacidades de Zoho, experimentar con agentes, descubrir sus límites, construir prototipos y averiguar qué ideas sobreviven cuando dejan la presentación comercial y entran a un proceso real.

Eso tiene un costo. Lo pagamos en horas de especialistas, investigación, desarrollo, infraestructura, pruebas y, cada vez más, tokens. Algunas veces también lo pagamos con código perfectamente funcional que terminamos descartando porque aprendimos que no tenía sentido convertirlo en una obligación permanente.

Ese costo de exploración 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.

Hay una diferencia enorme entre el costo de descubrir y el costo de operar

Roxy nos ayudó también 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á descartándose. Su retorno es conocimiento. En una empresa como Zherpa, ese conocimiento tiene valor porque mejora las decisiones posteriores y se acumula en nuestra práctica.

La segunda inversión 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écnicamente interesante. Hay que saber quién lo necesita, qué problema resuelve, cuánto está dispuesto a pagar por resolverlo, qué costos recurrentes tendrá, cuánto mantenimiento requerirá y qué alternativas existen.

Un prototipo puede ser un éxito extraordinario de ingeniería y un pésimo negocio. No existe contradicción entre ambas afirmaciones. Nuestro primer Roxy nos dio mucho valor como laboratorio. El error habría sido interpretar automáticamente ese éxito técnico como evidencia suficiente para seguir invirtiendo comercialmente en toda la arquitectura que habíamos construido.

El criterio aparece precisamente al saber cuándo dejar de admirar que algo funciona y comenzar a preguntar si alguien debería pagar por que siga existiendo.

Y ahora la IA está haciendo esa pregunta mucho más urgente para todas las empresas

Lo que nos ocurrió con Roxy puede suceder hoy con una facilidad extraordinaria en prácticamente cualquier organización. La inteligencia artificial está reduciendo radicalmente la fricción necesaria para desarrollar software. Podemos describir una aplicación y generar código en minutos. Podemos crear interfaces, estructuras de datos, integraciones, automatizaciones y prototipos con una velocidad que hace pocos años habría requerido equipos completos durante semanas.

Es una transformación extraordinaria y nosotros mismos la aprovechamos todos los días. Pero alrededor de esa capacidad se está formando también 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.

Y técnicamente cada día resulta más difícil decir que eso es falso. Claro que puedes. La pregunta que falta es si deberías.

Porque la inteligencia artificial está haciendo mucho más barato producir código, pero todavía no ha eliminado el costo empresarial de ser propietario de lo que construyes. Alguien seguirá teniendo que mantener ese CRM, proteger sus datos, administrar permisos, resolver excepciones, actualizar integraciones, documentar decisiones, garantizar continuidad y entender por qué fue diseñado de determinada manera.

Un ERP generado rápidamente sigue teniendo que sobrevivir a la operación real de una empresa. Un CRM construido con IA sigue teniendo que gestionar duplicados, perfiles, auditoría, integridad de datos, automatizaciones, APIs, seguridad y años de cambios en el proceso comercial. La demostración puede construirse en días; la responsabilidad de poseerla puede durar años.

El aparato comercial de la IA vende capacidad; la empresa necesita criterio

No creo que exista necesariamente mala intención detrás del entusiasmo actual. Estamos viviendo un cambio tecnológico extraordinario y es natural que fabricantes, plataformas, desarrolladores y proveedores quieran mostrar todo lo que ahora es posible.

El problema aparece cuando la demostración de capacidad se convierte en recomendación 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ño ERP no significa que tenga sentido asumir durante años la responsabilidad de mantenerlo. Que podamos desarrollar un agente para una tarea tampoco significa que no exista ya una capacidad nativa, una integración o una solución más sencilla para resolverla.

La industria tecnológica siempre ha tenido incentivos para vendernos lo nuevo. La diferencia actual es que la IA no sólo nos vende software: también nos vende la sensación de que ahora nosotros mismos podemos fabricar todo el software que queramos. Eso puede ser enormemente liberador cuando existe una necesidad real. También puede convertirse en una fábrica de complejidad innecesaria cuando no existe criterio.

Durante muchos años, el costo del desarrollo funcionó como una barrera imperfecta. Construir era suficientemente caro como para que muchas empresas tuvieran que justificar la inversión antes de comenzar. Ahora esa barrera está disminuyendo. Necesitamos reemplazarla por otra: necesitamos disciplina.

La experiencia también consiste en evitar inversiones que técnicamente podríamos ejecutar

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écnicamente podríamos ejecutar. Sin embargo, ésa puede ser precisamente la recomendación de mayor valor.

El cliente no ve las horas que nosotros ya dedicamos a investigar una API que después descartamos, el prototipo que construimos para descubrir sus límites o el código que funcionaba pero no justificaba convertirse en infraestructura. Tampoco ve todos los cambios de producto que hemos observado durante años y que nos ayudan a reconocer cuándo una plataforma probablemente terminará absorbiendo una capacidad que hoy parece requerir desarrollo propio.

Ve una recomendación que puede tomar pocos minutos explicar: “usa primero esto”, “no desarrolles todavía”, “espera a entender hacia dónde está evolucionando la plataforma” o “esta parte sí conviene construirla; aquella no”. El valor no está en la cantidad de palabras necesarias para expresar la recomendación. Está en todo lo que tuvo que ocurrir antes para poder hacerla con fundamento.

Por eso la experiencia no puede medirse únicamente por cuánto sabemos construir. También debe medirse por nuestra capacidad para evitar que un cliente invierta dinero, tiempo y atención en cosas que no debería tener que poseer.

Lo que realmente cambió con Roxy

Roxy no nos enseñó que debíamos abandonar el desarrollo propio ni que Zoho resolverá todo. Tampoco cambió la esencia de nuestra manera de hacer consultoría. Nos dio algo más valioso: mayor claridad.

Entendemos mejor la dirección que está tomando la plataforma sobre la que llevamos años trabajando. Entendemos mejor qué significa diseñar agentes que interactúan con sistemas empresariales. Tenemos más experiencia real con MCP, herramientas, permisos y gobierno. Y, sobre todo, somos más disciplinados al separar aquello que merece experimentarse de aquello que merece convertirse en una inversión permanente.

Como ingenieros y arquitectos, seguiremos entrando al laboratorio. Queremos saber hasta dónde podemos llevar estas tecnologías y nos sigue produciendo una enorme satisfacción conseguir que algo nuevo funcione. Como empresarios, después tendremos que hacer la pregunta incómoda: ¿quién va a pagar por esto y por qué debería hacerlo?

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ón que probablemente tendrá cada vez más valor en un mundo donde construir cualquier cosa será progresivamente más fácil.

Roxy está por volver, pero ahora sabemos mejor qué debe ser

Roxy no desapareció después de esta experiencia. El proyecto mejoró precisamente porque dejamos de medir su futuro por la cantidad de cosas que éramos capaces de programarle.

La primera etapa nos permitió entender qué debía permanecer, qué convenía eliminar, qué podía dejarse en manos de Zoho y dónde sí existe una razón para incorporar inteligencia, orquestación, integración y gobierno propios. La arquitectura evolucionó, pero sobre todo evolucionó nuestra comprensión del lugar que Roxy debe ocupar dentro del ecosistema.

Y el cambio que observamos en Zoho hace ese futuro todavía más interesante. Si la plataforma continúa evolucionando no sólo 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ñar qué debe cruzar por ellos, con qué propósito, con qué permisos, bajo qué límites y para producir qué valor.

Así que después de muchas horas de laboratorio, investigación, desarrollo, pruebas, errores, código que sobrevivió y código que no tenía por qué sobrevivir, una nueva Roxy está por salir muy pronto.

No es valiosa a pesar de todo lo que nos costó aprender para llegar hasta ella. Es mejor precisamente porque ese aprendizaje ya ocurrió. Y quizá ésa sea la forma más 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ándonos y entendiendo por qué.

Lo que ellos deberían recibir es el beneficio de ese aprendizaje convertido en mejores decisiones.

---

Fuentes técnicas: documentación oficial de Zoho Books sobre MCP y capacidades de la plataforma. Para conocer el enfoque de Zherpa sobre arquitectura e implementación de Zoho, consulta Consultoría Zoho.