Den AI-stack jeg faktisk kører i produktion
En rundtur gennem de AI-tools, der aktivt bruges i mit client work og mine produkter: hvad der har fortjent sin plads, hvad der er blevet fjernet, og hvilken operating logic der holder stacken sammen.
GTM architect & Growth operator · Insights · 22. maj 2026
TL;DR · Key insights
- Stacken har fire lag: reasoning, execution, research og CRM/data. Hvert lag har et klart job.
- Det der blev skåret fra er lige så vigtigt som det der blev: Zapier, Notion AI og flere enrichment-tools overlevede ikke rigtigt produktionsarbejde.
- Testen for ethvert AI-tool: skaber det bedre output, eller flytter det bare arbejdet rundt?
Der findes en version af denne artikel, jeg ikke skriver: 47 tools, en sammenligningsmatrix og en score ud af ti. Du har læst den artikel. Den hjalp ikke.
Her er den anden version: alle AI-tools, der faktisk kører i min production stack, hvilket job de har, og hvorfor de har fortjent pladsen. Jeg viser også, hvad der blev skåret fra, for den liste er ofte mere nyttig end keep-listen.
Min grundregel er enkel: Jeg skelner mellem tools, der skaber bedre output, og tools der bare flytter arbejdet rundt. Den første type bliver. Den anden bruger tid og får dig til at føle dig produktiv, uden at systemet bliver bedre.
Stacken lag for lag
Lag 1: Reasoning
Claude Sonnet / Opus bruger jeg til kompleks diagnose: ICP-analyse, GTM architecture reviews og positioning synthesis. Altså opgaver, hvor flere constraints skal holdes samtidig, og hvor svaret skal være forsvarligt, ikke bare sandsynligt.
Jeg bruger ikke Claude til alt. Rutine-drafts, simple rewrites og almindelige research-spørgsmål behøver ikke fuld reasoning. At bruge Opus på en subject line er som at bruge momentnøgle til at hænge et billede op.
Testen er: Kan jeg nå samme svar uden det? Hvis ja, bruger jeg det ikke. Hvis opgaven kræver trade-offs, modsatrettede signaler eller et argument fra spredte inputs, er reasoning-laget rigtigt.
Lag 2: Execution
Claude Code kører agent stacken. Research pipelines, enrichment loops, content drafts fra auditdata og CRM-classification kører her. Det er det største leverage-tool, ikke fordi det er smartest, men fordi det forbinder intelligence-laget med faktisk work product.
Konfigurationen betyder mest: CLAUDE.md pr. client, MCP tools til dataadgang og Skills til navngivne sub-tasks. Jeg har beskrevet outbound stacken og hvordan den kører i client engagements. Kort sagt: Claude Code med god operator-kontekst producerer arbejde, der tidligere krævede et team.
Cursor bruger jeg til kode, der skal leve i et repo. MCP servere, Cloudflare Workers og produktfeatures bygges dér. Claude Code tænker og driver agentarbejde; Cursor håndterer IDE, editing og diff review.
De overlapper ikke. Claude Code er operator. Cursor er editor.
Lag 3: Research
Exa MCP giver real-time web research inde i agent runs. Exa er bygget til LLM-brug: semantic search, rene svar og mindre crawler-drama. Det erstattede Brave Search i min stack, fordi kvaliteten på company research er bedre.
Browser automation MCP med Playwright bruges til sider, der blokerer scraping: LinkedIn company pages, nogle SaaS pricing pages, Glassdoor-signaler. Ikke bulk crawling, men high-value sider hvor statisk search ikke er nok.
Perplexity er til hurtige research-briefs om markeder, brancher eller tekniske emner. Jeg bruger det som startpunkt, ikke kilde. Alt vigtigt bliver verificeret.
Lag 4: CRM og data
HubSpot MCP bruges til CRM operations: læse contacts og companies, klassificere mod ICP-kriterier, flagge data quality issues og generere update payloads. Med MCP i loopet bliver klassificeringslogikken konsistent og auditable.
GA4 / Amplitude er datakilder, ikke AI-tools. Jeg eksporterer reports eller bruger API, giver strukturerede data til reasoning-laget og stiller operator-spørgsmål: “Her er 90 dages acquisition og conversion by cohort: hvad er diagnosen?”
Hvad blev skåret fra
Zapier blev erstattet af MCP servers. Zapier er stærkt til simple app-forbindelser, men komplekse workflows blev maintenance-problemer. MCP kræver mere setup, men er inspectable, versionable og mere robust.
Notion AI retfærdiggjorde aldrig sin plads. Output var generisk, og konteksten var for snæver. Jeg skriver i Notion, men tænker med Claude.
Apollo/Clearbit enrichment blev erstattet af agent research til min use case. Ved stort salesvolumen kan credits give mening. Til dyb research og personalisering i client work giver agent stacken bedre output til lavere cost.
GPT-4 / Gemini er ikke i aktiv brug. Ikke fordi de er dårlige, men fordi stacken allerede er coherent. Flere modeller uden et specifikt job skaber beslutningsstøj.
Operating logic
Stacken er ikke en liste af tools. Den er en række beslutninger om, hvor intelligence sidder i workflowet, og hvad hvert lag er ansvarligt for.
- Reasoning layer: holder judgment, diagnosticerer problemet, sætter logikken.
- Execution layer: kører arbejdet, producerer output, bevarer kontekst.
- Research layer: sender real-world data ind i de andre lag.
- Data layer: gemmer hvad der skete, og hvad det betyder.
Et tool fortjener sin plads, hvis det gør et af disse jobs bedre end alternativet. Når output bliver dårligere, maintenance bliver højere, eller et bedre valg findes, ryger det ud.
Stacken ændrer sig. Noget på listen er væk om seks måneder. Det er fint. Operating logic bliver.
Hvis du bygger en AI stack til GTM og vil have en second opinion på, hvad der skal blive eller skæres fra, book et call.
