Hay un tipo de consejo sobre inteligencia artificial que parece útil hasta la tercera vez que necesitas seguirlo.

“Usa este prompt: el pedido, escrito o hablado, que orienta lo que debe hacer la IA”.

“Antes, dile a la IA que investigue”.

“Después, pídele que asuma el papel de especialista”.

“No olvides exigir fuentes, definir el formato, pedir una revisión, comprobar los riesgos, preservar el contexto y solicitar la respuesta en una tabla”.

Perfecto. Ahora solo hace falta que la persona recuerde organizar una pequeña licitación pública cada vez que quiera resolver un problema.

No estoy en contra de los prompts. El pedido sigue siendo la forma más directa de decirle a la máquina lo que quiero. Lo que me incomoda es la expectativa de que cada usuario tenga que memorizar la coreografía operativa de la IA: cuándo investigar, qué herramienta activar, cómo transferir el contexto, qué datos no exponer, qué validación ejecutar y hasta dónde puede llegar el agente de IA —un sistema que recibe contexto, usa herramientas y ejecuta pasos para alcanzar un objetivo— sin pedir una decisión.

Si el trabajo es recurrente, esos criterios no deberían seguir viviendo solo en la memoria de quien hace el pedido. Deberían estar en el sistema.

Tener una carpeta llena de skills —instrucciones y capacidades reutilizables para ejecutar una clase de tarea— sin saber cuándo activarlas es como coleccionar superpoderes y dejarlos fuera de escena justo cuando aparece el problema. No sé tú, pero cuando yo veía Heroes y observaba a Sylar acumular habilidades, lo que sentía sobre todo era indignación —con algo de nerviosismo incluido—. La situación se complicaba, yo recordaba una habilidad que él ya había adquirido y que parecía perfecta para ese momento, y sentía unas ganas casi físicas de avisarle al personaje a través de la pantalla: “¡Vamos, hombre! Ya tienes la herramienta adecuada; úsala”. Para mejorar mi indignación, su arsenal incluía incluso una supermemoria. Eso era exactamente lo que me irritaba como espectador: una capacidad disponible en el inventario no equivale a una capacidad disponible en la práctica.

Una skill instalada, pero que el agente nunca reconoce en el contexto adecuado, sigue siendo un superpoder olvidado. El usuario no debería tener que recordar el nombre exacto de la habilidad ni prescribir cada paso para traerla al escenario. El Harness de IA —el conjunto de contexto, reglas y criterios que decide cuándo y cómo usar esas capacidades— debe conectar el pedido natural con el contrato de esa ejecución.

Ahí también entran los recursos y scripts usados por las skills, las reglas de activación, los contratos, los datos de contexto, los flujos de trabajo, las validaciones y los límites. No como palabras sofisticadas para vender un prompt más largo. Como partes de la operación.

El objetivo práctico es sencillo: hago un pedido natural; el sistema reconoce el tipo de trabajo, carga la skill adecuada y sigue el proceso ya acordado. Yo sigo marcando la dirección. Solo que no necesito volver a aprender a conducir por la misma rotonda cada mañana.

Esto no sucede porque la IA haya adquirido intuición. Depende de que alguien diseñe las señales de activación, pruebe casos reales, corrija malas elecciones y mantenga actualizadas las reglas y las fuentes.

El usuario no debería tener que navegar por un menú invisible de trucos —/investiga, /transfiere, /revisa, /ahora-sé-especialista— para que la operación funcione. Describe el resultado, aporta el contexto que solo él conoce y declara las restricciones. El Harness elige la capacidad y el procedimiento aplicables; si hay dos rutas plausibles, falta autorización o la decisión tiene consecuencias reales, pregunta en lugar de elegir a escondidas.

Un buen prompt ayuda. Un buen sistema deja de depender de mi memoria

Un prompt improvisado puede producir una respuesta excelente. También puede producir una respuesta excelente el lunes, una mediocre el martes y una pequeña obra de ficción corporativa el miércoles.

El problema no es solo la calidad del texto que escribí en el campo de conversación. Es todo lo que quedó fuera porque tenía prisa, estaba cansado o simplemente me parecía obvio.

Compara:

Investiga este tema y entrégame un informe completo.

Con un pedido dirigido a un Harness que ya conoce el contrato de investigación:

Quiero entender si esta solución tiene sentido para nuestro escenario.

En el segundo caso, la frase es más corta, pero el trabajo que hay detrás puede ser mayor. La skill de investigación sabe que necesita identificar la decisión en juego, priorizar fuentes primarias, separar la evidencia de la inferencia, registrar límites, comprobar la vigencia de la información, comparar alternativas y no convertir una página comercial en una prueba independiente.

No tuve que recitar esa lista de comprobación porque ya había sido discutida, escrita, probada y versionada.

La documentación de GitHub describe precisamente esta función de las Agent Skills: instrucciones, scripts y recursos que se cargan cuando son relevantes para una tarea especializada. La propia orientación diferencia las reglas generales, que caben en las instrucciones del proyecto, de los procedimientos detallados, que solo deberían entrar en contexto cuando sean necesarios.

Esto es importante porque meter todas las reglas en cada pedido tampoco resuelve el problema. Solo cambia la amnesia por la congestión.

La skill adecuada debe aparecer sin convertirse en una palabra mágica

Una skill útil no es un amuleto llamado respuesta-perfecta.md.

Debe declarar al menos:

• qué problema sabe resolver;
• qué señales deben activarla;
• qué información mínima requiere;
• qué fuentes y herramientas puede usar;
• cuándo investigar antes de afirmar y cuándo transferir el trabajo a otro especialista;
• qué pasos no se pueden omitir;
• qué formato de salida entrega;
• cómo se verificará la calidad;
• qué autorización recibió y qué acciones siguen fuera de su alcance;
• cuándo debe detenerse y pedir juicio humano.

La descripción forma parte del comportamiento. Si una skill solo dice “ayuda con la investigación”, casi cualquier cosa puede activarla y casi nada define lo que debería hacer. Si dice que debe usarse cuando una afirmación actual, la elección de un proveedor o una decisión de arquitectura depende de evidencia externa, el agente dispone de una frontera más útil.

GitHub documenta que el agente puede seleccionar una skill a partir de la descripción de la tarea. Eso no demuestra que la selección vaya a ser perfecta en cualquier herramienta o contexto. Demuestra algo más modesto y más importante para este artículo: ya existe una implementación concreta de la idea de cargar instrucciones especializadas en el momento oportuno, en lugar de obligar al usuario a pegarlas manualmente en cada conversación.

Si Sylar representa la frustración de tener la capacidad y no activarla, Batman representa el uso positivo. No es Batman solo porque lleve un cinturón de utilidades; lo es porque reconoce la herramienta adecuada, sabe cómo usarla y la pone en acción en el momento oportuno. Eso es lo que una skill bien integrada en el Harness debe hacer por la operación —sin capa, porque los presupuestos también tienen límites—.

El pedido natural sigue siendo necesario. El ritual entero, no.

La investigación profunda no debería depender de que recuerde pedirla

Si pregunto qué color queda mejor en un botón, quizá no sea necesario iniciar una expedición científica.

Si pregunto si una arquitectura debería almacenar datos personales en otro país, responder solo con lo que recuerda el modelo sería irresponsable.

El usuario común no debería tener que conocer el nombre del modo de investigación, decidir cuántas búsquedas hacer ni ordenarle al agente que “razone paso a paso”. El Harness puede reconocer las señales: un tema de actualidad, una decisión costosa, un riesgo jurídico, una referencia específica, información incierta o una afirmación que se va a publicar.

En ese caso, activa el proceso adecuado, informa que va a investigar y devuelve no solo una conclusión, sino también el camino verificable que conduce hasta ella.

Eso no elimina una pregunta esencial al usuario:

¿Qué pretendes decidir con esta investigación?

Sin un objetivo, incluso una investigación impecable puede resolver el problema equivocado con referencias muy bonitas.

Transferir contexto no es copiar toda la conversación y rezar

Otro prompt recurrente es: “continúa desde donde lo dejamos”.

¿Desde dónde, exactamente?

Una tarea larga acumula decisiones, archivos, hipótesis, resultados de pruebas, asuntos pendientes, autorizaciones y cosas que parecían ciertas hace tres horas. Copiar toda la conversación transfiere volumen, no necesariamente contexto útil. Es el juego del teléfono con un anexo de 80 páginas.

Una skill de transferencia de contexto puede exigir un paquete mínimo:

• objetivo actual;
• estado real del trabajo;
• decisiones ya adoptadas;
• hipótesis que siguen abiertas;
• archivos y sistemas involucrados;
• validaciones ejecutadas;
• riesgos, bloqueos y siguiente paso;
• lo que la nueva tarea está autorizada —y no autorizada— a hacer.

El usuario puede decir “lleva esto a otra tarea”. El Harness debería saber que “esto” no significa volcarlo todo. Significa preservar el estado que permite continuar sin inventar continuidad.

“Revisar” debe significar algo más que releer con la misma confianza

Cuando pido una revisión, no quiero que la misma respuesta cambie tres adjetivos y vuelva con gafas.

Una skill de revisión necesita conocer el objeto y el criterio. El código puede exigir pruebas, análisis del diff, compatibilidad y riesgos. Un artículo puede exigir coherencia autoral, fuentes, enlaces, afirmaciones contundentes, traducción, lectura en dispositivos móviles y metadatos. Una decisión puede exigir que alguien busque premisas frágiles y alternativas que fueron ignoradas.

El trabajo puede usar flujos diferentes. Anthropic describe, en su texto sobre la construcción de agentes eficaces, patrones como el encadenamiento, el enrutamiento, la ejecución en paralelo y un ciclo en el que una etapa produce y otra evalúa según criterios definidos. La empresa también recomienda empezar por la solución más sencilla que funcione y añadir complejidad solo cuando aporte un resultado medible.

Esto respalda el patrón técnico, no una promesa de calidad automática. Un mal evaluador puede aprobar una mala respuesta con una solemnidad impresionante. El criterio todavía necesita ser escrito, probado y revisado por personas que entienden el trabajo.

Los datos sensibles deben cambiar la ruta antes de entrar en el prompt

“Resume esta hoja de cálculo” puede ser un pedido inocente.

La hoja de cálculo puede contener salarios, diagnósticos, documentos, contratos, secretos comerciales o información de alguien que nunca autorizó que se enviara a un proveedor externo.

No es razonable esperar que cada colaborador recuerde recitar, en cada conversación, la política de datos de la empresa. Tampoco es razonable concluir que una línea en el prompt convierte un flujo inseguro en uno seguro.

El Harness debería clasificar el contexto antes de actuar y aplicar reglas como estas:

• minimizar los datos utilizados;
• preferir el procesamiento local o un entorno aprobado cuando sea necesario;
• eliminar los identificadores que no sean necesarios;
• bloquear proveedores o herramientas que estén fuera de la política;
• pedir autorización cuando la finalidad no esté cubierta;
• registrar qué se transmitió sin copiar el contenido sensible en el registro.

El perfil para riesgos de IA generativa del Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) trata la gestión de riesgos como un trabajo de gobernanza, mapeo, medición y gestión a lo largo del ciclo de vida. No ofrece una configuración universal para tu Harness ni certifica que se vaya a cumplir una política escrita en Markdown. Aquí sirve para sustentar la necesidad de contexto, responsabilidades, evaluación y monitoreo, no para delegar en el NIST una decisión que sigue siendo responsabilidad de la organización.

Publicar no es sinónimo de terminar de escribir

Una de las diferencias más importantes entre un chatbot y una operación es que generar un artefacto no concede automáticamente el derecho de ponerlo en el mundo.

Si digo “prepara un post”, una skill editorial puede investigar, escribir, revisar enlaces, generar una imagen, validar el sitio y abrir una versión para evaluación. Aun así, la publicación puede requerir mi aprobación explícita.

Si digo “publica el siguiente texto aprobado”, el Harness puede comprobar:

• si hay una aprobación humana registrada;
• si la revisión técnica ha terminado;
• si la fecha representa la publicación real;
• si las traducciones, la imagen y los metadatos están completos;
• si existe una dependencia con otro contenido;
• si el entorno de producción está en buen estado;
• si hay una vía para revertir la acción.

Fíjate en la diferencia: la skill no me obliga a recordar cada condición que debe cumplirse antes de avanzar —cada gate—, pero tampoco convierte mi frase en una autorización infinita.

Esto vale para una campaña, un cambio de infraestructura, un pago o un correo electrónico. La acción final puede ser sencilla; las condiciones para llegar hasta ella no lo son.

Lo que sigue siendo responsabilidad de quien hace el pedido

Quiero eliminar la coreografía inútil, no la responsabilidad.

El usuario todavía tiene que aportar cuatro cosas que ningún paquete de instrucciones debería inventar:

1. Objetivo

¿Qué debe cambiar en el mundo después del trabajo?

“Analiza los datos” es una actividad. “Quiero decidir si debo mantener este producto” es una dirección.

2. Contexto que solo él conoce

Una skill puede saber dónde buscar los archivos. No sabe que el proveedor prometió una condición ajena al contrato, que el equipo perdió a una persona o que la prioridad cambió en la reunión de ayer, a menos que eso se haya registrado y sea accesible.

3. Restricciones reales

Plazo, presupuesto, privacidad, infraestructura, riesgo aceptable, personas afectadas y aquello que no se puede modificar. Si la restricción cambia el camino, debe estar en el pedido o en una fuente de contexto confiable.

4. Decisión

El agente puede organizar evidencia, mostrar escenarios y señalar inconsistencias. La decisión que compromete dinero, personas, reputación o rumbo sigue necesitando un responsable identificable.

Ya he escrito que los datos no deciden por nosotros. Las skills tampoco.

Lo que sigue siendo responsabilidad de la organización

Una empresa no “instala” skills y da el asunto por terminado.

Necesita observar el uso real:

• ¿la skill se activa ante los pedidos correctos?;
• ¿deja de aparecer cuando debería hacerlo?;
• ¿pide demasiado contexto o demasiado poco?;
• ¿sus fuentes siguen siendo válidas?;
• ¿los scripts todavía funcionan?;
• ¿las validaciones detectan defectos reales?;
• ¿los límites reflejan la política actual?;
• ¿el costo y el tiempo siguen teniendo sentido?;
• ¿las personas pueden cuestionar y corregir el resultado?

El contexto envejece. Los procesos cambian. Las herramientas se sustituyen. Una skill que resolvió el problema de enero puede automatizar en septiembre una regla ya retirada con una eficiencia admirable.

OpenAI relata, en su artículo sobre ingeniería de Harness, que concentrarlo todo en un AGENTS.md gigantesco provocó un exceso de instrucciones, pérdida de contexto útil, envejecimiento y dificultades de verificación. La dirección descrita consiste en usar el archivo como mapa hacia fuentes de verdad más pequeñas y estructuradas.

No es una ley universal ni demuestra que la misma arquitectura sirva para todas las empresas. Es un relato primario de implementación que encaja con el problema: los criterios operativos deben ser localizables, específicos y verificables. Un prompt de 40 páginas pegado en cada conversación no es madurez. Es vaciar un archivador encima de la mesa.

Esto no se llama autonomía ciega

Cuando el sistema reconoce una tarea y aplica la skill adecuada, parece que la IA “ya sabe qué hacer”. La frase es cómoda, pero merece cautela.

No sabe como sabe una persona. Recibe descripciones, reglas, herramientas, contexto y señales que aumentan la probabilidad de elegir un camino útil. Esa selección puede fallar. La ejecución puede fallar. El entorno puede haber cambiado. Dos reglas pueden entrar en conflicto.

Por eso, un Harness confiable también debe incluir:

• estados de incertidumbre;
• criterios de parada;
• permisos proporcionales al riesgo;
• evidencia de lo que se ejecutó;
• evaluaciones repetibles;
• revisión humana en los puntos de impacto;
• reversión cuando la acción modifica algo real.

La documentación de OpenAI sobre Codex describe AGENTS.md como una forma de registrar la organización del proyecto, los comandos de prueba y las prácticas esperadas. La documentación también destaca los entornos configurados, las pruebas confiables y la evidencia verificable. No dice “escribe dos reglas y confía para siempre”. Es justo lo contrario: convierte las expectativas en contratos y los resultados en algo que pueda comprobarse.

Cómo empezaría sin construir la NASA para enviar un correo electrónico

Elige una tarea recurrente que hoy dependa de que alguien recuerde muchos detalles. No empieces por la más crítica de la empresa.

Puede ser preparar una investigación, revisar una propuesta, organizar el contexto de una reunión o validar un artículo antes de la evaluación.

Después:

1. registra tres buenos ejemplos y tres malos;
2. escribe cuándo la skill debe activarse y cuándo no;
3. define las entradas mínimas y qué se debe preguntar;
4. convierte el proceso real en pasos cortos;
5. marca los gates que exigen una decisión humana;
6. automatiza solo las comprobaciones que puedan demostrarse;
7. ejecuta la skill con los ejemplos;
8. revisa los errores y actualiza el contrato;
9. observa si mejora la consistencia, el tiempo o el retrabajo;
10. retira la skill si solo añade ceremonia.

Un prompt inicial podría ser:

Ayúdame a convertir esta tarea recurrente en una skill para mi agente. Primero, identifica el objetivo, las señales de activación, el contexto mínimo, las herramientas, los pasos, el formato de salida, las validaciones, los límites y las decisiones que siguen siendo humanas. Usa tres casos reales que salieron bien y tres que salieron mal. No escribas la versión final antes de señalar ambigüedades y riesgos. Después, propón una prueba pequeña, reversible y medible.

Eso todavía no produce una skill confiable. Produce un primer artefacto para discutir. La confiabilidad comienza cuando el texto se encuentra con casos reales y sobrevive a ellos.

La mejor interfaz puede volver a ser una frase normal

Invierto mucho tiempo en perfeccionar mis agentes para que, cuando llegue el momento de trabajar, no tenga que invertir el mismo tiempo en enseñarlo todo de nuevo.

Esa es la parte aparentemente contradictoria: detrás de un pedido sencillo puede haber un sistema complejo. No porque quiera ocultar la complejidad con una demostración vistosa, sino porque he decidido dónde debe residir.

La investigación tiene un contrato de investigación. La publicación tiene un gate de publicación. Los datos sensibles cambian la ruta. La revisión busca defectos según criterios. La transferencia de contexto preserva el estado. El agente recibe herramientas compatibles con la tarea y se detiene cuando encuentra una decisión que me corresponde.

El mercado seguirá vendiendo el prompt definitivo de la semana. Algunos serán útiles. Probablemente aprovecharé ideas de varios de ellos.

Solo que no quiero depender de recordar que el encantamiento correcto era Wingardium Leviosa —sin soltar la versión de Ron y conseguir que Hermione me corrija el énfasis— antes de cada trabajo.

Quiero decir lo que necesito y aportar el contexto que solo yo tengo. El Harness reconoce la capacidad, aplica el procedimiento y respeta las condiciones que ya hemos acordado.

El prompt sigue siendo la conversación.

El Harness es lo que impide que la conversación tenga que reinventar toda la empresa cada vez que abro la boca.

Si este es el tipo de operación que quieres construir —menos ritual, más contexto y resultados verificables—, conoce I-9.ai.

Sigue leyendo

• El modelo es solo el motor. El Harness de IA es el auto completo
• ¿Tu agente sabe cuándo detenerse?
• Si nadie sabe qué sucede después, no tienes un workflow
• Mi Harness aprende, pero no obtiene licencia para reescribir el pasado

Referencias y límites de uso

• GitHub Docs — About agent skills: sustenta la definición de skill como paquete de instrucciones, scripts y recursos que puede cargarse para un trabajo especializado. No demuestra que la activación vaya a ser correcta en todos los agentes ni que una skill sea buena por el mero hecho de existir.
• GitHub Docs — Adding agent skills for GitHub Copilot: sustenta el papel de la descripción en la activación y la distinción entre instrucciones generales y skills específicas. Se refiere al comportamiento documentado de GitHub Copilot.
• Anthropic — Building Effective AI Agents: sustenta los patrones de enrutamiento, encadenamiento, evaluación y orquestación, además de la recomendación de empezar por lo sencillo. Es la experiencia publicada por un proveedor, no una comparación independiente sobre el retorno empresarial.
• Anthropic — Effective context engineering for AI agents: sustenta la distinción entre optimizar un prompt aislado y cuidar el conjunto de instrucciones, herramientas, memoria, historial y datos disponibles para el agente. Es orientación técnica del propio proveedor.
• NIST AI 600-1 — Perfil de Inteligencia Artificial Generativa: sustenta el enfoque de gobernanza y gestión de riesgos a lo largo del ciclo de vida. No ofrece una arquitectura lista para usar ni certifica los controles descritos en este texto.
• OpenAI — Harness engineering: sustenta el relato sobre los límites de un archivo monolítico de instrucciones y el uso de documentación estructurada como fuente de verdad. Es un caso de implementación de OpenAI, no una regla universal.
• OpenAI — Introducing Codex: sustenta el uso de AGENTS.md, entornos configurados, pruebas y evidencia verificable en Codex. No demuestra autonomía ni confiabilidad para cualquier tarea fuera del contexto descrito.