Subagenter: hvornår en AI-agent skal dele arbejdet op

En subagent er en AI-agent, som en anden agent sender en delopgave til. Den arbejder i sin egen kontekst og sender kun et kort svar tilbage. Det lyder som en god måde at dele arbejdet på. Derfor bygger mange en subagent til hver rolle eller afdeling: én til salg, én til økonomi, én til kundeservice og en chef-agent øverst, der fordeler opgaverne.

Den 22. oktober 2026 skrev Anthropic, der laver Claude, at det ofte er den forkerte vej. Deres team har sammenlignet agenter hos flere store kunder. Én agent med skills gav ofte bedre svar end både én kæmpe-prompt og en flok subagenter. Tit var den også billigere og hurtigere. Anthropic kalder fejlen ved navn: agenterne bliver “a copy of their org chart”, en kopi af organisationsdiagrammet.

Jeg fandt artiklen gennem Ray Amjads video om den. Han bygger med kodeagenter og underviser i det. I videoen gennemgår han artiklen, prøver rådene af på sit eget setup og viser, hvad de betyder, når agenterne skriver kode. Det er Anthropic, der har lavet undersøgelsen. Men flere af eksemplerne i guiden og spørgsmålet, der afgør det hele, har jeg fra Ray.

Guiden er til dig, der bygger agenter. Den er også til dig, der har fået ansvaret for AI og står med et forslag om “en agent til hver afdeling”. Du får reglen for, hvornår arbejdet skal deles op, de tre situationer, hvor en subagent er det rigtige valg, og hvordan du gør i Claude Code.

Hurtige svar

Hvad er en subagent? En hjælpeagent med sit eget kontekstvindue, sine egne instruktioner og sine egne værktøjer. Den løser en delopgave og sender et resumé tilbage. Se også subagent i ordbogen.

Hvad er fejlen? At dele agenterne op efter roller og afdelinger. Så skal de sende viden til hinanden, og noget går tabt hver gang.

Hvad gør man i stedet? Bygger én agent og giver den skills og værktøjer, som den henter frem, når den skal bruge dem.

Hvornår er en subagent rigtig? Når opgaven skal ses med friske øjne. Når flere uafhængige opgaver kan køre samtidig. Og når én agent målbart bliver dårligere af at have det hele.

Hvad er spørgsmålet, der afgør det? Hjælper det, hovedagenten allerede ved, skader det, eller er det ligegyldigt?

Hvad en subagent er

En subagent har tre ting, som hovedagenten ikke deler med den: sit eget kontekstvindue, sine egne instruktioner og sine egne værktøjer. Hovedagenten giver den en opgave. Subagenten søger, læser og arbejder. Til sidst sender den et resumé tilbage. Alt det, den læste undervejs, bliver hos den.

Det er nyttigt af én grund. En agent, der selv læser 40 filer for at finde ét svar, fylder sin kontekst med tekst, den aldrig skal bruge igen. Claude Codes egen dokumentation siger det sådan: Brug en subagent, når en sideopgave ville fylde samtalen med søgeresultater, logfiler eller filer, du ikke skal bruge igen.

Men resuméet er også svagheden. Hovedagenten ser kun det, subagenten vælger at fortælle. Er en vigtig detalje skåret væk, ved hovedagenten det ikke. Hver gang arbejdet bliver delt, går der noget tabt i overleveringen.

Fejlen: én agent til hver kasse

Der er en gammel regel i softwareudvikling, der hedder Conways lov. Melvin Conway formulerede den i 1967: Organisationer, der designer systemer, er bundet til at lave designs, der kopierer deres egen kommunikationsstruktur. Seks teams bygger seks dele, uanset om opgaven naturligt falder i seks dele.

Det samme sker med agenter. Anthropic beskriver, hvordan det typisk går i en stor virksomhed. Man vil have én kundeagent, der kan svare på alt. Hvert produkt har sit eget team, så hvert team bygger sin egen agent. Fragt-teamet bygger en fragt-agent med adgang til fragtfirmaerne. Ordre-teamet bygger en ordre-agent. Retur-teamet bygger en agent, der kan flytte penge. Til sidst bygger et centralt team en chef-agent ovenpå, der fordeler spørgsmålene.

Det ser enkelt ud. Anthropic nævner fem problemer:

1. Kontekst går tabt. Nogen skal bestemme, hvad agenterne fortæller hinanden. Detaljer forsvinder i overleveringerne.
2. Agenterne vokser i antal. Hvert team laver sin egen. Videoen giver et eksempel: en refusions-agent, en retur-agent og så en retur-og-refusions-agent, fordi ingen vidste, at de to første fandtes. Anthropic har set virksomheder med hundredvis af overlappende subagenter uden fælles standard og uden en ejer.
3. Frankenprompten. Hvert team tilføjer en sætning til instruktionen. Reglerne strider mod hinanden, og agenten har ikke én stemme.
4. Test af dele i stedet for helheden. Hvert team tester sin egen agent. Ingen tester det hele, og ledelsen beslutter ud fra tal, der kun dækker en bid.
5. Det tager længere tid. En kunde målte sin flok af agenter mod én agent. Den ene agent var cirka dobbelt så hurtig.

En virksomhed havde et dusin specialist-agenter bag sin kundeagent. De gjorde det svært at holde en ensartet tone over for kunderne, og svartiden blev så lang, at brugerne mærkede det.

Personaer er samme fejl i det små

Fejlen er ikke kun for store virksomheder. Den findes også hos den enkelte, der bygger sit eget hold af agenter: en “CTO-agent”, en “sikkerheds-agent”, en “QA-agent”, hver med sin personlighed. Det ser ud som en organisation. Men det er stadig én model, der får at vide, at den skal lade, som om den er en anden.

Anthony Morris, der byggede Claude Code til desktop hos Anthropic, skrev 12. oktober 2026, at han ikke vil styre agenter med hver sin persona: “If intelligence is truly super there should be no need for roles. Smart generalists rule the world.” En kollega fra Anthropic svarede, at personaer snart bliver et anti-mønster.

Ray Amjad prøvede det af på sig selv. I en periode byggede han sit setup om til personaer: en stabschef, der talte med en QA-agent, en sikkerheds-agent, en analytiker, en bygger, en reviewer og flere til. Han prøvede at slå roller sammen og fjerne nogle. Så bad han Claude sammenligne det gamle og det nye setup ud fra hans tidligere sessioner. Svaret: Han fik mindre lavet, kvaliteten var den samme, og prisen pr. ændring var uændret. De nye lag tilføjede ingenting, men koordineringen kostede ekstra. Han gik tilbage til det gamle.

Hvorfor én agent med skills tit gør det bedre

Alternativet er ikke én kæmpe-prompt med alt i. Det er én agent, der kun ser korte beskrivelser af sine skills og værktøjer og henter det hele frem, når den skal bruge det. Det hedder progressive disclosure. Hvis begrebet skills er nyt, så start med guiden om Claude Skills.

Anthropic giver tre grunde til, at det virker.

Fælles kontekst giver bedre svar. En agent, der har set resultatet af hvert trin, kan forbinde dem. Det giver bedre svar end en stak resuméer fra subagenter. Det betyder også færre overleveringer, hvor noget kan gå tabt.

Videoen er selv et eksempel. Den er animeret af Claude. Før blev videoerne delt op i klip på 30 til 60 sekunder med en agent på hvert klip. Resultatet hang ikke sammen, fordi ingen agent så hele videoen. Da en chef-agent fik lov at se det hele, gik der i stedet noget tabt mellem den og agenterne på klippene. Det tog også længere tid. Én agent, der lavede hele videoen, gjorde det bedre.

Skills holder konteksten slank. Den gamle grund til at dele arbejdet op var, at én agent ikke kunne rumme instruktionerne til det hele. Med skills skal den ikke rumme dem på én gang. Anthropic skriver, at de har skåret over 80 procent af Claude Codes faste instruktion væk til de nyeste modeller, blandt andet ved at lade skills og værktøjer blive hentet efter behov.

Modellerne er blevet bedre. Fra Opus 4.5 kunne modellerne klare langt mere i én agent, end de fleste havde regnet med. Nyere modeller tjekker selv deres arbejde undervejs, hvis de har værktøjet til det. Anthropic skriver, at stive strukturer med mange agenter tit var det, der holdt en ny model tilbage. Den ny model kunne mere, men strukturen lod den ikke.

AI-forskeren Rich Sutton beskrev samme mønster i 2019 i essayet “The Bitter Lesson”. Hans pointe var, at generelle metoder, der bruger mere regnekraft, i det lange løb slår de metoder, hvor mennesker har bygget deres egen viden ind i systemet. Med viden mener han idéer om, hvordan systemet skal tænke, ikke fakta om din situation, som AI’en stadig skal have. Anthropics råd er et nyt eksempel på den lektie. En organisation af agenter er menneskets idé om, hvordan arbejdet skal deles. Modellen kan tit gøre det bedre selv.

Hvad med for meget kontekst?

Den indvending kommer altid. Bliver en agent ikke dum, når den har læst for meget? Det kan ske, og det har et navn: context rot. Men Anthropic er præcise på det punkt. Det skal være et målbart fald i kvalitet, ikke en fornemmelse.

Ray Amjad siger, at han ikke har set tal fra modelfirmaerne bag den grænse på 150.000 tokens, som mange nævner. Den passede måske på ældre modeller. Med Opus 5.5 kører han jævnligt op på 400.000 til 500.000 tokens og får stadig gode resultater. Det er hans erfaring, ikke en måling. Men det peger samme vej som Anthropic: grænsen flytter sig med hver ny model.

Spørgsmålet, der afgør det

Hvis du ikke skal dele efter rolle, hvad skal du så dele efter? Anthropics svar er kontekst. Giv hver subagent en opgave, der kun kræver lidt fra resten af systemet, og som kan aflevere et kort svar.

Ray Amjad gør det til ét spørgsmål, du kan stille om hver delopgave:

Et eksempel: tilbuddet

Et konstrueret eksempel. En maskinfabrik med 60 ansatte vil have en agent til at lave tilbud. Organisationsdiagrammet ville give fire agenter: en salgs-agent til teksten, en kalkulations-agent til prisen, en produktions-agent til leveringstiden og en jura-agent til vilkårene.

Kalkulations-agenten opdager undervejs, at kunden vil have rustfrit stål og ikke almindeligt. Det ændrer prisen. Det ændrer også leveringstiden, fordi stålet skal bestilles hjem. Hvis produktions-agenten ikke hører om det, står der fire uger i tilbuddet i stedet for seks. Salgs-agenten skriver et følgebrev om noget, ingen af dem har set samlet.

Med spørgsmålet ser det anderledes ud. Pris, leveringstid, vilkår og brev hænger sammen. Det, agenten lærer om stålet, skal bruges alle fire steder. Det skal én agent lave, med skills til kalkulation, produktionsplan og vilkår. Til gengæld har to opgaver gavn af ikke at vide noget:

• Tjekket. En ny agent får kun kundens forespørgsel og det færdige tilbud. Den ved ikke, hvorfor den første agent valgte, som den gjorde. Derfor ser den det, der mangler.
• Priserne fra leverandørerne. At slå tre priser op på stål kræver intet fra samtalen. En subagent kan gøre det, mens hovedagenten arbejder, og sende tre tal tilbage.

Videoen har et eksempel fra software, der viser det samme. En backend-agent beslutter halvvejs at gemme e-mailadresser med små bogstaver. Frontend-agenten hører det aldrig. Så bliver “Ray” og “ray” pludselig to forskellige brugere.

De tre situationer, hvor en subagent er rigtig

Anthropic er ikke imod subagenter. De skriver selv, at subagenter er gode til at tjekke arbejde, til parallelt arbejde og til at give dele af arbejdet forskellige rettigheder. De bruger dem i deres eget research-system. Her er de tre situationer, hvor det holder.

1. Friske øjne

En agent, der tjekker sit eget arbejde, har de samme blinde vinkler, som da den lavede det. Et tjek skal laves af en, der ikke har set ræsonnementet. Anthropic kalder det “black-box verification” og mønsteret “generator-verifier”: én laver, en anden tjekker.

Ray Amjad har skrevet det ind i sin skill task-lifecycle, der styrer en opgave fra kode til færdig ændring. Én agent bygger og får alle rettelser tilbage. Men den, der tjekker, er altid en ny agent: “a builder checking its own work proves nothing”. Den, der bygger, kan ikke bevise noget ved at tjekke sig selv. Jeg gør det samme i bb. Det har jeg beskrevet i mit AI-setup.

Det giver også en regel for, hvad tjekkeren skal have. Han skelner mellem to slags. Den, der læser ændringen igennem, får kun den oprindelige opgave og resultatet. Den, der tester, får endnu mindre: kun hvad den skal prøve af, som en bruger ville gøre.

2. Uafhængige opgaver, der kan køre samtidig

Når flere opgaver ikke har brug for hinanden, kan de køre på samme tid. Hver får sin egen kontekst, og konteksten kan smides væk, når svaret er afleveret. Research er det typiske eksempel: “Hvordan gør andre firmaer det her?” kræver intet fra din egen samtale.

3. Når én agent målbart bliver dårligere

Hvis én agent bliver målbart dårligere af alt det, den har i konteksten, så del. Det samme gælder, hvis den har svært ved at vælge det rigtige værktøj, eller hvis instruktionerne strider mod hinanden. Anthropic skriver, at valget af værktøj typisk bliver dårligere, når en agent har mere end 30 til 50 værktøjer at vælge imellem.

Faldet skal kunne måles. Det kræver en test at måle på, og den kommer vi til nedenfor.

Tommelfingerregel fra Claude Code

Claude Codes dokumentation siger det samme på hverdagssprog:

Det med tiden skyldes, at en subagent starter forfra. Den skal selv finde sin viden, og det tager tid.

Hvad det koster

Subagenter er ikke gratis. Hver subagent bruger sine egne tokens, mens den arbejder. Ofte skal den læse noget, hovedagenten allerede har læst. Og resuméerne, den sender tilbage, fylder også.

Filosoffen Toby Ord fra Oxford har regnet på store flokke af agenter, der arbejder på samme problem. Han finder, at fire agenter bruger cirka dobbelt så mange tokens som én agent for at nå samme niveau. Seksten agenter bruger cirka dobbelt så mange igen. Til gengæld går det hurtigere. Fra én til fire agenter halveres tiden cirka for den dobbelte pris. Han skriver: “The most important answer is speed.”

Subagenter, der kører samtidig, køber du tid med. Du køber ikke kvalitet med dem. Hvis tiden ikke er vigtig, er én agent det billigste valg.

To fejl, når agenter skriver kode

Anthropics artikel handler om kundeagenter. Men reglen gælder også, når agenter som Claude Code og Codex skriver kode. Anden halvdel af videoen handler om det, og der er to fejl, der går igen.

Fejl 1: Planen bliver hakket op i småopgaver. Man skriver en beskrivelse af, hvad der skal bygges. En agent deler den op i 5, 10 eller 20 småopgaver. Hver småopgave får en ny agent med en tom kontekst. Det ser pænt ud. Men hver agent starter fra nul. Den skal læse koden og lære det samme, som de andre allerede har lært. Og agent nummer syv ved ikke, hvad agent nummer tre fandt ud af.

Ingen beskrivelse er komplet. Én agent, der bygger det hele, opdager hullerne og retter sig selv undervejs. Rettelsen følger med resten af arbejdet. Jeg deler heller ikke opgaven op. Tit er grunden frygten for den grænse på 150.000 tokens, der er nævnt ovenfor.

Fejl 2: Småopgaverne kører samtidig. Når opgaven er hakket op, er det fristende at lade en chef-agent sætte dem i gang på én gang. Det burde gå hurtigere. Men opgaverne ser tit uafhængige ud uden at være det. De hænger sammen på måder, ingen kan se på forhånd. Og chef-agenten er ikke god til at vurdere det.

Toby Ord har et tal for det. Han låner det fra økonomer, der kalder det “stepping on toes”-parameteren. Det måler, hvor meget en opgave kan deles, før folk træder hinanden over tæerne. For kodeopgaver ligger den for AI-agenter omkring samme niveau som for et hold mennesker. Du ville heller ikke sætte 15 til 20 udviklere på én funktion.

Det, der virker i stedet

Del efter kontekst:

1. Én agent bygger det hele. Den får hele beskrivelsen, også en klar definition af, hvornår den er færdig.
2. En ny agent læser ændringen igennem. Den ser kun beskrivelsen og ændringen. Fejlene går tilbage til den samme agent, der byggede.
3. Nye agenter tester som en bruger. Hver måde, en bruger kan bruge funktionen på, bliver prøvet af for sig. De kan køre samtidig, fordi de er virkelig uafhængige. Det, der fejler, går tilbage til den, der byggede.

Der er stadig subagenter. Men kun til de opgaver, hvor det, hovedagenten ved, ville skade eller være ligegyldigt. Måske bliver selv det enklere. Næste generation af modeller kan måske tjekke sit eget arbejde i samme samtale.

Når der kommer en ny model, så slet noget af dit setup. Det, der hjalp en gammel model, kan holde en ny tilbage. Ray Amjad gør sine to skills til udvikling kortere for hver model. Anthropic har lavet en skill, /claude-api prompt-audit, der finder instruktioner skrevet til ældre modeller.

Sådan gør du i Claude Code

Claude Code har tre indbyggede subagenter. Explore søger i dine filer og må kun læse. Plan undersøger i plan mode og må også kun læse. general-purpose kan det hele. Claude bruger dem selv, når det giver mening. Du kan også bede om det: “Brug en subagent til at finde alle steder, hvor vi beregner moms.”

Hvis du tit beder om den samme slags hjælper med de samme instruktioner, så gør den til en fast subagent. Det er en Markdown-fil i mappen .claude/agents/ i projektet, eller i ~/.claude/agents/, hvis den skal gælde alle dine projekter. Her er en tjekker, der kun må læse:

---
name: tilbudstjek
description: Tjekker et færdigt tilbud mod kundens forespørgsel. Brug den, når et tilbud er skrevet, før det sendes.
tools: Read, Grep, Glob
model: sonnet
---

Du får kundens forespørgsel og det færdige tilbud. Du har ikke set,
hvordan tilbuddet blev lavet, og du skal ikke gætte på det.

Tjek:
1. Er alt, kunden bad om, med? Skriv det, der mangler.
2. Passer mængder, materialer og leveringstid til forespørgslen?
3. Står der noget i tilbuddet, kunden ikke bad om?

Svar med en kort liste. Ret ikke selv i tilbuddet.

Tre ting at lægge mærke til:

• Beskrivelsen bestemmer, hvornår den bliver brugt. Claude vælger subagent ud fra description. Skriv, hvornår den skal bruges, ikke hvad den er.
• Rettighederne er en del af designet. En tjekker skal ikke kunne rette. tools er en liste over det, den må.
• Den kan køre på en anden model. En simpel opgave kan køre på en mindre og billigere model. Du kan sætte en standard for alle subagenter med miljøvariablen CLAUDE_CODE_SUBAGENT_MODEL. Rækkefølgen er: den model, Claude vælger, når den starter subagenten, så model i filen, så miljøvariablen og til sidst den model, du selv bruger.

Pr. oktober 2026 kan en subagent selv starte subagenter, op til tre lag ned. Der kan køre 20 ad gangen. Begge grænser kan ændres. Det er ikke en anbefaling at bruge dem fuldt ud.

Giv subagenten en ordentlig opgave

En subagent ved kun det, du skriver til den. Den har ikke set jeres samtale. Den mest almindelige fejl er en opgave på én linje, hvor resten står i hovedagentens hoved. Når du selv beder Claude om at bruge en subagent, så bed den om at skrive opgaven sådan:

Brug en subagent til [opgaven]. Skriv opgaven til den, som om den er en ny kollega, der ikke har hørt noget af vores samtale:
1. Hvad målet er, og hvad svaret skal bruges til.
2. Hvad vi allerede har prøvet eller udelukket.
3. Hvilke filer eller kilder den skal se på, og hvilke den skal lade være.
4. Hvad den må ændre. Hvis den kun skal læse, så skriv det.
5. Hvordan svaret skal se ud, og hvor langt det må være.

Giv den ikke din egen konklusion med, hvis den skal tjekke noget. Den skal komme frem til sin egen.

En subagent, der får din hypotese med, vender som regel tilbage og bekræfter den.

Hvis I allerede har én agent pr. afdeling

Mange virksomheder har allerede bygget den chef-agent med specialister under. Anthropic anbefaler ikke at rive det hele ned på én gang. De anbefaler at samle det, én agent ad gangen, og måle undervejs.

1. Lav en lille test først. Ti rigtige opgaver med det svar, I forventer, er nok til at starte. Bedøm svaret ud fra en fast liste over, hvad et godt svar indeholder. Så længe I har en chef-agent, så mål også, om den vælger den rigtige specialist.
2. Slå de tætte par sammen. To agenter, der næsten altid bliver kaldt lige efter hinanden, arbejder i de samme data eller bygger på hinandens svar, er i virkeligheden én. Start med dem.
3. Kald resten som værktøjer. Lad hovedagenten kalde de tilbageværende agenter som værktøjer, så den selv holder samtalen. Det kræver ikke, at I skriver dem om. Kun en agent, der skal tale direkte med kunden, skal have samtalen overdraget.
4. Fold dem ind én ad gangen. En agents instruktion bliver til en skill. Dens adgang til systemer bliver til værktøjer. Kør testen igen.
5. Se på, hvilke opgaver der skifter. Ikke kun på det samlede tal. Behold kun subagenten, hvis den samlede agent bliver dårligere uden den.

Anthropic har selv et eksempel på, hvorfor punkt 5 er vigtigt. På en test-kundeservice slog de to agenter sammen. Det gik hurtigere. Men en proces, der havde virket, gik i stykker. Hovedagenten havde selv adgang til ordresystemet og svarede på leveringsdatoer uden at spørge fragt-specialisten. Fejlen viste sig kun i én ud af to kørsler. Kør derfor hver opgave mere end én gang.

Hvem ejer hvad bagefter

Når agenterne er foldet ind, ejer hvert team ikke længere en agent. Det ejer sine skills og sine værktøjer. Anthropic anbefaler én ansvarlig pr. team for de skills, der hører til. Et lille centralt team ejer instruktionen og kvaliteten af helheden. Det godkender nye skills, værktøjer og tests, før de kommer i brug.

Godkendelser hører til i værktøjet, ikke i en agent. Et værktøj, der kan refundere penge, tjekker selv, om brugeren må, og om beløbet skal godkendes af et menneske. Så kan én agent betjene brugere med forskellige rettigheder. Et værktøj som Executor kan det. Det samler alle værktøjer bag ét punkt og har regler for, hvad der må ske automatisk, hvad der skal godkendes, og hvad der er blokeret.

Sådan bruger jeg det selv

Jeg arbejder med agenter hver dag, og det meste af det, jeg har beskrevet i mit AI-setup, passer på reglen. Jeg bruger subagenter til to ting.

Et tjek med friske øjne. Den agent, der har bygget noget, er ikke den, der tjekker det. Som regel er det Codex fra OpenAI, der læser arbejdet igennem, fordi to modeller fra to leverandører ser forskellige fejl.

Det store og simple. Når jeg kommer hjem fra en rejse, har jeg taget billeder af kvitteringer undervejs. Det meste af en rejses billeder er ikke kvitteringer. En lille og billig model går dem alle igennem og skriver, hvilke filer der er kvitteringer, og hvad der står på dem. Den store model kigger kun på de billeder, den lille har fundet, og tjekker tallene. Konteksten fra de mange billeder bliver aldrig en del af hovedsamtalen.

Resten laver én agent i én samtale, fra plan til færdig ændring. Jeg deler ikke opgaven op i småopgaver. Den, der planlægger, er også den, der udfører. Det, jeg retter, bliver skrevet ind i en skill, så den næste samtale følger det fra start.

Kilder

• Diane Sarkis, Anthropic: Building agents: When to fold subagents into your main agent loop, 22. oktober 2026.
• Ray Amjad: Anthropic’s New Subagent Rules Will Change How You Build, YouTube, oktober 2026. Hans skills ligger på github.com/ray-amjad, herunder task-lifecycle.
• Claude Code Docs: Create custom subagents og Environment variables. Læst 26. oktober 2026.
• Melvin Conway, 1967. Forklaret i Nathania Gilson: What is Conway’s Law?, Atlassian, 28. december 2021.
• Rich Sutton: The Bitter Lesson, 13. marts 2019.
• Anthony Morris på X, 12. oktober 2026, og svaret fra Ado, begge Anthropic.
• Toby Ord: Swarm Scaling, 21. september 2026.
• Executor, åben kildekode.

Om eksemplerne

Eksemplet med maskinfabrikken og tilbuddet er konstrueret. Det ligner hverdagen i en dansk virksomhed, men handler ikke om en bestemt virksomhed. Eksemplerne med ordrer, fragt og retur og med e-mailadresserne er Anthropics og Ray Amjads. Kvitteringerne er fra min egen hverdag.