AI-assistent-architectuur: LLM, geheugen, tools, routing, observability

Een productie-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-details blootlegt om fouten te debuggen.

Dat systeemniveau-perspectief is wat de AI-systemen-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 beschrijft als een beheerd harnas dat bestanden, commando’s, webtoegang en code op een veilige manier kan uitvoeren.

De cleanste architectuur verdeelt verantwoordelijkheden in vijf lagen: LLM, Geheugen, Tooling, Routing en Observability. Deze splitsing sluit aan bij de mogelijkheden die worden blootgelegd door de APIs van grote providers, door MCP, door zelfgehoste runtimes zoals vLLM en llama.cpp, en door echte assistentsystemen zoals OpenClaw en Hermes.

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

Gebruik van tools is een contractgrens, geen magie. OpenAI function calling, Anthropic tool use en MCP vertrouwen allemaal op hetzelfde patroon: het model emiteert een gestructureerde aanvraag, een runtime voert deze uit en het resultaat stroomt terug in het gesprek. Als die grens losjes is, wordt de assistent losjes.

Mijn voorkeur is simpel: begin saai. Eén orchestrator, één duurzaam geheugenpad, één trace per request en één expliciete policy voor tool-uitvoering. Multi-agent grafen zijn nuttig, maar pas nadat je je single-agent failure cases kunt uitleggen zonder te raden.

Wat een AI-assistent systeem is

Een praktische definitie is dit: een AI-assistent systeem is een runtime die gebruikersintentie omzet in een antwoord of actie door een modelinterface, contextassemblage, tool-uitvoering, state management en telemetrie te combineren. Daarom zijn de nuttige documenten niet alleen modelcards. De nuttige documenten zijn API-referenties, tool-contracten, retrieval-gidsen, routing-documentatie en tracing-documentatie. OpenAI’s Responses API blootlegt stateful interacties, ingebouwde tools en function calling. Anthropic’s Claude API blootlegt 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 + attachments + policy
AssistantResponse = antwoord + acties + citaten + state wijzigingen + trace id

Dat contract is belangrijk omdat elke productie-discussie uiteindelijk reduceert tot 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 request door een applicatie, wat precies de abstractie is die serieuze assistenten nodig hebben. LangSmith en OpenLIT specialiseren dat idee vervolgens voor LLMs, tools, vector stores en agent workflows.

Kerncomponenten en interfaces

De componentensplitsing hieronder is 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 provider interfaces, MCP, vectordatabase documentatie en de runtime documentatie voor vLLM, llama.cpp, OpenClaw en Hermes.

De LLM-laag zou drie dingen goed moeten doen: een huidige werkcontext consumeren, ofwel een definitief antwoord of een gestructureerde actieverzoek emiteren, en genoeg metadata teruggeven om retries en tracing te ondersteunen. OpenAI’s Responses API is expliciet ontworpen voor stateful interacties plus ingebouwde tools en function calling. Anthropic’s Messages API blootlegt dezelfde kernlus via tool_use blokken en tool_result returns, terwijl Managed Agents je een gehost harnas geeft als je de lus niet zelf wilt bouwen. Zelfgehoste runtimes zoals vLLM en llama.cpp zijn belangrijk omdat ze bekende provider-stijl interfaces behouden terwijl ze je laten infereren binnen je eigen omgeving.

De Geheugelaag zou mentaal gesplitst moeten worden in drie buckets: werkgeheugen, duurzaam symbolisch geheugen en doorzoekbaar semantisch geheugen. OpenAI embeddings retourneren vectoren die geïndexeerd en doorzocht kunnen worden; OpenAI Retrieval en File Search leggen vervolgens semantische en keyword search bovenop vector stores. 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 alle geheugen in een vector store hoort: bestand-achtergrond notities, beoordeelde promoties en sessie-beperkte snapshots zijn vaak het eerlijkere ontwerp. Memory Systems in AI Assistants mapt het cross-framework model; Hermes Agent Memory System unpackt gebonden kerngeheugen en bevroren sessie snapshots in één product.

De Tooling-laag is waar een assistent stopt met zomaar 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 meer expliciet: tool use is een contract tussen je applicatie en het model, en het model voert nooit iets zelfstandig uit. MCP generaliseert dat contract naar een client-server protocol waar 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 comfortabel in als orchestration libraries: LangChain focust op een vooraf gebouwde agent architectuur en integraties, terwijl LlamaIndex focust op context-augmented data-toegang, query engines en workflows.

De Routing-laag bestaat omdat “welk model?” nooit de enige vraag is. Je hebt ook nodig “welke provider path, welke tenant, welk budget, welke latency class en welke fallback?”. LiteLLM is nuttig omdat zijn officiële documentatie verfrissend concreet is: weighted pick, least-busy, latency-based, cost-based routing en bounded failovers zijn allemaal first-class patronen. OpenClaw verlengt routing omhoog naar kanaal- en agent isolatie, terwijl Hermes het omlaag verlengt naar model slots voor hoofd- en hulpprocessen zoals samenvatting, context compressie en MCP tool routing. Dat is het juiste mentale model: de router kiest meer dan een model, het kiest een execution lane.

De Observability-laag is wat voorkomt dat architectuur folklore wordt. OpenTelemetry geeft je de trace abstractie. LangSmith geeft je end-to-end zichtbaarheid over LLM applicatie stappen en ondersteunt cloud, hybride en self-hosted deployment vormen. OpenLIT geeft je OpenTelemetry-native AI observability met zero-code en manual instrumentation opties, inclusief support voor LLMs, agent frameworks, vectordatabases en GPUs. Voor productie metrics, traces en SLO patronen over inference en agent workflows, zie Observability for LLM Systems. Als je assistent geen trace per request heeft, geen span per model call, en geen event history voor tool-uitvoering, dan heb je eigenlijk nog geen architectuur. Je hebt vibes.

Capture, verrijk, antwoord

De sequentie die steeds terugkomt in echte systemen is capture -> verrijk -> antwoord -> record. Verschillende frameworks verpakken het anders, maar de flow is stabiel genoeg om te behandelen als het ruggengraat.

De capture stap is meestal belangrijker dan het eruit ziet. OpenClaw en Hermes plaatsen beide een persistente gateway voor de assistent omdat ingress niet zomaar tekstinput is. Het omvat kanaal metadata, identiteiten, autorisatie, sessie grenzen, direct messages, groepen, cron ticks en delivery semantics. Als je die laag overslaat en vertrouwt op een raw chat widget abstractie, dan ga je het uiteindelijk toch als ad hoc middleware terugplaatsen.

De verrijk stap is waar rijpe systemen afwijken van toy demos. OpenAI Retrieval en File Search maken retrieval expliciet via vector stores en search calls. LlamaIndex formaliseert hetzelfde patroon via data connectors, indexes, query engines en workflows. Hermes gaat verder door het model estate 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 om te stelen: besteed je meest dure model tokens niet aan klusjes.

De antwoord 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, emiteert het een gestructureerde aanvraag. Anthropic’s tool-use contract en OpenAI’s function-calling guide maken dit beide expliciet. De reden waarom dit architecturaal belangrijk is, is dat outputs nu zowel taal als control flow bevatten. Je response object is deels proza en deels runtime plan.

De record stap is waar consistentie semantics naar voren komen. Pinecone scheidt write en read paths en verwerkt writes na durable acknowledgement. Hermes geheugen wordt geïnjekteerd als een bevroren snapshot per sessie zodat het prefix-cache performance kan behouden, wat betekent dat nieuwe writes niet automatisch verschijnen in de huidige sessie prompt. OpenClaw’s Dreaming systeem promoot alleen beoordeelde, gegronde 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 staged visibility.

OpenClaw en Hermes als referentiesystemen

OpenClaw en Hermes zijn nuttige referentiecases 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 model backends.

Deze mapping is gebaseerd op de officiële OpenClaw en Hermes documentatie en repos. OpenClaw documenteert een gateway architectuur, multi-agent routing, custom en zelfgehoste provider support inclusief vLLM en Ollama, optioneel actief geheugen en Dreaming-based promotie. Hermes documenteert een messaging gateway, een centrale AIAgent lus, hoofd- en hulpslots, ingebouwd geheugen en native MCP integratie.

Mijn iets opinionated 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, geheugen semantics, tool surfaces en backend heterogeniteit als first-class concerns. Dat is precies wat een productie architectuur zou moeten doen.

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

edge:
  gateway: hermes of openclaw

routing:
  proxy: litellm
  policy: latency en budget aware
  tenancy: sessie en kanaal scoped

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: filesystem, browser, web search, interne APIs

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

Die stack is een redeneerde deployment patroon in plaats van een vendor-prescribed blueprint. 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 standardiseert 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 assistent patronen die het waard zijn te noemen. 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 surfaces. Een specialist mesh decomposeert werk in meerdere agents of routes. Officiële documentatie van OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw en Hermes ondersteunt allemaal versies van deze patronen, ook als ze ze anders noemen.

Deze patronentabel is een synthese van de provider documentatie, framework documentatie 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 vector service, terwijl vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, LangSmith zelfgehost en OpenLIT allemaal self-managed of hybride operatie ondersteunen in verschillende mate.

Tabelnotities: Pinecone documenteert een beheerde control plane en regionale data planes. Weaviate documenteert vector en inverted indexes met meerdere vector index types. pgvector voegt exacte en approximate nearest-neighbour search toe aan Postgres. Milvus positioneert zich als een open-source high-performance, schaalbare vector database, 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 tool-use contract apart van Managed Agents. vLLM blootlegt een OpenAI-compatibele server plus Anthropic Messages API support. Ollama documenteert lokale embedding en model workflows. 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 documentatie, geen vendor benchmark. De consistentie rij is belangrijker dan veel blog posts toegeven: Pinecone scheidt write en read paths, Hermes bevriest geheugen in sessie-start prompts, en OpenClaw promoot duurzaam geheugen via staged review. Dat betekent dat “geheugen bijgewerkt” en “geheugen zichtbaar voor het huidige antwoord” vaak verschillende waarheden zijn.

Failure modes en mitigaties

De meeste assistents falen niet omdat het basismodel “slecht” is. Ze falen omdat het omringende systeem het model liegt, het de juiste context ontberft, tools laat driftten, of debugging onmogelijk maakt.

De evidence base voor deze tabel is breed maar consistent. Anthropic’s tool documentatie maakt duidelijk dat tool use een contractgrens is. OpenAI Guardrails inclusief hallucination detectie tegen een referentie kennisbase via File Search. SelfCheckGPT toont dat self-consistency over samples kan helpen bij het detecteren van niet-ondersteunde claims. De “Lost in the Middle” resultaten en Anthropic’s context guidance versterken beide dezelfde operationele les: meer tokens verwijderen niet de behoefte aan context curatie.

De voorkeurs mitigatie stack kan saai en repetitief zijn: trace elke request, versioneer prompts, evalueer retrieval onafhankelijk, houd tools idempotent, en run regression evals voordat je routes of geheugen policy verandert. OpenAI’s Evals documentatie en repo zijn blunt over waarom: zonder evals is het moeilijk en tijdrovend om te begrijpen hoe model of prompt veranderingen je use case beïnvloeden. Dat geldt net zo goed voor routers en retrieval 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 assistent architectuur.

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

• Anthropic: API Overview, Tool Use, het tool-use contract, Managed Agents, Context Windows en de MCP connector.

• MCP zelf: de Architecture Overview en Specification zijn het waard direct te lezen, omdat ze hosts, clients, servers, tools, prompts, resources, transports en capability negotiation clean uitleggen.

• Frameworks en routing: LangChain Overview, LlamaIndex context-augmentation documentatie, LiteLLM routing documentatie, LangSmith observability documentatie.

• Zelfgehoste runtimes en assistentsystemen: vLLM, llama.cpp server, Ollama embeddings, OpenClaw documentatie en repo, Hermes documentatie en repo.

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

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