Diseño, perfeccionamiento y mantenimiento de agent skills en Perplexity

Los productos de agentes de vanguardia de Perplexity se basan en una base de conocimientos y experiencia en el dominio empaquetada en Skill modulares. Mantenemos una biblioteca cuidadosamente seleccionada de Skill en todos nuestros entornos técnicos. Estas Skill incluyen muchas de las utilidades de propósito general que impulsan Perplexity Computer; capacidades específicas de sectores verticales en áreas como finanzas, derecho y salud; y una larga cola de módulos para satisfacer las necesidades de los usuarios. Algunas Skill se invocan con poca frecuencia, pero son fundamentales cuando se invocan. Para garantizar una experiencia de usuario sistemáticamente excelente, el equipo de agentes de Perplexity prioriza la calidad de las Skill tanto como la calidad del código.

Las intuiciones y las mejores prácticas necesarias para desarrollar una Skill de alta calidad difieren significativamente de las necesarias para crear software tradicional. El equipo de agentes revisa muchas solicitudes de incorporación de cambios (pull requests) de ingenieros excelentes que desarrollan Skill en el curso de su trabajo. El resultado es casi siempre numerosos comentarios y sugerencias de revisión. Esto se debe a que muchos patrones útiles para escribir código se convierten en antipatrones en la creación de Skill.

Por ejemplo, si tomas algunos de los aforismos de PEP20 – The Zen of Python, rápidamente queda claro que escribir buen código Python no se parece en nada a escribir buenas Skill. De las 20 líneas de sabiduría, al menos la mitad son totalmente erróneas o inducen activamente a error al escribir Skill. Aquí tienes cinco de ellas:

Cinco contrastes entre el Zen de Python y las recomendaciones del artículo para escribir Skills.

Esta guía es el documento que los ingenieros de todo Perplexity utilizan al desarrollar y revisar Skill. También estamos publicando esta guía para el público de modo que nuestros descubrimientos y aprendizajes puedan beneficiar a la comunidad en general. Ya seas un ingeniero que diseña Skill de producción en su trabajo diario, un usuario de Computer que busca desarrollar su propia Skill en un área que conoce bien, o ambas cosas, esta guía es para ti.

¿Qué es una Skill?

Cuando escribes una Skill, no estás escribiendo software convencional (aunque las Skill ahora formen parte de los motores lógicos principales para los sistemas de agentes). Más bien, estás construyendo un contexto para los modelos y sus entornos. Una Skill tiene diferentes restricciones y diferentes principios de diseño. Si escribes una Skill como si escribieras código, fracasarás.

Una Skill es al menos cuatro cosas, especialmente en el contexto de cómo las construimos en Perplexity.

Una Skill es un directorio

Una Skill no es solo un único archivo SKILL.md. En muchos casos, una Skill incluye varios archivos. Bajo el directorio que lleva el nombre de tu Skill, es posible que tengas:

SKILL.md: frontmatter e instrucciones

scripts/: código que el agente ejecuta, no reinventa

references/: documentos pesados, cargados de forma condicional

assets/: plantillas, esquemas y datos

config.json: configuración de usuario para el primer inicio

Este patrón de concentrador y radios (hub-and-spoke) te permite mantener las Skill muy enfocadas y precisas, y se puede utilizar la estructura de carpetas de una manera muy creativa. A veces, las Skill particularmente intrincadas se benefician de múltiples niveles de jerarquía para ayudar al modelo a navegar mejor. Supongamos que una Skill requiere conocimientos en 300 temas, agrupables en 20 áreas temáticas. Elegir de forma fiable el tema correcto entre 300 es un desafío no resuelto incluso para los mejores modelos de vanguardia de la actualidad. Es un problema de elección mucho más fácil para un modelo centrarse en una de las 20 áreas, que entre los 15 temas dentro de esa área.

Como un ejemplo de cómo la jerarquía multinivel aporta valor, nuestro equipo empleó tres niveles de anidamiento de temas dentro de las Skill que impulsan las capacidades de impuesto sobre la renta en EE. UU. de Computer esta temporada de impuestos pasada. Esta jerarquía era absolutamente indispensable dada la complejidad del derecho fiscal: en nuestras primeras pruebas, presentar al modelo una sola carpeta que contuviera las 1.945 secciones del Código de Rentas Internas de EE. UU. dio como resultado un peor rendimiento que no cargar la Skill en absoluto. Organizar la información en subdivisiones lógicas fue indispensable para garantizar operaciones de lectura de alta precisión.

Sin embargo, esta jerarquía no salió gratis. El incremento de los niveles de jerarquía requiere niveles crecientes de curaduría en toda la arquitectura de información para gestionar la indirección resultante. Ideamos guías de referencia rápida, utilidades de búsqueda personalizadas y otras herramientas para ayudar al modelo a localizar información con un mínimo de indirección. En este caso, realizar el arduo trabajo de curaduría produjo en última instancia un resultado final positivo: una Skill que permitió a los modelos realizar tareas relacionadas con los impuestos de manera mucho más competente que usando herramientas generales por sí solas.

Ampliar

Una Skill es un formato

Una Skill es un formato. El archivo raíz principal SKILL.md debe tener tanto un nombre como una descripción. Además, la Skill debe coincidir exactamente con el nombre del directorio en el que se encuentra la Skill. El nombre debe estar compuesto exclusivamente por caracteres en minúsculas, no tener espacios y puede utilizar guiones. La descripción es el activador de enrutamiento. Este es un punto común de fallo: la descripción no es documentación interna de lo que hace la Skill. Equivale a instrucciones para el modelo sobre cuándo cargar la Skill. Por lo tanto, verás frecuentemente "Load when", no "This Skill does". Esto es importante debido a la forma en que la mayoría de las implementaciones inyectan la descripción en el contexto del modelo.

Dentro del frontmatter, también existe "depends:", que te permite crear dependencias de Skill jerárquicas, y "metadata:", que se utiliza para revisiones y evaluaciones. Los diferentes sistemas de agentes pueden incluso definir sus propios campos de frontmatter, para ser utilizados de una manera específica para esos sistemas. Como alternativa, los metadatos específicos de la Skill se pueden empaquetar en un archivo de configuración auxiliar JSON o YAML. Esto es deseable al construir sistemas de agentes que necesitan facilitar diferentes tipos de comportamiento en tiempo de ejecución por Skill sin contaminar el contexto del modelo con minucias. Por último, se puede obtener un comportamiento similar eliminando el frontmatter de la Skill al leer. Computer emplea esta metodología, lo que permite conservar la configuración en el archivo raíz SKILL.md. Se requiere una cuidadosa atención a los detalles en la lógica de análisis sintáctico, y es posible que se desee implementar la eliminación condicional si hay ciertos campos que es útil tener dentro del contexto del modelo.

Una Skill es invocable

Una Skill es invocable. El agente carga una Skill en tiempo de ejecución. Es importante destacar que las Skill no siempre se agrupan en el contexto. Por defecto, la mayoría de los sistemas de agentes despliegan las Skill progresivamente según una necesidad específica.

Existen al menos tres niveles de costos de contexto en la forma en que hemos implementado las Skill en Computer. Este es el proceso:

Computer llama a load_skill(name="...")

Computer copia el directorio de la Skill en el entorno aislado de ejecución

Computer carga automáticamente de forma recursiva las dependencias en la etiqueta "depends:"

A continuación, Computer elimina el frontmatter y, por lo tanto, el agente solo ve el cuerpo y los archivos adicionales

Los diferentes sistemas de agentes pueden optar por exponer el contenido de la Skill de diferentes maneras. Como ejemplo, algunos sistemas pueden optar por no exponer la jerarquía de archivos en absoluto, dejando que el modelo descubra la jerarquía a través de operaciones del sistema de archivos. Otros sistemas pueden optar por darle al modelo un mapeo de todo el árbol de archivos hasta un cierto límite de truncamiento y/o profundidad. Para mantener el contexto limpio, Computer omite las jerarquías de archivos completas del contexto de invocación; sin embargo, esto se puede anular por cada Skill.

Una Skill es progresiva

Las Skill son progresivas. En Computer, hay tres niveles diferentes de costos de contexto, e incurrimos en los tres en varias etapas:

Los tres niveles del contexto de una Skill: índice, carga completa de la Skill y archivos de referencia en tiempo de ejecución.

Computer construye un índice de Skill que tiene el nombre y la descripción de cada Skill disponible. El presupuesto para esto es de alrededor de 100 tokens por Skill (cuanto más corto, mejor). Es tan ajustado porque estás pagando este costo en cada sesión, para cada usuario. Esto se inyecta en el mensaje del sistema al principio de la conversación. El modelo tiene acceso a un grupo de Skill nombradas y descripciones para que pueda decidir si llamar a "load_skill()". La barrera para entrar en este índice es extremadamente alta. Tu Skill debe ser muy útil, y la descripción debe ser extremadamente densa y concisa porque todos están pagando el costo todo el tiempo.

Después de que el sistema de agentes carga la Skill, se encuentra el cuerpo completo de SKILL.md. Lo ideal es que el texto del cuerpo no supere los 5.000 tokens. Aun así, querrás que cada oración importe porque una vez que cargas una Skill, el resto de la conversación tiene que pagar ese costo hasta que alcances el límite de compactación. Muchos hilos cargan entre tres y cinco Skill diferentes, multiplicando este costo. Las Skill con mucho contenido superficial degradarán casi con certeza otras Skill, así como las capacidades de los agentes en general. En resumen, si tu Skill se carga y no hace lo correcto, eso es contexto desperdiciado.

El nivel final de progresión son los scripts o casos especiales, como las subskill o el formato. Aquí es donde querrás colocar la lógica ramificada condicional ilimitada. El agente solo la usará cuando lo necesites, lo que significa que hay una barra mucho más baja para lo que quieras poner aquí.

En el índice, cada token es importante. El cuerpo de la Skill cargada es más flexible, y el tiempo de ejecución es el más flexible. Esto podría ser de 20.000 tokens o cero tokens. Este es el nivel en el que podrías pensar en expandir el contexto del modelo de manera progresiva.

¿Cuándo necesitas una Skill?

A menudo se le pide al equipo de agentes que opine sobre si realmente se necesita una Skill para un dominio o caso de uso determinado. Raras vez tenemos una respuesta definitiva a partir de los primeros principios por sí solos. La única manera de averiguar esto realmente es comenzar con tu agente sin la Skill, ejecutar varias consultas principales y luego averiguar si el agente está haciendo un buen trabajo.

Cuando necesitas una Skill

Hay muchas tareas que están dentro de la distribución para los modelos entrenados. Solo necesitas aplicar una Skill si deseas cambiar ese comportamiento de alguna manera específica que no puedes lograr con, digamos, una oración en tu mensaje. Por lo tanto, necesitas una Skill cuando el agente se equivocará sin un contexto especial, o si hay alguna inconsistencia o no determinismo en el que necesites una consistencia extrema entre ejecuciones.

Podría ser que tu conocimiento sea duradero pero no esté en los datos de entrenamiento. Podría haber cortes o flujos de trabajo específicos de la empresa, o podría ser una cuestión de gusto. Por ejemplo, tenemos varias Skill relacionadas con el diseño en Computer escritas por Henry Modisett (nuestro jefe de diseño). La razón por la que cada token existe en esas Skill es porque Henry tiene un gusto muy bueno a la hora de diseñar sitios web y PDF. Henry especifica qué fuentes usar y qué fuentes no usar, cómo se sienten esas fuentes y otros asuntos de juicio que el modelo no puede aprender solo de los datos de entrenamiento.

Cuando no necesitas una Skill

Vemos muchas Skill en las que los ingenieros han escrito una serie de comandos de git que deben ejecutarse en orden. Eso es innecesario porque el modelo ya sabe cómo hacer eso, lo que significa que es una excelente documentación pero una mala Skill.

Vemos ejemplos en los que las Skill recapitulan instrucciones del mensaje del sistema. No necesitas una Skill para eso. El conocimiento relevante para la mayoría de las solicitudes debe incluirse en el contexto global, no en una Skill cargada de forma condicional

Si hay algo que cambia más rápido de lo que puedes mantenerlo, no necesitas una Skill. Por ejemplo, si estás accediendo a algún extremo MCP remoto y sus herramientas o las versiones de esas herramientas cambian con frecuencia, no debes inyectar eso en una Skill. Si lo haces, terminarás generando desvíos y el modelo cometerá errores.

Cada Skill es un impuesto

Aquí tienes una prueba útil que puedes aplicar a cada oración de tu Skill: "¿Se equivocaría el agente sin esta instrucción?". Si la oración no necesita estar ahí, no puede permitirse estar ahí porque todos están pagando este costo cada vez. Cuando estés decidiendo si agregar una Skill o no, recuerda este impuesto en el que cada sesión y cada usuario cuestan tokens.

La siguiente famosa cita, que suena mucho mejor en francés, se traduce aproximadamente como "Solo he hecho esta carta más larga porque no he tenido tiempo de hacerla más corta".

« Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. » — Blaise Pascal, Lettres Provinciales, 1657

Al igual que Pascal, debes invertir tiempo en cada Skill. Es difícil escribir una Skill corta. Si tu Skill es fácil de escribir, probablemente sea demasiado larga o no debería existir. Una buena Skill es tan corta como puede ser.

Si te encuentras intentando generar una Skill de un solo intento y publicando solicitudes de incorporación de cambios en cinco minutos, los resultados serán casi con certeza mediocres. De hecho, las primeras investigaciones han demostrado que si estás utilizando LLM para escribir Skill, el LLM probablemente no se beneficiará de ello: "Las Skill autogeneradas no proporcionan ningún beneficio en promedio, lo que demuestra que los modelos no pueden autoría de manera confiable el conocimiento procedimental del que se benefician al consumirlo".

Cómo construir una Skill

Dicho de otra manera, necesitas inyectar tu opinión en cualquier Skill que escribas. Sigue estos pasos.

Paso 0: Escribir las evaluaciones (Evals)

Escribe algunas de las evaluaciones primero. Puedes obtener casos de evaluación de:

Consultas de usuarios reales: muestra de producción o de tu grupo de confianza

Fallos conocidos: El agente falló porque la Skill no existía

Confusión con vecinos: Cerca del límite de tu dominio pero se enruta a otra Skill

Como mínimo, debes asegurarte de probar que la Skill se carga cuando es necesario. Lo ideal es que muestrees algunas de estas, tal vez de un entorno de producción. También puedes considerar casos de error conocidos: tal vez la razón principal por la que te propusiste escribir la Skill se deba a un fallo específico que notaste o tal vez estés refactorizando y haya cierta confusión en dos dominios cercanos cubiertos por una Skill.

Comienza con ejemplos negativos y positivos similares. Los ejemplos negativos son extremadamente poderosos y pueden importar más que los ejemplos positivos.

Paso 1: La descripción

Esta es la línea más difícil de la Skill. Es un activador de enrutamiento, no documentación. Para hacer que el nombre y la descripción sean correctos, no te importa el contenido de la Skill. Solo te importa si la Skill se carga e inyecta en los puntos correctos y está libre de efectos secundarios no deseados, que es el modo de fallo número uno. Cada vez que agregas una Skill adicional, corres el riesgo de empeorar ligeramente a todas las demás Skill, por lo que debes asegurarte de minimizar la regresión.

Nuevamente, una mala descripción describe lo que hace la Skill o por qué es útil. Una buena descripción dice cuándo el agente debe cargar la Skill. Por ejemplo, supongas que tienes algo para monitorear solicitudes de incorporación de cambios. No escribas lo que hace la Skill. Escribe lo que dicen los ingenieros cuando están frustrados y quieren que te asegures de que su PR funcione, como "cuidar" (babysit), "vigilar CI" (watch CI) o "asegurarte de que esto se incorpore" (make sure this lands).

Aquí tienes una lista de verificación rápida:

Comienza con "Load when..."

Apunta a 50 palabras o menos

Describe la intención del usuario, idealmente a partir de consultas reales

No resume el flujo de trabajo

Las consultas reales son lo que puedes cubrir en una regla 80-20. Por lo general, dos o tres ejemplos funcionan bien. No es fácil agregar exactamente y solo tanto como necesites.

Paso 2: Escribir el cuerpo

A continuación, escribe el contenido de la Skill en sí. Ten en cuenta que este no es el Paso 0 ni el Paso 1.

Comunicar flujos de trabajo a un LLM es completamente diferente a comunicar flujos de trabajo a un colega, o incluso a tu sistema en tiempo de ejecución. Al aprender una nueva herramienta de software, un ingeniero puede necesitar leer la documentación, recibir una explicación de alguien con experiencia y aprender a usar la herramienta. Mientras tanto, para casi cualquier herramienta de software que haya existido durante al menos un año, solo necesitas mencionar su nombre y el LLM tiene toda la información que necesita.

Cuando estés escribiendo el cuerpo, omite las cosas obvias. Muchos ingenieros tienen mucha experiencia escribiendo archivos readme.md que enumeran cada comando que alguien necesita ejecutar. Es fácil recaer en eso cuando estás escribiendo una Skill porque se siente como si estuvieras escribiendo documentación, pero si haces eso, tu Skill será basura. Por lo tanto, no escribas una serie de comandos.

Por ejemplo, no necesitas escribir: "git log # find the commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;"

En su lugar, escribe: "Haz cherry-pick de la confirmación (commit) en una rama limpia. Resuelve los conflictos preservando la intención. Si no se puede incorporar limpiamente, explica por qué".

El modelo hará un trabajo mucho mejor con esto último que con la serie de comandos excesivamente prescriptiva del primero, especialmente cuando las cosas van mal. No impongas las cosas de forma rígida ni seas excesivamente prescriptivo, lo cual es frágil; en su lugar, sé flexible donde múltiples enfoques puedan funcionar. Nuevamente, una buena documentación para humanos suele ser una mala documentación para los modelos.

A continuación, céntrate en los detalles problemáticos (gotchas) o ejemplos negativos. Estos son contenidos de señal extremadamente alta porque a menudo guían al modelo en términos de qué no hacer. Si agregas una línea cada vez que el agente tropieza, aprenderás ejecutándolo y los detalles problemáticos crecerán orgánicamente.

Por último, si hay alguna parte que sea condicional o extremadamente pesada en contenido, sácala de SKILL.md, que es el nodo central (hub), y ponla en uno de los radios. Ponla en un archivo accesorio que se pueda cargar progresivamente, en el que profundizaremos a continuación.

Paso 3: Utilizar la jerarquía

Haz uso de la jerarquía de Skill cuando tengas un script, referencias o estés usando alguna herramienta específica:

Usos sugeridos para scripts, referencias, recursos y configuración dentro de una Skill.

Para cualquier cosa que sea condicional o se ramifique desde la Skill principal, divídela en una carpeta. Recuerda también que se puede utilizar una jerarquía multinivel para Skill particularmente intrincadas. Para estas, querrás reflexionar cuidadosamente sobre si la funcionalidad debe implementarse de forma monolítica o como una colección de Skill (tal vez con relaciones de carga basadas en depends:).

Paso 4: Iterar

A continuación, haz un montón de iteraciones en una rama. Comienza en la rama principal sin Skill, haz algunas iteraciones, construye tu conjunto de consultas principales y ejecuta una serie de evaluaciones. Cualquiera que revise el código de tu Skill te agradecerá que envíes un único conjunto de cambios completo con un conjunto de evaluaciones. Revisar cambios incrementales consecutivos (excepto un nuevo detalle problemático) es muy difícil, así que intenta minimizarlo.

Es probable que hagas muchos cambios pequeños de palabras. Los pequeños cambios de palabras en las descripciones pueden tener un impacto desproporcionado en el enrutamiento (incluidos los efectos de transferencia en otras Skill), así que haz todo ese trabajo antes del Paso 5.

Paso 5: Enviar (Ship)

Envíalo.

Cómo mantener una Skill

Ahora que has escrito una Skill, tienes que mantenerla.

El ciclo dinámico de los detalles problemáticos (Gotchas Flywheel)

A partir de este momento, tu lista de detalles problemáticos tiende a crecer o cambiar mucho. A menudo vemos ingenieros que realizan solicitudes de incorporación de cambios que no han sido evaluadas, por ejemplo, cambian la descripción. Si estás cambiando la descripción después de que tu Skill se haya fusionado, estás perdiendo el rumbo. Si estás haciendo cambios en lo que decide si debe enrutar tu Skill, debes escribir algunas evaluaciones que respalden los cambios.

Las Skill son principalmente acumulativas (append-mostly). La sección de detalles problemáticos acumula el mayor valor con el tiempo:

El agente falla en algo → Agrega un detalle problemático

El agente carga la Skill fuera del objetivo → Ajusta la descripción y agrega evaluaciones negativas

El agente no carga la Skill cuando debería → Agrega palabras clave y evaluaciones positivas

Los mensajes del sistema cambian → Comprueba si hay contiendas o duplicación

Es fácil notar un solo caso de fallo en las pruebas internas o en producción y agregar un detalle problemático. Es un ejemplo negativo, por lo que realmente no está cambiando la orientación explícita, pero le permite al modelo saber: "Oye, hay este fallo conocido".

A medida que pasas de la relación 80-20 a alcanzar una tasa de éxito del 99,9% o 99,99%, es fácil hacer crecer esta lista de detalles problemáticos. A medida que veas estos ejemplos negativos, debes agregar contenido principalmente a la sección de detalles problemáticos. No debes agregar instrucciones más largas ni cambiar la descripción.

Conjuntos de evaluación (Eval Suites)

En Perplexity, ejecutamos muchos conjuntos de evaluación para verificar diferentes cosas. Existen la carga de Skill y las lecturas de archivos de Skill, lo que verifica la precisión, la recuperación y las comprobaciones prohibidas de la carga de la Skill en sí. ¿Enrutará el agente tu Skill cuando se supone que debe hacerlo? Estos aseguran que las nuevas Skill no rompan los límites existentes.

También hay evaluaciones que pueden comprobar si la carga progresiva es correcta. El agente puede cargar la Skill, ¿pero lee el archivo o archivos accesorios? Por ejemplo, si tienes una Skill de finanzas para consultas financieras, ¿lee el archivo especial FORMATTING.md?

También hay evaluaciones para las Skill que prueban la finalización de tareas de extremo a extremo dentro de los dominios. Ejecutamos el bucle completo del agente y utilizamos un juez LLM para calificar los resultados basándonos en una rúbrica de criterios bien definidos.

Por último, es importante ejecutar estas evaluaciones frente a diferentes modelos. Computer admite al menos tres familias diferentes de modelos de orquestación: GPT, Claude Opus y Claude Sonnet. Quieres ejecutar tu carga de Skill y las Skill de dominio frente a estos diferentes orquestadores de agentes para asegurarte de no obtener un comportamiento diferente. Sonnet y GPT se comportan de manera bastante diferente en lo que respecta a las Skill.

Reflexiones finales y conclusiones

Cuantas más Skill construyas, mejor se te dará construirlas. Si no estás automatizando o intentando hacer más reproducibles las tareas que realizas en tu día a día utilizando Skill, empieza de inmediato.

El acto de construir Skill te hace mejor en la construcción de más Skill, pero además, son extremadamente buenas para automatizar procesos comerciales. Si puedes describir algo que haces todas las semanas antes de tu reunión de pie (standup), al final de cada sprint, o cualquier cosa que hagas como ingeniero de forma diaria, semanal o incluso trimestral, deberías estar escribiendo una Skill para recuperar tu tiempo.

¿Puedes automatizar los análisis posteriores (postmortems)? ¿Puedes revisar solicitudes de incorporación de cambios? Cualquier tarea que puedas hacer, puedes al menos hacer que la primera pasada sea una Agent Skill. Te ahorrará un tiempo significativo.

Dicho esto, recuerda que una Skill no es fácil ni siempre necesaria. Menos es más. Algunas otras conclusiones:

Escribe evaluaciones antes que la Skill. Incluye ejemplos negativos y cargas prohibidas para habilidades adyacentes pero distintas.

La descripción es la parte difícil. "Load when..." (cada palabra cuesta atención).

Los detalles problemáticos son contenido de valor extremadamente alto. Empieza delgado, hazlo crecer a medida que el agente falle.

Recuerda que es fácil romper otras Skill preexistentes al agregar una nueva Skill, aunque no la hayas tocado (cuidado con la acción a distancia).

Usa todas las herramientas disponibles cada vez que escribas y mantengas una Skill. Si quieres obtener más información, el sitio web de Agent Skills tiene muchos buenos ejemplos, y tanto nuestro repositorio interno como el ecosistema público contienen muchos ejemplos de Skill bien diseñadas.

Citación

@online{perplexity2026DesigningRefiningAndMaintainingAgentSkillsAtPerplexity,
  author = {{Perplexity} and Marshall Kiely and Daisy Lee and Jerry Ma and Lauren Kolm},
  title = {{Designing, refining, and maintaining agent skills at Perplexity}},
  date = {2026-05-01},
  url = {https://perplexity.coolkeypoint.com/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}