← Alla artiklar

Integration i AI-eran

I AI-eran gör agenter integrationsarbetet medan en plattform med fasta regler ser till att flödena går att lita på. Så fungerar det, lager för lager, från behov till förvaltning.

Jakob Thun · · 7 min läsning

De första integrationsplattformarna byggdes för specialister som ritade flöden i en egen konsol. Nästa generation byggdes för utvecklare som ville dra lådor och pilar i en webbläsare. Den som växer fram nu används av agenter, och det fungerar bara om plattformen redan är byggd för att saker ska bli rätt. Mönstren är desamma som för tjugo år sedan: ta emot, bearbeta, leverera. Det som är nytt är gränssnittet, som är Git, ett kommandoradsverktyg och ett API som en språkmodell kan använda i stället för en rityta.

Varför passar de gamla plattformarna inte agenter?

En vanlig integrationsplattform är byggd för en människa som loggar in, öppnar ett flöde, klickar i en mappning och trycker på Deploy. Sanningen om vad som körs finns i plattformens egen databas.

Försöker du låta en agent arbeta där märker du snabbt att den inte ser något. Flödet är en bild och namnen följer ingen regel. Vem som får läsa en kö är inställt i en dialogruta. Att ingenting ska driftsättas utan godkännande är rätt. Men godkännandet borde vara en granskad ändring i Git och inte ett klick i ett gränssnitt.

Vad har förändrats?

Två saker hände ungefär samtidigt.

  1. Språkmodellerna blev tillräckligt bra på kod. Med rätt mönster, namnstandard och dokumentation skriver en modell en vanlig integration som går att granska och godkänna.
  2. Agenter fick ordnade sätt att använda verktyg. Med MCP och kommandoradsverktyg kan "lägg till ett flöde" vara ett arbetsflöde i stället för en checklista.

Den tredje förutsättningen hände inte av sig själv. Hela leveranskedjan måste vara kod, och det är ett val man gör när man bygger plattformen.

Varför byggde vi allt som kod?

Inte för agenternas skull. Klok byggdes så från början för människor som bryr sig om att saker blir rätt.

När allt är kod kan verktygen göra kontrollen åt dig, och de verktygen blev bättre för varje år långt innan språkmodellerna kom:

  • Typade gränssnitt. En datamodell är ett schema med genererade klasser. Ett fält som inte finns är ett kompileringsfel, inte en överraskning i produktion.
  • Verifierbara byggen. Samma bygge och samma kontroller körs varje gång, och resultatet går att läsa i efterhand.
  • Namnstandarder som är implementerade. Standarden står inte i ett dokument som någon ska komma ihåg. Den sitter i verktygen.

Allt det gjorde arbetet enklare för en människa. Det visade sig vara precis vad en agent behöver. En språkmodell som får ett kompileringsfel, ett rött bygge eller ett avvisat namn får ett tydligt svar på vad som var fel och kan rätta det själv. I en plattform där reglerna bara finns i folks huvuden får den inget svar alls.

Vi byggde alltså inte Klok för agenter. Vi byggde det för att det skulle bli rätt, och det passar agenterna som handen i handsken.

Vem gör vad?

Rollerna byter plats. Förut byggde utvecklaren flödet, plattformen körde det och arkitekten granskade i efterhand. Nu designar utvecklaren och agenten gör rutinarbetet. Bygget kontrollerar reglerna: namn, topics, rättigheter och datamodeller. En människa godkänner, och den som granskar läser historiken i Git.

Det går bara att bygga där integrationen är kod i Git från första raden. Det är det vi menar med att Git är sanningen. Portalen klok.dev är ett bekvämt lager ovanpå, och allt den gör går också att göra för hand i Git.

Från behov till förvaltning, lager för lager

Så här ser det ut när ett behov blir ett flöde i drift. Varje lager är kod eller text i Git, och varje lager vilar på det under. Exemplet är påhittat: ett lager som ska avisera ekonomisystemet.

  1. 01 · Behov

    Det börjar med ett behov

    Lagret ska avisera ekonomisystemet när en leverans är gjord. Behovet skrivs som en ändringsbegäran, ett ärende som varje senare ändring pekar tillbaka på. Här bestäms vad som ska hända, inte hur.

  2. 02 · Lösning

    Behovet blir en lösning

    Lösningen får ett eget id, en ägare och ett dokument i Git som säger vilka system som är med och vilka steg flödet består av. NRD007 har sitt namn innan första raden kod är skriven, och verksamhet och IT pratar om samma sak.

  3. 03 · Datamodell

    Informationen får ett kontrakt

    Det som skickas beskrivs i ett schema som blir genererade klasser. Ett fält som inte finns är ett kompileringsfel, inte en överraskning i produktion, och en ändring som bryter kontraktet stoppas i bygget.

  4. 04 · Flöden

    Flödet byggs av namngivna steg

    Ett steg tar emot, ett levererar, och emellan dem ligger en topic. Systemen pratar med plattformen, aldrig direkt med varandra. Namnen följer standarden, så route-id:t är klassnamnet, konfigurationsprefixet och nyckeln i lösningsdokumentet.

    NRD007I1_DeliveryNoticeIngress   tar emot från lagersystemet
  publicerar på  persistent://nordvik/logistics/DeliveryNoticeV1
NRD007E1_DeliveryNoticeEgress    levererar till ekonomisystemet
  prenumeration  NRD007E1_DeliveryNoticeEgress
  5. 05 · Granskning

    Bygget verifierar, en människa godkänner

    Kod, tester och det uppdaterade lösningsdokumentet kommer i samma merge request. Bygget verifierar namn, topics och rättigheter, oavsett om förslaget kom från en människa eller en AI. Åtkomst till någon annans topic är också en rad i Git, och den godkänns av den som äger topicen. Agenten kan föreslå, men inte godkänna.

  6. 06 · Drift

    Det godkända går i drift

    När ändringen är godkänd byggs en ny version från main och rullas ut. Saknas en topic eller en rättighet stoppas driftsättningen med ett besked om vad som fattas. Samma bygge publicerar flödets dokumentation på docs.klok.dev, så den kan inte hamna efter koden.

  7. 07 · Förvaltning

    Varje händelse går att följa

    Varje transaktion får ett korrelations-id som följer med genom hela kedjan. Loggning, nya försök och felkö finns i varje flöde utan att någon behöver bygga in det. När något stoppar ligger meddelandet kvar i felkön, och Kloker, Kloks AI, förklarar på vanligt språk vad som hände och vad som behöver göras.

  8. Klok

    Sju lager, ett arbetssätt

    Nästa behov börjar om högst upp och har hela stapeln att stå på. Lösningsdokumentet, kontrakten, historiken och dokumentationen finns redan, för människor och för agenter.

Varför är reglerna grunden?

En agent som får hitta på namn, skapa topics i farten och ge sig själv behörighet bygger ett landskap ingen kan granska. En språkmodell får aldrig själv ändra det som körs. Den föreslår, och bygget och en människa avgör. Tre saker bär upp det:

  1. Git som enda sanning. Kod, datamodeller, topics och rättigheter ligger i Git, och varje ändring har en författare, en granskare och en tidpunkt.
  2. Fasta regler. Namnstandarden gäller flöden, topics och datamodeller. Man skriver smalt och läser brett: en tjänst publicerar bara i sitt eget område, och att läsa någon annans topic kräver ägarens godkännande. En topic skapas aldrig i farten, den beställs och läggs upp.
  3. Agenten föreslår. En agent läser dokumentation och kod, arbetar på en egen gren och lämnar en ändring för granskning. Den godkänner inte sitt eget arbete och hanterar inga hemligheter.

Den som granskar frågar inte längre vem som byggde något. Hen ser vem eller vad som föreslog ändringen och vem som godkände den.

Vad kan man bygga ovanpå?

Integrationslandskapet är organisationens rikaste karta. Den visar vilka system som finns, vilken information som rör sig mellan dem och vem som äger vad. Det som saknats är ett sätt för agenter och människor att läsa kartan. Med det på plats kan du fråga vilka flöden som använder en datamodell innan du ändrar den. Ett fel kan förklaras med loggarna som underlag. Och en ny kollega kan läsa sig in i en lösning utan att leta upp den som byggde den.

Vad börjar jag med?

Du behöver ingen AI-strategi för att komma igång. Du behöver tre saker:

  • en plattform där integrationen är kod i Git från grunden
  • en namnstandard som sitter i verktygen och inte i ett dokument
  • ett godkännandeflöde du litar på, med granskning, historik och rättelser som inte skriver över något

Sedan lägger du på AI en bit i taget. Börja med dokumentation och frågor om landskapet. Fortsätt med ändringar i befintliga flöden, och låt människor godkänna varje steg.

Vanliga frågor

Vad betyder integration i AI-eran konkret?

Att en AI-agent gör rutinarbetet, som ruttplaner, nya fält i en datamodell och dokumentation, medan plattformens regler ser till att resultatet följer standarden. Du godkänner det agenten föreslagit i stället för att bygga varje steg själv.

Tappar jag kontrollen om en AI bygger integrationerna?

Nej, så länge Git är källan till sanningen. Agenten föreslår, bygget kontrollerar reglerna och inget går i drift innan en människa godkänt. Historiken visar vad som ändrades, vem som föreslog det och vem som godkände.

Är Klok byggt för AI?

Nej, det är byggt för att integrationer ska bli rätt: typade gränssnitt, verifierbara byggen och namnstandarder som verktygen upprätthåller. Det är samma saker som gör att en agent kan arbeta där.

Vad krävs för att börja?

Ett konkret behov. Vi börjar i verksamheten och väljer ett flöde, som blir er första lösning och det första lagret i stapeln.

Nästa steg

Vill du se hur det ser ut hos er? Boka en integrationsgenomgång, eller läs hur arbetssättet ser ut i klok.dev.