Análisis / Desarrollo y agentes
Agentes de IA sin depender de un solo proveedor
Una empresa puede invertir meses en integrar un agente con sus procesos y descubrir después que cambiar de modelo exige reconstruir buena parte del sistema. La incorporación de nuevos estándares a la Agentic AI Foundation reduce ese riesgo, aunque todavía no garantiza migraciones automáticas.
Sí, una empresa puede diseñar sus agentes de IA para cambiar de modelo o proveedor sin reconstruirlos desde cero, pero debe preparar esa posibilidad desde el principio. La adopción de estándares abiertos facilita reutilizar instrucciones, herramientas e interfaces de comunicación. Sin embargo, la memoria, ciertas capacidades del modelo y las funciones exclusivas de cada plataforma todavía pueden exigir adaptaciones.
El 22 de octubre de 2026, la Linux Foundation anunció que cuatro proyectos pasaban a formar parte de la Agentic AI Foundation (AAIF), durante AGNTCon + MCPCon North America, celebrado en San José.
Dos de ellos afectan directamente a cualquier empresa que esté desarrollando agentes: Agent Skills, aportado por Anthropic, y Open Responses, aportado por OpenAI.
¿Qué ha cambiado con la Agentic AI Foundation?
La AAIF nació en diciembre de 2025 con tres proyectos. Con las nuevas incorporaciones, reúne 10 proyectos bajo un modelo de gobierno abierto y neutral.
Los cuatro anunciados son:
- Agent Skills (Anthropic): formato para empaquetar conocimientos, instrucciones, scripts y recursos reutilizables.
- Open Responses (OpenAI): especificación común para intercambiar peticiones y respuestas con distintos proveedores de modelos.
- OpenEnv (Hugging Face): infraestructura para crear y compartir entornos de entrenamiento y evaluación.
- OpenSandbox (Alibaba): entornos aislados para ejecutar tareas y código de agentes.
Se suman a proyectos como MCP, AGENTS.md, A2A, goose, agentgateway y Agent Router.
Según la Linux Foundation, el objetivo del gobierno neutral es que ninguna empresa controle por sí sola la evolución de estos proyectos.
Esto reduce la dependencia de las decisiones de un único fabricante, aunque no obliga a todas las plataformas a implementar los estándares.
Agent Skills permite trasladar instrucciones entre plataformas
Una skill contiene instrucciones para realizar una tarea concreta, normalmente organizadas en un archivo SKILL.md, junto con scripts y documentación complementaria.
Por ejemplo, una empresa puede preparar una skill que explique cómo revisar un presupuesto, validar determinados campos y generar un informe siguiendo sus criterios internos.
Al utilizar un formato abierto, esa documentación puede reutilizarse en plataformas compatibles sin tener que redactarla completamente de nuevo.
Anthropic afirma que más de 70 plataformas han integrado Agent Skills desde diciembre de 2025, entre ellas ChatGPT, Cursor, GitHub Copilot y VS Code.
La compañía también comunica aproximadamente 1 millón de skills publicadas y cerca de 280 millones de instalaciones. Son cifras aportadas por Anthropic, no verificaciones independientes.
La donación incluye el nombre, el logotipo, la organización de GitHub y el dominio agentskills.io. Cualquiera puede utilizar el estándar o contribuir sin pertenecer a la AAIF.
También se ha propuesto una hoja de ruta con versiones numeradas, un proceso formal de propuestas y recomendaciones de seguridad.
Ya explicamos cómo estructurar este conocimiento en AGENTS.md e instrucciones para agentes.
Open Responses busca reducir la dependencia de una API
Open Responses aborda otra parte del problema: la comunicación entre una aplicación y los modelos de IA.
La especificación, basada en la Responses API de OpenAI, propone un formato compartido de peticiones, respuestas y eventos de streaming.
Imagina una aplicación empresarial que envía documentos a un modelo, recibe resultados estructurados y utiliza herramientas para completar un proceso.
Si la aplicación depende directamente de una API propietaria, cambiar de proveedor puede obligar a modificar la integración.
Con una interfaz basada en Open Responses, parte de esa comunicación podría mantenerse al cambiar entre proveedores que implementen la especificación.
Esto todavía no significa que todos los modelos sean intercambiables. Open Responses acaba de incorporarse a la AAIF y su implementación no es universal.
Además, aunque dos proveedores acepten una estructura de petición similar, sus modelos pueden diferir en resultados, herramientas disponibles y comportamiento.
El artículo sobre por qué un mismo modelo funciona de forma distinta según su arnés profundiza en esas diferencias.
¿Qué partes de un agente son realmente portables?
La portabilidad depende de dónde resida cada componente del sistema.
| Criterio | Qué comprobar |
|---|---|
| Instrucciones del agente | Que estén documentadas en archivos reutilizables como AGENTS.md. |
| Skills | Que sigan un formato abierto y no dependan de funciones exclusivas de una plataforma. |
| Conexiones con herramientas | Que utilicen interfaces como MCP cuando resulte apropiado. |
| Peticiones al modelo | Que exista una capa de integración independiente y se valore Open Responses. |
| Memoria e historial | Que los datos puedan exportarse y no queden encerrados en servicios propietarios. |
| Herramientas específicas | Que exista una alternativa o un procedimiento de sustitución. |
| Comportamiento del modelo | Que se pruebe de nuevo al cambiar de proveedor. |
| Seguridad y permisos | Que las credenciales y autorizaciones puedan administrarse independientemente. |
MCP ya proporciona una base común para conectar agentes con herramientas externas. Puedes consultar cómo utilizarlo en nuestra guía sobre el estándar MCP.
La clave es distinguir entre portabilidad del formato y portabilidad del funcionamiento. Poder trasladar una skill no garantiza que otro modelo la ejecute exactamente igual.
Qué pedir antes de encargar un agente para tu empresa
Antes de aprobar el desarrollo, conviene acordar algunas condiciones técnicas:
1. Instrucciones accesibles: las reglas y procedimientos deben entregarse como archivos que la empresa pueda consultar y modificar.
2. Conexiones documentadas: cada integración debe especificar sus dependencias y permisos.
3. Separación del proveedor: la lógica de negocio no debería estar mezclada innecesariamente con llamadas a una API concreta.
4. Exportación de datos: conversaciones, estados y registros relevantes deben tener un procedimiento de recuperación.
5. Pruebas de migración: debe ser posible evaluar otro modelo con tareas representativas antes de sustituir el actual.
Cambiar de proveedor puede implicar nuevos costes, pruebas y modificaciones. Los estándares abiertos ayudan a reducir ese trabajo, pero no lo eliminan.
Qué decisión tomar esta semana
Si estás construyendo un agente, revisa dónde están almacenadas sus instrucciones, cómo se conecta a las herramientas y qué componentes dependen de una plataforma concreta. Si todavía estás definiendo el proyecto, exige que esas dependencias queden documentadas antes de comenzar. Y si necesitas integrar agentes en procesos empresariales, cuéntanos qué sistemas quieres conectar para estudiar una arquitectura que permita evolucionar sin rehacer toda la integración.
Fuentes
Comprobado el 25 de octubre de 2026