Habilidades.

¡Hola! Soy Oscar 👋, y por aquí estoy de nuevo!!!

El fin de semana pasado terminamos nuestro bootcamp Claude Master, 13 personas (si algunos tuvieron que irse antes de la foto jeje), y no solo la pasamos buenisimo conectando y conociendonos, si no que a la vez logramos unas reflexiones muy interesante sobre IA.

Y bueno cambiando de tema, últimamente he estado profundizando en algo que históricamente ha sido un tedio para las empresas: la gestion del conocimiento.

La empresas se acostumbraron a documentar procesos que nadie cumple, exigir reglas absurdas para que la gente los cumpla, y al final el engagement es super bajito y el conocimiento empieza a perderse poco a poco…

Pero y, ¿que tal si con inteligencia artificial pudiéramos mejorar esa situación?

Y aquí nace esta entrada: Habilidades.

Pensemos en esta situación:

Dos empresas contratan el mismo modelo de inteligencia artificial. Pagan licencias similares, conectan herramientas comparables y capacitan a equipos con perfiles parecidos.

Seis meses después, una de ellas ha reducido el tiempo necesario para preparar propuestas, mejorado la consistencia de sus análisis y acelerado la incorporación de nuevos empleados. La otra tiene cientos de prompts, decenas de experimentos y una creciente colección de documentos generados por IA, pero pocos cambios verificables en sus resultados.

La diferencia no está necesariamente en el modelo. Está en lo que cada organización fue capaz de enseñarle sobre su forma de trabajar.

Durante los primeros años de la inteligencia artificial generativa, buena parte de la conversación empresarial estuvo dominada por una pregunta:

¿Qué modelo debemos utilizar? Claude, ChatGPT, Gemini y sus competidores eran comparados según su capacidad de razonamiento, velocidad, precio, ventana de contexto y desempeño en benchmarks.

Esa pregunta sigue siendo relevante, pero cada vez explica menos la diferencia entre las compañías que experimentan con IA y las que consiguen transformarse con ella.

A medida que los modelos mejoran y su acceso se democratiza, la inteligencia general que proporcionan empieza a comportarse como infraestructura.

Puede haber diferencias importantes entre proveedores, pero cualquier ventaja basada exclusivamente en utilizar un modelo determinado será difícil de sostener: los competidores pueden comprarlo, contratarlo o sustituirlo.

Lo verdaderamente escaso es otra cosa.

Es saber cuándo una oportunidad comercial merece una excepción. Es reconocer que una propuesta aparentemente rentable puede sobrecargar al equipo. Es distinguir una métrica útil de una de vanidad. Es entender por qué una campaña que funciona en un mercado puede fracasar en otro. Es conocer las señales que anticipan un problema antes de que aparezca en el dashboard.

Los modelos conocen patrones generales. No conocen automáticamente la historia, los compromisos, los errores acumulados ni los criterios particulares de una empresa.

Ahí es donde las Agent Skills comienzan a ser interesantes.

Antes de analizar su impacto empresarial, conviene detenerse en su funcionamiento.

El término Skill puede sugerir una capacidad inteligente que Claude aprende por sí mismo, pero técnicamente se trata de algo más concreto: una carpeta organizada que contiene instrucciones, recursos y, cuando es necesario, scripts ejecutables para realizar un tipo de trabajo.

El componente obligatorio es un archivo llamado SKILL.md.

En su parte inicial incluye un nombre y una descripción breve que permiten a Claude reconocer para qué sirve esa Skill. Después contiene las instrucciones detalladas que explican cómo debe abordar la tarea.

Una estructura sencilla podría verse así:

propuesta-comercial/
├── SKILL.md
├── plantilla-propuesta.md
├── ejemplos/
│   ├── propuesta-correcta.md
│   └── propuesta-incompleta.md
├── politica-descuentos.md
└── validar-margen.py

El archivo principal podría indicarle al agente que primero recopile información sobre el cliente, después utilice una plantilla determinada, revise la política de descuentos y, finalmente, ejecute un script para comprobar el margen antes de generar la propuesta.

La Skill no tiene que incluir todos los detalles dentro de una sola instrucción. Puede enlazar documentos de referencia, plantillas, ejemplos, listas de comprobación y programas que el agente consulta o ejecuta cuando la tarea lo exige. Esto permite combinar dos tipos de capacidad: el razonamiento flexible del modelo y la consistencia del software tradicional.

La diferencia es importante. Claude puede redactar y adaptar una propuesta según el contexto, pero el cálculo del margen no debería depender de una interpretación probabilística. Para ese paso, la Skill puede utilizar un script determinista que aplique siempre la misma fórmula.

Una de las decisiones centrales de la arquitectura es que Claude no carga desde el principio todo el contenido de todas las Skills.

En una primera etapa, el agente solo recibe el nombre y la descripción de cada una. Esa información funciona como el índice de una biblioteca: le permite saber qué capacidades están disponibles sin tener que leer todos los manuales.

Cuando una solicitud parece relevante, Claude abre el archivo SKILL.md correspondiente y carga sus instrucciones. Si durante la ejecución necesita una política, una plantilla o un script adicional, accede a ese recurso en ese momento.

Anthropic llama a este mecanismo progressive disclosure, o revelación progresiva. Su ventaja es que una organización puede mantener una biblioteca amplia de conocimiento sin llenar la ventana de contexto del modelo con información que no tiene relación con la tarea actual.

En términos funcionales, el proceso se parece a lo siguiente:

Por ejemplo, ante la petición “prepara una propuesta para este cliente”, Claude podría activar la Skill comercial de la empresa. Al hacerlo, no dependería únicamente de lo que el usuario escribió en esa conversación. Tendría acceso al proceso aprobado, a la plantilla vigente, a los ejemplos disponibles y a las restricciones que deben respetarse.

Una Skill puede contener prompts, pero no es simplemente un prompt guardado.

Un prompt suele ser una instrucción puntual dentro de una conversación. Puede ser muy sofisticado, pero normalmente depende de que una persona recuerde utilizarlo, aporte el contexto necesario y verifique el resultado.

Una Skill empaqueta ese conocimiento en una estructura reutilizable. Puede incorporar recursos adicionales, establecer una secuencia de trabajo y mantenerse como una capacidad disponible para diferentes usuarios o agentes.

Tampoco es exactamente una herramienta. Una herramienta permite que el agente haga algo: consultar una base de datos, enviar un mensaje, crear un archivo o llamar una API. La Skill le explica cómo y cuándo utilizar esas capacidades para cumplir un objetivo específico.

Podemos expresarlo de esta manera:

El modelo aporta razonamiento. Las herramientas aportan acceso y acción. La Skill aporta procedimiento y contexto.

Una Skill para preparar un informe financiero, por ejemplo, podría indicar qué fuentes consultar, cómo validar los datos, qué cálculos ejecutar, qué formato utilizar y qué inconsistencias requieren intervención humana. Las herramientas permiten acceder a los sistemas; la Skill organiza el trabajo.

Buena parte del uso empresarial de la IA sigue siendo individual.

Una persona descubre una manera efectiva de preparar un análisis, guarda el prompt en un documento y lo reutiliza durante varias semanas. Quizá lo comparte con su equipo. Con el tiempo aparecen versiones distintas, cada una con pequeños cambios, y nadie sabe cuál representa la práctica actual.

Las Skills permiten imaginar una evolución desde esos experimentos personales hacia una memoria institucional.

La diferencia no es únicamente que la instrucción pueda compartirse. Es que puede tener un propósito claro, un propietario funcional, una versión, una fecha de revisión y un conjunto de recursos asociados. También puede evaluarse contra resultados reales.

Así, una compañía podría desarrollar capacidades reutilizables para preparar comités de inversión, investigar mercados, revisar propuestas, responder incidentes o incorporar nuevos product managers. Cada una recogería una parte del conocimiento operativo de la organización.

Eso no significa que la ventaja consista en acumular cientos de Skills.

De hecho, una biblioteca demasiado grande puede convertirse en una nueva forma de deuda. Aparecerán instrucciones duplicadas, criterios contradictorios y procesos que continúan ejecutándose meses después de haber perdido vigencia.

La ventaja estará en seleccionar unas pocas capacidades importantes y mantenerlas conectadas con el trabajo real.

BCG ha encontrado que las organizaciones que más valor obtienen de la IA tienden a concentrar sus recursos en prioridades estratégicas, mientras que las rezagadas dispersan la inversión entre demasiados casos de uso.

La misma lógica se aplica a las Skills.

Tres capacidades vinculadas con decisiones críticas pueden crear más valor que cien automatizaciones sin propietario, métrica ni mantenimiento.

Las Skills tampoco modifican los parámetros internos de Claude ni entrenan una versión nueva del modelo. No son fine-tuning.

Su conocimiento se incorpora durante la ejecución, cuando el agente descubre que la Skill es relevante y carga sus instrucciones. Esto facilita actualizar una política, corregir un procedimiento o sustituir una plantilla sin tener que volver a entrenar el modelo.

Esa separación tiene una consecuencia empresarial importante: el conocimiento de la organización puede evolucionar de forma independiente al proveedor de IA.

Una empresa puede cambiar una regla de aprobación, añadir un nuevo ejemplo o actualizar una política sin esperar una nueva versión del modelo. También puede revisar el historial de cambios y determinar quién modificó la forma en que el agente trabaja.

En su forma más básica, una Skill puede ser un manual operativo bien organizado. En su forma más avanzada, puede coordinar documentos, scripts, herramientas y criterios de decisión para ejecutar una parte significativa de un workflow.

Por eso su simplicidad no debe confundirse con falta de profundidad.

El formato es sencillo. Lo difícil es decidir qué conocimiento debe contener, quién tiene autoridad para definirlo y cómo comprobar que produce el resultado correcto.

Durante años, las empresas trataron el acceso a tecnología avanzada como una fuente de diferenciación. Quien podía comprar determinado software, contratar cierto talento o construir una infraestructura difícil de replicar obtenía una ventaja.

Con los modelos generativos ocurre algo diferente.

Una startup de diez personas y una corporación global pueden acceder, con diferencias de escala y gobierno, a capacidades de razonamiento similares. Ambas pueden generar texto, analizar documentos, escribir código o investigar un mercado.

Pero que dos organizaciones dispongan de la misma inteligencia general no significa que puedan utilizarla con la misma efectividad:

• Una empresa sabe, por ejemplo, que nunca debe ofrecer una integración personalizada antes de que arquitectura revise sus implicaciones.

• Otra ha aprendido que ciertos descuentos producen ingresos inmediatos, pero erosionan la relación con el cliente a largo plazo.

• Un equipo de producto conoce qué métricas representan adopción real y cuáles pueden inflarse sin generar valor.

• Un responsable de operaciones identifica en pocos minutos una anomalía que un analista nuevo tardaría días en reconocer.

Ese conocimiento no suele estar reunido en un solo lugar.

Una parte vive en políticas; otra, en documentos dispersos. Mucho permanece en conversaciones, hábitos y decisiones tomadas por personas con experiencia.

Las Skills ofrecen un mecanismo para empezar a convertir ese conocimiento en algo utilizable por un agente.

La innovación no consiste en que un archivo Markdown sea técnicamente revolucionario. Como señaló Simon Willison al analizar el lanzamiento, buena parte de su atractivo está precisamente en la simplicidad: texto, metadatos y recursos opcionales que el modelo puede utilizar cuando los necesita.

La simplicidad importa porque reduce la distancia entre el conocimiento de un experto y el sistema que debe aplicarlo.

Un responsable comercial no necesita comprender una arquitectura compleja para revisar las reglas de una Skill. Un product manager puede discutir sus criterios de priorización sin convertirse en ingeniero de modelos. Un equipo técnico puede añadir código determinista para aquellas operaciones que no deberían quedar abiertas a la improvisación de un sistema generativo.

Eso convierte a la Skill en un punto de encuentro entre negocio, producto y tecnología.

📌 Si llegaste hasta aquí, es porque te interesa ir más allá de la teoría, así que te invito a Xtrategas, mi comunidad para profesionales que lideran en producto, operaciones, tech, innovación y transformación digital.

¿Te unes?

únete hoy a Xtrategas Comunidad

La adopción de inteligencia artificial ya es amplia, pero su impacto continúa siendo desigual.

La encuesta global de McKinsey publicada en noviembre de 2025 encontró que el 88% de las organizaciones participantes utilizaba IA en al menos una función. Sin embargo, alrededor del 40% reportaba algún impacto en EBIT y, en la mayoría de los casos, esa contribución seguía siendo inferior al 5%.

Las empresas con resultados más significativos no se limitaban a desplegar herramientas: estaban rediseñando flujos de trabajo y utilizando la IA para transformar la manera en que operaban.

BCG describe una brecha parecida. En un estudio de más de 1.250 compañías, solo el 5% estaba obteniendo valor de IA a escala, mientras que el 60% reportaba ganancias materiales mínimas a pesar de sus inversiones.

Estos datos apuntan a una conclusión incómoda: tener IA no equivale a transformarse con IA.

Muchas compañías han seguido una secuencia predecible. Compran licencias, organizan talleres, recopilan casos de uso y celebran que algunos empleados ahorren varias horas por semana. Todo eso puede ser útil.

El problema aparece cuando esos avances individuales no modifican el sistema de trabajo.

Una organización puede tener miles de personas usando asistentes de IA y continuar atrapada en procesos fragmentados, decisiones poco claras y múltiples capas de revisión. Incluso puede producir más rápido sin mejorar el resultado: más informes, más presentaciones y más análisis que nadie convierte en decisiones.

La regla 10-20-70 explica esta dificultad. Alrededor del 10% del esfuerzo de una transformación corresponde a algoritmos, el 20% a tecnología y datos, y el 70% a personas, procesos y cambio organizacional.

No es una ley matemática, sino una forma de corregir una tendencia habitual: dedicar casi toda la atención al componente tecnológico y muy poca a la manera en que el trabajo debe cambiar.

En este contexto las Skills son relevantes porque obligan a entrar en ese 70%.

Construir una buena Skill requiere definir cuál es el resultado esperado, qué información necesita el agente, qué pasos agregan valor, qué criterios deben aplicarse y qué excepciones obligan a detener la ejecución. También exige decidir cuándo el sistema puede actuar y cuándo necesita la intervención de una persona.

Esas no son preguntas de prompting. Son preguntas de diseño organizacional.

Y revelan por qué tantas iniciativas de IA se quedan en la superficie. Es relativamente sencillo pedirle a un modelo que redacte una propuesta. Es mucho más difícil explicar qué hace que una propuesta sea aceptable para ventas, viable para operaciones, rentable para finanzas y prudente para legal.

La tecnología puede generar el documento en segundos.

La organización todavía debe ponerse de acuerdo sobre qué significa que el documento sea bueno.

En casi todas las compañías existe alguien que “sabe cómo se hace”.

No siempre es la persona con el cargo más alto ni quien produce más documentación. Es quien recuerda las excepciones, reconoce patrones y sabe por qué una regla escrita no debe aplicarse literalmente en determinada situación.

Imaginemos a Laura, responsable comercial de una empresa de servicios profesionales.

Antes de enviar una propuesta importante, el equipo se la entrega para revisión. Laura ajusta el lenguaje según el sector del cliente, detecta descuentos que comprometerían el margen y elimina promesas que el equipo de implementación no podría cumplir.

También reconoce señales que no aparecen en ningún manual: un cliente que insiste demasiado en personalizaciones, una fecha aparentemente inocente que creará un problema de capacidad o una cláusula que suele anticipar una negociación difícil.

Teoricamente, la compañía tiene un proceso comercial. En la práctica, tiene a Laura.

Mientras ella está disponible, el sistema parece funcionar. El problema aparece cuando se va de vacaciones, cambia de rol o abandona la organización. Entonces se descubre que buena parte del proceso nunca estuvo realmente en el CRM ni en la plantilla.

Estaba en sus decisiones.

Una Skill puede ayudar a transformar una parte de ese conocimiento en capacidad organizacional. Puede reunir las preguntas que Laura formula, las señales que revisa, los límites que no permite cruzar, los ejemplos que considera buenos y los casos que deberían escalarse.

Pero sería un error interpretar este proceso como una forma de “extraer” el conocimiento de Laura para reemplazarla.

El objetivo más valioso es liberar su atención.

En lugar de corregir una y otra vez los mismos errores, Laura puede ayudar a diseñar el sistema que los detecta.

En lugar de ser un cuello de botella para cada propuesta, puede concentrarse en las excepciones complejas.

En lugar de transmitir su experiencia únicamente mediante conversaciones informales, puede convertir parte de ella en un recurso que mejora el desempeño de todo el equipo.

Su papel no desaparece. Evoluciona.

Pasa de ejecutar cada revisión a definir criterios, evaluar resultados y actualizar el sistema a partir de casos nuevos.

Esta posibilidad resulta especialmente relevante en América Latina. ILIA 2025 muestra una región que adopta IA con dinamismo, pero que todavía enfrenta brechas significativas de talento, inversión, infraestructura y gobernanza. En muchas empresas medianas, esas limitaciones se combinan con una fuerte dependencia de personas clave y procesos documentados de manera irregular.

En ese contexto, convertir conocimiento crítico en una capacidad compartida no es únicamente una estrategia de productividad. También es una forma de continuidad empresarial.

Una Skill no debería convertirse en un manual estático con otro nombre.

Si una organización toma un proceso deficiente, lo documenta y se lo entrega a un agente, no ha producido una transformación. Solo ha conseguido ejecutar la mediocridad con más velocidad y consistencia.

Antes de codificar un proceso, es necesario observar cómo funciona realmente.

Consideremos la priorización de producto.

Un equipo podría crear una Skill que reúna la estrategia, los segmentos prioritarios, los criterios de impacto, las restricciones técnicas y el formato utilizado para presentar una recomendación.

Eso podría mejorar la calidad y comparabilidad de los análisis. El agente podría detectar información faltante, cuestionar supuestos o identificar contradicciones con la estrategia.

Pero la Skill no debería decidir automáticamente el roadmap.

Priorizar un producto no es sumar puntos en una matriz. Implica interpretar señales ambiguas, equilibrar oportunidades y renuncias, y entender qué apuesta tiene sentido para una compañía en un momento determinado.

La Skill puede estructurar el razonamiento; no debe ocultar que sigue existiendo una decisión.

Distingue lo que puede ejecutarse de forma determinista, lo que puede ser recomendado por el agente y lo que debe permanecer bajo juicio humano. Por eso el diseño de la Skill también es un ejercicio de claridad organizacional: obliga a separar reglas, heurísticas, excepciones y decisiones.

La aparición de agentes modifica el trabajo gerencial (Lee aquí mi entrada sobre Allocation Economy, y el fin de la economía del conocimiento).

Hasta ahora, los líderes distribuían responsabilidades principalmente entre personas. En una organización asistida por agentes también tendrán que decidir cómo se reparte el trabajo entre humanos, modelos, herramientas y mecanismos de control.

Harvard Business Review ha comenzado a utilizar el concepto de agent manager para describir a los responsables de coordinar el desempeño, el aprendizaje y la seguridad de sistemas agénticos.

Otros análisis recientes de la misma publicación sostienen que escalar agentes es, ante todo, un problema de rediseño del trabajo y onboarding, no una simple instalación tecnológica.

La metáfora tiene límites. Un agente no es un empleado y tratarlo literalmente como una persona puede confundir la atribución de responsabilidad.

Sin embargo, el cambio gerencial es real.

Alguien debe definir qué resultado se espera del agente, qué fuentes puede utilizar, qué acciones puede ejecutar y qué situaciones requieren supervisión. Alguien debe observar sus fallos, actualizar las instrucciones y responder cuando una decisión produce consecuencias no previstas.

La responsabilidad del líder no será motivar al agente, sino diseñar el sistema en el que opera.

Esto exige una forma de liderazgo más explícita.

Muchas empresas funcionan gracias a reglas que nunca fueron formalizadas: “ese cliente necesita otra revisión”, “esa métrica no cuenta toda la historia”, “no podemos lanzar si soporte no está preparado” o “en ese mercado la decisión debe involucrar al equipo local”.

Los agentes no absorben esas reglas recorriendo una oficina ni observando durante años cómo trabajan sus colegas.

La organización tiene que expresarlas.

Para trabajar con agentes, las empresas deben traducir principios tácitos y criterios de decisión en orientación estructurada.

Ese proceso puede ser incómodo porque revela desacuerdos que antes permanecían ocultos.

Quizá ventas, producto y finanzas creen seguir la misma política, pero interpretan sus límites de manera diferente. Tal vez un proceso que parecía consistente depende en realidad de negociaciones informales. Puede incluso descubrirse que nadie tiene autoridad clara para decidir cuál es la práctica correcta.

Crear una Skill no resuelve automáticamente esos conflictos. Los hace visibles.

Y esa visibilidad es parte de su valor.

Si aún no te has suscrito a Xtrategia, te invito a hacerlo dando click aquí:

La organización no necesita iniciar con un catálogo corporativo ni con un programa de varios años. Puede comenzar con una capacidad delimitada.

1. El primer paso es identificar un conocimiento cuya pérdida o aplicación inconsistente tenga consecuencias reales. Puede tratarse de una actividad que dependa demasiado de una persona, genere errores frecuentes o retrase al resto del equipo.

2. Después es necesario asignar un propietario funcional. Tecnología puede ayudar a implementar la Skill, pero no debería decidir por sí sola qué significa una propuesta comercial correcta, una investigación suficiente o una priorización de producto razonable.

3. El tercer paso consiste en observar el trabajo. No basta con preguntar cuál es el proceso oficial. Hay que revisar casos reales, excepciones, correcciones y decisiones anteriores. Con frecuencia, la diferencia entre el manual y la práctica contiene la parte más valiosa del conocimiento.

4. A continuación deben definirse las fronteras de autonomía. El agente puede preparar un borrador, detectar inconsistencias o recomendar una clasificación. Eso no implica que deba aprobar un descuento, enviar una comunicación legal o tomar una decisión irreversible.

5. Por último, la Skill necesita una forma de aprendizaje. Cada error debe permitir distinguir si falló el modelo, faltaba contexto, la regla era incorrecta o el proceso humano también estaba mal diseñado.

Una Skill que no aprende se convierte rápidamente en conocimiento obsoleto ejecutado con confianza.

Las Skills no son inocuas.

Pueden incluir código, acceder a archivos, utilizar herramientas y orientar al agente hacia acciones concretas. La documentación de Anthropic recomienda revisar tanto las instrucciones como los scripts, las dependencias y las conexiones externas, especialmente cuando la Skill procede de terceros.

Esto significa que una biblioteca empresarial de Skills debe gobernarse con una disciplina parecida a la del software. Necesita revisión, permisos mínimos, pruebas controladas, versiones, responsables y mecanismos de retiro.

Pero la seguridad técnica es solo una parte del problema.

Una Skill puede estar perfectamente protegida y, aun así, representar una mala decisión.

Puede consolidar el sesgo de una persona influyente, perpetuar una política desactualizada o convertir una excepción histórica en una regla permanente.

Por eso la pregunta crítica no es únicamente quién puede escribir una Skill.

Es quién tiene la autoridad para afirmar que esa Skill representa correctamente la manera en que la organización debe trabajar.

Cuando una instrucción dice “así se hacen las cosas aquí”, conviene preguntarse quién participó en esa definición, qué evidencia la respalda, cuándo fue revisada y cómo puede cuestionarse.

La gobernanza de las Skills no es solo gobierno de tecnología.

Es gobierno del conocimiento.

La próxima ventaja empresarial no consistirá en tener acceso al modelo más nuevo durante unas semanas.

Tampoco en producir más documentos o construir la mayor colección de automatizaciones.

Aparecerá cuando una organización sea capaz de identificar qué conocimiento crea valor, hacerlo explícito sin simplificarlo en exceso, conectarlo con procesos reales y mantenerlo actualizado. También deberá saber qué parte de ese conocimiento puede convertirse en una regla, qué parte puede asistir una recomendación y qué parte debe seguir dependiendo del juicio humano.

Las Skills son una manifestación temprana de esa transición.

No constituyen por sí solas una estrategia de inteligencia artificial. Pero hacen visible la capa en la que probablemente se decidirá buena parte del valor: la capacidad de una empresa para enseñar a sus sistemas cómo trabaja, cómo decide y dónde están sus límites.

Todos podrán acceder a inteligencia artificial.

No todos podrán convertir su experiencia acumulada en una capacidad escalable.

La conversación debería comenzar con una pregunta sencilla:

Si mañana se fueran las tres personas que mejor comprenden cómo funciona nuestro negocio, ¿qué conocimiento desaparecería con ellas?

La respuesta no es todavía una Skill.

Pero sí es el mapa de las primeras que vale la pena construir.

Deja un comentario

Gracias por leerme.

Si esta newsletter te resultó útil, compártela con un líder de tu red que siga usando IA sin muchos resultados. Nos ayuda a crecer y a ellos les puede cambiar la perspectiva.

Nos leemos la próxima semana.

Oscar Durán - @duranoscarf en instagram y Linkedin

Comparte Xtrategia Newsletter con alguien que creas le puede agregar valor.

Compartir Xtrategia

1. Anthropic — “Equipping agents for the real world with Agent Skills”
   Fuente principal para definir qué son las Skills, cómo funcionan y por qué usan revelación progresiva.
   https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills

2. Anthropic — “Agent Skills: Overview”
   Documentación oficial sobre estructura, activación, recursos, scripts y funcionamiento técnico.
   https://console.anthropic.com/docs/en/agents-and-tools/agent-skills/overview

3. Simon Willison — “Claude Skills are awesome, maybe a bigger deal than MCP”
   Análisis independiente clave sobre la simplicidad, portabilidad y relevancia estratégica del formato.
   https://simonwillison.net/2025/Oct/16/claude-skills/

4. McKinsey — “The State of AI 2025”
   Fuente para adopción de IA, impacto en EBIT, escalamiento de agentes y rediseño de workflows.
   https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

5. BCG — “Are You Generating Value from AI? The Widening Gap”
   Fuente principal para la brecha entre adopción y valor, y la concentración de esfuerzos en pocos casos estratégicos.
   https://www.bcg.com/publications/2025/are-you-generating-value-from-ai-the-widening-gap

6. BCG — “Closing the AI Impact Gap”
   Sustenta el argumento sobre personas, procesos, transformación organizacional y captura de valor.
   https://www.bcg.com/publications/2025/closing-the-ai-impact-gap

7. Harvard Business Review — “To Thrive in the AI Era, Companies Need Agent Managers”
   Fuente central para el concepto de agent manager y el cambio del rol gerencial.
   https://hbr.org/2026/02/to-thrive-in-the-ai-era-companies-need-agent-managers

8. Harvard Business Review — “Research: Why You Shouldn’t Treat AI Agents Like Employees”
   Útil para matizar la narrativa y evitar antropomorfizar a los agentes.
   https://hbr.org/2026/05/research-why-you-shouldnt-treat-ai-agents-like-employees

9. CEPAL y CENIA — “Latin American Artificial Intelligence Index, ILIA 2025”
   Fuente principal para la lente LATAM: adopción, talento, infraestructura, inversión y gobernanza.
   https://www.cepal.org/en/publications/84471-latin-american-artificial-intelligence-index-ilia-2025-executive-summary

10. Anthropic — “Our framework for developing safe and trustworthy agents”
    Fuente para riesgos, autonomía, seguridad, prompt injection y gobernanza de agentes.
    https://www.anthropic.com/news/our-framework-for-developing-safe-and-trustworthy-agents