LLM-stacken 2026: modeller, inferens, verktyg och avvägningar

Om du bygger riktiga AI-produkter 2026 frågar du inte längre ”ska jag använda OpenAI eller Anthropic?”. Det synsättet är två år föråldrat. Du fattar dussintals beslut i en stack med flera lager, och de flesta av dem spelar roll.

Den här artikeln ger en verksam arkitekts bild av LLM-stacken 2026 – vad som finns i varje lager, vilka avvägningar du gör och vart området är på väg. Det är artikeln vi önskar att någon hade skrivit åt oss innan vi gjorde alla misstag som hade kunnat undvikas.

Lagren

Stacken ser i stora drag ut så här:

┌────────────────────────────────────┐
│          Applikationslager         │  Din produkt/agent/ditt arbetsflöde
├────────────────────────────────────┤
│      Orkestrering/ramverk          │  LangGraph, CrewAI, eget, direkt
├────────────────────────────────────┤
│   Prompt- och kontexthantering     │  Promptmallar, kontextutveckling
├────────────────────────────────────┤
│       Hämtning/minne               │  RAG, vektorlager, strukturerat minne
├────────────────────────────────────┤
│       Verktygs-/MCP-lager          │  Verktygsanrop, MCP-servrar, funktions-API:er
├────────────────────────────────────┤
│          Modellager                │  Specifikt modellval, dirigering
├────────────────────────────────────┤
│         Inferenslager              │  Driftade API:er, egen drift, edge
├────────────────────────────────────┤
│ Observerbarhet/utvärderingar       │  Loggning, spårning, utvärderingssviter
└────────────────────────────────────┘

Varje lager har flera användbara alternativ. Valet i ett lager begränsar alternativen i andra. Tidiga beslut är svåra att ändra – modellvalet påverkar inferensvalet, som påverkar orkestreringsvalet.

Vi går igenom dem ett i taget.

Lager 1: modellagret

Modellerna 2026 grupperar sig i grova nivåer, och valet mellan dem är systemets mest betydelsefulla beslut per anrop.

Ledande resonemangsnivåer. Tankelägena i dagens toppmodeller – GPT-5.5 med resonemang, Claude Opus 4.8 med adaptivt tänkande, Gemini 3.1 Pro thinking – samt renodlade resonemangsmodeller som DeepSeek R1. Utmärkta för flerstegsproblem, matematik, kod och komplex analys. Dyra (3–30 USD per miljon indatatoken, betydligt mer för utdata) och långsammare (5–60 sekunder). Använd dem när resonemangskvaliteten är flaskhalsen.

Ledande generella modeller. GPT-5.5, Claude Sonnet 5, Gemini 3.1 Pro. Utmärkta för det mesta kunskapsarbetet, snabba (2–5 sekunder) och måttligt dyra (2–5 USD per miljon indatatoken). Standardvalet för användarnära svar av hög kvalitet.

Modeller i mellanskiktet. Claude Haiku 4.5, Gemini 3.5 Flash och OpenAI:s mellannivå. Bra för enkla till medelsvåra uppgifter, snabba (1–2 sekunder) och billiga (1–2,50 USD per miljon indatatoken). Används mycket i produktion för klassificering, extraktion och enkel generering.

Små/budgetmodeller. Leverantörernas minsta aktuella nivåer (exempelvis Gemini 3 Flash Preview) och små modeller med öppen källkod. Tillräckliga för smala, strukturerade uppgifter. Mycket billiga (0,50–1 USD per miljon indatatoken) och mycket snabba (<1 sekund). Använd dem för dirigering, poängsättning och batchbearbetning.

(Listpriserna verifierades 2026-07-07 mot leverantörernas prissidor. Nivåerna förändras – kontrollera igen innan du lämnar prisuppgifter.)

Specialiserade modeller. Modeller för inbäddningar, omrankning, bild, röst och kod. De är billigare än generella modeller för sina specifika uppgifter och oftast bättre. Överväg dem alltid för relevanta uppgifter.

Öppen källkod i framkant. Llama 4, DeepSeek V3/R2, Qwen 3, Mistral Large. Driftas hos inferensleverantörer (Groq, Together, Fireworks) eller i egen regi. Pris och kvalitet konkurrerar med slutna toppmodeller för många uppgifter, men släpar efter för vissa, särskilt resonemang över långa förlopp.

Konsekvenserna:

• En enda modell passar inte alla anrop i systemet. Dirigering är ett krav för att styra kostnaderna (se lager 5).
• Frontlinjen flyttas varje kvartal. Bygg för modellbyte, inte inlåsning.
• Öppen källkod är nu ett verkligt alternativ för många produktionsfall, inte bara för experiment.

Lager 2: inferenslagret

Var körs modellen i praktiken?

Leverantörer av slutna API:er – OpenAI, Anthropic, Google. Snabbaste vägen till drift, de bästa modellerna och högst tillförlitlighet. Du betalar ett högre pris och accepterar deras modell för data och säkerhet.

Inferensleverantörer för öppen källkod – Groq, Together AI, Fireworks, Replicate. Kör öppna modeller med olika optimeringar. Ofta mycket snabbare än egen drift och med konkurrenskraftiga priser. (Marknaden konsolideras snabbt – flera leverantörer från 2024 finns inte längre. Verifiera alltid leverantören innan du binder dig.)

Molnnativa tjänster – AWS Bedrock, Azure OpenAI, Google Vertex. Samlar slutna och öppna modeller under molnplattformens autentisering, fakturering och regelefterlevnad. Nödvändigt i många företagsmiljöer.

Egen drift – vLLM, TGI, SGLang, LMDeploy på egna GPU:er. Lägst kostnad per token i stor skala. Högst operativ komplexitet. Vanligen värt att överväga först när inferenskostnaden ligger i det övre ensiffriga tusentalet euro per månad (se artikeln om egen kontra driftad inferens för en nollpunktsberäkning).

Edge/på enheten – Apple Intelligence, MediaPipe, ONNX, GGUF-modeller via Ollama eller llama.cpp. Kostnadsfritt per anrop, men med begränsad modellkapacitet. Allt mer användbart för smala tillämpningar.

Avvägningarna:

• Latens spelar roll: röstagent och konversationsgränssnitt behöver snabb första token. Groq, Cerebras och körning på enheten dominerar här.
• Kapacitet spelar roll för batchjobb: bearbetar du miljontals poster behöver du hög kapacitet, inte låg latens.
• Regelefterlevnad spelar roll: GDPR, HIPAA och SOC 2 avgör ofta vilka leverantörer och regioner du kan använda.
• Leverantörsrisk spelar roll: fullständigt beroende av en leverantör är en enskild felpunkt. Flera leverantörer är god hygien.

Ett vanligt mönster 2026 är driftade, slutna modeller för användarnära begäranden med högst kvalitetskrav, driftad öppen källkod för billigare högvolymsarbete och körning på enheten för smala, latenskänsliga funktioner. Egen drift används först när skala och ekonomi motiverar den operativa bördan.

Lager 3: verktyg och MCP

LLM:er kan inte göra särskilt mycket på egen hand. De blir användbara när de kan anropa verktyg – funktioner som du definierar och som ger dem åtkomst till data, API:er och åtgärder.

Inbyggda funktionsanrop. Alla större modeller stöder ett strukturerat API för funktionsanrop. Du definierar funktioner med JSON-scheman, modellen avgör när de ska anropas, du kör anropet och returnerar resultatet.

MCP (Model Context Protocol). Ett standardiserat protokoll som introducerades av Anthropic och nu används brett, även av OpenAI, Cursor och andra, för verktygsservrar. En MCP-server exponerar verktyg. En MCP-klient (en LLM-agent) ansluter och använder dem. Verktygsimplementeringen frikopplas från en viss modell.

Direktintegrationer. För specifika högvolymfall, exempelvis ett visst CRM-system eller en viss databas, är det ofta enklare att skriva en direktadapter än en generell MCP-server.

Trenden 2026 är tydlig: MCP vinner som standard. Merparten av ny verktygsutveckling bör inriktas på MCP. Direktintegrationer är fortsatt värdefulla på prestandakänsliga vägar.

Några realiteter i implementationen:

• Verktygsbeskrivningar har enorm betydelse. Ett bristfälligt beskrivet verktyg används fel. Dokumentationssträngar för verktyg bör skrivas som prompter.
• Antalet verktyg spelar roll. Modeller med fler än 50 tillgängliga verktyg presterar sämre än modeller med 5–10 relevanta verktyg. Gallra hårt.
• Felhantering spelar roll. Verktygsfel måste kommuniceras strukturerat till modellen så att den kan anpassa sig.
• Behörighetsstyrning är svårt. Ett fleranvändarsystem där LLM:en har olika behörigheter för olika användare är inte trivialt. Låt inte LLM:en fatta behörighetsbeslut. Gör det i verktygsomslaget.

Lager 4: hämtning och minne

LLM:er behöver data som de inte tränats på. Det är hämtningslagrets uppgift.

Vektordatabaser. Pinecone, Weaviate, Qdrant, Chroma, PostgreSQL med pgvector, Turbopuffer. Lagrar inbäddningar och hanterar frågor om närmaste grannar. Moget och väl förstått. Standardvalet för semantisk hämtning.

Hybridsökning. Kombinerar vektorsökning med traditionell BM25-nyckelordssökning. Fångar både semantiska och lexikala träffar. Kombinera dem med Reciprocal Rank Fusion. Verktyg: Elasticsearch, OpenSearch, Vespa.

Kunskapsgrafer. Neo4j, Memgraph och egna trippellager. För data med rika relationer. Används i graph RAG-arkitekturer. Mer arbete att bygga, ofta högre kvalitet i domäner där relationer är centrala.

Specialiserade RAG-plattformar. LlamaIndex (nu moget), LangChains RAG-abstraktioner och Haystack. Ramverk på högre nivå för vanliga mönster.

Omrankning. Cohere Rerank, Voyage och egna korsenkodare. Efter den första hämtningen omrankas de främsta kandidaterna med en dyrare modell för bättre precision. Förbättrar vanligen hämtningskvaliteten 2–3 gånger.

Minne. För agenter och konversationer: strukturerade minneslager som Mem0, Letta (tidigare MemGPT) eller egna lösningar. Skilj mellan korttidsminne (den aktuella konversationen), medellångt minne (senaste ämnen) och långtidsminne (beständiga fakta om användaren eller kontot).

Arkitekturfrågan är var lagret ska finnas:

• I applikationen: LLM-anropet omsluts av hämtningslogik som teamet har skrivit.
• I MCP-lagret: hämtningen exponeras som verktyg.
• Som tjänst: en särskild hämtningstjänst som applikationerna anropar.

I monolitiska system för en enda produkt fungerar det bra att ha lagret i applikationen. I organisationer med flera produkter lönar det sig att behandla hämtning som en tjänst med enhetlig kvalitet och policy.

Lager 5: prompt- och kontextutveckling

År 2026 är promptteknik i stort sett synonymt med kontextutveckling – att styra vad som läggs i kontextfönstret för varje anrop.

Komponenterna:

Prompter. Ofta mallar med variabler. Lagrade i versionskontroll. Testade med utvärderingssviter. Behandlade som kod.

Prompthantering. Verktyg som Promptfoo, Langfuse, PromptLayer eller interna system. Versionshantering, A/B-testning och återställning. (Helicone och liknande LLM-proxyer hör hemma i observerbarhetslagret nedan, inte här – kategorierna är lätta att blanda ihop.)

Kontextstrategi. Beslut om vad varje anrop ska innehålla:

• Systemprompt (stabil, definierar beteende).
• Hämtad kunskap (dynamisk, från RAG).
• Konversationshistorik (hanterad, ofta sammanfattad när den blir lång).
• Few-shot-exempel (väljs dynamiskt utifrån frågan).
• Verktygsbeskrivningar (filtrerade till enbart relevanta verktyg).
• Användarens aktuella fråga.

Kontextkomprimering. När kontexten blir lång försämras modellen. Strategier: sammanfatta äldre turer, extrahera nyckelfakta till ett strukturerat minne och rensa irrelevant innehåll. Ett aktivt forskningsområde.

Användning av lång kontext. Fönster på en miljon token är standard i dagens toppmodeller (Claude, GPT-5.5, Gemini). De fungerar, men kontextförfall är verkligt – kvaliteten försämras med långa indata även när modellen tekniskt stöder dem. Använd lång kontext försiktigt. Häll inte in allt bara för att det går.

Lager 6: orkestrering

Hur samordnar du LLM-arbetsflöden och agenter i flera steg?

Direkt-API. Skriv helt enkelt loopen själv i Python eller TypeScript. Bäst för enkla fall och för att förstå vad som faktiskt händer.

LangChain/LangGraph. Brett använt. LangGraph, en tillståndsmaskin för agenter, har mognat avsevärt. Tunga abstraktioner och en inlärningskurva, men kraftfullt.

CrewAI. Ramverk för flera agenter med fokus på rollbaserade agenter. Enklare att komma igång med än LangGraph, mindre flexibelt.

LlamaIndex-agenter. Särskilt starka för RAG-tunga arbetsflöden.

OpenAI Agents SDK. Enklare, mer styrt och optimerat för OpenAI-modeller.

Anthropic Claude SDK. Liknande, optimerat för Claude.

Eget. För mogna team som levererar produktionsagenter är egen orkestrering vanligt. Ramverk medför kostnader – abstraktionsskatt, komplex felsökning och frekventa versionsförändringar – som kan överstiga nyttan.

Ett mönster 2026 är att ta fram prototypen i ett ramverk och skriva om den till egen kod för produktion. Ramverken hjälper dig upptäcka mönstren. När du väl känner dem är direkt kod enklare och mer tillförlitlig.

Lager 7: observerbarhet

Du kan inte leverera seriösa LLM-applikationer utan observerbarhet. Varje produktionssystem behöver:

Spårning. Varje LLM-anrop registreras: tidsstämpel, modell, indata, utdata, latens, kostnad och utfall. Träd för flerstegsspår.

Kostnadsuppföljning. Per anrop, funktion och användare. Kostnaderna är stora och obegränsade. Utan uppföljning upptäcker du dem först i slutet av månaden.

Kvalitetsövervakning. Automatiska kvalitetskontroller på ett urval av produktionstrafiken. Larm vid kvalitetsfall.

Insamling av användaråterkoppling. Tummen upp/ned, uttrycklig återkoppling och implicita signaler som andel omförsök och avhopp.

Felsökning. När något går sönder måste du kunna se hela anropskedjan. En misslyckad agentkörning kan ha många felpunkter.

Verktyg: LangSmith, Helicone, Arize, Phoenix, Braintrust, Weights & Biases, Datadog LLM Observability. De har olika styrkor. Välj ett tidigt och håll fast vid det.

För små team ger till och med en enkel Postgres-tabell med en rad per LLM-anrop 80 % av vad som behövs. Byt till ett verktyg när skalan eller funktionsbehoven motiverar det.

Lager 8: utvärderingar

Det enskilt viktigaste lagret för seriöst produktionsarbete.

Offlineutvärderingar. En definierad datamängd, förväntade utdata och poängsättning. Körs före driftsättning av ändringar. Fångar regressioner. (Vi behandlade detta i detalj på mellannivån.)

Onlineutvärderingar. Ett urval av produktionstrafiken poängsätts automatiskt (LLM-as-judge) eller via användarsignaler. Fångar drift.

Utvärderingar före driftsättning. Innan en prompt- eller modelländring går i produktion körs och granskas utvärderingssviten. Den blir en del av CI.

Utvärderingstaxonomi. Olika utvärderingar för olika frågor:

• Beteende: gör systemet det vi förväntar oss?
• Säkerhet: avvisar det sådant vi vill ska avvisas?
• Kvalitet: hur bra är resultatet?
• Robusthet: hur hanterar det antagonistiska indata?
• Kostnad/latens: håller vi budgeten?

Verktyg: Promptfoo, Braintrust, LangSmith och egna sviter. Alla fyller en funktion. Promptfoo är enklast att börja med.

Lager 9: applikationslagret

Här finns din specifika produkt. Besluten här:

Agent kontra arbetsflöde. Agenter (en LLM i en loop med verktyg) är kraftfulla men svårare att göra tillförlitliga. Arbetsflöden (en fast sekvens av LLM-anrop) är enklare och ofta tillräckliga. Välj arbetsflöden som standard. Använd agenter när de verkligen behövs.

Synkront kontra asynkront. Användarnära i realtid? Batchjobb i bakgrunden? Strömmat? Påverkar modellval, infrastrukturval och UX-design.

En kund (tenant) kontra flera. Krav på kundspecifik dataisolering driver viktiga arkitekturbeslut.

Lokalt kontra moln. Regelefterlevnad, säkerhet eller kostnad kan driva dig till lokal drift. Den operativa komplexiteten är mycket högre.

Specialfall. Hallucinationer, promptinjektioner och missbruk. Produktionssystem behöver skyddsräcken. Leverera inte utan dem.

Avvägningar som spelar roll

Några avvägningar som bör göras uttryckliga:

Kvalitet kontra kostnad kontra latens

Den grundläggande triangeln. Du kan vanligen optimera två. Den tredje blir sämre.

• Hög kvalitet + låg latens = dyrt.
• Låg kostnad + låg latens = lägre kvalitet.
• Hög kvalitet + låg kostnad = hög latens (batchbearbetning eller resonemangsmodeller).

Välj prioriteringar per uppgift. Försök inte optimera alla tre. Den vägen leder till medelmåttighet i allt.

Bygga kontra köpa

För varje lager kan du bygga eller köpa.

• Bygga: mer kontroll, mer underhåll, högre kostnad i ingenjörstid och särskiljande förmågor.
• Köpa: snabbare start, mindre kontroll, löpande leverantörsrisk och generiska förmågor som läggs ut externt.

En bra tumregel är att köpa standardlagren (vektorlagring, grundläggande observerbarhet) och bygga de särskiljande lagren (din specifika orkestrering, dina prompter och dina utvärderingar). Det omvända – att köpa det som särskiljer dig och bygga standardinfrastrukturen – är ett vanligt misstag.

Öppen kontra sluten källkod

Verkligheten 2026 är att modeller med öppen källkod konkurrerar för många uppgifter. För vissa är de bättre – snabbare och billigare. För andra, som resonemang över långa förlopp, leder slutna toppmodeller fortfarande.

Beslutsfaktorerna:

• Kvalitetskrav. För den absoluta frontlinjen inom en uppgift vinner slutna modeller fortfarande.
• Kostnad i stor skala. Öppen källkod i egen drift blir billig vid hög volym.
• Integritet/regelefterlevnad. Egen drift i den egna infrastrukturen krävs ofta för känsliga data.
• Anpassning. Finjustering och egen träning kräver öppen källkod.
• Operativ kapacitet. Slutna API:er är operativt triviala. Egen drift innebär mycket arbete.

De flesta produktionssystem 2026 är hybrider – slutna modeller för vissa anrop och öppna för andra, utifrån kalkylen för varje anrop.

Latens kontra resonemangsdjup

Resonemangsnivåer (GPT-5.5 thinking, Claude med adaptivt tänkande) byter latens mot kvalitet i svåra problem. Ibland är det värt det. Ibland kan användaren inte vänta 30 sekunder.

Ett mönster är att dirigera enkla frågor till snabba modeller och svåra frågor till resonemangsmodeller. Använd en dirigent – en liten modell eller en heuristik – för beslutet.

Lång kontext kontra RAG

Du kan fylla modellen med kontext via ett fönster på en miljon token eller hämta relevanta segment med RAG.

• Lång kontext: enklare, ingen hämtningsinfrastruktur, men dyrt per anrop och kontextförfall är verkligt.
• RAG: billigare per anrop, mer konfiguration, och hämtningskvaliteten är ett eget ingenjörsproblem.

Det mogna svaret 2026 är vanligen RAG i produktion. Lång kontext passar prototyper, särskilda engångsuppgifter eller fall där hämtningen håller så låg kvalitet att den förstör resultatet.

Agenter kontra arbetsflöden

Som ovan. Välj arbetsflöden som standard. Använd agenter när flexibiliteten verkligen behövs. Många ”agentsystem” vi ser borde vara arbetsflöden.

En referensarkitektur för 2026

För att göra allt konkret ser ett typiskt produktionssystem för en medelstor SaaS-produkt med AI-funktioner ut så här:

Användare → Applikation (React/Next.js)
    ↓
API-gateway/autentisering
    ↓
LLM-tjänst (ditt omslag)
    ↓
  Dirigent (liten modell eller heuristik)
    ├→ Enkla uppgifter: modell i mellanskiktet (Claude Haiku 4.5-klassen)
    ├→ Standarduppgifter: Claude Sonnet 5 eller GPT-5.5
    ├→ Svåra uppgifter: Claude Opus 4.8 eller en resonemangsnivå
    └→ Specialfall: specialister på bild/röst/inbäddning
    ↓
Verktygslager (MCP-servrar + direktintegrationer)
    ↓
Hämtningslager (Pinecone + hybrid + omrankare)
    ↓
Observerbarhet (Helicone eller LangSmith)
    ↓
Utvärderingssvit (Promptfoo, körs i CI)

Kostnad per aktiv användare och månad: vanligen 1–10 euro beroende på användningsintensitet. Utvecklingsinsats: 6–12 veckor för ett erfaret team. Driftskostnad: låg till måttlig beroende på trafik.

Vanliga fel

Felmönster som återkommer i LLM-stackar i produktion:

Mönster 1: En modell för allt. Skenande kostnader och kvalitetsproblem. Åtgärd: dirigering.

Mönster 2: Ingen observerbarhet. Det går varken att felsöka, mäta eller förbättra. Åtgärd: instrumentera tidigt.

Mönster 3: Inga utvärderingar. Kvaliteten driver utan att någon märker det. Åtgärd: utvärdera från dag ett.

Mönster 4: Ramverksinlåsning. Felsökning av LangChain eller CrewAI blir ett heltidsjobb. Åtgärd: använd inte ramverk om de inte sparar mer än de kostar. Skriv om till direkt kod när mönstren är tydliga.

Mönster 5: Bygga infrastruktur som borde köpas. En egen vektordatabas? Troligen bortkastad tid. Egen observerbarhet? Troligen bortkastad tid. Köp standardlagren.

Mönster 6: Köpa infrastruktur som borde byggas. Lägga ut prompterna på en tredje part. Lägga ut utvärderingarna. De är din konkurrensvallgrav. Äg dem.

Mönster 7: Ignorera promptinjektion. Ett produktionssystem utan indatasanering för användarinnehåll. Stor risk. Begränsa den tidigt.

Mönster 8: Lita på agenter i flöden med höga insatser. En LangGraph-agent som godkänner återbetalningar utan mänsklig granskning. Det kommer förr eller senare att gå fel. Lägg in en människa i loopen för åtgärder med konsekvenser.

Mönster 9: Optimera fel sak. Optimera inferenskostnaden när den totala kostnaden domineras av ingenjörstid. Eller optimera latensen när användarna inte märker den. Mät det som faktiskt spelar roll.

Mönster 10: Ingen plan för flera leverantörer. När – inte om – din huvudleverantör får ett avbrott ligger du nere. Konfigurera en reserv.

Tre tidsatta antaganden (återbesök i mitten av 2027)

Förutsägelser är billiga. Tidsatta, falsifierbara förutsägelser är det inte. Här är tre som vi är beredda att offentligt ha fel om:

1. EU-driftad inferens når praktisk prisparitet för modeller i mellanskiktet senast i mitten av 2027. EU-suverän kapacitet tas snabbt i drift och pristillägget jämfört med slutpunkter i USA-regioner har minskat. Om paritet nås ändras vår standardrekommendation för GDPR-känsliga arbetslaster från ”hybrid med maskering” till ”EU-drift som standard”. Tilltro: måttlig.

2. Ramverkslagret fortsätter att konsolideras, medan protokollagret fortsätter att vinna. Under de senaste 18 månaderna har Microsoft slagit samman sina två agentramverk och OpenAI har fört tillbaka sin fristående webbläsaragent till ChatGPT, samtidigt som MCP har gått från lansering till en leverantörsöverskridande standard. Vi lägger integrationsarbetet i protokoll (MCP, strukturerade utdata) och håller orkestreringsramverket utbytbart. Tilltro: hög.

3. Dirigering med små modeller går från optimering till standardarkitektur. Om toppmodellernas priser består samtidigt som de små nivåerna fortsätter förbättras kommer ”toppmodell för allt” att låta som ”fysisk server för allt” låter för en molningenjör. Tilltro: hög för kostnadskänsliga små och medelstora företag.

Det vi medvetet inte förutspår är modellrankningar. Varje specifik rangordning här skulle vara inaktuell före sidans nästa granskningsdatum.

Få arkitekturen rätt

LLM-stacken 2026 är verklig, skiktad och valen spelar roll. Teamen som vinner:

• Förstår hela stacken, inte bara delarna de själva arbetar med.
• Gör uttryckliga avvägningar mellan kvalitet, kostnad och latens per anrop.
• Bygger det som särskiljer dem och köper resten.
• Instrumenterar från dag ett med observerbarhet och utvärderingar.
• Förblir lättrörliga med modellportabilitet och flera leverantörer.

Teamen som förlorar valde en leverantör, hårdkodade dess API, instrumenterade aldrig, mätte aldrig och sitter nu med ett dyrt, skört system som är omöjligt att förbättra.

Få arkitekturen rätt. Allt annat blir enklare.