AI-stacken jeg faktisk kjører i produksjon
En gjennomgang av AI-verktøyene som er i aktiv bruk i klientarbeid og egne produkter: hva som har fortjent plassen, hva som ble kuttet, og hvilken operating logic som holder stacken sammen.
GTM-arkitekt & Growth-operatør · Insights · 22. mai 2026
TL;DR · Key insights
- Stacken har fire lag: reasoning, execution, research og CRM/data. Hvert lag har en konkret jobb.
- Det som ble kuttet er like viktig som det som ble igjen: Zapier, Notion AI og flere enrichment-verktøy holdt ikke i ekte produksjonsarbeid.
- Testen for alle AI-verktøy: skaper det bedre output, eller flytter det bare arbeid rundt?
Det finnes en versjon av denne artikkelen jeg ikke skriver: 47 verktøy, sammenligningsmatrise og score fra én til ti. Du har lest den. Den hjalp ikke.
Dette er den andre versjonen: hvert AI-verktøy som faktisk kjører i production stacken min, hvilken jobb det gjør, og hvorfor det har fortjent plassen. Jeg viser også hva som ble kuttet, fordi den listen ofte er mest nyttig.
Rammen er enkel: Jeg skiller mellom verktøy som skaper bedre output, og verktøy som bare flytter arbeidet rundt. Den første typen blir. Den andre brenner tid og gir en følelse av produktivitet uten å forbedre systemet.
Stacken lag for lag
Lag 1: Reasoning
Claude Sonnet / Opus bruker jeg til kompleks diagnose: ICP-analyse, GTM-arkitektur og positioning synthesis. Det er oppgaver der flere constraints må holdes samtidig, og der svaret må være forsvarlig, ikke bare sannsynlig.
Jeg bruker ikke Claude til alt. Rutinedrafts, enkle rewrites og raske research-spørsmål trenger ikke full reasoning. Å bruke Opus på en subject line er som å bruke momentnøkkel til å henge opp et bilde.
Testen: Kan jeg komme til samme svar uten dette? Hvis ja, bruker jeg det ikke. Hvis oppgaven trenger trade-offs, motstridende signaler og et koherent argument fra spredte inputs, er reasoning-laget riktig.
Lag 2: Execution
Claude Code kjører agent stacken. Research pipelines, enrichment loops, content drafts fra auditdata og CRM-klassifisering skjer her. Det er verktøyet med størst leverage, fordi det kobler intelligence-laget til faktisk work product.
Konfigurasjonen er viktig: CLAUDE.md per klient, MCP tools for datatilgang og Skills for navngitte sub-tasks. Jeg har skrevet om outbound stacken og hvordan den kjøres i klientengasjementer. Kort sagt: Claude Code med god operator-kontekst produserer arbeid som tidligere krevde et team.
Cursor bruker jeg til kode som skal bo i repo. MCP servere, Cloudflare Workers og produktfeatures bygges der. Claude Code tenker og driver agentarbeid; Cursor håndterer IDE, editing og diff review.
De er ikke redundante. Claude Code er operator. Cursor er editor.
Lag 3: Research
Exa MCP gir real-time web research inne i agent runs. Exa er bygget for LLM-bruk: semantic search, rene svar og mindre crawler-støy. Det erstattet Brave Search fordi kvaliteten på company research er bedre.
Browser automation MCP med Playwright brukes for sider som blokkerer scraping: LinkedIn company pages, enkelte SaaS pricing pages og Glassdoor-signaler. Ikke bulk crawling, men noen få high-value sider per engagement.
Perplexity bruker jeg som rask research brief-generator for markeder, bransjer og tekniske temaer. Jeg behandler det ikke som kilde. Alt viktig verifiseres.
Lag 4: CRM og data
HubSpot MCP brukes til CRM operations: lese contact og company records, klassifisere mot ICP-kriterier, flagge data quality issues og lage update payloads. Med MCP i loop er klassifiseringslogikken konsistent og auditerbar.
GA4 / Amplitude er datakilder. Jeg henter reports eller bruker API, gir strukturerte data til reasoning-laget og spør: “Her er 90 dager acquisition og conversion by cohort: hva er diagnosen?”
Hva ble kuttet
Zapier ble erstattet av MCP servers. Zapier er bra til enkle app-koblinger, men komplekse workflows ble maintenance-problemer. MCP krever mer setup, men er inspiserbart, versjonerbart og mer robust.
Notion AI forsvarte aldri plassen. Output var generisk, og konteksten var for smal. Jeg skriver i Notion, men tenker med Claude.
Apollo/Clearbit enrichment ble erstattet av agent research for min use case. Ved stort salesvolum kan credits gi mening. For researchkvalitet og personaliseringsdybde i client work gir agent stacken bedre output til lavere kost.
GPT-4 / Gemini er ikke aktive. Ikke fordi de er dårlige, men fordi stacken allerede er koherent. Flere modeller uten spesifikk jobb skaper beslutningsstøy.
Operating logic
Stacken er ikke en verktøyliste. Den er beslutninger om hvor intelligence sitter i workflowen og hva hvert lag eier.
- Reasoning layer: holder judgment, diagnostiserer problemet, setter logikken.
- Execution layer: kjører arbeidet, produserer output, bevarer kontekst.
- Research layer: sender real-world data inn i de andre lagene.
- Data layer: lagrer hva som skjedde og hva det betyr.
Et verktøy fortjener plassen hvis det gjør en av disse jobbene bedre enn alternativet. Når output blir dårligere, maintenance øker, eller et bedre valg finnes, ryker det.
Stacken vil endre seg. Noe av dette er borte om seks måneder. Det er greit. Operating logic blir.
Hvis du bygger en AI stack for GTM og vil ha en second opinion på hva som bør beholdes eller kuttes, book en samtale.
