𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗪𝗶𝗻𝗱𝗼𝘄𝘀 𝗔𝗿𝗲 𝗚𝗲𝘁𝘁𝗶𝗻𝗴 𝗛𝘂𝗴𝗲

People use the word agent for everything.

A function that calls a tool is an agent. A chatbot with memory is an agent. A script with a loop is an agent.

This mistake leads to bad engineering. Teams over-engineer simple tasks and under-engineer complex ones. I see teams spend weeks on agent orchestration for workflows that only need one good prompt.

Here is my definition of a real agent.

An agent has an objective. It does not just follow instructions. It decides what to do next. It handles failure. It knows when to stop.

Use these benchmarks:

• If a human must guide every step, it is a chat interface.
• If the system recovers from a failed tool call, it is moving toward an agent.
• If the system breaks a goal into tasks and delegates them, it is a real agent.

Most successful agents are narrow. They do one job well. They handle customer support triage or document extraction. They are not general reasoning engines.

Successful teams focus on these three things:

• Tool design: How clean is the interface?
• Failure handling: What happens when a tool returns nothing?
• Observability: Can you trace why the agent made a decision?

Unsuccessful teams just swap one model for a newer one and expect better results. They ignore the system design.

Frameworks like LangChain or CrewAI change every month. The framework matters less than the pattern.

Use these patterns:

• Plan then execute: Separate the reasoning step from the execution step.
• Separate retrieval from reasoning: Fetching context is a different job than using it.
• Explicit handoffs: Use structured logs when one agent passes work to another.

The framework is just scaffolding. The architecture is the building.

RAG is standard, but chunking is often broken. If you split documents poorly, the model loses context. This leads to hallucinations.

If your RAG results are useless, check your chunking and metadata. The model is rarely the problem.

Models will get better. Context windows will grow. Token costs will drop.

None of that solves the real engineering challenge. You must build systems that behave correctly when you are not watching.

Focus on governance, observability, and reliable tool use. The best engineers will not be model researchers. They will be systems designers who build reliable AI.

Contextvensters worden gigantisch: dit is waarom dat alles verandert

De wereld van Large Language Models (LLM's) beweegt zich in een razendsnel tempo. Een van de meest opvallende trends van de afgelopen tijd is de explosieve groei van contextvensters. Waar we een jaar geleden nog spraken over vensters van een paar duizend tokens, praten we nu over modellen die miljoenen tokens kunnen verwerken.

Maar wat betekent dit voor de manier waarop we AI gebruiken? En is een gigantisch contextvenster de "killer feature" die RAG (Retrieval-Augmented Generation) overbodig maakt?

Wat is een contextvenster?

In eenvoudige bewoordingen is het contextvenster het "werkgeheugen" van een LLM. Het is de hoeveelheid informatie die het model tegelijkertijd kan "zien" en verwerken tijdens een interactie. Alles wat je in de prompt plaatst — de instructies, de geschiedenis van het gesprek, de aangeleverde documenten — telt mee voor het totaal aantal tokens in het contextvenster.

Als het venster te klein is, "vergeet" het model het begin van het gesprek of kan het geen grote documenten in één keer analyseren.

De evolutie: van duizenden naar miljoenen

Laten we eens kijken naar de snelheid van deze ontwikkeling:

• Vroege modellen (zoals GPT-3): Contextvensters van ongeveer 2.048 tot 4.096 tokens. Dit was genoeg voor een paar pagina's tekst.
• De volgende generatie (GPT-4, Claude 2): Vensters van 32k tot 128k tokens. Hiermee kun je hele boeken of uitgebreide documentatie uploaden.
• De huidige grensreizigers (Gemini 1.5 Pro, Claude 3): Vensters van 200k tot wel 2 miljoen tokens. Dit stelt je in staat om volledige codebases, uren aan video of duizenden pagina's aan tekst in één keer te verwerken.

RAG vs. Long Context: De grote discussie

Met de komst van enorme contextvensters ontstond er een debat in de AI-community: hebben we nog wel RAG nodig?

Retrieval-Augmented Generation (RAG)

RAG werkt door een externe database te doorzoeken naar de meest relevante stukjes informatie en deze vervolgens in het contextvenster van het model te plaatsen.

Voordelen:

• Kostenefficiënt: Je stuurt alleen de relevante informatie naar het model, wat tokens bespaart.
• Snelheid: Minder tokens betekent snellere inferentie en lagere latentie.
• Actualiteit: Je kunt eenvoudig nieuwe informatie toevoegen aan je database zonder het model opnieuw te trainen.

Nadelen:

• Contextverlies: De zoekmachine (retriever) kan cruciale informatie missen die niet direct lijkt op de zoekopdracht.
• Fragmentatie: Informatie wordt in kleine stukjes gehakt, waardoor de globale structuur of de nuance van een document verloren kan gaan.

Long Context

Bij de "Long Context"-benadering stop je simpelweg de volledige dataset in het contextvenster van het model.

Voordelen:

• Holistisch begrip: Het model heeft toegang tot de volledige context, inclusief subtiele verbanden tussen verschillende delen van de data.
• Eenvoud: Geen complexe RAG-pijplijnen of vector-databases nodig.

Nadelen:

• Kosten: Het verwerken van miljoenen tokens per prompt is extreem duur.
• Latentie: Hoe meer tokens, hoe langer het duurt voordat het model begint met antwoorden.
• "Lost in the middle": Onderzoek heeft aangetoond dat veel modellen moeite hebben om informatie te onthouden die zich in het midden van een zeer groot contextvenster bevindt.

De "Needle in a Haystack" test

Om de effectiviteit van grote contextvensters te testen, gebruiken ontwikkelaars vaak de "needle in a haystack"-test. Hierbij wordt een willekeurige, ongerelateerde zin (de naald) verstopt in een enorme berg tekst (de hooiberg). Het model krijgt vervolgens de opdracht om die specifieke zin te vinden.

Hoewel moderne modellen zoals Gemini 1.5 Pro indrukwekkende scores halen, blijft het een uitdaging om consistent te blijven naarmate de "hooiberg" groter wordt.

Waarom dit alles verandert

De verschuiving naar grotere contextvensters verandert de rol van de AI-ontwikkelaar. We gaan van het bouwen van complexe systemen die informatie moeten "zoeken", naar systemen die informatie kunnen "begrijpen".

1. Agentic Workflows: AI-agenten kunnen nu hele projecten overzien, hun eigen code lezen en complexe taken uitvoeren die een diep begrip van de volledige omgeving vereisen.
2. Nieuwe Use Cases: Denk aan het analyseren van volledige juridische dossiers, het debuggen van enorme softwareprojecten of het begrijpen van de volledige geschiedenis van een bedrijf op basis van duizenden e-mails.
3. De dood van de "chunking" obsessie: Voorheen was het optimaliseren van hoe je tekst in stukjes (chunks) hakt voor RAG de belangrijkste taak. Met enorme vensters verschuift de focus naar de kwaliteit van de input en de instructies.

Conclusie

Grote contextvensters zullen RAG niet direct vervangen, maar ze veranderen de verhoudingen. De toekomst ligt waarschijnlijk in een hybride aanpak: RAG voor snelle, goedkope toegang tot enorme hoeveelheden data, en Long Context voor diepgaande analyse en complexe redeneringen waarbij de volledige context essentieel is.

De grens van wat mogelijk is met AI wordt niet langer bepaald door hoeveel de AI kan "onthouden", maar door hoeveel informatie wij in staat zijn om effectief aan de AI te presenteren.