AI-assistentarchitectuur: LLM, geheugen, tools, routing, observability

Een productieve AI-assistent is niet zomaar “een LLM met een prompt”. Het is een systeem dat intentie accepteert, staat behoudt, beslist wanneer het moet ophalen of handelen, en voldoende runtime-detail blootlegt om fouten te debuggen.

Dat systeemniveau-perspectief is wat de AI Systems-cluster verkent wanneer assistenten verder gaan dan een enkele modelaanroep.

OpenAI beschrijft agents als applicaties die plannen maken, tools aanroepen, samenwerken en voldoende staat behouden voor meerstapswerk, terwijl Anthropic hetzelfde probleem framet als een beheerd harnas dat bestanden, commando’s, webtoegang en code veilig kan uitvoeren.

De schoonste architectuur splitst verantwoordelijkheden in vijf lagen: LLM, Geheugen, Tooling, Routing en Observability. Die split komt overeen met de mogelijkheden die worden blootgelegd door de APIs van grote providers, door MCP, door self-hosted runtimes zoals vLLM en llama.cpp, en door echte assistentsystemen zoals OpenClaw en Hermes.

Geheugen moet worden behandeld als meer dan “langere context”. Ophaalsystemen zetten externe kennis om in expliciete niet-parametrische geheugen — dezelfde ontwerpruimte die diep wordt behandeld in Retrieval-Augmented Generation (RAG) — en zowel de contextguidance van Anthropic als het “Lost in the Middle”-paper waarschuwen dat het simpelweg meer tokens in de context proppen geen betrouwbare herinnering garandeert.

Toolgebruik is een contractgrens, geen magie. OpenAI function calling, Anthropic tool use en MCP vertrouwen allemaal op hetzelfde patroon: het model zendt een gestructureerd verzoek uit, een runtime voert het uit, en het resultaat stroomt terug in het gesprek. Als die grens slordig is, wordt de assistent slordig.

Mijn voorkeur is simpel: begin saai. Eén orchestrator, één duurzaam geheugenpad, één trace per verzoek en één expliciete beleid voor tooluitvoering. Multi-agent grafen zijn nuttig, maar pas nadat je je single-agent falingsgevallen kunt uitleggen zonder te raden.

Wat een AI-assistentsysteem is

Een praktische definitie is dit: een AI-assistentsysteem is een runtime die gebruikersintentie omzet in een antwoord of actie door een modelinterface, contextassemblage, tooluitvoering, staatbeheer en telemetrie te combineren. Daarom zijn de nuttige documenten niet alleen modelcards. De nuttige documenten zijn API-referenties, toolcontracten, ophaalgidsen, routingdocumenten en tracingdocumenten. De Responses API van OpenAI exposeert stateful interacties, ingebouwde tools en function calling. De Claude API van Anthropic exposeert directe Messages-toegang evenals Managed Agents. OpenClaw en Hermes gaan een stap verder en tonen wat er gebeurt wanneer je die mogelijkheden plaatst achter persistente gateways, kanalen, sessies en geheugen.

Met andere woorden, een assistentsysteem heeft een bredere contract dan een chat-completion. Een goed intern contract ziet er ongeveer zo uit:

AssistantRequest  = gebruikersintentie + identiteit + sessie + bijlagen + beleid
AssistantResponse = antwoord + acties + citaten + staatveranderingen + trace-id

Dat contract is belangrijk omdat elk productieongenemerkt uiteindelijk terugkomt op een van deze vragen: welke context was zichtbaar, welke tool is uitgevoerd, welk model heeft geantwoord, welk geheugen is gelezen of geschreven, en waar de trace aangeeft dat het systeem tijd heeft besteed. OpenTelemetry definieert traces als het pad van een verzoek door een applicatie, wat precies de abstractie is die serieuze assistenten nodig hebben. LangSmith en OpenLIT specialiseren dat idee vervolgens voor LLMs, tools, vectorstores en agentworkflows.

Kerncomponenten en interfaces

De componentensplitsing hieronder is de een die ik het meest duurzaam vind. Het is ook de splitsing die het beste aansluit bij de officiële APIs en de open-source runtimes die mensen daadwerkelijk exploiteren.

De bovenstaande tabel is afgeleid van de officiële providerinterfaces, MCP, vectordatabasedocumenten en de runtime-documenten voor vLLM, llama.cpp, OpenClaw en Hermes.

De LLM-laag moet drie dingen goed doen: een huidige werkcontext consumeren, ofwel een definitief antwoord of een gestructureerd actieverzoek uitzenden, en voldoende metadata teruggeven om retries en tracing te ondersteunen. De Responses API van OpenAI is expliciet ontworpen voor stateful interacties plus ingebouwde tools en function calling. De Messages API van Anthropic exposeert dezelfde kernlus via tool_use-blokken en tool_result-returns, terwijl Managed Agents je een gehoste harnas geeft als je de lus niet zelf wilt bouwen. Self-hosted runtimes zoals vLLM en llama.cpp zijn belangrijk omdat ze bekende provider-stijl interfaces behouden terwijl ze je in staat stellen inferentie binnen je eigen omgeving te plaatsen.

De Geheugelaag moet mentaal worden gesplitst in drie buckets: werkgeheugen, duurzaam symbolisch geheugen en doorzoekbaar semantisch geheugen. OpenAI embeddings returnen vectoren die kunnen worden geïndexeerd en doorzocht; OpenAI Retrieval en File Search leggen semantische en keyword-search er dan weer bovenop van vectorstores. Pinecone, Weaviate, pgvector en Milvus vertegenwoordigen vier veelvoorkomende opslagvormen: volledig beheerd, open-source vector-native, Postgres-native en gedistribueerde vectordatabase. Hermes en OpenClaw voegen een nuttige herinnering toe dat niet al geheugen in een vectorstore hoort: bestand-gestandaardiseerde notities, beoordeelde promoties en sessie-gebonden snapshots zijn vaak het eerlijkere ontwerp. Memory Systems in AI Assistants mapt het cross-framework model; Hermes Agent Memory System ontrafelt gebonden kerngeheugen en bevroren sessiesnapshots in één product.

De Tooling-laag is waar een assistent stopt met een samenvatting te zijn en begint als software. OpenAI function calling behandelt tools als schema-gedefinieerde functionaliteit die het model kan besluiten aan te roepen. Anthropic zegt hetzelfde explicieter: toolgebruik is een contract tussen je applicatie en het model, en het model voert nooit iets zelfstandig uit. MCP generaliseert dat contract tot een client-server protocol waarbij hosts verbinden met één of meer servers die tools, prompts en resources blootleggen — dezelfde grens die stap voor stap wordt beschreven in MCP Server in Go. LangChain en LlamaIndex passen hier goed als orchestratiebibliotheken: LangChain focust op een vooraf gebouwde agentarchitectuur en integraties, terwijl LlamaIndex focust op context-augmented data-toegang, query-engines en workflows.

De Routinglaag bestaat omdat “welk model?” nooit de enige vraag is. Je hebt ook nodig “welk providerpad, welke tenant, welke budget, welke latentieklass, en welke fallback?”. LiteLLM is nuttig omdat zijn officiële documenten verfrissend concreet zijn: gewogen pick, minst-bezette, latentie-gebaseerde, kosten-gebaseerde routing en gebonden failovers zijn allemaal first-class patronen. OpenClaw breidt routing uit naar kanaal- en agentisolatie, terwijl Hermes het uitbreidt naar modelslots voor hoofd- en hulpproces zoals samenvatting, contextcompressie en MCP-toolrouting. Dat is het juiste mentale model: de router kiest meer dan een model, het kiest een uitvoeringsbaan.

De Observability-laag is wat voorkomt dat architectuur in folklore verandert. OpenTelemetry geeft je de trace-abstractie. LangSmith geeft je end-to-end zichtbaarheid over LLM-applicatiestappen en ondersteunt cloud, hybride en self-hosted deployment-vormen. OpenLIT geeft je OpenTelemetry-native AI observability met zero-code en handmatige instrumentatie-opties, inclusief ondersteuning voor LLMs, agentframeworks, vectordatabases en GPUs. Voor productiemetrics, traces en SLO-patronen over inferentie en agentworkflows, zie Observability for LLM Systems. Als je assistent geen trace per verzoek heeft, geen span per modelcall, en geen gebeurtenisgeschiedenis voor tooluitvoering, heb je nog geen echte architectuur. Je hebt vibes.

Vangen, verrijken, reageren

De sequentie die steeds terugkomt in echte systemen is vangen -> verrijken -> reageren -> vastleggen. Verschillende frameworks wikkelen het anders, maar de flow is stabiel genoeg om als ruggengraat te behandelen.

De vangen-stap is meestal belangrijker dan het eruit ziet. OpenClaw en Hermes plaatsen beide een persistente gateway voor de assistent omdat ingress niet alleen tekst invoer is. Het omvat kanaalmetadata, identiteiten, autorisatie, sessiegrenzen, directe berichten, groepen, cron-ticks en delivery-semantiek. Als je die laag overslaat en vertrouwt op een ruwe chat-widgetabstractie, zal je het uiteindelijk toch als ad hoc middleware terugplaatsen.

De verrijken-stap is waar volwassen systemen afwijken van toy demos. OpenAI Retrieval en File Search maken ophalen expliciet via vectorstores en search-calls. LlamaIndex formaliseert hetzelfde patroon via dataconnectoren, indexes, query-engines en workflows. Hermes gaat verder door het modelpark op te splitsen in hoofd- en hulpslots, en werk zoals compressie, samenvatting en routing af te lasten op kleinere of gespecialiseerde modellen. Dat is een ontwerppatroon dat het waard is te stelen: besteed je meest dure modeltokens niet aan karweiwerk.

De reageren-stap is niet “tekst genereren”. Het is “de huidige lus sluiten”. Als het model direct kan antwoorden, doet het dat. Als het een tool nodig heeft, zendt het een gestructureerd verzoek uit. Het toolgebruikcontract van Anthropic en de function-calling guide van OpenAI maken dit beide expliciet. De reden waarom dit architectonisch belangrijk is, is dat outputs nu zowel taal als control flow omvatten. Je response-object is deels proza en deels runtime-plan.

De vastleggen-stap is waar consistentiesemantiek naar boven komt. Pinecone scheidt schrijf- en leespaden en verwerkt schrijvers na duurzame bevestiging. Hermes-geheugen wordt geïnjecteerd als een bevroren snapshot per sessie zodat het prefix-cache-prestaties kan behouden, wat betekent dat nieuwe schrijvers niet automatisch verschijnen in de huidige sessieprompt. OpenClaw’s Dreaming-systeem promoot alleen beoordeelde, onderbouwde kandidaten naar MEMORY.md, en het is opt-in in plaats van altijd-aan. De praktische les is dat geheugen zelden echt read-after-write is over elke laag. Je moet ontwerpen voor gestaffelde zichtbaarheid.

OpenClaw en Hermes als referentiesystemen

OpenClaw en Hermes zijn nuttige referentiegeval omdat ze niet zomaar wrappers zijn rond één provider API. Beide presenteren een assistent als een langlopend systeem met gateways, sessies, tools, geheugen en meerdere modelbackends.

Deze mapping is gebaseerd op de officiële OpenClaw en Hermes documenten en repos. OpenClaw documenteert een gatewayarchitectuur, multi-agent routing, ondersteuning voor aangepaste en self-hosted providers inclusief vLLM en Ollama, optioneel actief geheugen en Dreaming-gebaseerde promotie. Hermes documenteert een messaging gateway, een centrale AIAgent-lus, hoofd- en hulpslots, ingebouwd geheugen en native MCP-integratie.

Mijn iets opinielozere lezing is dat beide systemen hetzelfde architecturale argument maken in verschillende accenten. OpenClaw is sterk gateway-first. Hermes is sterk agent-loop-first. Maar beide verwerpen het oppervlakkige idee dat een assistent zomaar “prompt plus model” is. Ze modelleren kanalen, identiteiten, geheugensemantiek, tooloppervlakken en backend-heterogeniteit als first-class zorgen. Dat is precies wat een productiearchitectuur moet doen.

Een praktische hybride stack geïnspireerd door beide systemen ziet er zo uit:

edge:
  gateway: hermes of openclaw

routing:
  proxy: litellm
  policy: latentie- en budgetbewust
  tenancy: sessie- en kanaalgebonden

llm:
  primary: openai responses of anthropic messages
  local_fallback: vllm
  local_dev: ollama of llama.cpp

memory:
  session: sqlite of postgres
  semantic: pgvector of weaviate
  embeddings: openai embeddings of ollama embeddings

tools:
  contract: json schema tools plus mcp
  examples: bestandssysteem, browser, websearch, interne APIs

observability:
  traces: opentelemetry
  ai_dashboards: openlit of langsmith
  evals: openai evals plus app-specifieke regressiesets

Die stack is een redeneerd deploymentpatroon in plaats van een vendor-voorschrift blauwdruk. Het werkt omdat de officiële interfaces aansluiten: OpenAI en Anthropic blootleggen tool-gerichte APIs, vLLM en llama.cpp emuleren provider-stijl endpoints, Ollama hanteert lokale modellen en embeddings, MCP standaardiseert externe tools, LiteLLM hanteert routing en failover, en OpenTelemetry-compatibele platforms kunnen het hele pad traceren.

Patronen, tabellen en afwegingen

Er zijn een paar herhaalbare assistentpatronen die de moeite waard zijn om te benoemen. Een beheerde assistent houdt de meeste runtime binnen provider APIs. Een retrieval-first assistent behandelt geheugen en search als de belangrijkste differentiator. Een tool-first assistent gedraagt zich meer als een operator dan als een chatbot. Een gateway assistent prioriteert altijd-toegang via messaging oppervlakken. Een specialisten mesh deelt werk op in meerdere agents of routes. Officiële documenten van OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw en Hermes ondersteunen allemaal versies van deze patronen, zelfs als ze ze anders noemen.

Het specialisten mesh-patroon groeit uit tot een distinct engineering discipline naarmate het aantal agents stijgt. Voor de zes canonieke coördinatiepatronen — orchestrator-werker, sequentiële pipeline, fan-out, hiërarchisch, zwerm en mesh — met specifieke falingsmodi en een productiebenissingsraamwerk, zie Multi-Agent Orchestration Patterns.

Deze patrontabel is een synthese van de providerdocumenten, frameworkdocumenten en referentiesystemen in plaats van een claim van één vendor.

Tabelnotities: OpenAI gehoste File Search is een beheerde tool, Anthropic biedt een beheerd harnas, Pinecone is een beheerde vectorservice, terwijl vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, LangSmith self-hosted en OpenLIT allemaal self-managed of hybride exploitatie ondersteunen in verschillende mate.

Tabelnotities: Pinecone documenteert een beheerd controlepaneel en regionale dataplane. Weaviate documenteert vector- en omgekeerde indexes met meerdere vectortypen. pgvector voegt exacte en benaderde nearest-neighbour search toe aan Postgres. Milvus positioneert zich als een open-source high-performance, schaalbare vectordatabase, met Zilliz Cloud als de beheerde optie.

Tabelnotities: OpenAI documenteert Responses als zijn geavanceerde interface voor stateful responses en ingebouwde tools. Anthropic documenteert de Messages API en het toolgebruikcontract apart van Managed Agents. vLLM exposeert een OpenAI-compatibele server plus Anthropic Messages API-ondersteuning. Ollama documenteert lokale embedding- en modelworkflows. llama.cpp documenteert OpenAI-compatibele chat, responses en embeddings routes, plus Anthropic-compatibele chat completions.

Deze afwegingsmatrix is een architecturale afleiding van de officiële documenten, geen vendor benchmark. De consistentierij is belangrijker dan veel blogposts toegeven: Pinecone scheidt schrijf- en leespaden, Hermes bevriest geheugen in sessie-start prompts, en OpenClaw promoot duurzaam geheugen via gestaffelde review. Dat betekent dat “geheugen bijgewerkt” en “geheugen zichtbaar voor het huidige antwoord” vaak verschillende waarheden zijn.

Falingsmodi en mitigaties

De meeste assistenten falen niet omdat het basismodel “slecht” is. Ze falen omdat het omringende systeem het model liegt, het de juiste context ontbeert, tools laat afwijken, of debuggen onmogelijk maakt.

Het bewijsbasis voor deze tabel is breed maar consistent. Anthropic’s tooldocumenten maken duidelijk dat toolgebruik een contractgrens is. OpenAI Guardrails omvat hallucinatiedetectie tegen een referentiekennisbank via File Search. SelfCheckGPT toont aan dat self-consistency over samples kan helpen bij het detecteren van niet-ondersteunde claims. De “Lost in the Middle” resultaten en Anthropic’s contextguidance versterken beide dezelfde operationele les: meer tokens verwijderen niet de behoefte aan contextcuratie.

De voorkeersmitigatiestack zou saai en repetitief kunnen zijn: trace elk verzoek, versioneer prompts, evalueer ophalen onafhankelijk, houd tools idempotent, en voer regressie-evals uit voordat je routes of geheugenbeleid verandert. OpenAI’s Evals documenten en repo zijn blunt over waarom: zonder evals is het moeilijk en tijdrovend om te begrijpen hoe model- of promptveranderingen je use case beïnvloeden. Dat geldt net zo goed voor routers en ophalen als voor prompts.

Meer lezen

Als je dieper wilt gaan, zijn dit de meest nuttige primaire bronnen om open te houden tijdens het ontwerpen of reviewen van een assistentarchitectuur.

• OpenAI: Responses Overzicht, Function Calling, Tools Gebruiken, Retrieval, File Search, Evals en MCP voor remote tool servers.

• Anthropic: API Overzicht, Tool Use, het toolgebruikcontract, Managed Agents, Context Windows en de MCP connector.

• MCP zelf: het Architecture Overzicht en Specificatie zijn het waard om direct te lezen, omdat ze hosts, clients, servers, tools, prompts, resources, transports en capaciteitsonderhandeling helder uitleggen. Voor een praktische vergelijking van MCP met het Agent2Agent protocol en wanneer een multi-agentsysteem beide lagen nodig heeft, zie A2A vs MCP: Do AI Agents Really Need Both Protocols? en voor de A2A concepten zelf — Agent Cards, taaklevenscyclus, berichten, delen en artefacten — zie What Is the A2A Protocol? Agent Cards and Tasks Explained.

• Achtergrond en proactieve assistenten: de toolinglaag is slechts één deel van hoe assistenten handelen. Voor hoe je een assistent laat kijken, beslissen en zelfstandig handelen — schedulers, queue-based workers, claim protocollen, duurzame workflows en semantisch polling — zie Polling Agents in AI Assistants: 11 Implementation Patterns.

• A2A protocol en adoptie: zodra agents onafhankelijk worden deployed en moeten samenwerken over eigenaarschapsgrenzen, wordt A2A relevant. Voor een praktisch 2026 overzicht van waar A2A daadwerkelijk tractie heeft, de beveiligingsvragen die het opwerpt, en een beslissingsraamwerk voor wanneer het te adopteren, zie Google A2A Protocol in 2026: Adoption, Hype, and Reality. Wanneer die agents langlopende taken uitwisselen in plaats van enkele chat turns, A2A Streaming and Async Tasks for Long-Running Agent Workflows dekt SSE, push en input_required ontwerp aan de protocolgrens.

• Frameworks en routing: LangChain Overzicht, LlamaIndex context-augmentation documenten, LiteLLM routing documenten, LangSmith observability documenten.

• Self-hosted runtimes en assistentsystemen: vLLM, llama.cpp server, Ollama embeddings, OpenClaw documenten en repo, Hermes documenten en repo.

• Opslag en observability: Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.

• Onderzoeksartikelen: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lost in the Middle, en SelfCheckGPT.