Monitera AI-agenter med Langfuse. Tracing, kostnad och token-budgets.
En traditionell applikation som krånglar lämnar spår: en stack trace, en felkod, en logg. En AI-agent som krånglar säger oftast ingenting alls - den ger bara ett sämre svar, fattar ett konstigt beslut eller bränner tre gånger så många tokens som väntat. Utan observability är en agent i produktion en svart låda du betalar för utan att veta varför. Det här är det första jag sätter upp när en agent ska från demo till drift, för utan det famlar du i mörkret första gången något beter sig oväntat - och något kommer alltid att bete sig oväntat.
Jag bygger observerbara AI-system inom AI Engineering, och Langfuse är verktyget jag oftast når efter när en agent ska bli möjlig att förvalta.
Tracing: gör resonemanget synligt
Grunden är att fånga hela kedjan av vad agenten gör i en trace. Ett enda användaranrop kan internt utlösa flera LLM-anrop, verktygsanrop, retrieval-steg och beslut. En trace visar dem som en hierarki: vad gick in, vad kom ut, hur lång tid tog varje steg och var det gick fel. När en agent ger ett oväntat svar är det här du ser om felet låg i en dålig sökträff, en feltolkad prompt eller ett verktyg som returnerade skräp. Utan det gissar du, och att gissa kring ett icke-deterministiskt system är en förlorad strid.
Kostnad: tokens är pengar, gör dem synliga
AI-kostnader har en obehaglig vana att smyga sig på. En agent som loopar en gång för mycket, en kontext som vuxit obemärkt, eller en dyr modell använd där en billig räckt - allt syns på fakturan men ingenstans annars förrän du mäter. Langfuse kopplar kostnad till varje trace, så du ser inte bara vad totalen blev utan vilka flöden, användare eller funktioner som driver den. Det förvandlar kostnad från en månadschock till något du kan styra, och det avslöjar nästan alltid att en handfull flöden står för merparten.
- Kostnad per flöde: vilka användningsfall är dyra, och motsvaras kostnaden av värde?
- Token-budgetar: sätt tak per anrop eller session och larma när de överskrids innan fakturan gör det.
- Modellfördelning: ser du att en dyr modell används där en billig räcker har du hittat en enkel besparing.
Kvalitet: utvärdera, inte bara övervaka
Observability handlar inte bara om driftstatus utan om svarens kvalitet över tid. Langfuse låter dig samla in betyg - från användare, från regler eller från en modell som bedömer andra svar - och knyta dem till traces. Då kan du se om en promptändring faktiskt förbättrade utfallet eller bara kändes bättre, och fånga regressioner innan användarna gör det. Det här binder ihop observability med evals: produktionsdata blir ditt bästa underlag för nästa förbättring, eftersom det är de verkliga frågorna dina användare faktiskt ställer.
Self-hostad eller molntjänst
Langfuse går att köra både som molntjänst och self-hostad. För bolag med känslig data är self-hosting attraktivt eftersom prompterna och svaren - som ofta innehåller affärsdata - då stannar i er miljö. Avvägningen är den vanliga: ni får full kontroll men tar ansvar för drift. För många reglerade verksamheter är det en lätt avvägning åt self-hosting; för andra väger den hanterade tjänstens enkelhet tyngre. Det viktiga är att fatta beslutet medvetet utifrån hur känsligt innehållet i era prompter faktiskt är.
Börja innan du tror att du behöver det
Det vanligaste misstaget är att skjuta upp observability tills något redan gått fel. Då sitter du utan historik just när du som mest behöver den, och felsöker bakåt utan spår att följa. Instrumentera agenten från första produktionsdagen - det är några rader kod nu, mot dagar av blind felsökning senare. En agent du inte kan se är en agent du inte kan lita på, och en du inte kan lita på borde egentligen inte vara i produktion alls.
Relaterat
- MCP-servrar i produktion: Bygg din första Model Context Protocol-integration
- LangGraph vs n8n vs Temporal: När välja vad för agentiska workflows
- RAG-arkitektur 2026: Från naiv chunking till hybrid retrieval med rerankers
Ett exempel på en observerbar agent i drift finns i kundcase.
Vill du ta det vidare?
Jag hjälper svenska bolag att göra sina AI-agenter observerbara - med tracing, kostnadsstyrning och kvalitetsmätning från start. Boka ett förutsättningslöst samtal så går vi igenom ert upplägg.
“En AI-agent som krånglar säger oftast ingenting - den ger bara ett sämre svar eller bränner tre gånger så många tokens. En agent du inte kan se är en agent du inte kan lita på.”
- Simon Axelsson
Vanliga frågor
- Vad är skillnaden mellan loggning och tracing för agenter?
- Vanlig loggning ger lösryckta meddelanden. En trace binder ihop hela kedjan för ett anrop - varje LLM-anrop, verktygsanrop och retrieval-steg i en hierarki med in- och utdata. Det är skillnaden mellan att se symptom och att se var i flödet felet uppstod.
- Kan vi köra Langfuse utan att skicka vår data till en extern tjänst?
- Ja. Langfuse kan self-hostas, vilket innebär att prompter och svar - som ofta innehåller affärsdata - stannar i er miljö. Avvägningen är att ni får full kontroll men tar ansvar för drift.
- Hur hjälper observability oss att sänka AI-kostnaden?
- Genom att koppla kostnad till varje flöde ser du vilka användningsfall, användare eller funktioner som är dyra och om en dyr modell används där en billig räcker. Med token-budgetar och larm fångar du kostnadsökningar innan de når fakturan.
