AI-agenternas byggmaterial — en konstruktionslära för beställare och arkitekter

Sammanfattning

En arkitekt som ritar hus behöver inte kunna gjuta betong. Men hon behöver veta skillnaden mellan bärande och icke-bärande väggar, varför isolering sitter där den sitter, och hur ventilation påverkar inomhusklimatet. Utan den kunskapen ritar hon hus som ser bra ut på papper men inte fungerar att bo i.

Vi som bygger och beställer AI-agenter befinner oss i en liknande situation. De flesta diskussioner handlar om modellen, alltså vilken AI som är "bäst". Men modellen är bara ett av sex byggmaterial som måste samverka. Det här är grundkursen i de andra fem.

Vad jag ser i kundprojekten

Under det senaste halvåret har jag byggt agentlösningar i sex parallella kundprojekt, allt från industriella värmekablar till fakturakontroll och produktionsdimensionering. De som förstår byggmaterialen fattar bättre beslut. De ställer rätt frågor, förstår varför vissa saker tar tid, och bidrar med det som gör agenten bra: sin domänkunskap.

De som inte förstår byggmaterialen fastnar i modellvalet. "Ska vi köra Claude eller GPT?" Det är som att fråga "Ska huset vara av betong eller trä?" utan att ha bestämt om det är ett garage eller ett sjukhus.

De sex byggmaterialen

1. Modellen — råmaterialet

Modellen är den språkförståelse och det resonerande som driver agenten. Claude, GPT och Gemini är alla varianter av samma grundmaterial: stora språkmodeller tränade på enorma mängder text.

Vad modellen kan utan hjälp:

• Resonera, sammanfatta, översätta, skriva kod
• Följa komplexa instruktioner
• Dra slutsatser utifrån given kontext

Vad modellen inte kan utan hjälp:

• Läsa dina filer
• Söka på webben
• Komma ihåg vad ni pratade om förra veckan
• Följa era specifika processer och regler

En modell utan hjälp gör rimliga men generiska val. Den väljer dyrare material "för säkerhets skull" istället för att veta att ert standardval är det billigare alternativet. Den rundar av på ett annat sätt än era tekniker. Den missar branschkonventioner som ingen skrivit ner.

I ett av mina projekt, en agent för industriella värmekablar, dokumenterade vi tio sådana fall. Agenten satte installationstemperaturen till −20°C (logiskt, det var omgivningstemperaturen). Teknikerna sätter alltid 5°C. Det är en branschkonvention som inte finns i någon specifikation. Modellen kunde inte veta det, oavsett hur "smart" den är.

2. Kontextfönstret — arbetsytan

Om modellen är råmaterialet så är kontextfönstret arbetsytan, ritbordet där allt måste rymmas.

Kontextfönstret är allt modellen "ser" vid ett givet tillfälle: dina instruktioner, din fråga, verktygens beskrivningar, relevanta filer, konversationshistorik. Allt det packas ihop till en enda textmassa som skickas till modellen. Storleken mäts i tokens (ungefär 0,75 ord per token).

Moderna modeller har stora fönster (Claude: 200 000 tokens, ungefär 150 000 ord). Men det betyder inte att du kan lasta in allt. Ju mer irrelevant information som fyller fönstret, desto svårare blir det för modellen att hitta det som spelar roll. Det är som ett ritbord fullt med papper: tekniskt sett ryms allt, men du hittar inget.

Här kommer prompt-enrichment in. När jag skriver "sammanfatta var vi står inför nästa kundmöte" (tolv ord) händer följande innan de når modellen:

1. Mina projektinstruktioner (CLAUDE.md) laddas automatiskt
2. Miljöinformation injiceras (git-status, datum, aktuell mapp)
3. Verktygsdefinitioner bifogas (vilka verktyg agenten har tillgång till)
4. Relevant konversationshistorik inkluderas

Mina 15 tokens blir 20 000–35 000 tokens, och kvaliteten på den automatiska kontextkonstruktionen avgör mer än modellvalet.

Vad en beställare bör fråga: "Hur byggs kontexten upp? Vad ser agenten egentligen när den får en fråga?"

3. Verktyg — händerna

En modell utan verktyg är som en arkitekt utan händer: den kan resonera om vad som borde göras, men inte göra det.

Verktyg ger agenten förmågan att agera i världen:

• Filsystem. Läsa, skriva, söka bland lokala filer
• Kodexekvering. Köra script, testa, beräkna
• Webbåtkomst. Söka information, hämta dokumentation
• API-integrationer. Ansluta till ert ordersystem, ert beräkningsprogram, er databas
• Browserautomation. Interagera med webbapplikationer

Den tekniska standarden som växer fram för verktygsintegration heter MCP, Model Context Protocol. Det är ett öppet protokoll som gör att agenter kan anslutas till externa system på ett standardiserat sätt. Tänk USB-C för AI-agenter: en kontakt, många enheter.

I mina kundprojekt ser jag konkret hur verktyg förändrar vad en agent kan göra:

• Fakturakontrollagenten har verktyg för att söka i orderdatabaser, slå upp leverantörskoder, och jämföra fakturarader mot beställningar
• Värmekabelagenten har verktyg för att köra termiska beräkningar, söka i produktregister, och generera projektfiler
• Produktionsdimensioneringsagenten har verktyg för att läsa operationslistor, slå i maskinregister, och beräkna cykeltider

Utan dessa verktyg är samma modell en chatbot som kan prata om fakturor, kablar eller produktion. Med verktygen är den en agent som kan arbeta med dem.

Vad en beställare bör fråga: "Vilka verktyg har agenten? Kan den nå de system den behöver — eller stannar den vid att ge råd?"

4. Minne — arkivet

Modellen har inget inbyggt minne mellan sessioner. När du stänger konversationen och öppnar en ny är allt borta. Den vet inte vad ni bestämde igår, vilka beslut som fattades förra veckan, eller vilken kabeltyp ni brukar välja.

Minne måste byggas utanför modellen:

Sessionsminne. Konversationshistoriken inom en session. Modellen kommer ihåg vad ni sagt, men bara så länge fönstret är öppet.

Projektminne. Persistent information som laddas in automatiskt. I mina projekt tar detta formen av context-repos: mappar med strukturerade filer som agenten läser vid behov.

kund-x-context/
├── CLAUDE.md              ← Vem är kunden, vad gäller
├── _kund/
│   └── verksamhet.md      ← Domän, produkter, organisation
├── ai/
│   ├── moten/             ← Mötesanteckningar (kronologiskt)
│   └── arbete/            ← Eval-resultat, beslut, analyser

Organisationsminne. Kunskap som gäller över projekt. Processbeskrivningar, standarder, produktkataloger.

Minnet är det byggmaterial som gör att en agent kan bli bättre över tid. Varje mötesanteckning, varje korrigering, varje dokumenterat beslut ökar agentens förmåga, utan att modellen ändras.

Vad en beställare bör fråga: "Var lagras agentens kunskap? Hur uppdateras den? Vad händer om vi lär den något nytt?"

5. Instruktioner — byggnormen

Boverkets byggregler talar om för arkitekten vad som måste gälla: brandkrav, tillgänglighet, energiprestanda. Utan byggnormer ritar arkitekten hus som ser fina ut men inte uppfyller kraven.

Instruktioner fyller samma funktion för agenten. De styr hur den arbetar:

System prompts. De övergripande reglerna. "Du är en fakturakontrollant. Svara alltid på svenska. Flagga avvikelser över 500 kr."

Skills. Domänspecifika instruktionspaket i markdown-format. Det är det enda byggmaterialet som domänexperter direkt kan bidra med, utan att röra kod.

En skill kan vara: "Så här beräknar vi effektbehov för frostskyddskablar" eller "Vår process för att bedöma operationslistor". Det är expertkunskap, formaliserad som text, som injiceras i agentens kontext vid behov.

I värmekabelprojektet mätte vi effekten av en skill med domänkunskap genom evals:

• Utan skill: 25% pass rate på blindtester
• Med skill: 84% pass rate
• Delta: +59 procentenheter

Samma modell. Samma harness. Samma verktyg. Det enda som ändrades var en markdown-fil med domänkunskap. Det är som att ge arkitekten tillgång till bygghandlingarna istället för att be henne gissa.

Guardrails är en specialform av instruktioner, de som sätter gränser. Vad agenten inte får göra. Vilka system den inte får nå. Vilka beslut som kräver mänsklig bekräftelse. I fakturakontrollprojektet hittade vi under säkerhetsgranskningar både SSRF-risker och auth-brister som krävde explicita guardrails.

Vad en beställare bör fråga: "Vilka instruktioner styr agenten? Vem kan uppdatera dem? Kan vi ändra reglerna utan att ändra koden?"

6. Orkestrering — arbetsledningen

Det sista byggmaterialet binder samman alla andra: orkestrering, alltså hur agentens arbete planeras, fördelas och koordineras.

I det enklaste fallet är orkestrering en loop: ta emot input → bygg kontext → anropa modellen → exekvera verktyg → returnera resultat. Det är vad en harness gör: skalet runt modellen som hanterar hela flödet.

Men i mer komplexa scenarier krävs mer:

Multi-agent-orkestrering. Flera agenter som samarbetar. En planerare som bryter ner uppgiften, specialister som utför delarna, en utvärderare som kontrollerar kvaliteten. I produktionsdimensioneringsprojektet har vi en orchestrator-agent som delegerar till specialister för operationslistor, maskinval och linjebalansering.

Kontextkompaktering. När konversationen växer och närmar sig fönstrets gräns aktiveras automatisk sammanfattning. Agenten fortsätter arbeta utan avbrott.

Felhantering och retry. När ett verktygsanrop misslyckas, en beräkning ger orimligt resultat, eller modellen hamnar i en loop.

Kostnadsoptimering. Prompt caching som reducerar kostnaden med upp till 90% efter första anropet, progressiv context disclosure som bara laddar det som behövs, och modellval per uppgift.

Orkestrering är det mest komplexa byggmaterialet. Anthropic har ett helt team som arbetar med sin harness, med 2–3 releaser per vecka.

Vad en beställare bör fråga: "Hur hanteras det när något går fel? Hur skalar lösningen? Bygger ni orkestreringslagret själva eller använder ni ett befintligt?"

Hur materialen samverkar

Låt mig visa hur alla sex byggmaterial arbetar tillsammans i ett verkligt anrop. Jag öppnar mitt context-repo för en kund och skriver:

"Sammanfatta var vi står inför nästa kundmöte"

Här är vad som händer:

1. Instruktioner laddas. CLAUDE.md beskriver projektet, konventioner, arbetssätt. Skills som matchat aktiveras, till exempel mötessammanfattning.

2. Kontextfönstret fylls. Prompt enrichment konstruerar en kontext på 20 000+ tokens: systemprompt, projektinstruktioner, verktygsdefinitioner, konversationshistorik.

3. Modellen tar emot kontexten och resonerar: "Jag behöver hitta de senaste mötesanteckningarna och eventuella eval-resultat."

4. Verktyg exekveras. Modellen söker i filsystemet, hittar moten/2026-03-05-agentvalidering.md, läser eval-resultaten i arbete/eval/, hittar de senaste besluten.

5. Minne konsulteras implicit: context-repots struktur är minnet. Mötesanteckningar, beslut, resultat som sparats efter varje session finns tillgängliga.

6. Orkestrering hanterar flödet: verktygsanrop schemaläggs, resultat aggregeras, om kontexten växer för mycket kompakteras den, och slutligen formateras svaret.

Resultatet: en sammanfattning med rätt detaljeringsnivå, baserad på faktiska projektdata, levererad på några sekunder. Sex byggmaterial samverkade för att få fram den.

Vad detta innebär för beställare

Du behöver inte bygga agenter för att förstå dem. Men du behöver kunna ställa rätt frågor. Här är en checklista:

Byggmaterial	Fråga till leverantören
Modell	Vilken modell används? Kan den bytas? Vad händer vid nästa modellgeneration?
Kontextfönster	Hur byggs kontexten? Vad ser agenten vid ett anrop? Hur hanteras begränsningen?
Verktyg	Vilka system kan agenten nå? Vad kan den göra — inte bara svara på?
Minne	Hur behålls kunskap mellan sessioner? Vem uppdaterar den?
Instruktioner	Vilka regler styr agenten? Kan vi ändra dem utan kodändring?
Orkestrering	Vad händer vid fel? Hur skalar lösningen? Vad kostar ett anrop?

Fråga också dig själv:

Var finns ert byggmaterial redan?

• Mötesanteckningar, processbeskrivningar, produktkataloger → potentiellt minne
• Beräkningsprogram, ordersystem, databaser → potentiella verktyg
• Expertkunskap som sitter i enskilda personers huvuden → potentiella skills/instruktioner

I alla mina kundprojekt har det svåraste varit att formalisera den kunskap som organisationen redan har men aldrig skrivit ner. Tekniken har aldrig varit flaskhalsen.

Källor och vidare läsning

Se källorna i artikelns metadata för originalreferenser.