Dogwood legt volgorde vast voor agenttools; lokale sandboxes en SSD-inference verkennen grenzen

AWS brengt met Dogwood een open beleidstaal voor agent-toolcalls die ook naar eerdere acties kan kijken. Daarnaast verschijnen twee vroege lokale proeven: Firecracker-sandboxes die op disk slapen en een SSD-tier voor een te groot MoE-model. Beide zijn interessant als ontwerp- of testpunt, niet als bewezen productiepad.

Dogwood voegt tijd en volgorde toe aan agentbeleid

AWS heeft Dogwood als Apache-2.0-project en als uitbreiding voor Bedrock AgentCore Policy gepubliceerd. Waar Cedar een afzonderlijke autorisatiebeslissing kan nemen op basis van de huidige toolcall, kan Dogwood volgens AWS ook een recente eventgeschiedenis evalueren. Daarmee kun je bijvoorbeeld eisen dat een verkoop voor precies hetzelfde bedrag in het afgelopen uur is goedgekeurd, een maximumaantal transfers per uur afdwingen, of externe contacten blokkeren nadat een agent vertrouwelijke data heeft geraadpleegd.

Dat vult een praktisch gat: veel agentregels gaan niet over één call, maar over de volgorde en frequentie ervan. Dogwood registreert daarvoor toolcall-verzoeken én uitkomsten; voor MCP-tools wordt de actieschema volgens AWS uit de beschikbare tools afgeleid. De bron wijst zelf op de lastige kant: parallelle en asynchrone toolcalls kunnen in de gebeurtenisgeschiedenis interleaven. Een policy moet die race- en correlatiegevallen dus expliciet modelleren.

Dit is geen algemene oplossing voor agentveiligheid. De handhaving staat of valt met complete, betrouwbare eventregistratie en met de toolgrens waarop je de policy daadwerkelijk afdwingt. AWS presenteert de taal en voorbeelden zelf; onafhankelijke securityevaluaties of praktijkmetingen ontbreken in de beschikbare context. Toch is het een bruikbaar patroon voor risicovolle workflows: formuleer eerst controleerbare toestandsregels — approval vóór betaling, quota, egress-na-geheim — en test ze op concurrerende traces, niet alleen op één gelukkige route. AWS over Dogwood · Lobsters-discussie

kindling wil idle MCP-tools isoleren zonder permanent RAM-verbruik

Het open-sourceproject kindling gebruikt Firecracker-microVM’s met zogeheten golden snapshots. Volgens de maker kan een bevroren VM op disk zonder RAM of CPU blijven staan en bij een request in ongeveer 30 ms terugkeren. Het project richt zich onder meer op MCP-servers per microVM, tijdelijke omgevingen voor door een agent geschreven code en kleine llama.cpp-modellen die pas bij een request ontwaken.

Het interessante ontwerpidee is niet alleen de starttijd, maar de scheiding per workload: een toolserver hoeft niet automatisch bij bestanden en secrets van de host te kunnen. De maker rapporteert op een homelab 142 microVM’s in 3,9 GB host-RAM en tien instanties uit één snapshot die samen 68 MiB extra gebruiken. De runtime noemt ondersteuning voor bare metal, een privileged LXC op Proxmox en Apple Silicon.

Die cijfers zijn zelfrapportage en geen onafhankelijke isolatieaudit. Cruciaal is bovendien wat er na een call met gewijzigde disk- en geheugenstaat gebeurt: reset naar de snapshot of hergebruik kan sterk verschillende securityeigenschappen hebben. De repository verwijst volgens de auteur ook zelf naar onopgeloste punten in SECURITY.md. Zie dit daarom als een interessante manier om agenttools standaard kortlevend en beperkt te maken, maar controleer snapshot-lifecycle, mounts, netwerkegress en credential-injectie voordat je er vertrouwelijke automatisering op bouwt. Aankondiging en projectlink

SSD-tiering haalt Flash Next op één 16GB-kaart, met prefill als harde ruil

Een ontwikkelaar publiceert InferredThoughts, een eigen engine die Qwen3.8-Flash-Next in een NVFP4-GGUF van 119 GiB over VRAM, RAM en NVMe verdeelt. In de beschreven opstelling — RTX 5060 Ti met 16 GB, Ryzen 7 9700X, 32 GB RAM en Gen5-NVMe onder Windows 11 — blijven dense weights en veelgebruikte experts in geheugen; overige experts en de n-gramtabel worden vanaf SSD gelezen en vooraf opgehaald. De post noemt circa 9–10 tok/s decode, tegenover gemiddeld 4,9 tok/s met llama.cpp op dezelfde machine.

De beperking staat eveneens in de eigen metingen: voor elke token zou nog ongeveer 270 MiB van SSD worden gelezen en bij prefill worden alle experts geraakt. De auteur rapporteert 49,2 tok/s op een prompt van 5.500 tokens, maar een reactie noemt prefill in eigen gebruik te traag voor praktisch dagelijks werk. Dit past vooral bij een langlopende batchtaak waarbij je een koude start accepteert, niet bij een korte, interactieve agentbeurt.

Het is een andere technische route dan de eerder beschreven diskexperimenteerprojecten: hier claimt de maker expliciet NVFP4-matmuls, een VRAM/RAM-cache met GCLOCK-evictie en lookahead voor gerouteerde experts. Maar de resultaten zijn één makersopstelling, de server is volgens de post nog beperkt tot Windows/WSL2 en Blackwell, en toolcalls zijn nog buggy getest met Cline. Beoordeel dus koude én warme prefill, SSD-temperatuur, foutgedrag en echte taakvoltooiing naast decode-snelheid. Opzet, code en beperkingen

Go-vanitypaden maken een forgewissel eenvoudiger — maar verplaatsen vertrouwen

Een Go-artikel pleit ervoor interne en publieke modules niet direct als github.com/organisatie/project te importeren, maar via een eigen domein. De voorgestelde route is een go-import-meta-tag op dat domein die nu naar GitHub wijst; bij een latere verhuizing naar bijvoorbeeld GitLab blijft het importpad in afhankelijkheden gelijk. De bron bevat een minimale Nginx- en HTML-configuratie.

Dat is een bruikbare migratiekeuze voor teams die forge, eigendom of interne hosting willen kunnen veranderen zonder een grootschalige importpadmigratie. Maar een vanitydomein is geen gratis onafhankelijkheidslaag: het voegt DNS, domeinverlenging en beheer als nieuwe beschikbaarheids- en vertrouwensafhankelijkheid toe. In de HN-discussie wordt bovendien terecht opgemerkt dat een replace-directive alleen in de hoofdmodule telt; een fork die zelf zo’n override bevat, draagt die niet door naar consumers.

De pragmatische les is daarom: kies een domein waarvan het eigenaarschap en verlengingsproces ook op lange termijn geborgd zijn, houd de redirect- en metatagconfiguratie in versiebeheer, en test een forgewissel inclusief proxy, checksumdatabase, CI en private modules. Dit is een ontwerp- en migratieadvies, geen aanwijzing dat GitHub als host onveilig of onbruikbaar is. Artikel met configuratie · HN-discussie

Verder nog

• MiMo-9B en chattemplates: een gebruiker vermoedt dat de standaardtemplate van MiMo-V2.6-Distill-Qwen-9B in llama.cpp reasoning en toolcalls verkeerd afgrenst, en publiceert een alternatief. Dit is een ander, onbevestigd probleem dan de MOPD-patch voor Flash uit de einde-dagupdate van gisteren; er is geen upstreambevestiging of degelijke A/B-evaluatie. Inspecteer daarom eerst de daadwerkelijk gerenderde prompt en test toolcalls en meerturnsessies vóór je een custom template overneemt. Communityanalyse en template