Waarom Opus 4.7 en GPT-5.5 binnen één week landen geen toeval is

Op 16 april bracht Anthropic Claude Opus 4.7 uit. Zeven dagen later volgde OpenAI met GPT-5.5. Twee frontier-modellen in één week, en als je ze naast elkaar legt valt iets op: beide labs hebben hun release-thema centraal op agentic workloads gezet. Dat is geen toeval, dat is een richting.

Laten we eerst het hele plaatje tekenen. Wat hebben deze twee releases gemeenschappelijk, en wat betekent dat voor de manier waarop je nu over AI-automatisering nadenkt?

Wat verandert er deze maand?

De headlines van beide releases lijken oppervlakkig verschillend. Opus 4.7 wijst naar verbeterde SWE-bench-scores en hogere visuele resolutie. GPT-5.5 wijst naar token-efficiëntie en lange-context-redeneren tot 1 miljoen tokens. Maar onder de oppervlakte vinden ze elkaar:

• File-system-geheugen bij Opus 4.7: agents kunnen tussen sessies door context behouden via een eigen bestandsysteem. Een proces dat maandag start kan vrijdag worden voortgezet zonder dat de context kwijt is.

• Computer use bij GPT-5.5: de modellen kunnen nu betrouwbaarder een browser, een spreadsheet of een desktop-applicatie bedienen. De agent klikt zelf op knoppen.

• 1 miljoen tokens context bij beide: agents kunnen volledige codebases, contractenpakketten of dossiers in één keer overzien zonder summarisatie-tricks.

• Betere multi-step redenering: beide modellen tonen winst op benchmarks die meerdere afhankelijke stappen vereisen. Dat is precies wat een agent moet doen.

  
  

Vorig jaar konden agents redelijk goed één ding tegelijk. Vanaf nu kunnen ze processen aansturen die over meerdere stappen en sessies lopen.

De gemeenschappelijke richting

De grote labs investeren niet meer alleen in modellen die slimme antwoorden geven. Ze investeren in modellen die dingen doen. Het verschil is fundamenteel. Een chat-model wacht op een prompt en levert tekst. Een agent ontvangt een doel en kiest zelf welke stappen nodig zijn om het te bereiken: een database raadplegen, een mail opstellen, een formulier invullen, een fout corrigeren, opnieuw proberen.

Voor het MKB betekent dat een verschuiving van "AI als hulpmiddel" naar "AI als medewerker." En dat klinkt groter dan het is. Een medewerker met beperkt mandaat, met duidelijke instructies, en altijd onder toezicht. Maar wel een die de afgeleide taken zelfstandig afhandelt.

Wat dit concreet betekent voor MKB-automatisering

Er zijn drie patronen die deze maand realistisch worden voor MKB-organisaties die hier nog niet bij stilstonden.

1. Processen die uren duren in plaats van seconden. Tot voor kort was elke AI-interactie kortlopend: prompt erin, antwoord eruit. Met file-system-geheugen en lange context kunnen agents processen draaien die over een halve dag lopen. Een offerte voorbereiden, klantdata verzamelen, achtergrondcheck doen, en eindigen met een conceptmail die jij goedkeurt. Geen mens hoeft tussendoor te wachten.

2. Agents die echte software bedienen. Computer use betekent dat een agent zelf je boekhoudsoftware kan openen, een factuur kan invoeren, en kan controleren of het bedrag overeenkomt met de purchase order. Dat is geen integratie meer via API's, dat is een agent die werkt zoals een stagiair zou werken: klikken, lezen, beslissen.

3. Multi-stap-workflows zonder pipeline-bouw. Waar je vorig jaar nog een orchestratiesysteem moest bouwen voor processen met meerdere stappen, kun je nu een model instrueren om dat zelf te plannen. Niet voor elke workflow ideaal, maar voor lange-staartcases waar pipeline-bouw te duur was, is dit de eerste keer dat het echt kan.

Wanneer wel, wanneer niet

Niet elke automatisering wordt nu een agent. Gebruik een agentische aanpak wanneer:

• Het proces vier of meer stappen heeft die elk een eigen beslissing vereisen

• Tussenresultaten gevalideerd of bijgestuurd moeten worden voor de volgende stap

• Het proces meerdere systemen aanraakt die geen goede API hebben

• De fout-tolerantie hoog is en menselijke goedkeuring een natuurlijk eindpunt is

Houd het simpel met een directe API-call wanneer:

• Het een lineair proces is dat in één LLM-aanroep past

• De integraties die je nodig hebt allemaal goede API's hebben

• Voorspelbaarheid en lage kosten belangrijker zijn dan flexibiliteit

De reden dat ik agent-architecturen niet voor alles inzet: ze zijn niet altijd voorspelbaar. Een goed agentenproces is sterk op de happy path en kwetsbaar op de randgevallen. Voor kritieke processen begin je dus altijd met een mens-in-de-loop.

Hoe je begint

1. Kies één proces dat nu drie tot vijf handmatige stappen heeft. Geen volledige automatisering, één afgebakend werkpakket.

2. Definieer het doel, niet de stappen. "Verwerk inkomende offerteaanvragen tot een klantcontract-concept" is een doel. "Klik op deze knop, dan deze, dan deze" is een stappenplan dat een traditioneel script ook aankan.

3. Begin met een agent die voorstelt, niet uitvoert. De eerste twee weken laat je de agent een actie voorstellen, jij keurt af of goed. Pas als je vertrouwen hebt in 80% van de voorstellen geef je hem uitvoer-rechten.

4. Meet wat het oplevert en wat het kost. Agents kosten meer per run dan een simpele API-call. Het rendement zit in tijdbesparing, niet in modelkosten.

Dit is de minimale versie. Als dit draait, kun je er later koppelingen met meerdere agents, automatische rapportage en feedback-loops aan toevoegen waarbij de agent leert van eerdere correcties.

Bronnen: Anthropic, Introducing Claude Opus 4.7 (april 2026); GPT-5.5 vs Claude Opus 4.7 (Codersera, 2026).