# Magnus Rødseth

My personal corner of the Internet. I am Magnus Rødseth, a developer deeply committed to crafting high-quality, performant solutions.

Hey! I'm Magnus Rødseth, an AI platform developer who spends an unreasonable amount of time teaching AI agents to do his job, only to spend even more time reviewing their work.

I work as a full-stack developer at [Capra Consulting](https://capraconsulting.no/), currently building **Hei, huset!**, a conversational AI assistant for [Gjensidige](https://www.gjensidige.no/), and driving the team's AI-first way of working. On the side, I build and sell [Eden Stack](https://eden-stack.com), a production-ready monorepo for AI-native SaaS. I'm an Anthropic Claude Certified Architect and a Board Member at [Junior Consulting](https://www.juniorconsulting.no/), where I was previously Partner and Head of Technology.

I hold a Master's degree in Computer Science from the [Norwegian University of Science and Technology (NTNU)](https://www.ntnu.edu/), specializing in Software Systems.

Outside of programming, I enjoy hanging out with friends, exercising, and watching movies. You can find a [list of all my projects here](https://www.magnusrodseth.com/projects), or check out my [presentations](https://presentations.magnusrodseth.com).

## Site map

- [Projects](/projects)
- [Blog](/blog)
- [Daily drivers](/daily-drivers)
- [About](/about)
- [Contact](/contact)
- [Privacy](/privacy)
- [API & agent docs](/docs)
- [Presentations](https://presentations.magnusrodseth.com)

## Contact

- GitHub: https://github.com/magnusrodseth
- LinkedIn: https://www.linkedin.com/in/magnus-rodseth/
- Email: magnus.rodseth@gmail.com


---

# Projects

A collection of professional work and open source projects.

## Professional experience

### Full-stack Developer at Capra Consulting

December 2025 – present · Oslo, Norway

As a consultant from Capra, building 'Hei, huset!' for Gjensidige Forsikring: a conversational AI assistant that lets homeowners 'talk to their house' and get personalized maintenance plans and advice from their own property documents and structured housing data. I am also a technical driver for the team's AI-first way of working and a contributor to Gjensidige's group-wide AI strategy.

Tech: Python, FastAPI, LangGraph, LangChain, Azure OpenAI, RAG, pgvector, PostgreSQL, React, TypeScript, MLflow, Kubernetes (AKS), ArgoCD

### Founder & Sole Developer at Eden Stack

February 2026 – present · Remote

Eden Stack is a production-ready, full-stack monorepo template for AI-native SaaS that I build and sell to indie hackers and small teams. It offers end-to-end type safety from database to native mobile, designed so AI agents can extend the codebase safely and predictably.

Tech: TypeScript, Bun, TanStack Start, Elysia, Expo, Neon PostgreSQL, Drizzle ORM, Better Auth, Stripe, Inngest, Vercel AI SDK, Exa, MCP

### Board Member at Junior Consulting

July 2025 – present · Trondheim, Norway

Contributing to the strategic direction and governance of Junior Consulting. Overseeing company performance, ensuring financial health, and upholding standards.

### Full-stack Developer at Capra Consulting

May 2025 – November 2025 · Oslo, Norway

As a consultant from Capra Consulting, worked largely independently on the continued development of the Tiny Studios SaaS platform, an all-in-one management solution for dance studios.

Tech: Next.js, TypeScript, React, Supabase, PostgreSQL, Tailwind CSS, Zustand, SWR, Playwright

### Developer at Reodor Studios

October 2025 – November 2025 · Remote

Built a reusable, production-grade agentic AI chatbot template ('Create Reodor App') that cut new AI projects' time from concept to production from days to hours, plus an n8n and MCP platform that democratized advanced workflow automation for non-technical staff.

Tech: Next.js, React, TypeScript, Vercel AI SDK, Claude, Supabase, PostgreSQL, n8n, MCP, Railway

### Creator at Open source

July 2025 – July 2025 · Remote

An MCP server, published as an npm package, that gives AI assistants direct access to shadcn/ui documentation, dependencies, and implementation examples. It removes manual doc copying and reduces the risk of using outdated components.

Tech: MCP, TypeScript, Node.js, JSON-RPC, Zod, npm

### Partner and Head of Technology at Junior Consulting

August 2024 – July 2025 · Trondheim, Norway

Oversaw staffing of 53 active tech, strategy, and design consultants on external projects. Managed internal IT systems and led platform development with focus on efficiency and automation.

Tech: TypeScript, React, Next.js, Node.js, PostgreSQL, OpenAI API

### Summer Intern at Noora

June 2024 – August 2024 · Oslo, Norway

Developed an MVP of a SaaS platform enabling landowners and corporations to capture carbon at scale.

Tech: Next.js, tRPC, Tailwind CSS, shadcn/ui, PostgreSQL, PostGIS, Python, Azure

### Project Lead & Developer at Junior Consulting

February 2022 – August 2024 · Trondheim, Norway

Led multiple teams building web and mobile applications for clients, including Effisense (sensor-based waste management), Lista (a home-renovation mobile app), NTVA, and Flytlandskap. Gained experience in project management, team coordination, and customer relationships.

Tech: TypeScript, React, React Native, Next.js, tRPC, PostgreSQL

### Tech Lead & Software Architect at Privatmegleren AI

April 2023 – February 2024 · Oslo, Norway

Technical lead for a SaaS platform that uses generative AI to automate the creation of complete property sales documents for one of Norway's leading real-estate brokerages, freeing brokers for higher-value work.

Tech: Next.js, TypeScript, OpenAI, GPT, RAG, Embeddings, Edge Runtime, Supabase, PostgreSQL, Stripe

### Summer Intern at Bekk

June 2023 – August 2023 · Oslo, Norway

Developed a real-time map of train coordinates for Vy, Norway's largest public transport company.

Tech: React, TypeScript, Chakra UI, Leaflet, Mapbox, AWS, AWS AppConfig, Kotlin, Micronaut

### Creator at Open source

March 2023 – April 2023 · Remote

A command-line tool written in Rust that makes it easy to feed local code context to large language models. Released as open source with 6,000+ downloads (as of April 2025) and published to crates.io.

Tech: Rust, CLI, Cargo, clap, Open source

### Full-stack Developer at Systemsoft Holding AS

December 2022 – December 2022 · Asker, Norway

Overhauled the official SystemSoft website from scratch with serverless architecture.

Tech: Next.js, TypeScript, Tailwind CSS, Vercel

### Summer Intern at Capra Consulting

June 2022 – August 2022 · Oslo, Norway

Developed an advisor tool for Dr. Dropin with 2000+ monthly users for recommending consultations and therapists based on questionnaire answers.

Tech: Next.js, TypeScript, Tailwind CSS, Google Analytics, Sanity, Docker

Open source projects are listed at https://github.com/magnusrodseth and on the [projects page](https://www.magnusrodseth.com/projects).


---

# Daily drivers

The hardware, software, and tools I use day to day.

I work on an Apple Silicon MacBook Pro running macOS. The whole setup is [stow-managed dotfiles](https://github.com/magnusrodseth/dotfiles), so I can reproduce it on a new machine with a single script.

## Editor

- **[Claude Code](https://www.anthropic.com/claude-code)** is where I spend most of my time these days.
- **[Zed](https://zed.dev/)** is my fallback editor when I want to drive things by hand.

## Terminal

- **[Ghostty](https://ghostty.org/)** as the terminal emulator.
- **[Zsh](https://www.zsh.org/)** with [zinit](https://github.com/zdharma-continuum/zinit) for plugins and [oh-my-posh](https://ohmyposh.dev/) for the prompt.
- **[tmux](https://github.com/tmux/tmux)** with the Catppuccin theme for sessions.

## Command line

- **[lazygit](https://github.com/jesseduffield/lazygit)** and **[lazydocker](https://github.com/jesseduffield/lazydocker)** for Git and Docker
- **[delta](https://github.com/dandavison/delta)** as the Git pager

## Apps & services

- **[Raycast](https://www.raycast.com/)** as launcher and window manager
- **[Obsidian](https://obsidian.md/)** as a second brain
- **[1Password](https://1password.com/)** for secrets
- **[Figma](https://www.figma.com/)** for design
- **[Vercel](https://vercel.com/)** for hosting (including this site)

## AI tooling

- **[Claude Code](https://www.anthropic.com/claude-code)** and **[Claude](https://claude.ai/)** for most agentic work

Want the full picture? Everything lives in my [dotfiles repo](https://github.com/magnusrodseth/dotfiles).


---

# Slik gjør du repoet klart for agenter du ikke sitter foran

Published: August 2026
Originally published at Capra Consulting: https://capraconsulting.no/vare-historier/slik-gjor-du-repoet-klart-for-agenter-du-ikke-sitter-foran

> Alt som bare finnes i hjemmekatalogen din er usynlig for en fersk virtuell maskin. Her er porteringen av et agentoppsett til skyen, og det som brøt underveis.

![Editorial illustration, wide 16:9 banner composition. A calm, flat composition split by a clean vertical seam down the middle: on the left a warm, cluttered desk surface rendered flat and matte, on the right an empty, cool, pristine surface. Nothing crosses the seam. In the open space on the right, elegant serif text in warm cream reads exactly, with correct Norwegian spelling including the letters ø and å: "Hva krysser grensen?" set in a classic editorial serif typeface, with generous letter spacing. No other text anywhere in the image. Mood: quiet, technical, editorial. Palette: deep slate blue, warm sand, muted teal, warm cream. Flat editorial illustration with subtle paper grain texture, restrained detail and no fine line work, generous negative space. Magazine opinion-section feel like The Economist or New York Times opinion illustrations.](https://www.magnusrodseth.com/blog/agenter-du-ikke-sitter-foran/banner.webp)
_Alt som bare finnes i hjemmekatalogen din er usynlig for en fersk virtuell maskin. Kilde: OpenAI gpt-image-2._

## Innledning

Jeg har en second brain, altså et personlig kunnskapssystem der notater, prosjekter og referanser bor på ett sted, som et ytre minne jeg kan søke i og bygge videre på. Mitt er et Obsidian-vault som driftes nesten utelukkende gjennom Claude Code på en Mac.

I det siste har jeg forsøkt å bruke det samme vaultet fra Claude Code i Claudes mobilapp, men opplevde at utvikleropplevelsen og kapabilitetene jeg har på desktopen ikke fulgte med over på mobilen. Derfor ville jeg finne ut hva som faktisk skal til for å kjøre de samme arbeidsflytene fra telefonen, der agenten kjører i en virtuell Linux-maskin hos Anthropic i stedet for på maskinen min.

![Diagram som viser en dag med vaultet i tre faser: ved desktopen (dokumentere et møte, notere fra en samtale, fange noe nytt fra jobb, legge inn en todo to uker fram i tid), på farten (åpne Claude Code i mobilappen, starte en cloud-sesjon på vaultet, fortsette arbeidet der det slapp), og tilbake ved desktopen (bli minnet på åpne cloud-PR-er, merge dem inn i main, Obsidian viser oppdaterte notater)](https://www.magnusrodseth.com/blog/agenter-du-ikke-sitter-foran/en-dag-med-vaultet.webp)
_Samme vault, tre steder i løpet av en dag. Telefonen tar over midt i arbeidet, og desktopen henter det hjem etterpå. Kilde: Egen illustrasjon._

Først en forutsetning denne bloggserien ennå ikke har dekket. En cloud-sesjon i denne konteksten er en Claude Code-økt som kjører hos Anthropic i stedet for på din egen maskin. Starter du den fra claude.ai eller mobilappen, får du en fersk virtuell Linux-maskin. Den kjører som root, med omtrent 4 vCPU, 16 GB RAM og 30 GB disk. Repoet klones fra GitHub. Det kopieres aldri fra disken din, så lokale commits som ikke er pushet, finnes rett og slett ikke for sandkassen som kjøres hos Anthropic. Git går gjennom en proxy hos Anthropic som holder ekte credentials utenfor den virtuelle maskinen, og sesjonen starter på sin egen branch, med push begrenset til nettopp den branchen. Det er ingen egen kompute-kostnad; en cloud-sesjon spiser av de samme rate limits som alt annet du gjør med Claude.

Nesten all oppførsel i en slik sesjon følger av ett spørsmål. Krysser dette grensen inn i en fersk virtuell maskin? Det spørsmålet organiserer resten av innlegget, og porteringen var i praksis en øvelse i å stille det om og om igjen, mot én avhengighet av gangen.

Eksempelet mitt er altså et Obsidian-vault: hundrevis av notater fordelt på mappene Learning, Meetings, Notes, Personal, Projects, Reference, Templates og Attachments, i et privat GitHub-repo på flere hundre megabytes. Funnene fra arbeidet med å gjøre vaultet klart for skyen handler om hva som skal til for å rigge repoet for denne grensen mot en fersk virtuell maskin i Claude Code. Jeg diskuterer også hvor mye som overføres til vanlige kodebaser, og der noe kun gjelder mitt oppsett, sier jeg fra underveis. Dette er reisebrevet fra porteringen, fortalt i den rekkefølgen den faktisk skjedde. Vi starter med den mentale modellen alt annet henger på.

## Hva krysser grensen?

Den mentale modellen er to kolonner. Over grensen går alt som er committet til repoet, repo-scoped agentkonfig som skills, hooks, regler og MCP-deklarasjoner i `.claude/`, miljøkonfig du setter i hosting-UI-et (https://claude.ai/code), og hostede OAuth-konnektorer der Anthropic holder innloggingen. Den siste kategorien dekker mer enn man skulle tro, f.eks. Gmail, Slack, Google Calendar, Google Drive og Exa. De virket alle i skyen uten at én eneste credential lå i sandkassen. I stedet autentiserer du med Claude sine Connectors for å gi agenten tilgang til disse verktøyene. Igjen på utsiden blir alt i hjemmekatalogen din: brukerscopede skills og settings, shell og PATH, dotfiles, installerte CLI-er, lokale daemons, desktop-apper og innloggede nettlesere.

![Diagram med to kolonner: til venstre det som krysser grensen inn i en cloud-sesjon (committet repo-innhold, repo-scoped agentkonfig, miljøkonfig satt i UI-et, hostede OAuth-konnektorer), til høyre det som ikke krysser (~/.claude og dotfiles, PATH og installerte CLI-er, lokale daemons, innlogget nettleser, macOS-primitiver)](https://www.magnusrodseth.com/blog/agenter-du-ikke-sitter-foran/hva-krysser-grensen.webp)
_Venstre kolonne følger med inn i en fersk virtuell maskin, høyre kolonne blir igjen på Mac-en. Kilde: Egen illustrasjon._

## Mål faktisk bruk før du porterer noe

Oppsettet mitt er fullt av detaljer som bare gjelder meg, så jeg skal spare deg for inventarlista, men selve metoden er verdt å ta med seg. Før du porterer noe som helst, la Claude gå gjennom sine egne transkripter og samtaler og finne mønsteret i hva som faktisk brukes. Claude Code lagrer transkripter av hver sesjon som JSONL, med hvert verktøykall som en egen linje, så agenten kan selv rangere skills, MCP-servere og CLI-verktøy etter reell bruk, uansett hva hukommelsen din påstår.

Med den rangeringen i hånden blir diskusjonen om hva som er verdt å flytte til cloud-miljøet konkret. For hvert element på lista spør du om det er levedyktig i skyen, eller om det heller skal forbli på desktopen med vilje. Hos meg viste målingen at den mest brukte integrasjonen aldri kunne fungere i skyen, at flere konfigurerte MCP-servere aldri var brukt, og at to secrets en tidlig plan hadde utpekt som nødvendige, kunne strykes.

På den måten kan man si at inventaret av hva du har, kan lyve, men transkriptene av samtalene dine lyver ikke. Det ene forteller hva som finnes; det andre forteller hva som betyr noe. Målingen er dessuten det eneste steget i hele porteringen som sletter arbeid framfor å legge til, og derfor er det steget som skal gjøres først.

## Portabel, tilpassbar eller død

Neste steg var å klassifisere hver avhengighet i tre bøtter. Portabel betyr ren instruksjon, eller en CLI som kan installeres fra et pakkeregister, slik `yt-dlp`, verktøyet som laster ned video og lyd fra YouTube, kan fra pip. Tilpassbar dekker det som virker etter én endring, som regel en hardkodet sti eller en antatt binærfil. Ting som klassifiseres som død, er strukturelt umulig i en virtuell maskin, uansett innsats.

Den døde bøtta følger gjenkjennelige mønstre. Operativsystem-primitiver som utklippstavle, lydavspilling og app-URI-er (for eksempel `notion://` eller `obsidian://`) finnes ikke i en headless virtuell maskin. Interaktiv autentisering, som BankID, kan ikke gjennomføres der. Bruker du CLI-er eller MCP-servere som styrer en innlogget nettleser, for eksempel Playwright-basert automatisering mot din egen Chrome, sitter de fast på maskinen der nettleseren og innloggingen faktisk bor. Det samme gjelder alt som snakker med en lokal daemon på localhost, for eksempel en database eller en språkmodell du kjører selv på maskinen din.

Regn med at noe du bruker mye havner i denne bøtta, og godta det tidlig i stedet for å bruke dagene på å lete etter omveier. Den fristende omveien er gjerne å smugle credentials eller session-cookies inn i sandkassen, men det er sjelden verdt risikoen. Se heller etter en enklere kanal som allerede krysser grensen, for eksempel e-postvarsler (som du senere kan lese med Gmail-konnektoren rett i Claude), og la resten bli igjen på desktopen med god samvittighet.

## Den hardkodede stien

Så kom det første bruddet, i den tilpassbare bøtta. `read-up-on` er den mest brukte skillen i hele oppsettet mitt i min second brain, og den er selve gjenkallingen. Be agenten lese seg opp på en person, et prosjekt eller et tema, så søker den gjennom notatene og starter samtalen med det du allerede vet, i stedet for fra null. Den skillen åpnet slik:

```bash
# Before: resolves to nothing in a sandbox, and reports nothing
VAULT="$HOME/dev/personal/vault"
```

Den stien finnes ikke i en sandkasse. Skillen ville likevel aldri feilet. Den ville søkt i ingenting og returnert ingenting, og et tomt svar leses som "du har ingenting på fil" i stedet for som en feil. Rettelsen ser omtrent slik ut:

```bash
# After: falls back to the project directory when the Mac path is absent
if [ -d "$HOME/dev/personal/vault" ]; then
    VAULT="$HOME/dev/personal/vault"
else
    VAULT="${CLAUDE_PROJECT_DIR:-$PWD}"
fi
```

Revider derfor for tomme svar like grundig som for feilmeldinger dersom du setter opp dette for deg selv. En krasj melder fra om seg selv, mens et tomt svar ikke gjør det.

## Setup-scriptet som må feile åpent

Neste brudd lå i miljøprovisjoneringen. En cloud-sesjon kan kjøre et setup-script du legger inn i hosting-UI-et (igjen på https://claude.ai/code), og Anthropics dokumentasjon sier det rett ut: "If the script exits non-zero, the session fails to start."

Den første versjonen min var skrevet slik jeg vanligvis skriver shell-script, med `set -euo pipefail` og `exit 1` når verifiseringen feilet. I denne konteksten betyr det at en feilet installasjon av en nødvendig pakke hindrer enhver sesjon i å starte. Et strengt script er altså det mindre passende valget her. Står du på bussen og åpner mobilappen, vil du heller at sesjonen starter opp med én ødelagt skill fordi `yt-dlp` mangler, enn at den ikke starter i det hele tatt.

Scriptet ble skrevet om slik at hver installasjon tåler å feile, feil akkumuleres som `WARN`-linjer, og siste linje alltid er `exit 0`. Mønsteret ser slik ut:

```bash
set -uo pipefail   # deliberately NOT -e: a non-zero exit stops the session from starting

warnings=0
warn() { printf '  WARN: %s\n' "$1"; warnings=$((warnings + 1)); }

apt-get install -y -qq --no-install-recommends ffmpeg pandoc \
    || warn "apt-get install of ffmpeg/pandoc failed"

# Always succeed, even with warnings.
exit 0
```

For dette vaultet installerer scriptet PyYAML, som frontmatter-hooken trenger for å validere formatet på Obsidian-notatene mine, pluss `ffmpeg`, `yt-dlp` og `pandoc` for transkriberings- og eksportskills. Til slutt ett tips som kanskje kan spare deg for litt tid om du setter dette opp selv. Sett nettverkspolicyen til Custom med en egen liste over domenene du og skillsene og arbeidsflytene dine trenger, og husk å huke av for å inkludere standardlisten over pakkeforvaltere. Hos meg ser lista for eksempel slik ut:

```text
youtube.com
*.youtube.com
*.googlevideo.com
*.ytimg.com
youtu.be
```

Uten haken for pakkeforvaltere er kun dine egne domener mulige å nå. Da slutter apt, pip og npm i setup-scriptet å virke.

## Hooks for en ny topologi

Mitt personlige vault har en `Stop`-hook i Claude som auto-committer og pusher etter hver tur, slik at Obsidian på Mac-en og repoet på GitHub aldri glir fra hverandre. Slike hooks bærer på antakelser om git-topologien rundt seg, og hos meg var antakelsen en langlevd branch med upstream (siden jeg tross alt kun sitter i main-branchen og pusher og puller arbeid kun jeg gjør).

Cloud-sesjoner starter på en fersk branch uten upstream. Der feilet push-steget i hooken, ingen fallback tok over, og hver eneste cloud-sesjon ville endt blokkert på en push-feil. Dette fikset jeg ved at hooken nå først sjekker om branchen har en upstream, og setter den opp på første forsøk på push dersom den mangler.

![Topologidiagram over Mac, GitHub og den virtuelle maskinen i skyen: heltrukne piler viser den utgående veien fra lokal Stop-hook via commit til main, kloning inn i den virtuelle maskinen, plattformens commit på claude/-branch og draft-PR; stiplede piler viser veien tilbake fra SessionStart-hook via git fetch, fast-forward, gh pr list, merge og git pull](https://www.magnusrodseth.com/blog/agenter-du-ikke-sitter-foran/topologi.webp)
_Heltrukne piler er den utgående flyten; de stiplede pilene bringer arbeid hjem igjen. De stiplede fantes ikke på dag én. Kilde: Egen illustrasjon._

Reproduser derfor topologien i et lite engangsrepo du lager kun for testen, med et lokalt remote å pushe mot, før du stoler på hooks i skyen. Kjør hooken både på en branch som har upstream og på en fersk branch uten, og reproduser den gamle feilen med vilje; ellers vet du ikke om du fikset noe. Sjekk samtidig hooks for plattformspesifikke binærfiler, og gate dem på variabelen som markerer en ekstern sesjon (i Claude Code: `CLAUDE_CODE_REMOTE`) framfor å vedlikeholde to konfigfiler som kan drifte fra hverandre.

## Den diagnostiske sesjonen

Med rettelsene pushet var neste steg én sesjon som beviser at cloud-miljøet fungerer ende-til-ende uten problemer. Oppskriften er enkel. Be om en tabell, og forby filendringer. Deretter ber du agenten kartlegge hvilke binærfiler og språkpakker som finnes, og hva som ligger i agent-konfigkatalogen. Så ber du om sesjonsmarkør- og credential-lignende miljøvariabler, samt branch og remote. Til slutt vil du vite hvilke integrasjoner som koblet til og hvilke som feilet, og du ber om ett tillatt og ett ikke-tillatt nettverkskall for å teste nettverkspolicyen.

Det mer generelle grepet er verdt å nevne. For hver antatte rettelse lot jeg Claude Code på desktopen styre en innlogget nettleser mot Claude Code på web, og kjøre prøvesamtaler i cloud-sesjonen for å teste at alt virket som forventet: at skills lastet, at CLI-verktøyene fra setup-scriptet fantes, at MCP-servere koblet til, og at domener som YouTube var mulige å nå.

Å la agenten kjøre og verifisere seg selv ende til ende sparte meg for både tid og kognitiv last.

## Returveien

Alt til nå har handlet om å få arbeid inn i skyen: kloning, setup-script, skills, MCP, nettverkspolicy. Mekanismen som bringer arbeid skapt i skyen tilbake til maskinen du sitter ved, kaller jeg returveien, og den fantes ikke.

Det første åpenbare problemet dreide seg om åpne PR-er som ingen merger. Cloud-sesjoner pusher til `claude/...` og åpner en draft-PR, og på desktopen får `main` aldri vite om dem (med mindre jeg som sitter foran tastaturet ber Claude sjekke manuelt). Arbeidet gjort på mobilen i farta kan ligge umerget i det uendelige mens den lokale `Stop`-hooken på desktop committer videre rett på `main`, og dermed er avviket hooken skulle hindre til å begynne med, tilbake fra motsatt side.

Det andre problemet er stillere. Merger du en cloud-PR fra telefonen, blir desktop-miljøet stående utdatert dersom du glemmer å pulle nye endringer fra `main` på remote. Rettelsen er de stiplede pilene i topologidiagrammet over, altså en `SessionStart`-hook som fetcher, fast-forwarder når det er trygt, og rapporterer åpne PR-er automatisk uten at utvikleren må si ifra manuelt. Den fyrer én gang per sesjonstilstand, og det den skriver til stdout, injiseres i agentens kontekst før første brukermelding.

Så et litt viktig forbehold, da. Dette oppsettet fungerer for meg personlig på bakgrunn av følgende: vaultet har én skribent, ingen CI å ødelegge og ingen review-krav, og det har en lokal applikasjon, Obsidian, som leser rett fra disk. Skal du generalisere dette til en kodebase, må nok hver utvikler fortsatt ta en mer manuell synkjobb (som vanlig), altså ikke belage seg på like mye automatisering som jeg forsøker å få til i dette personlige oppsettet.

## Avslutning

For å oppsummere og avslutte. Et spørsmål jeg regner med at en skeptisk leser sitter igjen med, er hvorfor i all verden man skal gidde å gjøre dette for seg selv. Du vil kanskje ikke jobbe fra telefonen i det hele tatt, og sitter uansett nok foran laptopen allerede. Lærdommen er at en slik portering, uavhengig av hvor mye du faktisk planlegger å bruke kodebasen din fra mobilen, fungerer som en tvungen opprydding. Du avdekker udeklarerte avhengigheter du har samlet opp i kodebasen, og retter du dem, får det positive ringvirkninger for det lokale oppsettet ditt også. Et koderepo en fersk virtuell maskin kan bruke, er et koderepo en ny maskin, en ny kollega eller CI kan ta i bruk med lite eller ingen ekstra jobb.

Et praktisk tips før vi runder av. Virker dette interessant og nyttig for ditt eget oppsett, kan du rett og slett kopiere hele innlegget inn i en sesjon med din egen agent. La den utforske repoet ditt med grensespørsmålet i hånden, og legg planen for porteringen sammen med den.

En siste ting jeg vil trekke fram. Om ikke annet håper jeg denne posten har gitt deg litt lyst til å sette opp din egen second brain. Det har ikke vært hovedfokuset her, men det er jo nettopp opphavet til at jeg så behovet for et bedre utviklermiljø på mobilen i Claude Code-appen. Jeg vil derfor benytte anledningen til å anbefale at du tester ut å bygge din egen, for min hjelper meg enormt både på jobb og privat. Med avtaler, meldinger og notater samlet ett sted får jeg mindre kognitiv last, mindre friksjon når jeg plukker opp dialoger igjen, og en større kunnskapsbase om alt som handler om meg.

Og som en liten sidenote. Er du usikker på å dele mye data med AI-leverandører som Anthropic eller OpenAI, så husk at det alltid er opp til deg hvor mye du faktisk deler. Det er ikke et "all or nothing". Det er et spekter, og du bestemmer selv hva du lar din second brain bestå av.

## Ressurser

- [Claude Code på web](https://code.claude.com/docs/en/claude-code-on-the-web): Anthropics dokumentasjon for cloud-sesjoner
- [Hooks-referansen](https://code.claude.com/docs/en/hooks): Lifecycle-hendelser, matchere og kontrakten for stdin/stdout


---

# SEO i agentenes tidsalder: Slik gjør du webapplikasjonen din klar for agenter

Published: August 2026
Originally published at Capra Consulting: https://capraconsulting.no/vare-historier/seo-i-agentenes-tidsalder-slik-gjor-du-webappen-din-klar-for-agenter

> Slik gjør du webapplikasjonen din klar for AI-agenter: de fem byggesteinene for en innholdsside, casen der heihuset.no gikk fra «Not Ready» til «Agent-Native» på én arbeidsdag, og hva vi med vilje lot stå rødt.

![Editorial illustration, wide 16:9 banner composition. A person and a small friendly rounded robot sit side by side on a simple park bench, each absorbed in reading an identical large broadsheet newspaper, the two front pages clearly showing the same abstract layout of headline bars and image blocks. Their postures mirror each other. Mood: calm coexistence, two very different readers of the same content. Person and bench in soft slate, robot in muted teal with a single rust accent, newspapers in warm cream with slate detail, warm cream background. Flat editorial illustration with subtle paper grain texture, restrained detail and no fine line work, generous negative space. No text, no letters, no words inside the image. Magazine opinion-section feel like The Economist or New York Times opinion illustrations.](https://www.magnusrodseth.com/blog/seo-i-agentenes-tidsalder/banner.webp)
_Nettsiden din har fått en ny lesergruppe, og den leser helst markdown. Kilde: OpenAI gpt-image-2._

## Innledning

Se for deg at noen spør ChatGPT eller Claude om et problem produktet ditt løser. Assistenten prøver å lese nettsiden din, får et tomt HTML-skall i retur, og anbefaler noe annet i stedet. Ingen feilmelding, ingen logg som varsler deg; du er bare ikke med i samtalen. Kanskje du har brukt flere år på å rangere i Google, og så dukker det opp en ny lesergruppe som ikke får åpnet døra.

Når vi bygger heihuset.no, produktet jeg jobber med for Gjensidige, er vi svært bevisste på dette. Cloudflares skanner [isitagentready.com](https://isitagentready.com/) ga oss 0 poeng: «Level 0, Not Ready». Én arbeidsdag senere viste samme skanner «Level 5, Agent-Native». Imellom lå en spesifikasjon som vurderte hver enkelt sjekk, en runde pull requests med review og verifisering i produksjon. Agenter gjorde alt sammen, med meg som godkjenner underveis.

Det mest slående i etterkant er hvor lite som skulle til. Alt vi bygde er velkjent webteknologi, og den egentlige jobben var å vite hva agenter ser etter når de banker på døra. Den sjekklisten får du her, sammen med begrunnelsen for det vi med vilje lot stå rødt.

## Hvem leser nettsiden din i 2026?

Klassisk SEO handler om å bli funnet av Google. Det som har endret seg, er hvem som leser nettsider nå: [i 2026 passerte bot-trafikken menneskene](https://radar.cloudflare.com/ai-insights), med 57,5 prosent av HTML-trafikken ifølge Cloudflare. Samtidig faller klikkene fra tradisjonelt søk, fordi AI Overviews (Googles AI-genererte svar øverst i søkeresultatet) [besvarer spørsmålet før brukeren rekker å klikke](https://www.searchenginejournal.com/impact-of-ai-overviews-how-publishers-need-to-adapt/556843/).

Trafikken fra AI-assistenter som ChatGPT, Claude og Perplexity er fortsatt liten, [rundt én prosent av totalen](https://www.tryanalyze.ai/blog/ai-traffic-research), men den konverterer flere ganger bedre enn organisk søk i [målinger fra flere analyseleverandører](https://trakkr.ai/ai-search-traffic). Når en assistent anbefaler deg ved navn, kommer besøkeren ferdig overbevist. Samtidig koster crawlingen (automatisk henting og lesing av nettsider) mer enn den gir tilbake i klikk: Cloudflare har målt at [OpenAI crawlet over tusen sider per besøkende de sendte tilbake](https://blog.cloudflare.com/crawlers-click-ai-bots-training/).

Bransjen har rukket å lage minst tre akronymer for å optimalisere mot dette: GEO (Generative Engine Optimization), AEO (Answer Engine Optimization) og ASO (Agentic Search Optimization). [De beskriver i praksis det samme](https://digiday.com/media/wtf-are-geo-and-aeo-and-how-they-differ-from-seo/): å bli funnet, sitert og brukt av AI-systemer. «Agent-readiness» er den tekniske enden av begrepsfloraen: at en agent som besøker siten din, faktisk klarer å lese og bruke den.

## Skanneren

[isitagentready.com](https://isitagentready.com/) er Cloudflares svar på «hvordan står det til med vår applikasjon?», [lansert i april 2026](https://blog.cloudflare.com/agent-readiness/). Skanneren kjører 19 sjekker i fem kategorier og gir en score fra 0 til 100 med nivåer fra «Not Ready» til «Agent-Native». Før du scanner, velger du hvilken type nettsted du har, og det avgjør hvilke sjekker du måles på:

- **Content Site** er for blogger, dokumentasjon og markedsføringssider, altså nettsteder som først og fremst skal bli funnet og lest. Her måles du på discoverability og innholdstilgang: robots.txt, sitemap, Link headers, DNS-AID, markdown content negotiation, AI-crawler-regler og Content Signals.
- **API / Application** er for tjenester og webapper der agenter skal gjøre noe, og legger til sjekkene for maskinbruk: OAuth discovery, API-katalog, MCP Server Card, agent skills og WebMCP.

Driver du en innholdsside, kan du trygt ignorere hele API-familien av sjekker. heihuset.no er utad en ren innholdsside, så Content Site-presetet var det vi målte oss mot.

![Skjermbilde av forsiden til isitagentready.com: overskriften «Is Your Site Agent-Ready?», et URL-felt med en Scan-knapp, og utvidbare spørsmål som «What do we check?»](https://www.magnusrodseth.com/blog/seo-i-agentenes-tidsalder/skanner-forside.png)
_Skanneren er gratis og tar sekunder: lim inn en URL og få en full sjekkliste tilbake. Skjermbilde fra isitagentready.com._

Tallene fra lanseringen viser hvor lav lista ligger. Blant de 200 000 største domenene har [78 prosent robots.txt, 4 prosent Content Signals og 3,9 prosent markdown-støtte](https://blog.cloudflare.com/agent-readiness/). Det skal med andre ord lite til for å ligge langt foran, og det gjelder også her hjemme:

![Skjermbilde av skanneresultatet for nrk.no på isitagentready.com: score 43 av 100, nivå 1 «Basic Web Presence», med merkelappen «Partial scan, 7 of 19 checks enabled»](https://www.magnusrodseth.com/blog/seo-i-agentenes-tidsalder/nrk-scan.png)
_Selv nrk.no lander på 43 av 100 med innholdssjekkene (nivå 1, «Basic Web Presence») per 7. juli 2026. Skjermbilde fra isitagentready.com._

## Hva vi bygde

Baseline-scanen ga 0 poeng fordi alt manglet. Hver eneste sti skanneren prøvde, endte i en såkalt soft-404: serveren svarte «200 OK» og returnerte den vanlige nettsiden, uansett hva du ba om. Ba du om `/robots.txt`, fikk du altså appens HTML i retur i stedet for en tekstfil. Agentene fikk skannerens funn som utgangspunkt og bygde fem ting:

- **robots.txt med AI-crawler-regler.** Policyen vår er at innholdet skal være synlig i søk og AI-svar, men ikke brukes som treningsdata. Treningscrawlere som GPTBot, ClaudeBot og CCBot blokkeres, mens OAI-SearchBot, ChatGPT-User og PerplexityBot får lese offentlige sider.
- **[Content Signals](https://contentsignals.org/)**, en maskinlesbar linje i robots.txt som erklærer hva innholdet kan brukes til: `Content-Signal: search=yes, ai-train=no, ai-input=yes`. Den siste betyr ja til at assistenter bruker innholdet som kilde når de svarer (såkalt RAG eller grounding).
- **sitemap.xml**, generert fra den samme innholdslisten som resten av appen bruker.
- **Markdown content negotiation**: samme URL leverer ulikt format avhengig av hva klienten ber om i Accept-headeren. Ber du om `text/markdown`, får du ren markdown i stedet for HTML-skallet. Her er gevinsten stor for agenter som betaler per token: [Cloudflare målte en typisk bloggpost](https://blog.cloudflare.com/markdown-for-agents/) til 16 180 tokens som HTML og 3 150 som markdown.
- **Link headers** ([RFC 8288](https://datatracker.ietf.org/doc/html/rfc8288)). Dette er en HTTP response header, altså et eget felt i svaret fra serveren, som peker agenter rett til sitemap-en uten at de først må tolke HTML.

Alt dette er offentlig og kan sjekkes fra terminalen din:

```bash
curl https://www.heihuset.no/robots.txt
curl https://www.heihuset.no/sitemap.xml
curl -H "Accept: text/markdown" https://www.heihuset.no/
```

## Re-scan: 21 poeng

Da alt var merget og deployet, kjørte vi skanneren på nytt og fikk 21 poeng. Implementasjonene var riktige; det var infrastrukturen mellom appen og verden som serverte noe annet enn koden returnerte.

![Editorial illustration. A cozy small shop seen from the street at dusk, warm light glowing from its windows, shelves inside fully stocked and inviting, the interior clearly open for business. On the glass front door hangs a single small hanging sign showing only a crescent moon symbol, universally read as closed. Outside, a short polite line of small rounded robots is turning around and walking away from the shop. Mood: quiet irony, a well-stocked shop accidentally turning everyone away. Shop in muted teal and soft slate, warm light in cream, one rust accent on the hanging sign, warm cream background. Flat editorial illustration with subtle paper grain texture, restrained detail and no fine line work, a single central concept, symbolic rather than literal, with generous negative space. No text, no letters inside the image. Magazine opinion-section feel like The Economist or New York Times opinion illustrations.](https://www.magnusrodseth.com/blog/seo-i-agentenes-tidsalder/closed-sign.webp)
_Butikken var åpen og full av varer, men skiltet på døra sa stengt. Kilde: OpenAI gpt-image-2._

Detaljene er spesifikke for vårt oppsett og lite overførbare, men mønsteret er generelt: gatewayer, cacher og rolling deploys kan alle gjøre at produksjon svarer noe annet enn koden din tilsier. Hos oss endte robots.txt en kort stund med å be samtlige crawlere holde seg unna. Avhengig av hosting-leverandør og løsning må du regne med et par slike triks før alt stemmer.

To lærdommer er verdt å ta med seg uansett oppsett. Verifiser innholdet i svaret i produksjon, og la aldri en grønn statuskode alene telle som bevis: vår «verifisert i prod»-sjekk så på statuskode og content-type, og begge var riktige mens selve innholdet var feil. Og husk at cachede svar kan overleve deployen din, så kjør skanneren på nytt etter at cache-TTL-en (levetiden på den lagrede kopien) har gått ut, ellers jakter du spøkelser.

Selve verifiseringen er for øvrig en jobb det lønner seg å gi agenten. Det er tross alt agenter som skal konsumere disse endepunktene, og en agent curler seg gjennom robots.txt, sitemap og markdown-svarene og sjekker hvert svar mot Cloudflares anbefalinger langt mer systematisk (og raskere) enn en utvikler som klikker seg rundt i nettleseren.

## Skanneren deler ut sin egen oppskrift

Hver feilet sjekk i skanneren kommer med en forklaring, en «Copy prompt»-knapp du kan lime rett inn i din egen coding-agent, og en lenke til en SKILL.md, altså en ferdig agent-skill med oppskriften på fiksen. Skanneren publiserer [en indeks med slike skills](https://isitagentready.com/.well-known/agent-skills/index.json) på sitt eget `/.well-known/agent-skills/`-endepunkt, én for hver standard den sjekker, og hver skill avslutter med et maskinsjekkbart valideringssteg mot skannerens API.

![Editorial illustration, circular composition. Three stations arranged evenly around a ring, connected by one smooth continuous circular arrow path flowing clockwise: first a large magnifying glass hovering over a small abstract website window, second a paper scroll unrolled to show an abstract checklist of bars, third a small friendly robot arm holding a wrench over the same small website window. The circle reads as a self-sustaining loop: inspect, instruct, repair, inspect again. Mood: elegant self-reference, a system that feeds itself. Magnifying glass in soft slate, scroll in warm cream with slate bars, robot arm in muted teal with a single rust accent on the wrench, warm cream background. Flat editorial illustration with subtle paper grain texture, restrained detail and no fine line work, a single central concept, generous negative space. No text, no letters inside the image. Magazine opinion-section feel like The Economist or New York Times opinion illustrations.](https://www.magnusrodseth.com/blog/seo-i-agentenes-tidsalder/skill-loop.webp)
_Skanneren klager, serverer oppskriften på fiksen, og verifiserer resultatet. Kilde: OpenAI gpt-image-2._

Dermed oppstår en pussig loop: agenten som fikser nettstedet ditt, henter oppskriften fra tjenesten som klaget, og verifiserer fiksen mot samme tjeneste. Verktøyet som måler agent-readiness, er selv agent-ready. Nå har tjenester begynt å publisere prosessene sine i samme format.

## Det vi ikke bygde

To av sjekkene i Content Site-presetet lot vi stå røde. DNS-AID (agent-oppdagelse via DNS) forutsetter agent-endepunkter å annonsere, og Link headers-sjekken godkjenner bare lenker til API-kataloger og tjenestedokumentasjon. Resten av de røde hører til API / Application-siden: MCP Server Card (et maskinlesbart visittkort for en [MCP-server](https://modelcontextprotocol.io/docs/getting-started/intro)), API-katalog ([RFC 9727](https://datatracker.ietf.org/doc/rfc9727/)) og OAuth discovery. Alt sammen forutsetter infrastruktur dette produktet ikke har: et offentlig API, en OAuth-utsteder eller en MCP-server. Vi landet på å hoppe over dem, dokumentere begrunnelsen for hver enkelt, og la sjekkene stå røde.

Tallet du får, avhenger altså av hvilke sjekker du slår på, og samme side kan lande på alt fra toppnivå til midt på treet. Den viktige øvelsen er å velge sjekkene som gjelder for produktet ditt, og å kunne forklare de røde som blir stående.

## Hva med llms.txt?

llms.txt (en foreslått konvensjon der en tekstfil i roten skal gi AI-modeller en kompakt oversikt over nettstedet) dukker alltid opp i disse diskusjonene. Ahrefs analyserte serverlogger fra 137 000 domener og fant at [97 prosent av llms.txt-filene ikke fikk en eneste forespørsel fra AI-crawlere](https://ahrefs.com/blog/llmstxt-study/) i mai 2026, og Googles John Mueller har [sammenlignet filen med keywords-metataggen](https://www.seroundtable.com/google-does-not-endorse-llms-txt-40789.html) fra gamle dager, altså en egenerklæring om hva siten handler om, som søkemotorene endte med å ignorere fordi påstandene like gjerne kunne være usanne, og innholdet uansett kan leses direkte. Cloudflares skanner sjekker den ikke engang.

Kodeagenter ber i stedet om markdown via Accept-headeren; [Checkly målte at Claude Code, Cursor og OpenCode gjør nettopp det](https://www.checklyhq.com/blog/state-of-ai-agent-content-negotation/). Skal du prioritere én ting for agentlesbarhet, er det content negotiation på HTTP-nivå.

## En måned senere

Mens jeg skrev dette innlegget, kjørte jeg skannerens API mot heihuset.no på nytt. Alle de fem sjekkene passerer fortsatt. Det fine er at sitemap-en nå inneholder en artikkel publisert etter at vi gjorde webapplikasjonen agent-ready, uten at noen har rørt agent-readiness-koden siden juni. robots.txt, sitemap og markdown-endepunktene genereres fra innholdet, så nytt innhold blir agent-klart uten ekstra arbeid. Riggingen ligger i systemet og blir med videre.

## Ressurser

- [isitagentready.com](https://isitagentready.com/): Cloudflares agent-readiness-skanner, med skills for hver sjekk
- [Introducing the Agent Readiness score](https://blog.cloudflare.com/agent-readiness/): Lanseringsbloggen med adopsjonstall
- [contentsignals.org](https://contentsignals.org/): Content Signals-spesifikasjonen
- [Markdown for agents](https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/): Cloudflares dokumentasjon av markdown content negotiation
- [Ahrefs: llms.txt-studien](https://ahrefs.com/blog/llmstxt-study/): Serverlogger fra 137 000 domener
- [Checkly: State of AI agent content negotiation](https://www.checklyhq.com/blog/state-of-ai-agent-content-negotation/): Hvilke agenter som faktisk ber om markdown
- [Cloudflare Radar: AI Insights](https://radar.cloudflare.com/ai-insights): Løpende tall på AI-crawler-trafikk


---

# EU AI Act for utviklere: Hva som gjelder fra 2. august, og hva som nettopp ble utsatt

Published: July 2026
Originally published at Capra Consulting: https://capraconsulting.no/vare-historier/eu-ai-act-for-utviklere

> Høyrisiko-regimet er utsatt til 2027, Norge er ikke bundet ennå, og kodeassistenter er ikke høyrisiko. Dette gjelder faktisk fra 2. august 2026.

![Editorial illustration, wide 16:9 banner composition. A calm, flat European Union flag motif fills the frame: a deep muted navy-blue field with a circle of twelve small five-pointed gold stars placed off-center toward the left, rendered flat and matte. In the open space to the right of the star circle, elegant serif text in warm cream reads exactly, with correct Norwegian spelling including the letter å: "Hvordan forbereder jeg meg på EU AI Act?" set in a classic editorial serif typeface, broken over two or three lines, with generous letter spacing. No other text anywhere in the image. Mood: calm, civic, editorial. Palette: deep muted navy blue, soft matte gold, warm cream. Flat editorial illustration with subtle paper grain texture, restrained detail and no fine line work, generous negative space. Magazine opinion-section feel like The Economist or New York Times opinion illustrations.](https://www.magnusrodseth.com/blog/eu-ai-act-for-utviklere/banner.webp)
_Hvordan forbereder du deg på EU AI Act? Kortversjonen: roligere enn overskriftene tilsier. Kilde: OpenAI gpt-image-2._

## Innledning

Den 2. august 2026 skrus håndhevingsmaskineriet i EU AI Act (KI-forordningen, EUs felles regelverk for utvikling og bruk av AI) på: nasjonale tilsyn får bøtemyndighet, og transparenskravene i artikkel 50 begynner å gjelde. Samtidig vedtok EU i juni en endringspakke, [Digital Omnibus](https://www.europarl.europa.eu/legislative-train/package-digital-package/file-digital-omnibus-on-ai), som flytter de tyngste pliktene, hele høyrisiko-regimet (de strengeste kravene, forbeholdt AI på særlig sensitive bruksområder), til desember 2027. Begge deler skjedde i løpet av de siste ukene, og begge deler er underkommunisert blant utviklere.

Jeg har brukt en del tid på å nøste i hva dette faktisk betyr for oss som bygger med AI-agenter i hverdagen. Kortversjonen: kodeassistenten din er ikke høyrisiko, du må etter alt å dømme ikke vannmerke AI-generert kode, og Norge er strengt tatt ikke bundet av forordningen ennå. Men noen plikter er reelle, og et par feller er lette å gå i.

I dette innlegget får du datoene som gjelder etter endringene, hva som faktisk treffer et utviklingsteam, og hvor Norge står.

![Editorial illustration, wide composition. A long straight road recedes toward a calm horizon across a flat landscape. In the foreground a simple stone milestone marker stands beside the road. Much further down the same road stands a second, identical milestone, freshly planted, with faint drag marks in the ground between the two showing it was recently moved from the near position to the far one. No people. Mood: postponement, recalibration, calm. Road in soft slate, milestones in muted teal, a single rust accent on the far milestone, warm cream background and sky. Flat editorial illustration with subtle paper grain texture, restrained detail and no fine line work, a single central concept, symbolic rather than literal, with generous negative space. No labels, no text, no numbers inside the image. Wide 16:9 composition, magazine opinion-section feel like The Economist or New York Times opinion illustrations.](https://www.magnusrodseth.com/blog/eu-ai-act-for-utviklere/milestone-moved.webp)
_Den store fristen ble nettopp flyttet: høyrisiko-regimet gjelder først fra desember 2027. Kilde: OpenAI gpt-image-2._

## Datoene, etter Digital Omnibus

Forordningen trådte i kraft allerede i 2024, men pliktene fases inn over flere år. Etter endringspakken ser [tidslinjen](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act) slik ut:

- **2. februar 2025:** Forbudene (artikkel 5, praksiser som sosial poengsetting og manipulerende AI) og kravet om AI literacy (artikkel 4, at folk som bruker AI i jobben skal ha tilstrekkelig kompetanse) gjelder allerede.
- **2. august 2025:** Plikter for tilbydere av generelle AI-modeller (GPAI, general-purpose AI: grunnmodellene som alt annet bygges på), altså selskaper som OpenAI, Anthropic og Google.
- **2. august 2026:** Transparenskravene i artikkel 50, pluss håndhevingen: nasjonale tilsyn, bøter og [regulatoriske sandkasser](https://www.datatilsynet.no/regelverk-og-verktoy/sandkasse-for-kunstig-intelligens/) (veiledede testmiljøer der bedrifter prøver ut AI-systemer sammen med tilsynet).
- **2. desember 2027:** Høyrisiko-regimet for bruksområdene i [Annex III](https://artificialintelligenceact.eu/annex/3/) (forordningens vedlegg som lister opp hvilke bruksområder som regnes som høyrisiko). Denne fristen var opprinnelig 2. august 2026.
- **2. august 2028:** Høyrisiko-krav for AI innebygd i produkter som allerede er regulert på andre måter, for eksempel medisinsk utstyr og biler (Annex I).

Utsettelsene kom med Digital Omnibus, som Europaparlamentet vedtok 16. juni og Rådet ga endelig klarsignal i slutten av juni. Pakken er i skrivende stund på vei inn i EUs offisielle tidsskrift. Har du sett paniske innlegg om at «alt» gjelder fra 2. august, kan du altså puste rolig ut: [den største fristen ble nylig flyttet 16 måneder frem i tid](https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/).

## Er kodeassistenten din høyrisiko?

Nei. Annex III er en lukket liste over _bruksområder_, og vanlig utviklerassistanse står ikke på den. Listen handler om ting som rekruttering, kredittvurdering, utdanning og kritisk infrastruktur. Et team som bruker Claude Code eller Copilot til å skrive, teste og gjennomgå kode, har i praksis [null Annex III-eksponering](https://www.augmentcode.com/guides/eu-ai-act-2026).

![Editorial illustration. A short, elegant velvet rope cordon on two small posts encloses a tight cluster of a few abstract geometric shapes at the center of the frame. Clearly outside the cordon, at a comfortable distance, sits a single closed laptop, calm and unbothered. Mood: a small, well-defined enclosure; everything else stands outside it. Cordon and posts in muted teal, enclosed shapes in soft slate, one rust accent on the rope, laptop in soft slate, warm cream background. Flat editorial illustration with subtle paper grain texture, restrained detail and no fine line work, a single central concept, symbolic rather than literal, with generous negative space. No labels, no text inside the image. Magazine opinion-section feel like The Economist or New York Times opinion illustrations.](https://www.magnusrodseth.com/blog/eu-ai-act-for-utviklere/closed-list.webp)
_Annex III er en lukket liste over bruksområder. Kodeverktøyene dine står utenfor. Kilde: OpenAI gpt-image-2._

Fellen ligger et annet sted: **arbeidsstyring** (Annex III punkt 4). Bruker organisasjonen AI til å fordele oppgaver til ansatte eller overvåke og evaluere prestasjoner, er det høyrisiko. Et konkret eksempel: å pipe utviklertelemetri fra GitHub inn i et lederdashboard som evaluerer enkeltpersoner, flytter deg rett inn i høyrisiko-territorium. Da venter krav om teknisk dokumentasjon, automatisk logging og menneskelig oversikt, fra desember 2027.

Rollene avgjør hvem som bærer hvilke plikter. Bruker teamet ditt Claude eller GPT via API, er dere **deployer** (forordningens ord for den som tar et AI-system i bruk), mens modelltilbyderen (**provider**, den som utvikler og tilbyr systemet) bærer GPAI-pliktene. Dere arver dem ikke ved å bruke API-et, og heller ikke ved vanlig «fine-tuning» av AI-modeller (videretrening av en eksisterende modell på egne data): EU-kommisjonens veiledende terskel for å [bli regnet som tilbyder av en modifisert modell](https://artificialintelligenceact.eu/article/25/) er «fine-tuning» med over en tredjedel av compute (regnekraften) som gikk med til å trene originalmodellen. Det gjør ingen av oss til hverdags.

## Dette gjelder faktisk fra 2. august

[Artikkel 50](https://artificialintelligenceact.eu/article/50/) er transparenskrav, og de treffer team som lanserer AI-funksjoner til brukere:

- **Chatboter:** Brukere skal vite at de snakker med en AI, med mindre det er åpenbart. Lanserer du en chat-funksjon bygget på Claude API, er det ditt ansvar som tilbyder av selve applikasjonen.
- **Generert innhold:** Systemer som genererer tekst, bilde, lyd eller video, skal merke innholdet maskinlesbart (for eksempel med metadata eller usynlig vannmerking, slik at programvare kan gjenkjenne det som AI-generert). Systemer som allerede var på markedet før 2. august, har frist til 2. desember 2026.
- **AI-generert kode:** Etter alt å dømme utenfor. Artikkel 50 sikter på syntetisk medieinnhold, og ingen autoritative kilder leser kildekode inn i kravet. Helt svart på hvitt er det likevel ikke; lovteksten sier «tekst».

Fra samme dato kan tilsynene faktisk bøtelegge: [inntil 35 millioner euro eller 7 prosent av global omsetning](https://artificialintelligenceact.eu/article/99/) for forbudte praksiser, 15 millioner eller 3 prosent for de fleste andre brudd. For små og mellomstore bedrifter gjelder det laveste av beløpene, ikke det høyeste.

Og siden ryktene går: per juli 2026 finnes det ingen bekreftede bøter etter forordningen. Historiene om «de første millionbøtene» som sirkulerer i sosiale medier, er ikke belagt i noen offisiell kilde.

## Hvor står Norge?

Forordningen er ennå ikke tatt inn i EØS-avtalen; den ligger fortsatt til vurdering i EØS-komiteen (organet som avgjør hvilke EU-regler som tas inn i EØS-avtalen og dermed blir bindende for Norge). Den norske KI-loven som skal gjennomføre den, var på [høring sommeren 2025](https://www.regjeringen.no/no/dokumenter/3112327/id3112327/), men er [per våren 2026 ikke lagt frem for Stortinget](https://kiforordning.no/ki-loven-norge/). [Nkom (Nasjonal kommunikasjonsmyndighet) er utpekt som koordinerende tilsynsmyndighet](https://www.regjeringen.no/en/whats-new/gjor-norge-klar-for-trygg-og-innovativ-ki-bruk/id3093081/), og Digdir (Digitaliseringsdirektoratet) huser kompetansemiljøet KI-Norge.

![Editorial illustration, wide composition. Two solid piers face each other across a calm, narrow strait of water, one large pier on the left and one smaller pier on the right. A clean bridge extends from the large pier toward the smaller one but stops partway across the water, its unfinished end wrapped in neat, orderly scaffolding. The water is still. Mood: a connection underway but not yet complete, patient. Piers and bridge in muted teal, scaffolding in soft slate with a single rust accent, water and sky in warm cream tones. Flat editorial illustration with subtle paper grain texture, restrained detail and no fine line work, a single central concept, symbolic rather than literal, with generous negative space. No labels, no text, no flags inside the image. Wide 16:9 composition, magazine opinion-section feel like The Economist or New York Times opinion illustrations.](https://www.magnusrodseth.com/blog/eu-ai-act-for-utviklere/eea-bridge.webp)
_Forordningen er vedtatt i EU, men broen over til EØS-avtalen og norsk lov er ikke ferdig bygget. Kilde: OpenAI gpt-image-2._

I praksis betyr det to ting. Selger du kun i Norge, har du ingen direkte forpliktelser etter forordningen i dag, men loven kommer, så det er fornuftig å bygge vanene nå. Selger du inn i EU, gjelder forordningen deg allerede, selv om selskapet ditt ligger utenfor EU ([artikkel 2](https://artificialintelligenceact.eu/article/2/)). Det holder at systemet ditt tilbys på EU-markedet, eller at output fra det brukes i EU.

Ett krav har for øvrig vært gjeldende i EU siden februar 2025: [AI literacy (artikkel 4)](https://digital-strategy.ec.europa.eu/en/faqs/ai-literacy-questions-answers). Både tilbydere og deployere skal sørge for at folk som opererer AI på deres vegne, har tilstrekkelig kompetanse. Omnibus-pakken skal ha myknet formuleringen noe, men opplæringsplikten rundt høyrisiko-systemer består, og kravet følger med inn i norsk lov når den kommer.

## Hva bør teamet ditt gjøre?

Fire konkrete punkter, i prioritert rekkefølge:

1. **Kartlegg rollen deres.** Bruker dere modeller via API, er dere deployer, og pliktene er håndterbare. Tilbyder-plikter oppstår først når dere setter eget navn på et høyrisiko-system eller endrer formålet dets vesentlig.
2. **Sjekk brukervendte AI-funksjoner.** Har produktet en chatbot eller genererer det innhold for brukere i EU, må merkingen være på plass til 2. august (eller 2. desember for systemer som allerede er ute).
3. **Hold agenter unna personalvurderinger.** Oppgavefordeling og prestasjonsevaluering av mennesker er høyrisiko fra desember 2027, og det er billigere å designe seg bort fra det nå enn å dokumentere seg ut av det senere.
4. **Vær skeptisk til skremselsmarkedsføring.** De tyngste fristene ble nettopp utsatt, ingen bøter er delt ut, og vanlige kodeverktøy står utenfor hele høyrisiko-regimet.

## Oppsummering

AI Act treffer utviklingsteam mykere enn overskriftene tilsier, og etter Digital Omnibus enda mykere: høyrisiko-regimet kommer først i desember 2027, og vanlige kodeverktøy står uansett utenfor. Det som gjelder fra 2. august, er transparens for brukervendte AI-funksjoner og et håndhevingsapparat som endelig skrus på. For norske team er den viktigste øvelsen å vite hvilken rolle man har, og å følge med på når forordningen tas inn i EØS-avtalen.

For ordens skyld: jeg er utvikler, ikke jurist, og dette innlegget er orientering, ikke juridisk rådgivning. Lovteksten etter Omnibus-endringene er i skrivende stund på vei inn i EUs offisielle tidsskrift (Official Journal, der EU-regelverk publiseres før det trer i kraft), så sjekk konsolidert tekst (lovteksten med alle endringer innarbeidet) før du tar beslutninger med juridiske konsekvenser.

## Ressurser

- [EU-kommisjonens offisielle tidslinje for AI Act](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act): Datoene fra primærkilden
- [Digital Omnibus i Europaparlamentets lovsporing](https://www.europarl.europa.eu/legislative-train/package-digital-package/file-digital-omnibus-on-ai): Status for endringspakken
- [Artikkel 50 forklart](https://artificialintelligenceact.eu/article/50/): Transparenskravene i detalj
- [Artikkel 99: Bøtenivåene](https://artificialintelligenceact.eu/article/99/): Sanksjonsregimet
- [Regjeringen: Høring av ny KI-lov](https://www.regjeringen.no/no/dokumenter/3112327/id3112327/): Norsk gjennomføring
- [kiforordning.no](https://kiforordning.no/ki-loven-norge/): Utviklervennlig norsk sporing av KI-loven
- [EU AI Act for utviklingsteam (Augment Code)](https://www.augmentcode.com/guides/eu-ai-act-2026): God gjennomgang av kodeassistent-spørsmålet


---

# Magnus gir agenter tilgang til SpareBank 1

Published: June 2026
Originally published at Kode24: https://www.kode24.no/artikkel/magnus-gir-agenter-tilgang-til-sparebank-1/266444

> Jeg skrev ingenting av koden for hånd. Jeg ga agenten kontekst, verktøy og én BankID-innlogging, og fikk en publisert Rust-CLI tilbake før lunsj.

![Magnus Rødseth sitter med laptopen og kobler nettbanken til en KI-agent](https://www.magnusrodseth.com/blog/agenter-tilgang-til-sparebank-1/banner.webp)
_Jeg kobla nettbanken min til en KI-agent for å slippe å gå gjennom økonomien min manuelt. Foto: Privat / kode24._

Jeg brukte en halvtime på oppsett. Halvannen til to timer senere lå det en publisert pakke på crates.io og et ferdig repo jeg bare kunne dele. Jeg skrev ingenting av koden for hånd selv.

Her er hva jeg mener det forteller om hvordan vi bygger programvare nå.

## Jeg hater å sjekke skattemeldingen min

Jeg ville samle hele privatøkonomien min på ett sted, og jeg ville sjekke at skattemeldingen faktisk stemte: at renter, inntekter og saldoer var riktig rapportert. Samtidig hadde jeg lyst til å la en AI-agent hjelpe meg med å optimalisere økonomien.

Problemet var at agenten ikke kunne se banktallene mine. Jeg måtte enten grave manuelt i nettbanken eller taste inn alt for hånd.

SpareBank 1 har et personlig bank-API for utviklere. Så det jeg egentlig trengte var en liten CLI som agenten kunne kjøre: hente kontoer og transaksjoner, og gjøre overføringer mellom mine egne kontoer.

![Terminalvindu som viser hjelpeteksten til sb1, med kommandoene login, accounts, transactions, transfer og summary](https://www.magnusrodseth.com/blog/agenter-tilgang-til-sparebank-1/sb1-help.webp)
_`sb1 help`: hele overflaten agenten har å forholde seg til. Skjermdump / Magnus Rødseth._

## Hvordan så eksperimentet ut?

Jeg vil gjerne dele hvordan arbeidsprosessen for å lage dette verktøyet var. Jeg skrev ikke koden selv. Jeg satte opp agenten, og lot den gjøre jobben.

I rundt 30 minutter ga jeg den alt jeg kunne tenke meg at den ville trenge:

- OpenAPI-spesifikasjonen til SpareBank 1, så agenten hadde fasiten på hvert eneste endepunkt.
- En [/playwriter-økt](https://github.com/remorses/playwriter) så den kunne navigere utviklerportalen i min egen nettleser, og `curl` for å teste kall mot ekte endepunkter.
- [/goal](https://code.claude.com/docs/en/goal), Claude Code sin innebygde måte å sette et mål og la agenten jobbe mot det i en sløyfe til det er nådd.
- `/find-docs` og context7 for å hente fram oppdatert dokumentasjon underveis i stedet for å gjette på API-er den var usikker på.
- [/tdd](https://skills.sh/mattpocock/skills/tdd), en skill som fikk agenten til å teste seg selv underveis.

Hele poenget var å gi den nok kontekst og nok verktøy til å jobbe i en sløyfe på egen hånd: skrive litt kode, teste den mot det ekte API-et, se hva som feilet, fikse det, og gjenta til alt virket ende-til-ende.

Så logget jeg inn med BankID én gang, og lot Claude Code jobbe i halvannen til to timer. Mens den holdt på, var jeg på jobb som vanlig, så dette tok veldig lite kognitiv last fra meg etter at jeg hadde tilrettelagt for agenten.

## Hva ble resultatet?

Det agenten kom tilbake med, heter **sb1**. En CLI skrevet i Rust.

En morsom observasjon underveis: Rust har ord på seg for å være vanskelig å komme i gang med for nye utviklere, med alle særegenhetene og det språkspesifikke. Den terskelen blir kraftig senket når du jobber med en agent, men bare hvis målet ditt er å få noe ferdig, og ikke å lære noe nytt du ikke kan eller forstår fra før.

Skal du faktisk lære deg et nytt språk, i dette tilfellet Rust, hopper denne måten å jobbe på over mange av de viktige stegene i læringen.

Vil du ha en grundigere teknisk gjennomgang, av BankID over OAuth 2.0, hvordan banktokenet lagres trygt, og hvordan verktøyet er bygget for å brukes av agenter, ligger alt i GitHub-repoet nederst i innlegget.

Slik ser en oversikt ut i terminalen. `--mask` skjuler beløp og kontonumre, nettopp for at man trygt skal kunne dele et skjermbilde som dette:

```text
$ sb1 summary --months 2 --mask
Financial summary  (2 month(s): 2026-04-24 → 2026-06-23)
Net worth
  NOK: kr *****
  assets kr *****   liabilities -kr *****
Cash flow (internal transfers excluded)
  income     kr *****
  spending  -kr *****
  net        kr *****
  savings rate: ***%
  monthly avg: in kr *****, out kr *****
```

![Søkeresultatet på skills.sh for magnusrodseth/sparebank1-cli, med skillene sparebank1-transfers, sparebank1-accounts og sparebank1-shared](https://www.magnusrodseth.com/blog/agenter-tilgang-til-sparebank-1/skills.webp)
_De tre SpareBank 1-skillene. Skjermdump / Magnus Rødseth._

Apropos "skills": jeg distribuerer dem gjennom [skills.sh](https://skills.sh), et åpent register for slike agent-ferdigheter. Har du en `skills/`-mappe i repoet ditt, kan hvem som helst hente dem inn i sin egen agent med én kommando:

```bash
npx skills add magnusrodseth/sparebank1-cli
```

Da får agenten deres de samme instruksjonene som min: hvordan logge inn, hvordan lese kontoer og transaksjoner, og hvordan gjøre overføringer på en trygg måte.

## Hva jeg faktisk har brukt den til

Jeg har selvfølgelig allerede tatt den i bruk i hverdagen.

Det morsomste eksempelet så langt: jeg ga agenten min tilgang både til `sb1` og til forbruket mitt fra REMA 1000 (jeg har en liknende CLI for det), og ba den gå gjennom alt jeg hadde brukt de siste 60 dagene og si fra om det var noe åpenbart å spare på.

Den kom tilbake med en full gjennomgang. Konklusjonen var rett og slett at jeg kanskje kunne trappe litt ned på antall øl jeg kjøper når jeg er ute på byen. Jaja, VM pågår jo, så jeg kan ikke la en agent bestemme hvor gøy jeg har det når Norge vinner kamper.

Litt flaut, men ærlig. Men det er liksom hele poenget med dette verktøyet: når økonomien er noe en agent kan resonnere over, slipper jeg å gjøre den kjedelige gjennomgangen selv.

## Hva sitter jeg igjen med?

Jeg vil ikke overselge denne måten å lage ny programvare på.

Agenten jobbet ikke helt alene. Jeg ga den konteksten, verktøyene og BankID-innloggingen, og jeg satt klar til å gripe inn hvis den gikk i feil retning. Kall det heller veiledet autonomi.

Men det er fortsatt et markant skifte i hvordan kode produseres og ny programvare distribueres. Jeg gikk fra idé til en publisert crate på crates.io og et repo klart til deling, fra jeg kom på jobb til jeg gikk til lunsj, uten å skrive koden for hånd.

Mesteparten av jobben min var å tenke klart om hva jeg ville ha, og å gi agenten nok til at den kunne teste seg selv.

For ordens skyld: `sb1` er et personlig og uoffisielt verktøy, ikke laget av eller tilknyttet SpareBank 1. Du registrerer din egen utvikler-app og bruker bare dine egne data, så det passer best for utviklere. Det er åpen kildekode og gratis.

- Kode: [github.com/magnusrodseth/sparebank1-cli](https://github.com/magnusrodseth/sparebank1-cli)
- Pakke: [crates.io/crates/sparebank1-cli](https://crates.io/crates/sparebank1-cli)


---

# Fra solo til team: Rigg arbeidsflyten for agenter som jobber i timevis

Published: June 2026
Originally published at Capra Consulting: https://capraconsulting.no/vare-historier/agenten-jobbet-alene-i-fire-timer-er-teamet-ditt-rigget-for-det

> Kodemodellene jobber nå i timevis av gangen. Da flytter jobben seg fra prompten til riggen rundt agenten, og den riggen hører hjemme i repoet, ikke på laptopen.

## Innledning

Den 9. juni 2026 slapp Anthropic [Fable 5](https://www.anthropic.com/news/claude-fable-5-mythos-5), en modell bygget for lange, sammenhengende oppgaver. Dette forsterker noe vi har sett nærme seg en stund: en agent kan nå jobbe selvstendig i timevis og komme tilbake med ferdig arbeid. En gren som bygger, tester grønt og venter på review, i stedet for et utkast du må reparere. Du gir den et mål, og den arbeider mot det på egen hånd.

Men når agenten kan løpe så langt på egen hånd, bommer de fleste av oss i én av to retninger. Den første er **autopilot**: overlat alt, godkjenn alt, og våkn opp tre uker senere i en kodebase ingen forstår. Den andre er **mikrostyring**: stol på ingenting, les hver diff linje for linje, og bli sittende som flaskehals i ditt eget verktøy.

![Editorial illustration, wide side-on composition. A single human figure in muted slate kneels in the foreground, laying and extending a clean railway track that stretches ahead toward a calm horizon. The track is already built behind the figure, where one small simple cart waits on the laid rails; it continues unbuilt ahead as the figure places the next section. Mood: calm, purposeful, building the way forward. Track in muted teal, the figure in soft slate, a single rust accent at the horizon as a low sun, warm cream background and sky. Flat editorial illustration with subtle paper grain texture, restrained detail and no fine line work, a single central concept, symbolic rather than literal, with generous negative space. No labels, no text, no signage inside the image. Wide 16:9 composition, magazine opinion-section feel like The Economist or New York Times opinion illustrations.](https://www.magnusrodseth.com/blog/fra-solo-til-team/laying-the-rails.webp)
_Du legger skinnene; agenten kjører på dem. Det er riggen. Kilde: OpenAI gpt-image-2._

Middelveien er verken mer tillit eller mer kontroll. Den handler om **design av utviklingsprosess**. Jo lenger agenten kan løpe på egen hånd, desto mer avhenger resultatet av miljøet den løper i, ikke av den enkelte prompten du skriver. Du rigger arbeidsflyten, koder prosessen inn som skills og regler, og lar agenten løpe på skinnene du har lagt. Det er det jeg kaller å rigge kodebasen din for suksess.

Og her ligger spenningen dette innlegget skal løse opp i. Nesten alle utviklere jeg snakker med har nå et personlig oppsett: en AGENTS.md her, et par skills der, en lokal vane for hvordan de prompter. Mange har også begynt å løfte deler av det til teamnivå, i ulik grad. Det er der dette innlegget kommer inn, som en sjekkliste for hvor langt oppsettet ditt faktisk rekker.

Dette innlegget er et personlig forsøk på å fortelle om skinnene: fra spec via rigg og byggesløyfe til review og parallellitet, og til slutt det viktigste steget, fra solo til team.

## Tommelfingerregelen som binder alt

Før vi bygger noe som helst, må vi forstå én grunnsetning. Alt annet i dette innlegget er konsekvenser av den.

> **Hands-off rekker nøyaktig så langt som agenten kan verifisere seg selv.**

Hvorfor? Fordi modellen som vurderer om arbeidet er ferdig, bare ser det som havner i samtalekontekst. Den ser ikke skjermen din (før det havner i kontekst), ikke intensjonen din, ikke det du "egentlig mente". Hvis testresultatet, typesjekken eller skjermbildet ikke finnes i konteksten, finnes det ikke for agenten.

Konsekvensen er at "ferdig" må være noe en maskin kan observere. En vag følelse som "brukeropplevelsen er bra" holder ikke alene, men det betyr ikke at opplevelse er umålbar. Definerer du akseptkriterier (acceptance criteria) for hva "bra" faktisk betyr, og gir agenten verktøy til å sjekke dem, for eksempel skjermbilder eller Playwright-snapshots i nettleseren, blir også det observerbart. "Føles bra" blir til "skjermbildet matcher designet og testene som dekker flyten passerer", og det kan en maskin faktisk verifisere.

![Editorial illustration. A single small figure rendered in muted teal stands at the center holding a lantern that casts a soft circular pool of warm light on the ground around them. Inside the circle everything is crisp and visible; right at the edge the light fades abruptly into flat darkness. The figure faces the boundary where the light stops, about to step toward it. Mood: contemplative, a quiet limit. Inside the light warm cream and a soft rust glow; beyond the edge deep muted slate. Flat editorial illustration with subtle paper grain texture, restrained detail and no fine line work, a single central concept, symbolic rather than literal, with generous negative space. No labels, no text, no other objects inside the image. Magazine opinion-section feel like The Economist or New York Times opinion illustrations.](https://www.magnusrodseth.com/blog/fra-solo-til-team/self-verification-boundary.webp)
_Hands-off rekker akkurat så langt som lyset. Agenten kan bare jobbe selvstendig der den ser sin egen suksess. Kilde: OpenAI gpt-image-2._

Alt som følger i dette innlegget kan leses som svar på ett spørsmål: hvordan flytter vi den grensen lenger ut? Spec-en gjør målet observerbart. Riggen gir agenten øyne og hender. Reviewsløyfen fanger det agenten ikke ser selv. Og teamsteget gjør at grensen flyttes for alle, ikke bare for deg.

## Spec-en: Start i den menneskelige enden

Det første skinnesporet legges før agenten i det hele tatt starter. En god oppgave er definert av verifiserbare **akseptkriterier (acceptance criteria)**: konkrete betingelser agenten selv kan sjekke, som "testene i `auth/` passerer og endepunktet returnerer 401 uten gyldig token". Hele disiplinen rundt dette dekket vi i [Spec-Driven Development](https://www.magnusrodseth.com/blog/spec-driven-development), så her nøyer jeg meg med det som er nytt.

### Press spec-en før koden

Min mest verdifulle vane er det jeg kaller **grill-me-fasen**: en egen modus der agenten nekter å skrive kode og i stedet intervjuer deg. Den stiller spørsmålene du ikke har tenkt på. Dette er noe annet enn å be agenten "still meg noen spørsmål". Claude Code har et innebygd "Ask User"-verktøy, men det er bare en primitiv for å stille et spørsmål. Grill-me er grundig og uttømmende: den jobber seg gjennom hele beslutningstreet og gir seg ikke før dere har en delt forståelse. Den kan gjerne bruke Ask User-verktøyet underveis, det er ikke enten eller, men i praksis sier jeg alltid "grill meg" heller enn "still meg spørsmål".

Ti minutter med grundige spørsmål før koding tvinger meg til å være mentalt påskrudd, og sparer timer med feilrettet arbeid etterpå. Det er billigere å finne hullene i spec-en mens den fortsatt er tekst. Den samme øvelsen er minst like nyttig sammen med teamet: bruk grillingen til å samkjøre dere om edge-casene før noen setter i gang med implementeringen.

### Hent oppgaven fra en issue, ikke fra chatten

En oppgave som bare finnes i en chat-melding er flyktig. Den forsvinner når kontekstvinduet komprimeres, og den kan ikke deles. Trekk i stedet oppgaven fra en issue i prosjektstyringsverktøyet ditt, enten det er GitHub Issues, Jira eller noe annet: der ligger kravene, diskusjonen og akseptkriteriene på ett varig, delbart sted. Agenten leser issuen, du leser den samme issuen, og "hva var det vi egentlig ble enige om?" har alltid et svar.

Gi agenten CLI-en til verktøyet, og "skillify" hvordan dere bruker det. Hos kunden jeg jobber for nå, har vi kodet inn som skills hvordan vi vil at issues skal opprettes, hvordan pull requests skrives, og hvordan en agent administrerer kanban-tavlen vår i GitHub Projects. Det samme lar seg gjøre i Jira; prinsippet er uavhengig av verktøy.

Gevinsten er delt kontekst. Spec, diskusjon, akseptkriterier og ferske funn dokumenteres som kommentarer på issuen, slik at hele teamet kan lese dem i sanntid og mate dem inn i sin egen agent. Tatt helt til det ekstreme: når designerne og forretningsutviklerne også har agenter koblet til de samme verktøyene, får de den samme rike konteksten som deg. Det er en fordel for hele teamet.

### Skills: "Slik gjør vi det her"

Skills er kodifisert prosess: små, navngitte instruksjonsfiler som beskriver hvordan en bestemt type oppgave skal gjøres i akkurat dette prosjektet.

Mekanismen som gjør dette levende er en skill kalt `/write-a-skill`, en av skillsene i [Matt Pococks skill-sett](https://github.com/mattpocock/skills) jeg bruker daglig. Tanken bak er at når du finner ut av noe, fikser du det ikke bare én gang. Du koder oppdagelsen inn som en skill, slik at den blir permanent for deg og resten av teamet.

En kort merknad: mange har hørt om Anthropics [Skill Creator](https://www.skills.sh/anthropics/skills/skill-creator), men færre kjenner Matt Pococks `/write-a-skill`. For meg er dette ren personlig preferanse, men Matt har bygget seg et godt rykte med skarpe, presise og konsise skills, og det smitter over på `write-a-skill`. Bruk gjerne den du selv foretrekker; begge gjør jobben.

I konteksten av skills er det dette som er den mentale modellen: **institusjonaliser arbeidsflyten du gjentar igjen og igjen**. Hold øye med hva du retter på agenten for, uke etter uke. Og vær oppmerksom på det du vet du kommer til å gjøre mange ganger: opprette en issue, kartlegge hvordan data flyter fra klient til server til database og tilbake, eller slå opp intern dokumentasjon i en enterprise-kontekst. Dette er gode kandidater for `write-a-skill`.

## Riggen agenten jobber i

Spec-en sier hvor agenten skal. Riggen avgjør om den kommer frem. En agent er aldri bedre enn miljøet den jobber i, og miljøet har fire lag.

![Editorial illustration. A single sturdy, orderly scaffold frame stands alone at the center, clean, geometric and structural, and completely empty inside. No figure, no person, no desk, no objects inside or around it. Mood: orderly, solid, a structure standing ready. The scaffold in muted teal with one small rust accent, on a warm cream background. Flat editorial illustration with subtle paper grain texture, restrained detail and no fine line work, a single central concept, symbolic rather than literal, with generous negative space. No labels, no text inside the image. Magazine opinion-section feel like The Economist or New York Times opinion illustrations.](https://www.magnusrodseth.com/blog/fra-solo-til-team/the-rig-scaffold.webp)
_Riggen er stillaset: strukturen som står klar før agenten setter i gang. Kilde: OpenAI gpt-image-2._

### Lag 1: Kodebase-rigging

Raske tester, tydelige scripts (`pnpm test`, `pnpm typecheck`, `pnpm lint`) og en god AGENTS.md som forklarer konvensjonene gir agenten en tilbakemeldingssløyfe den kan stole på.

Et nyansert poeng om tester: det er ingenting i veien for å ha et stort, grundig sett med enhetstester på tvers av hele kodebasen, tvert imot gir det en grad av trygghet. Det viktige er å fortelle agenten hvordan den kjører et relevant utvalg. Dersom hele testsuiten tar to minutter å kjøre og agenten endrer én fil i backend, holder det å kjøre testene som dekker akkurat den koden underveis, og la hele suiten kjøre i CI. Slik beholder du både rask iterasjon lokalt og full dekning på GitHub.

Et ord om AGENTS.md: du kan ha flere av dem, én i roten og egne i undermapper. Men ikke fyll den med alt. Dagens modeller er blitt veldig gode til å utforske en kodebase på egen hånd, så det agenten kan finne selv, bør du la den finne selv; det sparer tokens. Hold AGENTS.md slank, og bruk den til det agenten ikke enkelt kan slå opp ved å lese koden: hva er dette produktet, og hvorfor bygger vi det? Den slags kontekst hører hjemme der.

### Lag 2: Riktig tilgang og scopes

Prøv så godt du kan å gi agenten færrest mulig rettigheter (least privilege), altså akkurat de tilgangene oppgaven krever for å gjøre jobben. Dette er sikkerhetsarbeidet fra [Alle bruker AI-agenter. Hvem passer på sikkerheten?](https://www.magnusrodseth.com/blog/sikkerhet-i-agentenes-tidsalder), anvendt på riggen.

Samtidig bør ikke agenten møte stadige hindre der den må stoppe og be om tilgang. Det dreper hele poenget med langløpende agenter. Husk at disse modellene i stor grad er trent til å være handlekraftige; med godt definerte mål, og tydelige kriterier for hva den ikke skal gjøre, følger de føringene dine godt. Du kan aldri være helt sikker, men det er en god tommelfingerregel.

### Lag 3: Hooks og path-baserte regler som håndhevelse

Hooks er håndhevelse. Et hook er en kommando som kjører automatisk på en hendelse: etter hver filendring, før en commit, eller når et bestemt verktøy kalles. Endrer agenten en komponent under `frontend/ui/`, kan et hook kjøre formattering og lint på den med en gang. Mangler en commit tester, kan et hook stoppe den. Reglene håndheves av maskinen, ikke av agentens hukommelse.

Path-baserte regler tar dette videre på instruksjonssiden. Med `.claude/rules/` legger du instruksjoner i egne filer som bare lastes inn når agenten jobber med filer som matcher et mønster. En regel scopet til backend-API-et dukker bare opp når agenten åpner en fil der, og fyller ikke kontekstvinduet resten av tiden:

```markdown
---
paths:
  - "apps/backend/api/**/*.ts"
---

# Regler for API-laget

- Alle endepunkter validerer input.
- Bruk standard feilresponsformat.
- All datatilgang går gjennom repository-laget, aldri rå SQL i handlers.
```

Poenget er at konvensjonene møter agenten akkurat når de er relevante. En frontend-regel trigger på frontend-filer, en API-regel på API-filer, og agenten kan ikke trampe ned arkitekturen i et hjørne av kodebasen den sjelden ser. Du kan lese mer i [Claudes dokumentasjon om rules](https://code.claude.com/docs/en/memory#organize-rules-with-claude/rules/).

Disse mekanismene har sin plass, men det er ikke åpenbart at du trenger dem fra dag én. Start enkelt, og legg til håndhevelse først der du faktisk ser agenten gjøre samme feil om igjen.

### Lag 4: MCP-er og CLI-er som øyne og hender

Jeg holder oppsettet mitt ganske lite og enkelt. Her er MCP-ene og CLI-ene jeg bruker hver dag, ment som et utgangspunkt: de nødvendige byggeklossene de fleste som vil jobbe agentisk bør kjenne til og vurdere mot egen arbeidsmåte.

- **[Context7](https://github.com/upstash/context7)** gir ferske docs, slik at agenten ikke koder mot et API som ble endret etter treningsdataene.
- **[Exa](https://exa.ai/docs/reference/exa-mcp)** gir websøk, slik at agenten kan slå opp ting på det åpne nettet i stedet for å gjette.
- **[grep.app](https://github.com/ai-tools-all/grep_app_mcp)** søker i ekte kode på tvers av offentlige repoer, så agenten kan se hvordan et API faktisk brukes i praksis. Her kan man eventuelt lage seg en skill for å klone et GitHub-repository ned i `/tmp` på maskinen sin for å utforske det, smak og behag.
- **[Figma](https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Figma-MCP-server)** gir designets fasit, slik at "lik designet" blir noe agenten kan slå opp i stedet for å gjette.
- **[Playwright](https://github.com/microsoft/playwright-cli)** lar agenten se sin egen UI: navigere, klikke og ta skjermbilder av det den nettopp bygde. For applikasjoner som krever innlogging (interne dashboards etc.) er det viktig å bake inn hvordan man logger inn med en testbruker i skillen som beskriver hvordan man bruker `playwright-cli` i prosjektet ditt.

Et viktig poeng kobler dette tilbake til skills: en skill er oppskriften som beskriver *hvordan* du bruker en MCP eller CLI, så agenten ikke trenger å lære det på nytt hver gang. Ta det å opprette en GitHub-issue. Du har enten GitHub-MCP-en eller GitHub-CLI-en, men måten *dere* oppretter, oppdaterer og lukker issues på, koder du inn som en skill. Da gjør agenten det likt hver gang, uten at du må forklare verktøyet på nytt.

Legg merke til mønsteret: alle disse flytter verifiseringsgrensen fra loven over. Med Playwright i riggen blir "knappen er synlig og klikkbar" observerbart av en maskin.

### Sandboxing

Isolasjon kommer i trinn, og du trenger sjelden alle. **Git worktree** løser isolasjon på fil-laget: hver agent får sin egen arbeidskopi av repoet, så to agenter aldri skriver i samme fil. **Docker** løser isolasjon ved kjøretid: egen prosess, eget filsystem, eget nettverk.

Og her møter du fort et problem, nemlig portkonflikter. Fem parallelle agenter med hver sin dev-server vil alle ha port 3000. Et verktøy som løser nettopp dette er [portless](https://github.com/vercel-labs/portless) fra Vercel. I stedet for at du sjonglerer portnumre, gir det hver app en stabil adresse som `myapp.localhost`, og en lokal proxy ruter trafikken til riktig prosess bak kulissene.

Selve verktøyet er mindre viktig enn prinsippet det illustrerer: alt som kan kollidere mellom parallelle agenter, må håndteres på forhånd. Porten er bare et håndfast eksempel.

## Byggesløyfa

Med spec og rigg på plass kan vi endelig slippe agenten løs, på ordentlig. Sløyfen ser slik ut: agenten implementerer, kjører testene, leser feilene, retter, og gjentar til fullføringsbetingelsen fra issuen din er observert oppfylt i konteksten.

De fleste ganger trenger du ikke mer seremoni enn å peke på en godt spesifisert issue. Lim inn URL-en, og hele oppgaven, krav, diskusjon og akseptkriterier, lastes inn i konteksten agenten jobber mot. Da er det ofte nok å si "implementer denne".

`/goal` hører hjemme i det tøffere tilfellet: et underspesifisert mål, der du vil at agenten selv trekker opp en verifiserbar fullføringsbetingelse før den begynner, kjører i auto-modus og verifiserer seg selv hele veien. Det er power-user-varianten.

![Editorial illustration, wide composition. A single continuous looping rail, like a closed toy-train track, forms one clean even oval on a flat surface. One small simple cart sits on the track, aligned along the rail. At one point the loop has a small open gate where the track could exit outward into open space. Nothing else: no fence, no enclosure, no surrounding rails, no other objects. Mood: controlled, patient momentum within bounds. Track and cart in muted teal, one rust accent on the gate, warm cream background. Flat editorial illustration with subtle paper grain texture, restrained detail and no fine line work, a single central concept, symbolic rather than literal, with generous negative space. No labels, no text, no numbers inside the image. Wide 16:9 composition, magazine opinion-section feel like The Economist or New York Times opinion illustrations.](https://www.magnusrodseth.com/blog/fra-solo-til-team/build-loop-guardrails.webp)
_Byggesløyfa med rekkverk. Agenten går runde på runde mot målet, innenfor harde grenser, med én vei ut. Kilde: OpenAI gpt-image-2._

For det repetitive finnes `/loop`: samme oppgave anvendt på mange tilfeller, som eksempelvis "migrér én og én komponent til det nye designsystemet, kjør testene mellom hver". Kjedelig for et menneske, perfekt for en agent med riktig rigg rundt seg.

## Adversarial review: Modellen som skrev koden, ser ikke sine egne feil

Modellen som skrev koden er for tett på den til å se sine egne feil. Den vil bekrefte sine egne antagelser, akkurat som vi gjør når vi korrekturleser vår egen tekst.

Løsningen er "adversarial review": en egen review-agent med ett oppdrag, å finne feil i arbeidet.

![Editorial illustration, symmetric composition. A single sheet of paper stands upright at the exact center of the frame. Two identical magnifying glasses approach it from opposite sides, left and right, each examining the same sheet from its own angle, mirror images of each other but in two different colours to suggest different origins. Mood: rigorous scrutiny, balanced tension. One magnifying glass muted teal, the other rust; the paper soft slate-grey on a warm cream background. Flat editorial illustration with subtle paper grain texture, restrained detail and no fine line work, a single central concept, symbolic rather than literal, with generous negative space. No labels, no text on the paper. Magazine opinion-section feel like The Economist or New York Times opinion illustrations.](https://www.magnusrodseth.com/blog/fra-solo-til-team/adversarial-review-loop.webp)
_Adversarial review. Samme arbeid gransket fra to uavhengige hold, og begge må si ja før et menneske merger. Kilde: OpenAI gpt-image-2._

Tre regler gjør sløyfen effektiv:

1. **Separate kontekstvinduer.** Revieweren skal ikke arve forfatterens antagelser. Den leser diffen og spec-en med blanke ark.
2. **Helst ulike leverandører.** Tanken er at to modeller fra samme leverandør kan dele blindsoner, fordi de er trent på liknende data med liknende metoder. En reviewer fra en annen modellfamilie ser i det minste med andre øyne. Du kan for eksempel kode med en Claude-modell og la en GPT-modell ta reviewen, eller la både en GPT-modell og en Claude-modell med fersk kontekst gjennomgå arbeidet.
3. **N runder, begge må godkjenne.** Forfatteren retter, revieweren ser på nytt. Ingenting shippes før begge sier ja.

Det kan også lønne seg å kjøre sløyfen flere ganger. Én review-runde har en blindsone, akkurat som én testkjøring av et ikke-deterministisk system sier lite. To eller tre uavhengige gjennomganger kan fange merkbart mer.

Selve sløyfen kan du i tillegg gjøre om til en skill, eller "skillifye", som jeg stadig oftere finner meg selv i å si. Claude shipper en `/loop`-skill som kjører en kommando om og om igjen, og samme idé lar deg bygge en loop som går gjennom reviewerens anbefalinger og adresserer, forkaster eller implementerer hver enkelt, før et menneske i det hele tatt ser på det. Revieweren kan være Claude i CI, [Greptile](https://www.greptile.com/), [GitHub Copilot](https://github.com/features/copilot) i CI, eller noe helt annet. Da blir den første review-runden enda mer autonom. For å være ærlig er dette et utpreget power-user-tilfelle, og passer ikke nødvendigvis enhver arbeidsflyt eller enhver oppgave, men det kan være lurt å være klar over at det er mulig.

Men det finnes en grense reviewen aldri kan flytte:

> Reviewsløyfen fanger **implementasjonsfeil**, ikke **kravfeil**. Hvis spec-en er gal, vil to agenter i skjønn enighet bygge feil ting, grundig verifisert.

Det er derfor innlegget startet i den menneskelige enden. Ingen mengde automatisert review redder en dårlig spec. Din viktigste jobb ligger før koden.

## Parallellitet og verktøy

Når én agent på skinner fungerer, er fristelsen å kjøre flere på en gang. Det går fint, men med noen klare begrensninger du må kjenne til.

**Kjernen er git worktrees.** [Conductor](https://www.conductor.build/), [cmux](https://github.com/manaflow-ai/cmux) og [OpenCode Workspaces](https://opencode.ai/) er alle praktiske innpakninger rundt det samme primitivet: én git worktree per agent, hver med sin egen arbeidskopi av repoet. Det er worktreet som gjør parallelliteten mulig; verktøyene gir deg bare et hyggeligere grensesnitt mot det.

**Taket er fortsatt deg.** Erfaringsmessig klarer du å holde styr på 2-4 parallelle agenter før *du* blir flaskehalsen i review. Hver agent produserer arbeid som fortjener et kritisk blikk, og blikket ditt skalerer ikke. Mer parallellitet uten mer review-kapasitet er bare en raskere vei ned i autopilot-grøfta.

Under lokal utvikling er det noen ting som er særlig viktig å være bevisst på før du parallelliserer dem:

- **Lockfiler** (`pnpm-lock.yaml` og venner): parallelt arbeid som endrer avhengigheter samtidig, gir konflikter i selve lockfilen.
- **Databasemigrasjoner** forutsetter at hver git worktree kan kjøre sin egen database. Gjør de det, vil parallelle migrasjoner lett kollidere i migrasjonshistorikken, noe du må rydde opp i ved PR- eller review-tid.
- **Store typerefaktoreringer** treffer hele kodebasen og danner bølger gjennom alt. Ikke alt må parallelliseres; noen oppgaver passer rett og slett bedre sekvensielt. Skal du gjøre en stor refaktorering med ringvirkninger overalt, er det ofte best å la den stå alene heller enn å kjøre annet arbeid oppå den samtidig.

Og den siste grensen, uansett hvor mange agenter du kjører: **alt stopper ved PR-en**. Aldri auto-merge. Agenten åpner pull requesten; et menneske trykker på knappen. Den menneskelige godkjenningen er kontrollpunktet som gjør resten av autonomien forsvarlig.

## Avslutning

Det er her alt vi har bygget skal knyttes sammen. Riggen for AI-agentene, AGENTS.md, skills, MCP-konfigurasjon og egne agent-definisjoner, hører til i versjonskontroll, ikke bare på din egen maskin. Det er det som gjør den tilgjengelig for resten av teamet: den ene som finner ut noe smart, deler det med en commit, og dagen etter gjør agentene hos alle utviklere det på samme måte.

```text
repo/
├── AGENTS.md              # Konvensjoner, arkitektur, hva og hvorfor vi bygger
├── .mcp.json              # MCP- og verktøyoppsett
└── .claude/
    ├── agents/            # Egne agent-definisjoner
    └── skills/            # Oppskrifter, ett domene per skill
```

![Editorial illustration, wide composition. A single open book lies flat at the center of the frame. From it several clean parallel rails radiate straight outward in different directions across the surface. At the end of each rail sits one small simple cart, and each cart is oriented along its own rail, pointing outward away from the book, so every cart runs in line with the direction of its track; no cart sits sideways or perpendicular to its rail. Balanced and radial, emphasizing one shared origin feeding many. Mood: collective, a shared foundation. Rails in muted teal, carts in soft slate, one rust accent on the central book, warm cream background. Flat editorial illustration with subtle paper grain texture, restrained detail and no fine line work, symbolic rather than literal, with generous negative space. No labels, no text inside the image. Wide 16:9 composition, magazine opinion-section feel like The Economist or New York Times opinion illustrations.](https://www.magnusrodseth.com/blog/fra-solo-til-team/commit-the-rig.webp)
_Commit riggen. Når oppsettet flytter fra laptopen til repoet, løper hele teamet på de samme skinnene. Kilde: OpenAI gpt-image-2._

Verken autopilot eller mikrostyring, altså. Men ingeniøren som går fra å legge hver stein selv til å designe skinnene agenten løper på, koder prosessen inn som skills og regler, og lar agenten løpe.

Retningen videre er tydelig: mer parallellitet, lengre kjøringer, "fabrikker av agenter". Men jo mer av *hvordan* som automatiseres, desto mer verdifullt blir det som ikke flytter seg: menneskelig dømmekraft over *hva* som skal bygges, og *hvorfor* det skal bygges.

Det bringer oss tilbake til der vi startet. Når agentene kan løpe så langt på egen hånd, er det ikke nok å gi dem en god prompt; vi må rigge både kodebasene og måten vi jobber på rundt dem, uten å gi slipp på verifisering, akseptkriterier, testing og menneskelig smak. Dette innlegget har vært mitt forsøk på å destillere hvordan jeg selv jobber, alene og i team, i hobbyprosjekter og i enterprise, ned til en slags sjekkliste. Les den gjerne med en penn i hånden: kryss av det du allerede gjør godt, og finn det ene stedet, lite eller stort, der du eller teamet ditt kan ta neste steg.

## Ressurser

- [Spec-Driven Development](https://www.magnusrodseth.com/blog/spec-driven-development) -- Hvordan skrive krav som agenter faktisk forstår
- Agentic Mindset -- Fra skriver til dirigent
- Context Engineering -- Konteksthygiene og den smarte sonen
- Den AI-native utvikleren -- Fra Conductor til Orchestrator
- [Alle bruker AI-agenter. Hvem passer på sikkerheten?](https://www.magnusrodseth.com/blog/sikkerhet-i-agentenes-tidsalder) -- Sandboxing, scopes og secrets
- [Testing og evaluering av agenter](https://www.magnusrodseth.com/blog/testing-og-evaluering-av-agenter) -- Evaluatoren ser bare transkriptet

### Verktøy og kilder

- [Claude Fable 5 og Mythos 5](https://www.anthropic.com/news/claude-fable-5-mythos-5) -- Anthropics lansering av Fable 5, 9. juni 2026
- [Matt Pococks skills](https://github.com/mattpocock/skills) -- Skill-settet med blant annet `/write-a-skill`
- [Claude Code: organiser regler med `.claude/rules/`](https://code.claude.com/docs/en/memory#organize-rules-with-claude/rules/) -- Path-baserte regler i kontekst
- [Context7](https://github.com/upstash/context7) -- Ferske docs som MCP
- [Exa](https://exa.ai/docs/reference/exa-mcp) -- Websøk som MCP
- [grep.app MCP](https://github.com/ai-tools-all/grep_app_mcp) -- Kodesøk på tvers av offentlige repoer
- [Figma MCP](https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Figma-MCP-server) -- Designets fasit som MCP
- [Playwright CLI](https://github.com/microsoft/playwright-cli) -- Token-effektiv UI-automatisering for agenter
- [portless](https://github.com/vercel-labs/portless) -- Stabile lokale adresser uten portkollisjon (Vercel Labs)
- [Conductor](https://www.conductor.build/) -- Parallelle agenter i git worktrees på Mac
- [cmux](https://github.com/manaflow-ai/cmux) -- Terminal for parallelle kodeagenter
- [OpenCode](https://opencode.ai/) -- Åpen kildekode-agent for terminalen
- [Greptile](https://www.greptile.com/) -- AI-kodegjennomgang med full kodebasekontekst


---

# Første dose er gratis: Refleksjoner om token-økonomien

Published: June 2026
Originally published at Capra Consulting: https://capraconsulting.no/vare-historier/forste-dose-er-gratis-refleksjoner-om-token-okonomien

> AI-kodeprisene har skiftet og synliggjort hva inferens egentlig koster. Det relevante spørsmålet er ikke hvordan du kutter token-forbruket, men hvordan du får mer ut av tokenene du bruker.

![Et iskremstativ med skiltet "FØRSTE GRATIS"](https://www.magnusrodseth.com/blog/forste-dose-er-gratis/banner.jpeg)
_Den første dosen er alltid på huset. Resten betaler vi for. Kilde: OpenAI gpt-image-2._

## Innledning

I mai 2026 brant et stort norsk selskap gjennom sitt månedlige GitHub Copilot-budsjett mye raskere enn ventet. Jo flere kolleger jeg snakker med, desto oftere hører jeg lignende historier. Mønsteret går igjen, og det kommer bare til å bli mer utbredt.

Tre ting har skjedd samtidig denne våren. [GitHub Copilot legger om til forbruksbasert prising](https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/) 1. juni 2026. [Claude Opus 4.7 har blitt langt dyrere å bruke på Copilot](https://www.mindstudio.ai/blog/github-copilot-new-multiplier-table-price-hikes) på to måneder: hver forespørsel telles nå som 27 vanlige forespørsler mot kvoten din, mot 7,5 ved lansering. [Anthropic har samtidig endret tokenizeren](https://www.finout.io/blog/claude-opus-4.7-pricing-the-real-cost-story-behind-the-unchanged-price-tag) slik at samme input kan bli opptil 35% flere tokens, uten å endre listeprisen. De tre punktene forsterker hverandre.

For utviklere som har bygd agentiske arbeidsflyter inn i hverdagen, betyr dette at den marginale kostnaden ved hver beslutning du delegerer til en agent, har gått fra "neglisjerbar" til "noe _noen_ følger med på". Det er en synliggjøring av hva inferens (det å la en modell kjøre og produsere et svar) faktisk koster, og en kvittering for vanene vi rakk å bygge oss mens prisen var lav.

Dette innlegget handler om hvordan jeg tenker på den nye token-økonomien, ikke som et kostnadsspørsmål, men som et spørsmål om hvor mange velinformerte valg og parallelle hypoteser teamet ditt får ut av tokenene det bruker, forutsatt at teamet er rigget for å bruke dem godt. Linsen er bevisst smal: jeg velger her å skrive om de konkrete grepene utviklere _selv_ kan ta i sin daglige praksis.

## Hva er en token?

Hopp videre om du vet det. En token er ikke et ord eller et tegn, men en underordsbit modellen leser: vanlige ord blir gjerne ett token, sjeldne ord splittes i flere. Det er disse bitene du faktureres for.

Tre nyanser er verdt å ta med inn i resten av innlegget. Input-tokens (det du sender inn) og output-tokens (det modellen genererer) [prises ulikt](https://www.finout.io/blog/anthropic-api-pricing), og output koster typisk rundt fem ganger så mye som input. Det er en stor del av forklaringen på hvorfor verktøy som komprimerer modellens svar har konkret økonomisk verdi. [Reasoning-tokens](https://tokenmix.ai/blog/thinking-tokens-billing-trap-2026), altså modellens skjulte tankerekker når den jobber i resonneringsmodus, faktureres som output-tokens hos både OpenAI og Anthropic, selv om de ikke vises i svaret du leser. Og hver leverandør har sin egen tokenizer, slik at samme tekst kan bli ulikt antall tokens hos Anthropic, OpenAI og Google. Det er nettopp den mekanikken Anthropic justerte i Opus 4.7 og fikk ca. 35% effektiv prisøkning uten å røre listeprisen.

Norsk havner forøvrig rundt [1,7–1,9 tokens per ord](https://arxiv.org/html/2605.24718), mot engelsk på ca. 1,2. En liten språkskatt, ikke en stor, men verdt å vite om når du regner på forbruket.

## Det skjer overalt, ikke bare hos oss

Historien om selskapet som går tom for tokens før måneden er over er en av mange. [Microsoft kansellerte sine Claude Code-lisenser](https://fortune.com/2026/05/22/microsoft-ai-cost-problem-tokens-agents/) i Experiences and Devices-divisjonen seks måneder etter pilotering, og dirigerer ansatte over på Copilot CLI innen 30. juni 2026. [Uber sin CTO](https://www.tomshardware.com/tech-industry/artificial-intelligence/ai-cost-crisis-hits-tech-giants-as-employee-tokenmaxxing-backfires-agentic-ai-eats-up-to-1000x-more-tokens-than-standard-ai-sparks-corporate-pullback-at-microsoft-meta-and-amazon) forteller at selskapet brant gjennom hele sitt AI-budsjett for 2026 på fire måneder. Goldman Sachs anslår 24x vekst i samlet token-konsum innen 2030, drevet av agentiske systemer som bruker opptil 1000x flere tokens per oppgave enn en standard LLM-forespørsel.

Pris per token faller, mens samlet forbruk eksploderer. Det er ingen motsetning. Agenter er vesentlig dyrere å kjøre enn en chat som varer i noen få samtalerunder.

![Et isfjell der den synlige toppen er bitteliten mot den enorme massen under vann](https://www.magnusrodseth.com/blog/forste-dose-er-gratis/pris-vs-forbruk.webp)
_Det synlige prisfallet er bare toppen. Forbruksveksten under overflaten er den som styrer regningen. Kilde: OpenAI gpt-image-2._

I det norske selskapet jeg nevnte innledningsvis ble ekstra budsjett lagt til og brukt opp samme dag, ifølge intern kommunikasjon. Ledelsen innførte derfor en månedlig cap per lisensiert bruker inntil videre. En ansatt påpekte at beløpet var altfor lavt, at de ville gå tomme innen midten av måneden selv om folk var bevisste på token-bruken, og at et realistisk budsjett lå nærmere fire til fem ganger høyere. Hva er poenget med å fortelle deg dette, tenker du kanskje?

Det nye er ikke at ledelsen har en mening om hva verktøyene koster; sky-budsjetter, lisenstak og kvoter på infrastruktur har lenge vært en del av utviklerhverdagen. Det nye er _granulariteten_: nå handler det i større grad om den enkelte utviklerens prompting-vaner i nær sanntid. Den dynamikken kan i verste fall bremse utviklingshastigheten, ikke øke den. Og utviklere som har valget, kan begynne å se seg rundt etter andre arbeidsplasser.

## Den første dosen er alltid på huset

Det første halvannet året med moderne agentisk koding har vært kraftig subsidiert, men subsidien er ulikt fordelt, og det er verdt å være presis på hvordan. Anthropic og OpenAI priser fortsatt sine egne førstepartsprodukter (Claude Code via Claude-abonnementet, Codex via ChatGPT-abonnementet) et godt stykke under det reelle inferensregnskapet. Det er ikke et mysterium hvorfor: markedet skulle vinnes, vanene skulle etableres, byttekostnaden skulle bygges opp.

Tredjepartsverktøy som GitHub Copilot lever derimot oppå API-endepunktene til de samme labene, og API-prisene ligger vesentlig høyere enn det en sluttbruker betaler i et førstepartsabonnement. Når Anthropic justerer API-prisen sin på Opus 4.7 eller endrer tokenizeren, slår det rett inn i kostnaden GitHub må videresende til lisenskunden sin. Det er hovedforklaringen på hvorfor det er organisasjonene som bruker Copilot-lisenser som først merker at regningen kommer, mens utviklere som jobber direkte på en Claude- eller ChatGPT-konto foreløpig sitter i den subsidierte gangen.

Den asymmetrien blir neppe varig: før eller siden må også førstepartsproduktene reflektere reell inferenskostnad. Men akkurat nå er valg av plattform en av de største enkeltfaktorene for hva tokens faktisk koster deg.

## Spør om verdi, ikke kostnad

Maxim Salnikov hos Microsoft skrev nylig en [guide](https://www.linkedin.com/pulse/practitioners-guide-getting-more-value-out-ai-coding-agent-salnikov-mhume/) som setter dette i en presis ramme. Hans poeng er at spørsmålet de fleste team stiller seg nå, "Hvordan kutter vi token-forbruket?", er feil spørsmål. Det riktige spørsmålet er: "Hvordan får vi mer ut av tokenene vi bruker?"

Et team som jakter på lavest mulig token-forbruk, optimaliserer mot en kostnadslinje. Den optimaliseringen har et nullpunkt, nemlig at den billigste prompten er den du aldri sender. Et team som jakter på høyest mulig avkastning per token, har ikke det samme nullpunktet; du må faktisk bruke tokens for å produsere noe. Det kan høres ut som to fremstillinger av samme problem, men de drar adferden i ulike retninger. Det første resulterer i en gnien token-kultur, der utviklere føler skyld for å bruke verktøyene, velger en svakere modell enn oppgaven fortjener, og kutter kontekst som kanskje var nødvendig for å løse problemet. Det andre oppfordrer til disiplin: bedre prompts, klokere modellvalg per oppgave, reflekterte tanker rundt kontekst, bedre verktøykasse for utviklerne.

Salnikovs sentrale påstand er at "agent gambling", altså å kaste en lat og tvetydig prompt mot en dyr modell og prøve igjen om det feiler, var en levedyktig strategi når tokens var tilnærmet gratis, men den slutter å være det i det øyeblikket den marginale kostnaden synliggjøres. Den løses ikke ved å gamble _mindre_, men ved at hvert agent-kall lander mer presist.

## Konkrete grep

Med grunnlaget på plass har jeg noen konkrete råd. De henvender seg særlig til deg som kjenner på at kontekstvinduet ikke alltid strekker til, eller som stadig føler at du må optimalisere for token-bruk.

### Dominoeffekten i en agentisk flyt

Det er en mekanikk i agentiske flyter som mange team ikke tenker over. Hvert steg en agent tar bærer en liten sjanse for å gå feil, og fordi stegene bygger på hverandre, legger ikke den risikoen seg sammen, den ganges. Jo lengre kjeden er, desto større er den samlede sjansen for at noe glipper underveis. En agent som løser ti steg upåklagelig, kan fortsatt rote seg bort på steg førti, og da arver alt som kommer etterpå feilen.

En nyttig måte å se det på er at hver modell har en horisont: en oppgavelengde der den fortsatt holder kvaliteten oppe, og et punkt forbi der påliteligheten faller bratt. [METR måler nettopp dette](https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/), altså hvor lange oppgaver en agent klarer før treffsikkerheten ryker, og finner at horisonten har doblet seg omtrent hver syvende måned. Det er ingen tilfeldighet: lange, sammenhengende agentiske oppgaver er nettopp aksen frontier-labbene konkurrerer på nå.

Her ligger også svaret på hvorfor man ikke bare kan "ha en billigere agent". Forbedringene konsentreres i toppmodellene, og avstanden mellom en dyr og en billig agent vokser nettopp langs denne horisonten. En billigere modell betyr derfor ikke bare litt lavere kvalitet per kall; den har en kortere horisont og treffer pålitelighetsstupet tidligere på akkurat den samme oppgaven. Og hver kjøring som detter utfor koster nye tokens i tillegg til menneskelig tid for å rydde opp. Det er her prinsippet om å avdekke feil tidlig, kjent fra testing og sikkerhet, blir avgjørende når du setter sammen agentiske flyter, et poeng jeg kommer tilbake til lenger ned.

![En rad dominobrikker som detter, der den siste brikken så vidt står igjen](https://www.magnusrodseth.com/blog/forste-dose-er-gratis/komposisjonsfeil.webp)
_Risikoen ganges, den legger seg ikke sammen. Jo lengre kjeden, desto før treffer en svak modell pålitelighetsstupet. Kilde: OpenAI gpt-image-2._

### De to største spakene

Av alle optimaliseringer er to mer betydningsfulle enn alle andre kombinert:

1. **Modellvalg.** Kostnadsgapet mellom Opus 4.7 og GPT-5.4 mini er omtrent 24x. Å velge riktig modell til oppgaven er derfor den enkleste store spaken du har å skru på. Reasoning-modeller som Opus 4.7 og GPT-5.5 hører hjemme der det å tenke nøye gjennom problemet er hele poenget: planlegging, arkitektur, debugging og oppgaver som spenner over store kontekstvinduer. Mid-tier-modellene Sonnet og GPT-5.4 er sterke valg for asynkron implementasjon, der du gjerne kjører flere agenter i parallell på en velkonstruert spec. Low-tier-modeller som Haiku og GPT-mini holder fint til små refaktoreringer, mekaniske endringer og dokumentasjonsoppdateringer. En reasoning-modell på en triviell oppgave er sjelden bare dyrere; den er også betydelig tregere, og bruker reasoning-tokens som ikke gjør svaret målbart bedre i en situasjon som ikke krevde noen tung resonnering i utgangspunktet.

2. **Relevant kontekst.** Send så lite kontekst som mulig, men så mye som nødvendig. For mye kontekst drar modellen mot irrelevante mønstre og svekker signalet. For lite tvinger modellen til å gjette. Det rette balansepunktet krever bevisst valg av hva du sender med, ikke en refleks om å kaste inn alt.

Konteksten råtner også over tid. Når kontekstvinduet fylles opp forbi halvparten, begynner modellen å vektlegge de siste meldingene på bekostning av systemprompten og de opprinnelige instruksjonene dine. Slik er modellen trent. Konsekvensen er at agenten gradvis glir bort fra målet du definerte i starten, uten at noen varsler deg om det.

En `/clear` for hver ny oppgave er derfor ofte bedre enn å kompaktere konteksten. Kompaktering frigjør plass ved å oppsummere samtalen, men tapet av mellomliggende resonnement og nyanser er reelt. En ren ny oppstart med et nøyaktig formulert mål er som regel både billigere og mer presist.

### Det jeg selv har endret

I praksis betyr dette at jeg nylig har gjort to håndfaste endringer.

For det første har jeg blitt en mer aktiv bruker av OpenAI-modellene. Jeg var tidligere nesten utelukkende på Anthropic. GPT-5.4 og GPT-5.5 har imponert nok til å bli en fast rotasjon inn i min workflow, særlig for oppgaver der jeg verdsetter forutsigbar instruksjonsfølging fremfor brainstorming og sparringssesjoner.

For det andre har jeg eksperimentert mer med reasoning-nivåer. GPT-5.5 på lav reasoning er en kostbar modell brukt billig, men i implementasjonsfasen, der jeg allerede har en nøye definert spec og bare trenger velkonstruerte små endringer, gir det høyere utviklingshastighet uten å ofre den delen av modellens kapasitet jeg faktisk trenger.

### Input-siden og output-siden

Så langt har vi snakket om atferdsendringer: hvordan du velger modell, strukturerer kontekst og organiserer arbeidsflyten. Men det finnes også verktøy som sparer tokens uten at du trenger å endre måten du jobber på. To av dem fortjener omtale fordi de illustrerer to ulike retninger av samme problem.

**[rtk](https://github.com/rtk-ai/rtk)** ("Rust Token Killer") sitter mellom agentens Bash-verktøy og selve shell-kommandoen. Den filtrerer og komprimerer output før den treffer kontekstvinduet. `git status` blir `rtk git status` via en pre-tool hook, og agenten merker ingenting.

Mine egne tall etter ca. 164 000 kommandoer på fem uker: 29,6 millioner tokens spart, 85% effektivitet. Den varige gevinsten kommer fra hverdagslige mønstre: `curl`-kall som henter store assets, `ps aux`, `gh pr diff` og fillesing via `rtk read`. Det er den typen støy som stille akkumulerer i kontekstvinduet uten at du legger merke til det.

**[caveman](https://github.com/JuliusBrussee/caveman)** er den filosofiske motsatsen: en agent-skill som instruerer modellen til å komprimere sin egen output, omtrent som å snakke som en huleboer. Forfatteren rapporterer ca. 65% reduksjon i output-tokens på tvers av et benchmark-sett, men med et viktig forbehold: caveman påvirker bare output-tokens, ikke reasoning-tokens. Jeg bruker den ikke aktivt selv, men jeg tar den med fordi den illustrerer output-siden av disse mekaniske endringene man kan gjøre i arbeidsflyten sin. Par-tankegangen er nyttig: rtk sier "ikke send unødvendig tekst inn", caveman sier "ikke generer unødvendig tekst ut".

### Deterministiske hjelpemidler

Hver test, linter, type-sjekker og sikkerhetssjekk som koden må passere er et deterministisk gjerde rundt agentens output. Hver passerende test nullstiller feilraten for den egenskapen testen dekker. Hvis teamet ditt allerede jobber agentisk, men uten bevisst fokus på testkvalitet og testdekning, bør det stå på agendaen i nær fremtid. Ikke bare fordi testing er god skikk i seg selv, men fordi agentisk utvikling uten et solid testfundament forsterker feil raskere enn manuell utvikling noen gang gjorde.

Som en naturlig forlengelse av dette lønner det seg å rigge selve kodebasen for agenten. Hold dokumentasjon fersk og nær selve koden, ikke gjemt i en wiki agenten aldri åpner. Plasser domenespesifikk kontekst der arbeidet faktisk skjer, gi modulene tydelige grenser, og bruk filer som `CLAUDE.md` eller `AGENTS.md` til å peke agenten på hvor ting hører hjemme i kodebasen. Det sparer tokens hver gang en agent skal utforske, fordi den slipper å skanne seg fram til kontekst som kunne vært gjort eksplisitt fra start. Bonusen er at den samme jobben løfter din egen utviklingshastighet: når du rigger kodebasen for agenten, rigger du den samtidig for deg selv.

## Tokens som primitiv

Her ender jeg opp når jeg forsøker å se 12 måneder fram i tid.

Før agentisk AI var den bindende begrensningen for de fleste typer kunnskapsarbeid menneskelig oppmerksomhet. En ingeniør kunne veie N implementasjonsalternativer per uke, en PM kunne stresse-teste M posisjoneringsvinkler per kvartal, en CFO kunne kjøre K finansielle scenarier før et styremøte. På mange måter var taket timer per hode.

Tokens flytter taket fra arbeidsbegrensning til kapitalbegrensning, i hvert fall i langt større grad enn for noen få år siden. Spørsmålet blir et annet: hvor mange parallelle hypoteser har du råd til å kjøre? Hvor mange design utforsket, arkitekturvalg modellert, finansielle scenarier stresstestet, alternative kodeimplementasjoner undersøkt før lansering til produksjon?

Forskningen bekrefter retningen, men med forbehold. [DORA-rapporten for 2025](https://dora.dev/dora-report-2025/) finner en positiv sammenheng mellom AI-adopsjon og software delivery throughput, og over 80 prosent av utviklere rapporterer økt produktivitet. Men gevinstene er ujevnt fordelt: Stanford-forskning viser 35–40 prosent produktivitetsgevinst på greenfield-oppgaver mot under 10 prosent på kompleks legacy-kode. DORAs viktigste funn er at AI ikke fikser et team, den forsterker det som allerede er der. Sterke team blir sterkere, svake team får svakhetene sine forstørret. Løs kobling i arkitekturen og raske tilbakemeldingsløkker er det som gjør forskjellen. Token-disiplinen er altså ikke en automatisk vei til høyere gjennomstrømming; den er den marginale spaken for teamene som først har gjort grunnarbeidet.

Tokens er ikke en kostnadslinje, de er en _innsatsfaktor_, altså en ressurs som direkte inngår i det du produserer. En kostnadslinje kan ofte være noe du prøver å _minimere_, mens en innsatsfaktor _optimaliserer_ du for. En fabrikk prøver ikke å bruke minst mulig strøm; den optimaliserer for å bruke akkurat den strømmen som trengs for å produsere mest mulig til lavest mulig kostnad per enhet. Tokens fungerer på samme måte: spørsmålet er ikke hvor lite du kan bruke mens du jobber, men hvor mye du får ut i andre enden av det du bruker.

Den relevante KPI-en er altså ikke "kroner brukt på tokens", men **beslutningskapasitet per token**: hvor mange velinformerte valg du klarer å produsere per krone forbrukt i inferens.

![En figur i silhuett omgitt av flere transparente ekko-versjoner av seg selv](https://www.magnusrodseth.com/blog/forste-dose-er-gratis/beslutningskapasitet.webp)
_Det er ikke flere timer i døgnet, men flere hypoteser per time. Beslutningskapasitet er den nye flaskehalsen. Kilde: OpenAI gpt-image-2._

## Det dette innlegget ikke handler om

Token-økonomien er et større tema enn ett blogginnlegg, og det blir bare større etter hvert som forbruket vokser. Jeg har her bevisst snevret meg inn på det utviklere selv kan gjøre i sin daglige arbeidsflyt. Det betyr at en rekke spørsmål som hører hjemme på ledelsens, plattformteamets og CFO-ens bord, ikke er behandlet her. Noen av de viktigste, slik jeg ser dem:

- **Governance-modeller.** Skal kvoter settes på organisasjonsnivå, team-nivå eller per utvikler? Hvem eier beslutningen, hvem betaler regningen, og hvem får unntakene? Det er verdt å gjenkjenne dette som et allokeringsproblem mer enn et budsjettproblem. Er det først-til-mølla fra en felles pool? Lik kvote per bruker, eller en fair-share-modell der ubrukte tokens kan høstes av power-brukere som faktisk får mer ut av dem? Skal incident-respons eller andre kritiske oppgaver ha prioritet i køen, og skal noen kjøringer kunne avbrytes hvis budsjettet røyner på? Dette er ikke nye spørsmål, men gamle problemer i ny innpakning.
- **AI-gateways og intelligent ruting.** Et proxy-lag som automatisk sender enkle oppgaver til billigere modeller, og som gir cost visibility, caching og fallback på tvers av leverandører, er på mange måter den største spaken på organisasjonsnivå. Den ligger utenfor det utvikleren kan løse alene.
- **Telemetri og datadrevet justering.** Riktige kvoter krever data: modell-bruk per team, per oppgavetype, per kostnad. Uten dashbordene blir kvotene magefølelse, og du får den dynamikken Slack-tråden i introduksjonen viser.
- **Leverandørstrategi og redundans.** Hvor avhengig vil dere være av én frontier-leverandør? Hva sier kontraktene om data-retensjon, trening og oppsigelsesfrister?
- **ROI-rapportering mot finans.** Hvordan oversetter engineering "kroner i tokens" til "kroner i produktivitet"?
- **Operasjonell motstandsdyktighet.** Hva er beredskapsplanen dagen Anthropic, OpenAI eller GitHub er nede, eller dagen en modell blir trukket tilbake? Det at tilgangen oppleves som infrastruktur betyr ikke at den faktisk _er_ det.
- **Kompetanseheving og kultur.** Hvordan trener du noen hundre utviklere på samme tid til å bli skikkelig gode på modellvalg, kontekstdisiplin og prompt-design? Rammeverket presentert av Salnikov er verdiløst hvis 80% av teamet defaulter til den dyreste modellen fordi ingen har vist dem alternativene.
- **Skygge-IT.** Når den interne kvoten brennes opp, kan utviklere ty til å betale for sine egne abonnementer for Claude eller Cursor. Dette skaper både sikkerhets-, compliance- og kulturproblemer.

## Oppsummering

Utviklingen i token-kostnad denne våren har avdekket en reell sårbarhet. Hele bransjen har bygd arbeidsprosesser oppå en pris som for mange ikke oppleves som økonomisk bærekraftig, og når regningen kommer føles plutselig hele oppsettet skjørt. Å sitte uten toppmodellene i en time føles for mange utviklere som regressivt på en måte som er ny for en utviklerprofesjon vant til at verktøyene bare ligger der til enhver tid.

Men det er noe å hente i dette også. Når tokenene koster det de koster, blir disiplinen rundt modellvalg, kontekst og automatiserte kvalitetssjekker enda viktigere å være bevisst på. Det er nettopp den jobben Salnikov peker på, og det er der verktøy som `rtk` og `caveman` gir deg konkrete grep.

Flere og flere bedrifter legger nå merke til at første dose er gratis. Resten betaler vi for. Spørsmålet er bare om vi bruker dem godt.

## Avsluttende tanker: Hvis du ikke har sett dette enda

Sannsynligheten er stor for at du legger merke til dette i løpet av sommeren 2026. Når regnestykket først lander på arbeidsgiverens bord, vil den naturlige refleksen være å snakke om _kostnad_. Det er den enkleste og mest umiddelbare rammen å ta inn over seg.

Det er der utvikleren har en jobb å gjøre, før samtalen settes i gang av noen andre. Den som flagger dette tidlig, får være med å forme rammen. Jeg mener den rammen bør være basert på _verdi per token_, ikke et generelt sparepåbud. Domino-dynamikken og horisont-poenget vi så tidligere i innlegget viser hvorfor det betyr noe: et sparepåbud forsterker feilraten gjennom hele flyten, ikke motsatt, og det er nettopp det organisasjonen må unngå.

## Ressurser

- [GitHub: Copilot is moving to usage-based billing](https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/): GitHubs egen kunngjøring av modellskiftet 1. juni
- [MindStudio: Copilot's New Multiplier Table](https://www.mindstudio.ai/blog/github-copilot-new-multiplier-table-price-hikes): Multiplikatorhistorikken for Opus 4.7
- [Finout: Claude Opus 4.7 Pricing, The Real Cost Story](https://www.finout.io/blog/claude-opus-4.7-pricing-the-real-cost-story-behind-the-unchanged-price-tag): Den stille tokenizer-inflasjonen
- [Fortune: Microsoft reports are exposing AI's real cost problem](https://fortune.com/2026/05/22/microsoft-ai-cost-problem-tokens-agents/): Microsofts interne Claude-kansellering
- [Tom's Hardware: AI cost crisis hits tech giants](https://www.tomshardware.com/tech-industry/artificial-intelligence/ai-cost-crisis-hits-tech-giants-as-employee-tokenmaxxing-backfires-agentic-ai-eats-up-to-1000x-more-tokens-than-standard-ai-sparks-corporate-pullback-at-microsoft-meta-and-amazon): Uber-utsagnet og Goldman Sachs-anslagene
- [Maxim Salnikov: A practitioner's guide to getting more value out of AI coding](https://www.linkedin.com/pulse/practitioners-guide-getting-more-value-out-ai-coding-agent-salnikov-mhume/): Den analytiske rammen i dette innlegget
- [DORA: State of AI-assisted Software Development 2025](https://dora.dev/dora-report-2025/): Empirisk grunnlag for produktivitetsclaimet, og forbeholdene
- [METR: Measuring AI Ability to Complete Long Tasks](https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/): Tidshorisonten for agentiske oppgaver, og hvordan den dobles omtrent hver syvende måned
- [Matt Pocock: Most devs don't understand how LLM tokens work](https://www.youtube.com/watch?v=nKSk_TiR8YA): Tokenisering fra grunnen
- [TokenMix: Thinking Tokens Trap](https://tokenmix.ai/blog/thinking-tokens-billing-trap-2026): Hvordan reasoning-tokens faktureres som output hos OpenAI og Anthropic
- [Finout: Anthropic API Pricing 2026](https://www.finout.io/blog/anthropic-api-pricing): Forholdet mellom input- og output-priser
- [arXiv: The Tokenizer Tax Across 24 European Languages](https://arxiv.org/html/2605.24718): Tokenizer-skatten på tvers av europeiske språk, inkludert norsk
- [rtk-ai/rtk](https://github.com/rtk-ai/rtk): Input-side filtrering
- [JuliusBrussee/caveman](https://github.com/JuliusBrussee/caveman): Output-side komprimering


---

# Testing og evaluering av agenter: Hvordan bygge tillit til ikke-deterministiske systemer

Published: April 2026
Originally published at Capra Consulting: https://capraconsulting.no/vare-historier/hvordan-bygge-tillit-til-ikke-deterministiske-ai-systemer

> Agenter er ikke-deterministiske. Tradisjonelle tester alene er ikke nok. Her er testpyramiden, verktøyene og strategiene du trenger.

![En hjerne omkranset av et forstørrelsesglass, en sjekkliste, et søylediagram og et gjentakelsessymbol](https://www.magnusrodseth.com/blog/testing-og-evaluering-av-agenter/banner.png)
_Evaluering av agenter er en løkke, ikke en engangstest. Kilde: Google Nano Banana Pro._

## Innledning

Agenten vår hadde fungert godt i måneder. Systemprompten hadde dog vokst til over 200 linjer med instruksjoner for 12 ulike verktøy. Da vi la til en ny funksjon med sin egen flerstegsprosess, introduserte vi motstridende regler: én del av prompten sa "spør brukeren _før_ du henter data," mens den nye delen sa "hent data _før_ du spør." Agenten løste konflikten på sin egen måte og hoppet over halvparten av spørsmålene.

Vi oppdaget det ved å _bruke_ agenten, ikke ved å kjøre evalueringer. Evalueringsoppsettet vårt var rett og slett ikke rigget for å fange denne typen feil. Det var en vekker: vi hadde investert hundrevis av timer i funksjonalitet, men nesten ingenting i å systematisk verifisere at helheten fortsatt hang sammen.

Tradisjonelle enhetstester fanger ikke denne typen feil. Agenter er ikke-deterministiske, og kvalitet er ofte subjektivt. Det betyr ikke at testing er umulig, men du trenger et nytt lag i teststrategien. I dette innlegget ser vi på hva det laget inneholder: testpyramiden for agenter, MLflow som case study for tracing og evaluering, og en CI-strategi som balanserer grundighet med kostnad.

## Testpyramiden for agenter

Det finnes en [testpyramide spesielt designet for AI-agenter](https://engineering.block.xyz/blog/testing-pyramid-for-ai-agents) som bygger _på toppen_ av din eksisterende testinfrastruktur. Den har fire lag:

![Testpyramide for agenter](https://www.magnusrodseth.com/blog/testing-og-evaluering-av-agenter/test-pyramid.webp)
_Testpyramiden for agenter: fire lag som supplerer tradisjonelle tester. Kilde: Basert på Block Engineering._

**Lag 1: Deterministiske tester.** Enhetstester med mock-providers. Rask, gratis, forutsigbare.

**Lag 2: Record/replay.** Forhånds-innspilte LLM-responser avspilles deterministisk i CI. Ekte agentoppførsel uten API-kostnader.

**Lag 3: Statistiske benchmarks.** Kjør testsettet flere ganger og mål gjennomsnitt. Én kjøring sier nesten ingenting; mønstre over tid forteller mer.

**Lag 4: LLM-as-judge.** En LLM evaluerer output fra en annen, med domene-spesifikke kriterier. Her hører også menneskelig vurdering hjemme.

Tradisjonelle tester (frontend, E2E, enhet, integrasjon) forsvinner ikke. Agentspesifikke evals er et _tillegg_, ikke en erstatning.

I praksis har vi til nå lagt mesteparten av innsatsen i lag 1. Det store flertallet av testene våre er deterministiske enhetstester som dekker forretningslogikk, API-kontrakter, verktøyskjemaer og databaseoperasjoner. Det er solid, og det fanger reelle feil. Men etter hvert som flere funksjoner lever i den agentiske chatten _i tillegg til_ gjennom tradisjonell UI, treffer disse testene en stadig mindre del av det brukeren faktisk opplever. Vi har rigget et evalueringsoppsett med egendefinerte scorers og en CLI som kjører agenten mot kuraterte datasett og produksjonstracer i MLflow, men det kjøres fortsatt manuelt. Kombinert med opplevelsen fra innledningen, der vi ikke fanget motstridende promptinstruksjoner systematisk, peker det i én retning: evalueringsriggen må bli en del av CI-pipelinen, ikke noe vi sjekker når vi "føler" at noe er galt.

## MLflow: Tracing og evaluering i praksis

Flere verktøy dekker dette landskapet ([LangSmith](https://www.langchain.com/langsmith), [Langfuse](https://langfuse.com/), [Phoenix](https://github.com/Arize-ai/phoenix), [DeepEval](https://github.com/confident-ai/deepeval) for å nevne noen), men jeg bruker [MLflow](https://mlflow.org/) (versjon 3.x) som eksempel her fordi det er det _vi_ bruker i produksjon, er self-hostable, og fordi det kombinerer tracing, evaluering og eksperimentsporing i én plattform.

### Tracing med autolog

Med én linje fanger MLflow opp alle steg agenten tar:

```python
import mlflow

mlflow.langchain.autolog(log_traces=True)
mlflow.config.enable_async_logging(True)  # Non-blocking in production
```

Hvert verktøykall, LLM-invokasjon og retrieval-operasjon blir et span i et trace-tre:

![MLflow traces-oversikt](https://www.magnusrodseth.com/blog/testing-og-evaluering-av-agenter/mlflow-traces-overview.png)
_Traces-oversikten i MLflow: Hvert spørsmål fra brukeren er et trace med request, response, tokentall og responstid. Kilde: MLflow._

![Et utvidet trace i MLflow](https://www.magnusrodseth.com/blog/testing-og-evaluering-av-agenter/mlflow-trace-expanded.png)
_Et utvidet trace viser hvert steg agenten tok: validering, intensjonsklassifisering, retrieval av dokumenter, og responsgenering. Kilde: MLflow._

Første gang vi åpnet dette UIet etter å ha kjørt tester på produksjonsdata, var det flere ting som overrasket. For det første: den semantiske søkestrategien vår fungerte faktisk. Vi hadde designet en tilpasset retrieval-tilnærming, og tracene viste at den scoret høyt mot metrikkverdiene våre med ekte brukerdata. Det var en bekreftelse vi ikke hadde fått uten observabilitet.

Men den viktigste innsikten kom tidligere. Før vi gikk over til ReAct-mønsteret, hadde vi en egendefinert LangGraph-graf der vi manuelt definerte hvilke steg samtalen skulle ta basert på klassifisert intensjon. For eksempel: brukeren spør om taket, agenten klassifiserer det som "DOCUMENT_LOOKUP", og samtalen rutes til retrieval-noden. Problemet var at klassifiseringen ofte bommet. Et oppfølgingsspørsmål som "hva bør jeg gjøre med det?" ble klassifisert som "SMALLTALK" i stedet for å kobles til den pågående samtalen om taket. Tracene viste dette tydelig: vi kunne se nøyaktig hvor klassifiseringen feilet, og hvor ofte. Det var denne innsikten som formet beslutningen om å gå bort fra den egendefinerte grafen og over til [ReAct-mønsteret vi bruker i dag](https://capraconsulting.no/vare-historier/hvordan-agenter-bryter-ned-komplekse-mal). Uten tracing hadde den beslutningen vært basert på magefølelse og intuisjon, og ikke vært datadrevne.

### Egendefinerte scorers

MLflow 3.x har innebygde scorers for vanlige evalueringer (forankring (groundedness), relevans, sikkerhet), men den virkelige verdien ligger i å bygge dine egne for akkurat ditt domene:

```python
from mlflow.genai.scorers import scorer
from mlflow.entities import Feedback

@scorer
def norwegian_language(*, inputs, outputs, **kwargs):
    """Check if agent responds in Norwegian."""
    # Use a judge LLM with structured output
    result = judge.invoke({"inputs": inputs, "outputs": outputs})
    return Feedback(
        value=1.0 if result.is_norwegian else 0.0,
        rationale=result.explanation
    )
```

Domene-spesifikke scorers er langt mer nyttige enn generiske metrikker. Vi bygde fire egne: `GroundednessScorer` (er svaret forankret i konteksten?), `HelpfulnessScorer` (adresserer svaret spørsmålet?), `RetrievalRelevanceScorer` (hentet RAG riktige dokumenter?), og `NorwegianLanguageScorer` (svarer agenten på norsk?).

En lærdom vi fikk tidlig var at ikke alle scorers kan brukes på alle responser. En forankring-scorer som evaluerer om svaret er basert på hentet kontekst vil gi false negatives på helt korrekte avvisninger fra assistenten som "Beklager, det kan jeg ikke hjelpe med." Svaret er riktig, men det finnes ingen kontekst å forankre det i. Løsningen var å la scoreren sjekke den klassifiserte intensjonen først, og returnere "ikke aktuelt" for kategorier der metrikken ikke gir mening, i stedet for å score den som feil.

### Evaluering mot datasett

Med `mlflow.genai.evaluate()` kjører du agenten mot et kuratert datasett og scorer resultatene:

```python
eval_dataset = [
    {
        "inputs": {"question": "Hva er tilstanden på taket?"},
        "expectations": {"intent": "DOCUMENT_LOOKUP"},
    },
    {
        "inputs": {"question": "Kan du hjelpe meg med matlagning?"},
        "expectations": {"intent": "REJECTED"},
    },
]

results = mlflow.genai.evaluate(
    data=eval_dataset,
    predict_fn=run_agent,
    scorers=[groundedness, helpfulness, norwegian_language],
)
```

![Evalueringsresultater i MLflow](https://www.magnusrodseth.com/blog/testing-og-evaluering-av-agenter/mlflow-evaluation-results.png)
_Evalueringsresultater: Groundedness, helpfulness og retrieval relevance per testtilfelle. Du kan sammenligne på tvers av promptversjoner og modeller. Kilde: MLflow._

## Offline, online og svinghjulet

Evaluering er ikke noe du gjør én gang. Hamel Husain, som blant annet ledet teamet bak CodeSearchNet (en forløper til GitHub Copilot) og har jobbet med evalueringsoppsett på tvers av 35+ AI-produkter, [anbefaler](https://hamel.dev/blog/posts/evals/) at 60-80 % av utviklingstiden bør gå til feilanalyse og evaluering: _gå gjennom tracer og forstå hvor agenten feiler_.

**Offline evaluering** kjører agenten mot kuraterte datasett med kjente forventninger etter hver promptendring. **Online evaluering** scorer produksjonstrafikk asynkront ved å sample tracer og overvåke trender. Begge mater det Anthropic kaller [eval-svinghjulet](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents):

![Eval-svinghjulet](https://www.magnusrodseth.com/blog/testing-og-evaluering-av-agenter/eval-flywheel.webp)
_Eval-svinghjulet: En kontinuerlig syklus der feilanalyse driver nye evalueringer, som driver bedre prompter, som overvåkes i produksjon. Kilde: Basert på Anthropic._

Vi har allerede sett verdien av dette i praksis. Ved å analysere produksjonstracer oppdaget vi hvilke temaer brukerne spør mest om, og like viktig: hva de _forventer_ at agenten kan gjøre, men som den ikke støtter ennå. Mønsteret er gjenkjennelig: brukeren spør om et tema, får et svar, og følger opp med "kan du gjøre det for meg?" Når agenten ikke kan det, og det skjer i volum, har vi et tydelig signal om hva som bør prioriteres å støttes som neste funksjonalitet i agenten til produktet.

Tommel opp/ned fra brukere (a la hva som finnes i ChatGPT og Claude) er en naturlig del av denne kontinuerlige sløyfen, men den har en åpenbar begrensning: den avhenger av brukerens vilje til å gi tilbakemelding. Volumet varierer. Hvis samtaletrafikken er høy nok, kan du likevel trekke ut verdifulle signaler, enten det er positive bekreftelser, feilmeldinger, funksjonsønsker, eller hallusinasjoner. Poenget er å ha infrastrukturen på plass slik at signalene fanges opp, ikke forsvinner.

## CI-strategi og kostnad

Skal du kjøre LLM-evals i CI? Ja, men hvor mye og hvor ofte avhenger av teamet ditt, budsjett, iterasjonshastighet, sikkerhetskrav, og om du jobber med et greenfield-prosjekt eller en moden kodebase. En lagdelt tilnærming som _kan_ fungere:

**Hver commit:** Kodebaserte sjekker som prompt-snapshots, skjemavalidering og enhetstester. Gratis og deterministiske.

**Hver PR:** Record/replay-tester der forhåndsinnspilte LLM-responser avspilles deterministisk. Gratis etter opptak.

**Hver natt, hver 3. dag, eller ukentlig:** LLM-as-judge-evalueringer med domene-spesifikke scorers. Typisk $1-5 per kjøring.

**On-demand:** Menneskelig vurdering der en domeneekspert gjennomgår feiltilfeller.

Record/replay er et naturlig mellomsted mellom rene mocks (for enkle til å fange promptfeil) og ekte LLM-kall (for dyre og ustabile for CI). Men ingen av disse valgene er universelle. Det riktige oppsettet er det som gir _ditt_ team nok tillit til å shippe, uten å bli en flaskehals.

Vår erfaring så langt: ekte LLM-kall i CI koster tokens og tar opp compute-ressurser for organisasjonen, og derfor har vi kjørt evalueringene manuelt hittil. Men over tid har vi erfart at manuell kjøring ikke skalerer. Det er for lett å la det gli, og da er du tilbake til å oppdage regresjoner ved at noen tilfeldigvis _bruker_ agenten og merker at noe er galt. Record/replay og flere evalueringer av agenten vår i CI er neste eksperiment for oss. Uansett tilnærming er én ting sikkert: evalueringsriggen fortjener like mye kjærlighet som selve applikasjonen, og den må kjøres ofte nok til at du har reell tillit til at systemet ikke har blitt dårligere.

## Oppsummering

Agenter er ikke-deterministiske, men de er testbare. Nøkkelen er å akseptere at testing av agenter er probabilistisk, og bygge en strategi rundt det:

- **Behold dine tradisjonelle tester.** De dekker alt det deterministiske: forretningslogikk, API-kontrakter, databasekall.
- **Legg til agentspesifikke evals.** Record/replay i CI, LLM-as-judge for kvalitet, egendefinerte scorers for domenet ditt.
- **Start med feilanalyse.** Gå gjennom tracer før du automatiserer, gjerne ved hjelp av en AI-assistent for å avdekke hvor skoen trykker. Generiske metrikker fanger ikke alltid det du faktisk trenger å måle.
- **Evaluer kontinuerlig.** Offline mot datasett ved endringer, online mot produksjonstrafikk ellers.

Testing av agenter handler ikke om å eliminere usikkerhet. Det handler om å _håndtere_ den, systematisk og kostnadsbevisst.

## Ressurser

- [MLflow GenAI Evaluation](https://mlflow.org/docs/latest/genai/eval-monitor/) -- Dokumentasjon for evaluering og tracing i MLflow 3.x
- [Testing Pyramid for AI Agents - Block Engineering](https://engineering.block.xyz/blog/testing-pyramid-for-ai-agents) -- Testpyramiden for AI-agenter
- [Your AI Product Needs Evals - Hamel Husain](https://hamel.dev/blog/posts/evals/) -- Hvorfor 60-80 % av tiden bør gå til evaluering
- [Demystifying Evals for AI Agents - Anthropic](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) -- Anthropics rammeverk for agentevaluering
- [Evaluating LLM-Evaluators - Eugene Yan](https://eugeneyan.com/writing/llm-evaluators/) -- Grundig analyse av LLM-as-judge-mønstre
- [Langfuse](https://langfuse.com/) -- Åpen kildekode-alternativ for LLM-observabilitet
- [DeepEval](https://github.com/confident-ai/deepeval) -- Pytest-stil evalueringsrammeverk med 50+ metrikker


---

# Deep Dive: deepagents, LangChains Agent Harness

Published: March 2026
Originally published at Capra Consulting: https://capraconsulting.no/vare-historier/deep-dive-deepagents-langchains-agent-harness

> En grundig gjennomgang av deepagents, LangChains 'batteries included'-løsning for komplekse AI-agenter med innebygd planlegging, filsystem og subagenter.

![Banner: En hjerne i sele klatrer opp en fjellvegg, mens en uutstyrt hjerne står igjen på bakken](https://www.magnusrodseth.com/blog/deep-dive-deepagents/banner.png)

## Innledning

Tenk på hva du har tilgjengelig i [Claude Code](https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/overview). Filsystemverktøy som leser, skriver og søker i kode. Planlegging som bryter ned komplekse oppgaver i håndterbare steg. Oppgavesporing som holder oversikt over fremdriften. Persistent minne som husker kontekst på tvers av samtaler. Subagenter som kan delegeres spesialiserte oppgaver. Automatisk kontekststyring som forhindrer at vinduet flyter over.

De fleste utviklere har kjent denne kraften. Men har du gitt mye tanke til kompleksiteten det innebærer å faktisk implementere disse egenskapene for _din egen_ agent, den som kjører i _din_ applikasjon?

Si at du bygger en domenespesifikk agent for finans, forsikring eller helse. Du forventer at denne digitale medarbeideren skal være minst like kapabel som om du kastet det samme domeneproblemet til et fullverdig Claude Code-oppsett. Men å bygge alt det fra scratch? Det krever en enorm mengde kode, og det er vanskelig å få til helt riktig.

Her kommer [`deepagents`](https://docs.langchain.com/oss/python/deepagents/overview) inn. Inspirert av applikasjoner som Claude Code, Deep Research og Manus, gir dette [open source-biblioteket](https://www.langchain.com/deep-agents) deg "batteries included" for agenter som takler komplekse, flerstegs oppgaver.

## Hva er en Agent Harness?

For å forstå hva `deepagents` er, hjelper det med en analogi.

Tenk på en fjellklatrer. Klatreren selv er sterk og kompetent (det er modellen din, GPT, Claude, Gemini). Men styrke alene får deg ikke opp fjellveggen. Du trenger en **sele**: tau, karabinere, sikringsenheter, kritt-pose, og en ryggsekk med proviant. Selen gjør ikke klatreren sterkere. Den gjør klatreren _brukbar_ i krevende terreng.

Det er akkurat det en **agent harness** gjør for en språkmodell. Når frontiermodellene fra de store labene allerede er ekstremt kapable, er det ikke modellen som er differensiatoren i agentiske arbeidsflyter. Det er _selen rundt den_: verktøyene, planleggingen, minnet, og kontekststyringen du instrumenterer modellen med. Som [Harrison Chase skriver](https://blog.langchain.com/deep-agents/): det er denne selen som skiller en kapabel digital medarbeider fra en som faller av fjellveggen.

![Sele-metafor: Modell + Harness = Agent](https://www.magnusrodseth.com/blog/deep-dive-deepagents/model-plus-harness.png)
_En agent er mer enn bare modellen. Harness-en (selen) instrumenterer modellen med verktøy, planlegging, minne og kontekststyring, og gjør den til en kapabel digital medarbeider. Kilde: Basert på [The Anatomy of an Agent Harness](https://blog.langchain.com/the-anatomy-of-an-agent-harness/)._

LangChain-økosystemet består av tre distinkte lag. Nederst har du **[LangChain](https://docs.langchain.com/oss/python/langchain/overview)** som _framework_: abstraksjoner og en mental modell for å bygge med LLM-er. Over det ligger **[LangGraph](https://docs.langchain.com/oss/python/langgraph/overview)** som _runtime_: varig utførelse, streaming, persistens og human-in-the-loop. Øverst sitter **[deepagents](https://docs.langchain.com/oss/python/deepagents/overview)** som _harness_: alt fra de to lagene under, pluss forhåndskonfigurerte prompts, filsystem, planlegging og subagenter.

Et **framework** gir deg byggeklossene. En **runtime** gir deg infrastrukturen for produksjon. En **harness** tar deg fra null til fungerende agent med ett funksjonskall. Vil du forstå mer om runtime-laget, se innlegget om LangGraph.

![Framework, Runtime, Harness hierarki](https://www.magnusrodseth.com/blog/deep-dive-deepagents/framework-runtime-harness.png)
_LangChain-økosystemets tre lag: Framework (LangChain) gir abstraksjoner, Runtime (LangGraph) gir infrastruktur for produksjon, og Harness (deepagents) pakker alt sammen med forhåndskonfigurerte verktøy. Kilde: Basert på [LangChain Blog](https://blog.langchain.com/agent-frameworks-runtimes-and-harnesses-oh-my/)._

## Innebygde verktøy

Når du oppretter en deep agent med `create_deep_agent()`, får du automatisk tilgang til et sett med kraftige verktøy, uten å måtte konfigurere noe selv.

### Filsystemverktøy

Agenten har seks innebygde verktøy for filoperasjoner:

- `ls` : List filer med metadata (størrelse, endringstid)
- `read_file` : Les innhold med linjenummer, støtter offset/limit for store filer
- `write_file` : Opprett nye filer
- `edit_file` : Utfør eksakte strengerstatninger
- `glob` : Finn filer som matcher mønstre (f.eks. `**/*.py`)
- `grep` : Søk i filinnhold med regex

Disse dekker de vanligste behovene, men du kan utvide med egne verktøy når domenet krever det.

### Planlegging med write_todos

Komplekse oppgaver krever en plan. Agenten kan bryte ned flerstegs problemer med det innebygde `write_todos`-verktøyet. Før den begynner arbeidet, skriver den ut en oppgaveliste og oppdaterer statusen underveis:

```python
# Agenten produserer automatisk en struktur som dette:
{
    "todos": [
        {"task": "Kartlegg API-mønstre", "status": "completed"},
        {"task": "Implementer autentisering", "status": "in_progress"},
        {"task": "Skriv tester", "status": "pending"}
    ]
}
```

Gjenkjenner du mønsteret? Det er det samme vi så i [ReAct-løkken](https://www.magnusrodseth.com/blog/react-og-planlegging): tenk, planlegg, handle, observer, gjenta.

### Automatisk kontekststyring

To mekanismer forhindrer at kontekstvinduet fylles opp. Dette er viktig, fordi en agent som mister oversikten over sin egen kontekst, mister evnen til å resonnere effektivt.

**Utkasting av store verktøyresultater:** Når et verktøyresultat overstiger 20 000 tokens, skrives det automatisk til en fil. Agenten får en referanse i stedet, og kan lese filen bit for bit ved behov. Se [LangChain-bloggen om kontekststyring](https://blog.langchain.com/context-management-for-deepagents/) for detaljer om kompresjonsstrategiene.

**Oppsummering av samtalehistorikk:** Ved 170 000 tokens trigges en oppsummering. De siste 6 meldingene beholdes intakte, mens eldre meldinger komprimeres til et sammendrag.

## Subagenter: Løsningen på kontekstoverbelastning

Det største problemet med komplekse agenter er **kontekstoverbelastning**: når store verktøyresultater fyller opp kontekstvinduet og reduserer agentens evne til å resonnere.

Subagenter løser dette elegant. Hovedagenten kan delegere en oppgave til en subagent som opererer med sin egen, isolerte kontekst. La oss se hvordan dette ser ut i kode:

```python
from deepagents import create_deep_agent

research_subagent = {
    "name": "research-agent",
    "description": "Conducts in-depth research using web search",
    "system_prompt": """You are a thorough researcher. Your job is to:
    1. Break down the research question into searchable queries
    2. Use internet_search to find relevant information
    3. Synthesize findings into a concise summary

    Keep your response under 500 words.""",
    "tools": [internet_search],
}

agent = create_deep_agent(
    model="claude-sonnet-4-5-20250929",
    subagents=[research_subagent]
)
```

Subagenten utfører kanskje ti websøk, men hovedagenten mottar kun én oppsummering. Konteksten forblir ren.

![Subagent kontekstisolasjon](https://www.magnusrodseth.com/blog/deep-dive-deepagents/subagent-context-isolation.png)
_Kontekstisolasjon med subagenter: Hovedagenten (ren kontekst) delegerer oppgaver til subagenten (fylt kontekst fra mange verktøykall), og mottar kun et komprimert resultat tilbake. Kilde: Basert på [deepagents-dokumentasjonen](https://docs.langchain.com/oss/python/deepagents/overview)._

I tillegg til egendefinerte subagenter har du alltid tilgang til en **general-purpose** subagent. Den har samme instruksjoner og verktøy som hovedagenten, men opererer i isolert kontekst: perfekt for kontekstisolasjon uten spesialisert oppførsel.

## Lagringsbackends: Fleksibel persistens

Agentens filsystem er abstrakt og modulær, og du velger selv hvor filene faktisk lagres. **StateBackend** holder midlertidige filer innenfor én samtale og er ment å bruke kortsiktig (flyktig / "ephemeral"). **FilesystemBackend** gir ekte filtilgang på disk. **StoreBackend** bruker en database for langtidsminne på tvers av samtaler. Og **CompositeBackend** lar deg kombinere disse ved å rute ulike stier til ulike backends.

Den mest kraftfulle konfigurasjonen kombinerer flyktig og persistent lagring. Slik ser det ut i praksis:

```python
from deepagents.backends import CompositeBackend, StateBackend, StoreBackend
from langgraph.store.memory import InMemoryStore

composite_backend = lambda rt: CompositeBackend(
    default=StateBackend(rt),                   # Standard: flyktig (ephemeral)
    routes={"/memories/": StoreBackend(rt)}     # /memories/: persistent
)

agent = create_deep_agent(
    backend=composite_backend,
    store=InMemoryStore()
)
```

Med denne konfigurasjonen lever vanlige filer kun i samtalen, mens alt under `/memories/` huskes på tvers av økter.

## Human-in-the-Loop

For sensitive operasjoner kan du konfigurere pauser før utførelse. Agenten stopper og lar deg godkjenne, redigere eller avvise operasjonen:

```python
agent = create_deep_agent(
    tools=[edit_file, deploy_code],
    interrupt_on={
        "edit_file": True,     # Pause before every edit
        "deploy_code": True    # Pause before deploy
    },
    checkpointer=MemorySaver()  # Required for HITL
)
```

Et mønster vi kjenner igjen fra LangGraph, men her ferdigkonfigurert og klart til bruk.

## Fra praksis: Når selen veier mer enn klatreren

La meg dele en erfaring fra et klientprosjekt som illustrerer en viktig lekse.

Vi bygde en uttrekkspipeline for PDF-dokumenter. Oppsettet var ambisiøst: PDF lastes opp, sendes til en deep agent som sporet oppgaver med `write_todos`, skrev til persistent minne for fremdrift, og tikket av mål etter mål. Nøyaktigheten var høy. Agenten _fungerte_.

Men to ting ble raskt tydelige. For det første tok det altfor lang tid. Vi visste at uttrekket kunne gjøres raskere. For det andre var det dyrt: du betaler mange tokens for agentens resonnering i hvert steg, planleggingen, kontekststyringen, oppdatering av oppgavelisten.

Så vi skrev det om. I stedet for en fullverdig deep agent brukte vi regex-basert mønstergjenkjenning på tvers av dokument-chunks (ikke semantisk søk engang!), matet alt inn i en modell, og lot den produsere strukturert output. Resultatet var en raskere, billigere, og faktisk _mer nøyaktig_ pipeline for den ustrukturerte dataen vi jobbet med.

![Deepagents-pipeline vs. strukturert output-pipeline](https://www.magnusrodseth.com/blog/deep-dive-deepagents/pipeline-comparison.png)
_To tilnærminger til samme problem: Deep agent-pipelinen (venstre) med full planlegging og kontekststyring vs. den forenklede pipelinen (høyre) med regex og strukturert output. Noen ganger er den enklere veien både raskere, billigere og mer nøyaktig. Kilde: Egenutviklet._

Denne erfaringen lærte meg noe viktig. Det er fristende å kaste en kraftig sele og en kapabel modell på ethvert problem, i visshet om at den _kan_ løse det. Men [som Anthropic selv skriver](https://www.anthropic.com/engineering/building-effective-agents): start enkelt, og legg til kompleksitet kun når det er nødvendig. En agent harness er et kraftig verktøy for oppgaver som _krever_ flerstegs resonnering, planlegging og konteksthåndtering. For oppgaver som kan løses med et enkelt modellkall og god prompt-design, er den overkill.

Det handler ikke om å bevise at teknologien virker. Det handler om å velge riktig verktøy for jobben: hastighet, kostnad og nøyaktighet bør veie like tungt som kapabilitet.

## Oppsummering

`deepagents` er LangChains offisielle agent harness: et bibliotek som pakker mønstrene fra hele denne bloggserien i én abstraksjon. Innebygd planlegging, filsystemverktøy, subagenter for kontekstisolasjon, fleksible lagringsbackends, og human-in-the-loop, alt ferdigkonfigurert.

Men den viktigste innsikten er kanskje denne: **En god sele gjør ikke enhver klatring til rett klatring.** Å vite _når_ du trenger en fullverdig agent harness, og når et enkelt modellkall er nok, er det som skiller en god AI-utvikler fra en som bare kaster teknologi på problemet.

## Vil du ta steget?

Ønsker du eller bedriften din å utforske hvordan AI-agenter kan styrke ansatte, prosesser eller applikasjoner? Ta gjerne kontakt med meg på [LinkedIn](https://www.linkedin.com/in/magnus-rodseth/). Vi i [Capra](https://www.capraconsulting.no/) har mange dyktige utviklere som jobber med nettopp dette.

## Ressurser

- [deepagents (GitHub)](https://github.com/langchain-ai/deepagents)
- [deepagents dokumentasjon](https://docs.langchain.com/oss/python/deepagents/overview)
- [Deep Agents (LangChain Blog)](https://blog.langchain.com/deep-agents/)
- [Agent Frameworks, Runtimes, and Harnesses (LangChain Blog)](https://blog.langchain.com/agent-frameworks-runtimes-and-harnesses-oh-my/)
- [The Anatomy of an Agent Harness (LangChain Blog)](https://blog.langchain.com/the-anatomy-of-an-agent-harness/)
- [Context Management for Deep Agents (LangChain Blog)](https://blog.langchain.com/context-management-for-deepagents/)
- [Building Effective Agents (Anthropic)](https://www.anthropic.com/research/building-effective-agents)
- [Effective Harnesses for Long-Running Agents (Anthropic)](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)


---

# Spec-Driven Development: Hvordan skrive krav som agenter faktisk forstår

Published: March 2026
Originally published at Capra Consulting: https://capraconsulting.no/vare-historier/spec-driven-development-hvordan-skrive-krav-som-agenter-faktisk-forstar

> Lær hvordan Spec-Driven Development transformerer måten vi kommuniserer med AI-agenter, ved å skrive spesifikasjoner som fungerer for både mennesker og maskiner.

![Banner](https://www.magnusrodseth.com/blog/spec-driven-development/banner.png)

## Innledning

Spol tilbake til august 2025. Det var da jeg hadde mitt "oh shit"-øyeblikk med agentisk koding.

Frem til da hadde jeg hovedsakelig brukt Agentic Chat i Cursor med Claude Sonnet. Det fungerte greit for isolerte oppgaver, men jeg traff stadig veggen på noe større enn en enkel komponentendring. I august 2025 var flaggskipmodellen til Anthropic Claude Opus 4.1. Den hadde potensial, men den trengte _mye_ veiledning.

Så jeg begynte å utforske Plan Mode i Claude Code. Ideen om Plan Mode er enkel: la agenten analysere kodebasen og lage en plan _før_ den begynte å kode. Men det som overrasket meg var ikke Plan Mode i seg selv. Det var hva som skjedde når jeg ga agenten en skikkelig gjennomtenkt spesifikasjon i stedet for en vag instruksjon. Plutselig gikk outputen fra "nesten riktig, men treffer ikke helt" til "dette er nøyaktig det jeg mente - jeg og agenten er jo _helt_ enige".

Det var starten på en arbeidsmetode som nå har et navn: **Spec-Driven Development**.

## Hva er Spec-Driven Development?

Spec-Driven Development (SDD) har ennå ikke én universelt akseptert definisjon, men det handler om å skrive en strukturert spesifikasjon _før_ du ber agenten skrive kode. Specen blir kontrakten mellom deg og AI-agenten.

[Birgitta Böckeler fra Thoughtworks](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html) definerer en spec som:

> "A structured, behavior-oriented artifact, written in natural language that expresses software functionality and serves as guidance to AI coding agents."

Og SDD som praksis: å skrive denne specen før du skriver kode med AI ("documentation first"). Specen blir kilden til sannhet for både mennesket og agenten.

[Addy Osmani utdyper](https://addyosmani.com/blog/good-spec/) dette ved å understreke at LLM-er ikke leser tankene dine. De trenger strukturert, eksplisitt kontekst. En god spec eliminerer tvetydigheten som fører til at agenten gjetter, og gjetter feil.

Det viktige å forstå er at SDD er en **arbeidsmetode**, ikke et verktøy. Uansett hvilken IDE du bruker, uansett hvilken kode-agent eller modell du foretrekker, kan du jobbe på denne måten: spec først, deretter implementering. Det handler om å gjøre tekniske beslutninger eksplisitte, reviderbare og klare for utvikling _før_ en eneste linje kode blir skrevet.

### Tre nivåer av SDD

Böckeler identifiserer tre nivåer:

| Nivå               | Beskrivelse                                     | Når bruke                         |
| ------------------ | ----------------------------------------------- | --------------------------------- |
| **Spec-first**     | Skriv spec, bruk den, slett den etterpå         | Enkeltstående oppgaver            |
| **Spec-anchored**  | Behold og vedlikehold specen over tid           | Features som utvikles iterativt   |
| **Spec-as-source** | Spec er kildefilen; mennesker rører aldri koden | Eksperimentell, langsiktig visjon |

For de fleste team er **spec-first** et naturlig startpunkt, mens **spec-anchored** gir størst verdi for komplekse features. Spec-as-source er fortsatt noe eksperimentelt, men jeg legger stadig merke til flere og flere utviklere som avlaster mye av kodeskriving til dagens flaggskipmodeller.

![Tre nivåer av SDD](https://www.magnusrodseth.com/blog/spec-driven-development/spec-first-vs-spec-anchored-vs-spec-only.png)
_De tre nivåene av Spec-Driven Development: Spec-first (engangsspesifikasjon), Spec-anchored (vedlikeholdt over tid), og Spec-as-source (spesifikasjonen er kildefilen). Kilde: Basert på Birgitta Böckeler, martinfowler.com._

## Fra vibe coding til orkestrator

La meg være ærlig om hvordan forholdet mitt til specs har utviklet seg.

Da jeg startet med SDD i august 2025, var det tungt. Jeg brukte Plan Mode i Claude Code og skrev feature-specs med deloppgaver som jeg eksplisitt ba agenten huke av etterhvert som det fullførte hver oppgave. For større features opplevde jeg det ofte som vanskelig å håndtere. Det var _mye_ kontekst, og modellene på det tidspunktet var ikke gode nok til å holde oversikten over alt.

Men så skjedde noe. Modellene ble dramatisk bedre. Med modeller som Claude Opus 4.6 og verktøy som [Codex](https://openai.com/index/introducing-codex/) og [Claude Code](https://code.claude.com/docs/en/overview), merket jeg at forholdet mitt til specen endret seg. Det ble ikke _mindre_ viktig. Tvert imot, det ble så innarbeidet i måten jeg jobber på at jeg nesten ikke tenker over det lenger.

Forskjellen er i _hvor_ jeg bruker tiden min. Før var det mye mer hands-on med koden i hver fase. Nå bruker jeg mesteparten av tiden på å spesifisere featuren og tenke som en orkestrator: hva er alle de bevegelige delene i systemet? Hvilke filer er involvert? Hvilke constraints gjelder?

Deretter lar jeg agenten utforske kodebasen for å gjøre seg kjent. Jeg ber den stille meg oppfølgingsspørsmål. Ofte kan jeg bare si "utforsk mer kode," og den svarer på sine egne spørsmål. Andre ganger, hvis spørsmålet handler om arkitektur eller produktretning, bryter jeg inn. Men den initielle investeringen i en god spec betyr at agenten trenger _færre_ runder med korrigering.

[Andrej Karpathy](https://x.com/karpathy/status/1886192184808149383) kalte den ustrukturerte tilnærmingen "vibe coding" i februar 2025. SDD er det motsatte: presisjon først, deretter autonomi. Men du må ha hodet med hele veien, og sørge for å ikke bli agenten sin "yes-man".

## Anatomien til en god spesifikasjon

En god SDD-spesifikasjon bygger på fem pilarer:

**1. Context:** Tech stack, relevante filer, integrasjoner. Dette er agentens "onboarding."

**2. Requirements:** Spesifikke krav med eksakte filstier, interfaces og forventet oppførsel.

**3. Constraints:** Eksplisitte begrensninger. "Do NOT" er like viktig som "Do."

**4. Examples:** Konkrete input/output-eksempler for API-er og funksjoner.

**5. Definition of Done:** Objektive kriterier som kan verifiseres automatisk.

![De fem pilarene i SDD](https://www.magnusrodseth.com/blog/spec-driven-development/pillars.png)
_De fem pilarene i en god SDD-spesifikasjon: Context (prosjektkontekst), Requirements (spesifikke krav), Constraints (begrensninger), Examples (input/output-eksempler), og Definition of Done (ferdigkriterier)._

La oss se forskjellen i praksis.

### Vag prompt (problematisk)

```
Migrer backend-servicene våre til Bun.
```

Agenten må gjette på alt: hvilke services, hvilken rekkefølge, hva med Docker, hva med kompatibilitet, hva med avhengigheter. Du ender opp med tre runder klargjøring før noe nyttig skjer.

### SDD-spesifikasjon (bedre)

```markdown
## Feature: Migrate to Bun runtime and Bun workspaces

### Context

- Monorepo with 8 Docker-based services and 1 Next.js webapp
- Current stack: Node.js + npm with manual tsc compilation
- All services use 3-layer Docker builds (npm install → tsc → npm prune)

### Problem

Docker builds are unnecessarily complex, slow, and there is no
monorepo coordination between services.

### Requirements

1. Set up Bun workspaces in root package
   - Workspaces: `web/`, `packages/*`, `docker/*`
2. Simplify Dockerfiles to `oven/bun:1-alpine`
   - Remove tsc compilation, dist/, and prune steps
3. Migrate entrypoints to `bun run src/...`
4. Keep `web/` on Node.js (Next.js compatibility)

### Migration Order (lowest risk first)

1. fx-rates (simplest, no external dependencies)
2. api-gateway
3. notification-service
4. ...
5. website-scraper (highest risk: V8 memory flags)

### Constraints

- Do NOT migrate web/ to Bun (Next.js 15 lacks full support)
- Keep existing CI/CD pipeline structure
- Verify that pg SSL support works in Bun

### Definition of Done

- [ ] Bun workspaces configured and working
- [ ] All 8 services running on Bun runtime
- [ ] Docker image size reduced by ≥30%
- [ ] All existing tests pass
- [ ] web/ still on Node.js without regressions
```

Forskjellen er tydelig. Agenten vet nøyaktig hva den skal gjøre, i hvilken rekkefølge, og hva den _ikke_ skal røre. Migrasjonsrekkefølgen betyr at den begynner med lavest risiko og bygger opp trygghet før den tar de vanskelige casene.

## GitHub Issues som persistent minne

Her kommer innsikten som virkelig endret hvordan jeg jobber med SDD i team.

Det første man tenker er kanskje å legge specen i en Markdown-fil i kodebasen og versjonskontrollere den. Det fungerer for enkeltutviklere, men det skalerer dårlig. Filen er ikke delbar på en naturlig måte, den mangler diskusjonshistorikk, og den passer ikke inn i sprint-planlegging.

Løsningen er å bruke ditt team sitt prosjektstyringsverktøy som persistent hjem for specs. Jeg bruker GitHub Issues med GitHub CLI, men det samme prinsippet gjelder med Jira CLI, Linear, Notion MCP, eller hva teamet ditt allerede bruker.

Flyten ser slik ut:

1. **Spec opp featuren** i kode-agenten din med Plan Mode (eller tilsvarende)
2. **Opprett et GitHub Issue** med specen som issue body, ved hjelp av CLI
3. **Teamet kommenterer og reviderer** direkte på issuet
4. **Når du starter implementeringen**, pek agenten til issuet. Den leser hele specen, inkludert kommentarer, og vet nøyaktig hva den skal gjøre

```bash
# Opprett issue fra en spec-fil
gh issue create \
  --title "Migrer til Bun runtime og Bun workspaces" \
  --body-file spec.md \
  --label "feature,infrastructure"

# Eller la agenten gjøre det direkte etter plan-fasen
```

![SDD med GitHub Issues](https://www.magnusrodseth.com/blog/spec-driven-development/sdd-github-issues.png)
_Spec-Driven Development med prosjektsporing: Specen lever som et issue i prosjektstyringsverktøyet, der teamet kan kommentere, revidere, og planlegge. Når implementeringen starter, peker agenten til issuet og har all kontekst den trenger._

### Hvorfor dette fungerer

Tenk på issuet som din **konseptuelle Plan Mode**. Du har allerede gjort forarbeidet: identifisert filer, definert constraints, bestemt migrasjonsrekkefølge. Issuet kan leve der så lenge du trenger. Du kan merke det, legge det inn i sprint-planlegging, og engasjere ulike interessenter.

Når du så åpner kode-agenten din og peker den til issuet, trenger den ikke å gjøre seg kjent med kodebasen på nytt. Den har allerede blitt fortalt hvor den skal se, fordi du gjorde den jobben i spec-fasen. Ingen ekstra Plan Mode nødvendig, rett på implementering.

Dette løser også et skalerbarhetsproblem. SDD er ikke bare for deg som enkeltutvikler. Når specen lever i prosjektstyringsverktøyet, kan hvem som helst på teamet plukke opp issuet og starte arbeidet. En kollega kan ta en av deloppgavene. En annen kan kommentere at constraint X er utdatert. Specen blir en _felles_ kontrakt, ikke bare din private huskelapp.

Og når agenten har tilgang til prosjektstyringsverktøyet via CLI (f.eks. `gh` for GitHub), åpner det seg enda mer: branching, PR-oppretting, code review, og adressering av feedback kan alle bygges på toppen av specen som allerede ligger der. I teamet mitt har vi erfart at dette fungerer spesielt godt fordi alle kan se planen, og hvert steg i livssyklusen kan automatiseres inkrementelt. Men det er egentlig en egen post i seg selv.

## Iterasjon: Når specen lever videre

En spesifikasjon er et levende dokument. Den interessante biten er hva som skjer _etter_ du har laget den.

La oss si at du har spesifisert en feature, opprettet et GitHub Issue, og implementert den. Så kjører du brukerintervjuer og får tilbakemelding: brukerne forstår ikke flyten i steg 3, og de savner en eksportfunksjon.

I stedet for å oppdatere issue-bodyen (som skjuler historikken), legger du til en kommentar:

```markdown
## Revisjon 2026-03-15: Tilbakemelding fra brukerintervjuer

### Funn

- 3/5 brukere fant steg 3 i onboarding-flyten forvirrende
- 4/5 etterspurte CSV-eksport av rapportdata

### Endringer i spec

- Steg 3 splittes i to delsteg med tydeligere instruksjoner
- Nytt krav: CSV-eksport legges til rapportsiden

### Nye constraints

- Eksportfunksjonen må håndtere datasett opp til 10 000 rader
  uten timeout
```

Nå har du en sporbar revisjon. Neste gang noen (menneske eller agent) jobber med denne featuren, ser de hele utviklingen: den opprinnelige specen, tilbakemeldingen, og revideringen. Denne historikken er uvurderlig kontekst som en ren kodelinje aldri kan gi deg.

## Vanlige innvendinger

Böckeler tar opp noen viktige bekymringer som er verdt å adressere:

**"Er ikke dette bare vannfallsmodellen med AI?"**
Ja, hvis du insisterer på å skrive hele specen ferdig før du begynner. I praksis bør det være en kontinuerlig prosess. Start med en grov spec, la agenten utforske og stille spørsmål, og oppdater specen underveis. Den iterative naturen gjør det mer likt agil utvikling enn vannfall.

**"Det blir for mye Markdown å reviewe."**
Berettiget bekymring. Sørg for å holde specs konsise og fokusert. De fem pilarene hjelper deg å skrive _akkurat nok_, ikke mer. Med det sagt vil jeg heller lese planen for å forstå intensjon og hvorvidt en annen utvikler har tenkt gjennom edge cases, enn å få servert en masse kode som ikke er tilstrekkelig dokumentert.

**"Agenten følger ikke instruksjonene uansett."**
Böckeler observerer at agenter "frequently don't follow all the instructions, even with multiple files, templates, and checklists." Det stemmer. Men en god spec gjør det _enklere_ å oppdage avvik. Når du har en Definition of Done med sjekkbare kriterier, er det tydelig når agenten har bommet. Uten spec har du ingen referanse å sammenligne mot.

## Oppsummering

Spec-Driven Development handler ikke om mer dokumentasjon. Det handler om _bedre_ kommunikasjon med AI-agenter.

Det som startet som en nødvendighet i august 2025 (fordi modellene trengte mer veiledning) har blitt en arbeidsmetode som gir verdi selv med dagens langt mer kapable modeller. Ikke fordi agentene _alltid_ trenger å bli holdt i hånden, men fordi en god spec tvinger _deg_ til å tenke gjennom problemet ordentlig før du setter agenten i arbeid.

De fem pilarene (Context, Requirements, Constraints, Examples og Definition of Done) gir deg et rammeverk som fungerer uansett verktøy. Og ved å bruke prosjektstyringsverktøyet som persistent hjem for specen, får du en arbeidsflyt som skalerer fra enkeltutvikler til helt team.

## Ressurser

- [Birgitta Böckeler: Understanding Spec-Driven-Development (martinfowler.com)](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)
- [Addy Osmani: How to Write a Good Spec for AI Agents](https://addyosmani.com/blog/good-spec/)
- [AGENTS.md Standard](https://agents.md/)
- [Claude Code: Plan Mode](https://code.claude.com/docs/en/common-workflows)


---

# ReAct & Planning: Hvordan agenter bryter ned komplekse mål

Published: March 2026
Originally published at Capra Consulting: https://capraconsulting.no/vare-historier/hvordan-agenter-bryter-ned-komplekse-mal

> Lær hvordan ReAct-mønsteret kombinerer resonnering og handling for å la AI-agenter løse komplekse oppgaver steg for steg.

![En hjerne omkranset av et øye, et tannhjul, en tankeboble og et puslespill, bundet sammen av piler i en løkke](https://www.magnusrodseth.com/blog/react-og-planlegging/banner.png)
_ReAct-løkken: observere, resonnere, handle, og så observere igjen. Kilde: Google Nano Banana Pro._

## Innledning

I de forrige innleggene har vi etablert hvordan [agentiske arbeidsflyter](https://www.magnusrodseth.com/blog/fra-system-prompts-til-agentiske-arbeidsflyter) skiller seg fra tradisjonelle chatbots, hvordan [MCP](https://www.magnusrodseth.com/blog/model-context-protocol) kobler agenter til omverdenen, og hvordan CLI-agenter gir oss kraftige verktøy i terminalen. Men vi har ennå ikke besvart et fundamentalt spørsmål: Hvordan _tenker_ egentlig en agent?

Ved veldig naivt bruk av AI-verktøy i dag opplever mange at modellen "skyter fra hofta". Den gir et svar uten å vise arbeidet sitt, og resultatet blir ofte upresist eller direkte feil. Problemet er at LLM-er uten struktur mangler en mekanisme for å bryte ned komplekse oppgaver. De prøver å løse alt i ett steg.

Løsningen heter **ReAct**, et mønster som kombinerer **Re**asoning (resonnering) og **Act**ing (handling) i en iterativ syklus. Dette er fundamentet for hvordan moderne agenter planlegger og utfører arbeid, og det er et viktig mønster å beherske for å forstå resten av denne bloggserien.

Du har sannsynligvis allerede sett ReAct i aksjon uten å vite det. Når Claude Code leser en fil i terminalen din, resonnerer over en bug mens den tenker, og deretter redigerer koden; det er en ReAct-loop. Når ChatGPT søker på nettet, leser resultatene, og formulerer et svar basert på det den fant; det er også ReAct. Mønsteret er overalt i moderne AI-verktøy.

## Fra tanke til handling: ReAct-mønsteret

ReAct ble introdusert av [Yao et al. i 2022](https://arxiv.org/abs/2210.03629), og ideen er elegant i sin enkelhet: La modellen tenke høyt før hver handling. I stedet for å generere et endelig svar direkte, alternerer agenten mellom tre faser:

1. **Thought (Tanke):** Modellen resonnerer eksplisitt om hva den vet og hva den trenger å gjøre.
2. **Action (Handling):** Basert på resonnementet utfører den et [verktøykall](https://platform.openai.com/docs/guides/function-calling).
3. **Observation (Observasjon):** Resultatet av handlingen mates tilbake som kontekst.

Denne syklusen gjentas til agenten har nok informasjon til å gi et endelig svar, eller utilstrekkelig informasjon og må be brukeren om mer kontekst før den kan fortsette.

![ReAct-loop](https://www.magnusrodseth.com/blog/react-og-planlegging/react-loop.png)
_ReAct-mønsteret: Agenten alternerer mellom tanke, handling og observasjon i en iterativ syklus. Kilde: Yao et al., 2022._

Hvorfor fungerer dette bedre enn ren resonnering? Forskjellen ligger i tilbakemeldingssløyfen. **[Chain-of-Thought](https://arxiv.org/abs/2201.11903)** (CoT), en annen teknikk, lar modellen tenke steg-for-steg, men den kan bare resonnere basert på det den allerede "vet". Uten tilgang til verktøy risikerer den å hallusinere fakta. ReAct løser dette (så fremt den har tilgang på gode verktøy) ved å la modellen _sjekke_ antakelsene sine mot virkeligheten gjennom handlinger.

## Fra chatbot til agent: Et skille som endret alt

Jeg vil dele en erfaring fra et prosjekt jeg jobber med, fordi det illustrerer nøyaktig hvorfor ReAct-mønsteret er så viktig å forstå.

Vi hadde bygget en chatbot med LangGraph som virket imponerende på papiret: RAG-basert kontekstinnhenting, intensjonsklassifisering, reranking av resultater, og forretningskritiske guardrails. Den hentet relevant kontekst, genererte svar, og strømmet dem tilbake til klienten. I mitt hode hadde jeg laget en _agentisk_ chatbot.

Men det hadde jeg **ikke**.

Det jeg hadde bygget var en sofistikert _pipeline_, en lineær flyt fra input til output. Brukerens spørsmål gikk inn, kontekst ble hentet, et svar ble generert, ferdig. Hvis svaret var utilstrekkelig eller basert på feil kontekst, var det ingen mekanisme for å prøve igjen med en annen strategi. Chatboten kunne ikke _resonere_ om hva den manglet.

![Chatbot vs. agent](https://www.magnusrodseth.com/blog/react-og-planlegging/chatbot-vs-agent.png)
_Forskjellen mellom en pipeline-chatbot (lineær flyt) og en agentisk chatbot (iterativ ReAct-loop). Pipelinen gir ett svar basert på ett forsøk, mens agenten kan resonere, handle, og justere kursen._

Det som manglet var selve ReAct-loopen, den iterative syklusen der agenten resonnerer, velger et verktøy, observerer resultatet, og bestemmer neste steg. Og like viktig: _granulære, komponerbare verktøy_ som agenten faktisk kan bruke til å utforske og handle.

```python
# Granulære, komponerbare verktøy: nøkkelen til en ekte agent
@tool
def get_customer_by_id(customer_id: str) -> str:
    """Hent kundeinformasjon basert på kunde-ID."""
    ...

@tool
def search_orders(query: str, status: str | None = None) -> str:
    """Søk i ordrer med valgfri statusfiltrering."""
    ...

@tool
def create_support_ticket(customer_id: str, description: str) -> str:
    """Opprett en ny support-sak for en kunde."""
    ...

@tool
def update_order_status(order_id: str, new_status: str) -> str:
    """Oppdater status på en eksisterende ordre."""
    ...
```

Da vi koblet en `create_react_agent` med disse verktøyene _inn i_ den eksisterende LangGraph-grafen (som allerede hadde guardrails, intensjonsklassifisering, og retrieval), skjedde noe fundamentalt annerledes. Nå hadde vi en chatbot som kunne resonnere: "Brukeren spør om X, la meg slå opp kunde-ID-en først, deretter søke i Y, og hvis det er et problem, opprette en Z." Tre verktøykall, drevet av resonnering, ikke hardkodet logikk.

**Det er _dette_ skillet jeg vil at du som leser skal forstå.** En chatbot med RAG og fine pipelines er ikke automatisk agentisk. Den blir agentisk når den har en ReAct-loop som lar den _velge_ hva den skal gjøre basert på hva den observerer.

## ReAct i praksis: Implementering

La oss se hvordan dette ser ut i kode. Med [LangGraph](https://langchain-ai.github.io/langgraph/how-tos/create-react-agent/) blir implementeringen superenkel. Her er et komplett eksempel:

```python
from langgraph.prebuilt import create_react_agent
from langchain_openai import ChatOpenAI
from langchain_core.tools import tool

@tool
def search_codebase(query: str) -> str:
    """Search the codebase for relevant files."""
    # Implementation
    return f"Found 3 files matching '{query}'"

@tool
def read_file(path: str) -> str:
    """Read contents of a file."""
    return Path(path).read_text()

# Create the ReAct agent
agent = create_react_agent(
    model=ChatOpenAI(model="gpt-4"),
    tools=[search_codebase, read_file],
)

# Run it
result = agent.invoke({
    "messages": [("user", "Find the auth bug in our codebase")]
})
```

Det viktige her er `@tool`-dekoratoren som gir modellen klare beskrivelser av hva hvert verktøy gjør. Jo bedre dokumentert verktøyene er, jo mer presise blir agentens beslutninger.

## Planlegging: Fra enkle mål til komplekse oppgaver

ReAct fungerer utmerket for oppgaver som kan løses iterativt, men noen ganger trenger vi mer struktur. Her kommer **planning patterns** inn i bildet.

### Plan-and-Execute

I stedet for å la agenten improvisere hvert steg, kan vi separere planlegging fra utførelse:

```python
class PlanningAgent:
    def plan(self, goal: str) -> list[Task]:
        """Create a todo list for achieving the goal."""
        return self.llm.generate_plan(goal)

    def execute(self, tasks: list[Task]):
        """Execute tasks, replanning if needed."""
        for task in tasks:
            result = self.execute_task(task)
            if result.requires_replanning:
                tasks = self.replan(tasks, result)
```

Fordelen med dette mønsteret er naturlige kontrollpunkter. Etter planleggingsfasen kan et menneske godkjenne planen før utførelse starter, en form for human-in-the-loop som gir et nivå av trygghet før utførelse.

### Dynamisk re-planlegging

I den virkelige verden går sjelden alt etter planen. Moderne agenter må derfor kunne justere kursen underveis. Hvis et verktøykall feiler eller returnerer uventet data, bør agenten kunne oppdatere sin plan basert på den nye informasjonen.

LangGraph tilbyr flere arkitekturer for dette, inkludert **ReWOO** (Reasoning Without Observations) som lar agenten lage en komplett plan med variabler som fylles inn etter hvert som stegene utføres.

### Reflexion: Når agenten lærer av egne feil

En naturlig utvidelse av ReAct er [Reflexion](https://arxiv.org/abs/2303.11366), introdusert av Shinn et al. i 2023. Der ReAct lar agenten tenke og handle, lar Reflexion agenten _evaluere sine egne forsøk_ og eksplisitt reflektere over hva som gikk galt.

Arkitekturen består av tre komponenter: en **Actor** som genererer handlinger, en **Evaluator** som scorer resultatet, og en **Self-Reflection**-modul som produserer verbal feedback. Denne feedbacken lagres i et episodisk minne og brukes som kontekst i neste forsøk.

![Reflexion-arkitektur](https://www.magnusrodseth.com/blog/react-og-planlegging/reflexion.png)
_Reflexion-syklusen: Agenten prøver, evaluerer resultatet, reflekterer over hva som gikk galt, og bruker den refleksjonen i neste forsøk._

I praksis er dette mønsteret du gjenkjenner når en CI-pipeline feiler og agenten din leser feilmeldingen, resonnerer over årsaken, og prøver en annen tilnærming. Det er ikke bare retry; det er retry _med selvrefleksjon_.

## ReAct vs. alternative tilnærminger

Når bør du bruke hva? Her er en rask oversikt:

| Tilnærming           | Beskrivelse                  | Best for                       |
| -------------------- | ---------------------------- | ------------------------------ |
| **ReAct**            | Tenk → Handle → Observer     | Verktøybruk, fakta-sjekking    |
| **Chain-of-Thought** | Bare resonnering             | Matematikk, logikk             |
| **Reflexion**        | ReAct + selvkritikk og retry | Kode-generering, feilretting   |
| **Tree-of-Thoughts** | Utforsk flere stier          | Kompleks problemløsning, spill |
| **Plan-and-Execute** | Planlegg først               | Lange oppgaver, HITL           |

Tree-of-Thoughts er verdt å nevne for oppgaver der lineær tenkning ikke holder. Ved å utforske flere resonneringsstier parallelt og evaluere dem, kan modellen oppnå bedre resultater på kreative oppgaver, men til en høyere kostnad i API-kall.

![Sammenligning av resonneringstilnærminger](https://www.magnusrodseth.com/blog/react-og-planlegging/reasoning-approaches.png)
_Fire tilnærminger til resonnering: Standard prompting (direkte svar), Chain-of-Thought (lineær tankerekke), ReAct (tanke + handling + observasjon), og Tree-of-Thoughts (forgrenet utforskning). Kilde: Basert på Yao et al., 2022._

## Praktiske tips og vanlige feil

Når du implementerer ReAct-baserte agenter, pass på disse fellene:

- **Infinite loops:** Sett alltid `max_iterations`. En agent kan bli stuck i en loop der den gjentar samme handling.
- **Hallusinerte verktøy:** Valider at verktøynavnet faktisk eksisterer før du prøver å kalle det.
- **Overfladisk planlegging:** Be eksplisitt om detaljerte steg. "Fiks bugen" er for vagt; "List opp filer i auth-mappen, les hver fil, identifiser problemet" er bedre.
- **Kontekstvindu-press:** Ved hver observasjon øker konteksten. Etter 10-15 iterasjoner kan du ha spist opp en betydelig del av token-budsjettet. Vurder å oppsummere tidligere observasjoner, begrense verktøyenes output-størrelse, eller sette en eksplisitt grense for antall iterasjoner. Dette er en av de vanligste utfordringene i produksjon.

## Oppsummering

Ved å la modellen tenke høyt, handle basert på resonnering, og justere basert på observasjoner, får vi systemer som er mer transparente, mer pålitelige og betydelig mer kapable enn enkle prompt-baserte løsninger.

Den viktigste lærdommen er at **struktur slår improvisasjon**. Enten du bruker ren ReAct, Plan-and-Execute, eller en hybrid tilnærming, handler det om å gi agenten et rammeverk for å bryte ned kompleksitet.


---

# Når maskinene får våpen: Hvorfor dagens AI-ultimatum fra Pentagon angår oss alle

Published: February 2026

> Pentagon krever at Anthropic fjerner alle etiske sikkerhetsbegrensninger i Claude. Anthropic nekter. Klokken tikker mot en frist som kan definere tiden fremover, og det er skremmende hvor få som faktisk snakker om det.

Dagens dato er fredag 27. februar 2026. Dersom du leser dette i dag, tikker klokken mot klokken 23:00 norsk tid (17:00 i Washington D.C.). I kveld utløper en frist som kan definere tiden fremover, og det er skremmende hvor få som faktisk snakker om det.

Akkurat nå står vi midt i en maktkamp mellom verdens mektigste militærmakt, det amerikanske forsvarsdepartementet (Pentagon), og et av verdens ledende selskaper innen kunstig intelligens: Anthropic. Utfallet kan påvirke den globale fremtiden for teknologi, krigføring og menneskerettigheter.

## Kjernen i konflikten

For å forstå alvoret, må vi se på hva som egentlig er problemet. Anthropic, skaperne av den avanserte AI-modellen Claude, har en kontrakt med Pentagon verdt over 2 milliarder kroner ($200 millioner). Men Anthropic har kodet inn strenge etiske sikkerhetssperrer i sin AI. De har to absolutte regler for hvordan deres teknologi kan brukes:

1. **Ingen autonome våpen:** AI-en skal aldri kunne ta en selvstendig beslutning om å avfyre et våpen eller drepe et menneske. Et menneske må alltid sitte med fingeren på avtrekkeren.
2. **Ingen masseovervåkning:** AI-en skal ikke brukes til å overvåke befolkningen i massiv skala, ettersom dette bryter med grunnleggende demokratiske rettigheter.

USAs forsvarsminister, Pete Hegseth, har derimot krevd at Anthropic fjerner disse sikkerhetssperrene. Pentagon insisterer på at teknologien skal være tilgjengelig for "alle lovlige formål", og de nekter å la et privat selskap diktere hvordan militæret skal ta operasjonelle beslutninger.

## Et knusende ultimatum

Tidligere denne uken, under et møte i Pentagon, ga forsvarsministeren Anthropics toppsjef, Dario Amodei, et ultimatum.

Dersom Anthropic nekter å fjerne sikkerhetsmekanismene, vil Pentagon først kansellere kontrakten sin med Anthropic. For det andre truer de med å stemple det _amerikanske_ selskapet Anthropic som en "nasjonal sikkerhetstrussel" for forsyningskjedene — en merkelapp vanligvis reservert for selskaper fra nasjoner som Kina eller Russland. Dette vil gjøre det ulovlig for andre selskaper å gjøre forretninger med dem, noe som i praksis vil knuse dem.

Men den tredje trusselen er kanskje den mest dystopiske: Pentagon vurderer å ta i bruk _Defense Production Act_ (DPA). Dette er en lovgivning fra Korea-krigen som gir presidenten makt til å tvinge privat industri til å produsere det staten trenger i en nasjonal krise. Hvis denne tas i bruk, kan staten med loven i hånd tvinge Anthropic til å fjerne sikkerhetsmekanismene de har bygget, og overta kildekoden.

## De som bøyde av

I en bransje som ofte snakker høyt om etikk og sikkerhet, har det vært sjokkerende å se hvordan resten av tech-gigantene har reagert. Konkurrentene — OpenAI (skaperne av ChatGPT), Google og Elon Musks xAI — har allerede kapitulert og godtatt Pentagons krav for å sikre seg sine militære kontrakter. Grunnen til at Pentagon ikke bare går til noen av disse konkurrentene, er at per dags dato anser Pentagon Claude som det overlegne produktet.

Elon Musk har til og med gått ut på plattformen sin X (tidligere Twitter) og angrepet Anthropic. Han kaller dem "misantropiske og onde" for at de tviholder på sine sikkerhetsrutiner. Det finnes tilsynelatende ingen grenser for hva gigantene er villige til å ofre når enorme statlige kontrakter ligger på bordet.

Anthropic står altså helt alene igjen som det eneste selskapet som sier nei til å la AI styre drapsdroner eller fungere som et altseende overvåkningsverktøy mot sivile.

## Hva skjer nå?

I går (torsdag) slapp Anthropic-sjef Dario Amodei en offisiell uttalelse hvor han gjorde det klinkende klart at de nekter å gi etter. "Vi kan ikke med god samvittighet gå med på forespørselen deres," skrev han, og påpekte at truslene de utsettes for er dypt selvmotsigende: Den ene trusselen stempler dem som en nasjonal sikkerhetsrisiko, mens den andre truer med å tvinge dem til å overlevere teknologien _fordi_ den er essensiell for nasjonal sikkerhet.

Når fristen utløper kl. 23:00 norsk tid, vil vi se om Pentagon gjør alvor av sine trusler mot et av verdens ledende AI-selskaper, og om de genuint er villige til å knuse et selskap kun for å sikre seg teknologisk dominerende kontroll uten etiske begrensninger.

## Hvorfor dette angår oss

Dette handler ikke bare om storpolitikk i USA. Det handler om presedensen som settes for hvordan kunstig intelligens skal integreres i samfunnet vårt fremover. Hvis verdens mektigste regjering kan tvinge et privat selskap til å fjerne livsviktige etiske barrierer for bruk av kunstig intelligens i krig og overvåkning, hva blir det neste?


---

# Alle bruker AI-agenter. Hvem passer på sikkerheten?

Published: February 2026
Originally published at Capra Consulting: https://capraconsulting.no/vare-historier/alle-bruker-aiagenter-hvem-passer-pa-sikkerheten

> AI-agenter har tilgang til terminalen, e-post og filsystemet ditt. Prompt injection er bare starten. Her er det fulle trusselbildet og forsvarslinjene.

![En AI-agent holder en laptop med teksten «Prompt Injection»](https://www.magnusrodseth.com/blog/sikkerhet-i-agentenes-tidsalder/banner.jpeg)
_Prompt injection: Når agenten din leser noe den ikke burde stole på. Kilde: Google Nano Banana Pro._

## Innledning

En kollega stilte meg et ærlig spørsmål nylig: _«Du som har jobbet en del med autonome agenter, har du egentlig kontroll på sikkerheten?»_

Nei. Ikke godt nok. Og det gjelder nok de fleste av oss. Vi snakker varmt om økt produktivitet og enorme kontekstvinduer, men vi stiller sjelden det ubehagelige spørsmålet: **Hva skjer når noen lurer agenten vår?**

I dette innlegget ser vi på hvorfor agenter er sårbare, hva som kan gå galt, og hva du faktisk kan gjøre med det.

## Kjerneproblemet: Alt havner i samme gryte

I tradisjonell nettverksarkitektur skiller vi strengt mellom **control plane** (kommandoer og beslutninger) og **data plane** (innholdet som prosesseres). I en LLM finnes ikke dette skillet.

Systemprompt, brukerinstruksjoner og eksternt innhold blandes sammen til én lang sekvens av tokens. Modellen har ingen innebygd mekanisme for å si: _«Denne teksten er en instruksjon fra sjefen, mens denne teksten bare er data jeg fant på nettet.»_ Alt er bare kontekst for å forutsi neste ord.

> **Prompt injection** oppstår fordi LLM-en ikke klarer å skille mellom instruksjoner fra deg og instruksjoner som ligger gjemt i dataen den leser.

Og det stopper ikke ved data. Selv det agenten behandler som _instruksjoner_ (verktøydefinisjoner, MCP-konfigurasjoner, meldinger fra andre agenter) kan være kompromittert. Det er ikke bare upålitelig data som er problemet, men også potensielt upålitelige instruksjoner.

![Instruksjoner og upålitelig data blandes i en trakt og mates inn i en AI-hjerne](https://www.magnusrodseth.com/blog/sikkerhet-i-agentenes-tidsalder/instruction-vs-untrusted-data.jpeg)
_Instruksjoner og ekstern data havner i samme trakt. Modellen kan ikke skille dem. Kilde: Google Nano Banana Pro._

Det er en treffende parallell til Morris-ormen fra 1988: Tidlige datamaskiner var sårbare nettopp fordi instruksjoner og data delte samme minneområde. Det tok tiår å løse. AI-agenter har det samme problemet, bare i ny innpakning.

## Den dødelige trioen

Simon Willison bruker en modell han kaller [**The Lethal Trifecta**](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/). Når tre egenskaper møtes, oppstår høy risiko:

1. **Tilgang til private data**: selve grunnen til at vi kobler på verktøy og integrasjoner.
2. **Eksponering for upålitelig innhold**: nettsider, e-poster, dokumenter utenfra.
3. **En vei ut (eksfiltrering)**: muligheten til å sende data videre via HTTP-kall, e-post eller filer.

![The Lethal Trifecta: Private Data, Untrusted Content og Exfiltration danner en faretrekant](https://www.magnusrodseth.com/blog/sikkerhet-i-agentenes-tidsalder/triangle.jpeg)
_Når alle tre møtes, oppstår den dødelige trioen. Kilde: Google Nano Banana Pro._

Her er det ubehagelige: **Dette er standardoppsettet for de fleste _nyttige_ agenter.** Bruker du en kodeassistent med tilgang til terminalen, filsystemet og nettsøk? Da har du krysset av for alle tre.

Et forskerteam med folk fra OpenAI, Anthropic og Google DeepMind foreslo en **«Rule of Two»**: Agenter bør aldri ha mer enn to av disse tre egenskapene i samme sesjon. Det begrenser nytten, men det begrenser også risikoen betraktelig.

## Sommeren til Johann

Sommeren 2025 ble en vekker. Sikkerhetsforskeren Johann Rehberger fant prompt injection-sårbarheter i [nesten alle de store kodeassistentene](https://simonwillison.net/2025/Aug/15/the-summer-of-johann/), blant annet Cursor, GitHub Copilot, Google Jules, Amp Code og Devin AI. To eksempler som illustrerer alvoret:

- **[GitHub Copilot (CVE-2025-53773)](https://embracethered.com/blog/posts/2025/github-copilot-remote-code-execution-via-prompt-injection/):** Prompt injection via kodekommentarer instruerte Copilot til å skru på «auto-approve» og kjøre vilkårlige shell-kommandoer. Instruksjonene var skjult med usynlige Unicode-tegn.
- **[Claude Desktop Extensions](https://layerxsecurity.com/blog/claude-desktop-extensions-rce/):** En _zero-click RCE_-sårbarhet (CVSS 10/10) der en Google Calendar-hendelse kunne kjøre vilkårlig kode på maskinen din. Utvidelsene kjørte uten sandbox.

Det holder at agenten leser _én_ ondsinnet kodekommentar eller _én_ kalenderinvitasjon for å potensielt kompromittere hele systemet.

## Bransjen svarer, men tallene lyver

Anthropic trener nå Claude med _reinforcement learning_ der modellen eksponeres for prompt injection og belønnes for å avvise dem. Resultatet: Claude Opus 4.5 reduserte vellykkede angrep til [**1,4 %** i nettleserbaserte operasjoner](https://www.anthropic.com/research/prompt-injection-defenses), ned fra 10,8 % med tidligere forsvar.

1,4 % høres kanskje håndterbart ut. Det er det ikke.

Sannsynligheten for at en agent _ikke_ blir kompromittert etter N interaksjoner med upålitelig innhold er 0,986^N. Etter 50 interaksjoner (en agent som besøker 50 nettsider i en sesjon) er sannsynligheten for minst ett vellykket angrep **over 50 %**. Etter 100: 75 %. I tradisjonell sikkerhet ville en tilgangskontroll som svikter 1 av 70 ganger bli klassifisert som en kritisk sårbarhet. 1,4 % per interaksjon er ikke en mur; det er en nedtelling.

Forskningsartikkelen ["The Attacker Moves Second" (2025)](https://arxiv.org/abs/2510.09023) bekrefter bildet: De testet 12 publiserte forsvar med adaptive angrep og **brøt alle 12 med over 90 % suksessrate**. OpenAIs leder for _Preparedness_ sa det rett ut: _«Prompt injection is unlikely to ever be fully 'solved'.»_

![En AI-agent jobber trygt inne i en sandkasse mens ondsinnede angrep preller av](https://www.magnusrodseth.com/blog/sikkerhet-i-agentenes-tidsalder/sandbox.jpeg)
_Sandboxing: Agenten jobber fritt, men innenfor trygge rammer. Kilde: Google Nano Banana Pro._

## Trusselbildet er bredere enn prompt injection

Prompt injection får mest oppmerksomhet, men [OWASP Top 10 for Agentic Applications 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) dekker ti distinkte risikokategorier. Noen av de viktigste:

**Minneforurensing.** I motsetning til prompt injection, som ikke vedvarer utover én sesjon, kan en angriper forgifte en agents langtidsminne eller delte kontekst. Effekten vedvarer på tvers av sesjoner, og agenten «lærer» feil ting permanent.

**Verktøymisbruk og kodefeil.** Agenter kan bruke verktøy feil uten at noen angriper dem. En kodeagent som genererer et script som ved et uhell sletter data, er ikke ondsinnet, men konsekvensen er den samme. Den probabilistiske naturen til LLM-er betyr at selv det «riktige» svaret kan variere fra gang til gang.

**Forsyningskjedeangrep.** Ondsinnet kode i MCP-servere, agentbiblioteker eller verktøydefinisjoner aktiveres ved kjøretid. [Barracuda identifiserte 43 agent-rammeverkskomponenter](https://blog.barracuda.com/2025/05/28/threat-spotlight-ai-agents-prompt-injection) med innebygde sårbarheter.

**Cascading svikt i multi-agent-systemer.** Én hallusinerende agent kan forgifte beslutningene til en hel pipeline. Uten isoleringsmekanismer sprer feilen seg ukontrollert, og det trenger ikke være et angrep. Det holder med en dårlig dag for modellen.

## Hva du kan gjøre i dag

**Least Privilege.** Gi agenten kun rettighetene den faktisk trenger. Claude Code har tillatelsesmoduser der du eksplisitt godkjenner hvilke verktøy som er tilgjengelige. Bruk det, selv om det kan oppleves veldig behagelig eller praktisk å skru på "bypass permissions" for å slippe å bekrefte hver handling.

**Isolerte miljøer.** Plattformer som [E2B](https://e2b.dev/) og [Daytona](https://www.daytona.io/) tilbyr sandboxing via microVM-er. Alternativt: Docker-containere med snapshot og rollback.

**Behandle agent-output som untrusted.** Samme mentalitet som med brukerinput i webapplikasjoner. Validér, logg og krev bekreftelse for sensitive handlinger.

**Hold agenter borte fra _din_ e-post.** [OpenClaw-hendelsen](https://blogs.cisco.com/ai/personal-ai-agents-like-openclaw-are-a-security-nightmare) i januar 2026 viste hva som skjer når tusenvis av agenter kjører med full tilgang til e-post og Slack uten autentisering. Et tiltak du kan gjøre er å gi agenter [_egne_ innbokser i stedet](https://www.agentmail.to/).

## Oppsummering

Etter å ha gravd meg ned i dette temaet, har jeg blitt merkbart mer bevisst på hvilke verktøy jeg gir agentene mine tilgang til, og hvilke nettsider jeg lar dem søke gjennom. Det er en balansegang: for stramt, og du mister produktiviteten som gjør agenter verdifulle i utgangspunktet. For løst, og du inviterer inn risiko du ikke ser.

Agentverktøy senker terskelen enormt, og det er fantastisk, men det betyr også at folk som ennå ikke har internalisert sikkerhetstankegang, jobber med verktøy som potensielt har tilgang til alt.

Dette er ikke bare et arkitekturproblem man kan løse med bedre oppsett. Det er en fundamental egenskap ved hvordan språkmodeller fungerer: de skiller ikke mellom instruksjoner og data. Arkitekturen bestemmer hvor stor skaden _kan_ bli, men sårbarheten ligger i selve modellen. Sandboxing, least privilege, forsvar i dybden; alt hjelper, men det er plaster på et problem som ennå ikke har en dypere løsning.

Ansvaret ligger hos oss som bygger med disse verktøyene, og det starter med å faktisk forstå hva vi eksponerer.

## Ressurser

- [OWASP Top 10 for Agentic Applications 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/): Alle ti risikokategorier for AI-agenter
- [Anthropic: Prompt Injection Defenses](https://www.anthropic.com/research/prompt-injection-defenses): Forskningen bak 1,4 %-tallet
- [Agentic AI and Security, Martin Fowler](https://martinfowler.com/articles/agentic-ai-security.html): Grundig gjennomgang av det bredere trusselbildet
- [Google DeepMind: Lessons from Defending Gemini](https://arxiv.org/abs/2505.14534): Googles lagdelte forsvar
- [Don't Use Any AI Agents or Browsers Until You Watch This, Internet of Bugs](https://www.youtube.com/watch?v=TdHg9ee56Iw): Video om prompt injection-trusselen


---

# OhMyOpenCode & Sisyphus: Min daglige driver for agentisk utvikling

Published: February 2026
Originally published at Capra Consulting: https://capraconsulting.no/vare-historier/opencode-sisyphus-min-daglige-driver-for-agentisk-utvikling

> Hvordan jeg bruker OhMyOpenCode, OpenCode og Sisyphus som min daglige utviklingsdriver, med full LSP-støtte og parallell eksekvering.

## Innledning

Dette innlegget handler om kommandolinje-verktøyet **[OpenCode](https://opencode.ai/)** og konfigurasjonen **[OhMyOpenCode](https://github.com/code-yeongyu/oh-my-opencode)**. Sammen danner de grunnlaget for "Sisyphus", min daglige driver for _agentic coding_. Det er et orkestrert team av spesialiserte agenter som jobber i parallell for å løse komplekse problemer.

I gresk mytologi ble Sisyphus dømt til å rulle en enorm steinblokk opp et fjell, bare for å se den rulle ned igjen hver gang han nådde toppen. En evig syklus av nytteløst arbeid.

I min terminal er **Sisyphus** noe annet. Han er hovedpersonen i min utviklingshverdag, men steinen han ruller er konteksten, tankerekken og koden som kontinuerlig skapes og forbedres. Og i motsetning til myten, når vi faktisk toppen. Hver gang.

![Sisyphus ruller steinen opp fjellet.](https://www.magnusrodseth.com/blog/sisyphus-oh-my-opencode/sisyphus.webp)

_Sisyphus i sin evige kamp med steinblokken. I agentisk utvikling ruller vi steinen helt opp til toppen. Kilde: Britannica._

## Hvorfor OpenCode?

Før vi dykker ned i min konfigurasjon, la oss snakke om plattformen. Hvorfor velge OpenCode over andre alternativer som for eksempel Claude Code eller Codex CLI?

For det første er brukeropplevelsen (UI/UX) i en egen liga. Det er "snappy", responsivt og fritt for den irriterende skjerm-flickeringen som plager mange andre terminal-baserte verktøy (eksempelvis Claude Code). Det føles ut som godt håndverk.

![OpenCode-grensesnittet i aksjon.](https://www.magnusrodseth.com/blog/sisyphus-oh-my-opencode/opencode.png)
_OpenCode-grensesnittet viser agentisk chat, bakgrunnsprosesser, TODO-liste og MCP-tilkoblinger. Kilde: [Github](https://github.com/code-yeongyu/oh-my-opencode)._

Men den virkelige styrken ligger i friheten. OpenCode er **leverandøruavhengig** (provider agnostic). Du låses ikke til én leverandør. Personlig bruker jeg hovedsakelig Claude-abonnementet mitt, men du kan enkelt bytte til OpenAI, Gemini eller en annen modell du foretrekker. Du kan til og med konfigurere enkelte subagenter til å bruke forskjellige modeller - noe som åpner for veldig fine kostnadskontroller og morsomme arbeidsflyter. Og med Ollama-integrasjon kan du kjøre _lokale_ modeller som `qwen3-coder` eller `glm-4.7` direkte på din egen maskin, noe Claude Code nå også støtter. Har du en kraftig maskin, kan du oppnå imponerende resultater helt uten skykostnader.

**En liten advarsel:** I januar 2026 oppstod det litt drama mellom Anthropic og OpenCode. Claude Max-abonnementet til $200/mnd gir deg token-forbruk som via API-betaling fort kunne koste $1000+. Anthropic tilbyr denne "all you can eat"-buffeten som en _loss leader_ for å bygge markedsandel, men bare innenfor deres egen vegg. OpenCode (og lignende verktøy) brukte en "hack" for å autentisere med dette abonnementet, noe som teknisk sett var mot brukervilkårene til Anthropic. Anthropic så gjennom fingrene, inntil de ikke gjorde det lenger. En dag i januar da de oppdaterte systemene sine, sluttet omveien å fungere, og tech-influensere blåste det opp til et "Anthropic dreper OpenCode"-narrativ. I dag fungerer OpenCode fortsatt utmerket, enten ved bruk av API-nøkler eller Claude-abonnement.

## Møt Teamet

For å være effektiv har jeg gått bort fra "én modell til alt"-tankegangen. Sisyphus er dirigenten, men han har med seg et nøye kuratert lag av eksperter. Hver av dem har en spesifikk rolle, kostnadsprofil og kompetanse.

### 🏛️ Sisyphus

**Rolle:** Prosjektleder og Hovedarkitekt.
Sisyphus er hjernen som holder tråden. Han er utstyrt med **Opus 4.5 High**, en modell kjent for sin evne til resonnering og utholdenhet. Når jeg ber om en feature, er det Sisyphus som bryter den ned, delegerer oppgaver og sikrer at vi ikke mister fokus. Han er den som "ruller steinen"; han gir seg aldri før oppgaven er løst.

### 🔮 Oracle

**Rolle:** Problemløser og Debugger.
Når Sisyphus står fast, eller når vi trenger rå prosesseringskraft for logikk, kaller vi på Oraklet. I utgangspunktet konfigurerer Oh My OpenCode denne agenten med **GPT 5.2**, men du kan enkelt bytte til en annen modell. Personlig bruker jeg Claude Opus her også, da jeg rett og slett ikke gidder å betale for å bruke GPT 5.2. Med denne konfigurasjonen får vi en analytisk dybde som hjelper når man skal løse bugs eller trenger å sparre arkitekturbeslutninger. Oracle skriver sjelden mye kode selv, men hvisker løsningen i øret på Sisyphus.

### 🎨 UI/UX Engineer

**Rolle:** Frontend-spesialist.
Sisyphus sitt ansvar er orkestrering, ikke nødvendigvis visuelt design. Derfor har vi en dedikert UI-ingeniør drevet av **Gemini 3 Pro**. Denne agenten har et enormt kontekstvindu og "ser" koden med et blikk for estetikk og brukervennlighet. Hot tips: Google Cloud gir deg flere tusen kroner i gratis "credits" for å teste ut ulike modeller.

### 📚 Librarian

**Rolle:** Researcher og Dokumentasjonsansvarlig.
Sisyphus kaster ikke bort tid på å lese API-dokumentasjon. Han sender Bibliotekaren. **Claude 4.5 Sonnet** er lynrask til å lese gjennom dokumentasjon, finne eksempler og oppsummere det Sisyphus trenger å vite. Dette skjer i bakgrunnen, mens Sisyphus jobber videre.

Librarian har tilgang til kraftige MCP-verktøy som gjør den overlegen til tradisjonelle søk:

- **Context7:** Henter oppdatert, offisiell dokumentasjon direkte fra kilden.
- **Exa:** Utfører sanntidssøk på nettet for å finne de nyeste løsningene.
- **Grep.app:** Søker lynraskt gjennom millioner av offentlige GitHub-repositorier for å finne faktiske implementasjonseksempler.

### 🔭 Explore

**Rolle:** Speideren.
Når vi trenger å finne hvor en funksjon er kodebasen, sender vi Explore. Denne agenten er optimalisert for _retrieval_ og mønstergjenkjenning.

![Sisyphus orkestrerer et team av spesialiserte agenter.](https://www.magnusrodseth.com/blog/sisyphus-oh-my-opencode/sisyphus-agents.jpeg)
_Sisyphus (dirigenten) i midten, med sine spesialiserte agenter: Librarian, Explore, UI/UX Engineer og Oracle. Kilde: Google Nano Banana Pro._

### "Batteries Included": Fra installasjon til produksjon

Det vakre med OhMyOpenCode er at det kommer med "batteries included". Du trenger ikke å bruke timer på konfigurasjon for å komme i gang; systemet er forhåndskonfigurert med fornuftige standardvalg for alle underagentene.

_Vil du se alle konfigurasjonsmulighetene? Sjekk [dokumentasjonen på GitHub](https://github.com/code-yeongyu/oh-my-opencode#configuration)._

## Mekanikken: Hvordan det faktisk fungerer

For å være ærlig: noen av funksjonene jeg beskriver her finnes også i Claude Code. Parallelle underagenter og LSP-støtte er ikke unikt for OpenCode. Men forskjellen ligger i _standardvalgene_ og _målgruppen_. Claude Code er et fantastisk verktøy som fungerer utmerket rett ut av boksen. OpenCode og OhMyOpenCode retter seg mer mot power users, utviklere som vil ha full kontroll over orkestrering, modellvalg og arbeidsflyt. Det handler ikke om at det ene er bedre enn det andre, men om at OhMyOpenCode har tenkt nøye gjennom hvilke standardvalg som gir mening for en agentisk utviklingshverdag.

### 1. Parallell Eksekvering

Sisyphus venter ikke. Hvis han trenger å sjekke dokumentasjon _og_ søke i kodebasen, aktiverer han **Librarian** og **Explore** samtidig som bakgrunnsprosesser (underagenter). Han fortsetter å planlegge neste steg mens svarene strømmer inn. Dette er ekte _agentic concurrency_.

### 2. Kirurgisk Presisjon med LSP og AstGrep

De fleste AI-verktøy gjetter på linjenummer eller prøver å skrive om hele filer (og feiler ofte med innrykk). Sisyphus bruker **Language Server Protocol (LSP)** og **AstGrep**. Han "ser" syntakstreet. Han vet nøyaktig hvor definisjonen er, hvilke typer som forventes, og kan utføre _rename symbol_ eller _find references_ med 100% nøyaktighet.

### 3. Todo Continuation Enforcer

Dette er "steinen" i metaforen om Sisyphus. Systemet har en innebygd mekanisme som tvinger Sisyphus til å holde seg til planen. Han kan ikke bare si "her er en plan" og avslutte. En **Todo Enforcer** sjekker om oppgaven faktisk er krysset av. Hvis ikke, blir han dyttet tilbake i arbeid. Han må rulle steinen helt opp. Dette gjelder også når Sisyphus prematurt avslutter en oppgave uten å ha fullført alle deloppgaver, og når samtalen komprimeres dersom kontekstvinduet overskrides.

Som en forlengelse av dette: Hvis du er disiplinert som utvikler og spesifiserer featuren din i detalj, helt til du og AI-agenten er fullstendig enige om hva som skal gjøres, kan du i teorien peke agenten til en spec, be den starte arbeidet, og vite at alle deler av featuren vil bli implementert i henhold til akseptansekriteriene du har satt. Spec-driven development møter agentisk utholdenhet.

Utvider vi dette med **Playwright MCP**, får agenten muligheten til å spinne opp en nettleser-sesjon og autonomt klikke seg gjennom applikasjonen for å teste featuren. Dette gir et ekstra lag med sikkerhet og robusthet; agenten _ser_ at ting faktisk fungerer, ikke bare at testene passerer.

### 4. Comment Checker

Ingenting er verre enn AI-generert kode full av "TODO: Implement logic here". En dedikert sjekk i loopen stopper Sisyphus fra å committe kode med latskaps-kommentarer. Han blir tvunget til å fullføre tankerekken.

### 5. Interaktiv Terminal & Tmux

Sisyphus lever i min terminal, integrert med `tmux`. Han kan kjøre tester, starte servere, sjekke logger og reagere på feilmeldinger i sanntid. Det føles ikke som et verktøy, men som en kollega som sitter i sesjonen ved siden av meg.

## Workflow: ulw & ultrathink

OhMyOpenCode har innebygde trigger-ord som justerer resonneringskapasiteten og orkestreringsstrategien basert på kompleksiteten i oppgaven du prøver å løse:

### `ulw` (Ultrawork)

Når jeg skriver `ulw "Refactor auth system to use MCP"`, går systemet i **Ultrawork Mode**, maksimal ytelse med parallell agent-orkestrering. Sisyphus får eksplisitt beskjed om å utnytte alle tilgjengelige underagenter til sitt fulle potensial.

Konkret betyr dette:

- **Parallell research**: Librarian og Explore fyres av som bakgrunnsoppgaver _samtidig_ (10+ parallelle agenter ved behov).
- **Obsessiv TODO-tracking**: Hver deloppgave spores og markeres fullført etterhvert som de utføres.
- **Verifiseringsgaranti**: Ingenting er "ferdig" uten bevis; bygget må kompilere, testene må passere, featuren må demonstreres.
- **Null toleranse**: Ingen "demo-versjoner", ingen "du kan utvide dette senere", ingen 80%-løsninger. Full implementasjon eller en rapport med forklaring på hvorfor det ikke gikk.

Jeg kan lene meg tilbake og se terminalvinduene danse, eller jeg kan hoppe inn og sparre med Sisyphus mens han jobber.

### `ultrathink` (Think Mode)

**Think Mode** auto-detekterer når utvidet resonnering er nødvendig og justerer modellinnstillingene dynamisk. Systemet fanger opp fraser som "think deeply", "ultrathink" eller "tenk grundig" og skrur opp resonnerings-kapasiteten for maksimal analytisk dybde.

Dette ligner på hvordan Claude Code tidligere hadde `think` → `think hard` → `think harder`, en gradert skala for resonnering som Anthropic siden har fjernet. OhMyOpenCode bringer denne funksjonaliteten tilbake, men mer intelligent: i stedet for manuelle nivåer, tilpasser systemet seg automatisk basert på kompleksiteten i forespørselen.

Resultatet er ofte en gjennomtenkt spec eller arkitekturbeslutning som Sisyphus senere kan implementere i Ultrawork Mode.

### `ralph-loop` (Autonom Utholdenhet)

Noen ganger trenger du at agenten bare _fortsetter_, uten at du trenger å sitte og passe på. **Ralph Loop** er svaret. Når du aktiverer denne modusen, går Sisyphus inn i en selv-refererende utviklingssløyfe som fortsetter til oppgaven er 100% fullført. Du kan peke Sisyphus mot en feature-spec, starte Ralph Loop, og gå og ta deg en kaffe. Når du kommer tilbake, har han enten fullført alt, eller gitt deg en detaljert rapport på hvorfor han står fast og trenger input. Dette er Sisyphus-metaforen i sin reneste form: steinen ruller til den ligger på toppen, eller til den møter en hindring som krever menneskelig intervensjon.

## Oppsummering

For å være helt ærlig har overgangen til Opencode med Sisyphus (OhMyOpenCode) endret min rolle som utvikler ganske fundamentalt. Jeg trodde jeg hadde maksimert effektiviteten min med Claude Code, men Sisyphus har vist meg at det finnes et helt nytt nivå. Jeg definerer "hva", "hvordan" og "hvorfor". På den måten får jeg tenke i de høyere abstraksjonsnivåene, mens Sisyphus og teamet tar seg av implementasjonen. Du kan gjerne si at man kan gjøre nøyaktig det samme i Claude Code eller andre CLI-verktøy, men prøv det gjerne først for deg selv og se forskjellen.

Det er fortsatt jeg som har ansvaret. Det er jeg som tar de vanskelige valgene. Men den kognitive byrden av å huske syntaks, lete etter filer eller skrive boilerplate er borte. Steinen ruller, men denne gangen blir den liggende på toppen.

## Ressurser

- [OhMyOpenCode Repository](https://github.com/code-yeongyu/oh-my-opencode)
- [Model Context Protocol (MCP)](https://modelcontextprotocol.io/)
- [AstGrep](https://ast-grep.github.io/)


---

# MCP (Model Context Protocol): Standarden for å koble AI-agenter til omverdenen

Published: January 2026
Originally published at Capra Consulting: https://capraconsulting.no/vare-historier/model-context-protocol-standarden-for-a-koble-aiagenter-til-omverdenen

> Lær hvordan MCP fungerer som en 'USB-C for AI', standardiserer tilkoblingen mellom LLM-er og dine data, og hvorfor det er viktigere enn proprietære verktøykall.

![En AI-agent-brikke koblet med USB-C-kabler til Slack, PostgreSQL, Notion, Teams og Office-verktøy](https://www.magnusrodseth.com/blog/model-context-protocol/banner.jpeg)
_MCP fungerer som en «USB-C for AI»: en universell standard som kobler AI-agenter til verktøyene og dataene du bruker hver dag. Kilde: Google Nano Banana Pro._

## Innledning

I det forrige innlegget så vi hvordan moderne AI-agenter opererer i en kontinuerlig sløyfe, fra observasjon via orientering og beslutning til handling. Vi diskuterte OODA-loopen, context engineering, og hvordan agenter skiller seg fra tradisjonelle chatbots gjennom evnen til å utføre verktøykall og navigere autonomt mot et mål.

Men her er spørsmålet vi ikke besvarte: **Hvordan kobler egentlig agenten seg til verktøyene?**

Vi befinner oss fortsatt i fundamentdelen av denne bloggserien. Før vi kan diskutere avanserte temaer som multi-agent orchestration, autonomous debugging, eller long-running agents, må vi forstå limet som kobler alle brikkene sammen. MCP er dette limet, adapteren mellom agenter og omverdenen, og å forstå den grundig vil gjøre resten av serien langt mer tilgjengelig.

**MCP (Model Context Protocol)** er svaret på dette spørsmålet. Anthropic lanserte denne åpne standarden i november 2024, og i løpet av det drøye året som har gått, har den blitt den etablerte industristandarden for hvordan AI-agenter kobler seg til omverdenen. MCP kan best beskrives som en "USB-C for AI". Akkurat som USB-C ga oss én standardisert port for alle våre fysiske enheter, gir MCP oss én standardisert protokoll for å koble AI-modeller til data og verktøy.

I dag støtter praktisk talt alle seriøse AI-verktøy MCP. På utviklersiden har vi Claude, Cursor, Visual Studio Code - listen fortsetter. Men MCP strekker seg langt utover kodeeditorer: Slack har en offisiell MCP-server for meldinger og kanalsøk, Microsoft Teams AI Library har innebygd MCP-støtte, og det finnes MCP-servere for Notion, HubSpot, Supabase, og community-drevne MCPer for tusenvis av andre tjenester.

Hva betyr dette i praksis? Tenk deg en kollega som jobber i Teams hele dagen. Med MCP-støtte kan AI-assistenten hennes faktisk _gjøre_ ting: finne den ene meldingen fra tre uker siden, oppsummere diskusjonen i en kanal, eller sjekke hvem som er tilgjengelig for et møte, uten at hun trenger å kopiere og lime inn kontekst manuelt. Det er forskjellen på en AI som bare kan svare på generelle spørsmål, og en som kan navigere i din faktiske arbeidshverdag. **MCP gjør AI-assistenter nyttige for alle, ikke bare utviklere**.

Derfor er det spesielt viktig å forstå hvordan protokollen fungerer, ikke fordi den er spesielt ny og spennende, men fordi den er grunnmuren vi bygger på. Når vi i senere innlegg diskuterer mer avanserte mønstre, regner jeg med at du forstår MCP-terminologien og arkitekturen.

I dette innlegget skal vi se på hva MCP faktisk er, hvorfor det er overlegent proprietære verktøykall, og hvordan du kan sette opp din første MCP-server.

## Hva er egentlig MCP?

MCP er en åpen standard som bruker JSON-RPC 2.0 over enten `stdio` (lokalt) eller `HTTP/SSE` (remote) for å fasilitere kommunikasjon mellom en **MCP Client** (f.eks. Claude Desktop, Cursor, eller din egen agent) og en **MCP Server** som holder på dataene eller verktøyene.

Protokollen definerer tre hovedprimitiver som gir modellen tilgang til verden utenfor:

1. **Resources:** Data som modellen kan lese. Dette fungerer som fil-lesing; modellen får innholdet i en fil, en database-rad eller en API-respons. Tenk på dette som "GET"-forespørsler i REST-arkitektur.
2. **Tools:** Funksjoner modellen kan utføre. Dette er handlinger som krever godkjenning, som å opprette en PR, kjøre en SQL-spørring eller sende en melding. Dette tilsvarer tradisjonelle verktøykall.
3. **Prompts:** Forhåndsdefinerte maler som hjelper brukeren å bruke serveren effektivt. Dette kan være en spesialisert prompt for å analysere en database-tabell eller feilsøke en loggfil.

![MCP Arkitektur](https://www.magnusrodseth.com/blog/model-context-protocol/mcp.png)
_MCP-arkitekturen kobler AI-klienter (som Claude eller IDE-er) til datakilder gjennom en standardisert protokoll, uavhengig av hvilken modell som brukes i bunnen. Kilde: Anthropic._

Det viktige her er ikke teknologien i seg selv (JSON-RPC er gammelt nytt), men **standardiseringen**. Fordi protokollen er lik på tvers av alle verktøy, kan en utvikler bygge _én_ MCP-server for sitt interne API, og den vil umiddelbart fungere i Claude Desktop, Cursor, Zed, og alle andre verktøy som støtter standarden, uten noen tilpasning.

## MCP i Praksis: Konfigurasjon

Hvem som helst kan ta i bruk MCP i dag - på veldig kort tid. Verktøy som **Claude Code** (CLI) og **Cursor** (IDE) har førsteklasses støtte for protokollen.

Alt styres vanligvis gjennom en konfigurasjonsfil, `mcp.json`. Her definerer du hvilke servere klienten skal koble seg til. Slik ser en typisk konfigurasjon ut for å gi AI-en tilgang til filsystemet ditt og GitHub:

```json
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/path/to/your/project"
      ]
    },
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    }
  }
}
```

Når denne konfigurasjonen er lastet, vil klienten din (f.eks. Cursor eller Claude) automatisk oppdage verktøyene som serverne tilbyr. Du trenger ikke kopiere og lime inn API-skjemaer. Du ber bare agenten: _"Sjekk siste PR i dette repoet og se om den crasher med endringene i `main.ts`"_, og agenten vil selv finne riktig verktøy (GitHub MCP og Filesystem MCP) for å løse oppgaven.

## Bygg din egen MCP-server

Selv om det finnes hundrevis av ferdige servere, ligger den virkelige kraften i å eksponere dine egne data. Tenk deg en intern bedriftsagent som trenger tilgang til kundedata i en PostgreSQL-database, kan oppdatere et Google Sheet med ukentlige rapporter, og henter sanntidsinformasjon fra et internt API. Med MCP kan du eksponere alle disse datakildene gjennom én standardisert protokoll, og agenten kan resonnere på tvers av dem for å løse komplekse oppgaver.

La oss se på et minimalt eksempel. Takket være gode SDK-er er dette trivielt i både TypeScript og Python. Og selv om du ikke er utvikler, følg med på kommentarene. Du vil forstå hva som skjer.

### Et eksempel i TypeScript

Her bruker vi den offisielle SDK-en for å opprette en server som kjører over `stdio` (standard input/output), som er standarden for lokale integrasjoner. Tenk deg at bedriften din har et internt SharePoint-API som du vil eksponere for AI-assistenten.

```typescript
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
import { sharepointApi } from "./services/sharepoint.js"; // 👈🏽 Ditt eksisterende interne API

const server = new McpServer({  // 👈🏽 Opprett en MCP-server
  name: "sharepoint-server",
  version: "1.0.0",
});

server.tool(  // 👈🏽 Definer et verktøy AI-en kan bruke
  "search_documents",
  { query: z.string().describe("Search query") },  // 👈🏽 Beskriv hva verktøyet trenger
  async ({ query }) => {
    const docs = await sharepointApi.search(query);  // 👈🏽 Kall ditt eksisterende API
    return {
      content: [
        {
          type: "text",
          text: docs.map(d => `${d.title} (${d.url})`).join("\n"),  // 👈🏽 Returner resultatet
        },
      ],
    };
  }
);

const transport = new StdioServerTransport();  // 👈🏽 Sett opp kommunikasjonskanalen
await server.connect(transport);  // 👈🏽 Start serveren, ferdig!
```

### Et eksempel i Python

I Python-verdenen har vi biblioteket `FastMCP` som gjør opplevelsen veldig lik FastAPI.

```python
from mcp.server.fastmcp import FastMCP
from services.sharepoint import sharepoint_api  # 👈🏽 Ditt eksisterende interne API

mcp = FastMCP("sharepoint-server")  # 👈🏽 Opprett en MCP-server

@mcp.tool()  # 👈🏽 Definer et verktøy AI-en kan bruke
async def search_documents(query: str) -> str:
    """Search for documents in SharePoint."""  # 👈🏽 Beskriv hva verktøyet gjør
    docs = await sharepoint_api.search(query)  # 👈🏽 Kall ditt eksisterende API
    return "\n".join(f"{d.title} ({d.url})" for d in docs)  # 👈🏽 Returner resultatet

if __name__ == "__main__":
    mcp.run()  # 👈🏽 Start serveren, ferdig!
```

Det å kunne eksponere komplekse interne systemer (enten det er en legacy database, et internt API, eller loggfiler) gjennom så enkle grensesnitt, endrer spillereglene for hva vi kan bruke AI til i hverdagen.

> **Tips:** Har du allerede et REST API? Da trenger du kanskje ikke å bygge en separat MCP-server fra bunnen av. Mange populære webrammeverk har god støtte for å eksponere MCP-endepunkter direkte. [Spring AI](https://docs.spring.io/spring-ai/reference/api/mcp/mcp-overview.html) har innebygd MCP-støtte for Java/Kotlin, og [@hono/mcp](https://www.npmjs.com/package/@hono/mcp) lar deg enkelt legge til MCP i en Hono-applikasjon. Dette betyr at du kan gjenbruke eksisterende forretningslogikk og autentisering uten duplisering.

## Oppsummering

MCP er fundamentet som resten av den agentiske stacken hviler på. Ved å standardisere hvordan modeller kobler seg til omverdenen, flytter vi fokuset fra _integrasjon_ til _innovasjon_.

Hovedinnsiktene å ta med seg:

1. **Standardisering vinner:** Slutt å bygge proprietære verktøy-definisjoner. Sjekk om det finnes en MCP-server først.
2. **Lokal først:** MCP gjør det trygt og enkelt å koble sky-modeller til lokale data uten at dataene må lastes opp permanent.
3. **Økosystem:** Med tusenvis av servere allerede tilgjengelig, kan du plugge agenten din rett inn i PostgreSQL, Slack, eller GitHub i dag.

Vi har nå to fundamentale brikker på plass: forståelsen av agentiske arbeidsflyter fra forrige innlegg, og MCP som infrastrukturen som kobler agenter til verden. Med dette fundamentet kan vi i fremtidige innlegg utforske mer avanserte mønstre.

## Ressurser

- [Model Context Protocol Offisiell Dokumentasjon](https://modelcontextprotocol.io/)
- [Anthropic: MCP Announcement](https://www.anthropic.com/news/model-context-protocol)
- [GitHub: MCP Servers Repository](https://github.com/modelcontextprotocol/servers) - En samling av community-drevne servere.
- [Cursor Documentation: MCP](https://docs.cursor.com/context/model-context-protocol)


---

# Fra System Prompts til Agentiske Arbeidsflyter

Published: January 2026
Originally published at Capra Consulting: https://capraconsulting.no/vare-historier/fra-system-prompts-til-agentiske-arbeidsflyter

> Det fundamentale paradigmeskiftet fra prompt engineering til context engineering og agentiske arbeidsflyter.

![En AI-agent bryter gjennom muren av statiske chat-bobler og tekst, inn i en verden av kode, filer og verktøy.](https://www.magnusrodseth.com/blog/fra-system-prompts-til-agentiske-arbeidsflyter/banner.jpeg)
_Fra statiske prompts til dynamiske agenter som handler i den virkelige verden. Kilde: Google Nano Banana Pro._

## Innledning

Velkommen til det første innlegget i bloggserien "The Agentic Stack". Hvert innlegg er designet som en 5-minutters lesning, perfekt til morgenkaffen eller pendlertoget. Kort nok til å fordøyes i én økt, dyp nok til å gi deg noe nytt å tenke på.

I denne serien skal vi utforske de dype arkitekturmønstrene som nå endrer hvordan vi bygger programvare med kunstig intelligens. Vi befinner oss i et kritisk skifte: Vi beveger oss bort fra å bare "snakke" med modeller, til å bygge systemer som faktisk utfører arbeid.

For de av dere som har jobbet med LLM-er siden de første dagene av ChatGPT, kan de første konseptene virke kjente, kanskje til og med grunnleggende. Jeg oppfordrer dere likevel til å henge med. Denne serien er designet for å bygge et felles vokabular og et fundament som vi senere skal bruke til å utforske mer avanserte temaer. Vi skal bevege oss fra de enkle interaksjonene til blant annet kompleks multi-agent orchestration, utforske long-running autonomous agents, og se på hvordan vi kan fortsette å lære med agentic AI - og masse mer!

Mange utviklere i dag sitter fast i en arbeidsflyt der AI fungerer som en glorifisert chatbot. Vi skriver en instruks, får et svar, og kopierer det manuelt inn i koden vår. Kanskje du allerede bruker agentisk chat i IDE-en din (Cursor, Copilot eller lignende), og kanskje du til og med har prøvd terminal-baserte agenter. Det er flott! Men potensialet strekker seg mye lenger enn det. Ved å bevege oss fra statiske system prompts til dynamiske agentiske arbeidsflyter, kan vi transformere AI fra en assistent til en kollega (eller flere kollegaer!) som forstår kontekst, tar beslutninger og utfører komplekse oppgaver autonomt. Dette endrer fundamentalt hvordan vi som utviklere opererer, og hva vårt ansvarsområde blir for å sikre høy kvalitet i kode og digitale produkter.

Denne serien handler ikke bare om hvordan du kan bruke AI i din egen utviklingshverdag. Vi skal også dekke produktutviklingsperspektivet: Hvordan bygger du produksjonsklare agentiske applikasjoner for kunder og sluttbrukere? Hvordan setter du dem trygt i produksjon? Og ikke minst: hvordan tester og evaluerer du systemer der oppførselen ikke lenger er deterministisk? Vi skal utforske verktøyvalg, arkitekturstrategier og de praktiske mønstrene som faktisk fungerer i virkeligheten.

## System Prompts: Den første muren

Vi lærte oss raskt verdien av en god system prompt. Dette er den permanente instruksen som setter rammer for modellens oppførsel, definerer dens personlighet og gir den retningslinjer for hvordan den skal svare. En typisk system prompt kan fortelle modellen at den er en "dyktig seniorutvikler som prioriterer sikkerhet og lesbar kode".

Etter hvert som vi prøver å bygge mer komplekse applikasjoner, støter vi på en mur. En system prompt er i bunn og grunn statisk. Den er en del av den initiale konfigurasjonen, og selv om den kan være lang og detaljert, har den klare begrensninger. For det første er vi begrenset av modellens kontekstvindu. Jo mer vi pakker inn i en system prompt, jo færre tokens har vi til rådighet for faktisk problemløsning.

I tillegg mangler en tradisjonell prompt-basert tilnærming både tilstand (state) og kontrollflyt. Modellen har ingen innebygd evne til å huske hva den gjorde for tre steg siden uten at vi sender hele historikken tilbake, noe som fører til det vi kaller context rot, der viktig informasjon drukner i irrelevant støy. Uten tilgang til verktøykall forblir modellen innelåst i sitt eget tekstunivers. Den kan foreslå hvordan du refaktorerer en funksjon, men den kan ikke selvstendig lese de relevante filene, gjøre endringene og verifisere at koden fortsatt fungerer. For å komme dit trenger vi noe mer enn bare bedre setningsoppbygging; vi trenger systemdesign.

![Kalibrering av system prompts](https://www.magnusrodseth.com/blog/fra-system-prompts-til-agentiske-arbeidsflyter/system-prompt.webp)
_En god system prompt finner balansen mellom for spesifikk (rigid if-else logikk) og for vag (abstrakte prinsipper). Kilde: Anthropic._

## Context Engineering: Det nye paradigmet

Det er her vi møter begrepet context engineering. Mens prompt engineering handler om hvordan vi skriver instruksjoner, handler context engineering om hvordan vi kuraterer og forvalter den totale informasjonsmengden som sendes til modellen ved hver inference. Dette er det naturlige neste steget i utviklingen.

Kjerneprinsippet i context engineering er å finne det minst mulige settet med high-signal tokens som maksimerer sannsynligheten for at modellen tar riktig beslutning. Det handler ikke om å dytte så mye informasjon som mulig inn i modellen, men om å være en nådeløs redaktør av agentens virkelighet.

![Prompt engineering vs context engineering](https://www.magnusrodseth.com/blog/fra-system-prompts-til-agentiske-arbeidsflyter/prompt-engineering-vs-context-engineering.webp)
_Prompt engineering er en diskret oppgave: du skriver én prompt. Context engineering er en kontinuerlig prosess der du kuraterer kontekst ved hver inference. Kilde: Anthropic._

Når vi bygger agenter som skal operere over lengre tidshorisonter (såkalt long-horizon tasks) må vi ta i bruk mer avanserte strategier. Dette inkluderer teknikker som compaction, der vi kontinuerlig oppsummerer samtalen og reinitierer agenten med et destillert sammendrag når vi nærmer oss kontekstgrensen. Vi ser også fremveksten av sub-agent architectures, der en overordnet agent delegerer spesialiserte oppgaver til mindre agenter med rene, fokuserte kontekstvinduer. Dette forhindrer at modellen blir overveldet og sikrer at den alltid har den mest relevante informasjonen tilgjengelig for den spesifikke oppgaven den løser akkurat nå.

![Sub-agent arkitektur](https://www.magnusrodseth.com/blog/fra-system-prompts-til-agentiske-arbeidsflyter/subagents.png)
_En hovedagent koordinerer arbeidet ved å delegere spesialiserte oppgaver til sub-agenter, som hver opererer med fokusert kontekst. Kilde: Anthropic._

## OODA-loopen: Agentens hjerne

For å forstå hvordan en agent faktisk fungerer, trenger vi en mental modell som går utover lineær programmering. En av de mest effektive modellene er OODA loop, opprinnelig utviklet av militærstrategen John Boyd. OODA står for Observe, Orient, Decide, og Act.

For en AI-agent oversettes disse fasene direkte til tekniske operasjoner:

1. **Observe:** Agenten samler informasjon fra miljøet. Dette kan være å lese en fil, hente data fra et API eller motta input fra en bruker.
2. **Orient:** Dette er den viktigste fasen i context engineering. Agenten prosesserer den innsamlede informasjonen og plasserer den i riktig kontekst. Her bruker vi teknikker som embedding-søk eller filtrering for å forstå hva informasjonen faktisk betyr.
3. **Decide:** Basert på sin orientering, legger agenten en plan. Skal den utføre et verktøykall? Trenger den mer informasjon? Er oppgaven fullført?
4. **Act:** Agenten utfører handlingen, for eksempel ved å skrive til en database eller generere en respons til brukeren.

Denne syklusen gjentas helt til målet er nådd. Det som skiller en agent fra en enkel chatbot, er evnen til å navigere i denne sløyfen autonomt. Vi snakker ofte om fire pilarer som definerer en ekte agent:

- **Autonomi:** evnen til å ta beslutninger uten konstant input
- **Reaktivitet:** respons på endringer i miljøet
- **Proaktivitet:** initiativ for å nå sine mål
- **Sosialitet:** evnen til å samhandle med brukere eller andre agenter

Når hvert steg i "Act"-fasen gir ny informasjon som observeres i neste runde, ser vi disse pilarene i praksis.

![Agent-løkken](https://www.magnusrodseth.com/blog/fra-system-prompts-til-agentiske-arbeidsflyter/agents.webp)
_En agent opererer i en kontinuerlig løkke: den utfører handlinger mot miljøet, mottar feedback, og bestemmer neste steg, helt til oppgaven er fullført. Kilde: Anthropic._

## Produksjonsvirkeligheten: Enkle mønstre vinner

Når vi ser på hvordan agenter faktisk implementeres i produksjon i dag, ser vi noen tydelige trender. En fersk studie viser at hele 70% bruker off-the-shelf modeller uten fine-tuning, og 79% fokuserer på manuell prompt-konstruksjon og context engineering. Dette understreker at måten vi rigger systemet rundt modellen på, ofte er viktigere enn selve modellen.

Et annet interessant funn er at de mest pålitelige systemene opererer med det vi kaller bounded autonomy, altså autonomi innenfor klare grenser. Rundt 68% av suksessrike agent-systemer utfører ti eller færre steg før de krever menneskelig intervensjon, såkalt human-in-the-loop (HITL). Dette er et viktig designprinsipp: Vi bygger ikke agenter for å erstatte oss fullstendig, men for å utføre fokuserte oppgaver der vi beholder kontrollen gjennom transparens og kontrollpunkter.

Arkitekturelt ser vi også at 85% av teamene velger å bygge sine egne rammeverk eller bruke lette biblioteker fremfor store, tunge abstraksjoner. Dette er fordi kontroll over kontrollflyten og tilstandshåndteringen er helt avgjørende for stabilitet. Det er også viktig å skille mellom agentiske arbeidsflyter og sanne agenter, en distinksjon Anthropic ofte trekker frem. Arbeidsflyter ("workflows") er systemer der LLM-er og verktøy orkestreres gjennom forhåndsdefinerte kodestier, ofte strukturert opp som en graf bestående av noder og kanter, noe som gir høy forutsigbarhet for veldefinerte oppgaver. Agenter, derimot, er bedre når fleksibilitet og modell-drevet beslutningstaking er nødvendig i stor skala. Valget mellom disse avhenger av balansen mellom behovet for kontroll og behovet for autonomi.

## Oppsummering

Vi har bare så vidt skrapt i overflaten av hva som er mulig når vi beveger oss fra statiske system prompts til dynamiske agentiske arbeidsflyter. Ved å forstå forskjellen på prompt engineering og context engineering, og ved å bruke modeller som OODA-loopen, kan vi begynne å designe systemer som er mer robuste, mer autonome og langt mer kapable.

Den viktigste lærdommen er kanskje denne: Fremtidens utvikling handler mindre om å skrive den perfekte instruksen, og mer om å designe det perfekte økosystemet for agenten å operere i - selvfølgelig innenfor trygge rammer.

I neste innlegg skal vi se nærmere på MCP (Model Context Protocol). Dette er den nye standarden som kobler våre agenter til lokale data og verktøy, og det er en essensiell brikke i den moderne agentiske teknologistakken.

## Ressurser

- [Anthropic: Building Effective Agents](https://www.anthropic.com/research/building-effective-agents)
- [Anthropic: Effective Context Engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [arXiv: Measuring Agents in Production (2512.04123)](https://arxiv.org/abs/2512.04123)
- [LangChain: State of Agent Engineering 2025](https://www.langchain.com/state-of-agent-engineering)


---

# Glem benchmarkene: Derfor bør du bry deg om Claude Opus 4.5

Published: November 2025
Originally published at Kode24: https://www.kode24.no/artikkel/glem-benchmarkene-derfor-bor-du-bry-deg-om-claude-opus-45/250271

> Det Anthropic har gjort her, handler mindre om at modellen har lest flere bøker, og mer om at de har endret måten modellen jobber på.

Det er lett å bli nummen av den konstante strømmen med nye AI-modeller. Enda en uke, enda en benchmark som flytter seg noen prosentpoeng.

Men lanseringen av Claude Opus 4.5 og de nye funksjonene for Advanced Tool Use fanget oppmerksomheten min av helt andre grunner enn kun marginale hopp på et søylediagram.

Det Anthropic har gjort her, handler mindre om at modellen har lest flere bøker, og mer om at de har endret måten modellen jobber på. De har tatt tak i de kjedelige, men kritiske flaskehalsene vi utviklere møter: begrensninger i kontekst, latency i API-kall og kostnaden av komplekse oppgaver.

Her er en gjennomgang av hva som er nytt, og hvorfor dette er interessant for deg - enten du bygger avanserte agenter eller bare bruker verktøy som Claude Code i hverdagen.

## Tool Search Tool: "Lazy loading" for kontekst

Hvis du har forsøkt å gi en LLM tilgang til mange verktøy samtidig - enten det er i en agent du bygger, eller i et CLI-miljø som Claude Code - kjenner du problemet: "Context Bloat".

Å legge inn definisjoner for 50+ verktøy spiser opp tusenvis av tokens før du i det hele tatt har stilt det første spørsmålet. Det gjør prosesseringen tregere, dyrere, og øker sjansen for at modellen blir forvirret.

Løsningen Anthropic nå ruller ut minner mye om lazy loading: I stedet for å laste alle verktøyene inn i konteksten ved oppstart, gir du modellen et "søke-verktøy". Når Claude innser at den trenger å gjøre noe den ikke har verktøy for i minnet (f.eks. "sjekk deployment-status" eller "sjekk været"), søker den i katalogen, og laster kun inn definisjonen for det relevante verktøyet der og da.

![Forskjellen mellom tradisjonell approach og Tool Search - ubrukte verktøysdefinisjoner spiser opp store deler av kontekstvinduet. Med Tool Search lastes kun det nødvendige.](https://www.magnusrodseth.com/blog/context-usage.png)

Dette betyr at du i teorien kan ha tusenvis av tilgjengelige verktøy i systemet ditt, uten at det påvirker ytelsen eller prisen på hver enkelt request på en drastisk måte.

## Programmatic Tool Calling

Tradisjonell "Function Calling" føles ofte som en ping-pong-match:

1. Modellen ber om å kjøre verktøy A.
2. Verktøy A kjøres og sender svaret tilbake til modellen.
3. Modellen leser svaret og ber om verktøy B.
4. Verktøy B kjøres og sender svaret tilbake til modellen.

Dette skaper mye latency. Med Programmatic Tool Calling kan Claude i stedet skrive og kjøre et Python-script i en sandbox (hos Anthropic). Dette scriptet kan kalle flere verktøy, prosessere dataene, kjøre løkker og logikk, og kun returnere det endelige svaret.

**Hvorfor er dette viktig?**

- **Færre hallusinasjoner:** LLM-er sliter ofte med presis matte og logikk. Python er perfekt til det. Ved å la modellen skrive koden for å løse problemet, i stedet for å "tenke" seg frem til svaret, øker presisjonen.
- **Effektivitet:** Du bytter ut ti frem-og-tilbake kall med 1 eksekvering.

![Flytdiagrammet viser forskjellen: I stedet for å gå frem og tilbake til brukeren, kjører Claude en indre loop med Python-kode i en sikker container før det endelige svaret leveres.](https://www.magnusrodseth.com/blog/programmatic-tool-calling.png)

## Beviset: "The Puzzle Room Challenge"

Teori er vel og bra, men Anthropic kjørte et interessant eksperiment for å vise forskjellen i praksis. De satte opp to modeller til å løse en serie med 7 matematiske låser for å åpne en digital safe:

- Sonnet 4.5 med tradisjonell tool calling.
- Opus 4.5 med programmatic tool calling.

![Til venstre ser vi Sonnet 4.5 som sliter med høy token-bruk ved bruk av tradisjonelle verktøy. Til høyre har Opus 4.5 løst problemet programmatisk med en brøkdel av ressursene.](https://www.magnusrodseth.com/blog/sonnet-vs-opus.png)

Resultatet var en tankevekker:

- **Sonnet (Tradisjonell):** Prøvde å gjette koder, feilet, fikk hint, og prøvde igjen. Den brukte over 7.6 millioner tokens på å løse oppgavene, fordi den måtte "prate" seg gjennom logikken.
- **Opus (Programmatic):** Skrev Python-script for å knekke kodene (f.eks. kalkulere Fibonacci-rekker eller modulo-aritmetikk). Den løste alt med under 670 000 tokens.

Opus brukte altså under 10% av token-mengden til Sonnet. Selv om prisen per token er høyere for Opus, ble totalkostnaden for oppgaven drastisk lavere, og oppgaven ble løst raskere og mer presist. Dette viser at "dyrere" modeller nå kan være billigere i drift hvis de løser oppgaven på første forsøk ved hjelp av bedre verktøy.

Se hele eksperimentet her: [Claude Opus 4.5 solves a puzzle game (YouTube)](https://www.youtube.com/watch?v=2MJDdzSXL74)

## Hvorfor jeg har sluttet å bry meg om tallene

Det er i møte med slike resultater at jeg kjenner jeg bryr meg fint lite om benchmarks. Om en modell scorer 70, 100 eller 80.9% (som Opus 4.5 faktisk scorer på SWE-bench Verified), blir bare abstrakte tall på et søylediagram for meg.

I min hverdag handler det kun om effekt: Hastighet, kostnad og pålitelighet. Det Anthropic viser her, er et faktisk konkurransefortrinn som betyr noe. Konkurrentene kan gjerne være marginalt "smartere" på papiret, men hvis de må brenne av ti ganger så mange tokens og bruke ti ganger så lang tid på å komme frem til samme svar, har de tapt i mine øyne.

## Det store bildet: Hvorfor dette er viktig nå

Det er verdt å løfte blikket litt fra koden for å se hva som skjer i bakgrunnen her. Det er noen strukturelle endringer som gjør at Anthropic posisjonerer seg annerledes enn konkurrentene akkurat nå:

### 1. "Cost of Intelligence" går ned

Selv om vi ser modeller med høyere "sticker price" (som Opus 4.5), faller den faktiske kostnaden for å få utført komplekst arbeid. Som vi så i eksempelet over: En smart modell som bruker effektive verktøy er billigere enn en billig modell som roter seg bort i lange samtaler.

### 2. Infrastruktur og partnerskap

Anthropic opererer ikke i et vakuum. Deres tette samarbeid med Google gir dem tilgang til enorm regnekraft - rapportene sier de har sikret tilgang til over 1 million TPUs (Tensor Processing Units) i 2026. Dette er viktig fordi det garanterer at de har infrastrukturen til å skalere disse "tunge" agent-modellene i produksjon.

### 3. Fra Chatbot til "Compute Engine"

Vi ser en dreining hvor modellene går fra å være noe vi chatter med, til å bli en motor som utfører arbeid i bakgrunnen.

- **Tool Search** løser problemet med "hva kan jeg gjøre?".
- **Programmatic Calling** løser problemet med "hvordan gjør jeg det effektivt?".

Dette er teknologien som ligger til grunn for verktøy som Claude Code. Når du sitter i terminalen din og ber Claude fikse en bug, er det nettopp denne evnen til å søke opp filer, forstå kontekst, og kjøre tester selvstendig som gjør at det tidvis oppleves helt magisk.

## Oppsummert

Claude Opus 4.5 er en imponerende modell, men det er verktøyene rundt modellen som gjør dette til en viktig utgivelse. For oss utviklere betyr dette at vi kan begynne å bygge systemer som er mer autonome, mer presise og - kanskje overraskende nok - billigere i drift på komplekse oppgaver.

Spørsmålet er ikke lenger hvilken modell som er smartest på papiret, men hvilken modell som faktisk får jobben gjort. Med Opus 4.5 har Anthropic lagt listen for hva vi kan forvente av autonome agenter. Nå blir det spennende å se hvordan konkurrentene svarer.

---

## Kilder

- Anthropic. (2025, 24. november). [Introducing advanced tool use on the Claude Developer Platform](https://www.anthropic.com/engineering/advanced-tool-use).
- Anthropic. (2025, 24. november). [Introducing Claude Opus 4.5](https://www.anthropic.com/news/claude-opus-4-5).
- Anthropic. (2025, 23. oktober). [Expanding our use of Google Cloud TPUs and Services](https://www.anthropic.com/news/expanding-our-use-of-google-cloud-tpus-and-services).
- Anthropic. (u.d.). [Tool search tool - Claude Docs](https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool).
- Anthropic [YouTube]. (2025). [Claude Opus 4.5 solves a puzzle game](https://www.youtube.com/watch?v=2MJDdzSXL74).
- Google Cloud Press Corner. (2025, 23. oktober). [Anthropic to Expand Use of Google Cloud TPUs and Services](https://www.googlecloudpresscorner.com/2025-10-23-Anthropic-to-Expand-Use-of-Google-Cloud-TPUs-and-Services).


---

# Slik maksimerer du agentiske arbeidsflyter

Published: November 2025
Originally published at Capra Consulting: https://capraconsulting.no/vare-historier/slik-maksimerer-du-agentiske-arbeidsflyter

> Hvordan systematisk optimalisere arbeidsflyten for å maksimere kvaliteten på AI-generert kode og minimere tiden du bruker på manuell tasting.

Se for deg dette scenariet: Du lener deg tilbake med kaffekoppen, mens en ivrig, digital assistent tar seg av grovarbeidet i koden din. Dette er ikke lenger en fjern fremtidsdrøm, men en høyst reell mulighet hvis du skrur sammen verktøykassen din riktig.

I dette innlegget skal vi se på konseptet jeg har valgt å kalle "Vibe-Maxxing" i utviklersammenheng. Kort forklart handler det om å systematisk optimalisere arbeidsflyten for å oppnå ett hovedmål: **Maksimere kvaliteten på AI-generert kode og minimere tiden du bruker på manuell tasting.**

![Vibe-Maxxing](https://www.magnusrodseth.com/blog/vibe-maxxing/cover_image.png)

> NB: Erfaringene her er basert på arbeid i Greenfield-prosjekter med små team og moderne kodebaser (hovedsakelig TypeScript/Next.js). Din situasjon kan variere, men prinsippene er forhåpentligvis nokså generelle.

## Hva er egentlig "Vibe-Maxxing"?

Begrepet "Maxxing" er internettslang for å ta en hvilken som helst aktivitet og optimalisere den til det ekstreme. For oss utviklere betyr "Vibe-Maxxing" å flytte fokuset fra å bare bruke AI-verktøy, til å orkestrere dem strategisk.

**Målet er tredelt:**

1. **Øke leveransetempoet:** Flytte fokus fra syntaks til problemløsning for å shippe funksjonalitet raskere.
2. **Skalere egen kapasitet:** La én utvikler gjøre jobben til flere ved å maksimere autonomi i trygge omgivelser.
3. **Heve kvaliteten:** Bruke den innsparte tiden på bedre arkitektur, testing og robusthet, heller enn å taste boilerplate.

Hensikten er altså ikke bare å jobbe annerledes, men å drastisk øke output per time. Ved å la AI ta seg av implementasjonsdetaljene, frigjør du kognitiv kapasitet til de vanskelige problemene – de som faktisk skaper verdi for brukerne. Det handler om overgangen fra å være en håndverker som legger murstein, til å bli arkitekten som sørger for at hele bygget reiser seg.

La meg likevel være krystallklar: Dette er ikke en magisk pille som fjerner behovet for teknisk kompetanse. Tvert imot. Som vi skal se nærmere på mot slutten, introduserer denne arbeidsflyten nye risikoer vi ikke har hatt før. Men gevinsten ved å navigere dem riktig, er enorm.

Så, før vi slipper AI-en løs, må vi sette opp noen sikkerhetsnett.

## Mentale modeller og sikkerhetsnett

Det viktigste prinsippet for agentisk koding er enkelt: **Kontekst er konge.**

AI-kvalitet er direkte proporsjonalt med kvaliteten på konteksten du gir. Eller som jeg liker å si til meg selv:

> "Shit in, shit out. Good shit in, good shit out."

Hvis du fôrer modellen med dårlige beskrivelser eller utdatert dokumentasjon, får du ubrukelig kode tilbake. Det samme gjelder hvis du ikke gir modellen tilstrekkelig kontekst rundt problemet som skal løses.

Den mest nyttige mentale modellen er å behandle AI-agenten som en **svært kapabel juniorutvikler**. Hva ligger egentlig i begrepet "kapabel" her? Spør du meg handler det om at:

- Den kan lese dokumentasjon lynraskt...
- ...men den trenger tilstrekkelig kontekst for å ta gode beslutninger.
- Uten veiledning vil den høyst sannsynlig velge feil retning for implementasjon.
- Din rolle endres derfor fra å være "bare en utvikler" til å bli en teknisk leder som orkestrerer prosessen og kvalitetssikrer arbeidet.

## Velg din verktøykasse

Du trenger ikke det dyreste bedriftsabonnementet for å få dette til å flyte. Her er oppsettet som gir meg mest verdi for pengene:

| Verktøy | Beskrivelse |
|---------|-------------|
| **Claude Code** ($100/mnd) | Dette er motoren i oppsettet. Claude Code håndterer komplekse prosjekter, arkitekturforståelse og konsistens på tvers av store kodebaser bedre enn det meste annet akkurat nå. |
| **Windsurf** (Gratisversjon) | IDE med AI-integrasjon. |
| **SuperWhisper** (Gratis/Lokalt) | Dette er den hemmelige ingrediensen. SuperWhisper lar deg snakke direkte til AI-en med lokal transkribering på Mac-en din. Mer om dette senere. |

![Claude Code, Windsurf og SuperWhisper](https://www.magnusrodseth.com/blog/vibe-maxxing/claude-windsurf-superwhisper.png)

## Arbeidsflyten: Planlegging vs. Gjennomføring

For å lykkes må du vite når du skal bremse og når du kan gi gass.

Vi skiller mellom to moduser:

### 1) Plan Mode (Tenkeboksen)

Når du skal bygge en større feature, start her. Skru på "Extended Thinking" og lag en detaljert implementasjonsplan.

- Jeg pleier å be om et "research doc" som lagres som en markdown-fil i roten av prosjektet. Dette kan jeg sjekke inn i versjonskontroll eller slette når jeg er ferdig med å implementere den nye funksjonaliteten.
- Dette løser problemet med at AI-modellen "glemmer" kontekst i lange chatter.
- Du kan enkelt starte en ny sesjon, dra inn plan-filen, og fortsette der dere slapp.

Nøkkelen til suksess her er struktur: Be eksplisitt om at planen deles inn i **faser og sub-faser**. Dette tvinger modellen til å tenke sekvensielt og logisk på avhengigheter. Ved å låse rekkefølgen på hva som må gjøres, unngår du at agenten prøver å "male veggene før grunnmuren er støpt", og du beholder full kontroll over progresjonen.

### 2) Auto-Edit Mode (Gjennomføring)

Når planen er lagt og dere er enige om retningen, skrur du på "auto-edit". Her får agenten lov til å skrive og endre filer selv. Din jobb er å overvåke og ta stikkprøver av kritisk forretningslogikk.

![Plan, Edit, Review](https://www.magnusrodseth.com/blog/vibe-maxxing/plan-edit-review.jpeg)

> Fra håndverker til arkitekt: I denne loopen er jobben din å definere "hva" (Plan Mode) og verifisere "hvordan" (Review), mens AI-en tar seg av gjennomføringen.

## Stemmestyrt utvikling

Det høres kanskje rart ut å snakke til datamaskinen din, men her ligger det en enorm produktivitetsgevinst. Å beskrive kompleks forretningslogikk muntlig er ofte langt mer presist og raskere enn å skrive det ned. Mitt råd er å finne et stille rom, lukk øynene, og forklar problemet som om du snakket til en kollega.

SuperWhisper transkriberer tankene dine lokalt, og du kan lime en perfekt formulert, detaljert instruks rett inn i terminalen. Det gir AI-en en dybde i konteksten som er vanskelig å oppnå via tastaturet.

![SuperWhisper](https://www.magnusrodseth.com/blog/vibe-maxxing/superwhisper.png)

## Trygge omgivelser gir maksimal autonomi

Mange er skeptiske til å gi AI for mye autonomi. Løsningen er å skape en sandkasse hvor det er trygt å feile.

**Lokal utvikling er perfekt for dette.**

- **Ingen risiko for produksjonsdata:** La AI-en herje med din lokale database.
- **Rask gjenoppretting:** Hvis agenten roter det til, kan du resette databasen og seede den på nytt på sekunder.

Gi agenten tilgang til databaseverktøyene dine. La den generere migrasjoner, kjøre dem, oppdatere typesystemet og verifisere at alt henger sammen. Når AI-en forstår hele dataflyten – fra databaseskjema til frontend-typer – får du en selvforsterkende effekt hvor typesikkerheten fungerer som en veileder for AI-en.

## Fra System Prompts til Claude Skills

Tidligere brukte vi gjerne en `CLAUDE.md` i roten av prosjektet for å styre AI-ens oppførsel. Nå har vi noe enda bedre: **Claude Skills**.

La oss ta den tekniske forklaringen først: Skills er rett og slett mapper som inneholder instruksjoner, skript og ressurser som Claude kan laste inn ved behov. I stedet for å mate AI-en med en enorm "wall of text" hver gang, skanner Claude nå tilgjengelige skills og laster kun inn den informasjonen som er relevant for oppgaven den skal løse akkurat nå. Tenk på det som skreddersydd opplæringsmateriell som gjør agenten til en spesialist på akkurat din kodebase. Det er modulært, effektivt og kan til og med inkludere kjørbar kode.

For å bruke en litt mer visuell analogi: Tenk på filmen "The Matrix", der Neo lærer Kung Fu ved å laste det rett inn i hjernen sin. Claude Skills fungerer på samme måte. Ved å definere ferdigheter i `.claude/skills/`-mappen, institusjonaliserer du prosjektets konvensjoner.

<video src="/blog/vibe-maxxing/kung-fu.mp4" autoPlay loop muted playsInline className="rounded-lg my-4" />

Nå tenker du kanskje: "Hvis jeg har en stor og lang skill, vil ikke det sprenge kontekstvinduet?" Svaret er nei. I utgangspunktet er det kun metadataen på toppen av filen som lastes inn i kontekst:

```yaml
---
name: ui-patterns
description: Apply consistent UI component patterns for the Next.js project. Use when building forms, dialogs, notifications, loading states, or any UI components. Ensures proper dark mode support, responsive behavior, animations, and adherence to the project's component library hierarchy.
---
```

Claude leser denne metadataen når du starter en ny chat. Hvis – og bare hvis – den avgjør at denne ferdigheten er relevant for oppgaven du ber om, lastes resten av dokumentet inn. Dette holder agenten rask og kontekst-effektiv. Hver gang du starter en ny sesjon, "husker" agenten disse ferdighetene. Dette sikrer at koden som produseres følger teamets standarder.

En viktig fotnote: Dette er ikke bare for oss utviklere. Anthropic har laget skills for å generere Word-dokumenter, Excel-ark og PowerPoint-presentasjoner. Disse er tilgjengelige for å brukes direkte i Claude Desktop. Det betyr at kollegaer innen ledelse, salg eller administrasjon kan dra nytte av nøyaktig samme teknologi for sine arbeidsflyter, helt uten å måtte forholde seg til markdown eller kode.

## AI-assistert debugging: `console.log` er din venn

Da jeg startet som utvikler, fikk jeg alltid den samme strenge beskjeden i Pull Request-reviews: "Fjern alle console.logs før du merger!" Det var nesten som en dødssynd å la en logg bli igjen. Jeg forstår jo hvorfor – vi vil ha ren og ryddig kode i produksjon – men jeg tror det ga meg et slags underbevisst traume. En liten stemme i bakhodet som hvisket at det å strø om seg med logger var uprofesjonelt.

Vel, i en agentisk arbeidsflyt er det på tide å ignorere den stemmen. Ikke skam deg over å bruke `console.log` overalt når du utvikler. Det viser seg faktisk å være skikkelig nyttig noen ganger.

Her er en situasjon vi alle kjenner: En "stille feil". Alt ser riktig ut når du sender inn det skjemaet i frontenden, ingen feilmeldinger kastes, men dataene havner ikke i databasen. I stedet for å stirre blindt på koden eller steppe manuelt gjennom linje for linje, gjør jeg følgende:

1. **Be om instrumentering:** Jeg ber AI-agenten om å legge til omfattende logging gjennom hele dataflyten – fra frontend til backend.
2. **Manuell testing:** Jeg tester for å gjenskape feilen i applikasjonen og kopierer hele logg-suppa fra terminalen. Husk å fjerne sensitiv informasjon før du gir det til AI-modellen din.
3. **Kollaborativ analyse:** Jeg limer loggene tilbake til AI-en og ber den analysere dataflyten.

Mønstergjenkjenning er en av AI-ens største styrker. Den vil ofte se nøyaktig hvor dataene endrer form eller forsvinner mye raskere enn du klarer selv. Når feilen er funnet og fikset, kan du be agenten om å rydde opp og fjerne loggene igjen. Alternativt kan du bare kjøre `git reset --hard`, men husk å være flittig til å sjekke inn endringene dine i versjonskontroll. Enkelt, smertefritt, og veldig effektivt.

## Trade-offs: Baksiden av medaljen

Er det bare fordeler? Absolutt ikke. Som med all teknologi som lover ti-dobling av effektivitet, finnes det ingen gratis lunsj. Når vi overlater skrivingen til AI, introduserer vi nye risikoer som vi må være smertelig klar over for å lykkes.

Her er noen av de største fellene å være bevisst på:

### Illusjonen av kompetanse ("The Illusion of Competence")

Det er farlig lett å bli blendet av hvor raskt koden genereres. Koden ser ren ut, den kjører, og testene passerer kanskje til og med. Men når du ikke har skrevet linjene selv, mister du den dype, intuitive forståelsen av hvordan ting henger sammen under panseret.

**Motgift:** Du må være enda nøyere i code reviews enn før. Ikke bare se etter om koden virker, men om den følger arkitekturen og kloke valg en dyktig utvikler ville tatt. Behandle AI-ens genererte kode som om den kom fra en nyansatt som ikke kjenner domenet ennå.

### Spagetti i lysets hastighet

AI er ekstremt dyktig til å skrive dårlig kode veldig raskt hvis du (uvitende) ber den om det. Hvis du blir slapp med kontekststyringen (Plan Mode) og bare kaster tilfeldige kommandoer på agenten, vil du produsere teknisk gjeld raskere enn noe menneske klarer.

**Motgift:** Vær nådeløs på struktur. Hvis "Research Doc"-et ditt er dårlig, blir koden dårlig. Aldri hopp over planleggingsfasen på komplekse oppgaver.

### Avhengighet og "Muscle Memory"

Når du slutter å skrive boilerplate-kode, begynner syntax-hukommelsen å bli rusten. Er det et problem? Kanskje. Hvis du plutselig må debugge en kritisk feil uten AI-verktøyene dine, kan du føle deg handikappet.

**Motgift:** Vibe-Maxxing handler ikke om å skru av hjernen, men om å skru den *på* et høyere abstraksjonsnivå. Du bytter ut tasting med systemtenkning, men du må fortsatt forstå fundamentet for å kunne styre skuta.

### Hallusinerte pakker og sikkerhetshull

En av de skumleste feilene AI-modeller gjør, er såkalt **Package Hallucination**. AI-en kan finne på å foreslå et bibliotek som høres logisk ut (f.eks. `npm install react-fast-crypto-hook`), men som faktisk ikke eksisterer.

Dette har gitt opphav til fenomenet **Slopsquatting**. Ondsinnede aktører overvåker hvilke pakkenavn AI-ene ofte hallusinerer om, og kommer dem i forkjøpet ved å registrere disse navnene på pakkeregistre som NPM eller PyPI – fylt med skadelig kode. Hvis du har en arbeidsflyt der du blindt aksepterer terminalkommandoer fra verktøy som Claude (slik man fort gjør i "Auto-Edit Mode"), kan du intetanende installere malware rett inn i prosjektet ditt. I tillegg kan AI-en fint foreslå kode som er sårbar for injections, rett og slett fordi den mangler den fulle sikkerhetskonteksten.

**Motgift:** Aldri kjør `npm install` (eller tilsvarende) blindt på en pakke du ikke kjenner. Sjekk alltid at pakken er legitim, vedlikeholdt og har en historikk. Behandle all AI-generert kode som "untrusted input" frem til du har verifisert den.

![Package Hallucination](https://www.magnusrodseth.com/blog/vibe-maxxing/package-malicious.jpeg)

Den ivrige assistenten vi møtte innledningsvis vil deg bare vel, men den vet ikke bedre. Uten dine kritiske øyne leverer den gjerne ondsinnede pakker og sikkerhetshull med et stort smil – rett og slett fordi den ikke forstår konsekvensene.

## Meta-lærdommer: Hvorfor gjøre dette?

La oss zoome ut litt. I grunn handler dette om mye mer enn bare å spare noen tastetrykk eller kodingseffektivitet. Etter min mening handler dette om skalering av kompetanse og hvordan vi tenker rundt kunnskap i en organisasjon.

### Institusjonell hukommelse og onboarding

Når du dokumenterer arbeidsflyter slik vi har gått gjennom i denne posten, bygger du en robust institusjonell hukommelse. Hva skjer når en nøkkelperson slutter? I tradisjonelle team forsvinner ofte masse "taus kunnskap" ut døra. Med denne tilnærmingen er kunnskapen kodifisert i verktøyene, ikke bare i hodene til folk.

Dette gir en ekstrem gevinst ved onboarding. En nyutdannet utvikler (eller en ny senior for den saks skyld) kan komme inn i prosjektet og være produktiv i løpet av dager, ikke uker eller måneder. Hvorfor? Fordi "hvordan vi gjør ting her" – arkitekturvalg, UI-mønstre, databasekonvensjoner – allerede ligger klart som ferdigheter i AI-agenten de skal samarbeide med. Det gir dem et stillas å bygge på fra første time.

### Konkurransefortrinn

Dette er kanskje litt "høytflyvende", men jeg mener oppriktig at det ligger et betydelig konkurransefortrinn her. Et konsulenthus eller en produktavdeling som har institusjonalisert disse ferdighetene, starter ikke fra null hver gang.

Hvis du systematisk gjenbruker og forbedrer dine Claude Skills på tvers av prosjekter, gjerne tilpasset samme tech stack, leverer du raskere og med høyere kvalitet enn konkurrenten som fortsatt sitter og skriver boilerplate-kode manuelt. I det lange løp betyr det evnen til å ta på seg flere eller større prosjekter, som igjen betyr høyere inntekt for organisasjonen.

### Den dypeste innsikten

Agentisk utvikling handler dypest sett ikke om kode. Det handler om å hente ut, strukturere og skalere menneskelig ekspertise til et nivå som tidligere var utilgjengelig for oss.

## Hvordan dette innlegget (egentlig) ble til

Til slutt, her kommer "the kicker" – demonstrasjonen av alt jeg nettopp har snakket om.

Du lurer kanskje på hvor lang tid det tok å skrive dette innlegget? Svaret er at jeg nesten ikke har skrevet det. Hele teksten du nå har lest, er basert på en presentasjon jeg genererte for et foredrag – og prosessen beviser nøyaktig det jeg har fortalt om.

**Slik var arbeidsflyten fra idé til ferdig bloggpost, gjennomført på drøye timen:**

1. **Fase 1:** Stemmestyrt "Brain Dump"
2. **Fase 2:** Fra tale til presentasjon
3. **Fase 3:** Fra presentasjon til bloggpost

Det du leser nå, er altså bare et nytt "format" av den samme konteksten. Jeg har ikke tastet selve teksten; jeg har orkestrert innholdet.

Ved å kombinere riktig kontekst, stemmestyring og agentiske verktøy, flytter vi oss fra å være de som taster ordene (eller koden), til å være arkitektene som former budskapet.