De agentcloud begint niet bij je model, maar bij je controlelaag

De demo-agent is niet het probleem

Een agent-demo werkend krijgen is voor veel AI-teams niet meer het spannendste deel. Je kiest een model, koppelt een tool, laat de agent een taak uitvoeren en ziet snel waar de belofte zit. Het probleem ontstaat pas zodra zo’n agent niet meer in een veilige testomgeving draait, maar onderdeel wordt van echt bedrijfswerk. Dan gaat het niet alleen over de vraag of de agent een goede suggestie doet. Dan gaat het over wie toegang heeft, welke data gebruikt mag worden, welke acties worden gelogd, hoe kosten worden begrensd en hoe je voorkomt dat waardevolle workflowkennis opgesloten raakt in één interface.

Precies daar wordt de discussie rond een agentcloud interessant. Niet als modieuze term voor ‘nog een AI-platform’, maar als denkraam voor de laag boven losse agents. AI-teams gebruiken nu vaak verschillende omgevingen naast elkaar: coding agents, interne tools, custom workflows en experimentele interfaces. Dat kan prima zijn in de testfase. In productie ontstaat echter de vraag wie het overzicht houdt over sessies, rechten, context, beveiliging en kosten. De modelkeuze blijft belangrijk, maar de beheerslaag bepaalt of het geheel bestuurbaar wordt.

De nuchtere les voor AI-leads en platformteams: beoordeel agentstrategie niet alleen op outputkwaliteit. Kijk ook naar de infrastructuur eromheen. Een agent die vandaag indrukwekkend lijkt, kan morgen lastig te beheren zijn als sessies niet overdraagbaar zijn, beslissporen verdwijnen of data-toegang per tool opnieuw moet worden ingericht.

Wat een agentcloud in de praktijk kan betekenen

Databricks positioneert zich met de term agentcloud nadrukkelijk voorbij alleen dataopslag of traditionele analytics. De relevante richting is een data-en-AI-besturingslaag waarin agents, databases, open formats en governance dichter bij elkaar komen. Daarbij wordt Omnigent gepositioneerd als een open-source meta-harness: een laag boven verschillende agentomgevingen zoals coding agents, custom agents en interne tools. Het idee is niet dat één agent alle andere vervangt, maar dat organisaties een gemeenschappelijke manier nodig kunnen hebben om verschillende agentharnesses te combineren, controleren en delen.

Dat onderscheid is belangrijk. Veel organisaties zoeken nog naar ‘de beste agent’. Een platformblik stelt een andere vraag: hoe voorkom je dat elke agent zijn eigen geschiedenis, rechtenmodel, kostenlogica en integratiepatroon meeneemt? Als iedere tool zijn eigen kleine wereld wordt, groeit de complexiteit snel. Teams krijgen dan niet één AI-roadmap, maar een verzameling losse experimenten die moeilijk te herhalen, beveiligen en opschalen zijn.

Een meta-harness of controlelaag kan in zo’n situatie dienen als de plek waar samenwerking, sessiegeschiedenis, portabiliteit, beveiliging, spend controls en een gemeenschappelijke API samenkomen. Dat is geen bewijs dat één vendorbenadering de marktstandaard wordt. Het is wel een bruikbaar signaal voor de volwassenheidsvraag: als agents meer bedrijfswerk uitvoeren, moeten AI-teams bepalen welke onderdelen ze per tool accepteren en welke onderdelen ze centraal willen organiseren.

Waarom agents een controlelaag nodig hebben

De eerste reden is portabiliteit. Een agentworkflow bevat vaak meer dan alleen een prompt. Er zit context in, toolconfiguratie, bestanden, tussenstappen, beslislogica en soms domeinkennis van medewerkers. Als die workflow alleen binnen één specifieke agentinterface bruikbaar is, wordt overstappen of combineren lastiger. Voor platformteams is daarom de vraag: kunnen we workflows, context en evaluaties hergebruiken als we een andere agent, ander model of andere tool kiezen?

De tweede reden is samenwerking. Agents worden vaak individueel getest, maar productiegebruik is meestal teamwerk. Een developer, data-engineer, securityspecialist en proceseigenaar kunnen allemaal een ander deel van dezelfde workflow raken. Zonder gedeelde sessiegeschiedenis of duidelijk beslisspoor wordt het moeilijk om te begrijpen wat de agent heeft gedaan, waarom een bepaalde route is gekozen en waar een fout is ontstaan. Samenwerking vraagt dus om meer dan chatgeschiedenis; het vraagt om reproduceerbare context.

De derde reden is security. Zodra agents tools mogen aanroepen, bestanden mogen lezen of wijzigingen mogen voorstellen, wordt rechtenbeheer cruciaal. Een controlelaag moet helpen bepalen welke agent welke actie mag uitvoeren, namens wie, onder welke voorwaarden en met welke logging. Dat hoeft niet te betekenen dat elke agent volledig autonoom mag handelen. Juist begrenzing maakt productiegebruik realistischer: sommige taken mogen automatisch, andere alleen na menselijke goedkeuring.

De vierde reden is kostenbeheersing. Agents kunnen meerdere stappen uitvoeren, itereren, tools aanroepen en context verwerken. Daardoor is het verstandig om spend controls niet pas achteraf te bekijken. Platformteams hebben vooraf grenzen nodig: per workflow, team, omgeving of taaktype. Kostencontrole is geen rem op innovatie; het is een voorwaarde om experimenten te kunnen blijven doen zonder dat onduidelijk wordt waar verbruik ontstaat.

De vijfde reden is een gemeenschappelijke API boven losse harnesses. Als elk team eigen integraties bouwt, ontstaat technische schuld op precies de laag waar later snelheid nodig is. Een gedeelde interface kan helpen om agents op een voorspelbare manier te koppelen aan interne systemen, databases, logging, autorisatie en monitoring. Daarmee verschuift de waarde van losse experimenten naar een platform dat geleerd gedrag en operationele controle vasthoudt.

Databases worden strategisch, maar niet op de oude manier

In agentdiscussies gaat veel aandacht naar modellen en interfaces. Toch kan de datalaag voor productiegebruik minstens zo bepalend zijn. Databricks koppelt de agentcloud-richting aan onderwerpen als Lakebase, LTAP, open formats en Mosaic. Op hoofdlijnen wijst dat naar een wereld waarin agents niet los boven de organisatie zweven, maar dicht op data-operaties, opslagkeuzes en formatkeuzes komen te liggen.

Dat betekent niet dat databases ineens ‘alles’ oplossen. Het betekent wel dat agentwerk afhankelijk is van betrouwbare, gecontroleerde toegang tot data. Een agent die een taak uitvoert, moet weten welke data actueel is, welke bron gebruikt mag worden, welke wijziging toegestaan is en welke context nodig is om een actie te begrijpen. Als die datalaag rommelig is, wordt de agentlaag kwetsbaar. Niet omdat het model per se slecht is, maar omdat het fundament voor beslissingen onduidelijk is.

Open formats zijn in dat kader interessant omdat ze kunnen helpen om afhankelijkheid van één interface te beperken. Voor AI-teams is de praktische vraag niet of elk systeem volledig open moet zijn. De vraag is welke onderdelen van de workflow je later nog wilt kunnen meenemen: datarepresentaties, evaluaties, sessiehistorie, tooldefinities, logging en domeincontext. Hoe meer daarvan alleen binnen één gesloten laag leeft, hoe moeilijker portabiliteit wordt.

LTAP en Lakebase hoeven in een AI-roadmap niet als losse productnamen centraal te staan. Ze zijn vooral nuttig als haakjes voor het grotere punt: agents die echt werk doen, raken transactionele processen, analytische vragen en operationele data tegelijk. Dan moet je nadenken over consistentie, snelheid, rechten en auditability. De databasekeuze wordt daarmee minder een achtergrondbeslissing en meer een onderdeel van de agentarchitectuur.

Checklist voor AI-teams die verder willen dan experimenten

Begin met een inventarisatie van de agentharnesses die al in gebruik zijn. Welke teams gebruiken coding agents? Welke teams bouwen custom agents? Welke interne tools worden gekoppeld? Noteer niet alleen de namen van tools, maar vooral welke context, sessies en workflows erin ontstaan. Vaak zit de echte waarde niet in de tool zelf, maar in de manier waarop medewerkers ermee leren werken.

Vraag daarna waar sessiegeschiedenis en beslissporen worden bewaard. Kun je achteraf reconstrueren welke data is gebruikt, welke tool is aangeroepen en welke stap door een mens is goedgekeurd? Als dat niet kan, is productiegebruik moeilijker te verdedigen richting security, compliance of proceseigenaren. Logging moet niet voelen als administratieve ballast, maar als het geheugen van je agentplatform.

Controleer vervolgens het rechtenmodel. Welke acties mogen agents uitvoeren? Welke acties mogen ze alleen voorstellen? Welke systemen zijn read-only en waar mag een agent schrijven? Maak dit expliciet per workflow. Een generieke ‘agent mag bij alle data’-aanpak is zelden verstandig. Een bruikbare controlelaag maakt rechten fijnmazig genoeg om risico’s te beperken, zonder elke workflow handmatig te blokkeren.

Leg ook kostenlimieten vast. Niet alleen op totaalbudget, maar op het niveau waarop teams sturen: per agenttype, omgeving, workflow of project. Zo voorkom je dat experimenten onbedoeld operationele kosten worden zonder eigenaar. Kostenbeheersing hoort thuis in hetzelfde gesprek als security en logging, omdat alle drie bepalen of agents bestuurbaar blijven.

Tot slot: bepaal welke onderdelen eigen platform-IP zijn. Een prompt is meestal niet genoeg. Denk aan evaluaties, datasets, workflowpatronen, integraties, autorisatieregels en domeinspecifieke beslislogica. Als je die laag bewust opbouwt, wordt de organisatie minder afhankelijk van de grillen van één agentinterface. Dat maakt je AI-roadmap niet automatisch eenvoudig, maar wel beter bestuurbaar.

Kies niet alleen een agent, ontwerp de laag erboven

De kern is simpel: agents worden pas interessant voor bedrijfsprocessen als ze betrouwbaar binnen grenzen kunnen werken. Dat vraagt om controle over context, data, rechten, kosten en samenwerking. Wie alleen modelreleases volgt, mist de operationele laag waar AI-experimenten wel of niet volwassen worden.

Voor AI-teams is een houdbare agentstrategie daarom geen keuze tussen één model of één interface. Het is een architectuurbesluit: welke controlelaag bouwen of kiezen we boven onze agents, en welke data- en platformkeuzes maken we daarbij bewust? Databricks geeft met Omnigent, Lakebase, LTAP, open formats en Mosaic een duidelijke productrichting aan. De bredere les is vendor-onafhankelijk: behandel agents niet als losse slimme schermen, maar als onderdeel van een bestuurbaar systeem.

Mijn advies als Funnel Adviseur: begin klein, maar ontwerp alsof hergebruik later belangrijk wordt. Leg vast waar context leeft, wie rechten beheert, hoe kosten worden bewaakt en hoe data veilig beschikbaar komt. Dan bouw je geen verzameling demo’s, maar een fundament waarop agents stap voor stap verantwoord meer werk kunnen ondersteunen.