# Så konfigurerar du CLAUDE.md 2026: Mall och 6 regler > En färdig CLAUDE.md-mall, 6 regler för att hålla filen levande och en analys av en fungerande fil från ett aktivt företag. Innehåller officiella citat från Anthropic. Source: https://ailoot.ai/blog/sv/claude-md-template/ Canonical: https://ailoot.ai/blog/sv/claude-md-template/ Language: sv Publisher: Ailoot (https://ailoot.ai/) Translation: guide-126 Revision: sha256-37cb0a3aa72a9e891fa1cb2759958b4bab82b36a566191b8d0f83d082efdfc15
Det viktigaste CLAUDE.md är en textfil i projektets rot som Claude Code läser i början av varje session. Utan den börjar agenten från noll varje gång: du lägger 5–10 minuter på att säga: ”Hej, jag arbetar med det här projektet, det här är min målgrupp och så här skriver jag.” En kompakt startfil siktar ofta på 100–200 rader; det är en granskningsriktlinje, inte ett tekniskt tak. Mallen innehåller 6 avsnitt (beskrivning, verktyg, struktur, filhänvisningar, regler och språk) och uppdateras varje gång Claude gör ett misstag. Den här artikeln innehåller en färdig mall, 6 regler, en analys av en fungerande fil från ett aktivt företag och en granskningschecklista med 12 punkter.
Material om vibe coding: verktyg, fallstudier, misstag. [Ailoot-guider](https://ailoot.ai/docs/).
[Ailoot-guider](https://ailoot.ai/docs/)
## Varför behöver du CLAUDE.md, och varför glömmer Claude projektet utan den?
Det viktigaste I Claude Code börjar varje ny chatt med tom kontext. CLAUDE.md är den enda fil som Claude automatiskt läser in i varje ny session. Utan den arbetar agenten som en praktikant på sin första dag: hen vet ingenting om ditt företag, din stil eller dina regler. Med den arbetar hen som en medarbetare på sitt andra år.
Du öppnar Claude Code på tisdag och förklarar: ”Jag arbetar med det här projektet, det här är verktygen, gör inte så här.” Det fungerar. På torsdag har den chatten redan avslutats, så du upprepar allt. På lördag igen; på måndag en gång till. Så ser det ut att arbeta med en agent utan CLAUDE.md: varje nytt fönster är en praktikant från noll som du måste berätta samma saker för om och om igen. Jag brukade lägga 5–10 minuter på att skriva den här uppvärmningen inför varje session. Promptarna blev långa eftersom jag var tvungen att föra över all kontext manuellt. Och resultatet var ändå generiskt: agenten kände inte till min målgrupp, min ekonomi eller mina principer.
Obs Det här är inte ett problem med modellens minne. Det handlar om arkitekturen. Claude Code börjar medvetet med ren kontext i varje session; annars skulle olika projekt på samma dator blandas ihop. CLAUDE.md är mekanismen som låter dig tala om för agenten vad den ska läsa in.
Med en levande CLAUDE.md försvinner uppvärmningen. Alla regler du brukade upprepa i varje chatt finns i en fil och visas automatiskt i början av varje session. Prompten blir kort: ”gör X”, i stället för ”jag arbetar med projekt Y, verktygen är Z, gör inte A eller B och kom förresten ihåg C också.” Då upphör de återkommande misstagen. Varje agentmisstag är en anledning att lägga till en rad i CLAUDE.md. Efter en månad har du en levande ”projektförfattning”, och Claude slutar gå i samma välbekanta fällor. Och så finns det ett tredje lager: agenten slutar skriva i ett vakuum. Via `CLAUDE.md` hänvisar jag Claude till mappar med kontext: var den ska leta efter information om målgruppen, prissättningen och varumärket. Utan den här hänvisningen skriver agenten ”lösningar av hög kvalitet” utan att känna till min ekonomi, så resultatet blir abstrakt, formelartat och ”precis som alla andras”. ## Vad är CLAUDE.md, och i vilken ordning läser Claude den?
Det viktigaste CLAUDE.md är en textfil i Markdown-format. Claude Code letar efter den på fyra ställen samtidigt: systemnivå, användarnivå, projektroten och i lokala anteckningar. Alla fyra läses in i kontexten i början av varje session. Filnamnet är skiftlägeskänsligt: använd alltid `CLAUDE.md` med versaler.
Anthropic beskriver CLAUDE.md så här i sin officiella dokumentation:
CLAUDE.md-filer är Markdown-filer som ger Claude bestående instruktioner för ditt projekt, ditt personliga arbetsflöde eller hela din organisation. Du skriver dem i vanlig text, och Claude läser dem i början av varje session.
— Anthropic, code.claude.com/docs/en/memory
De fyra platser där Claude Code letar efter CLAUDE.md, i stigande prioritetsordning: | Nivå | Plats | Syfte | |----|----|----| | **Organisation** | `/Library/Application Support/ClaudeCode/CLAUDE.md` på Mac, `/etc/claude-code/CLAUDE.md` på Linux | Regler som företagets administratör distribuerar till hela teamet via MDM. Du behöver inte detta som privatperson. | | **Användare** | `~/.claude/CLAUDE.md` | Personliga regler som gäller för alla dina projekt. ”Svara alltid på det språk användaren föredrar”, ”använd inte tankstreck.” | | **Projekt** | `./CLAUDE.md` i projektroten eller `./.claude/CLAUDE.md` | Regler för ett specifikt projekt: verktyg, mappstruktur, affärslogik. Den här filen checkas in i git. | | **Lokalt** | `./CLAUDE.local.md` | Dina personliga anteckningar för projektet som inte ska checkas in i git. Till exempel tillfälliga experiment eller personliga önskemål som teamet inte behöver känna till. | Alla fyra filer läses in i kontexten samtidigt. Om reglerna står i konflikt säger Anthropic direkt i dokumentationen att det är okänt vilken som får företräde; Claude kan välja en av dem på måfå. Därför är det enklare att samla allt kritiskt i projektets CLAUDE.md och undvika dubbletter.
Tips Filnamnet är strikt skiftlägeskänsligt. Använd versalerna `CLAUDE.md`, så läser Claude den. Den läser inte `claude.md` eller `Claude.md`. Detsamma gäller `CLAUDE.local.md`. Det här är ett typiskt misstag bland dem som konfigurerar Claude Code för första gången: de skapar en fil, skriver instruktionerna, undrar varför det inte fungerar och upptäcker sedan att filnamnet är skrivet med gemener.
Det finns en teknisk detalj som nästan ingen skriver om, men den förklarar mycket märkligt beteende.
Innehållet i CLAUDE.md skickas som ett användarmeddelande efter systemprompten, inte som en del av systemprompten. Claude läser det och försöker följa det, men strikt efterlevnad kan inte garanteras.
— Anthropic, code.claude.com/docs/en/memory
Med andra ord är CLAUDE.md inte en ”systemprompt” i strikt mening. Det är det första användarmeddelandet Claude ser. Reglerna är alltså starka rekommendationer, inte lagar. Om en regel måste upprätthållas använder du en testad hook för den händelse som omfattas och behörigheter eller miljöisolering för den bredare åtkomstgränsen. Att en hook körs automatiskt gör inte dess kontroller fullständiga. Jag förklarar gränsdragningen mellan `hooks` och `CLAUDE.md` nedan. ## Hur skriver du en minimal CLAUDE.md på 5 minuter (färdig mall)?
Det viktigaste Kopiera mallen, ersätt fälten inom hakparenteser och spara den i projektroten som `CLAUDE.md`. Det räcker för att hindra Claude från att börja från noll i varje session. Du kan bygga ut den efter hand med regeln: ”lägg till en rad efter varje agentmisstag.”
Nedan finns en mall som jag har testat i dussintals av mina projekt. Den håller filen kring 80–120 rader, inom Anthropics rekommendation att sikta på under 200 rader. Med den här mallen ger agenten de mest förnuftiga resultaten. ```markdown # [PROJECT NAME] - project navigation This document is the project map. Read it at the start of every session to understand where things are and how to work with them. ## What this project is **[NAME]** - [one sentence: what it is and who it’s for]. [1-2 sentences: what problem it solves and how]. Details are in `business/INDEX.md`. ## Reading order at the start of every session 1. `about-me/INDEX.md` - who I am and how I think 2. `business/INDEX.md` - what we do (product, audience, economics) 3. `CLAUDE.md` (this file) - repo rules, tools, navigation 4. Task area: the relevant file from `business/`, `plans/`, `mastery/` or the feature folder in the code Principle: layer 1 (about me) comes before layer 2 (business) for a reason. First, **who** is thinking, then **about what**. ## Repository structure [NAME]/ ├── CLAUDE.md ← this file, navigation ├── about-me/ ← digital projection of you (how you think, what you value) │ └── INDEX.md ├── business/ ← the business’s second brain │ ├── INDEX.md │ ├── audience/ ← customer profile │ ├── products/ ← products, prices │ ├── goals/ ← goals, metrics │ └── economics/ ← unit economics, revenue ├── plans/ ← technical plans (one plan = one feature) ├── retrospectives/ ← reflections after each session └── (project code) ### Where to find things | What you need | Where to look | |---|---| | Why we’re building the project, and for whom | `business/INDEX.md` | | Target customer, pains, desires | `business/audience/` | | Product, plans, prices | `business/products/` | | Goals and metrics | `business/goals/` | | Economics | `business/economics/` | | Technical plans | `plans/` | ## Tools [INSERT TOOLS - for example: Next.js 14, TypeScript, Tailwind CSS, Prisma + PostgreSQL]. ## Repo rules 1. Never hardcode dynamic data (prices, dates, figures) - get everything from files in `business/` and the LIVE marker. 2. Don’t publish without my explicit command. 3. Before `git push`, run `npm run build` and check that it builds without errors or warnings. 4. Add files by name with `git add`. Never use `git add .` or `git add -A`. 5. Don’t read `.env` in full. To check a variable, use `grep "^VAR=" .env`. ## Big features = a plan in `plans/` Any task lasting more than an hour must be written up as a plan in the `plans/` folder: 1. Filename: `YYYY-MM-DD-feature-name.md`. 2. Divide the plan into phases. Mark each phase `[ ]` or `[x]`. 3. At the end of the plan, add a summary: whether it was fully implemented and what remains. ## End-of-feature cycle After each feature is complete, go through these 5 steps: 1. Find errors → prove them with an example → fix them. 2. What was missed (edge cases, input validation, error handling). 3. Is this a real problem in our project? Check `business/` and `plans/`. 4. Take a fresh look: reread the diff as if you’re seeing it for the first time. 5. Security review. Especially: personal data and third-party materials. ## End-of-session reflection In `retrospectives/YYYY-MM-DD_short-name.md`, record: 1. What the task was. 2. How it was solved. 3. Whether it was solved - yes / no / partially. 4. What could have been done better. 5. What was learned about the user or project. ## Language Always respond in the user’s preferred language. Use hyphens only, not em dashes. ``` För att låta Claude fylla i mallen för ditt projekt automatiskt, ge den den här prompten. Den läser kontexten och fyller i fälten inom hakparenteser:
Prompt: Fyll i CLAUDE.md för mitt projekt ``` Create a CLAUDE.md file at the project root using this template: [INSERT THE ENTIRE TEMPLATE FROM ABOVE] Proceed as follows: Read about-me/INDEX.md and business/INDEX.md to understand the project context and me as the author. Fill in all the square-bracketed fields in the template based on what you find in those folders. If some information is missing, ask me clarifying questions one at a time, with 3-4 answer options. Aim to keep the resulting CLAUDE.md under 200 lines. If it is longer, review duplication and move detailed procedures to linked files. Preserve essential planning, reflection, and repo rules, then test them on representative tasks. Show me the final file and ask what should be revised. Always respond in the user’s preferred language. ```
Om du ännu inte har mapparna `about-me/` och `business/` är det okej. Claude ställer frågor och sätter ihop en minimal CLAUDE.md utifrån det som finns tillgängligt. Du kan skapa mapparna senare, när du vet vad du ska lägga i dem. ## Vilka 6 regler gör CLAUDE.md till ett levande dokument?
Det viktigaste De här 6 reglerna är en destillation av erfarenheter från dussintals projekt. De förvandlar CLAUDE.md från ”en fil vi skapade och glömde” till ett arbetsdokument som Claude rådfrågar i varje session.
### Regel 1. Håll den under 200 rader Anthropic uttrycker det kortfattat i sin officiella dokumentation:
Sikta på att hålla CLAUDE.md under 200 rader. Längre filer använder mer kontext och minskar följsamheten till instruktionerna.
— Anthropic, code.claude.com/docs/en/memory
En lång CLAUDE.md motverkar sitt eget syfte på två sätt. För det första förbrukar den tokens. En 800 rader lång instruktionsfil läses in i varje fönster och använder flera tusen tokens av din budget i varje session. Med en Pro-prenumeration och en daglig gräns minskar det märkbart antalet tillgängliga sessioner. För det andra börjar modellen ignorera reglerna. Dokumentationen rekommenderar att sikta på under 200 rader för att minska kontextanvändningen och förbättra följsamheten. Den fastställer ingen skarp felgräns vid rad 201. Granska relevans, motsägelser, inläst tokenmängd och faktiska uppgiftsresultat innan du avgör vad som ska flyttas ut.
Varning Om du redan har kommit upp i 300–500 rader behöver du inte få panik - dela upp innehållet i mappar. Lägg detaljerade regler om exempelvis designsystemet i `business/assets/brand-guidelines.md`. CLAUDE.md kan då hänvisa till den på en rad: ”När du arbetar med gränssnittet, läs `business/assets/brand-guidelines.md`.” Hänvisningsprincipen: CLAUDE.md är en innehållsförteckning, inte en bok.
### Regel 2. Avsluta varje session med en reflektion Skriv i CLAUDE.md: ”I slutet av varje session dokumenterar du vad du gjorde och lärde dig i `retrospectives/YYYY-MM-DD_*.md`.” När du har lagt till den här raden börjar Claude själv avsluta varje session med en reflektion; du behöver inte be om det. Varför reflektera: - Två veckor senare kan du öppna en gammal tillbakablick och komma ihåg varför du valde den vägen. - När du återvänder till projektet en månad senare har du en färdig översikt över de senaste besluten. - Om du arbetar i ett team kan en kollega läsa tillbakablicken och förstå nuläget på 2 minuter, utan ett samtal. ### Regel 3. Checka in efter varje avslutad uppgift I min CLAUDE.md står det: ”Efter varje avslutad uppgift skapar du en git-commit med ett beskrivande meddelande.” Claude börjar då på egen hand dela upp arbetet i atomära commits. Det ger dig två saker. För det första kan du återställa en enskild åtgärd om något går sönder, inte ”allt jag gjorde i dag”. För det andra blir commit-historiken en arbetslogg som visar vad som ändrades och i vilken ordning. ### Regel 4. Läs alltid mappen `business/` Vid alla uppgifter som rör kunder, produkter eller text bör agenten först öppna `business/INDEX.md` och den relevanta filen därifrån. I min CLAUDE.md står det uttryckligen: ”När du arbetar med gränssnittet eller text, kontrollera först `business/audience/avatar.md` och `business/assets/brand-guidelines.md`.” Utan den här regeln skriver Claude text i ”den allmänna stilen hos en kvalitetswebbplats”. Med regeln skriver den i din stil, för din kund och utan dina förbjudna ord. ### Regel 5. Lägg till en regel efter varje agentmisstag Det här är huvudregeln som håller CLAUDE.md levande. Exempel från min egen CLAUDE.md som lades till efter specifika misstag: - ”Checka aldrig in någon annans WIP-filer med `git add .` - lägg till filer var för sig.” - ”Kontrollera `git log origin/main..main --oneline` före push till `main` - om resultatet inte är tomt, gör ingen push.” - ”Hitta inte på värden - hämta dem från `.env` eller koden. Särskilt URL:er, användarnamn och tokens.” Var och en av de här raderna är spåret efter en specifik incident. En gång checkade en agent in en partners ofärdiga gren. En gång inkluderade jag någon annans lokala commits som inte hade pushats. En gång hittade en agent på en URL som inte finns. Varje misstag blir en regel, och samma självförvållade skada upprepas inte. ### Regel 6. Lägg säkerheten i `.claude/settings.json`, inte i CLAUDE.md I CLAUDE.md kan du skriva ”rör inte `.env`”, men det är en begäran; Claude kan bryta mot den eftersom CLAUDE.md läses in som ett användarmeddelande, inte som en lag. För kritisk säkerhet använder du `.claude/settings.json`, där du kan blockera vissa kommandon helt. Blockeringslistan jag lägger till i varje nytt projekt: - `rm -rf` (rekursiv radering av filer). - Fullständig läsning av `.env` (`Read .env`). - `export` och `curl` i samma kommando (ett mönster för att läcka hemligheter externt). - `git push --force` utan uttryckligt godkännande.
Varning Skillnaden är enkel: en regel i CLAUDE.md är ett råd som agenten kan bryta mot. En matchande deny-regel blockerar den åtgärd som omfattas i det tillämpliga behörighetsflödet. Den bevisar inte skydd mot varje likvärdigt kommando, ett annat verktyg eller ett annat behörighetsläge. Ha kritiska säkerhetsregler i `settings.json` och allt annat i CLAUDE.md.
Hitta fler guider på [Ailoot](https://ailoot.ai/docs/).
[Ailoot-guider](https://ailoot.ai/docs/)
## Hur är CLAUDE.md strukturerad i ett aktivt företag (anatomin hos en fil med 280 rader)?
Det viktigaste Jag går igenom strukturen i en CLAUDE.md-fil som används av en aktiv onlinetjänst. Filen är cirka 280 rader lång och har 11 avsnitt. Jag visar vad varje avsnitt innehåller och varför. Jag publicerar inte själva texten; den innehåller operativa detaljer. Men ramverket kan tillämpas på vilket företag som helst.
De flesta exempel på CLAUDE.md på nätet är tekniska mallar för utvecklare: ”Använd TypeScript”, ”Skriv inte tester som är längre än 50 rader.” För en entreprenör är en sådan CLAUDE.md värdelös - den täcker inte affärsdelen. Nedan finns strukturen i min fungerande CLAUDE.md. Jag har tagit bort de specifika reglerna och sökvägarna eftersom de speglar min interna verksamhet. Men avsnittens struktur och logik kan tillämpas på vilket projekt som helst: lägg in dina egna omständigheter, så får du en fungerande fil. **1. Kort projektbeskrivning (15 rader).** Vad vi gör, vilken målgruppen är och vilka produkter vi erbjuder. Inte en sammanfattning av marknadswebbplatsen, utan en sammanfattning för agenten så att den förstår ”vart vi är på väg”. **2. Om mig (10 rader).** En hänvisning till mappen `about-me/` - en digital representation av hur jag tänker. Ton, värderingar, principer och förbjudna ord. När Claude skriver text ”som jag” läser den först den här mappen så att rösten stämmer. **3. Arkivstruktur (20 rader).** Ett träd med kommentarer: var koden finns, var affärskontexten finns och var planerna och tillbakablickarna finns. Utan den här kartan letar Claude blint efter filer varje gång. **4. Tabellen ”Var du hittar saker” (25 rader).** Hänvisningar från ”fråga → fil”. För en fastighetsbyrå kan det till exempel stå ”behöver du lånevillkoren → `business/products/mortgage.md`” eller ”behöver du tonen för inlägg → `business/assets/voice.md`”. Byt ut exemplen mot dina egna filer. Den här tabellen är kärnan i CLAUDE.md. Utan den gissar agenten vilken fil som innehåller svaret. Med den går den direkt till källan. **5. Viktiga projektprinciper (40 rader, 10–15 punkter).** Det här avsnittet byggs upp långsamt och kräver mest arbete. Varje punkt är spåret efter ett specifikt misstag. För en nätbutik kan reglerna till exempel vara ”hårdkoda aldrig priser och leveranstider”, ”publicera inte en produkt utan en uttrycklig uppmaning” och ”kontrollera stilen mot varumärkets ordlista innan du publicerar en produktbeskrivning”. Det här avsnittet är ”projektförfattningen”. **6. Operativ planering (20 rader).** En utlösartabell som kopplar ”användarens fras → åtgärd”. Till exempel: ”När jag säger ’planera veckan’, öppna `ops/monthly.md` och skapa veckans fil.” Det gör Claude till en operativ assistent som förstår sammanhanget för kommandon. **7. Verktyg (5 rader).** Tekniker. Kortfattat och utan utfyllnad. **8. Publicering (15 rader).** En stegvis process för att publicera ändringar till produktion: vilka kommandon som ska köras, i vilken ordning och vad som ska kontrolleras. Jag brukade förklara det varje gång. Nu vet Claude. **9–12. Säkerhet (35 rader).** Fyra separata underavsnitt: regler för hantering av `.env`, åtkomst till produktionsdatabasen, säkra kommandon för demonstrationer (skärminspelningar, strömmar, skärmbilder, så att tokens inte råkar exponeras) och regler för att rotera hemligheter. **13. Mappen `plans/` (10 rader).** Planstandarden: filnamn, fasstruktur och vad som ska finnas i sammanfattningsblocket. **14. Mappen `retrospectives/` (5 rader).** Reflektionsstandarden: mall, filnamn och vad den ska innehålla. **15. Data från live-databasen (15 rader).** En regel för att markera ”färska data”: när en fil anger att siffror måste vara aktuella hämtar agenten dem från källan i stället för att använda gamla värden. Det minskar risken för att Claude använder gårdagens siffror. **16. Språk (3 rader).** ”Svara alltid på det språk användaren föredrar. Använd endast bindestreck, inte tankstreck.” Cirka 280 rader totalt. Det överstiger målet för korthet men gör inte filen ogiltig. I detta exempel förblev den användbar; beslutet att behålla den bör bygga på uppmätt kontextanvändning och kontroller med representativa uppgifter. Tabeller är inte automatiskt billigare i tokens än löptext.
Tips Strukturen som jag har utvecklat under ett års arbete är ingen dogm. Ramverket är: beskrivning (1–2 avsnitt), struktur och hänvisningar (2–3 avsnitt), regler/principer (1 stort avsnitt), operativa rutiner (2–3 avsnitt specifika för ditt företag) och små detaljer (språk, kontakter). Fyll det med detaljer som gäller ditt företag. Huvudregeln: varje avsnitt ska besvara frågan ”Skulle Claude göra ett misstag utan detta?” Om inte, ta bort det.
## Vad gör kommandot `/init`, och varför räcker det inte?
Det viktigaste Kommandot `/init` i Claude Code skapar automatiskt en grundläggande CLAUDE.md genom att skanna projektet och lista verktyg och byggkommandon. Det är en bra början, men utan affärskontext och principer blir filen teknisk och generisk. Använd `/init` som första steg och bygg sedan vidare manuellt.
Anthropic beskriver kommandot så här i dokumentationen:
Kör /init för att automatiskt skapa en inledande CLAUDE.md. Claude analyserar koden och skapar en fil med byggkommandon, testinstruktioner och identifierade projektkonventioner.
— Anthropic, code.claude.com/docs/en/memory
Det här gör `/init` bra: - Identifierar verktygen utifrån `package.json`, `Cargo.toml` och `pyproject.toml`. - Listar bygg- och testkommandon. - Upptäcker konventioner i befintliga filer (`.eslintrc`, `.prettierrc`). - Upptäcker befintliga Cursor-regler (`.cursorrules`, `.cursor/rules/`) och Copilot-regler och tar med relevanta delar. Den läser in `AGENTS.md` i läget `CLAUDE_CODE_NEW_INIT=1`. Det här gör `/init` inte: - Den vet inte vem kunden är. - Den inkluderar inte dina förbjudna ord för texter. - Den lägger inte till regler om agentmisstag (eftersom sådana ännu inte har inträffat). - Den skapar ingen tabell över ”var du hittar saker” för företagets struktur. Därför är rätt arbetsflöde: 1. ### Kör /init i Claude Code Du får en inledande CLAUDE.md på 30–50 rader med verktyg och kommandon. Det är den tekniska grunden. 2. ### Lägg mallen från den här artikeln ovanpå Använd avsnittet ”En minimal CLAUDE.md på 5 minuter”. Lägg till avsnitt om navigering, hänvisningar och principer. 3. ### Fyll i fälten inom hakparenteser Ge Claude prompten ”läs mitt projekt och fyll i mallen”. Om mapparna `business/` och `about-me/` inte finns ännu kommer Claude att ställa följdfrågor. 4. ### Gör ett stresstest Be Claude: ”Läs min CLAUDE.md och hitta 10 oklarheter som kan få dig, som agent, att missförstå.” Du får en lista med förbättringar. 5. ### Använd sedan filen i vardagen Lägg till en rad efter varje agentmisstag. Efter en månad har du en levande CLAUDE.md som är anpassad till ditt företag. Prompt för steg fyra:
Prompt: Stresstesta CLAUDE.md ``` I have a CLAUDE.md. Tomorrow I’ll be building a feature based on it. Your task is to stress-test it. Find 10 reasons we could potentially fail: where CLAUDE.md is ambiguous and you, as an agent, might misunderstand it where there are gaps that would force you to make things up where rules contradict one another where I overestimate how much can be done in one day where I underestimate things (this is even worse) Don’t hold back. Criticize it harshly. I want to find these issues now, not in production. At the end, give me a list of specific changes: what to change and how, so these problems don’t happen. ```
## CLAUDE.md jämfört med AGENTS.md och MEMORY.md: vem läser vad 2026?
Det viktigaste Tre liknande filer blandas ofta ihop. CLAUDE.md innehåller projektspecifika regler som du skriver själv och som Claude Code läser i varje session. AGENTS.md är en universell standard för andra agenter (Codex, Cursor, Copilot), och sedan september 2026 läser Claude Code den också om projektet saknar CLAUDE.md. MEMORY.md innehåller automatiska anteckningar som Claude skriver till sig själv om dina vanor. Alla tre kan finnas samtidigt utan att stå i konflikt.
| Fil | Vem skriver den | Vem läser den | När läses den in | |----|----|----|----| | **CLAUDE.md** | Du, manuellt | Claude Code (inbyggt) | I början av varje session | | **AGENTS.md** | Du, manuellt | Codex CLI, Cursor, GitHub Copilot CLI, Gemini CLI och, sedan version 2.1.277, Claude Code om projektet saknar CLAUDE.md | I början av varje session | | **MEMORY.md** | Claude Code självt | Claude Code (inbyggt) | I början av varje session, de första 200 raderna (eller 25 KB, beroende på vilket som är minst) | Huvudfrågan som förvirrar nybörjare är: **läser Claude Code `AGENTS.md`?** Före september 2026 var svaret ”nej”: Anthropics dokumentation rekommenderade att skapa en CLAUDE.md som importerar AGENTS.md. Sedan version 2.1.277 (släppt 18 september 2026) läser Claude Code AGENTS.md själv, men bara om det inte finns någon CLAUDE.md, `.claude/CLAUDE.md` eller `CLAUDE.local.md` i arbetsmappen eller ovanför den.

Claude Code kan läsa AGENTS.md som projektinstruktioner, så ett repo som redan är konfigurerat för andra agenter fungerar utan CLAUDE.md, import eller konfiguration.

— Anthropic, https://code.claude.com/docs/en/memory#agents-md
Om projektet har en CLAUDE.md läser Claude Code som standard bara den och hoppar över AGENTS.md. Du kan ändra detta i `/config`, under Project instructions: till exempel gör inställningen `claude-md-and-agents-md` att båda filerna läses. Ett annat sätt fungerar i alla versioner: lägg till en import i CLAUDE.md: ```markdown @AGENTS.md ## Claude Code Additional rules for Claude Code that other agents don’t need. ``` Syntaxen `@filename` importerar en annan fil. Claude läser in den i kontexten tillsammans med CLAUDE.md. Importen gör inte att filen läses två gånger, även om Claude Code kan läsa AGENTS.md på egen hand. **När du behöver AGENTS.md.** Om du arbetar parallellt med Claude Code och Codex CLI, Cursor eller Copilot skapar du en AGENTS.md som enda källa till sanningen, lägger till `@AGENTS.md` i CLAUDE.md och kompletterar med eventuella regler som bara gäller Claude. Om det inte finns sådana regler behöver du inte skapa CLAUDE.md: sedan version 2.1.277 läser Claude Code AGENTS.md på egen hand. Om du bara arbetar i Claude Code behöver du inte AGENTS.md; använd enbart CLAUDE.md. För alla alternativ steg för steg, se [guiden om att använda AGENTS.md och CLAUDE.md i samma projekt](https://ailoot.ai/blog/sv/agents-md-claude-md-one-instruction-file/). **Vad är MEMORY.md?** Sedan en nylig uppdatering sparar Claude Code automatiskt anteckningar om dig i `~/.claude/projects//memory/MEMORY.md`. De kan handla om samtalsvanor (”användaren föredrar korta svar”), återkommande uttryck (”förbjöd emojis i kod”) och beteenden (”arbetar på macOS, använder zsh”). Det är ett separat minnessystem, inte CLAUDE.md. Du skriver inte den för hand; Claude gör det utifrån era samtal. Om MEMORY.md innehåller något som borde bli en regel flyttar du det till CLAUDE.md. Om den innehåller något onödigt eller felaktigt kan du ta bort det manuellt; det är en textfil.
Obs Skriv `/memory` i Claude Code för att se vad som läses in i början av en session. Kommandot visar innehållet i CLAUDE.md, MEMORY.md och andra inlästa filer. Det är användbart när Claude beter sig märkligt: öppna `/memory` och leta efter regeln som kan ha orsakat det.
## Vilken storlek är användbar för CLAUDE.md, och hur granskar du en lång fil?
Det viktigaste Längre instruktionsfiler använder mer kontext och kan göra relevanta regler svårare att följa, särskilt om de innehåller upprepningar eller motsägelser. Anthropic rekommenderar att sikta på under 200 rader. Rekommendationen är inget tekniskt tak och ingen allmän förutsägelse om hur många regler agenten kommer att följa.
I varje Claude Code-fönster läses flera lager in i kontexten: Anthropics systemprompt (uppskattningsvis tiotusentals tokens), din CLAUDE.md, filer som importerats med `@`, MEMORY.md, den aktuella chatthistoriken och innehållet i filer som Claude öppnar. Allt detta måste rymmas i modellens kontext (200K tokens för Sonnet, 1M för Opus). Ju större CLAUDE.md blir, desto mindre utrymme finns för det aktuella arbetet. En fil på 1 000 rader är ungefär 8 000 tokens och upprepas i varje session. Med en Pro-prenumeration (enligt min erfarenhet omkring 10–12 ”tunga” promptar per dag) minskar det din kapacitet med en fjärdedel. Kostnaden är bara en av flera frågor. Följsamheten kan försämras när instruktionerna är långa, irrelevanta eller motstridiga; det finns inget allmängiltigt antal instruktioner som följs pålitligt. Testa några representativa uppgifter som prövar de kritiska reglerna, dokumentera misslyckanden och jämför beteendet efter en fokuserad redigering.
Uppsvällda CLAUDE.md-filer får Claude att ignorera dina faktiska instruktioner.
— Anthropic, code.claude.com/docs/en/best-practices
Här är alltså tumregeln för storleken: - **80–120 rader** - ett praktiskt startintervall för en kort projektkarta, inte en garanterad följsamhetspoäng. - **150–200 rader** - en användbar påminnelse om att granska relevansen och flytta detaljerade procedurer till länkade filer. - **200–300 rader** - granska tokenmängd, upprepningar och uppgiftsresultat; företagsexemplet med 280 rader ovan kan fortfarande fungera bra. - **400+ rader** - ett starkt skäl för en fokuserad granskning, inte bevis på att filen är oanvändbar. Behåll nödvändiga begränsningar och flytta detaljer först efter att du kontrollerat att länkarna och reglerna fortfarande fungerar. Radantalet ensamt kan inte fastställa framgång eller misslyckande. Upprepa samma representativa uppgifter efter en redigering och kontrollera viktiga regler, i stället för att tilldela en påhittad procentsats för följsamheten.
Varning Om din CLAUDE.md har blivit för stor ska du inte strukturera om den för hand. Ge Claude den här prompten: ”Läs CLAUDE.md och betygsätt varje rad utifrån frågan ’Om den här raden togs bort, skulle agenten då göra ett misstag?’ Returnera en lista över rader som kan tas bort utan nackdel, med en motivering.” Den tar bort sådant som objektivt inte fungerar.
Anthropic ger ett direkt test i sin dokumentation:
Fråga för varje rad: ’Om jag tar bort den här, kommer Claude att börja göra misstag?’ Om inte, ta bort den.
— Anthropic, code.claude.com/docs/en/best-practices
Tillämpa detta på varje rad. Om svaret är ”det skulle fortfarande bli rätt”, ta bort raden. CLAUDE.md är inte platsen för dokumentation, beslutshistorik eller filosofi. Den ska bara innehålla regler som agenten behöver för att undvika misstag. ## Vilka 7 misstag gör CLAUDE.md oanvändbar?
Det viktigaste Det här är sju vanliga misstag som jag regelbundet ser i andras CLAUDE.md-filer. Vart och ett är ett skäl att städa upp filen metodiskt. De flesta är varianter av samma problem: att försöka göra CLAUDE.md till ett universellt ”projektdokument” i stället för att behålla den som ett arbetsverktyg för agenten.
### Misstag 1. ”Var en bra ingenjör” Det vanligaste misstaget. Folk skriver allmänna önskemål i CLAUDE.md: ”skriv ren kod”, ”använd bästa praxis”, ”tänk som en senior ingenjör”. De här orden betyder ingenting. Claude skriver redan ”ren kod” i allmän mening. Sådana rader tar upp kontext utan att påverka några beslut. Ersätt ”skriv ren kod” med ”använd indrag på 2 blanksteg”, ”använd inte `any` i TypeScript” eller ”funktioner får inte vara längre än 30 rader”. Konkret och verifierbart. ### Misstag 2. Att upprepa sådant Claude redan vet Beskrivningar av vanliga språkkonventioner (”i JavaScript är funktioner förstklassiga objekt”, ”TypeScript har statisk typning”). Förklaringar av hur npm, git eller docker fungerar. Claude lärde sig allt det här under träningen. Att upprepa det i CLAUDE.md tillför ingenting; det tar bara utrymme från din kontext. ### Misstag 3. Långa steg-för-steg-instruktioner i CLAUDE.md Långa instruktioner om ”hur man driftsätter projektet”, ”hur man skriver en databasmigrering” eller ”hur man sätter upp en ny komponent”. Dussintals stegvisa rader. Det här är inte platsen för långa steg-för-steg-instruktioner. Den är till för regler på en rad. Lägg långa instruktioner i `skills/` (en separat Claude Code-mekanism som läses in vid behov) eller i `docs/`. I CLAUDE.md använder du en hänvisning på en rad: ”När du skapar en ny migrering, öppna `docs/migrations.md`.” ### Misstag 4. Regler som redan kontrolleras av en automatisk kodanalysator ”Använd semikolon”, ”lämna inte oanvända importer”, ”använd inte `var`”. ESLint, Prettier och Biome fångar allt detta - de är linterverktyg (automatiska verktyg för kodkontroll). En linter är deterministisk: den körs, hittar ett fel och rättar till det. En CLAUDE.md-regel är sannolikhetsbaserad; agenten kan glömma den. Det finns ingen anledning att upprepa regeln - det är enklare att konfigurera linterverktyget. ### Misstag 5. Hemligheter i CLAUDE.md Jag har sett lösenord till testkonton, API-token för sandlådor och länkar till autentiserade administrationspaneler. Allt låg i en fil som checkats in i git och lästs in i Anthropics modellkontext. Aldrig. Hemligheter hör hemma i `.env`, som finns i `.gitignore`. Som mest bör CLAUDE.md säga: ”Läs inte `.env` i sin helhet; använd `grep` för en specifik variabel.” ### Misstag 6. En dumpningsplats på 500+ rader som inte rensats på sex månader CLAUDE.md har vuxit, dubblar hälften av `docs/`, motsäger sig själv på flera ställen och ingen minns vad som står i den. Agenten börjar ignorera det mesta. Teamet klagar över att ”Claude inte följer instruktionerna” och lägger till fler regler, vilket gör saken värre. Tecken på att en CLAUDE.md är eftersatt: mer än 300 rader, upprepade regler i olika avsnitt, föråldrade länkar till filer som inte längre finns och ”historiska” anteckningar som ”2024 bestämde vi oss för att göra så här, men sedan ändrade vi oss”. Lösningen: be Claude granska den varannan vecka med Anthropics test: ”Om den här raden togs bort, skulle agenten då göra ett misstag?” Ta bort allt där svaret är ”nej”. ### Misstag 7. CLAUDE.md skapas och glöms bort Det här är motsatsen till det föregående misstaget. Filen sattes ihop en gång för två månader sedan och har inte rörts sedan dess. Under tiden har verktygen ändrats, nya mappar lagts till och nya agentmisstag dykt upp. CLAUDE.md känner inte till något av detta eftersom ingen har uppdaterat den. Ett tydligt tecken: du upprepar samma instruktion i varje session. ”Gör inte X”, ”rör inte Y”, ”kom ihåg Z”. Om du har upprepat den mer än två gånger hör regeln hemma i CLAUDE.md, inte i ditt huvud.
[Ailoot-guider](https://ailoot.ai/docs/)
## Hur gör du CLAUDE.md självlärande med regeln ”uppdatera i slutet av sessionen”?
Det viktigaste Den viktigaste tekniken som förvandlade min CLAUDE.md från ett dokument till ett levande verktyg var att lägga till en regel i filen: ”I slutet av varje session ska du kontrollera om du har lärt dig något nytt om användaren eller hur du ska arbeta med hen som inte står i CLAUDE.md, och lägga till en rad.” Inom två månader började filen samla på sig individuella regler utan någon separat process.
Min CLAUDE.md har ett kort avsnitt: ```markdown ## Self-learning At the end of every session, check: - Have I learned anything new about the user or how to work with them? - Did I break any rule that should now be recorded? If so, create or update a file in `about-me/feedback/` in this format: Rule (one-line rule) → Why (why it was added) → How to apply (when it applies). I don’t write the rules by hand - I say, “not like that, because this is how,” and you put it into a file. ``` När det här avsnittet lades till i CLAUDE.md började Claude i slutet av varje session fråga: ”Var det något nytt som är värt att dokumentera?” Om det fanns något föreslog den ett utkast till regel, jag förtydligade den och en fil skapades. Efter två månaders arbete på det här sättet har jag mer än två dussin filer i `about-me/feedback/` - regler som lärts in från specifika misstag. Varje fil är en sida i formatet Regel → Varför → Hur. Mappen blev ett ”andra minne” som registrerar mina personliga önskemål och tabun. Varje misstag upprepas inte eftersom det blir en regel, och reglerna byggs på och förstärker varandra. Efter sex månader känner Claude mitt projekt bättre än jag själv minns det efter en månads paus. ## Hur lägger du till juridiska regler, marknadsföring och verksamhet i CLAUDE.md?
Det viktigaste Tekniska riktlinjer i CLAUDE.md är bara halva bilden. Den andra halvan är affärsregler: förbjudna formuleringar av juridiska skäl, formatering av extern text för varumärket och operativa vanor för hur teamet arbetar från vecka till vecka. När CLAUDE.md täcker båda sidor blir Claude inte bara programmerare, utan också redaktör och operativ assistent.
För de flesta team är CLAUDE.md ett rent tekniskt dokument: verktyg, byggkommandon och kodningskonventioner. Det är användbart, men utgör bara en tredjedel av värdet. När en entreprenör underhåller CLAUDE.md är det klokt att lägga till affärsavsnitt. Tre är viktigast: ### Juridiska regler (för reglerade marknader) Om du publicerar text i en reglerad bransch (finans, medicin, läkemedelsreklam, barnprodukter) har förbjudna ord juridisk betydelse och hör hemma i CLAUDE.md som uttryckliga regler. Inte i någons huvud, inte på en skärmbild från en redaktör - i en fil som agenten ser i varje session. Exempel för ett fintechprojekt utan banklicens: Redaktionell anmärkning: Följande visar formatet för en intern regel för ett specifikt projekt. Det är inte ett generellt tillstånd att använda de angivna termerna: om ett påstående är godtagbart beror på tillämplig lag och företagets status. > 🚨 KRITISKT - finansiella formuleringar är förbjudna. I material riktat till kunder får du inte använda: ”insättning”, ”garanterad avkastning” eller ”investeringsprodukt”. Använd: ”sparkonto”, ”förväntad avkastning” och ”produkt med rörlig ränta”. Skälet är de juridiska krav som gäller för marknadsföring av finansiella tjänster i det här projektet. Det här blocket i CLAUDE.md gör något enkelt: varje gång du ber Claude skriva kundriktad text kontrollerar agenten den mot förbuden. Utan regeln dyker förbjudna ord upp i var tredje kampanj. Med den glömmer du att de ens finns. Samma arbetssätt fungerar för: - Medicinska projekt (inga påståenden om att något ”behandlar” eller ”botar”). - Läkemedelsreklam (inga påståenden om ”mest effektiv”; obligatoriska varningar). - Alla reglerade branscher med egna reklamregler. ### Marknadsföringsstil och textformat Om du publicerar text regelbundet (sociala medier, nyhetsbrev, webbplatser) är det värt att dokumentera formatet i ett stycke i CLAUDE.md. Här är ett exempel på vad en influencer eller byrå som driver en meddelandekanal kan skriva: > När du skriver inlägg för kanalen ska du läsa `style/posts.md`. Använd kanalens tillåtna formateringsmarkörer och undvik ”farliga” specialtecken. Avsluta med en CTA som har en UTM-tagg enligt den här konventionen: `utm_source=&utm_medium=&utm_campaign=`. Claude brukade skriva inlägg i ”den allmänna stilen hos en marknadsföringswebbplats”. Nu följer den ditt format, använder dina UTM-taggar och avslöjar inte att texten är AI-skriven. ### Operativa vanor Utlösartabeller. När du säger en viss fras vet agenten vilka filer den ska öppna och vilka åtgärder den ska utföra. Här är ett exempel för ett team som planerar veckovis: > ”Planera veckan” → öppna `ops/monthly.md`, skapa `YYYY-WNN.md` i samma mapp och flytta uppgifterna från `ops/backlog.md` till rätt dagar. ”Vad finns i backloggen?” → läs `ops/backlog.md` och visa den som en lista. ”Avsluta veckan” → fyll i avsnittet ”Veckosammanfattning” i den aktuella veckans fil. Med sådana tabeller går Claude från att vara en ”hjälpreda som skriver kod” till en ”operatör” som känner till företagets rutiner. Varje måndag säger jag ”låt oss planera veckan”, och Claude öppnar rätt filer, läser månadsmålen och föreslår hur uppgifterna kan delas upp.
Obs Affärsspecifika riktlinjer i CLAUDE.md är meningsfulla när du redan har en `business/`-mapp med faktisk kontext om målgruppen, produkterna och målen. Om du inte har en sådan skapar du `business/` först och lägger sedan till hänvisningar till den i CLAUDE.md. Annars får du instruktioner som pekar mot ingenting.
## Hur kontrollerar du din CLAUDE.md mot en checklista med 12 punkter på 5 minuter?
Det viktigaste Gå igenom din nuvarande CLAUDE.md med den här checklistan. Varje punkt tar 30 sekunder. Om du svarar ”nej” fem gånger eller fler behöver filen städas upp.
1. **Storlek.** Är filen kortfattad, med cirka 200 rader som granskningsmål i stället för en godkänd/underkänd-gräns? 2. **Namn.** Är den exakt `CLAUDE.md` med versaler, inte `claude.md`? 3. **Plats.** Finns den i projektroten eller i `./.claude/CLAUDE.md`? 4. **Projektbeskrivning.** Framgår det av de första 5 raderna vad projektet är och vem det är till för? 5. **Verktyg.** Är teknikerna uttryckligen listade och utan utfyllnad? 6. **Struktur.** Finns det ett arkivdiagram med förklaringar? 7. **Hänvisningar.** Finns det en tabell med ”fråga → fil” som visar var man hittar svar? 8. **Principer.** Finns det ett avsnitt med regler som börjar med ”aldrig” och ”alltid”? 9. **Specificitet.** Går varje regel att verifiera? (”Använd 2 blanksteg”, inte ”skriv vackert”.) 10. **Självuppdatering.** Finns det en regel om att ”kontrollera vad som ska läggas till i slutet av sessionen”? 11. **Reflektion.** Finns det en regel om att ”dokumentera sessionssammanfattningen i `retrospectives/`”? 12. **Säkerhet.** Finns kritiska förbud (`.env`, `rm -rf`) även i `.claude/settings.json`? Om du har fler än fem ”nej”-svar öppnar du Claude och ger den den här prompten:
Prompt: Granska CLAUDE.md mot checklistan ``` Read my CLAUDE.md and compare it with the checklist below. For each item, say: yes / no / partly, and what specifically to fix. Checklist: Compact enough for the task; review around 200 lines without treating it as a hard ceiling Project description in the first 5 lines Tools listed explicitly Repository structure diagram included “Question → file” table included Principles section with rules included Every rule is specific and verifiable “Update at the end of the session” rule included “Reflect at the end of the session” rule included Critical prohibitions included in .claude/settings.json No duplicates of the same rule in different sections No dangling links to files that no longer exist After the audit, give me a list of specific changes that will make the file living. ```
## Vad ska du använda efter CLAUDE.md: Plan Mode, Skills eller sub-agenter?
Det viktigaste CLAUDE.md är grunden. När den fungerar finns nästa nivåer tillgängliga: Plan Mode (låt Claude planera först och agera sedan), Skills (flytta kunskap som sällan används från CLAUDE.md till separata filer) och sub-agenter (isolerade uppgifter i egna kontexter).
CLAUDE.md är grunden. När den fungerar kan du lägga till tre Claude Code-mekanismer som förstärker varandra. **Plan Mode.** Ett läge där Claude först skapar en ändringsplan, väntar på ditt godkännande och först därefter börjar arbeta. Aktivera det med Shift+Tab eller kommandot `/plan`. Det hanterar den största smärtpunkten med vibe coding: ”Jag bad Claude fixa en sak, och den skrev om halva projektet.” Det händer inte i Plan Mode - du ser planen innan agenten rör några filer. **Skills.** Separata `.md`-filer i mappen `.claude/skills/` som innehåller kunskap för en viss typ av uppgift. Till exempel innehåller en skill för ”hur man skriver en databasmigrering” en specifik procedur, en mall och exempel. Den kunskapen finns inte i CLAUDE.md eftersom den är för omfattande. Men när Claude får en uppgift som ”skriv en migrering” läser den in relevant skill och följer den. **Sub-agenter.** När en uppgift kräver mycket kontext (till exempel granskning av en stor funktion) kan Claude starta en separat sub-agent i en egen, ren kontext. Sub-agenten utför arbetet och returnerar resultatet utan att belasta huvudchattens kontext. Alla tre mekanismerna använder CLAUDE.md som ingångspunkt: de läser den i början av arbetet för att förstå projektets kontext. Därför fungerar de här funktionerna också dåligt utan en levande CLAUDE.md. Först grunden, sedan lagren ovanpå. **Nästa steg.** Skapa en `CLAUDE.md` i projektroten, kopiera mallen från början av artikeln och fyll i fälten inom hakparenteser med hjälp av hjälpprompten. Använd sedan filen i vardagen: gör varje agentmisstag till en ny rad. Efter två eller tre veckor slutar CLAUDE.md vara ”ett dokument vi skrev och glömde” och blir något som Claude faktiskt rådfrågar i varje session. Om du vill bygga ett komplett ramverk kring `CLAUDE.md` - en `business/`-mapp för en Second Brain, en `about-me/`-mapp för en digital representation av dig, grundläggande skills och ett konfigurerat Plan Mode - använder du stegen och exemplen i den här artikeln. [Ailoot-guider](https://ailoot.ai/docs/).
### Källor - [Anthropic - Claude Code Memory](https://code.claude.com/docs/en/memory) - officiell dokumentation om CLAUDE.md, MEMORY.md och inläsningshierarkin - [Anthropic - Best Practices](https://code.claude.com/docs/en/best-practices) - regler för att skriva en effektiv CLAUDE.md och testet ”skulle Claude göra misstag om detta togs bort?” - [Anthropic Support - Give Claude Context](https://support.claude.com/en/articles/14553240-give-claude-context-claude-md-and-better-prompts) - supportguide till kontextarbete - [Ailoot-guider](https://ailoot.ai/docs/) - dokumentation.
[Fortsätt med Ailoot](https://ailoot.ai/).
[Fortsätt med Ailoot](https://ailoot.ai/)
[Fortsätt med Ailoot](https://ailoot.ai/)
## Frågor om den här guiden: Så konfigurerar du CLAUDE.md 2026: Mall och 6 regler ### Blir en CLAUDE.md-fil ogiltig efter 200 rader? Nej. Rekommendationen är ett mål för korthet, inte ett tak för tolkningen eller en garanterad brytpunkt. Granska upprepningar, motsägelser och inläst kontext och testa sedan viktiga regler på representativa uppgifter. Artikelns exempel med 280 rader behöver samma bedömning. ### Vad bör flyttas ut ur en växande CLAUDE.md? Flytta detaljerade procedurer, långt referensmaterial och beslutshistorik till relevanta dokument eller skills. Behåll korta projektfakta, nödvändiga begränsningar och tydliga länkar i ingångsfilen. Upprepa verkliga uppgifter efter redigeringen för att kontrollera att vägval och kritiska regler fungerar. ## Ailoot · Företaget och dess projektportfölj Ailoot bygger på etablerad driftserfarenhet, en stor kundbas, stabil service och löpande KPI-kontroll. Företaget och dess projektportfölj: miljontals kunder; månatlig försäljning för miljarder. Ailoot använder denna driftserfarenhet för API-åtkomst till AI-funktioner i kundernas produkter, agenter, applikationer och automatiseringar.