Hoppa till innehåll
September 5, 2026

Promptware: Agenter som bevarar och förbättrar sina egna instruktioner

En promptware är en självständig agentenhet som lagrar sina egna instruktioner, minne (Memory), verktygsbehörigheter (Tools) och körhistorik (Logs) som filer, och som reviderar sina instruktioner och sitt minne efter varje körning. I Ivy Tendril körs varje fas i planens livscykel, från planutkast till att öppna en pull request, av en av dessa enheter. Instruktionerna är versionshanterade filer i arkivet, vilket gör att de kan granskas, jämföras (diffas), rullas tillbaka och delas i teamet precis som vilken källkodsfil som helst. Den här artikeln förklarar strukturen hos en enhet, körloopen, de sju inbyggda promptware-enheterna och de två fellägen man behöver hålla koll på.

Vad en promptware-enhet innehåller

En promptware-enhet är en katalog med fyra delar. Varje del har ett specifikt syfte.

Del Innehåll Vem som skriver det
Program.md Instruktionerna som agenten följer i sin fas. Revideras av agenten efter en körning, granskas av människor. Agenten och människor
Memory/ Bestående lärdomar om kodbasen och teamets konventioner. Fylls på efter varje körning. Agenten
Tools/ De avgränsade behörigheterna för fasen: vilka kommandon, filer och integrationer agenten får använda. Människor
Logs/ Körhistoriken: vad agenten läste, körde och ändrade samt vilka slutsatser den drog. Agenten (endast tillägg)

Program.md är prosa, inte kod. Ett avsnitt för en planexekverande enhet kan se ut så här:

## Innan du öppnar en pull request

- Kör `pnpm lint` och `pnpm test` från arkivets rotkatalog. Öppna inte en PR om något av kommandona misslyckas.
- Begränsa ändringarna (diffen) till filerna som anges i planen. Om ytterligare en fil måste ändras, motivera detta i PR-beskrivningen.
- Använd commit-meddelandeformatet `type(scope): summary`.

En minnespost registrerar något som agenten lärt sig och som inte är uppenbart från koden, men som framtida körningar bör känna till:

### 2026-08-21, plan #412

Faktureringsmodulen under `src/billing/` saknar tester. Lägg till tester innan den refaktoreras.
`pnpm test` kör databasmigreringarna först; en körning tar ungefär fyra minuter på en ren utcheckning.

De två filerna skiljer sig till sin natur. Programmet anger vad som ska göras. Minnet beskriver vad som är sant om det här arkivet. Genom att hålla dem åtskilda kan en granskare godkänna ett nytt faktum utan att acceptera en ändring av arbetsmetoden – och tvärtom.

Körloopen

Varje promptware-körning följer samma fyra steg.

  1. Läs in programmet. Agenten läser Program.md och behörigheterna i Tools/. Inget utanför dessa behörigheter är tillgängligt för den.
  2. Läs minnet. Agenten läser Memory/ så att fakta från tidigare körningar finns med i kontexten innan arbetet startar.
  3. Exekvera uppgiften. Agenten utför fasens arbete: utarbetar en plan, bygger ut den, kör den i ett worktree eller öppnar en pull request. Varje verktygsanrop och dess utdata läggs till i Logs/.
  4. Reflektera och skriv tillbaka. Agenten jämför vad som inträffade med vad programmet angav att den skulle förvänta sig. Nya fakta sparas i Memory/. Om en instruktion var felaktig, saknades eller var överflödig, reviderar agenten Program.md.

Loopen att agera, observera resultatet och revidera nästa instruktion är samma mönster som beskrivs i ReAct-artikeln för resonerande agenter; en promptware skiljer sig främst genom att revideringen skrivs till en fil som lever vidare efter körningen. Det fjärde steget är det som gör att instruktionerna förbättras över tid istället för att försämras. Det är också det steg som kräver mest tillsyn, vilket avsnittet om risker behandlar.

De inbyggda promptware-enheterna

Ivy Tendril levereras med sju promptwares, en för varje fas i livscykeln som beskrivs i från GitHub-ärende till pull request. Var och en har sitt eget program, minne, behörigheter och loggar.

  • CreatePlan omvandlar en idé, ett GitHub-issue eller en felrapport till ett planutkast: mål, omfattning, berörda filer och verifieringssteg.
  • ExpandPlan lägger till detaljer i ett utkast som saknar tillräcklig information för att köras, till exempel acceptanskriterier eller öppna designbeslut.
  • UpdatePlan skriver om ett utkast baserat på utvecklarens infogade kommentarer.
  • SplitPlan delar upp en plan vars omfattning har vuxit i flera mindre planer som kan köras parallellt.
  • ExecutePlan kör den godkända planen med vald kodningsagent (Claude Code, Codex CLI, Copilot CLI, Gemini CLI, OpenCode eller valfri CLI-agent) i ett isolerat git-worktree. Anthropics bästa praxis för Claude Code lyfter fram samma argument för incheckade instruktionsfiler som det här avsnittet gör för Program.md.
  • CreatePr öppnar en pull request efter att diffen har passerat verifiering och mänsklig granskning.
  • CreateIssue skapar ett GitHub-issue utifrån en rekommendation eller observation under exekveringen.

Eftersom varje enhet är isolerad delas inte minnet från CreatePlan (till exempel: "teamet vill att planer specificerar vilka testfiler som ska ändras") med ExecutePlan, och ExecutePlans behörighet att köra skalkommandon ges inte till CreatePlan. I promptware-dokumentationen listas standardinnehållet för varje enhet.

Versionshanterade instruktioner och de två riskerna

Varför filer i arkivet slår tillfälliga prompts

En tillfällig prompt som skrivs i ett chattfönster existerar bara en gång, för en enda person, och försvinner när sessionen avslutas. En Program.md incheckad i arkivet har fyra egenskaper som en prompt saknar:

  1. Granskning. En ändring i programmet är en diff i en pull request. En senior ingenjör kan avvisa en instruktion som "hoppa över tester om ändringen är liten" innan den påverkar någon körning.
  2. Diff. När kvaliteten på resultaten förändras visar git log för promptware-katalogen exakt vilken instruktion som ändrades och när.
  3. Återställning (Rollback). En felaktig revidering återställs med en enda commit.
  4. Delning. Varje utvecklare i teamet, och varje agentkörning, använder samma instruktioner. En konvention som lärdes in under en körning på måndagen tillämpas av alla på tisdagen.

Detta är samma resonemang som flyttade infrastruktur från manuell konfiguration till versionshanterade filer, och samma princip som ligger bakom att hålla konfiguration utanför koden i The Twelve-Factor App; det gäller av exakt samma skäl. Andra sätt att strukturera agentarbete och hur promptware förhåller sig till dem tas upp i mönster för agentorkestrering.

Risk 1: Instruktionsavvikelse (instruction drift)

En agent som kan redigera sitt eget program kan också göra det sämre. En körning som misslyckas på grund av ett instabilt (flaky) test kan lägga till "försök köra misslyckade tester upp till tre gånger igen", vilket döljer ett verkligt problem nästa gång. Två saker begränsar detta. För det första är programmet en versionshanterad fil, så en revidering är en diff som en granskare ser och kan rulla tillbaka. För det andra loggar Logs/ körningen som föranledde revideringen, så att granskaren kan bedöma om resonemanget håller innan ändringen accepteras.

Risk 2: Uppsvällt minne (memory bloat)

Ett minne som bara växer blir en kostnad utan nytta. En fil med 400 poster, varav hälften är inaktuella, kostar tokens vid varje körning och gör det svårare att hitta de användbara posterna. Två metoder håller det användbart. Datum- och omfattningsmärk varje post, som i exemplet ovan, så att inaktuella poster är enkla att hitta. Rensa under granskning: när en plan berör ett visst område kontrollerar granskaren de relaterade minnesposterna och tar bort det som koden inte längre stöder. Kostnads- och tokenspårning per plan och jobb gör tillväxten synlig, eftersom en enhet med uppsvällt minne visar ett stigande tokenantal utan motsvarande ökning i planens storlek – vilket är anledningen till att mätning av kodningsagenters genomströmning spårar kostnad per sammanfogad pull request snarare än kostnad per körning.

Hur man kommer igång

Installera Ivy Tendril, öppna ett arkiv och skapa en plan. De sju inbyggda promptware-enheterna finns där från första körningen.

curl -sSf https://cdn.ivy.app/install-tendril.sh | sh

På Windows använder du irm https://cdn.ivy.app/install-tendril.ps1 | iex. Läs filerna Program.md innan du kör en exekvering, och granska sedan de första minnesposterna och programrevideringarna med samma noggrannhet som en kodändring. Efter ett tiotal planer kommer minnet att spegla de delar av kodbasen där agenten stötte på problem, vilket oftast också är där en människa skulle göra det. I promptware-dokumentationen finns mer information om de inbyggda enheterna.

Vanliga frågor

Ändrar agenten Program.md utan att fråga?

Agenten reviderar sitt program efter en körning. Eftersom Program.md är en versionshanterad fil är revideringen en diff som du kan läsa, godkänna eller återställa, och loggen från körningen som orsakade den finns sparad bredvid den.

Kan jag skriva mina egna promptware-enheter?

De sju inbyggda enheterna täcker livscykelns alla faser. Deras program, minne och verktygsbehörigheter är vanliga filer, så du kan redigera dem för att matcha ditt teams konventioner. Se dokumentationen för de aktuella utökningsmöjligheterna.

Var lagras minne och loggar?

På maskinen som kör Tendril. De laddas inte upp till Ivy. De enda nätverksanrop Tendril gör är till det LLM-API du konfigurerat samt till GitHub.

Kom igång med Ivy Tendril

Är du redo för parallell agentorkestrering på utvecklarnivå?

Written by

Ivy Team