eerste stabiele v1.0-release eind oktober 2025. Na de afgelopen twee maanden met hun nieuwe API’s te hebben gewerkt, heb ik echt het gevoel dat dit de meest samenhangende en doordacht ontworpen versie van LangChain tot nu toe is.
Ik was niet altijd een LangChain-fan. De vroege versies waren fragiel, slecht gedocumenteerd, de abstracties veranderden regelmatig en het voelde te voorbarig om in productie te gebruiken. Maar v1.0 voelde meer opzettelijk aan en had een consistenter mentaal model voor hoe gegevens door agenten en tools zouden moeten stromen.
Dit is niet trouwens een gesponsorde post – ik hoor graag je mening, stuur me gerust een DM hier!
Dit artikel is niet hier om de documenten opnieuw uit te braken. Ik neem aan dat je al met LangChain hebt gewerkt (of een zware gebruiker bent). In plaats van een waslijst met punten te dumpen, kies ik slechts vier belangrijke punten.
Een korte samenvatting: LangChain, LangGraph & LangSmith
Op een hoog niveau is LangChain een raamwerk voor het bouwen van LLM-apps en -agents, waardoor ontwikkelaars AI-functies snel kunnen leveren met gemeenschappelijke abstracties.
LangGraph is de op grafieken gebaseerde uitvoeringsengine voor duurzame, stateful agentworkflows op een beheersbare manier. Ten slotte is LangSmith een observatieplatform voor tracering en monitoring.
Simpel gezegd: met LangChain kunt u snel agenten bouwen, met LangGraph kunt u ze betrouwbaar uitvoeren, en met LangSmith kunt u ze tijdens de productie controleren en verbeteren.
Mijn stapel
Ter context: het grootste deel van mijn recente werk richt zich op het bouwen van multi-agentfuncties voor een klantgericht AI-platform op het werk. Mijn backendstack is FastAPI, waarbij Pydantic schemavalidatie en datacontracten mogelijk maakt.
Les 1: Ondersteuning voor Pydantic-modellen laten vallen
Een belangrijke verschuiving in de migratie naar v1.0 was de introductie van het nieuwe create_agent methode. Het stroomlijnt de manier waarop agenten worden gedefinieerd en aangeroepen, maar het vermindert ook de ondersteuning voor Pydantic-modellen en dataklassen in de agentstatus. Alles moet nu worden uitgedrukt als TypedDicts-uitbreiding AgentState.
Als u FastAPI gebruikt, is Pydantic vaak de aanbevolen en standaard schemavalidator. Ik waardeerde schemaconsistentie in de hele codebase en was van mening dat het mixen van TypedDicts- en Pydantic-modellen onvermijdelijk voor verwarring zou zorgen, vooral voor nieuwe engineers die misschien niet weten welk schemaformaat ze moeten volgen.
Om dit op te lossen heb ik een kleine helper geïntroduceerd die een Pydantic-model omzet in een TypedDict dat zich uitbreidt AgentState vlak voordat het wordt doorgegeven create_agent . Het is van cruciaal belang op te merken dat LangChain aangepaste metagegevens toevoegt aan typeannotaties die u moet behouden. Python-hulpprogramma’s zoals get_type_hints() verwijder deze annotaties, wat betekent dat een naïeve conversie niet zal werken.
Les 2: Diepe agenten hebben een eigen mening
Naast het nieuwe create_agent API in LangChain 1.0 kwam er iets dat mijn aandacht trok: de deepagents bibliotheek. Geïnspireerd door tools als Claude Code en Manus kunnen deep agents plannen, taken in stappen opsplitsen en zelfs subagenten spawnen.
Toen ik dit voor het eerst zag, wilde ik het gebruiken overal. Waarom zou je geen “slimmere” agenten willen, toch? Maar nadat ik het in verschillende workflows had uitgeprobeerd, besefte ik dat deze extra autonomie soms onnodig (en in bepaalde gevallen contraproductief) was voor mijn gebruiksscenario’s.
De deepagents bibliotheek is redelijk eigenwijs, en heel erg door het ontwerp. Elke deep agent wordt geleverd met ingebouwde middleware, zoals ToDoListMiddleware, FilesystemMiddleware, SummarizationMiddlewareenz. Deze bepalen hoe de agent de context denkt, plant en beheert. De vangst is dat jij kan het niet precies controleren wanneer deze standaard middleware wordt uitgevoerd, en u kunt ook niet de middleware uitschakelen die u niet nodig hebt.
Na het graven in de deepagents broncode hier, kunt u zien dat de middleware-parameter is aanvullend middleware toe te passen na standaard middleware. Elke middleware die is doorgegeven middleware=(...) wordt toegevoegd na de standaardinstellingen.
Al deze extra orkestratie zorgde ook voor merkbare latentie, en levert mogelijk geen betekenisvol voordeel op. Dus als u meer gedetailleerde controle wilt, blijf dan bij de eenvoudigere create_agent methode.
Ik zeg niet dat diepe agenten slecht zijn; ze zijn krachtig in de juiste scenario’s. Dit is echter een goede herinnering aan een klassiek technisch principe: jaag niet op het “glimmende” ding. Gebruik de technologie die uw daadwerkelijke probleem oplost, ook al is dit de “minder glamoureuze” optie.
Mijn favoriete functie: gestructureerde uitvoer
Nadat agenten in de productie waren ingezet, vooral degenen die integreren met deterministische bedrijfssystemen, was het van cruciaal belang om agenten consistent de output van een specifiek schema te laten produceren.
LangChain 1.0 maakt dit vrij eenvoudig. U kunt een schema definiëren (bijvoorbeeld een Pydantic-model) en dit doorgeven create_agent via de response_format parameter. De agent produceert vervolgens uitvoer die voldoet aan dat schema binnen één agentlus zonder extra stappen.
Dit is ongelooflijk handig geweest wanneer ik de agent nodig heb om zich strikt aan een JSON-structuur te houden, waarbij bepaalde velden gegarandeerd zijn. Tot nu toe is de gestructureerde output ook zeer betrouwbaar gebleken.
Waar ik meer van wil ontdekken: Middleware
Een van de lastigste onderdelen van het bouwen van betrouwbare agenten is contexttechniek— ervoor zorgen dat de agent altijd over de juiste informatie op het juiste moment beschikt. Middleware is geïntroduceerd om ontwikkelaars nauwkeurige controle te geven over elke stap van de agentloop, en ik denk dat het de moeite waard is om er dieper in te duiken.
Middleware kan verschillende dingen betekenen, afhankelijk van de context (woordspeling bedoeld). In LangGraph kan dit betekenen dat u de exacte volgorde van de uitvoering van knooppunten moet controleren. Bij langlopende gesprekken kan het gaan om het samenvatten van de verzamelde context vóór het volgende LLM-gesprek. In human-in-the-loop-scenario’s kan middleware de uitvoering pauzeren en wachten tot een gebruiker een toolaanroep goedkeurt of afwijst.
Meer recentelijk heeft LangChain in de nieuwste kleine release v1.1 ook een middleware voor opnieuw proberen toegevoegd met configureerbare exponentiële back-off, waardoor een soepel herstel van tijdelijke eindpuntfouten mogelijk is.
Persoonlijk denk ik dat middleware een game changer is, omdat agentische workflows complexer, langduriger en stateful worden, vooral als je fijnmazige controle of robuuste foutafhandeling nodig hebt.
Deze lijst met middleware groeit en het helpt echt dat deze provideronafhankelijk blijft. Als je in je eigen werk met middleware hebt geëxperimenteerd, hoor ik graag wat je het nuttigst vond!
Om af te sluiten
Dat was het voor nu: vier belangrijke reflecties van wat ik tot nu toe over LangChain heb geleerd. En als iemand van het LangChain-team dit toevallig leest, ben ik altijd blij om op elk gewenst moment gebruikersfeedback te delen of gewoon te chatten 🙂
Veel plezier met bouwen!
