Vad gjorde min AI-agent? Fyra frågor att besvara med belägg

För att veta vad din AI-agent gjorde ska du inte börja med dess sammanfattning. Kontrollera fyra saker: vilken anslutning som gjorde arbetet, vad som ändrades (visat av något du själv kan öppna), vad som lämnades ogjort, och vad som beslutades och varför. Om någon av de fyra bara vilar på agentens ord har du en berättelse, inte en dokumentation.

Vi gör Weft. Fakta om andra produkter kommer från deras officiella sidor och kontrollerades den 27 oktober 2026.

Varför räcker det inte med en kommentar som säger ”klart”?

En kommentar är agenten som beskriver sitt eget arbete. Den kan mycket väl stämma, men kommentaren kan inte visa det, eftersom författaren är just den part du försöker kontrollera. Att veta att en agent rörde en uppgift besvarar vem. Det besvarar inte om arbetet är det du tror att det är.

Hypertasks artikel om spårbarhet för AI-arbete har en poäng: agenters arbete ska hamna på samma tavla som människors arbete, inte i en terminallogg som ingen läser. Hypertask ger också agenter en egen identitet som tjänstekonton, så att ändringar tillskrivs agenten i stället för dig, och har belägg och leasing för uppgifter, även om deras dokumentation säger att de bara finns som REST-slutpunkter, inte MCP-verktyg, med avsikt. Där vi skiljer oss åt är vad dokumentationen ska innehålla. En kommentarstråd med agentens utdata är en logg över vad agenten sa. Vi vill att dokumentationen ska innehålla belägg.

Det finns inga enkätsiffror i den här guiden. Du kan testa de fyra frågorna på din egen tavla i eftermiddag, och det säger dig mer än ett branschgenomsnitt.

Vilka är de fyra frågorna?

Välj valfri uppgift som en agent avslutade förra veckan. Du ska kunna besvara var och en av de här på under en minut utan att fråga agenten eller öppna dess chatt:

1. Vem gjorde den? Vilken klient, på vilken anslutning, som tog och avslutade uppgiften.
2. Vad ändrades? Resultatet, plus artefakter som du kan kontrollera utan att lita på agenten: en commit-hash, en URL, en fil, ett meddelande-id.
3. Vad gjordes inte? De delar den hoppade över, och det den var osäker på.
4. Vad beslutades, och varför? Varje val som gjordes på vägen, med de alternativ som vägdes, och varje gång du skickade tillbaka arbetet.

Hur vet jag vilken agent som gjorde det?

Weft ansluter till AI-klienter via Model Context Protocol på en enda slutpunkt, https://letsweft.com/api/mcp. Varje OAuth-klient och varje personlig åtkomsttoken är en egen aktör. En uppgift registrerar vilken klient som skapade den, och tavlan visar namnet som klienten registrerade vid inloggningen, plus en ikon. Varje händelse i uppgiftens journal sparar om den kom från en person eller via MCP, och vilken klient som skickade den.

Den fullständiga journalen (get_task_history i läget full) visar det råa klient-id:t för varje händelse: ett OAuth-klient-id, eller mcp-token följt av tokenens id. Det är inget vänligt namn, men det är exakt, och det skiljer två anslutningar åt även när de kommer från samma produkt.

Ägarskapet under arbetet är också uttryckligt. En agent anropar start_task, som tar uppgiften med en 20-minuters lease och flyttar den till Doing. report_progress förnyar leasen. En andra agent som försöker ta samma uppgift får already_claimed, och en lease som löper ut frigör uppgiften för någon annan. Guiden om anspråksloopen går igenom detta steg för steg, och att köra flera agenter på en tavla täcker fallet med flera klienter.

En praktisk regel: ge varje verktyg en egen anslutning. Om två klienter delar en åtkomsttoken ser tavlan en aktör, och frågan om vem förlorar sitt svar.

Vad ändrades, och kan jag kontrollera det utan att fråga agenten?

När en agent är klar anropar den complete_task. Bara uppgiftens id krävs; allt annat är valfritt, och anropet misslyckas aldrig på grund av saknade belägg. Det är avsiktligt: det är värre att förlora färdigt arbete än att registrera det overifierat. Det här kan ett kvitto innehålla:

• outcome: upp till 1 000 tecken om vad som gjordes och var resultatet finns.
• artifacts: upp till 20 poster, var och en med en typ (url, file, message, commit och så vidare), en plats och eventuellt en sha256-kontrollsumma.
• claims: det agenten påstår att den gjorde, sparat som påståenden snarare än verifierade fakta.
• notDone och unknowns: beskrivs i nästa avsnitt.
• nextStep: vad agenten skulle göra härnäst om du godkänner.

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"
})

Raden med resultatet är fortfarande en berättelse. Artefakterna är den del du kan kontrollera. En commit-hash finns antingen i ditt kodförråd eller inte. En URL laddas eller inte. En fils sha256 stämmer eller inte. Om ett kvitto har ett resultat men inga artefakter, behandla det som arbete rapporterat av agenten, för det är vad det är. På webben visar korten i Done om en uppgift är Verifierad eller Enligt agenten.

Vad gjorde agenten inte?

Det här är frågan som de flesta dokumentationer hoppar över, och den som biter två veckor senare. complete_task har två listor för den, var och en med upp till 20 poster på 500 tecken: notDone för det agenten medvetet utelämnade, och unknowns för det den är osäker på. Verktygets egen beskrivning ber agenterna att uttryckligen säga vad de inte gjorde. Det är det som skiljer ett resultat du kan lita på från ett du måste återskapa.

Läs de här listorna först. ”Körde inte testerna mot staging-databasen” ändrar vad du gör härnäst. Ett kvitto utan notDone-poster på en stor uppgift är i sig värt en fråga.

Vad beslutades, och varför?

Beslut som fattas i en chatt försvinner när chatten scrollar förbi. record_decision behåller dem på två sätt:

• Ett fristående beslutsprotokoll: en titel, utfallet, sammanhanget, de alternativ som faktiskt vägdes, konsekvenserna och villkoret för när det ska omprövas. Protokollen är oföränderliga; att ändra ett innebär att registrera ett nytt beslut som ersätter det, och det gamla ligger kvar, markerat som ersatt.
• Ett vidarebefordrat utslag: när du säger ”godkänt”, ”gör om det med X”, ”slopa det” eller ”inte nu” till en agent i ett samtal registrerar den utslaget på uppgiften, med din notering.

get_task_history läser tillbaka det i tre lägen: summary (kortet, dess senaste kvitto och antal), decisions (varje beslut om uppgiften, inklusive varför den skickades tillbaka, vilket finns kvar även efter ett senare godkännande) och full (den råa journalen, högst 100 händelser). get_context lämnar över de gällande besluten till nästa agent inom en tokenbudget, så att nästa körning börjar från det som beslutades i stället för från noll. Mer om det i varför beslut i AI-chattar går förlorade.

Var granskar jag det, och vad klickar jag på?

Som standard går en avslutad uppgift direkt till Done. Den stannar i din Inkorg när uppgiften behöver granskas eller när en verifieringskontroll misslyckas. Där ser du kvittot och fyra knappar: Godkänn, Omarbeta, Senare och Slopa. Omarbeta kräver en notering, och den noteringen går tillbaka till agenten.

Om agenten skickade med ett nextStep visas det ovanför knappen Godkänn, och att godkänna godkänner exakt det steget. Godkännandet gäller i 72 timmar och kommer tillbaka till agenten via get_my_work eller start_task som det enda steg den ska göra härnäst. Frågor som en agent ställer med request_input hamnar i samma Inkorg, på webben och i apparna för iOS och Android, med en push-notis i mobilen.

Inkorgen har en gräns med avsikt: 5 väntande poster för en arbetsyta med en person, 10 för ett team, eller 45 minuters uppskattad granskningstid, det som kommer först. När den är full nekar start_task med attention_queue_full, så att agenterna avslutar eller förtydligar arbete i stället för att stapla upp mer för dig att kontrollera.

Vilka belägg ska jag be om för olika typer av uppgifter?

Skriv in det här i uppgiftsbeskrivningen så att agenten vet vilka belägg du väntar dig:

• Kod: commit-hashen och PR-URL:en som artefakter. notDone ska nämna tester som inte körts, migreringar som inte tillämpats och filer som medvetet lämnats orörda.
• Innehåll: den publicerade URL:en, eller utkastfilen med sin sha256 om den inte är publicerad än. unknowns ska lista fakta som agenten inte kunde bekräfta.
• Research: en käll-URL för varje viktigt påstående, och anteckningsfilen. unknowns ska skilja det en källa säger från det agenten drog slutsatser om.
• Utskick: meddelande-id för varje skickat meddelande, och mottagarlistan som en fil. notDone ska lista vilka som inte kontaktades och varför.

Hur styr jag vad en agent får göra från början?

Spårbarhet i efterhand fungerar bäst med gränser i förväg. I Weft har varje OAuth-anslutning en av tre behörighetsnivåer, som sätts på samtyckesskärmen eller senare under Inställningar, Anslutna AI-klienter:

• full (standard): alla 32 verktyg.
• skriv: allt utom de tre destruktiva verktygen (trash_task, archive_done_tasks, complete_sprint).
• läs: bara de 11 skrivskyddade verktygen.

Kontrollen körs vid varje anrop. Koppla bort återkallar anslutningens refresh-token och nekar varje token som utfärdats före avbrottet vid dess nästa anrop. Personliga åtkomsttoken, för klienter utan OAuth, har inga behörighetsnivåer: en token når alla 32 verktyg, och att återkalla den gäller från nästa anrop. Agenter kan flytta uppgifter till en papperskorg som sparar dem i 30 dagar men kan inte radera dem för gott; återställning från papperskorgen är en Pro-funktion.

Vad gör Weft inte här?

• Det har ingen integration med GitHub eller Slack, så Weft slår inte upp dina commits eller meddelanden åt dig. Du öppnar artefakten.
• Det har inget publikt REST-API, inga webhooks eller CLI för att skicka kvitton till andra system. Det finns en export till JSON och Markdown.
• Det spårar inte modellens steg. Verktyg som loggar prompter, token och latens i modellagret gör ett annat jobb, och du kanske vill ha ett sådant också.
• Agenterna skriver sina egna kvitton. Weft gör glappet mellan påstående och belägg synligt; det kan inte göra en agent ärlig.

Vill du ha agenter som hanteras som tjänstekonton via ett REST-API, ett CLI för CI-skript, eller inbyggda AI-funktioner som uppgiftsskrivande och sortering, passar Hypertask bättre för det. Vår sida alternativ till Hypertask jämför de två sida vid sida.

Räcker inte git-historiken för att veta vad min agent gjorde?

Git visar vad som ändrades i koden. Det visar inte vad agenten hoppade över, vad den var osäker på eller vilket val den gjorde mellan två alternativ. Använd commit-hashen som artefakt på uppgiften, och håll resten i kvittot och beslutsprotokollet.

Kan inte en agent bara hitta på en artefakt?

Den kan skicka vilken sträng som helst. Poängen med en artefakt är att du kan öppna den: en hash du kan slå upp, en URL du kan ladda, ett meddelande-id du kan hitta. En påhittad faller i samma ögonblick som du kontrollerar, vilket en kommentar aldrig gör. När en uppgift har en verifieringskontroll och en blockerande kontroll misslyckas hålls uppgiften utanför Done.

Väntar varje färdig uppgift på min granskning?

Nej. Som standard går en avslutad uppgift till Done. Den väntar i din Inkorg på Godkänn, Omarbeta, Senare eller Slopa bara när uppgiften behöver granskas eller en verifieringskontroll misslyckas.

Vilka AI-klienter kan skriva kvitton till Weft?

Vilken MCP-klient som helst. ChatGPT har Weft som ett publicerat plugin på alla planer, även Free. Claude Code ansluter med claude mcp add --transport http weft https://letsweft.com/api/mcp. Claude.ai och Claude Desktop använder en egen koppling. Det finns uppsättningssidor för 33 klienter, till exempel Claude Code, ChatGPT, Cursor och Codex.

Vad kostar det här?

Free täcker 50 uppgifter och 200 AI-anrop i månaden. Pro kostar $7 per plats i månaden eller $60 per plats om året. Weft har inga AI-krediter: tänkandet sker i din egen AI-klient. Se priser.