Designing, refining, and maintaining agent skills at Perplexity

Perplexitys frontier-agentprodukter hviler på et fundament af knowhow og domæneekspertise pakket ind i modulære Agent Skills. Vi vedligeholder et omhyggeligt udvalgt bibliotek af Skills på tværs af vores tekniske miljøer. Disse Skills omfatter mange af de generelle værktøjer, der driver Perplexity Computer; vertikalspecifikke egenskaber inden for områder som finans, jura og sundhed; og en lang række moduler til at imødekomme brugeres behov. Nogle Skills aktiveres sjældent, men er kritiske, når de aktiveres. For at sikre en konsekvent fremragende brugeroplevelse prioriterer Perplexitys agent-team kvaliteten af Skills lige så højt som kodekvaliteten.

De intuitioner og best practices, der kræves for at udvikle en Skill af høj kvalitet, adskiller sig væsentligt fra dem, der kræves for at bygge traditionel software. Agent-teamet gennemgår mange pull requests fra dygtige ingeniører, som udvikler Skills i deres arbejde. Resultatet er næsten altid utallige kommentarer og forslag til revision. Det skyldes, at mange nyttige mønstre til skrivning af kode bliver til antipatterns ved oprettelse af Skills.

Hvis man f.eks. tager nogle af aforismerne fra PEP20 – The Zen of Python, står det hurtigt klart, at det at skrive god Python-kode ikke er det samme som at skrive gode Skills. Ud af de 20 visdomslinjer er mindst halvdelen fuldstændig forkerte eller direkte vildledende, når man skriver Skills. Her er fem af dem:

Fem kontraster mellem Zen of Python og artiklens vejledning til at skrive Skills.

Denne guide er det dokument, som ingeniører på tværs af Perplexity bruger, når de udvikler og gennemgår Skills. Vi frigiver også denne guide til offentligheden, så vores opdagelser og erfaringer kan komme det bredere samfund til gode. Uanset om du er ingeniør og designer produktions-Skills i dit daglige arbejde, eller en Computer-bruger, der ønsker at udvikle din egen Skill inden for et område, du kender bedst, eller begge delene, er denne guide til dig.

Hvad er en Skill?

Når du skriver en Skill, skriver du ikke bare almindelig gammel software (selvom Skills nu er en del af de vigtigste logiske motorer for agentsystemer). I stedet opbygger du kontekst til modeller og deres miljøer. En Skill har andre begrænsninger og andre designprincipper. Hvis du skriver en Skill, som du skriver kode, vil du fejle.

En Skill er mindst fire ting, især i sammenhæng med den måde, vi bygger dem på hos Perplexity.

En Skill er et bibliotek

En Skill er ikke bare en enkelt SKILL.md-fil. I mange tilfælde indeholder en Skill flere filer. Under mappen opkaldt efter din Skill kan du have:

SKILL.md: frontmatter og instruktioner

scripts/: kode, som agenten kører, i stedet for at genopfinde

references/: tunge dokumenter, indlæses betinget

assets/: skabeloner, skemaer og data

config.json: brugeropsætning ved første kørsel

Dette hub-and-spoke-mønster gør det muligt at holde Skills meget fokuserede og stramme, og man kan bruge mappestrukturen på en meget kreativ måde. Nogle gange har særligt indviklede Skills fordel af flere hierarkiniveauer for at hjælpe modellen med at navigere bedre. Forudsæt en Skill, der kræver viden på tværs af 300 emner, som kan grupperes i 20 faglige områder. At vælge det rigtige emne pålideligt blandt 300 er en ubesvaret udfordring selv for nutidens bedste frontier-modeller. Det er et meget nemmere valgproblem for en model at indsnævre til et af 20 områder end blandt de 15 emner inden for det pågældende område.

Som et eksempel på, hvordan et hierarki i flere niveauer giver værdi, benyttede vores team tre niveauer af emnemæssig indlejring i de Skills, der drev Computers amerikanske indkomstskattefunktioner i denne skattesæson. Dette hierarki var helt uundværligt i betragtning af skattelovgivningens kompleksitet: I vores tidlige tests resulterede det i at præsentere modellen for en enkelt mappe, der indeholdt alle 1.945 sektioner i U.S. Internal Revenue Code, i en ringere ydeevne end slet ikke at indlæse Skillen. Organisering af informationen i logiske underinddelinger var uundværlig for at sikre læseoperationer med høj præcision.

Alligevel kom dette hierarki ikke gratis. Stigende hierarkiniveauer kræver stigende niveauer af kuratering på tværs af informationsarkitekturen for at håndtere den resulterende indirekte adgang. Vi udformede hurtige opslagsguider, tilpassede søgeværktøjer og andre værktøjer til at støtte modellen i at finde information med et minimum af omveje. I dette tilfælde skabte det hårde arbejde med kuratering i sidste ende et positivt slutresultat: en Skill, der gjorde det muligt for modeller at udføre skatterelaterede opgaver meget dygtigere end ved kun at bruge generelle værktøjer.

Udvid

En Skill er et format

En Skill er et format. Den vigtigste rod-SKILL.md-fil skal have både et navn og en beskrivelse. Desuden skal Skillen præcist matche mappenavnet, som Skillen er placeret i. Navnet skal udelukkende bestå af små bogstaver, må ikke have mellemrum og kan bruge bindestreger. Beskrivelsen er routing-udløseren. Dette er et almindeligt fejlpunkt: beskrivelsen er ikke intern dokumentation for, hvad Skillen gør. Den udgør instruktioner til modellen om, hvornår den skal indlæse Skillen. Så du vil ofte se "Load when" (Indlæs når), ikke "This Skill does" (Denne Skill gør). Dette er vigtigt på grund af den måde, hvorpå de fleste implementeringer indsprøjter beskrivelsen i modelkonteksten.

Inden for frontmatteren findes der også "depends:", som gør det muligt at oprette hierarkiske Skill-afhængigheder, og "metadata:", som bruges til gennemsyn og evalueringer. Forskellige agentsystemer kan endda definere deres egne frontmatter-felter, der skal bruges på en måde, der er specifik for disse systemer. Som et alternativ kan Skill-specifik metadata pakkes i en ekstra JSON- eller YAML-konfigurationsfil. Dette er ønskværdigt, når man bygger agentsystemer, der skal facilitere forskellige typer kørtidsadfærd pr. Skill uden at forurene modellens kontekst med detaljer. Endelig kan lignende adfærd opnås ved at fjerne Skill-frontmatter ved læsning. Computer anvender denne metodologi, hvilket gør det muligt at bevare konfigurationen i rod-SKILL.md-filen. Der kræves omhyggelig opmærksomhed på detaljer i parseringslogikken, og man vil måske ønske at implementere betinget fjernelse, hvis der er visse felter, som det er nyttigt at have inden for modelkonteksten.

En Skill kan aktiveres

En Skill kan aktiveres. Agenten indlæser en Skill under kørsel. Vigtigt er det, at Skills ikke altid er bundtet ind i konteksten. Som standard udfolder de fleste agentsystemer gradvist Skills efter specifikt behov.

Der er mindst tre niveauer af kontekstomkostninger på den måde, vi har implementeret Skills på i Computer. Her er processen:

Computer kalder load_skill(name="...")

Computer kopierer Skill-mappen ind i det isolerede eksekverings-sandbox

Computer auto-indlæser rekursivt afhængigheder i "depends:"-tagget

Computer fjerner derefter frontmatteren, og agenten ser dermed kun brødteksten og de yderligere filer

Forskellige agentsystemer kan vælge at eksponere Skill-indhold på forskellige måder. Som et eksempel vælger nogle systemer muligvis slet ikke at eksponere filhierarkiet, men overlader det til modellen at opdage hierarkiet gennem filsystemoperationer. Andre systemer vælger måske at give modellen et overblik over hele filtæet op til en vis afskæring og/eller dybdegrænse. For at holde konteksten ren udelader Computer fulde filhierarkier fra aktiveringskonteksten; dette kan dog tilsidesættes for hver enkelt Skill.

En Skill er progressiv

Skills er progressive. I Computer er der tre forskellige niveauer af kontekstomkostninger, og vi pådrager os alle tre på forskellige stadier:

De tre niveauer af Skill-kontekst: indeks, fuld Skill-indlæsning og runtime-referencefiler.

Computer opbygger et Skill-indeks, der har navnet og beskrivelsen for hver tilgængelig Skill. Budgettet for dette er omkring 100 tokens pr. Skill (kortere er endnu bedre). Det er så stramt, fordi du betaler denne omkostning i hver session for hver bruger. Dette indsprøjtes i systemprompten helt i begyndelsen af samtalen. Modellen har adgang til en række navngivne Skills og beskrivelser, så den kan beslutte, om den skal kalde "load_skill()". Adgangskravet for at komme ind i dette indeks er ekstremt højt. Din Skill skal være meget nyttig, og beskrivelsen skal være ekstremt tæt og kortfattet, fordi alle betaler omkostningen hele tiden.

Efter agentsystemet indlæser Skillen, er der den fulde SKILL.md-brødtekst. Ideelt set overstiger brødteksten ikke 5.000 tokens. Selv da ønsker du, at hver sætning betyder noget, for når først du indlæser en Skill, skal resten af samtalen betale det, indtil du rammer komprimeringsgrænsen. Mange tråde indlæser alt mellem tre og fem forskellige Skills, hvilket multiplicerer denne omkostning. Skills med en masse fyld vil næsten helt sikkert forringe andre Skills såvel som de overordnede agent-evner. Kort sagt, hvis din Skill indlæses og ikke gør det rigtige, er det spildt kontekst.

Det endelige progressionsniveau er scripts eller specialtilfælde, såsom subskills eller formatering. Det er her, du vil placere ubegrænset betinget forgrenet logik. Agenten vil kun bruge det, når den har brug for det, hvilket betyder, at der er en meget lavere bar for det, du ønsker at placere her.

I indeksen er hvert token vigtigt. Den indlæste Skill-brødtekst er mere afslappet, og køretiden er mest afslappet. Dette kan være 20.000 tokens eller nul tokens. Dette er det niveau, hvor du måske overvejer at udvide modellens kontekst på en progressiv måde.

Hvornår har du brug for en Skill?

Agent-teamet bliver ofte spurgt om deres mening om, hvorvidt en Skill er reelt nødvendig for et givet domæne eller brugstilfælde. Meget sjældent har vi et definitivt svar udelukkende fra første principper. Den eneste måde at finde ud af det på er at starte med din agent uden Skillen, køre flere nøgleforespørgsler og derefter finde ud af, om agenten gør et godt stykke arbejde.

Når du har brug for en Skill

Der er mange opgaver, der er in-distribution for trænede modeller. Du behøver kun at anvende en Skill, hvis du vil ændre denne adfærd på en specifik måde, som du ikke kan med f.eks. én sætning i din prompt. Så du har brug for en Skill, når agenten vil gøre det forkert uden specifik kontekst, eller hvis der er en inkonsekvens eller ikke-determinisme, som du har brug for skal være ekstremt konsekvent på tværs af kørsler.

Det kan være, at din viden er holdbar, men ikke findes i træningsdataene. Der kan være cutoffs eller virksomhedsspecifikke arbejdsprocesser, eller det kan være et spørgsmål om smag. For eksempel har vi flere designrelaterede Skills i Computer skrevet af Henry Modisett (vores designchef). Grunden til, at hvert token findes i disse Skills, er, at Henry har rigtig god smag, når det kommer til at designe websteder og PDF'er. Henry specificerer, hvilke fonte der skal bruges, og hvilke der ikke skal bruges, hvordan disse fonte føles, og andre dømmekraftsspørgsmål, som modellen ikke kan lære udelukkende fra træningsdata.

Når du ikke har brug for en Skill

Vi ser mange Skills, hvor ingeniører har skrevet en række git-kommandoer, der skal udføres i rækkefølge. Det er unødvendigt, fordi modellen allerede ved, hvordan den gør det, hvilket betyder, at det giver god dokumentation, men en dårlig Skill.

Vi ser eksempler, hvor Skills rekapitulerer instruktioner fra systemprompten. Du har ikke brug for en Skill til det. Viden, der er relevant for flertallet af forespørgsler, bør inkluderes i global kontekst, ikke i en betinget indlæst Skill

Hvis der er noget, der ændrer sig hurtigere, end du kan vedligeholde det, har du ikke brug for en Skill. For eksempel, hvis du rammer et fjernt MCP-endpoint, og dets værktøjer eller versionerne af disse værktøjer ændrer sig hyppigt, bør du ikke indsprøjte dem i en Skill. Hvis du gør det, ender du bare med drift, og modellen vil begå fejl.

Enhver Skill er en skat

Her er en nyttig test, du kan anvende på hver sætning i din Skill: "Ville agenten gøre dette forkert uden denne instruktion?" Hvis sætningen ikke behøver at være der, har den ikke råd til at være der, fordi alle betaler denne omkostning hver eneste gang. Når du beslutter dig for, om du vil tilføje en Skill eller ej, skal du huske denne skat, hvor hver session og hver bruger koster tokens.

Følgende berømte citat, som lyder meget bedre på fransk, oversættes groft til "Jeg har kun lavet dette brev længere, fordi jeg ikke har haft tid til at gøre det kortere."

« 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

Ligesom Pascal er du nødt til at investere tid i hver Skill. Det er svært at skrive en kort Skill. Hvis din Skill er nem at skrive, er den sandsynligvis for lang eller burde ikke eksistere. En god Skill er så kort, som den kan være.

Hvis du tager dig selv i at forsøge at lave one-shot Skill-generering og oprette PR'er på fem minutter, vil resultaterne næsten helt sikkert være under middel. Faktisk har tidlig forskning vist, at hvis du bruger LLM'er til at skrive Skills, vil LLM'en sandsynligvis ikke drage fordel af det: "Selvgenererede Skills giver ingen fordel i gennemsnit, hvilket viser, at modeller ikke pålideligt kan forfatte den proceduremæssige viden, de drager fordel af at forbruge."

Sådan bygger du en Skill

Med andre ord er du nødt til at indsprøjte din holdning i enhver Skill, du skriver. Følg disse trin.

Trin 0: Skriv evals

Skriv nogle af evals først. Du kan indhente evalueringssager fra:

Rigtige brugerforespørgsler: sample fra produktion eller din vidensbase

Kendte fejl: Agenten fejlede, fordi Skillen ikke fandtes

Nabo-forvirring: Tæt på din domænegrænse, men router til en anden Skill

Du bør som minimum sikre dig, at du tester, at Skillen indlæses, når det er nødvendigt. Ideelt set sampler du nogle af disse, måske fra et produktionsmiljø. Du kan også overveje kendte fejltilfælde: Måske er hele grunden til, at du satte dig for at skrive Skillen, på grund af en specifik fejl, du bemærkede, eller måske er du ved at refaktorisere, og der er en vis forvirring i to tætte domæner, der dækkes af én Skill.

Start med lignende negative og positive eksempler. Negative eksempler er ekstremt kraftfulde og kan betyde mere end positive eksempler.

Trin 1: Beskrivelsen

Dette er den sværeste linje i Skillen. Det er en routing-udløser, ikke dokumentation. For at få navnet og beskrivelsen rigtige er du ligeglad med indholdet af Skillen. Du er kun interesseret i, om Skillen indlæses og indsprøjtes på de rigtige tidspunkter og er fri for utilsigtede bivirkninger, hvilket er den primære fejltilstand. Hver gang du tilføjer en ekstra Skill, risikerer du at gøre hver anden Skill lidt dårligere, så du skal sørge for at minimere regression.

Igen beskriver en dårlig beskrivelse, hvad Skillen gør, eller hvorfor den er nyttig. En god beskrivelse fortæller, hvornår agenten skal indlæse Skillen. Sig f.eks., at du har noget til overvågning af pull requests. Skriv ikke, hvad Skillen gør. Skriv, hvad ingeniører siger, når de er frustrerede, og de vil have dig til at sikre, at deres PR virker, såsom "babysit", "watch CI" eller "make sure this lands".

Her er en hurtig tjekliste:

Starter med "Load when..."

Sigt efter 50 ord eller færre

Beskriver brugerens hensigt, ideelt set fra rigtige forespørgsler

Opsummerer ikke arbejdsprocessen

Rigtige forespørgsler er det, du kan dække i en 80-20. Normalt fungerer to eller tre eksempler godt. Det er ikke nemt at tilføje præcist og kun så meget, som du har brug for.

Trin 2: Skriv brødteksten

Dernæst skal du skrive selve indholdet af Skillen. Bemærk, at dette ikke er trin 0 eller trin 1.

At kommunikere arbejdsprocesser til en LLM er fuldstændig forskelligt fra at kommunikere arbejdsprocesser til en kollega eller endda til dit kørtidssystem. Når en ingeniør lærer et nyt softwareværktøj, skal vedkommende muligvis læse dokumentationen, få en gennemgang af en med erfaring og lære at bruge værktøjet. I mellemtiden, for næsten ethvert softwareværktøj, der har eksisteret i mindst et år, behøver du bare at nævne dets navn, og LLM'en har alle de oplysninger, den har brug for.

Når du skriver brødteksten, skal du springe det åbenlyse over. Mange ingeniører har masser af erfaring med at skrive readme.md-filer, der opisterer hver kommando, som nogen har brug for at køre. Det er nemt at falde tilbage på det, når du skriver en Skill, fordi det føles som om, du skriver dokumentation, men hvis du gør det, bliver din Skill noget rod. Så lad være med at skrive en række kommandoer.

F.eks. behøver du ikke at skrive: "git log # find the commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;"

Skriv i stedet: "Cherry-pick commit'et over på en ren branche. Løs konflikter, så hensigten bevares. Hvis det ikke kan lande rent, skal du forklare hvorfor."

Modellen vil gøre et meget bedre stykke arbejde med sidstnævnte end med førstnævntes overdrevent præskriptive række af kommandoer, især når tingene går galt. Lad være med at lægge skinner ud eller være overdrevent præskriptiv, hvilket er skrøbeligt, og vær i stedet fleksibel, hvor flere tilgange kan fungere. Igen er god dokumentation for mennesker oftest dårlig dokumentation for modeller.

Dernæst skal du fokusere på faldgruberne eller de negative eksempler. Disse er indhold med ekstremt høj værdi, fordi de ofte vejleder modellen med hensyn til, hvad den ikke må gøre. Hvis du tilføjer en linje hver gang agenten snubler, vil du lære ved at køre den, og faldgruberne vil vokse organisk.

Endelig, hvis der er en del, der er betinget eller ekstremt tung i indhold, skal du tage den ud af SKILL.md, som er hubben, og lægge den ind i en af egerne (spokes). Læg den i en accessorisk fil, der kan indlæses progressivt, hvilket vi vil dykke ned i næste gang.

Trin 3: Brug hierarkiet

Gør brug af Skill-hierarkiet, når du har et script, referencer, eller du bruger et bestemt værktøj:

Foreslåede anvendelser af scripts, referencer, assets og konfiguration i en Skill.

For alt, der er betinget eller forgrener sig fra hoved-Skillen, skal det brydes ud i en mappe. Husk også, at hierarki i flere niveauer kan bruges til særligt indviklede Skills. For disse vil du ønske at overveje nøje, om funktionaliteten skal implementeres monolitisk eller som en samling af Skills (måske med depends:-baserede indlæsningsrelationer).

Trin 4: Iterér

Dernæst skal du udføre en flok iterationer på en branche. Start på hovedbranchen uden nogen Skill, foretag nogle iterationer, byg dit sæt af nøgleforespørgsler, og kør en masse evals. Enhver, der gennemgår din Skill-kode, vil takke dig for at indsende et enkelt ændringssæt komplet med et evalueringssæt. Det er meget svært at gennemgå hinanden følgende inkrementelle ændringer (undtagen en ny faldgrube), så prøv at minimere det.

Du vil sandsynligvis foretage mange små ordændringer. Små ordændringer i beskrivelser kan have en uforholdsmæssig stor indvirkning på routing (herunder overløbseffekter på andre Skills), så gør alt det arbejde før trin 5.

Trin 5: Udgiv

Udgiv den.

Sådan vedligeholder du en Skill

Nu hvor du har skrevet en Skill, skal du vedligeholde den.

Faldgrup-svinghjulet

Fra dette tidspunkt har din liste over faldgruber en tendens til at vokse eller ændre sig meget. Vi ser ofte ingeniører, der laver PR'er, der f.eks. er uevaluerede, og ændrer beskrivelsen. Hvis du ændrer beskrivelsen, efter din Skill er blevet flettet, er du på afveje. Hvis du foretager ændringer i den ting, der beslutter, om din Skill skal routes, er du nødt til at skrive nogle evals, der understøtter ændringerne.

Skills er primært tilføjende (append-mostly). Faldgrube-sektionen oparbejder mest værdi over tid:

Agenten fejler i noget → Tilføj en faldgrube

Agenten indlæser Skillen ved siden af målet → Stram beskrivelsen op, og tilføj negative evals

Agenten indlæser ikke Skillen, når den burde → Tilføj nøgleord og positive evals

Systemprompten ændrer sig → Tjek for strid eller duplikering

Det er nemt at bemærke en enkelt fejltilstand i intern testning eller i produktion og tilføje en faldgrube. Det er et negativt eksempel, så det ændrer ikke rigtig eksplicit vejledning, men det lader modellen vide: "Hey, der er denne kendte fejl."

Når du bevæger dig fra 80-20 til at opnå en succesrate på 99,9 % eller 99,99 %, er det nemt at udvide denne liste over faldgruber. Når du ser disse negative eksempler, bør du primært tilføje dem til faldgrube-sektionen. Du bør ikke tilføje længere instruktioner eller ændre beskrivelsen.

Eval-suite

Hos Perplexity kører vi mange eval-suiter for at tjekke for forskellige ting. Der er Skill-indlæsning og læsning af Skill-filer, hvilket tjekker præcisionen, genkaldelsen og forbudte tjek af selve Skill-indlæsning. Vil agenten route din Skill, når den skal? Disse sikrer, at nye Skills ikke bryder eksisterende grænser.

Der er også evals, der kan tjekke for korrekt progressiv indlæsning. Agenten indlæser muligvis Skillen, men læser den den accessoriske fil eller filer? For eksempel, hvis du har en finans-Skill til finansforespørgsler, læser den så den særlige FORMATTING.md-fil?

Der er også evals til Skills, der tester for end-to-end opgavefuldførelse inden for domæner. Vi kører hele agent-loopet og bruger en LLM-dommer til at bedømme resultaterne baseret på et regelsæt af veldefinerede kriterier.

Endelig er det vigtigt at køre disse evals mod forskellige modeller. Computer understøtter mindst tre forskellige orkestreringsmodelfamilier: GPT, Claude Opus og Claude Sonnet. Du ønsker at køre din Skill-indlæsning og domæne-Skills mod disse forskellige agent-orkestratorer for at sikre, at du ikke får forskellig adfærd. Sonnet og GPT opfører sig ganske anderledes, når det kommer til Skills.

Afsluttende tanker og takeaways

Jo flere Skills du bygger, jo bedre bliver du til at bygge dem. Hvis du ikke automatiserer eller prøver at gøre opgaver, som du udfører til daglig, mere reproducerbare ved hjælp af Skills, bør du starte med det samme.

Handlingen med at bygge Skills gør dig bedre til at bygge flere Skills, men desuden er de ekstremt gode til at automatisere forretningsprocesser. Hvis du kan beskrive noget, du gør hver uge før dit standup-møde, i slutningen af hver sprint, eller alt hvad du gør som ingeniør på daglig, ugentlig eller endda kvartalsvis basis, bør du skrive en Skill for at købe din tid tilbage.

Kan du automatisere postmortems? Kan du gennemgå pull requests? Enhver opgave, du kan udføre, kan du i det mindste lade første gennemløb være en Agent Skill. Det vil spare dig for betydelig tid.

Når det er sagt, skal du huske på, at en Skill ikke er nem eller endda altid nødvendig. Mindre er mere. Et par andre takeaways:

Skriv evals før Skillen. Inkluder negative eksempler og forbudte indlæsninger for tilstødende, men distinkte skills.

Beskrivelsen er den svære del. "Load when..." (hvert word koster opmærksomhed).

Faldgruber er indhold med ekstremt høj værdi. Start tyndt, og voks, efterhånden som agenten fejler.

Husk, at det er nemt at ødelægge andre forudeksisterende Skills ved at tilføje en ny Skill, selvom du ikke rørte ved den (pas på handling på afstand).

Brug alle tilgængelige værktøjer hver gang du skriver og vedligeholder en Skill. Hvis du vil lære mere, har Agent Skills-webstedet masser af gode eksempler, og både vores interne lager og det offentlige økosystem indeholder mange eksempler på veldesignede Skills.

Citation

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