LangChain laat AI-agents hun eigen taken inplannen

TL;DR

• Wat: LangChain brengt versie 0.9 uit van Managed Deep Agents, met onder meer een Schedules SDK waarmee AI-agents zelf herinneringen en terugkerende taken aanmaken.
• Waarom relevant: AI-agents die zichzelf taken kunnen geven, verschuiven van "tool die je aanstuurt" naar "medewerker die zaken oppakt" — dat verandert hoe je over automatisering nadenkt.
• Wat je ermee kunt: Bekijk of terugkerende taken in je bedrijf (standups, checks, follow-ups) kandidaat zijn voor een agent die zichzelf inplant.

Ik viel over een bericht van LangChain op X waarin ze versie 0.9 van hun Managed Deep Agents aankondigen. Drie nieuwe functies sprongen eruit: agents die zelf taken inplannen, configuratie per afzonderlijke run, en Slack-reacties zodra een agent begint te werken. Wat mij hier triggert is niet zozeer de techniek, maar de stap die het vertegenwoordigt: een AI-agent die niet alleen antwoordt als je iets vraagt, maar zichzelf ook een agenda geeft.

Wat zijn Managed Deep Agents eigenlijk?

Managed Deep Agents (MDA) is een dienst van LangChain, gebouwd bovenop hun open-source Deep Agents-framework. Het idee: jij schrijft de instructies, kiest het taalmodel, stelt tools in en bepaalt het gedrag. LangChain regelt de infrastructuur — hosting, persistente gesprekken, sandboxes voor code-uitvoering, en koppelingen met kanalen zoals Slack.

Je uploadt je agentproject via een command-line tool (mda deploy) en LangChain draait het op hun LangSmith-platform. Volgens de publieke beta-aankondiging van augustus 2026 is MDA beschikbaar op LangSmith Cloud, voorlopig alleen in de VS-regio.

Voor de volledigheid: Deep Agents is een open-source framework dat planning, subagents, bestandsbeheer en menselijk toezicht combineert. Managed Deep Agents is de gehoste variant daarvan. Denk aan het verschil tussen zelf een server beheren en een managed hosting-pakket afnemen — dezelfde software, maar iemand anders regelt het draaiend houden.

Agents die hun eigen agenda maken

Dit is wat mij het meest opvalt aan versie 0.9. De nieuwe Schedules SDK maakt het mogelijk dat een agent — midden in een gesprek — zelf herinneringen, follow-ups en terugkerende taken aanmaakt.

Hoe werkt dat concreet? Je bouwt een tool (bijvoorbeeld remind_me) die onder de motorkap de schedules.create-functie aanroept. De agent kan dan zelf beslissen: "Dit moet elke werkdag om 9 uur gebeuren" en stelt een cron-expressie in (0 9 * * 1-5). Het resultaat wordt teruggepost in hetzelfde Slack-kanaal waar het gesprek plaatsvond.

Volgens de LangChain-documentatie zijn er twee smaken:

Statische schema's

Deze definieer je in code, in een schedules/-map. Ze worden aangemaakt bij deployment en veranderen alleen als je opnieuw deployt. Geschikt voor vaste, voorspelbare taken.

Dynamische schema's (via de SDK)

Deze maakt de agent zelf aan tijdens een gesprek. Ze kunnen berekende waarden bevatten en blijven bestaan tot ze verlopen of worden verwijderd. Je kunt ze pauzeren, aanpassen of opheffen via de API.

Stel dat je als ondernemer een agent hebt die dagelijks je voorraadstatus checkt. Met statische schema's moet een ontwikkelaar dat inbouwen en opnieuw deployen als de frequentie verandert. Met dynamische schema's zeg je tegen de agent: "Check elke maandag en donderdag om 8 uur of de voorraad van product X onder de 50 zit" — en de agent plant dat zelf in.

Ik vind het eerlijk gezegd fascinerend dat een agent hier het initiatief krijgt. Tegelijk roept het een vraag op: wie houdt overzicht over wat de agent allemaal heeft ingepland? De documentatie laat zien dat er list- en get-operaties zijn, en dat verlopen eenmalige taken standaard verborgen worden. Maar voor een bedrijfsomgeving zou ik willen weten hoe je voorkomt dat een agent zichzelf volplant met taken die niemand meer verwacht.

Eén deployment, meerdere configuraties

De tweede feature in v0.9 is per-run configuratie. Het idee: je hebt één gedeployde agent, maar bij elke afzonderlijke run kun je kiezen welk taalmodel, welke skills, welke MCP-servers en welke sandbox worden gebruikt.

De runtime-documentatie beschrijft dat de agent-factory bij elke aanroep context ontvangt. Op basis van die context — bijvoorbeeld welk team of welk kanaal de vraag stelt — kan de agent anders geconfigureerd worden.

Voor een MKB-ondernemer is dit relevant als je meerdere afdelingen of klantgroepen hebt die elk net iets anders nodig hebben. In plaats van voor elke afdeling een aparte agent te bouwen en te onderhouden, zou je één agent kunnen draaien die zich aanpast aan de context. Kun je je voorstellen wat dat scheelt in onderhoud als je drie of vier verschillende werkstromen hebt?

Een kanttekening: de documentatie is hier nog niet volledig helder. De runtime-pagina verwijst naar een "Select configuration per run"-gids die ik niet kon verifiëren. De precieze werking is dus nog niet in alle details gedocumenteerd — of in elk geval niet publiek toegankelijk op het moment van schrijven.

Slack-reacties: een klein maar slim detail

De derde toevoeging klinkt bescheiden maar is in de praktijk slim: als een agent een taak oppakt vanuit Slack, reageert hij direct met een emoji op het bericht. Zo weet je als gebruiker meteen dat je vraag is opgepikt, zonder te hoeven wachten tot het volledige antwoord klaar is.

Volgens een docs-PR op GitHub staat dit standaard aan. Je kunt de emoji aanpassen of uitschakelen. Er is ook een concept voor een functie die per bericht een passende emoji kiest, maar die is volgens de PR nog niet beschikbaar op de main-branch.

Het is een detail, maar het raakt iets fundamenteels: als een agent geen feedback geeft dat hij bezig is, voelt het alsof je in een lege ruimte praat. Die ene emoji maakt het verschil tussen "werkt dit?" en "oké, hij is ermee bezig".

Wat dit betekent voor de bredere ontwikkeling

Wat mij opvalt als ik deze drie features samen bekijk: LangChain duwt agents steeds verder richting zelfstandigheid. Niet alleen antwoorden op vragen, maar zelf taken inplannen, zich aanpassen aan de context, en communiceren dat ze bezig zijn.

Dat is een andere dynamiek dan de meeste ondernemers nu kennen van AI-tools. De meeste AI-toepassingen in het MKB zijn reactief — je stelt een vraag, je krijgt een antwoord. Een agent die zelf follow-ups inplant, is proactief. Dat vraagt ook iets anders van jou als ondernemer: je moet nadenken over grenzen, toezicht en governance.

Een analyse van TrueFoundry — zij verkopen zelf een concurrerend product, dus neem het met een korrel zout — wijst erop dat Deep Agents zich richt op agent-uitvoering, niet op enterprise-governance zoals credentialbeheer en modelbeleid. Dat is een relevante kanttekening voor wie dit in een bedrijfsomgeving wil inzetten.

Een stille verschuiving

Voor mij is dit vooral een signaal dat AI-agents in een volgende fase terechtkomen. De vraag is niet meer alleen "kan een agent mijn vraag beantwoorden?" maar "kan een agent zelfstandig taken oppakken en opvolgen?". Versie 0.9 van Managed Deep Agents zet weer een stap in die richting. Of dat voor jouw bedrijf nu al relevant is, hangt af van hoe ver je bent met automatisering — maar het is in elk geval iets om in de gaten te houden.