Blog

Wat heeft mijn AI-agent gedaan? Vier vragen die je met bewijs beantwoordt

Bij elke taak van een AI-agent hoor je te zien wie hem deed, wat er veranderde, wat werd overgeslagen en waarom, met bewijs in plaats van een reactie “klaar”.

Weft is het AI-takenbeheer voor solo-oprichters en kleine teams.

Alle artikelen

Door Andrei Finogeev ·

Wil je weten wat je AI-agent heeft gedaan, begin dan niet bij zijn samenvatting. Controleer vier dingen: welke verbinding het werk deed, wat er veranderde (aangetoond door iets wat je zelf kunt openen), wat er is blijven liggen, en wat er besloten is en waarom. Rust een van de vier alleen op het woord van de agent, dan heb je een verhaal, geen dossier.

Wij maken Weft. Feiten over andere producten komen van hun officiële pagina's, gecontroleerd op 27 oktober 2026.

Waarom is een reactie met "klaar" niet genoeg?

Een reactie is de agent die zijn eigen werk beschrijft. Die kan best kloppen, maar de reactie kan dat niet aantonen, want de auteur is precies de partij die je wilt controleren. Weten dat een agent een taak heeft aangeraakt, beantwoordt de vraag wie. Het beantwoordt niet of het werk is wat je denkt dat het is.

Het artikel van Hypertask over de toeschrijving van AI-werk maakt een terecht punt: werk van agents hoort op hetzelfde bord te landen als werk van mensen, niet in een terminallog die niemand leest. Hypertask geeft agents ook een eigen identiteit als serviceaccounts, zodat wat ze schrijven aan de agent wordt toegeschreven in plaats van aan jou, en het heeft bewijs bij taken en leases, al zeggen de docs dat dat bewust alleen REST-endpoints zijn, geen MCP-tools. Waar we verschillen, is wat het dossier moet bevatten. Een reactiedraad met de uitvoer van de agent is een log van wat de agent zei. Wij willen dat het dossier bewijs bevat.

Er staan geen enquêtecijfers in deze gids. Je kunt de vier vragen vanmiddag op je eigen bord testen, en dat zegt je meer dan een branchegemiddelde.

Wat zijn de vier vragen?

Kies een willekeurige taak die een agent vorige week heeft afgerond. Je hoort elk van deze vragen in minder dan een minuut te kunnen beantwoorden, zonder de agent te vragen of zijn chat te openen:

  1. Wie deed het? Welke client, op welke verbinding, de taak claimde en afrondde.
  2. Wat is er veranderd? De uitkomst, plus artifacts die je kunt controleren zonder de agent te vertrouwen: een commit-hash, een URL, een bestand, een bericht-id.
  3. Wat is er niet gedaan? De delen die hij oversloeg, en de dingen waar hij niet zeker van was.
  4. Wat is er besloten, en waarom? Elke keuze die onderweg is gemaakt, met de afgewogen opties, en elke keer dat je het werk terugstuurde.
VraagZwak antwoord: een reactie met "klaar"Sterk antwoord: bewijs dat je kunt controleren
Wie deed het?"Agent" of je eigen naam bij elke wijziging, omdat alle tools één sleutel delenDe verbinding die de taak claimde en afrondde, onder de naam waarmee de client zich registreerde, met elke gebeurtenis in het logboek gemarkeerd als persoon of MCP en voorzien van het client-id
Wat is er veranderd?"Authenticatiemodule gerefactord, tests slagen"Een commit-hash, een URL van een PR of pagina, een bestand met zijn sha256, een bericht-id: iets wat je zelf opent
Wat is er niet gedaan?Niets gezegd, dus je neemt aan dat er niets is overgeslagenEen notDone-lijst ("migratie niet op staging gedraaid") en een unknowns-lijst ("niet zeker dat het oude endpoint geen andere aanroepers heeft")
Wat is er besloten, en waarom?Begraven in een chat die inmiddels is weggescroldEen beslissingsrecord met de afgewogen opties en de voorwaarde om erop terug te komen, plus de beslisgeschiedenis van de taak, inclusief waarom hij werd teruggestuurd

Hoe weet ik welke agent het deed?

Weft verbindt met AI-clients via het Model Context Protocol op één endpoint, https://letsweft.com/api/mcp. Elke OAuth-client en elk persoonlijk toegangstoken is een eigen actor. Een taak legt vast welke client hem aanmaakte, en het bord toont de naam waarmee die client zich bij het aanmelden registreerde, plus een pictogram. Elke gebeurtenis in het logboek van de taak bewaart of hij van een persoon kwam of via MCP, en welke client hem stuurde.

Het volledige logboek (get_task_history in de modus full) toont het ruwe client-id bij elke gebeurtenis: een OAuth-client-id, of mcp-token gevolgd door het id van het token. Het is geen vriendelijke naam, maar het is exact, en het onderscheidt twee verbindingen, ook als ze van hetzelfde product komen.

Ook het eigenaarschap tijdens het werk is expliciet. Een agent roept start_task aan, dat de taak claimt met een lease van 20 minuten en hem naar Doing verplaatst. report_progress verlengt de lease. Een tweede agent die dezelfde taak probeert, krijgt already_claimed, en een lease die verloopt, geeft de taak vrij voor iemand anders. De gids over de claimlus behandelt dit stap voor stap, en meerdere agents op één bord draaien behandelt het geval met meerdere clients.

Eén praktische regel: geef elke tool zijn eigen verbinding. Delen twee clients één toegangstoken, dan ziet het bord één actor, en verliest de vraag wie zijn antwoord.

Wat is er veranderd, en kan ik dat controleren zonder de agent te vragen?

Wanneer een agent klaar is, roept hij complete_task aan. Alleen het id van de taak is verplicht; al het andere is optioneel, en de aanroep faalt nooit bij ontbrekend bewijs. Dat is bewust: afgerond werk kwijtraken is erger dan het ongeverifieerd vastleggen. Wat een bewijsstuk kan bevatten:

  • outcome: tot 1.000 tekens over wat er gedaan is en waar het resultaat staat.
  • artifacts: tot 20 items, elk met een soort (url, file, message, commit, enzovoort), een locatie en optioneel een sha256-digest.
  • claims: wat de agent beweert te hebben gedaan, opgeslagen als beweringen in plaats van geverifieerde feiten.
  • notDone en unknowns: behandeld in de volgende sectie.
  • nextStep: wat de agent als volgende zou doen als je accepteert.
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"
})

De regel met de uitkomst is nog steeds een verhaal. De artifacts zijn het deel dat je kunt controleren. Een commit-hash bestaat in je repository of niet. Een URL laadt of niet. De sha256 van een bestand klopt of niet. Heeft een bewijsstuk een uitkomst maar geen artifacts, behandel het dan als werk volgens de agent, want dat is wat het is. Op het web laten kaarten in Done zien of een taak Geverifieerd is of Volgens de agent.

Wat heeft de agent niet gedaan?

Dit is de vraag die de meeste dossiers overslaan, en die je twee weken later opbreekt. complete_task heeft er twee lijsten voor, elk tot 20 items van 500 tekens: notDone voor wat de agent bewust heeft weggelaten, en unknowns voor waar hij niet zeker van is. De eigen beschrijving van de tool vraagt agents om hardop te zeggen wat ze niet hebben gedaan. Dat is wat een resultaat waarop je kunt bouwen onderscheidt van een resultaat dat je opnieuw moet uitzoeken.

Lees deze lijsten eerst. "Tests niet tegen de stagingdatabase gedraaid" verandert wat je hierna doet. Een bewijsstuk zonder notDone-items bij een grote taak is op zichzelf al een vraag waard.

Wat is er besloten, en waarom?

Beslissingen die in een chat worden genomen, verdwijnen wanneer de chat wegscrolt. record_decision bewaart ze op twee manieren:

  • Een op zichzelf staand beslissingsrecord: een titel, de uitkomst, de context, de opties die echt zijn afgewogen, de gevolgen, en de voorwaarde waaronder je erop terugkomt. Records zijn onveranderlijk; er een wijzigen betekent een nieuwe beslissing vastleggen die hem vervangt, en de oude blijft staan, gemarkeerd als vervangen.
  • Een doorgegeven oordeel: wanneer je een agent in een gesprek zegt "geaccepteerd", "doe het opnieuw met X", "laat maar vallen" of "niet nu", legt hij dat oordeel vast op de taak, met je notitie.

get_task_history leest het terug in drie modi: summary (de kaart, het laatste bewijsstuk en tellingen), decisions (elke beslissing over de taak, inclusief waarom hij werd teruggestuurd, wat zelfs na een latere acceptatie bewaard blijft) en full (het ruwe logboek, begrensd op 100 gebeurtenissen). get_context geeft de geldende beslissingen binnen een tokenbudget door aan de volgende agent, zodat de volgende run begint bij wat er besloten is en niet bij nul. Meer hierover in waarom beslissingen in AI-chats verloren gaan.

Waar beoordeel ik het, en waar klik ik op?

Standaard gaat een afgeronde taak rechtstreeks naar Done. Hij stopt in je Inbox wanneer de taak beoordeling nodig heeft of wanneer een verificatiecontrole faalt. Daar zie je het bewijsstuk en vier knoppen: Accepteren, Herwerken, Later en Laten vallen. Herwerken vraagt om een notitie, en die notitie gaat terug naar de agent.

Heeft de agent een nextStep meegegeven, dan staat die boven de knop Accepteren, en accepteren keurt precies die stap goed. De goedkeuring geldt 72 uur en komt via get_my_work of start_task terug bij de agent als de ene stap die hij als volgende moet doen. Vragen die een agent stelt met request_input komen in dezelfde Inbox terecht, op het web en in de apps voor iOS en Android, met een pushmelding op mobiel.

De Inbox heeft bewust een limiet: 5 wachtende items voor een werkruimte voor één persoon, 10 voor een team, of 45 minuten aan geschatte beoordelingstijd, wat het eerst bereikt wordt. Is hij vol, dan weigert start_task met attention_queue_full, zodat agents werk afmaken of verduidelijken in plaats van nog meer voor je op te stapelen om te controleren.

Om welk bewijs vraag ik per soort taak?

Schrijf dit in de taakbeschrijving, zodat de agent weet welk bewijs je verwacht:

  • Code: de commit-hash en de URL van de PR als artifacts. notDone hoort de tests te noemen die niet zijn gedraaid, migraties die niet zijn toegepast en bestanden die bewust met rust zijn gelaten.
  • Content: de gepubliceerde URL, of het conceptbestand met zijn sha256 als het nog niet live staat. unknowns hoort de feiten op te sommen die de agent niet kon bevestigen.
  • Onderzoek: een bron-URL voor elke belangrijke bewering, en het notitiebestand. unknowns hoort te scheiden wat een bron zegt en wat de agent heeft afgeleid.
  • Outreach: het bericht-id van elk verstuurd bericht, en de lijst met ontvangers als bestand. notDone hoort op te sommen wie niet is benaderd en waarom.

Hoe bepaal ik vooraf wat een agent mag doen?

Toeschrijving achteraf werkt het best met grenzen vooraf. In Weft heeft elke OAuth-verbinding een van drie rechtenniveaus, in te stellen op het toestemmingsscherm of later in Instellingen, Gekoppelde AI-clients:

  • full (de standaard): alle 32 tools.
  • write: alles behalve de drie destructieve tools (trash_task, archive_done_tasks, complete_sprint).
  • read: alleen de 11 tools die alleen lezen.

De controle draait bij elke aanroep. Ontkoppelen trekt de refresh-tokens van de verbinding in en weigert bij de volgende aanroep elk token dat vóór dat moment is uitgegeven. Persoonlijke toegangstokens, voor clients zonder OAuth, hebben geen scopes: één token bereikt alle 32 tools, en intrekken werkt bij de volgende aanroep. Agents kunnen taken naar een prullenbak van 30 dagen verplaatsen, maar ze niet definitief verwijderen; herstellen uit de prullenbak is een Pro-functie.

Wat doet Weft hier niet?

  • Het heeft geen integratie met GitHub of Slack, dus Weft zoekt je commits of berichten niet voor je op. Je opent het artifact zelf.
  • Het heeft geen openbare REST API, webhooks of CLI om bewijsstukken naar andere systemen te sturen. Er is wel een export naar JSON en Markdown.
  • Het traceert geen modelstappen. Tools die prompts, tokens en latentie op modelniveau loggen, doen ander werk, en misschien wil je er ook zo een.
  • Agents schrijven hun eigen bewijsstukken. Weft maakt het gat tussen bewering en bewijs zichtbaar; het kan een agent niet eerlijk maken.

Wil je agents beheren als serviceaccounts via een REST API, een CLI voor CI-scripts, of ingebouwde AI-functies zoals taken schrijven en triage, dan past Hypertask daar beter bij. Onze pagina Hypertask-alternatief zet de twee naast elkaar.

Is de git-geschiedenis niet genoeg om te weten wat mijn agent deed?
Git laat zien wat er in de code veranderde. Het laat niet zien wat de agent oversloeg, waar hij niet zeker van was, of welke keuze hij tussen twee opties maakte. Gebruik de commit-hash als artifact op de taak, en bewaar de rest in het bewijsstuk en het beslissingsrecord.
Kan een agent niet gewoon een artifact verzinnen?
Hij kan elke willekeurige tekst sturen. Het punt van een artifact is dat je het kunt openen: een hash die je kunt opzoeken, een URL die je kunt laden, een bericht-id dat je kunt vinden. Een verzonnen artifact valt door de mand zodra je controleert, wat een reactie nooit doet. Heeft een taak een verificatiecontrole en faalt een blokkerende controle, dan blijft de taak buiten Done.
Wacht elke afgeronde taak op mijn beoordeling?
Nee. Standaard gaat een afgeronde taak naar Done. Hij wacht alleen in je Inbox op Accepteren, Herwerken, Later of Laten vallen wanneer de taak beoordeling nodig heeft of een verificatiecontrole faalt.
Welke AI-clients kunnen bewijsstukken naar Weft schrijven?
Elke MCP-client. ChatGPT heeft Weft als gepubliceerde plugin op elk plan, ook Free. Claude Code verbindt met claude mcp add --transport http weft https://letsweft.com/api/mcp. Claude.ai en Claude Desktop gebruiken een custom connector. Er zijn setuppagina's voor 33 clients, zoals Claude Code, ChatGPT, Cursor en Codex.
Wat kost dit?
Free dekt 50 taken en 200 AI-aanroepen per maand. Pro kost $7 per plek per maand of $60 per plek per jaar. Weft heeft geen AI-credits: het denkwerk gebeurt in je eigen AI-client. Zie prijzen.