Disseny, refinament i manteniment de les habilitats d'agents a Perplexity

Els productes d'agents de la frontera de Perplexity es basen en una fundació de coneixements i experiència en un domini determinats, empaquetats en Agent Skills modulars. Mantenim una biblioteca curosament seleccionada de Skills als nostres entorns tècnics. Aquestes Skills inclouen moltes de les utilitats d'ús general que alimenten Perplexity Computer; capacitats específiques de verticals en àrees com les finances, el dret i la salut; i una llarga cua de mòduls per satisfer les necessitats dels usuaris. Algunes Skills s'invoquen poc sovint, però són crucials quan s'invoquen. Per garantir una experiència d'usuari excel·lent i constant, l'equip d'Agents de Perplexity prioritza la qualitat de les Skills tant com la qualitat del codi.

Les intuïcions i les millors pràctiques necessàries per desenvolupar una Skill d'alta qualitat difereixen significativament de les necessàries per construir programari tradicional. L'equip d'Agents revisa moltes sol·licituds d'extracció (pull requests) d'enginyers excel·lents que desenvolupen Skills en el curs de la seva feina. El resultat gairebé sempre inclou nombrosos comentaris i suggeriments de revisió. Això passa perquè molts patrons útils per escriure codi es converteixen en antipatrons en la creació de Skills.

Per exemple, si preneu alguns dels aforismes de PEP20 – El Zen de Python, de seguida queda clar que escriure bon codi en Python no s'assembla a escriure bones Skills. De les 20 línies de saviesa, almenys la mitad són completament errònies o enganyoses de manera activa quan s'escriuen Skills. Aquí en teniu cinc:

Cinc contrastos entre el Zen de Python i la guia de l’article per escriure Skills.

Aquesta guia és el document que els enginyers de tot Perplexity utilitzen quan desenvolupen i revisen Skills. També publiquem aquesta guia per al públic perquè els nostres descobriments i aprenentatges puguin beneficiar la comunitat en general. Tant si sou un enginyer que dissenya Skills de producció en el vostre dia a dia, com si sou un usuari de Computer que busca desenvolupar la seva pròpia Skill en una àrea que coneix bé, o totes dues coses, aquesta guia és per a vosaltres.

Què és una Skill?

Quan escriviu una Skill, no esteu escrivint programari normal i corrent (tot i que les Skills ara formen part dels motors lògics principals per als sistemes d'agents). Més aviat esteu construint context per als models i els seus entorns. Una Skill té limitacions diferents i principis de disseny diferents. Si escriviu una Skill com ho feu amb el codi, fracassareu.

Una Skill és almenys quatre coses, especialment en el context de com les construïm a Perplexity.

Una Skill és un directori

Una Skill no és només un únic fitxer SKILL.md. En molts casos, una Skill inclou diversos fitxers. Sota el directori que porta el nom de la vostra Skill, podeu tenir:

SKILL.md: frontmatter i instruccions

scripts/: codi que l'agent executa, no reinventa

references/: documents pesats, carregats de manera condicional

assets/: plantilles, esquemes i dades

config.json: configuració de l'usuari en el primer inici

Aquest patró de concentrador i radis us permet mantenir les Skills molt enfocades i tancades, i es pot utilitzar l'estructura de carpetes d'una manera molt creativa. De vegades, les Skills especialment intrincades es beneficien de múltiples nivells de jerarquia per ajudar el model a navegar millor. Suposeu que una Skill requereix coneixements en 300 temes, agrupables en 20 àrees temàtiques. Triar de manera fiable el tema correcte entre 300 és un repte no resolt fins i tot per als millors models de frontera d'avui. És un problema d'elecció molt més fàcil per a un model centrar-se en una de les 20 àrees, que entre els 15 temes d'aquesta àrea.

Com a exemple de com la jerarquia multinivell aporta valor, el nostre equip va emprar tres nivells d'imbricació temàtica dins de les Skills que alimenten les capacitats d'impostos sobre la renda dels EUA de Computer aquesta darrera temporada d'impostos. Aquesta jerarquia era absolutament indispensable donada la complexitat de la llei fiscal: en les nostres primeres proves, presentar al model una única carpeta que contingués les 1.945 seccions del Codi d'Ingressos Interns dels EUA va donar lloc a un rendiment pitjor que no carregar cap Skill. Organitzar la informació en subdivisions lògiques va ser indispensable per garantir operacions de lectura d'alta precisió.

Tot i així, aquesta jerarquia no va sortir gratis. Els nivells creixents de jerarquia requereixen nivells creixents de comissariat en tota l'arquitectura de la informació per gestionar la indirigibilitat resultant. Vam idear guies de referència ràpida, utilitats de cerca personalitzades i altres eines per ajudar el model a localitzar informació amb un mínim d'indirecció. En aquest cas, fer la feina dura del comissariat finalment va produir un resultat final positiu: una Skill que va permetre als models realitzar tasques relacionades amb els impostos amb molta més capacitat que no pas utilitzant eines generals soles.

Amplia

Una Skill és un format

Una Skill és un format. El fitxer arrel principal SKILL.md ha de tenir tant un nom com una descripció. A més, la Skill ha de coincidir exactament amb el nom del directori on es troba la Skill. El nom ha de ser tot en minúscules, no tenir espais i pot utilitzar guions. La descripció és el disparador d'encaminament. Aquest és un punt de fallada habitual: la descripció no és documentació interna per al que fa la Skill. Equivaleix a instruccions per al model sobre quan carregar la Skill. Per tant, veureu freqüentment "Load when," no "This Skill does." Això és important a causa de la manera com la majoria de les implementacions injecten la descripció al context del model.

Dins del frontmatter, també hi ha "depends:", que us permet crear dependències de Skills jeràrquiques, i "metadata:", que s'utilitza per a revisions i avaluacions. Els diferents sistemes d'agents poden fins i tot definir els seus propis camps de frontmatter, per ser utilitzats d'una manera específica per a aquests sistemes. Com a alternativa, les metadades específiques de les Skills es poden empaquetar en un fitxer de configuració JSON o YAML auxiliar. Això és desitjable quan es construeixen sistemes d'agents que necessiten facilitar diferents tipus de comportament en temps d'execució per Skill sense contaminar el context del model amb minuciositats. Finalment, es pot obtenir un comportament similar eliminant el frontmatter de la Skill en la lectura. Computer empra aquesta metodologia, que permet preservar la configuració al fitxer arrel SKILL.md. Es requereix una atenció acurada als detalls en la lògica d'anàlisi sintàctica (parsing), i es podria voler implementar l'eliminació condicional si hi ha certs camps que és útil tenir dins del context del model.

Una Skill és invocable

Una Skill és invocable. L'agent carrega una Skill en temps d'execució. Importantment, les Skills no sempre s'agrupen al context. Per defecte, la majoria dels sistemes d'agents despleguen les Skills de manera progressiva segons necessitats específiques.

Hi ha almenys tres nivells de costos de context en la manera com hem implementat les Skills a Computer. Aquí teniu el procés:

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

Computer copia el directori de la Skill a l'entorn de proves d'execució aïllat

Computer carrega automàticament de manera recursiva les dependències de l'etiqueta “depends:”

A continuació, Computer elimina el frontmatter i, per tant, l'agent només veu el cos i els fitxers addicionals

Diferents sistemes d'agents poden triar exposar el contingut de les Skills de diferents maneres. Com a exemple, alguns sistemes poden optar per no exposar gens la jerarquia de fitxers, deixant que el model descobreixi la jerarquia mitjançant operacions del sistema de fitxers. Altres sistemes poden triar donar al model un mapatge de tot l'arbre de fitxers fins a un límit de truncament i/o profunditat determinat. Per mantenir net el context, Computer omet les jerarquies de fitxers completes del context d'invocació; tanmateix, això es pot anul·lar per a cada Skill de manera individual.

Una Skill és progressiva

Les Skills són progressives. A Computer, hi ha tres nivells diferents de costos de context, i assumim tots tres en diverses etapes:

Les tres capes de context d’un Skill: índex, càrrega completa del Skill i fitxers de referència en temps d’execució.

Computer construeix un índex de Skills que té el nom i la descripció de cada Skill disponible. El pressupost per a això és d'uns 100 tokens per Skill (més curt és encara millor). És tan ajustat perquè pagueu aquest cost a cada sessió, per a cada usuari. Això s'injecta a l'indicatiu del sistema (system prompt) al mateix començament de la conversa. El model té accés a un conjunt de Skills amb nom i descripcions perquè pugui decidir si ha de cridar “load_skill()”. El llistó per entrar en aquest índex és extremadament alt. La vostra Skill ha de ser molt útil i la descripció ha de ser extremadament densa i concisa perquè tothom està pagant el cost tot el temps.

Després que el sistema d'agents carregui la Skill, hi ha tot el cos de SKILL.md. Idealment, el text del cos no supera els 5.000 tokens. Fins i tot llavors, voleu que cada frase importi perquè un cop carregueu una Skill, la resta de la conversa ha de pagar-ho fins que arribeu al límit de compactació. Molts fils carreguen entre tres i cinc Skills diferents, multiplicant aquest cost. Les Skills amb molts elements superfluïs gairebé segur que degradaran altres Skills així com les capacitats generals dels agents. En resum, si la vostra Skill es carrega i no fa el que cal, això és context desaprofitat.

El nivell final de progressió són els scripts o casos especials, com ara subskills o format. Aquí és on voleu posar lògica ramificada condicional sense límits. L'agent només l'utilitzarà quan ho necessiti, la qual cosa significa que hi ha un llistó molt més baix per al que voleu posar aquí.

A l'índex, cada token és important. El cos de la Skill carregada és més relaxat, i el temps d'execució és el més relaxat de tots. Això podria ser de 20.000 tokens o zero tokens. Aquest és el nivell en què podríeu pensar a ampliar el context del model de manera progressiva.

Quan necessiteu una Skill?

Sovint es demana a l'equip d'Agents que s'opini sobre si realment es necessita una Skill per a un domini o cas d'ús determinat. Molt poques vegades tenen una resposta definitiva només a partir de principis bàsics. L'única manera d'esbrinar-ho realment és començar amb el vostre agent sense la Skill, executar diverses consultes heroiques i després esbrinar si l'agent està fent una bona feina.

Quan necessiteu una Skill

Hi ha moltes tasques que estan en distribució per als models entrenats. només heu d'aplicar una Skill si voleu canviar aquest comportament d'alguna manera específica que no podeu fer amb, per exemple, una frase al vostre missatge (prompt). Per tant, necessiteu una Skill quan l'agent s'equivoqui sense un context especial, o si hi ha alguna inconsistència o no determinisme que necessiteu que sigui extremadament consistent a través de les execucions.

Podria ser que el vostre coneixement sigui durador però no estigui en les dades d'entrenament. Podria haver-hi límits o fluxos de treball específics de l'empresa, o podria ser una qüestió de gustos. Per exemple, tenim diverses Skills relacionades amb el disseny a Computer escrites per Henry Modisett (el nostre cap de disseny). La raó per la qual cada token existeix en aquestes Skills és perquè Henry té molt bon gust a l'hora de dissenyar llocs web i PDFs. Henry especifica quines fonts utilitzar i quines fonts no utilitzar, com se senten aquestes fonts i altres assumptes de criteri que el model no pot aprendre només amb les dades d'entrenament.

Quan no necessiteu una Skill

Veiem moltes Skills en què els enginyers han escrit una sèrie d'ordres de git que s'han d'executar en ordre. Això és innecessari perquè el model ja sap com fer-ho, la qual cosa significa que serveix per a una gran documentació però per a una pobra Skill.

Veiem exemples on les Skills recapitulen instruccions de l'indicatiu del sistema (system prompt). no necessiteu una Skill per a això. El coneixement rellevant per a la majoria de les sol·licituds s'ha d'incloure en el context global, no en una Skill carregada de manera condicional

Si hi ha alguna cosa que canvia més ràpidament del que podeu mantenir-la, no necessiteu una Skill. Per exemple, si accediu a algun punt final MCP remot i les seves eines o les versions d'aquestes eines canvien freqüentment, no hauríeu d'injectar-les en una Skill. Si ho feu, només acabareu amb una desviació (drift) i el model cometrà errors.

Cada Skill és un impost

Aquí teniu una prova útil que podeu aplicar a cada frase de la vostra Skill: "L'agent s'equivocaria en això sense aquesta instrucció?" Si la frase no necessita ser-hi, no es pot permetre ser-hi perquè tothom està pagant aquest cost cada vegada. Quan decidiu si voleu afegir una Skill o no, recordeu aquest impost on cada sessió i cada usuari costa tokens.

La següent cita famosa, que sona molt millor en francès, es tradueix aproximadament com a "Només he fet aquesta carta més llarga perquè no he tingut el temps de fer-la més curta."

« 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

Igual que Pascal, heu d'invertir temps en cada Skill. És difícil escriure una Skill curta. Si la vostra Skill és fàcil d'escriure, probablement és massa llarga o no hauria d'existir. Una bona Skill és tan curta com pot ser.

Si us trobeu intentant fer una generació de Skills d'un sol tret (one-shot) i penjant PRs en cinc minuts, els resultats gairebé segur que seran deficitaris. De fet, la investigació prèvia ha demostrat que si utilitzeu LLMs per escriure Skills, el LLM probablement no se'n beneficiarà: "Les Skills autogenerades no proporcionen cap benefici de mitjana, cosa que mostra que els models no poden autoritzar de manera fiable el coneixement procedimental del qual es beneficien en consumir-lo."

Com construir una Skill

Dit d'una altra manera, heu d'injectar la vostra opinió en qualsevol Skill que escriviu. Seguiu aquests passos.

Pas 0: Escriviu les avaluacions (Evals)

Primer escriviu algunes de les avaluacions. Podeu obtenir casos d'avaluació de:

Consultes d'usuaris reals: mostres de producció o del vostre grup de confiança (brain trust)

Errors coneguts: L'agent ha fallat perquè la Skill no existia

Confusió amb el veí: A prop del límit del vostre domini però s'encamina cap a una altra Skill

Com a mínim, haureu d'assegurar-us de provar que la Skill es carrega quan calgui. Idealment, mostreu algunes d'aquestes, potser d'un entorn de producció. També podeu considerar casos d'error coneguts: potser tota la raó per la qual us vau proposar escriure la Skill es deu a una fallada específica que heu notat o potser esteu refactoritzant i hi ha certa confusió en dos dominis propers coberts per una sola Skill.

Comenceu amb exemples negatius i positius similars. Els exemples negatius són extremadament poderosos i poden importar més que els exemples positius.

Pas 1: La descripció

Aquesta és la línia més difícil de la Skill. És un disparador d'encaminament, no documentació. Per encertar amb el nom i la descripció, no us importa el contingut de la Skill. Només us importa si la Skill es carrega i s'injecta en els punts correctes i està lliure d'efectes secundaris no desitjats, que és el mode de fallada número u. Cada vegada que afegiu una Skill addicional, arrisqueu a fer que totes les altres Skills siguin una mica pitjors, per la qual cosa heu d'assegurar-us que minimitzeu la regressió.

Un cop més, una mala descripció descriu el que fa la Skill o per què és útil. Una bona descripció diu quan l'agent ha de carregar la Skill. Per exemple, diguem que teniu alguna cosa per supervisar les sol·licituds d'extracció (pull requests). no escriviu el que fa la Skill. Escriviu el que diuen els enginyers quan estan frustrats i volen que us assegureu que la seva PR funcioni, com ara "vigilar" (babysit) o "observar CI" o "assegurar-se que això aterri".

Aquí teniu una llista de comprovació ràpida:

Comença amb "Load when..."

Apunteu a 50 paraules o menys

Descriu la intenció de l'usuari, idealment a partir de consultes reals

No resumeix el flux de treball

Les consultes reals són el que podeu cobrir en un 80-20. Normalment, dos o tres exemples funcionen bé. no és fàcil afegir exactament i només tant com necessiteu.

Pas 2: Escriviu el cos

A continuació, escriviu el contingut de la pròpia Skill. Observeu que això no és el Pas 0 ni el Pas 1.

Comunicar fluxos de treball a un LLM és completament diferent de comunicar fluxos de treball a un col·lega, o fins i tot al vostre sistema en temps d'execució. En aprendre una nova eina de programari, un enginyer pot necessitar llegir la documentació, obtenir una guia d'algú amb experiència i aprendre a utilitzar l'eina. Mentrestant, per a gairebé qualsevol eina de programari que hagi existit almenys un any, només cal mencionar el seu nom i el LLM té tota la informació que necessita.

Quan escriviu el cos, ometeu les coses òbvies. Molts enginyers tenen molta experiència escrivint fitxers readme.md que enumeren cada ordre que algú necessita executar. És fàcil tornar a això quan escriviu una Skill perquè sembla que esteu escrivint documentació, però si feu això, la vostra Skill serà escombraries. Per tant, no escriviu una sèrie d'ordres.

Per exemple, no cal que escriviu: “git log # trobar el commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;”

En lloc d'això, escriviu: “Aplica per extracció selectiva (cherry-pick) el commit en una branca neta. Resol els conflictes preservant la intenció. Si no pot aterrar netament, expliqueu per què.”

El model farà una feina molt millor amb aquest últim que amb la sèrie d'ordres excessivament prescriptiva del primer, especialment quan les coses van malament. No imposeu un camí rígid ni sigueu excessivament prescriptius, la qual cosa és fràgil, i en el seu lloc sigueu flexibles quan múltiples enfocaments puguin funcionar. Un cop més, una bona documentació per a humans és sovint una mala documentació per a models.

A continuació, centreu-vos en els problemes imprevistos (gotchas) o exemples negatius. Aquests tenen un contingut de molt alt valor perquè sovint guien el model pel que fa a què no s'ha de fer. Si afegiu una línia cada vegada que l'agent ensopega, aprendreu executant-lo i els problemes imprevistos creixeran orgànicament.

Per últim, si hi ha alguna part que sigui condicional o extremadament pesada en contingut, traieu-la del SKILL.md, que és el centre (hub), i poseu-la en un dels radis. Poseu-la en un fitxer accessori que es pugui carregar de manera progressiva, en el qual ens endinsarem a continuació.

Pas 3: Utilitzeu la jerarquia

Aprofiteu la jerarquia de les Skills quan tingueu un script, referències o utilitzeu alguna eina específica:

Usos recomanats per a scripts, referències, recursos i configuració dins d’un Skill.

Per a qualsevol cosa que sigui condicional o que es ramifiqui de la Skill principal, segpareu-la en una carpeta. Recordeu també que la jerarquia multinivell es pot utilitzar per a Skills especialment intrincades. Per a aquestes, voldreu reflexionar acuradament sobre si la funcionalitat s'ha de implementar de manera monolítica o com a conjunt de Skills (potser amb relacions de càrrega basades en depends:).

Pas 4: Itereu

A continuació, feu un grapat d'iteracions en una branca. Comenceu a la branca principal sense cap Skill, feu algunes iteracions, construïu el vostre conjunt de consultes heroiques i executeu una gran quantitat d'avaluacions. Qualsevol persona que revisi el vostre codi de Skill us agrairà que envieu un únic conjunt de canvis complet amb un conjunt d'avaluació. Revisar canvis incrementals consecutius (excepte un nou problema imprevist) és molt difícil, així que intenteu minimitzar-ho.

Probablement fareu molts canvis petits de paraules. Els canvis petits de paraules en les descripcions poden tenir un impacte desproporcionat en l'encaminament (inclosos els efectes d'excedent en altres Skills), així que feu tota aquesta feina abans del Pas 5.

Pas 5: Publicació (Ship)

Publiqueu-ho.

Com mantenir una Skill

Ara que heu escrit una Skill, l'heu de mantenir.

El volant d'inèrcia dels problemes imprevistos (Gotchas Flywheel)

A partir d'aquest moment, la vostra llista de problemes imprevistos tendeix a créixer o canviar molt. Sovint veiem enginyers que fan PRs que no han estat avaluades, per exemple, canviant la descripció. Si esteu canviant la descripció després que la vostra Skill s'hagi fusionat (merged), esteu fora del bon camí. Si esteu fent canvis en allò que decideix si s'ha d'encaminar la vostra Skill, heu d'escriure algunes avaluacions que donin suport als canvis.

Les Skills són principalment d'addició (append-mostly). La secció de problemes imprevistos acumula més valor amb el temps:

L'agent falla en alguna cosa → Afegiu un problema imprevist (gotcha)

L'agent carrega la Skill fora de l'objectiu → Afineu la descripció i afegiu avaluacions negatives

L'agent no carrega la Skill quan hauria de fer-ho → Afegiu paraules clau i avaluacions positives

El sistema de missatges (system prompt) canvia → Comproveu si hi ha contenció o duplicació

És fàcil notar un sol cas de fallada en les proves internes o en producció i afegir un problema imprevist. És un exemple negatiu, per la qual cosa no està realment canviant la guia explícita, sinó que fa saber al model: "Ei, hi ha aquesta fallada coneguda."

A mesura que passeu del 80-20 a aconseguir una taxa d'èxit del 99,9% o 99,99%, és fàcil fer créixer aquesta llista de problemes imprevistos. A mesura que veieu aquests exemples negatius, hauríeu d'afegir principalment a la secció de problemes imprevistos. No hauríeu d'afegir instruccions més llargues ni canviar la descripció.

Conjunts d'avaluació (Eval Suites)

A Perplexity, executem molts conjunts d'avaluació per comprovar diferents coses. Hi ha la càrrega de Skills i la lectura de fitxers de Skills, que comprova la precisió, la recuperació (recall) i les comprovacions prohibides de la càrrega de la Skill en si. L'agent encaminarà la vostra Skill quan se suposa que ha de fer-ho? Això garanteix que les noves Skills no trenquin els límits existents.

També hi ha avaluacions que poden comprovar la càrrega progressiva adequada. L'agent pot carregar la Skill, però llegeix el fitxer o fitxers accessoris? Per exemple, si teniu una Skill de finances per a consultes financeres, llegeix el fitxer especial FORMATTING.md?

També hi ha avaluacions per a Skills que proven la finalització de tasques de punta a punta (end-to-end) dins dels dominis. Executem el bucle complet de l'agent i utilitzem un jutge LLM per qualificar els resultats basant-se en una rúbrica de criteris ben definits.

Finalment, és important executar aquestes avaluacions contra diferents models. Computer admet almenys tres famílies de models d'orquestració diferents: GPT, Claude Opus i Claude Sonnet. Voleu executar la càrrega de la vostra Skill i les Skills de domini contra aquests diferents orquestradors d'agents per assegurar-us que no obteniu un comportament diferent. Sonnet i GPT es comporten de manera força diferent pel que fa a les Skills.

Pensaments finals i conclusions

Com més Skills construïu, millor us aturureu a construir-les. Si no esteu automatitzant o intentant fer tasques més reproduibles que feu en el vostre dia a dia utilitzant Skills, comenceu immediatament.

L'acte de construir Skills us fa millors en la construcció de més Skills, però a més, són extremadament bones per automatitzar processos de negoci. Si podeu descriure alguna cosa que feu cada setmana abans de la vostra reunió d'alineació (standup), al final de cada sprint, o qualsevol cosa que feu com a enginyer diàriament, setmanalment o fins i tot trimestralment, hauríeu d'estar escrivint una Skill per recuperar el vostre temps.

Podeu automatitzar les revisions pòstumes (postmortems)? Podeu revisar sol·licituds d'extracció (pull requests)? Qualsevol tasca que pugueu fer, almenys podeu fer que la primera passada sigui un Agent Skill. Us estalviarà un temps significatiu.

dit això, recordeu que una Skill no és fàcil ni tampoc sempre necessària. Menys és més. Algunes conclusions més:

Escriviu avaluacions abans de la Skill. Incloeu exemples negatius i càrregues prohibides per a habilitats adjacents però distintes.

La descripció és la part difícil. "Load when..." (cada paraula costa atenció).

Els problemes imprevistos (gotchas) són contingut de molt alt valor. Comenceu prims, feu-lo créixer a mesura que l'agent falla.

Recordeu que és fàcil trencar altres Skills preexistents afegint una nova Skill, fins i tot encara que no l'hagueu tocada (aneu amb compte amb l'acció a distància).

Utilitzeu totes les eines disponibles cada vegada que escriviu i mantingueu una Skill. Si voleu aprendre més, el lloc web de Agent Skills té molts exemples bons, i tant el nostre repositori intern com l'ecosistema públic contenen molts exemples de Skills ben dissenyades.

Citació

@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}
}