Hva er AGENTS.md, og hvordan skriver du din egen på 30 minutter?

Praktisk materiell om vibe coding og arbeid med agenter: Ailoot-dokumentasjon.

AGENTS.md i ett avsnitt#

Nedenfor ser vi på formatet med utgangspunkt i agents.md, dokumentasjonen for OpenAI Codex, JetBrains Junie, Cursor Rules Docs, endringsloggen for GitHub Copilot Coding Agent og Linux Foundations pressemelding om Agentic AI Foundation. Alle tall og funksjoner er oppdaterte per 30. mai 2026. Støtte for AGENTS.md i Claude Code beskrives i henhold til Anthropics dokumentasjon, med oppdatering fra 24. september 2026.

Hvis du ikke aner hva denne verktøyzooen på markedet er, eller hvorfor den trenger en felles fil, bør du først lese guiden «Hva skal du kode med i 2026: 8 AI-verktøy fra Claude Code til Antigravity». Denne artikkelen handler spesifikt om AGENTS.md-formatet og hvordan du skriver din egen på 30 minutter.

Hva er AGENTS.md, og hvor kommer det fra?#

Tidligere hadde hvert AI-verktøy sin egen fil med regler: Anthropic hadde CLAUDE.md, Cursor hadde .cursorrules, GitHub hadde .github/copilot-instructions.md, Aider hadde .aider.conf.yml, og JetBrains hadde .junie/guidelines.md. Hvis teamet ditt hadde tre ulike agenter, betydde det tre parallelle filer med samme innhold, som ville begynne å sprike i løpet av en uke.

OpenAI var først ute med å bli lei av dette. I august 2025 lanserte selskapet Codex CLI og samtidig agents.md som et åpent format. Fra nettstedet:

«Tenk på AGENTS.md som en README for agenter.»

(agents.md, oversatt fra engelsk)

Denne standardregelen gjelder klienter som faktisk implementerer denne søke- og prioritetsmåten. Kontroller den installerte versjonen; eksplisitt konfigurert innlasting kan bruke en annen filsti.

Hovedpoenget er at AGENTS.md supplerer README. README er skrevet for mennesker: «hva prosjektet er, hvordan du kjører det lokalt, og hvordan du kan bidra.» AGENTS.md er skrevet for agenten: nøyaktige skallkommandoer, kriterier for at noe er «ferdig» som kan verifiseres, og grenser som «ikke rør dette».

Fra nettstedet:

«AGENTS.md supplerer README: Den inneholder ekstra, noen ganger detaljert kontekst agenten trenger – byggetrinn, tester og konvensjoner som ville gjort README rotete, eller som menneskelige bidragsytere rett og slett ikke trenger.»

(agents.md, oversatt fra engelsk)

I september 2025 støttet GitHub Copilot Coding Agent formatet (endringslogg, 28.08.2025). I desember hadde Cursor, Junie, Gemini CLI, Aider og et dusin andre verktøy blitt med. Den 9. desember 2025 opprettet Linux Foundation Agentic AI Foundation (AAIF): De tre grunnleggerprosjektene var OpenAIs AGENTS.md, Anthropics MCP og Blocks goose. Grunnleggerne var AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft og OpenAI. Innen 24. februar 2026 hadde stiftelsen allerede 146 organisasjoner, blant andre Red Hat, ServiceNow, Akamai, Lenovo, JPMorgan Chase, Huawei, UiPath og Hitachi.

Fra da av sluttet AGENTS.md å være «enda en ting fra OpenAI» og ble en de facto-standard.

Hvilke AI-agenter leser AGENTS.md, og hvilke gjør det ikke?#

Tabell over støtte per 30. mai 2026; raden for Claude Code ble oppdatert 24. september 2026:

Anthropic var den siste av de store aktørene som ble med. I august 2025 ble issue #6235 med ønske om støtte for AGENTS.md opprettet i det offisielle repositoriet anthropics/claude-code.

Issue-en var åpen i nesten ett år og ble lukket 17. august 2026. Versjon 2.1.277 med støtte for AGENTS.md kom 18. september. Anthropics logikk er slik: CLAUDE.md har forrang, og AGENTS.md leses når det ikke finnes noen CLAUDE.md i arbeidsmappen eller i noen av foreldremappene. Ifølge dokumentasjonen fungerer det slik:

Haken er at en personlig CLAUDE.local.md også teller, og da slutter Claude Code å lese AGENTS.md. Du kan endre denne oppførselen i /config, under Project instructions – for eksempel slik at Claude Code leser begge filene samtidig. I versjoner eldre enn 2.1.277 blir AGENTS.md ikke oppdaget automatisk; linjen @AGENTS.md i CLAUDE.md er fortsatt en løsning.

Hvordan skiller AGENTS.md seg fra CLAUDE.md og .cursorrules?#

Sammenligning av de fire formatene per 30. mai 2026:

Hovedideen er at AGENTS.md kan samle felles regler når hver klient er riktig koblet til; personlige innstillinger du ikke committer, er fortsatt en egen oppgave. Claude Code har CLAUDE.local.md til dette, og Cursor har lokale .mdc-filer under brukeren. AGENTS.md alene gir deg ikke dette – du må enten kombinere det med andre filer eller bli enige i teamet om å skrive personlige regler i deler som er ignorert av git.

En annen viktig detalj er monorepoer. Codex og Cursor bruker regelen «den nærmeste AGENTS.md-filen vinner»:

«I et monorepo plasserer du en egen AGENTS.md i hver pakke. Agenter leser automatisk den nærmeste filen i katalogtreet, og den nærmeste vinner.»

(agents.md, oversatt fra engelsk)

agents.md opplyser at OpenAIs viktigste monorepo inneholder 88 AGENTS.md-filer for ulike underpakker. Hvis du jobber i et monorepo, bør du fordele reglene mellom nivåene: generelle regler i roten og spesifikke regler i undermapper.

Hva bør en god AGENTS.md inneholde?#

Nettstedet agents.md tilbyr et fleksibelt format – «hvilken som helst Markdown». Men 80% av gode filer der ute inneholder de samme åtte delene. Hovedregelen: hvert punkt bør være en nøyaktig kommando eller et konkret eksempel. En abstrakt idé som «skriv ren kode» blir ignorert av agenten.

1. Prosjektoversikt — 2–3 linjer. Hva prosjektet er, hvem det er for, og hva hovedmålet er. Ingen markedsføring. Eksempel: «Telegram-bot for onboarding til en betalt workshop. Stack: Next.js 14, Prisma, PostgreSQL. Utløses når en ny post legges til i purchases.»
2. Oppsettskommandoer — nøyaktige skallkommandoer for lokal kjøring. npm install, npm run dev, npm run build. Ikke skriv «slik pleier vi å gjøre det».
3. Kodestil / konvensjoner — konkrete regler med et eksempel, ikke «skriv ryddig». For eksempel: «TypeScript strict, enkle anførselstegn, ingen default exports, komponentnavn i PascalCase, hooks begynner med use.»
4. Tips til utviklingsmiljøet — hvor viktige ting ligger. Hvilke variabler som trengs i .env, hvor hemmeligheter lagres, hvilke porter som brukes, og hvordan man arbeider med den lokale databasen.
5. Testinstruksjoner — hvordan en bestemt test kjøres, og hva som regnes som «grønt». For eksempel: npm test -- --testPathPattern=user-auth; alle testene skal bestå.
6. PR- / commitretningslinjer — format for commitmeldinger, sjekkliste før PR (tester, linter, dokumentasjon) og hvem som godkjenner.
7. Sikkerhetshensyn — hva som aldri må skje. «Ikke commit .env. Hemmeligheter skal bare ligge i Vault. Ikke vis brukernes personopplysninger i logger.»
8. Grenser / Dette må du aldri gjøre — forbud med et alternativ. «Ikke bruk git push --force på main. Hvis du må rulle tilbake, bruk git revert eller git reset på en feature-branch.»

Bruk prinsippet «kommando i stedet for idé» i hver del. Agenten ignorerer «vær forsiktig med migreringer». Den følger «Kjør alembic check før alembic upgrade head. Hvis det rapporterer en feil, ikke bruk migreringen; spør meg.»

AGENTS.md-mal som er klar til bruk (kopier og tilpass)#

# AGENTS.md

## Prosjektoversikt

<project-name> - <én frase som beskriver formålet>.
Stack: <Next.js / Python / Go / ...>.
Hovedentiteter: <brukere, bestillinger, innlegg ...>.
Detaljer for mennesker står i README.md.

## Oppsettskommandoer

```bash
# første installasjon
npm install
cp .env.example .env  # fyll deretter inn manuelt; se listen nedenfor

# kjøring
npm run dev           # utviklingsserver på :3000
npm run build         # produksjonsbygg
npm run start         # kjør produksjonsbygget
```

## Utviklingsmiljø

- Node 20+ (via nvm: `nvm use 20`)
- PostgreSQL 16 lokalt på :5432 (`docker-compose up postgres`)
- Redis er valgfritt og trengs bare for køer (`docker-compose up redis`)
- `.env`: `DATABASE_URL`, `STRIPE_KEY`, `RESEND_API_KEY`, `JWT_SECRET`
- Les aldri hele `.env`-filen. Hvis du trenger én variabel: `grep "^VAR=" .env`

## Kodestil

- TypeScript strict mode
- Enkle anførselstegn, ingen semikolon (med mindre ESLint krever det)
- Imports: eksterne først, deretter interne via `@/`, så relative
- Komponenter i PascalCase; hooks begynner med `use`
- Ikke bruk `any` uten en uttrykkelig kommentar som forklarer «hvorfor den ikke kan types»

Eksempel på en god modul:

```ts
import { z } from 'zod'

const UserSchema = z.object({
  email: z.string().email(),
  name: z.string().min(2),
})

export function parseUser(raw: unknown) {
  return UserSchema.parse(raw)
}
```

## Testing

```bash
npm test                                # alle tester
npm test -- --testPathPattern=auth      # bare auth
npm test -- --watch                     # overvåkingsmodus
```

Alle tester må bestå (være grønne) før du committer. Hvis en test feiler, ikke commit; spør meg hva du skal gjøre.

## Retningslinjer for pull requests

- Commitformat: `<type>(<scope>): <description>` (`feat(auth): add magic-link`)
- Før PR: `npm run build && npm test && npm run lint`
- PR-beskrivelse = hva som endres, hvorfor og hvordan det skal testes
- Ikke godkjenn din egen PR – vent alltid på en menneskelig gjennomgang

## Sikkerhet

- Hemmeligheter bare i `.env` og Vault, aldri i kode
- Ikke logg personopplysninger (e-post, telefon, navn)
- Når du arbeider med produksjonsdatabasen, bruk bare skrivebeskyttede spørringer med mindre du har fått uttrykkelig tillatelse
- Ikke hardkod API-nøkler til eksterne tjenester (Stripe, OpenAI) i tester

## Dette må du aldri gjøre

- Ikke kjør `git push --force` til main. Hvis du må rulle tilbake, bruk `git revert` eller åpne en ny PR
- Ikke kjør databasemigreringer uten `alembic check` (eller tilsvarende i ORM-en din)
- Ikke bruk `npm install -g` eller `sudo` for prosjektavhengigheter
- Ikke legg til avhengigheter uten godkjenning (særlig tunge: webpack-plugins, ORM)

Malen er i gjennomsnitt 80–120 linjer. Hvis filen er over 150 linjer, er det et tegn på at du bør strukturere den på nytt: flytt noe til docs/, lenk til noe, eller komprimer det til én linje. I praksis fungerer filer på 100–150 linjer best; etter dette punktet begynner kvalitetsgevinstene å snu.

Hvilke 5 regler gjør AGENTS.md virkelig nyttig?#

1. Kommandoer i stedet for ideer. En agent forstår ikke «vær forsiktig med migreringer». Den følger alembic check før alembic upgrade head. Agenter arbeider med kommandoer og vilkår, ikke stemninger. Formuler alle viktige regler som «gjør X, ellers Y».

2. Forbud med et alternativ. Et bart «ikke bruk force push» blir stille ignorert av agenten etter to eller tre prompts. Koblingen «ikke gjør X; gjør Y i stedet» fungerer. Eksempel: «Ikke bruk git push --force på main; hvis du må rulle tilbake, bruk git revert eller åpne en ny PR.»

3. Nøyaktig én fasit. AGENTS.md i rotmappen er fasiten for hele prosjektet. Hvis du har et monorepo, bruker du nestede AGENTS.md-filer i undermappene etter regelen «den nærmeste vinner». Ingen parallelle filer med motstridende instruksjoner.

4. Kriterier for «ferdig» som kan verifiseres. «Testene må bestå» er ubrukelig. Et presist kriterium er: npm test returnerer avslutningskode 0 og skriver ikke FAIL til stdout. «Koden skal være ryddig» er også ubrukelig. Et presist kriterium er: npm run lint består uten advarsler. En agent forstår bare hva «ferdig» betyr når du beskriver vilkåret uttrykkelig.

5. En fil på under 150 linjer. Etter 150 linjer begynner måltallene å falle: agenten bruker mer kontekst på lesing og overser viktige regler. Hvis alt ikke får plass, flytt detaljene til docs/architecture.md og lenk til den fra AGENTS.md. La bare kommandoer og grenser stå i filen.

Hvilke 10 feil gjør AGENTS.md ubrukelig?#

1. Vage regler uten kommandoer. Agenten ignorerer «vær forsiktig med migreringer» – setningen er tom for den. Bare en konkret kommando med et vilkår fungerer: «Kjør alembic check før alembic upgrade head. Hvis det oppstår en feil, ikke bruk migreringen; spør meg.»

2. «Ren kode.» En ubrukelig frase. Bytt den ut med et konkret mønster: «Bruk funksjonelle komponenter med hooks. Eksempel: function LoginForm() { const [email, setEmail] = useState(''); ... }»

3. Ustrukturert prosa. Hvis AGENTS.md består av 300 linjer prosa uten overskrifter, bruker agenten 80K konteksttoken på irrelevante avsnitt og overser det viktige. Bruk H2/H3-overskrifter, korte avsnitt og punktlister.

4. En fil på over 150 linjer. Kvalitetsmålinger svekkes når du passerer denne grensen. Del den opp i en hovedfil med lenker til detaljer i docs/.

5. 30+ forbud uten alternativer. Hvis filen har en lang liste med «ikke gjør X, ikke gjør Y» uten å forklare «gjør Z i stedet», famler agenten i blinde.

6. Duplisering av README.md. Hvis du allerede har skrevet «slik installerer og kjører du» i README, ikke kopier det til AGENTS.md. Henvis i stedet til README i én linje, og beskriv i AGENTS.md det agenten trenger som menneskelige bidragsytere ikke trenger.

7. Hardkoding av hemmeligheter. AGENTS.md kan være offentlig (den ligger i git). Ikke legg inn ekte API-nøkler, token eller passord. Bare henvis til lagre for hemmeligheter: «Se Vault: secret/staging/db.»

8. Motstridende prioriteringer uten rangering. «Jobb raskt» + «oppretthold 90% testdekning» gjør agenten usikker på hva den skal velge. Ranger dem uttrykkelig: «Testdekning ≥80% først, deretter hastighet. Hvis de kommer i konflikt, prioriter testene.»

9. Utdatert dokumentasjon. En arkitekturbeskrivelse sier REST+polling, mens virkeligheten allerede bruker WebSockets. Agenten følger den utdaterte beskrivelsen og ødelegger arkitekturen. Regel: Oppdater AGENTS.md i samme PR som koden når arkitekturen endres.

10. Overdreven arkitektur for en enkel oppgave. Hvis noen ber om å endre to linjer i en konfigurasjon, skal ikke agenten måtte lese hele topologien for 14 mikrotjenester. Flytt den «dype» arkitekturen til docs/architecture.md; la bare «Hvis oppgaven gjelder arkitektur, les docs/architecture.md» stå i AGENTS.md.

GitHub Blogs studie av mer enn 2,500 AGENTS.md-repositorier oppgir hovedkonklusjonen:

«De fleste agentfiler mislykkes fordi de er for generelle. ‘Du er en hjelpsom kodeassistent’ fungerer ikke.»

(GitHub Blog, oversatt fra engelsk)

Hvordan holder du AGENTS.md og CLAUDE.md i samme repository?#

Det viktigste praktiske spørsmålet er hvordan man kan bruke begge filene uten å duplisere innhold. Det finnes tre scenarioer:

Scenario 1: Bare Claude Code. Behold CLAUDE.md og bruk alle funksjonene i Claude Code: ~/.claude/CLAUDE.md for instruksjoner på brukernivå, CLAUDE.md for prosjektet, CLAUDE.local.md for personlige overstyringer, @import for å inkludere andre filer og .claude/skills/ for spesialiserte skills. AGENTS.md trengs ikke.

Scenario 2: Flere kodeklienter. Ha felles regler i AGENTS.md, og koble til og kontroller hver klient separat. Gemini CLI støtter et konfigurert kontekstfilnavn; Aider kan laste inn en fil gjennom lesekonfigurasjonen. Dette er eksplisitte innlastingsmåter, ikke identisk automatisk oppdagelse.

Start en ny økt i et ufarlig test-repository. Legg inn en unik, ufarlig instruksjon, for eksempel «ta med markøren instructions-loaded i testsvaret», og kontroller klientens dokumenterte visning av innlastede filer eller logger i tillegg til svaret. Gjenta for hver klient og versjon du faktisk bruker. Modellens påstand om at filen er lest, er ikke et uavhengig bevis på innlasting; én vellykket kontroll beviser ikke støtte i alle andre verktøy.

Scenario 3: Et blandet team (Claude Code + andre). Dette er det vanligste oppsettet i 2026. Gjør AGENTS.md til hovedfilen. Hvis du ikke har regler som bare gjelder Claude Code, trenger du ikke opprette CLAUDE.md: Fra og med versjon 2.1.277 leser Claude Code AGENTS.md når det ikke finnes noen CLAUDE.md i prosjektet. Hvis du har slike regler, gjør du CLAUDE.md enten til en symlenke eller en kort wrapper med en @AGENTS.md-import.

Undersøk og sikkerhetskopier begge før endring. Finnes begge, slå felles regler uten konflikt sammen i AGENTS.md og behold Claude-spesifikke instruksjoner i CLAUDE.md med @AGENTS.md-import. Bevar eksisterende symlenker fremfor å erstatte dem.

For vanlig CLAUDE.md bare når AGENTS.md mangler nekter denne macOS/Linux-sjekken å overskrive eksisterende mål eller symlenke:

if [ -e AGENTS.md ] || [ -L AGENTS.md ]; then
  printf '%s\n' 'STOP: AGENTS.md exists; merge both files first.' >&2
elif [ -f CLAUDE.md ] && [ ! -L CLAUDE.md ]; then
  mv CLAUDE.md AGENTS.md && ln -s AGENTS.md CLAUDE.md
else
  printf '%s\n' 'STOP: inspect the existing CLAUDE.md path first.' >&2
fi

Etter vellykket omdøping er CLAUDE.md en symlenke til AGENTS.md. Alle agenter som leser AGENTS.md, ser det samme innholdet. Claude Code, som leser CLAUDE.md, ser det samme gjennom symlenken.

På Windows krever opprettelse av en symlenke Developer Mode (eller Admin), noe som kanskje ikke passer for hele teamet. Et alternativ er en kort CLAUDE.md som importerer AGENTS.md:

# CLAUDE.md

@AGENTS.md

## Spesifikt for Claude Code

- Bruk .claude/skills/ for spesialiserte prompts
- Når du arbeider med Skills, se .claude/skills/INDEX.md
- Bruk Plan Mode før større endringer (Shift+Tab)

I Claude Code henter denne syntaksen inn AGENTS.md med én linje og legger til egne Claude Code-regler nedenfor. Hvis du senere vil fjerne AGENTS.md, sletter du bare importen. Linjen fører ikke til at filen leses to ganger: Ifølge dokumentasjonen til Claude Code lastes ikke samme AGENTS.md inn to ganger, selv om Claude kan lese den på egen hånd.

Anbefalt struktur for et team med flere verktøy i 2026:

repo-root/
├── AGENTS.md                              # fasit, ≤150 linjer
├── CLAUDE.md                              # bare hvis det finnes regler spesifikt for Claude: symlenke → AGENTS.md ELLER @AGENTS.md + ekstra regler
├── .cursor/rules/                         # målrettede overstyringer bare for Cursor
├── .github/copilot-instructions.md        # «Se AGENTS.md», hvis den brukes
└── docs/architecture.md                   # detaljert arkitektur som AGENTS.md viser til

Mer om CLAUDE.md finner du i guiden «Slik konfigurerer du CLAUDE.md riktig». Hvis du vil lese mer om hvorfor en agent trenger en stor instruksjonsfil, kan du lese «Hva er kontekstutforming?».

Hva endret seg i 2026: Hvorfor la AAIF AGENTS.md under Linux Foundation?#

Den viktigste politiske historien innen AI-koding i mai 2026 var ikke lanseringen av enda en modell, men konsolideringen av formater. Tidligere hadde hver leverandør sin egen fil med regler. Det var praktisk for leverandørene, men tungvint for team som arbeidet med flere verktøy.

I en pressemelding datert 9. desember 2025 kunngjorde Linux Foundation Agentic AI Foundation som en paraply for tre formater:

• AGENTS.md fra OpenAI — et filformat med instruksjoner til agenter
• Model Context Protocol (MCP) fra Anthropic — en protokoll for å koble eksterne verktøy til agenter
• goose fra Block — et rammeverk for agenter med åpen kildekode

Fra Linux Foundations pressemelding:

«Når disse prosjektene samles under AAIF-paraplyen, kan de utvikles med den åpenheten og stabiliteten som bare åpen styring gir.»

(Pressemelding fra Linux Foundation, 9. desember 2025, oversatt fra engelsk)

Innen 24. februar 2026 var 146 organisasjoner medlemmer av AAIF (97 nye medlemmer på to måneder). Blant de nye Gold-medlemmene var Red Hat, ServiceNow, Akamai, Lenovo, JPMorgan Chase, Huawei, Hitachi, UiPath, American Express og Autodesk. Anthropic er Platinum-medlem og fremmer MCP. OpenAI er Platinum-medlem og fremmer AGENTS.md. Block er Platinum-medlem med goose.

Dette endrer posisjonen til AGENTS.md: fra et «OpenAI-format» til en bransjestandard. Våren 2026 sto Claude Code fortsatt på sidelinjen, men i september lærte det å lese AGENTS.md på egen hånd med versjon 2.1.277. CLAUDE.md er ikke borte, og har fortsatt forrang som standard hvis den finnes i prosjektet.

Et praktisk utgangspunkt er felles prosjektregler i AGENTS.md, supplert med importen, wrapperen eller den eksplisitte lesekonfigurasjonen hver klient trenger. For Claude Code kontrollerer du installert versjon og instruksjonsfilenes prioritet før du velger CLAUDE.md-import eller symlenke. Verifiser innlasting i hver klient; ingen dekningsprosent er fastslått her.

Hva skjer videre?#

AGENTS.md er den første byggeklossen i «hvordan bli enig med en agent slik at den arbeider forutsigbart». Deretter kommer den andre byggeklossen — en kunnskapsmappe for prosjektet, som inneholder forretningskontekst, målgruppe, produkter og priser. Den tredje byggeklossen er kontekstutforming, som samler alt: hvilke filer agenten ser på hvert trinn, hvordan tilstanden bevares mellom økter, og hvordan man bytter mellom ulike modeller.

Praktisk materiell: Ailoot-dokumentasjon.

Flere materialer og verktøy: Ailoot.