Arkitektur¶
Sju delar, var och en utbytbar: fyra i en kedja från idé till drift, två som bär information genom hela kedjan, och granskningen som skär tvärs över allt.
Översikt¶
| Del | Vad den gör | Exempel på öppna komponenter |
|---|---|---|
| 1 Verkstad | Webbgränssnitt där medarbetaren beskriver, provar och förbättrar sin app i en isolerad sandlåda | Eget gränssnitt; CloudCLI UI; bolt.diy; Dyad (skrivbord) |
| 2 Agent | Planerar, skriver och testar koden på uppdrag av medarbetaren | OpenCode; Goose; Aider – eller ett proprietärt agentverktyg som ett av flera val |
| 3 Modell | Språkmodellen som agenten anropar | Europeiska LLM-API och självhostade öppna modeller (se katalogen, lager 6) |
| 4 Granskning | Automatiska kontroller och mänsklig granskning innan en app flyttas upp en nivå | Forgejo Actions med skannrar för kod, beroenden, hemligheter, SBOM, licenser och tillgänglighet |
| 5 Drift | Driftsätter och kör appen på infrastruktur organisationen råder över | OpenTofu, cloud-init/Ansible, Docker Compose; valfritt Coolify |
| 6 Informationslager | Organisationens begrepp, informationsmängder, grunddata och gränssnitt – maskinläsbart | SKOS och DCAT-AP-SE i Git, exponerat via en MCP-server |
| 7 Appkatalog | Vilka appar som finns, deras nivå och status, och vad som delas | Genereras ur appmanifesten |
Identiteten ligger under alltihop: inloggning i verkstaden, i apparna och i driften sker mot organisationens egen identitetstjänst, i linje med identitetsnavet.
Flödet¶
- Medarbetaren beskriver ett behov i verkstaden. Agenten söker först i appkatalogen om något liknande finns.
- Agenten bygger appen i en sandlåda med testdata. Den frågar informationslagret vilka begrepp, källor och gränssnitt som redan finns och bygger mot dem.
- Appen får ett appmanifest som beskriver syfte, ägare, nivå och vilken information den behandlar.
- Vid varje ändring körs granskningens automatiska kontroller. För högre nivåer tillkommer mänsklig granskning.
- När appen godkänns skapar driften den infrastruktur manifestet anger och driftsätter appen.
- Appen registreras i appkatalogen. Nya begrepp som godkänts registreras tillbaka i informationslagret.
Agent och modell är två lager¶
Det är lätt att tala om »Claude« eller »ChatGPT« som om verktyget och modellen vore samma sak. För rådigheten är skillnaden avgörande:
- Agentlagret planerar, läser och skriver filer, kör kommandon och testar. Vissa agentverktyg är byggda för en enda leverantörs modeller och är inte öppen källkod. Öppna agentverktyg som OpenCode, Goose och Aider kan kopplas till många olika modeller (licenser och modellstöd ej oberoende verifierade i detta utkast).
- Modellagret är språkmodellen som anropas via ett API: en amerikansk leverantör, en europeisk leverantör eller en öppen modell som körs på egen eller svensk GPU.
Om plattformen byggs direkt på ett leverantörsbundet agentverktyg låses båda lagren samtidigt. Med ett öppet agentlager kan modellen väljas per uppgift eller per informationsklass – till exempel en stark kommersiell modell i verkstaden med testdata och en självhostad modell när känsligare information är inblandad.
Kvaliteten beror i dag på kombinationen av agent och modell. Ett öppet agentverktyg med en svagare modell ger märkbart sämre resultat än de bästa kommersiella kombinationerna. Det är en avvägning som ska göras medvetet och mätas, se Öppna frågor.
Verkstaden¶
Verkstaden är det enda lager de flesta användare ser, och det som avgör om konceptet används. Ett terminalgränssnitt upplevs som främmande av många; verkstaden behöver vara ett polerat webbgränssnitt i nivå med de kommersiella verktygen.
Det finns öppna webbgränssnitt ovanpå agentverktyg, till exempel CloudCLI UI och claude-ui-oss, men de är byggda för utvecklare. Öppna Lovable-alternativ som Dyad och bolt.diy ligger närmare målgruppen men saknar granskning och driftkedja, och Dyad är en skrivbordsapp. Den troligaste vägen är ett eget, enkelt gränssnitt ovanpå ett öppet agentlager, med en isolerad container per projekt.
Tre krav gäller oavsett gränssnitt:
- Isolering. Agenten kör kod och kommandon. Varje projekt behöver en egen sandlåda så att en användares instruktioner inte kan nå en annans projekt.
- Testdata. I verkstaden används bara test- eller syntetisk data. Det är det som gör låga trösklar möjliga.
- En godkänd stack. Agenten styrs mot ett ramverk, en databas och organisationens inloggning. Fritt teknikval gör apparna oförvaltningsbara.
Källor¶
- CloudCLI UI – README, GitHub, ZenTheScripter/Claude-Code-GUI (hämtad 26 september 2026): öppen källkod, självhostbar, stöd för flera agentverktyg, experimentell sandlådeisolering.
- claude-ui-oss – README, GitHub, anitigravitylab-oss (hämtad 26 september 2026): webbgränssnitt som använder agentverktygets strömmande JSON-gränssnitt.
- Dyad – README, GitHub, dyad-sh/dyad (hämtad 26 september 2026): lokal skrivbordsapp, Apache 2.0 utanför katalogen src/pro, egna API-nycklar.
- Dyad: »Free AI App Builders Compared (2026)«, 29 januari 2026 (leverantörsuppgift): bolt.diy som självhostad variant.
- Rådig 2026.09, kapitel 4 och 5 samt katalogen för lager 6, faktaläge 9 september 2026.