Hvad lavede min AI-agent? Fire spørgsmål, du skal kunne besvare med bevis

Vil du vide, hvad din AI-agent lavede, så start ikke med dens opsummering. Tjek fire ting: hvilken forbindelse der udførte arbejdet, hvad der ændrede sig (vist af noget, du selv kan åbne), hvad der blev ladt ugjort, og hvad der blev besluttet og hvorfor. Hviler bare ét af de fire på agentens ord alene, har du en fortælling, ikke en registrering.

Vi laver Weft. Fakta om andre produkter kommer fra deres officielle sider, tjekket 27. oktober 2026.

Hvorfor er en kommentar, der siger "færdig", ikke nok?

En kommentar er agenten, der beskriver sit eget arbejde. Den kan sagtens være korrekt, men kommentaren kan ikke vise det, fordi forfatteren er netop den part, du prøver at kontrollere. At vide, at en agent har rørt en opgave, besvarer hvem. Det besvarer ikke, om arbejdet er det, du tror, det er.

Hypertasks artikel om tilskrivning af AI-arbejde har en fair pointe: agenters arbejde bør lande på den samme tavle som menneskers arbejde, ikke i en terminallog, som ingen læser. Hypertask giver også agenter deres egen identitet som servicekonti, så ændringer tilskrives agenten i stedet for dig, og den har opgavedokumentation og leases, selvom dens dokumentation siger, at det kun er REST-endpoints, ikke MCP-værktøjer, by design. Hvor vi er uenige, er i, hvad registreringen skal indeholde. En kommentartråd med agentens output er en log over, hvad agenten sagde. Vi vil have, at registreringen rummer bevis.

Der er ingen tal fra undersøgelser i denne guide. Du kan teste de fire spørgsmål på din egen tavle i eftermiddag, og det fortæller dig mere end et branchegennemsnit.

Hvad er de fire spørgsmål?

Vælg en hvilken som helst opgave, en agent gjorde færdig i sidste uge. Du bør kunne besvare hvert af disse på under et minut uden at spørge agenten eller åbne dens chat:

1. Hvem gjorde det? Hvilken klient, på hvilken forbindelse, der gjorde krav på og afsluttede opgaven.
2. Hvad ændrede sig? Resultatet plus artefakter, du kan tjekke uden at stole på agenten: en commit-hash, en URL, en fil, et besked-id.
3. Hvad blev ikke gjort? De dele, den sprang over, og de ting, den var usikker på.
4. Hvad blev besluttet, og hvorfor? Ethvert valg undervejs med de afvejede muligheder, og hver gang du sendte arbejdet tilbage.

Hvordan ved jeg, hvilken agent der gjorde det?

Weft forbinder til AI-klienter over Model Context Protocol på ét endpoint, https://letsweft.com/api/mcp. Hver OAuth-klient og hvert personligt adgangstoken er sin egen aktør. En opgave registrerer, hvilken klient der oprettede den, og tavlen viser det navn, klienten registrerede ved login, plus et ikon. Hver hændelse i opgavens journal gemmer, om den kom fra en person eller over MCP, og hvilken klient der sendte den.

Den fulde journal (get_task_history i full-tilstand) viser det rå klient-id for hver hændelse: et OAuth-klient-id eller mcp-token efterfulgt af tokenets id. Det er ikke et venligt navn, men det er præcist, og det skelner mellem to forbindelser, selv når de kommer fra det samme produkt.

Ejerskabet under arbejdet er også eksplicit. En agent kalder start_task, som gør krav på opgaven med en lease på 20 minutter og flytter den til Doing. report_progress fornyer leasen. En anden agent, der prøver den samme opgave, får already_claimed, og en lease, der udløber, frigiver opgaven til en anden. Guiden til claim-løkken gennemgår det skridt for skridt, og at køre flere agenter på én tavle dækker tilfældet med flere klienter.

En praktisk regel: giv hvert værktøj sin egen forbindelse. Deler to klienter ét adgangstoken, ser tavlen én aktør, og hvem-spørgsmålet mister sit svar.

Hvad ændrede sig, og kan jeg tjekke det uden at spørge agenten?

Når en agent er færdig, kalder den complete_task. Kun opgavens id er påkrævet; alt andet er valgfrit, og kaldet fejler aldrig på grund af manglende dokumentation. Det er bevidst: at miste færdigt arbejde er værre end at registrere det uverificeret. Det kan en kvittering indeholde:

• outcome: op til 1.000 tegn om, hvad der blev gjort, og hvor resultatet ligger.
• artifacts: op til 20 poster, hver med en type (url, file, message, commit osv.), en placering og eventuelt en sha256-digest.
• claims: det, agenten påstår, den gjorde, gemt som påstande og ikke som verificerede fakta.
• notDone og unknowns: beskrevet i næste afsnit.
• nextStep: det, agenten ville gøre som det næste, hvis du godkender.

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 stadig fortælling. Artefakterne er den del, du kan tjekke. En commit-hash findes enten i dit repository, eller også gør den ikke. En URL indlæses, eller også gør den ikke. En fils sha256 passer, eller også gør den ikke. Har en kvittering et resultat og ingen artefakter, så behandl den som arbejde rapporteret af agenten, for det er, hvad det er. På nettet viser Done-kort, om en opgave er Verificeret eller Ifølge agenten.

Hvad gjorde agenten ikke?

Det er det spørgsmål, de fleste registreringer springer over, og det, der bider to uger senere. complete_task har to lister til det, hver med op til 20 poster på 500 tegn: notDone til det, agenten bevidst lod ude, og unknowns til det, den er usikker på. Værktøjets egen beskrivelse beder agenter sige højt, hvad de ikke gjorde. Det er det, der skiller et resultat, du kan stole på, fra et, du må regne ud forfra.

Læs de lister først. "Kørte ikke testene mod staging-databasen" ændrer, hvad du gør nu. En kvittering uden notDone-poster på en stor opgave er i sig selv et spørgsmål værd.

Hvad blev besluttet, og hvorfor?

Beslutninger truffet i chatten forsvinder, når chatten ruller væk. record_decision gemmer dem på to måder:

• En selvstændig beslutningsregistrering: en titel, udfaldet, konteksten, de muligheder, der faktisk blev afvejet, konsekvenserne og betingelsen for at tage den op igen. Registreringer kan ikke ændres; at ændre en betyder at registrere en ny beslutning, der erstatter den, og den gamle bliver stående, markeret som erstattet.
• En dom videregivet: når du i en samtale siger til en agent "godkendt", "lav det om med X", "drop det" eller "ikke nu", registrerer den dommen på opgaven sammen med din note.

get_task_history læser det tilbage i tre tilstande: summary (kortet, dets seneste kvittering og antal), decisions (hver beslutning om opgaven, inklusive hvorfor den blev sendt tilbage, som overlever selv efter en senere godkendelse) og full (den rå journal, højst 100 hændelser). get_context giver de gældende beslutninger videre til den næste agent inden for et budget af tokens, så næste kørsel starter fra det, der blev besluttet, i stedet for fra bunden. Mere om det i hvorfor beslutninger i AI-chats går tabt.

Hvor gennemgår jeg det, og hvad klikker jeg på?

Som standard går en afsluttet opgave direkte til Done. Den stopper i din Inbox, når opgaven skal gennemgås, eller når en verifikation fejler. Dér ser du kvitteringen og fire knapper: Godkend, Omarbejd, Senere og Drop. Omarbejd kræver en note, og den note går tilbage til agenten.

Har agenten givet et nextStep, vises det over Godkend-knappen, og en godkendelse godkender præcis det skridt. Godkendelsen gælder i 72 timer og kommer tilbage til agenten via get_my_work eller start_task som det ene skridt, den skal tage nu. Spørgsmål, som en agent stiller med request_input, lander i den samme Inbox, på nettet og i apps til iOS og Android, med en push-besked på mobilen.

Inbox har med vilje en grænse: 5 ventende punkter i et arbejdsområde med én person, 10 i et team eller 45 minutters anslået gennemgangstid, alt efter hvad der kommer først. Når den er fuld, afviser start_task med attention_queue_full, så agenterne gør arbejde færdigt eller afklarer det i stedet for at dynge mere op, som du skal tjekke.

Hvilke beviser skal jeg bede om for hver type opgave?

Skriv dem ind i opgavebeskrivelsen, så agenten ved, hvilket bevis du forventer:

• Kode: commit-hashen og PR-URL'en som artefakter. notDone bør nævne de test, der ikke blev kørt, migreringer, der ikke blev anvendt, og filer, der bevidst blev ladt i fred.
• Indhold: den udgivne URL eller kladdefilen med sin sha256, hvis den ikke er live endnu. unknowns bør liste fakta, agenten ikke kunne bekræfte.
• Research: en kilde-URL til hver vigtig påstand og notatfilen. unknowns bør skelne mellem, hvad en kilde siger, og hvad agenten har udledt.
• Opsøgende kontakt: besked-id'et for hver sendt besked og modtagerlisten som en fil. notDone bør liste, hvem der ikke blev kontaktet og hvorfor.

Hvordan styrer jeg, hvad en agent overhovedet kan gøre?

Tilskrivning bagefter virker bedst med grænser forinden. I Weft har hver OAuth-forbindelse ét af tre rettighedsniveauer, sat på samtykkeskærmen eller senere under Indstillinger, Forbundne AI-klienter:

• full (standard): alle 32 værktøjer.
• write: alt undtagen de tre destruktive værktøjer (trash_task, archive_done_tasks, complete_sprint).
• read: kun de 11 skrivebeskyttede værktøjer.

Tjekket kører ved hvert kald. Disconnect tilbagekalder forbindelsens refresh tokens og afviser ethvert token udstedt før afbrydelsen ved dets næste kald. Personlige adgangstokens til klienter uden OAuth har ingen scopes: ét token når alle 32 værktøjer, og en tilbagekaldelse virker fra næste kald. Agenter kan flytte opgaver til en papirkurv i 30 dage, men ikke slette dem for altid; gendannelse fra papirkurven er en Pro-funktion.

Hvad gør Weft ikke her?

• Den har ingen GitHub- eller Slack-integration, så Weft slår ikke dine commits eller beskeder op for dig. Du åbner selv artefaktet.
• Den har intet offentligt REST API, ingen webhooks og ingen CLI til at skubbe kvitteringer ind i andre systemer. Der er eksport til JSON og Markdown.
• Den sporer ikke modellens skridt. Værktøjer, der logger prompts, tokens og latens i modellaget, gør et andet job, og du vil måske også have et af dem.
• Agenterne skriver selv deres kvitteringer. Weft gør afstanden mellem påstand og bevis synlig; den kan ikke gøre en agent ærlig.

Vil du have agenter administreret som servicekonti over et REST API, en CLI til CI-scripts eller indbyggede AI-funktioner som opgaveskrivning og triage, passer Hypertask bedre til det. Vores side om alternativ til Hypertask sammenligner de to side om side.

Er git-historikken ikke nok til at vide, hvad min agent lavede?

Git viser, hvad der ændrede sig i koden. Den viser ikke, hvad agenten sprang over, hvad den var usikker på, eller hvilket valg den traf mellem to muligheder. Brug commit-hashen som artefakt på opgaven, og hold resten i kvitteringen og beslutningsregistreringen.

Kan en agent ikke bare finde på et artefakt?

Den kan sende en hvilken som helst streng. Pointen med et artefakt er, at du kan åbne det: en hash, du kan slå op, en URL, du kan indlæse, et besked-id, du kan finde. Et opdigtet et falder igennem, i samme øjeblik du tjekker, hvilket en kommentar aldrig gør. Har en opgave en verifikation, og et blokerende tjek fejler, kommer opgaven ikke i Done.

Venter hver færdig opgave på min gennemgang?

Nej. Som standard går en afsluttet opgave til Done. Den venter kun i din Inbox på Godkend, Omarbejd, Senere eller Drop, når opgaven skal gennemgås, eller en verifikation fejler.

Hvilke AI-klienter kan skrive kvitteringer til Weft?

Enhver MCP-klient. ChatGPT har Weft som udgivet plugin på alle planer, også Free. Claude Code forbinder med claude mcp add --transport http weft https://letsweft.com/api/mcp. Claude.ai og Claude Desktop bruger en custom connector. Der er opsætningssider til 33 klienter, som Claude Code, ChatGPT, Cursor og Codex.

Hvad koster det?

Free dækker 50 opgaver og 200 AI-kald om måneden. Pro koster 8,13 € pr. plads om måneden eller 68,75 € pr. plads om året. Weft har ingen AI-kreditter: tænkningen sker i din egen AI-klient. Se priser.