Cómo diseñamos nuestro stack de employents para no depender de un proveedor
Elegir un framework para tus agentes, un proveedor de modelo o un host de despliegue parece una decisión técnica más, hasta que ese proveedor cambia las reglas y toda tu arquitectura depende de que no lo haga. Al construir Mercuria, nuestro primer employent, el agente de IA con rol de empleado, decidimos que ninguno de esos tres elementos tuviera ese poder sobre nuestra arquitectura.
Este artículo va sobre cómo evitar el vendor lock-in en agentes de IA sin renunciar a la velocidad que da apoyarte en herramientas de terceros. Depender de alguien en algún punto del stack es inevitable, pero lo que decide si esa dependencia sale cara es en qué capa la aceptas y en cuál no. El repositorio de la plataforma sigue siendo privado: lo que defendemos aquí, capa por capa, es qué proveedor controla cada una, no si el código es abierto.
El cerebro es el activo; el runtime es desechable
El sector de los agentes de IA cambia de dirección cada pocos meses, así que apostar la arquitectura entera a que el harness de moda siga siendo la opción correcta dentro de un año es la manera más rápida de quedar atrapado. Por eso trazamos la frontera de portabilidad alrededor del conocimiento del rol, no alrededor del runtime que lo ejecuta, una separación que llamamos cerebro y arnés siguiendo la disciplina de harness engineering: el cerebro es el conocimiento del rol en markdown, versionado y publicado fuera del código; el arnés es todo lo demás, desechable por diseño.
El cerebro de Mercuria vive en un repositorio propio y se publica como paquete público en npm (@orbitant/brain-marketing), fijado a una versión concreta con su lockfile. Se actualiza mediante Pull Request revisada, que no se integra si los evals fallan. El arnés, por su parte, esconde cada integración externa (el modelo en sí, Slack, Zoom, Notion…) detrás de una interfaz fina, de modo que cambiar de proveedor no debería afectar al conocimiento que el agente aplica.
Esta tesis superó dos pruebas reales:
- Revertimos la primera elección de runtime el mismo día que la propusimos. Ese cambio solo requirió actualizar un Architecture Decision Record (ADR, la documentación con la que registramos cada decisión de arquitectura): el calendario de trabajo no sufrió ningún retraso.
- Pasar de un modelo fijo por defecto a probar modelos abiertos europeos mediante un endpoint compatible con OpenAI no tuvo ninguna repercusión en el resto de la arquitectura: solo cambiamos la configuración del proveedor.
"platform": {
"models": {
- "orchestrator": "anthropic:claude-sonnet-5",
+ "orchestrator": "openai-compatible:gemma4",
"content": "anthropic:claude-sonnet-5",
"image": "gemini-3.1-flash-image"
},
"timezone": "Europe/Madrid",
"webhooks": { "port": 3000 }
},{La prueba de que la portabilidad está donde tiene que estar es que revertir una decisión de runtime cueste solo un documento y cero replanificación. Si esa frontera hubiera estado en el runtime, cualquier cambio de framework habría significado reescribir el conocimiento del rol entero, que es justo el coste que queríamos evitar.
Cómo evitar el vendor lock-in en agentes de IA: cuatro capas, cuatro decisiones
Quizá decir «ningún proveedor es dueño de nuestro stack» suene a eslogan, pero cuando existe una forma de verificarlo deja de ser una promesa de marketing. Hay que descomponerlo en las cuatro capas donde se decide de verdad, con lo que demuestra cada una:
| Capa | Cómo evitamos el lock-in | Qué demuestra |
|---|---|---|
| Modelo | El proveedor vive detrás del AI SDK; usamos modelos abiertos para la mayoría del trabajo y reservamos un modelo de frontera solo donde medimos que hace falta | Cambiamos de un modelo fijo por defecto a modelos abiertos europeos mediante un endpoint compatible con OpenAI sin tocar nada más en el sistema |
| Framework | Mastra queda sellado detrás de nuestra propia frontera (core/agent); ningún tipo de Mastra sale de ahí | Si tuviéramos que sustituir Mastra mañana, el impacto quedaría acotado a la capa de integración: habría que adaptar las importaciones y algunos puntos de conexión, sin tener que replantear el resto de la plataforma |
| Conocimiento | El conocimiento del rol vive en markdown portable, versionado y publicado de forma independiente del código | Cualquiera puede instalar la versión exacta que usamos con un simple npm install, igual que cualquier otra dependencia pública |
| Infraestructura | El camino decidido es nuestro propio clúster, no un proveedor de hosting serverless | Corregimos por escrito un ADR que había nombrado un proveedor concreto: el requisito real es «cualquier host que ejecute Node de forma permanente», no una marca |
La cifra que más pesa de las cuatro es la del framework: dos importaciones en un fichero de 176 líneas es toda nuestra exposición a Mastra. Responde a la vez a dos preguntas (por qué no elegimos otra alternativa y si Mastra de verdad aporta algo) y convierte una discusión de gustos en un número que cualquiera puede comprobar con un grep.
Cada una de las cuatro decisiones tiene un coste concreto que aceptamos: menos automatismos por defecto, más código propio y alguna migración futura si el requisito cambia. A cambio, ningún proveedor puede obligarnos a reescribir el sistema entero por su cuenta.
El cementerio de frameworks que no llegamos a usar
Descartar una opción sin haberla probado es barato y poco convincente, así que el criterio de búsqueda no se quedó en comparar tablas de características: buscábamos algo de alto nivel, con memoria y evaluaciones automáticas ya resueltas, que no nos casara con un proveedor de modelo concreto y que encajara con nuestro stack en TypeScript. Con ese filtro llegamos a una lista corta de candidatos serios. A la mayoría no los descartamos leyendo su documentación: los llevamos a código real antes de tomar la decisión. Estos son los tres bloques que más tiempo nos hicieron dudar, y por qué ninguno acabó formando parte del arnés de Mercuria.
Eve (Vercel): el que más nos gustaba sobre el papel
Era la opción que más nos gustaba sobre el papel: un agente como una carpeta con skills, canales, calendarios y aprobaciones, con ejecución duradera y revisión humana de serie, casi nuestra propia visión escrita por otra empresa. No la descartamos leyendo sus documentos: montamos encima un piloto real del employent de marketing y lo llevamos a producción. Lo que falló fue la integración con Slack Connect, con tres incidentes distintos entre reenvíos, rotación de token y permisos de ficheros, además de una capa de producción todavía en beta y acoplada a la plataforma de Vercel.
Hermes (Nous Research): comparte la tesis, resuelve otro problema
Hermes comparte nuestra misma tesis de fondo, conocimiento portable en markdown, pero resuelve otro problema: reescribe sus propias skills sin que ninguna persona las revise antes, algo que rompe justo lo que para nosotros es el activo, la voz de marca. Necesitábamos lo contrario en un punto concreto: una fuente de verdad revisada por humanos antes de publicarse.
Los descartados por bajo nivel o por stack: LangGraph, Agno, Letta y CrewAI
Ninguno de estos cuatro llegó a la fase de piloto: la comparación con Eve y Hermes ya bastaba para descartarlos, cada uno por un motivo concreto.
- LangGraph: orquestación por grafos, descartada por el mismo motivo que el Claude Agent SDK, un nivel de abstracción demasiado bajo para lo que necesitábamos resolver en memoria.
- Agno, Letta y CrewAI: frameworks de Python en un stack que es TypeScript, además de estar, en distinto grado, demasiado especializados para el problema que teníamos entre manos. Un «nos gustó» durante el piloto valida el producto, la voz y el contenido, no el arnés que lo sostiene. Separar esas dos conclusiones es lo que nos libró de casarnos con la herramienta equivocada por las razones correctas.
Por qué revertimos el Claude Agent SDK el mismo día que lo propusimos
De toda la lista de rechazados, el que más peso tiene en esta tesis no es Eve ni Hermes: es el Claude Agent SDK, de Anthropic. Fue nuestra primera propuesta de arnés y la revertimos el mismo día que llegó el primer comentario de revisión.
El motivo no fue que sea un mal SDK. Fueron dos razones muy concretas, las mismas que explican el resto de esta tesis:
- Es de bajo nivel: habríamos tenido que construir encima casi todo lo que Mastra ya trae hecho, memoria, workflows que se pausan y se reanudan, MCP y evals.
- Contradice el principio que sostiene todo lo demás: si la regla es modelo detrás de una interfaz sin acoplar proveedor, adoptar el arnés del propio proveedor del modelo rompe esa regla en la primera decisión de arquitectura, antes incluso de escribir una línea de producto.
Revertirlo costó un solo ADR y cero replanificación del trabajo ya hecho, lo que confirma otra vez la tesis: nada dependía todavía de esa elección porque el conocimiento del rol vivía fuera de ella desde el principio.
Conviene dejar por escrito una aclaración, porque es fácil malinterpretarla: el repositorio de la plataforma sigue siendo privado. Lo que sí puede comprobar cualquiera son dos piezas concretas que publicamos: el paquete de conocimiento en el npm público y las decisiones de arquitectura documentadas capa a capa, como las que hemos contado aquí. La afirmación que defendemos habla de qué proveedor controla cada capa del stack, no de si el código es abierto.
Este es el primer capítulo de una serie sobre cómo estamos construyendo a Mercuria puertas afuera. El siguiente cuenta qué pasó cuando el borrador de un post dejó de vivir en un hilo de Slack y pasó a ser una fila en Notion que revisa una persona antes de publicar nada, el guardarraíl que hace posible enseñar todo esto sin miedo: nada de lo que construimos sale a la calle sin que alguien lo apruebe antes.
