Hva gjorde KI-agenten min? Fire spørsmål du bør kunne besvare med bevis

For å vite hva KI-agenten din gjorde, bør du ikke begynne med sammendraget dens. Sjekk fire ting: hvilken tilkobling som gjorde arbeidet, hva som endret seg (vist med noe du kan åpne selv), hva som ble latt være, og hva som ble bestemt og hvorfor. Hviler noen av de fire bare på agentens ord, har du en fortelling, ikke en registrering.

Vi lager Weft. Fakta om andre produkter er hentet fra deres offisielle sider, kontrollert 27. oktober 2026.

Hvorfor er ikke en kommentar som sier «ferdig», nok?

En kommentar er agenten som beskriver sitt eget arbeid. Den kan godt være riktig, men kommentaren kan ikke vise det, fordi forfatteren er nettopp den du prøver å sjekke. Å vite at en agent har vært borti en oppgave, svarer på hvem. Det svarer ikke på om arbeidet er det du tror det er.

Hypertasks artikkel om attribusjon av KI-arbeid har et godt poeng: agentarbeid bør havne på den samme tavla som menneskelig arbeid, ikke i en terminallogg ingen leser. Hypertask gir også agenter egen identitet som tjenestekontoer, så det de skriver, tilskrives agenten i stedet for deg, og de har bevis og leieavtaler på oppgaver, selv om dokumentasjonen deres sier at dette bare er REST-endepunkter, ikke MCP-verktøy, med vilje. Der vi er uenige, er hva registreringen bør inneholde. En kommentartråd med agentens utdata er en logg over hva agenten sa. Vi vil at registreringen skal inneholde bevis.

Det finnes ingen undersøkelsestall i denne guiden. Du kan teste de fire spørsmålene på din egen tavle i ettermiddag, og det forteller deg mer enn et bransjesnitt.

Hva er de fire spørsmålene?

Velg en hvilken som helst oppgave en agent ble ferdig med forrige uke. Du bør kunne svare på hvert av disse på under ett minutt uten å spørre agenten eller åpne chatten dens:

1. Hvem gjorde det? Hvilken klient, på hvilken tilkobling, som tok og fullførte oppgaven.
2. Hva endret seg? Resultatet, pluss artefakter du kan sjekke uten å stole på agenten: en commit-hash, en URL, en fil, en meldings-id.
3. Hva ble ikke gjort? Delene den hoppet over, og det den var usikker på.
4. Hva ble bestemt, og hvorfor? Ethvert valg som ble tatt underveis, med alternativene som ble veid, og hver gang du sendte arbeidet tilbake.

Hvordan vet jeg hvilken agent som gjorde det?

Weft kobler seg til KI-klienter over Model Context Protocol på ett endepunkt, https://letsweft.com/api/mcp. Hver OAuth-klient og hvert personlige tilgangstoken er sin egen aktør. En oppgave registrerer hvilken klient som opprettet den, og tavla viser navnet klienten registrerte seg med ved innlogging, pluss et ikon. Hver hendelse i oppgavens journal lagrer om den kom fra en person eller over MCP, og hvilken klient som sendte den.

Den fullstendige journalen (get_task_history i full-modus) viser den rå klient-id-en for hver hendelse: en OAuth-klient-id, eller mcp-token etterfulgt av tokenets id. Det er ikke et vennlig navn, men det er nøyaktig, og det skiller to tilkoblinger selv når de kommer fra samme produkt.

Eierskapet under arbeidet er også eksplisitt. En agent kaller start_task, som tar oppgaven med en leieavtale på 20 minutter og flytter den til Doing. report_progress fornyer leieavtalen. En annen agent som prøver den samme oppgaven, får already_claimed, og en leieavtale som løper ut, frigjør oppgaven for noen andre. Guiden til oppgavesløyfen går gjennom dette steg for steg, og å kjøre flere agenter på én tavle dekker tilfellet med flere klienter.

Én praktisk regel: gi hvert verktøy sin egen tilkobling. Deler to klienter ett tilgangstoken, ser tavla én aktør, og spørsmålet om hvem mister svaret sitt.

Hva endret seg, og kan jeg sjekke det uten å spørre agenten?

Når en agent er ferdig, kaller den complete_task. Bare oppgavens id er påkrevd; alt annet er valgfritt, og kallet feiler aldri på grunn av manglende bevis. Det er med vilje: det er verre å miste ferdig arbeid enn å registrere det uverifisert. Dette kan en kvittering inneholde:

• outcome: opptil 1 000 tegn om hva som ble gjort og hvor resultatet ligger.
• artifacts: opptil 20 oppføringer, hver med en type (url, file, message, commit og så videre), en plassering og eventuelt en sha256-sjekksum.
• claims: det agenten påstår at den gjorde, lagret som påstander og ikke som verifiserte fakta.
• notDone og unknowns: se neste avsnitt.
• nextStep: det agenten ville gjort neste gang hvis du godtar.

complete_task({
  "id": "<task id>",
  "runId": "<from start_task>",
  "leaseToken": "<from start_task>",
  "outcome": "Rate limiting added to /login; PR open, not merged.",
  "artifacts": [
    { "kind": "commit", "uri": "<repo>/commit/<hash>" },
    { "kind": "url", "uri": "<repo>/pull/<number>" }
  ],
  "notDone": ["Did not change the signup endpoint"],
  "unknowns": ["Limit of 5 per minute is a guess; no traffic data"],
  "nextStep": "Merge the PR to main"
})

Resultatlinjen er fortsatt fortelling. Artefaktene er den delen du kan sjekke. En commit-hash finnes enten i repoet ditt eller ikke. En URL lastes eller ikke. En fils sha256 stemmer eller ikke. Har en kvittering et resultat og ingen artefakter, behandle det som arbeid rapportert av agenten, for det er det det er. På nettet viser kort i Done om en oppgave er «Verifisert» eller «Ifølge agenten».

Hva gjorde ikke agenten?

Dette er spørsmålet de fleste registreringer hopper over, og det som biter to uker senere. complete_task har to lister for det, hver med opptil 20 oppføringer på 500 tegn: notDone for det agenten med vilje lot være, og unknowns for det den er usikker på. Verktøyets egen beskrivelse ber agentene si høyt hva de ikke gjorde. Det er det som skiller et resultat du kan stole på, fra et du må utlede på nytt.

Les disse listene først. «Kjørte ikke testene mot staging-databasen» endrer hva du gjør videre. En kvittering uten notDone-oppføringer på en stor oppgave er i seg selv verdt et spørsmål.

Hva ble bestemt, og hvorfor?

Beslutninger tatt i en chat forsvinner når chatten ruller forbi. record_decision tar vare på dem på to måter:

• En frittstående beslutningsregistrering: en tittel, utfallet, konteksten, alternativene som faktisk ble veid, konsekvensene og betingelsen for å se på den igjen. Registreringene kan ikke endres; å endre en betyr å registrere en ny beslutning som erstatter den, og den gamle blir stående, merket som erstattet.
• Videreformidling av en dom: når du sier til en agent i samtalen «godtatt», «gjør det om med X», «forkast det» eller «ikke nå», registrerer den dommen på oppgaven, med merknaden din.

get_task_history leser det tilbake i tre moduser: summary (kortet, den siste kvitteringen og antall), decisions (hver beslutning om oppgaven, inkludert hvorfor den ble sendt tilbake, noe som overlever selv etter en senere godkjenning) og full (den rå journalen, begrenset til 100 hendelser). get_context gir de gjeldende beslutningene videre til neste agent innenfor et tokenbudsjett, så neste kjøring starter fra det som ble bestemt i stedet for fra null. Mer om dette i hvorfor beslutninger i KI-chatter går tapt.

Hvor går jeg gjennom det, og hva klikker jeg på?

Som standard går en fullført oppgave rett til Done. Den stopper i innboksen din når oppgaven trenger gjennomgang eller når en verifiseringssjekk feiler. Der ser du kvitteringen og fire knapper: Godta, Omarbeid, Senere og Forkast. Omarbeid ber om en merknad, og den merknaden går tilbake til agenten.

Har agenten sendt med et nextStep, vises det over Godta-knappen, og å godta godkjenner akkurat det steget. Godkjenningen gjelder i 72 timer og kommer tilbake til agenten via get_my_work eller start_task som det ene steget den skal gjøre neste gang. Spørsmål en agent stiller med request_input, havner i den samme innboksen, på nettet og i appene for iOS og Android, med push-varsel på mobilen.

Innboksen har en grense med vilje: 5 ventende elementer for et arbeidsområde for én person, 10 for et team, eller 45 minutter med beregnet gjennomgangstid, det som kommer først. Når den er full, avviser start_task med attention_queue_full, så agentene fullfører eller avklarer arbeid i stedet for å stable opp mer for deg å sjekke.

Hvilke bevis bør jeg be om for hver type oppgave?

Skriv dette inn i oppgavebeskrivelsen, så agenten vet hvilke bevis du forventer:

• Kode: commit-hashen og PR-URL-en som artefakter. notDone bør nevne tester som ikke ble kjørt, migreringer som ikke ble brukt og filer som med vilje ble latt være.
• Innhold: den publiserte URL-en, eller utkastfila med sha256 hvis den ikke er publisert ennå. unknowns bør liste fakta agenten ikke kunne bekrefte.
• Research: en kilde-URL for hver viktig påstand, og notatfila. unknowns bør skille det en kilde sier, fra det agenten har sluttet seg til.
• Utsendelser: meldings-id-en til hver sendte melding, og mottakerlista som en fil. notDone bør liste hvem som ikke ble kontaktet, og hvorfor.

Hvordan styrer jeg hva en agent i det hele tatt kan gjøre?

Attribusjon i etterkant fungerer best med grenser på forhånd. I Weft har hver OAuth-tilkobling ett av tre tilgangsnivåer, satt i samtykkevinduet eller senere under Innstillinger → Tilkoblede AI-klienter:

• Alt (full, standard): alle 32 verktøyene.
• Alt unntatt å slette (skrive): alt unntatt de tre destruktive verktøyene (trash_task, archive_done_tasks, complete_sprint).
• Skrivebeskyttet (lese): bare de 11 skrivebeskyttede verktøyene.

Sjekken kjøres ved hvert kall. Disconnect tilbakekaller tilkoblingens oppdateringstokener og avviser ethvert token utstedt før bruddet ved neste kall. Personlige tilgangstokener, for klienter uten OAuth, har ingen omfang: ett token når alle 32 verktøyene, og å tilbakekalle det får virkning ved neste kall. Agenter kan flytte oppgaver til en papirkurv som beholder dem i 30 dager, men kan ikke slette dem for godt; gjenoppretting fra papirkurven er en Pro-funksjon.

Hva gjør ikke Weft her?

• Det har ingen GitHub- eller Slack-integrasjon, så Weft slår ikke opp commitene eller meldingene dine for deg. Du åpner artefaktet.
• Det har ikke noe offentlig REST-API, webhooks eller CLI for å sende kvitteringer inn i andre systemer. Det finnes eksport til JSON og Markdown.
• Det sporer ikke modellsteg. Verktøy som logger prompter, tokener og latens på modellnivå, gjør en annen jobb, og du kan godt ønske deg et slikt også.
• Agentene skriver sine egne kvitteringer. Weft gjør gapet mellom påstand og bevis synlig; det kan ikke gjøre en agent ærlig.

Vil du ha agenter administrert som tjenestekontoer over et REST-API, en CLI for CI-skript eller innebygde KI-funksjoner som oppgaveskriving og sortering, passer Hypertask bedre til det. Siden vår om alternativ til Hypertask sammenligner de to side om side.

Holder det ikke med git-historikken for å vite hva agenten min gjorde?

Git viser hva som endret seg i koden. Den viser ikke hva agenten hoppet over, hva den var usikker på, eller hvilket valg den tok mellom to alternativer. Bruk commit-hashen som et artefakt på oppgaven, og hold resten i kvitteringen og beslutningsregistreringen.

Kan ikke en agent bare finne på et artefakt?

Den kan sende hvilken som helst streng. Poenget med et artefakt er at du kan åpne det: en hash du kan slå opp, en URL du kan laste, en meldings-id du kan finne. Et oppdiktet artefakt avsløres i det øyeblikket du sjekker, noe en kommentar aldri gjør. Har en oppgave en verifiseringssjekk og en blokkerende sjekk feiler, holdes oppgaven utenfor Done.

Venter hver ferdige oppgave på at jeg skal gå gjennom den?

Nei. Som standard går en fullført oppgave til Done. Den venter i innboksen din på Godta, Omarbeid, Senere eller Forkast bare når oppgaven trenger gjennomgang eller en verifiseringssjekk feiler.

Hvilke KI-klienter kan skrive kvitteringer til Weft?

Alle MCP-klienter. ChatGPT har Weft som publisert plugin på alle planer, inkludert Free. Claude Code kobler til med claude mcp add --transport http weft https://letsweft.com/api/mcp. Claude.ai og Claude Desktop bruker en egendefinert kobling. Det finnes oppsettsider for 33 klienter, som Claude Code, ChatGPT, Cursor og Codex.

Hva koster dette?

Free dekker 50 oppgaver og 200 KI-kall i måneden. Pro koster 72 kr per plass i måneden eller 620 kr per plass i året. Weft har ingen KI-kreditter: tenkingen skjer i din egen KI-klient. Se priser.