En Solventio empezamos a desarrollar chatbots de WhatsApp en 2024. Desde entonces hemos probado agentes, reconstruido automatizaciones y conectado herramientas para consultar información, preparar trabajo y mantener nuestros sistemas al día. Ese recorrido nos enseñó a comenzar por un cuello de botella concreto, documentar cómo se resuelve y probar una primera solución antes de ampliarla. Nuestra transformación con IA sigue en marcha.
Caso propio · Agentes internos · Proceso iniciado en 2024
Cuando un chatbot prometía más de lo que podía cumplir
Nuestra primera apuesta se llamó VanGo. Queríamos crear una plataforma para desplegar agentes en WhatsApp que ayudaran a las empresas a atender mejor y vender más. La idea tenía sentido: estar disponibles cuando llegaba un mensaje y ayudar a que una conversación avanzara.
La operación nos mostró la parte difícil. Pasábamos demasiado tiempo ajustando respuestas. En ocasiones el chatbot inventaba información o no realizaba la acción que necesitaba el cliente. Corregíamos un comportamiento y aparecía otro problema. Lo que funcionaba en una prueba breve podía fallar ante una conversación distinta.
Hubo momentos incómodos frente a clientes. Nos obligaron a reconocer que todavía necesitábamos aprender más antes de ampliar esa solución. Pausamos parte de esa apuesta y seguimos experimentando. Una respuesta convincente tenía que ir acompañada de información correcta y acciones verificables.
Ese aprendizaje sigue presente cuando diseñamos agentes para atender clientes. El trabajo incluye entender qué debe responder, de dónde obtiene la información y en qué momento tiene que pedir ayuda a una persona.
Con Make automatizamos tareas, pero cada cambio tenía trabajo detrás
Mientras la tecnología avanzaba, seguimos usando ChatGPT y explorando herramientas que permitían actuar sobre otros sistemas. Nos interesaba que un agente pudiera consultar una base de datos, actualizar un registro o ayudarnos con gastos e ingresos de la agencia.
Construimos automatizaciones en Make. Pudimos resolver tareas concretas y conectar partes de nuestra operación. También aprendimos cuánto trabajo puede haber detrás de un flujo: definir pasos, prever condiciones, configurar permisos y revisar qué ocurre cuando falta información.
Cuando queríamos hacer algo diferente, con frecuencia teníamos que construir otro recorrido. Cada nueva necesidad añadía configuración y mantenimiento. A eso se sumaban los problemas de uso de herramientas: a veces el agente no las activaba cuando debía o las utilizaba de una forma que no esperábamos.
La automatización ya nos ayudaba. El siguiente reto era ampliar lo que podíamos pedir sin tener que diseñar desde cero cada secuencia posible.
Una prueba cambió nuestra forma de construir
En nuestras pruebas con un entorno de agentes conectado a herramientas encontramos otra manera de trabajar. Podíamos ofrecer herramientas, explicar el resultado esperado y dejar que el agente organizara los pasos dentro de ese alcance.
Nuestro fundador recuerda una experiencia que nos llamó la atención: había dedicado aproximadamente un día a construir un flujo para un agente en Make. En una prueba posterior, al entregar las herramientas y las instrucciones al nuevo entorno, pudo preparar una solución en unos veinte minutos.
Es una anécdota de una tarea concreta, recordada por quien la realizó. No fue una comparación controlada entre productos y no representa el tiempo que necesita cualquier implementación. Para nosotros sirvió para descubrir una posibilidad: parte del esfuerzo podía pasar de dibujar cada paso a preparar buenas herramientas y explicar con claridad qué había que conseguir.
Seguimos probando internamente. Algunos agentes se quedaban atascados, y mantener el entorno actualizado requería conocimientos técnicos y atención. También empezamos a sentir que una conversación por Telegram se quedaba corta cuando necesitábamos revisar trabajo más complejo.
El potencial era evidente en nuestras pruebas, pero todavía había que diseñar una forma de usarlo todos los días.
Las herramientas cambiaban; nuestro conocimiento tenía que quedarse
En distintos momentos trabajamos con asistentes de programación, Codex y Hermes. Probamos interfaces y formas de ejecución que respondieran mejor al tipo de tarea que teníamos delante. La decisión más útil fue empezar a guardar nuestro conocimiento operativo de una forma que pudiéramos reutilizar.
Una skill reúne instrucciones y recursos para realizar una tarea. Puede explicar dónde buscar la información, qué pasos seguir y cómo preparar el resultado. Una herramienta permite actuar: consultar datos, crear un archivo o actualizar un sistema. Mantener claras esas dos funciones nos ayudó a organizar el trabajo. El formato abierto de Agent Skills permite agrupar instrucciones, referencias y otros recursos para clientes compatibles. Referencia: Agent Skills.
Si usábamos varios agentes con instrucciones distintas, aparecía otro problema: uno podía trabajar con una versión actualizada del proceso mientras otro seguía usando una anterior. Por eso empezamos a centralizar las skills en un repositorio desde el que pudieran instalarse y actualizarse.
Cada mejora podía convertirse así en una instrucción reutilizable. Nos permitía conservar lo aprendido sobre nuestra forma de trabajar aunque cambiáramos de interfaz o de entorno de agentes.
Conectar la empresa también exigía ordenar la empresa
Empezamos a combinar conexiones mediante MCP, APIs y herramientas de línea de comandos. Para parte de esas integraciones utilizamos Composio. Cada conexión debía dar acceso a una acción o a una fuente de información que tuviera sentido para el trabajo.
MCP es un protocolo para conectar aplicaciones de IA con herramientas y datos externos. Ayuda a establecer esa comunicación; el diseño de permisos y la elección de qué puede hacer un agente siguen formando parte de la implementación. Referencia: Model Context Protocol.
Con el tiempo combinamos servicios contratados con aplicaciones que podíamos alojar en nuestros servidores. Queríamos mantener interfaces visuales para las personas y, al mismo tiempo, permitir que los agentes consultaran y operaran los sistemas mediante sus conexiones.
Esto cambió también nuestra manera de elegir software. Empezamos a revisar qué operaciones estaban disponibles, cómo se conectaban y qué posibilidades teníamos de adaptar la aplicación. Una herramienta tenía que ayudarnos en el uso cotidiano y permitir trabajar con nuestra información de una manera ordenada.
En ese proceso fuimos abordando otra necesidad: conservar contexto entre agentes. Un lugar común para instrucciones, referencias y memoria puede evitar que cada nueva sesión empiece con las mismas explicaciones. Es un trabajo que seguimos desarrollando, con atención a qué información corresponde a cada tarea.
El computador apagado dejó clara otra necesidad
Cuando parte de la operación dependía del computador del fundador, apagarlo también detenía ese trabajo. Empezamos a distribuir tareas entre el entorno local y agentes desplegados en servidores VPS.
Para nuestro trabajo de desarrollo seguimos aprovechando equipos locales y las herramientas que usamos allí. Para consultas, cálculos y reportes cotidianos desplegamos agentes remotos con las conexiones que necesitaban. Esa combinación nos permitió pensar cada tarea según dónde convenía ejecutarla.
La experiencia también nos recordó que “tener un agente” incluye más que elegir un modelo. Hay que decidir dónde funciona, cómo accede a los datos y qué necesita para continuar trabajando cuando la persona que lo utiliza no está frente al computador.
Jarvis y una rutina que une reuniones con trabajo pendiente
Llamamos Jarvis a un asistente que nos ayuda a recuperar información y realizar tareas de la agencia. Su utilidad se entiende mejor con un ejemplo del trabajo diario.
Después de una reunión hay información que debe llegar a otros lugares: compromisos, pendientes y cambios sobre un cliente o un proyecto. Según la experiencia relatada por nuestro fundador, hemos trabajado en un flujo que combina Fireflies para transcribir, n8n para encadenar el proceso y un agente para resumir y extraer los puntos relevantes, con actualizaciones previstas en herramientas de CRM y proyectos como Twenty y Plane. La validación del alcance y de la continuidad de ese flujo sigue en curso; este relato no acredita una automatización completa o aceptada.
Make formó parte de las primeras etapas. Más adelante pasamos a n8n autoalojado para esta capa de automatización. El resultado combina procesos definidos con agentes que trabajan sobre información: seguimos necesitando ambos.
El beneficio que observamos es cualitativo: menos trabajo de ir a buscar y trasladar información entre herramientas, y más facilidad para consultar lo que está pasando. No presentamos aquí una cifra de ahorro porque no hemos aportado una medición comparable para este caso.
También evitamos describir a Jarvis como una solución que hace todo sola. Su trabajo depende de las herramientas conectadas, las instrucciones disponibles y el alcance de cada tarea. Ese contexto permite entender lo que un agente puede aportar y lo que todavía necesita del equipo.
También construimos cosas que no necesitábamos
Hubo una etapa en la que las novedades nos arrastraban. Aparecía una herramienta, veíamos una demostración y queríamos probarla. La posibilidad de automatizar cada vez más cosas nos llevó a invertir tiempo en soluciones cuyo valor no habíamos definido bien.
Algunas no resolvían un problema importante. Otras competían por atención con trabajo que tenía más impacto. Cambiar de herramienta continuamente también dificultaba aprender a utilizar una con profundidad.
Tuvimos que cambiar el orden de nuestras decisiones. Empezamos a mirar primero dónde se estaba perdiendo tiempo, qué provocaba reprocesos y qué información costaba mantener al día. Después ordenábamos las oportunidades y elegíamos una primera implementación.
Esperar a que una herramienta madurara también se volvió una decisión válida. Las pruebas internas nos daban espacio para conocer sus límites antes de hacer depender de ella un proceso de un cliente.
Lo que hoy recomendamos a una empresa que quiere empezar
Nuestra experiencia nos ha llevado a una secuencia práctica:
- Elegir un cuello de botella. Una tarea frecuente que alguien pueda describir y cuyo problema sea visible: recopilar información, preparar un reporte o actualizar registros.
- Entender el trabajo actual. Hablar con quien lo hace, reunir ejemplos y definir qué sería un buen resultado. El agente necesita esa información para ser útil.
- Preparar una primera versión pequeña. Darle las herramientas y las instrucciones necesarias para una tarea delimitada. La IA puede ayudar a explicar y construir esa versión.
- Probar con situaciones reales y revisar. Observar dónde falla, qué le falta y qué parte exige intervención de una persona. Incorporar esos aprendizajes a las instrucciones.
- Ampliar cuando exista valor. Escalar lo que ayuda y medirlo con una referencia: tiempo de trabajo, correcciones necesarias o facilidad para mantener la información al día.
Seguimos construyendo una Solventio en la que los agentes participan en el trabajo cotidiano. El recorrido empezó con chatbots para WhatsApp y hoy incluye instrucciones compartidas, herramientas conectadas, automatizaciones y aplicaciones que usamos dentro de la agencia.
La eficiencia es el criterio con el que queremos seguir avanzando: que el equipo pueda dedicar menos esfuerzo a tareas repetitivas y tenga mejores condiciones para desarrollar, atender y tomar decisiones.
¿Qué tarea le está quitando tiempo a tu equipo? En Solventio te ayudamos a entender el proceso, elegir una primera oportunidad y construir una solución con IA que puedas probar en tu operación.
Identificar una oportunidad de eficiencia · Conocer los agentes internos