Slik bygger du ditt eget PPC OS: et AI-operativsystem for Google Ads

Alle som driver med betalt søk har nå tilgang til den samme AI-en. Du kan installere en kodeagent i ettermiddag, koble den til Google Ads-kontoen din og ha den i gang med å hente ut rapporter innen en time. Det kan konkurrenten i nabogata også, og det kan byrået som pitcher kunden din neste uke. Når alle sitter med samme maskinvare, er det ikke lenger maskinvaren som er fortrinnet.

Det er premisset bak en idé som er i ferd med å feste seg i performance marketing: PPC OS-et, eller PPC-operativsystemet. Navnet kommer fra PPCOS, et produkt bygget av folkene bak PPC Mastery [1]. Men det som er verdt oppmerksomheten din, er ikke produktet du kan kjøpe. Det er rammeverket under, som enhver dyktig spesialist på betalt søk kan studere og bygge opp på nytt til sitt eget bruk.

Miles McNair, medgründer i PPC Mastery, oppsummerte det slik i workshopen der teamet åpnet opp systemet sitt: «Fortrinnet ditt er ikke agenten, for alle har agenten. Fortrinnet ditt er operativsystemet du bygger for å styre den.» [1]

Så la oss ta det ordentlig: hva et PPC-operativsystem faktisk er, hvorfor det å bygge ditt eget slår å lene seg på Googles innebygde AI, hva som ligger i hvert lag, og i hvilken rekkefølge du bygger et. Arkitekturen her er PPC Masterys, og jeg lenker til arbeidet deres underveis, men poenget er at det er en byggeplan, ikke bare et kjøp.

Hva er et PPC OS?

En kodeagent som Claude Code er i bunn og grunn standard maskinvare. Kraftig, ja, men alene vet den ingenting om kundene dine, standardene dine eller hva «bra» betyr i kontoene dine. Et PPC-operativsystem er programvarelaget som gjør den generiske agenten om til en pålitelig motor for utføring og strategi i Google Ads: kroppen av kunnskap, instruksjoner og sikkerhetsnett den laster inn før den rører en eneste kampanje.

Det er der den varige verdien ligger. Hvem som helst kan kjøre agenten. Ingen kan kopiere din nedskrevne måte å jobbe på, dine SOP-er, din definisjon av et irrelevant søkeord, kundens enhetsøkonomi. Og det akkumulerer. Hver beslutning du skriver ned, gjør neste kjøring litt skarpere, og over tid blir kunnskapsbasen en vollgrav konkurrentene ikke bare kan laste ned [1].

Hvorfor bygge ditt eget i stedet for å bruke Googles AI?

Google skulle helst sett at du lot være. På Google Marketing Live 2026 lanserte de Ask Advisor, en Gemini-drevet agent som spenner over Google Ads, Analytics og Merchant Center, med et delt minnelag som holder på målene dine mens du beveger deg mellom oppgaver [6][7]. Spør den «hvorfor falt resultatene?» og den svarer; be den utarbeide kampanjeendringer, og den gjør det. For mange annonsører er det genuint nyttig, og jeg gikk gjennom hele rekken av nyheter i min gjennomgang av Google Marketing Live 2026.

Men her er haken. Ask Advisor kjører på Googles operativsystem og Googles insentiver. Rådene har en tendens til å peke mot det som øker Googles inntekter: øk budsjettet, slå på AI Max. Omtrent det du kan vente deg av en assistent bygget av selskapet som selger annonseplassen. Bygger du ditt eget PPC OS, bygger du i praksis din egen Ask Advisor, bortsett fra at den kjører på din definisjon av bra. Du bestemmer hvorfor et ROAS-mål er for høyt eller for lavt. Du bestemmer hva som teller som bortkastet forbruk. Den kontrollen er hele poenget [1].

De fire lagene i et PPC-operativsystem

Et fungerende operativsystem trenger alle disse fire lagene. Mangler ett, faller kvaliteten [1].

1. Teknologi, kjøretiden. Selve kodeagenten, koblet til sanntidsdata fra kontoen. PPC Mastery kjører Claude Code, Anthropics terminalbaserte agent som leser filene dine, kjører kommandoer og faktisk utfører arbeid i stedet for bare å prate [3]. Den når Google Ads API-et, ofte via en MCP-server (Model Context Protocol), den åpne standarden Anthropic lanserte for å koble AI-verktøy til datakilder [5][8]. Inngangsprisen ligger rundt 20 dollar i måneden; tung bruk koster 100 til 200.
2. Operativsystemet, kunnskapsbasen. Ekspertisen din, destillert til prosedyrer og deretter oversatt til agentferdigheter («skills»). Dette er hoveddelen av arbeidet, og der de fleste månedene går.
3. Kontekst, forretningsvirkeligheten din. Mål, budsjettmål, marginer, kundehistorikk, begrensninger. Som PPC Masterys AI-arkitekt sa det: «Hvis det bare finnes i hodet ditt, finnes det ikke.» [1] Ferdigheter uten kontekst får agenten til å gjette.
4. Kvalitetssikring, sikkerhetsnettene. Tørrkjøringer, definerte spørringer og menneskelig gjennomgang som hindrer agenten i å skli ut eller hallusinere. Begge spesialistene som ble profilert i workshopen, kjører oppsett med både lese- og skrivetilgang, men ingenting publiseres uten at et menneske ser på det først [1].

Resten av denne artikkelen handler om lag to og tre. Det er der byggingen skjer, og det er det de fleste gjennomganger hopper lett over.

Bygg kunnskapsbasen nedenfra og opp

Kunnskapsbasen er selve hjertet. PPCOS består av rundt 257 dokumenter fordelt på åtte kategorier, og strukturen er ikke tilfeldig: den bygges nedenfra og opp, fordi hvert lag refererer til lagene under [1][2]. Du skriver teorien først fordi de mentale modellene hviler på den, så de mentale modellene fordi SOP-ene hviler på dem, og så videre. Her er hva som ligger i hver kategori, med den typen dokument du ville skrevet for en konto i betalt søk.

• Teori — rammeverkene hele systemet resonnerer ut fra. Et teoridokument kan legge ut systemtenkning, eller teorien om begrensninger, på en side agenten slår opp i når den skal avgjøre hvor den bør bruke kreftene. Disse endrer seg knapt når de først er skrevet.
• Mentale modeller — hvordan du tenker deg gjennom en gjentakende beslutning. «Når skal du segmentere kontra slå sammen en Shopping-kampanje.» «Gylne regler for struktur i søkekampanjer.» «Hvordan de vanlige feilmønstrene ser ut i dataene.» Dette er skjønnet du bruker uten å tenke over det, skrevet ned så agenten kan bruke det også.
• Referanser — tørre, faktiske spesifikasjoner som hindrer agenten i å bomme på detaljer: tegngrenser for responsive søkeannonser, bildedimensjoner og størrelsesforhold per kampanjetype, hvilke GAQL-felter som finnes på en gitt ressurs. Rent sikkerhetsnett, ingen meninger.
• Retningslinjer — standardoppsettet ditt, med begrunnelsen festet ved så agenten vet når det er trygt å avvike. «Dynamiske sitelinks av, dynamiske callouts av, selgervurderinger på, lange overskrifter på», og hvorfor for hvert valg [1].
• Kataloger — biblioteker av alternativer som med vilje ikke gir noen anbefaling. Shopping-segmenteringskatalogen lister for eksempel opp alle måtene å dele opp en feed på: etter produktkategori, etter bestselgere, tilbud kontra ordinær pris, sesong, lagernivå, produktets livssyklus, priskonkurranseevne, eller heroes/sidekicks/villains/zombies-modellen. Katalogen velger ikke. Den sørger bare for at agenten vet at alle alternativene finnes.
• Sjekklister — binære bestått/ikke bestått-porter. Krysset kampanjen av alle boksene før lansering? Agenten kjører lista og rapporterer ja eller nei, ingen tolkning nødvendig.
• SOP-er — de repeterbare prosedyrene, og den største kategorien med 88 dokumenter. SOP-en for testing av responsive søkeannonser, for eksempel, staver ut forutsetningene før selve loopen starter: fiks tilbudet, vinklene, de eksisterende annonsene og søkeordsrelevansen først, kjør så iterasjonen. En SOP som hopper over forutsetningene sine, automatiserer bare en feil raskere.
• Spillebøker (playbooks) — det øverste laget, og fronten. En spillebok er en rutingferdighet: den følger med på et signal, avgjør hvilken ferdighet som skal svare, og fyrer den av. PPCOS har bare to så langt, noe som sier en del om hvor vanskelig dette orkestreringslaget er å få til.

De tre kategoriene folk blander sammen, er kataloger, mentale modeller og retningslinjer, og å holde dem fra hverandre er det som lar agenten resonnere i stedet for å papegøye. En katalog lister opp alternativene og tier. En mental modell holder på resonnementet for å velge mellom dem. En retningslinje gir standardsvaret ditt og hvorfor. Mas dem sammen til én «beste praksis»-fil, og agenten bruker bare det som står der, som er nettopp den generiske oppførselen du prøver å unnslippe. Hold dem adskilt, og den kan veie katalogalternativene opp mot den mentale modellen din og kundens kontekst, og gripe til en retningslinje bare når en faktisk passer [1].

Ett teoridokument fortjener å trekkes frem. McNair kaller flaskehalsanalyse «ferdighetenes mor», og det er egentlig Eliyahu Goldratts teori om begrensninger anvendt på annonser: ethvert system har én bindende begrensning, og krefter brukt et annet sted flytter knapt nålen [9]. Oversatt til betalt søk: er konverteringsraten flaskehalsen din, gjør det å utvide matchtyper eller skru på AI Max bare at mer trafikk presses inn i en lekk trakt. Noen ganger er ikke begrensningen i kontoen i det hele tatt. Et plutselig fall kan spores tilbake til et prishopp i forsyningskjeden, som ikke er noe du fikser i Google Ads uansett hvor lenge du stirrer på dashbordet [1].

Anatomien til én enkelt ferdighet

En ferdighet er det som gjør en prosedyre om til noe agenten kjører på nøyaktig samme måte hver eneste gang. Gapet mellom en menneskelig SOP og en fungerende ferdighet er større enn det ser ut, og å tette det er den egentlige ingeniørjobben [4].

Ta revisjon av søkeord. Menneskeversjonen er to linjer: hent søkeordene, se etter noe irrelevant, legg de dårlige til som negative. Du leser det og vet nøyaktig hva du skal gjøre, fordi du bærer på flere års kontekst bak det. Agenten bærer ingenting av det, så hvert underforstått steg må gjøres eksplisitt. Her er hva én ferdighet faktisk inneholder:

• En definert spørring. Ferdigheten leveres med én eksakt GAQL-spørring så den henter identiske data hver kjøring [1]. Lar du agenten skrive sin egen spørring, formulerer den den litt ulikt hver gang, og da sammenligner du denne ukas revisjon mot forrige ukes på tvers av to litt forskjellige datasett.
• Et skript som kjører den. Ikke en høflig forespørsel om å «hente dataene», men et faktisk skript som treffer Google Ads API-et og returnerer radene. Deterministisk inn, deterministisk ut.
• Et komprimeringsskript. En reell eksport av søkeord kan komme opp i hundretusenvis av rader, og det kan du ikke gi til en språkmodell. Så et skript oppsummerer den først, de største forbrukerne, de dyreste ordene uten konverteringer, den lange halen slått sammen, og agenten leser sammendraget mens råfila blir liggende på disk for når den må sjekke noe [1].
• En business.md. «Irrelevant» betyr ingenting uten kontekst. For en rørlegger er ordet «kurs» søppeltrafikk; for et kursselskap er det hele forretningen. Ferdigheten peker på en fil som definerer hva irrelevant betyr for nettopp denne kunden [1].
• En eksakt endringsmetode. «Legg til de negative» må si hvordan: hvilket skript som skriver dem, om utdataene er en CSV for Google Ads Editor eller en direkte API-push, og at den kjører som en tørrkjøring du godkjenner før noe går live [1]. La det stå vagt, og agenten improviserer en ny metode hver kjøring; den dagen en av dem bommer, klarer du ikke å spore hva den gjorde.

Legg alt dette sammen, og én enkelt ferdighet, søkeordrevisoren, ender på ni filer pluss fire andre ferdigheter den støtter seg på, pluss skriptene [1]. Én ferdighet kan sluke dager med bygging, testing og feilsøking før du stoler på den med en live konto. Det er den reelle kostnaden, og det er ingen som forteller deg den på forhånd.

Det er en grunn til at det tar så mye. Hver ferdighet må kombinere tre lag med kunnskap [1]:

5. Det modellen allerede vet. Generell beste praksis fra treningen, som «ikke bland merkevare- og ikke-merkevaresøkeord i samme annonsegruppe». Dette trenger du ikke å lære den.
6. Hvordan du spesifikt gjør oppgaven. Din metode for å gjennomgå søkeord, din måte å skrive en annonse på. Dette er selve ferdigheten.
7. Kundens forretningskontekst. Marginene deres, målene deres, listen over hva de ikke vil ha. Uten dette tredje laget gjetter agenten med selvtillit.

Hopper du over lag tre, får du generisk output forkledd som skreddersydd råd. Det er den klart vanligste grunnen til at et hjemmebygd OS skuffer.

Ferdigheter jobber heller ikke alene. PPCOS sorterer dem i fire typer, samlere, revisorer, optimerere og produsenter (gatherers, auditors, optimizers, makers), som gir oppgaven videre til hverandre: en samler henter dataene, en revisor flagger et problem, og systemet vet allerede hvilken optimerer som skal kjøre neste [10]. Skrivinger settes bevisst i en forsiktig pipeline, lesinger først, så små endringer, så større, i stedet for å la agenten skrive om en konto i ett jafs [10]. Og Anthropic har siden gjort Agent Skills til en åpen standard, mapper med instruksjoner og skript en agent laster inn bare når de er relevante [4], noe som gjør hele dette laget langt mer flyttbart enn det var for et år siden.

Kontekst-engineering: den egentlige flaskehalsen

Enhver stor språkmodell har to strukturelle problemer, og et brukbart PPC OS må løse begge. Dette er lag tre, og det er her mesteparten av det løpende arbeidet faktisk går [1].

Det første problemet er tilstandsløshet. Hver økt starter på null; modellen husker ingenting fra i går. Løsningen er en mappestruktur som fungerer som minne, og kontoranalogien er den klareste måten å se det for seg. Hub-mappa er selve byrået. Inni den får hver kunde sitt eget rom, en mappe som rommer konteksten deres, kontohistorikken og en løpende endringslogg. Agenten skriver tilbake til disse filene mens den jobber, så minnet tykner over tid: denne månedens revisjon kan se hva forrige måned endret og hvorfor. Og fordi rommene er forseglet fra hverandre, lekker ingenting fra én kunde inn i en annen kundes anbefalinger [1].

Hver mappe bærer også en CLAUDE.md, en fil agenten laster inn helt i starten av hver økt. Tenk på den som systemprompten pluss et kart. Den rommer ikke kunnskapen selv; den merker hvor kunnskapen ligger, kundekontekst her, Google-data der, merkevareretningslinjer der borte, og setter husreglene. Workshopens analogi er den som sitter: uten en CLAUDE.md er agenten en praktikant som åpner hver dør i bygget på jakt etter én stiftemaskin; med den er dørene merket, og den går rett til riktig en [1]. Det er forskjellen på en agent som brenner hele kontekstvinduet sitt på å vandre rundt, og en som holder seg skarp på oppgaven.

Det andre problemet er kontekstvinduet. Den oppgitte grensen kan være en million tokens, men svarkvaliteten faller lenge før det. Du kan ikke slenge 200 dokumenter og en eksport på 500 000 rader med søkeord på modellen og vente noe sammenhengende tilbake; den leser den første biten og hallusinerer resten. Løsningene er komprimeringsskriptene fra tidligere, som koker store datasett ned før agenten i det hele tatt ser dem, og de definerte spørringene per ferdighet som holder hvert datauttrekk stramt og likt [1].

Det er også her romantikken rundt «revider kontoen din på 90 sekunder» faller fra hverandre. Slash-kommandoen er rask. Arbeidet er det ikke. Da PPC Mastery demonstrerte en «rask» revisjon, gikk mesteparten av tiden til å samle kontekst, bygge et langt kundespørreskjema, mate svarene tilbake, la systemet flagge motsetninger, og det er den delen du ikke kan automatisere bort [1]. Kontekst-engineering blir aldri helt ferdig; det er tingen du alltid fyller på.

Slik bygger du ett, steg for steg

Du setter ikke sammen alt dette på én gang, og du bør ikke prøve. Her er en realistisk rekkefølge for å gå fra ingenting til et fungerende, om enn lite, operativsystem for betalt søk.

8. Velg kjøretid, og hold det billig. Start med Claude Code på inngangsplanen, kjørende inne i Cursor, der pluginen er gratis [3]. Ikke øs penger eller uker i verktøy før du har bevist arbeidsflyten på én konto.
9. Koble til dataene dine, kun lesing. Koble agenten til Google Ads API-et, helst via en MCP-server så du kan be om data på naturlig språk og la den lage spørringen under [5][8]. Start strengt med kun lesetilgang. Agenten kan hente og analysere, men ikke endre noe, og du vil ha uker med å se den resonnere før den noensinne rører en live kampanje.
10. Bygg mappestrukturen. Én hub-mappe, én kundemappe inni. I kundemappa skriver du ned det du allerede vet: målene deres, marginene, listen over hva de ikke vil ha, den nylige historikken. Dette er lag tre, laget de fleste hopper over, som er nettopp derfor agenten deres gir generiske råd [1].
11. Skriv din første CLAUDE.md. Hold den kort. Fortell agenten hvor hver fil ligger, hva denne kunden selger, hva «bra» betyr i denne kontoen, og den ene regelen den aldri kan bryte: publiser aldri uten din godkjenning. Du utvider fila etter hvert [1].
12. Kod én ferdighet, fra ende til ende. Velg den hyppigste irriterende oppgaven; søkeordrevisjon er det vanlige førstevalget. Skriv den definerte spørringen, skriptet som kjører den, komprimeringsskriptet, og business.md-en som sier hva irrelevant betyr her. Sett endringsmetoden til en tørrkjørt CSV du gjennomgår for hånd. Det er én komplett ferdighet, og den tar lengre tid enn du tror. Det er normalt [1].
13. Kjør den kun-lesing og gjennomgå alt. Fyr av ferdigheten, les det den produserer, og sammenlign det mot det du selv ville gjort. Der den bommer, er løsningen sjelden modellen; det er en manglende bit kontekst eller et underspesifisert steg. Lapp ferdigheten, kjør igjen. Denne loopen er selve arbeidet [1].
14. Legg til en sjekkliste og sikkerhetsnett. Før du noensinne lar en ferdighet skrive til kontoen, pakk den inn i en sjekkliste, respekterte den lista over hva de ikke vil ha, er endringen reversibel, og behold tørrkjøringsporten foran den. Dette er kvalitetssikringslaget, og det er det som står mellom deg og en agent som selvsikkert svir av en kampanje [1].
15. Bygg neste ferdighet, så en spillebok. Når du har tre–fire ferdigheter, skriv en tynn spillebok som ruter mellom dem: hvis revisoren flagger bortkastet forbruk, kjør produsenten for negative søkeord neste [10]. Dette orkestreringslaget er det vanskeligste og mest verdifulle, og det selv PPCOS knapt har begynt på, så ikke bli motløs av at det går sakte.

Legg merke til hva som mangler på lista: «la den kjøre uten tilsyn». Begge spesialistene som faktisk har skalert dette, holder et menneske som gjennomgår hver endring [1]. Operativsystemet gjør deg raskere. Det gjør deg ikke fraværende.

Bygge fra bunnen, eller forke et eksisterende OS?

To ærlige veier her. Å bygge fra bunnen gir deg total kontroll og koster hundrevis av timer; PPC Masterys eget system tok måneder og er, etter deres egen innrømmelse, «fortsatt halvveis». Eller du kobler deg på et eksisterende operativsystem som PPCOS, forker det, roter rundt under panseret og bytter inn dine egne prosedyrer [2][11]. Selv da må du fortsatt levere lag tre, kundekonteksten din, og du bør bygge i det minste noen av dine egne ferdigheter. Ingen andre kan forklare hvordan du skriver en søkeannonse.

Én sikkerhetsmerknad verdt å gjenta: nedlastbare ferdigheter kan være spekket med skadelig kode for å stjele API-nøklene dine. Sjekk hva du installerer [1].

Hva det faktisk låser opp

Ingenting av dette er teoretisk. Workshopen profilerte to spesialister som kjører motsatte modeller på samme grunnmur [1]:

• Volumspillet. En gründer driver 40+ e-handelskontoer med et tomannsteam og en egen agent han behandler som en ekte ansatt, med egen innlogging og alt. En diagnoserutine feier gjennom hver konto daglig og løfter frem dagens prioriteringer. Han anslår at han har vunnet tilbake 60 til 80 % av dagen, som går rett inn i å skaffe nye kunder.
• Dybdespillet. En annen håndterer rundt 50 kunder, mest lead-gen, og tok rapporteringen fra fem dager ned til omtrent to timer, kjørende flere oppgaver samtidig. Han holdt prisene flate og leverer mer per retainer i stedet, og satser på lojalitet.

Tre ting de deler: menneskelig gjennomgang før noe går live, retainer-priser fremfor timepris (som slutter å gi mening i det øyeblikket AI kollapser tiden din til levering), og ingen illusjon om at AI-en gjør tenkingen. «En tosk med et verktøy er fortsatt en tosk», som McNair liker å si. Eller, fra en av de to: «AI-first i seg selv gir ikke mening, det er alltid AI-first noe.» Du må være eksperten først.

Fortrinnet ditt er operativsystemet

Hvis én ting skal feste seg, la det være dette. Agenten er en handelsvare. Operativsystemet du bygger rundt den, prosedyrene dine, konteksten din, sikkerhetsnettene dine, din definisjon av bra, er det som akkumulerer og det ingen kan kopiere.

Du trenger ikke å skrive alle 257 dokumentene denne måneden. Start i det små. Åpne én kundemappe, skriv én CLAUDE.md, gjør én SOP om til én ferdighet, og kjør den kun-lesing til du stoler på den. Hold deg selv i loopen. Legg så til neste ferdighet. Teamene som drar ifra i betalt søk akkurat nå, er ikke de med den smarteste modellen, for alle har samme modell. Det er de som begynte å bygge operativsystemet rundt den først.

Kilder

[1] How to Win in the Agentic Era (workshop) — PPC Mastery. https://www.youtube.com/watch?v=DlKh7AJh6p4
[2] PPC OS Knowledge Base — PPC Mastery. https://os.ppcmastery.com/
[3] Claude Code — Anthropic. https://www.anthropic.com/product/claude-code
[4] Equipping agents for the real world with Agent Skills — Anthropic. https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
[5] Introducing the Model Context Protocol — Anthropic. https://www.anthropic.com/news/model-context-protocol
[6] Google launches Ask Advisor across Ads, Analytics and Merchant Center — Search Engine Land. https://searchengineland.com/google-launches-ask-advisor-across-ads-analytics-and-merchant-center-478114
[7] Ask Advisor — Google. https://business.google.com/us/accelerate/announcements/ask-advisor/
[8] What is the Model Context Protocol (MCP)? — modelcontextprotocol.io. https://modelcontextprotocol.io/docs/getting-started/intro
[9] Theory of Constraints — Theory of Constraints Institute. https://www.tocinstitute.org/theory-of-constraints.html
[10] PPCOS: An AI Operating System for Google Ads — Pitcocy. https://pitcocy.com/projects/ppcos-ai-agent-challenge
[11] The PPC Hub — PPC Mastery. https://www.ppcmastery.com/hub