Kortversion: När en AI-agent får använda filer, modeller och externa verktyg räcker det inte att mäta hur många förslag den gav. Team behöver kunna se vilken väg agenten tog: vilken modell den anropade, vilka verktyg som användes, var den fastnade och om en ändring accepterades. GitHub Copilot-appens nya OpenTelemetry-stöd visar ett praktiskt sätt att börja. Samla spår, mått och händelser centralt – men håll promptar, svar och verktygsargument avstängda tills ni har ett tydligt behov och en godkänd datamodell.
En agent kan ge ett bra svar av fel skäl. Den kan också misslyckas efter femton verktygsanrop utan att användaren förstår varför. Båda problemen blir dyrbara när AI flyttar från enskilda experiment till ett återkommande arbetssätt i produkt- och utvecklingsteam.
Svaret är inte hela förloppet
För vanlig analys räcker det ibland att kontrollera slutresultatet. För en agent är vägen ofta lika viktig. Den kan läsa filer, söka i en kunskapsbas, be om godkännande, köra ett test eller anropa ett externt system innan den svarar. Om ni bara sparar den sista texten missar ni informationen som behövs för att förbättra kvalitet, kostnad och säkerhet.
Det betyder inte att varje prompt eller kodrad ska skickas till ett analysverktyg. Målet är att kunna besvara några mycket konkreta frågor:
- Hur många sessioner slutförs utan mänsklig handpåläggning?
- Vilka verktyg används oftast, och vilka skapar återkommande fel?
- Är det en viss modell, ett visst repo eller en viss typ av uppgift som drar ovanligt mycket resurser?
- När användare avvisar agentens ändringar, vad i flödet bör undersökas?
- Kan teamet felsöka en incident utan att göra kunddata eller källkod till onödiga telemetridata?
Det är ett observability-problem, inte ett generellt ”vi behöver mer AI-analys”-problem.
Vad GitHub släppte
Den 22 september 2026 annonserade GitHub stöd för OpenTelemetry (OTel) i GitHub Copilot-appen genom centralt hanterade företagsinställningar. OTel är en etablerad öppen standard för att skicka telemetri till kompatibla observability-system.
GitHubs dokumentation delar upp materialet i tre typer:
- Spår (traces) kopplar ihop stegen i en agent-session, till exempel modell-anrop följt av filläsning och ett nytt modell-anrop.
- Mått (metrics) visar numeriska mönster över tid, exempelvis tokenanvändning.
- Händelser (events) registrerar enskilda utfall, som om en användare accepterade eller avvisade en agentändring.
Viktigt för en första implementation: promptar, svar och verktygsargument ingår inte som standard enligt GitHub. Innehållsfångst kan väljas till, men kan omfatta känslig kod, filinnehåll och användarfrågor. Det är en klok ordning. Börja med strukturen i förloppet, inte med allt innehåll i förloppet.
Börja med tre signaler, inte med ett jättedashboard
Ett bra första dashboard ska stödja beslut, inte imponera i en demo. Välj en signal från varje kategori.
1. En flödessignal
Mät hur många steg och verktygsanrop en uppgift normalt behöver. Om antalet plötsligt fördubblas kan det handla om ett sämre verktyg, ny kontext eller ett missförstånd i instruktionerna. Den signalen hjälper er att se var agenten snurrar innan kostnaden syns på fakturan.
2. En kvalitetssignal
Mät exempelvis andelen accepterade kodändringar, hur ofta ett förslag återställs eller hur ofta en agent-session avslutas med mänsklig eskalering. Det är inte ett bevis på affärsvärde, men det är bättre än att betrakta antal genererade rader som produktivitet.
3. En driftsignal
Mät fel per verktygstyp och om möjligt tid till återhämtning. En agent som saknar rättighet till ett system ska inte försöka tjugo gånger; den ska ge ett begripligt nästa steg. Telemetrin ska hjälpa teamet att skilja på ett saknat godkännande, ett trasigt verktyg och en svag modellinstruktion.
En datagräns före en instrumenteringsgräns
Det vanligaste misstaget är att börja med frågan ”vilket observability-verktyg ska vi köpa?”. Börja i stället med ”vilken information får lämna utvecklarnas datorer och produktionsmiljöer?”.
Gör en enkel klassning innan ni sätter en endpoint:
- Sessions-id, verktygstyp, tid och felkod: Tillåt om retention, åtkomst och syfte är definierade.
- Modellnamn, tokenmängd och latency: Tillåt för kapacitets- och kostnadsuppföljning.
- Filnamn eller repository-id: Tillåt bara om det behövs för felsökning och kan begränsas.
- Promptar, svar, kod och verktygsargument: Av som standard; kräver särskild riskbedömning och kort retention.
Raderna är inte juridisk rådgivning. De gör däremot det tekniska beslutet synligt: innehållstelemetri är en separat produkt- och integritetsfråga, inte en standardinställning som ska följa med när man aktiverar tracing.
Centralt konfigurerat, lokalt förstått
GitHubs lösning kan hanteras med företagsinställningar så att användarna inte behöver sätta upp varsin exporter. Det är en styrka när ett team behöver gemensam riktning. Men central konfiguration får inte bli central okunskap.
Berätta för utvecklarna vad som samlas in, vart det skickas, vilka roller som kan se det och varför. Ge dem ett sätt att flagga en felaktig eller känslig session. Den transparensen är inte bara en HR-fråga; den ger bättre data. Om människor tror att varje prompt granskas kommer de att anpassa beteende och då förlorar ni den signal ni försökte mäta.
En fyraveckors pilot
En försiktig pilot kan se ut så här:
- Vecka 1: Välj ett avgränsat team och två arbetsuppgifter, till exempel felsökning och kodgranskning. Skriv vilka frågor telemetrin ska besvara.
- Vecka 2: Konfigurera en säker OTLP-kompatibel mottagare med begränsad åtkomst. Slå på spår, mått och händelser, men inte innehållsfångst.
- Vecka 3: Gå igenom fem verkliga sessioner tillsammans med utvecklare. Kontrollera om verktyg, fel och acceptans går att förstå utan prompttext.
- Vecka 4: Besluta om ni ska behålla signalerna, ändra retention, lägga till en specifik innehållstyp under kort tid eller avstå helt.
Det ger ett beslut grundat i era faktiska flöden. Det är bättre än att köpa en omfattande AI-övervakning och sedan försöka hitta en anledning att samla in mer data.
När spårbarhet är särskilt viktigt
Prioritera det här före bredare autonomi när agenten får externa verktyg, arbetar i kundnära kod, gör dyra modell-anrop eller kör på uppgifter som är svåra att reproducera. Spårbarhet ersätter inte kodgranskning, testning eller tydliga behörigheter. Den visar däremot om dessa skydd fungerar i verkliga agentförlopp.
En bra tumregel är enkel: om ni inte kan förklara vilka verktyg agenten använt och vad den gjorde när den misslyckades, bör den inte få större handlingsutrymme nästa vecka.
Slutsats
AI-agenter ska inte följas upp som om de vore anställda, och telemetri ska inte bli en ursäkt för innehållsinsamling. Men team som vill använda agenter på allvar behöver se förloppet bakom resultatet. Börja med standardiserade spår, få mått och tydliga händelser. Håll innehåll avstängt. Lägg sedan till data först när ni kan beskriva exakt vilket beslut den gör möjligt.
GitHubs OTel-stöd är ett färskt exempel. Den mer hållbara lärdomen är att agentens observability bör byggas lika medvetet som övrig drift: med tydligt syfte, minsta möjliga data och en människa som kan tolka signalerna.