MCP er noe dritt

En av kundene våre har prøvd et verktøy for å måle AI-synlighet. Resultatet fra verktøyet var at kunden lå langt bak konkurrentene. Deretter la de inn en konkurrent som «eget selskap», og plutselig var det konkurrenten som lå etter.

Selskapet som var registrert som kunden, kom dårligst ut, uansett hvem det var.

Det er ikke nytt at verktøy roper ulv. Her ble det dokumentert svart på hvitt. Det er trolig ikke gjort med vilje av dem som tilbyr løsningen. Vi har ikke sett koden, men den sannsynlige forklaringen er at modellen ble bedt om å vurdere «din» synlighet mot konkurrentene, og at svaret ble farget av hvordan spørsmålet ble stilt.

Hva ville skjedd dersom kunden hadde styrt etter rapporten? De ville flyttet budsjett og innsats for å tette et gap som ikke fantes, og fortalt ledelsen at de taper terreng. Et måleverktøy som gir feil svar, er verre enn ingen måling, fordi det fremstår som innsikt.

Som byråleder har jeg ansvaret for retningen i NOVA Rocket og for hva vi investerer i. Faglig leder setter standarden, og den kundeansvarlige tar beslutningene i hvert enkelt case. Min jobb er å sørge for at de har det de trenger: en rigg som gir tall som holder, og utviklere å jobbe tett med. Hvordan tallene blir til, er derfor et ledelsesspørsmål hos oss.

Telling er en jobb for kode

Å måle AI-synlighet handler om telling: Still de samme spørsmålene, tell hvor ofte hvert merke nevnes, og regn ut andelen. Hvem som er «deg», skal ikke påvirke tallet. Det er en jobb for kode.

Vegard Rohde Garder er Fagleder i NOVA Rocket og markedsfører:

Hvem bryr seg om at du har brukt AI? Det interessante er om du løser et problem på en måte som ikke var mulig før. Hvis ikke, bør løsningen i det minste være vesentlig bedre enn det vi allerede har. Ellers er det bare vibekoding med et grensesnitt rundt.

Når arbeidsminnet blir fullt

Når en språkmodell får gjøre telling og vurdering i samme operasjon, går det galt. Gjør den det via MCP, betaler du to ganger: i tokens og i presisjon.

Hver MCP-kobling har en pris. Bare beskrivelsene av verktøyene tar plass i modellens arbeidsminne, kontekstvinduet, før agenten har gjort noe som helst. Kobler du til ti verktøy uten en plan, går en god del av minnet til bruksanvisninger. Når agenten deretter henter rådata runde etter runde, fylles resten opp.

Resultatet er høyere tokenforbruk og mindre presise svar. I et eksempel Anthropic har publisert, gikk én oppgave fra 150 000 til 2 000 tokens da agenten skrev kode i stedet for å kalle verktøyene ett og ett. Kostnaden er likevel det minste problemet. Feilen oppstår i modellen, som får for lite plass til å tenke. MCP er bare døren dataene kommer inn gjennom.

Når agenten ikke skiller mellom butikkene

Tenk deg en kjede med butikker over hele landet. En snørik vinter selger butikkene rundt Mjøsa ski så fort de kommer inn. Butikken i Bergen har knapt ski på hyllene og selger fotballsko hele året. En AI-agent som styrer markedsføringen på kjedenivå, ser at ski selger, og øker skibudsjettet over hele landet. I Bergen går pengene til varer butikken ikke har, og kundene finner ikke det de så i annonsen.

Erik Heggeland, Head of Commerce i Novacare, har jobbet med e-handel siden 2006:

Som retailer har du data om lagerstatus, priser og kampanjer i systemene dine. Kobler du en AI-agent på mediebudsjettet uten disse dataene, styrer den etter halve bildet.

Men det hjelper ikke å koble på lagerstatus alene. Riktig oppsett snur rekkefølgen. Koden henter salg og lagerstatus per butikk og regner ut hvilke varer som både selger og finnes på hyllene i hvert område. Markedsføreren setter reglene, for eksempel at en vare ikke annonseres lokalt når lageret er under et visst nivå. Først da slipper AI-en til: Den fordeler budsjettet og tilpasser annonsene innenfor rammene koden har satt. Skiannonsene går til butikkene rundt Mjøsa, og fotballskoene til Bergen.

Derfor trenger teamet en tredje kompetanse ved siden av markedsføring og AI: Noen som designer hvordan AI-en får tilgang til data og verktøy. Hvilke koblinger skal agenten ha? Hva skal hentes og regnes ut med kode før AI-en i det hele tatt ser det?

Kenneth Solberg, Seniorutvikler i Novacare:

Det første jeg spør om når noen vil koble en AI-agent på et nytt system, er: Hva skal den faktisk se, og på hvilket nivå? Ofte trenger den færre data enn man tror, men de må være de riktige.

Hvordan får du utvikleren og markedsføreren til å spille ball?

I NOVA fordeler vi arbeidet etter fire roller. Bygget etter dem ville synlighetsverktøyet sett slik ut:

1. Markedsføreren skriver instruksjonene: 
   Bestemmer hvilke spørsmål som skal stilles.

2. Koden styrer flyten og beregningene: 
   Stiller spørsmålene, teller treffene og regner ut andelene.

3. AI-en gjør de skjønnsmessige vurderingene:
   Vurderer hvordan merket omtales.

4. Kunden gir konteksten:
   Om merkevaren og konkurrentene.

Det krever en utvikler som forstår forretningen, og en markedsfører som forstår teknologien godt nok til å vite hva den kan og ikke kan. Da blir tallene de samme, uansett hvem som er registrert som «deg».

Hva dette betyr for deg som markedsdirektør

Jeg får ofte spørsmål om hvilke AI-verktøy vi bruker. Det viktigere spørsmålet er hvilke tall du styrer etter, og hvem som kan forklare hvordan de er laget. Det handler om bestillerkompetanse.

Tre ting hører etter min mening hjemme på markedsdirektørens bord:

1. Eierskap til dataene. Lagerstatus, priser, kundedata og måling er grunnmuren. Den bør du eie selv, uansett hvilke verktøy som bygges oppå.

2. Tall som kan forklares. Krev at byrået og leverandørene kan vise hvilken del av et tall som er regnet ut, hvilken som er vurdert, og hva målingen ikke fanger opp. Kan de ikke det, bør tallet ikke påvirke budsjettet.

3. Datafangst før AI. Gevinsten av AI kommer når dataene er på plass. Hver beslutning er bare så god som dataene og utregningen bak.

Derfor har vi bygget riggen vår fra bunnen: ordentlig datafangst, beregninger i kode og AI der det trengs skjønn.

Markedsfører, teknolog og AI. Mangler én av dem, er det du som får svi.