Den verkliga skillnaden mellan en chattbot och en agent
Den ena svarar på en fråga. Den andra bestämmer vad som ska göras, gör det, granskar sitt eget arbete och går vidare till nästa steg — utan att vänta på att du frågar. Den skillnaden är inte akademisk. Den ändrar vad som kan gå fel och vem som ska fånga det.
En chattbot tar det du skriver, genererar ett svar och stannar. En agent tar det du skriver, bestämmer vad som behöver hända, gör något åt det, kontrollerar om det fungerade och bestämmer vad som ska göras härnäst — på egen hand, ofta över många steg — innan en människa ser något av det. Det är hela skillnaden. Allt människor bråkar om när de bråkar om "AI-agenter" — risken, den tillsyn ett system behöver och det mesta av marknadsföringsförvirringen — följer av den enda skillnaden.
Vad en chattbot faktiskt gör
En chattbot är ett system med ett enda pass. Du ger den text, den genererar text tillbaka, och interaktionen slutar där. Även en chattbot med ett långt minne av samtalet gör fortfarande en sak per tur: läser allt som sagts hittills och förutspår nästa meddelande. Den frågar aldrig en databas för att kontrollera ett faktum, skickar aldrig något för din räkning och kommer aldrig tillbaka senare för att se om svaret höll. Om den har fel är skadan en mening som en människa läser — och som den personen, i vanlig ordning, kan fånga innan hen handlar på den.
Det mesta människor ber chattbotar om passar den här formen utan att någon märker det: sammanfatta det här dokumentet, skriv ett födelsedagsmeddelande, förklara vår återbetalningspolicy, skriv tre rubrikalternativ. Inget av detta kräver att systemet stämmer av något mot den verkliga världen eller tar en åtgärd utanför chattfönstret. Det gäller fortfarande när gränssnittet kallas "AI-assistent" eller "copilot" i stället för "chattbot" — etiketten på lådan ändrar inte vad som händer inuti den.
Vad en agent faktiskt gör
En agent kör en loop, inte ett enda pass: planera ett steg, agera genom att anropa ett verkligt verktyg — söka i en databas, skicka ett meddelande, redigera en fil, anropa ett API — se vad den åtgärden faktiskt returnerade och använda det resultatet för att bestämma nästa steg. Den upprepar detta tills uppgiften är klar, den kör fast eller den är byggd för att stämma av med en människa. Det viktiga är att ingen godkänner varje enskilt steg längs vägen. Systemet bestämmer själv vad det ska prova härnäst utifrån vad som faktiskt hände förra gången det agerade — och det kan ha fel vid var och en av de beslutspunkterna, inte bara i ett slutligt svar.
Den här loopen är inte ny eller exotisk. Forskare har beskrivit varianter av den — resonera om vad som ska göras, agera, observera resultatet, resonera igen — i åratal, och det är vad som faktiskt körs under produkter som kallar sig agenter, från programvara som lämnar in utläggsrapporter till kodverktyg som öppnar en terminal och kör sina egna kommandon. Det som gör något till en agent i stället för en mycket pratsam chattbot är att den agerar på världen, ser vad som hände och justerar — upprepade gånger, utan att en människa godkänner varje drag.
Samma begäran, körd på två sätt
Så här ser skillnaden ut när två system får instruktioner som låter likadana.
"Sammanfatta det här dokumentet."
- 1Läser texten du klistrade in.
- 2Genererar ett sammanfattande stycke.
"Hitta de tre öppna fakturorna som är mer än 30 dagar försenade, skriv ett påminnelsemejl för varje och lägg dem i min utkastmapp."
- 1Frågar faktureringssystemet och filtrerar fram fakturor som varit öppna i mer än 30 dagar.
- 2Kontrollerar att den faktiskt hittade tre, inte två eller fem — flaggar avvikelsen i stället för att gissa.
- 3Hämtar rätt belopp, förfallodatum och kontakt för varje faktura och skriver en påminnelse.
- 4Sparar varje utkast i den riktiga utkastmappen via mejlverktyget.
- 5Rapporterar vad den hittade och vad den skrev.
Fråga en chattbot den andra frågan och den ger dig ändå något som ser ut som ett svar: tre rimligt formulerade påminnelsemejl, genererade utifrån det du råkade klistra in i samtalet. Det den inte gör är att fråga ditt faktiska faktureringssystem, verifiera antalet eller lägga något i en riktig utkastmapp. Utdata kan se likadana ut. Vad systemet faktiskt gjorde är det inte.
Varför det här inte bara är en semantisk diskussion
Skillnaden spelar roll eftersom den ändrar vad som kan gå fel, och vem som fångar det. En chattbots värsta fall är ett felaktigt svar. Någon läser det och fångar, i vanlig ordning, felet eller väljer att inte handla på det — misstaget lämnar aldrig samtalet. En agents värsta fall är en felaktig handling som redan är utförd i den verkliga världen: påminnelsen som gick till fel kund med fel saldo, posten som uppdaterades med fel värde, återbetalningen som utfärdades två gånger — innan någon granskade något. Misstaget är inte en mening längre. Det är en händelse, och händelser gör sig inte ogjorda.
En chattbots värsta fall är ett felaktigt svar som någon läser. En agents värsta fall är en felaktig handling som redan är utförd — innan någon läste något alls.
Därför behöver en agent en annan sorts tillsyn än en chattbot. En chattbot behöver mest någon som kontrollerar svaren, när den personen hinner. En agent behöver att dess konstruktörer redan har bestämt, innan den någonsin körs, vilka handlingar den får utföra utan att fråga, vilka som kräver att en människa ser planen först och vad som händer när den kör fast. Räknar du ut det i efterhand får du veta vad agenten redan gjort den hårda vägen.
Du kan bara lita på det du kan se
Det är samma idé som ligger bakom FabricLoops begrepp Läsbarhet: du kan bara styra den åtkomst, och det beteende, som du faktiskt kan se. För en chattbot är det nästan automatiskt — hela utdata är ett meddelande som en människa läser, så handlingen och registreringen av handlingen är samma sak. För en agent är de inte det. Dess handlingar sker inne i andra system — ett CRM, en inkorg, en databas, en fil — och om inget loggar vad den rörde, ändrade eller skickade finns det inget sätt att granska det i efterhand, än mindre stoppa det i förväg. Läsbarhet är inte ett efterlevnadstillval som läggs ovanpå en agent. För en agent är det hela frågan, eftersom dess "svar" inte är en mening du kan korrekturläsa — det är en uppsättning handlingar du kanske aldrig får veta hände, om inte systemet byggdes för att visa dig dem.
Det är den praktiska kopplingen mellan de två idéerna: en agent tar på sig mer, och annan, risk än en chattbot, vilket är precis varför den behöver ett synligt spår av vad den gjorde och, i fallen med högre insats, en kontrollpunkt innan den agerar — det som FabricLoops begrepp Andel mänsklig insats behandlar som ett tal du utformar och mäter, inte som en eftertanke du skruvar fast när något redan har gått fel.
Marknaden prissätter det här bakvänt, hela tiden
När du har det verkliga testet är det uppenbart hur ofta etiketten ljuger i båda riktningarna. Gott om produkter som marknadsförs hårt som "AI-agenter" — ordet i huvudrubriken, i prisnivåerna — är under ytan en enda vältrimmad prompt: läs indata, generera utdata, klart. Inget självständigt verktygsanrop, ingen loop, inget beslut utan att en människa godkänner nästa klick. Samtidigt kör gott om programvara som aldrig använder ordet "agent" — ett automatiserat fakturaflöde, ett övervakningssystem som dirigerar om trafik på egen hand, ett driftsskript som startar om en havererad tjänst och kontrollerar om det löste problemet — tyst exakt den loop som beskrivs ovan. Ordet på etiketten säger inget tillförlitligt om vilken maskin du faktiskt använder.
1. Tar det mer än ett steg att göra saken? 2. Bestämmer det själv vad nästa steg är, eller bestämmer en människa varje steg, ett klick i taget? Om en människa väljer varje steg tittar du på en chattbot med extra knappar — kalla den vad marknadsföringssidan kallar den. Om systemet väljer sitt eget nästa steg över mer än ett steg tittar du på en agent, och den behöver styras som en sådan: synliga loggar, definierade gränser för vad den får göra utan att fråga, och ett verkligt svar på vem som granskar den och när.
FabricLoops egen AI-produkt, Loop Agent, kör den loopen — söker, skriver utkast, granskar sitt eget arbete över verktyg anslutna via MCP — men den är byggd för att visa sitt arbete och fråga innan stegen med högre insats, inte för att agera tyst och rapportera i efterhand. Varje MCP-anslutning den använder är avgränsad till en person, och i Enterprise syns det den gjorde i en revisionslogg i stället för att bara leva i dess eget minne av samtalet.
Det är samma logik som i Läsbarhet och Andel mänsklig insats — värt att läsa härnäst om det här är den första av de tre idéerna som fastnade.
Inget av det här kräver en teknisk bakgrund för att tillämpas. Nästa gång en leverantör, eller en kollega, kallar något en agent, fråga vad det faktiskt gjorde mellan din instruktion och resultatet — och hur många av de stegen det bestämde själv.
