Cómo empezamos a adoptar OpenClaw en Eximus

Hace unos meses OpenClaw aparecía por todas partes. Había entusiasmo, demos y mucha conversación alrededor de los agentes. Lo que nos llamó la atención en Eximus no fue solo la parte conversacional. Fue la idea de tener un sistema capaz de responder, ejecutar comandos y completar tareas reales con cierto margen operativo.

Ahí cambia por completo el tipo de discusión.

Ya no estamos hablando solo de generación de texto. Estamos hablando de software con capacidad de actuar dentro de un entorno técnico real.

Eso nos interesó rápido, pero había una condición clara: probarlo sin improvisar por completo.

La infraestructura no fue el cuello de botella

En Eximus llevábamos tiempo ordenando nuestra base en Azure. Seguimos apoyándonos bastante en Azure IaaS, veníamos migrando infraestructura a Terraform y ya teníamos un repositorio en Azure DevOps con buena parte del aprovisionamiento descrito como código.

Eso hizo una diferencia concreta cuando decidimos movernos.

Lo primero fue crear una VM Linux dedicada para agentes. Como el patrón de infraestructura ya existía, provisionar un recurso nuevo no fue una aventura larga. Fue un paso relativamente corto dentro de una arquitectura que ya tenía cierta disciplina.

Eso liberó tiempo para lo importante: cómo aislarlo, cómo conectarlo con el resto de la empresa y cómo reducir riesgos desde el primer día.

Si el sistema puede actuar, la seguridad deja de ser decorativa

Desde el principio tuvimos claro que este entorno no podía quedar expuesto públicamente como una demo más. Una cosa es mostrar una interfaz. Otra muy distinta es operar un sistema que puede ejecutar comandos, revisar archivos y convertirse en una capa práctica de trabajo interno.

Por eso el servidor quedó sin acceso público directo. Lo dejamos detrás de un reverse proxy y funcional únicamente dentro de nuestra VNET privada en Azure. El acceso administrativo se restringió a VPN y clave SSH.

Puede sonar obvio, pero aquí vale la pena insistir: cuando uno monta agentes con capacidad operativa, la seguridad no puede dejarse para el final. El perímetro, los caminos de acceso, la segmentación y la superficie expuesta pasan a ser parte del diseño del producto, no solo del checklist de infraestructura.

El siguiente reto era volverlo útil para la empresa

Tener OpenClaw corriendo en una VM resolvía la base técnica, pero no el problema real de adopción. La pregunta práctica era otra: cómo lo iba a usar el equipo en el día a día.

Eximus opera fuertemente sobre herramientas de Microsoft, y nuestro canal natural de coordinación es Microsoft Teams. Así que la integración con Teams no era un detalle bonito para más adelante. Era una condición real para que OpenClaw dejara de ser un experimento aislado y empezara a sentirse útil dentro de la empresa.

Ahí fue donde el trabajo se volvió más interesante.

Integrar Teams fue bastante más enredado de lo que parecía

Sobre el papel, la historia parece simple: registrar la aplicación en Azure, preparar el bot, exponer un endpoint seguro y conectar el canal.

En la práctica hubo varias piezas que ordenar para que todo funcionara con estabilidad. Volvimos a apoyarnos en IaC para dejar listos los recursos del lado de Azure, pero también hubo que resolver el puente del lado de Teams y la forma en que ese canal hablaría con el runtime de OpenClaw.

Sin meternos en detalle innecesario, el reto era dejar alineados tres planos al mismo tiempo:

• la aplicación y permisos del lado de Microsoft;
• el endpoint seguro y el runtime del lado nuestro;
• y un puente capaz de mover eventos, solicitudes y respuestas entre ambos.

Ahí aparecen temas menos glamorosos, pero decisivos: mensajes, estados de conversación, websockets, handoffs entre componentes y fricción entre plataformas que no siempre fueron pensadas para este tipo de experiencia.

Ese tramo tomó bastante más trabajo del que parecía al inicio. Y está bien que así sea. La integración real con un canal corporativo casi nunca sale limpia a la primera.

Lo más llamativo: OpenClaw terminó ayudando en su propia configuración

Una de las partes más potentes de toda esta historia fue lo que empezó a pasar cuando el entorno quedó mínimamente funcional.

OpenClaw empezó a ayudarnos a revisar parte de su propia configuración.

Mientras íbamos afinando el sistema, lo usamos para revisar configuraciones del proxy, lanzar peticiones de un lado y del otro, comparar respuestas, detectar fricciones y apoyar la estabilización del canal con Teams. Dejó de sentirse como una pieza estática que uno simplemente despliega. Empezó a comportarse como una herramienta que, bajo supervisión, podía colaborar en el mismo trabajo técnico necesario para dejarla estable.

Eso fue una señal fuerte. La promesa dejaba de ser teórica y empezaba a mostrarse en la operación misma.

Montar el servicio era solo una parte; faltaba ponerle cerebro

Una vez que el servicio quedó corriendo en el servidor de agentes y que la integración principal ya estaba encaminada, apareció otra decisión igual de importante: con qué modelos iba a trabajar y bajo qué límites.

En esa etapa el stack inicial fue bastante pragmático. Teníamos una suscripción de OpenAI Plus, otra de Claude y la API corporativa de OpenAI con un presupuesto controlado. Con eso el sistema ya tenía combustible suficiente para empezar a operar.

La lógica era sencilla: combinar rutas según disponibilidad, límites y conveniencia para cada flujo. En teoría eso suena simple. En la práctica obliga a convivir con costos, topes de uso, continuidad y cambios reales en las condiciones de consumo.

Esa fue otra lección útil. Cuando uno monta agentes en serio, el problema ya no es solo qué modelo luce mejor en abstracto. También importa qué tan usable, estable y sostenible resulta dentro de una operación diaria.

La adopción temprana valió la pena porque nos obligó a tocar la realidad

Lo valioso de adoptar OpenClaw temprano no fue decir que estábamos probando agentes. Fue llegar rápido a las preguntas que de verdad importan:

• cómo aislar un sistema con capacidad operativa;
• cómo provisionarlo rápido sin perder control;
• cómo integrarlo con el canal real donde trabaja el equipo;
• cómo sostenerlo dentro de una arquitectura segura;
• y cómo combinar modelos con límites concretos de presupuesto y disponibilidad.

Ese aprendizaje aparece cuando la herramienta sale del demo y entra a un entorno con restricciones de verdad.

La parte más larga de la historia vino después

Esta primera etapa trata sobre infraestructura, seguridad, integración y stack base. Pero montar OpenClaw no termina cuando ya responde desde Teams o cuando ya tiene modelos conectados.

Después vino la parte más larga: definir roles, construir memoria, ordenar coordinación entre agentes, endurecer automatizaciones y convertir el sistema en una capa operativa más seria dentro de Eximus.

Esa segunda parte merece contarse aparte.

Cierre

Si tuviera que resumir qué permitió que Eximus adoptara OpenClaw relativamente rápido, diría algo muy concreto: ya teníamos una base seria en Azure, IaC, seguridad y delivery técnico. Eso nos dio un entorno real para probar agentes con control, no solo con entusiasmo.

Ahí estuvo la diferencia.

Una vez que OpenClaw entró en ese entorno, la conversación dejó de ser teórica. Empezó el trabajo de verdad.