Architectuur van AI-assistenten: LLM, geheugen, hulpmiddelen, routing, observabiliteit

Een productie- AI-assistent is niet zomaar “een LLM met een prompt”. Het is een systeem dat intentie accepteert, staat behoudt, beslist wanneer er informatie opgehaald of actie ondernomen moet worden, en voldoende runtime-details blootlegt om fouten te debuggen.

Dat systeemniveau-perspectief verkent de AI Systems cluster wanneer assistants verder gaan dan een enkele model-aanroep.

OpenAI beschrijft agents als toepassingen die plannen maken, tools aanroepen, samenwerken en voldoende staat behouden voor meerstaps werk, terwijl Anthropic hetzelfde probleem frameert als een beheerd omhulsel dat bestanden, commando’s, webtoegang en code veilig kan uitvoeren.

De schoonste architectuur verdeelt verantwoordelijkheden in vijf lagen: LLM, Geheugen, Tooling, Routing en Observability. Deze splitsing komt overeen met de mogelijkheden die worden blootgelegd door de APIs van grote providers, door MCP, door zelfgehoste runtimes zoals vLLM en llama.cpp, en door echte assistent-systemen zoals OpenClaw en Hermes.

Geheugen moet worden behandeld als meer dan “langere context”. Ophalingssystemen zetten externe kennis om in expliciete niet-parametrische geheugen — dezelfde ontwerpruimte die uitgebreid wordt behandeld in Retrieval-Augmented Generation (RAG) — en zowel de contextuele richtlijnen van Anthropic 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 zendt een gestructureerd verzoek uit, een runtime voert dit uit en het resultaat stroomt terug in het gesprek. Als die grens slordig is, wordt de assistent slordig.

Mijn voorkeur is eenvoudig: begin saai. Eén orchestrator, één duurzaam geheugenpad, één trace per verzoek en één expliciet beleid voor tool-uitvoering. Multi-agent grafieken zijn nuttig, maar pas nadat je je single-agent foutgevallen kunt verklaren zonder te raden.

Wat een AI-assistent systeem is

Een praktische definitie is deze: een AI-assistent systeem is een runtime die gebruikersintentie omzet in een reactie of actie door een modelinterface, contextassemblage, tool-uitvoering, staatbeheer en telemetrie te combineren. Daarom zijn de nuttige documenten niet alleen modelkaarten. De nuttige documenten zijn API-referenties, tool-contracten, ophalingsgidsen, routing-documenten en tracing-documenten. De Responses API van OpenAI biedt stateful interacties, ingebouwde tools en function calling. De Claude API van Anthropic biedt directe toegang tot Messages 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 assistentensysteem heeft een bredere contract dan een chat-completie. 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 productieconflict uiteindelijk terug te voeren is op een van deze vragen: welke context was zichtbaar, welke tool werd uitgevoerd, welk model antwoordde, welk geheugen werd gelezen of geschreven, en waar de trace aangeeft dat het systeem tijd besteedde. OpenTelemetry definieert traces als het pad van een verzoek door een applicatie, wat precies de abstractie is die serieuze assistants nodig hebben. LangSmith en OpenLIT specialiseren dat idee vervolgens voor LLMs, tools, vectorstores en agent-workflows.

Kerncomponenten en interfaces

De onderstaande componentensplitsing is die ik het meest duurzaam vind. Het is ook de splitsing die het beste overeenkomt met de officiële APIs en de open-source runtimes die mensen daadwerkelijk exploiteren.

De bovenstaande tabel is afgeleid van de officiële providerinterfaces, MCP, vectordatabase-documenten 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 uitzenden of een gestructureerd verzoek voor actie, en genoeg 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 biedt dezelfde kernlus via tool_use-blokken en tool_result-retourwaarden, terwijl Managed Agents je een gehost omhulsel geeft als je de lus niet zelf wilt bouwen. Zelfgehoste runtimes zoals vLLM en llama.cpp zijn belangrijk omdat ze bekende provider-achtige interfaces behouden terwijl ze je laten inference uitvoeren binnen je eigen omgeving.

De Geheugelaag moet mentaal worden opgesplitst in drie categorieën: werkgeheugen, duurzaam symbolisch geheugen en doorzoekbaar semantisch geheugen. OpenAI embeddings retourneren vectoren die geïndexeerd en doorzocht kunnen worden; OpenAI Retrieval en File Search lagen semantische en trefwoordsearch daarbovenop op 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 alle geheugen in een vectorstore hoort: notities gebaseerd op bestanden, beoordeelde promoties en sessie-gebonden snapshots zijn vaak het eerlijkere ontwerp — patronen die worden uitgepakt in Hermes Agent Memory System voor gebonden kerngeheugen en bevroren sessie-snapshots.

De Toolinglaag 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 explicieter: toolgebruik 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 waarbij hosts verbinden met één of meerdere 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 als orkestratiebibliotheken: LangChain focust op een vooraf gebouwde agent-architectuur en integraties, terwijl LlamaIndex focust op context-verrijkte data-toegang, query-engines en workflows.

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

De Observabilitylaag 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 zelfgehoste deployment-vormen. OpenLIT geeft je OpenTelemetry-native AI observability met zero-code en handmatige instrumentatie opties, inclusief ondersteuning voor LLMs, agent-frameworks, vectordatabases en GPUs. Voor productiemetrics, traces en SLO-patronen over inference en agent-workflows, zie Observability for LLM Systems. Als je assistent geen trace per verzoek heeft, geen span per modelaanroep, en geen geschiedenis van gebeurtenissen voor tool-uitvoering, heb je eigenlijk nog geen architectuur. Je hebt vibes.

Vangen, verrijken, reageren

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

sequenceDiagram
    participant U as Gebruiker of Kanaal
    participant G as Gateway of UI
    participant R as Router
    participant M as Geheugen en Ophaling
    participant L as LLM
    participant T als Tools of MCP
    participant O als Observability

    U->>G: bericht, bestand of commando
    G->>O: start root trace
    G->>R: verzoek + identiteit + sessie + beleid
    R->>M: laad sessiestaat en haal context op
    M-->>R: notities, chunks, metadata
    R->>L: prompt + context + tool schemas
    L-->>R: antwoord of tool call
    alt tool call
        R->>T: voer tool of MCP actie uit
        T-->>R: tool resultaat
        R->>L: tool resultaat + bijgewerkte context
        L-->>R: definitief antwoord
    end
    R->>M: persisteer sessie-veranderingen en geheugenkandidaten
    R->>O: spans, metrics, eval gebeurtenissen
    G-->>U: reactie

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 tekstinput is. Het omvat kanaalmetadata, identiteiten, autorisatie, sessiegrenzen, direct messages, groepen, cron-ticks en delivery-semantiek. Als je die laag overslaat en vertrouwt op een ruwe chat-widget abstractie, zul je het uiteindelijk toch terugzetten als ad hoc middleware.

De verrijken-stap is waar rijpe systemen afwijken van toy demos. OpenAI Retrieval en File Search maken ophaling expliciet via vectorstores en search-calls. LlamaIndex formaliseert hetzelfde patroon via dataconnectoren, indexes, query-engines en workflows. Hermes gaat verder door de modelbezit op te splitsen in hoofd- en hulp-slots, en werk zoals compressie, samenvatting en routing af te dragen aan kleinere of gespecialiseerde modellen. Dat is een ontwerppatroon dat het waard is te stelen: besteed je meest kostbare modeltokens niet aan huishoudelijke klusjes.

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

De vastleggen-stap is waar consistentiesemantiek naar voren komt. Pinecone scheidt schrijf- en leespaden en verwerkt schrijvers na duurzame bevestiging. Hermes geheugen wordt geïnitieerd als een bevroren snapshot per sessie zodat het prefix-cache prestaties kan behouden, wat betekent dat nieuwe schrijvers niet automatisch verschijnen in de huidige sessie-prompt. 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 gefaseerde zichtbaarheid.

OpenClaw en Hermes als referentiesystemen

OpenClaw en Hermes zijn nuttige referentiegevallen 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 documenten en repos. OpenClaw documenteert een gateway-architectuur, multi-agent routing, custom en zelfgehoste providerondersteuning inclusief vLLM en Ollama, optioneel actief geheugen en Dreaming-gebaseerde promotie. Hermes documenteert een messaging gateway, een centrale AIAgent lus, hoofd- en hulpmodel slots, ingebouwd geheugen en native MCP integratie.

Mijn iets meningsvolle 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 concerns. Dat is precies wat een productie-architectuur 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 kanaal-gebonden

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, websearch, interne APIs

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

Die stack is een redelijk deployment patroon in plaats van een vendor-voorschreven blauwdruk. Het werkt omdat de officiële interfaces op elkaar aansluiten: OpenAI en Anthropic bieden tool-gerichte APIs, vLLM en llama.cpp emuleren provider-achtige endpoints, Ollama handelt lokale modellen en embeddings af, MCP standardiseert externe tools, LiteLLM handelt routing en failover af, 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 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 prioritiseert 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.

Deze patrontabel is een synthese van de provider documenten, framework documenten en referentiesystemen in plaats van een claim van één vendor.

Tabel notities: OpenAI gehosted File Search is een beheerde tool, Anthropic biedt een beheerd omhulsel, Pinecone is een beheerde vectorservice, terwijl vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, LangSmith zelfgehost, en OpenLIT allemaal self-managed of hybride operatie ondersteunen in verschillende mate.

Tabel notities: Pinecone documenteert een beheerd controlplane en regionale dataplannen. 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.

Tabel notities: 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 biedt een OpenAI-compatibele server plus Anthropic Messages API ondersteuning. Ollama documenteert lokale embedding en model workflows. llama.cpp documenteert OpenAI-compatibele chat, responses en embedding routes, plus Anthropic-compatibele chat completies.

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

Foutmodi en mitigaties

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

Het bewijsbestand voor deze tabel is breed maar consistent. De tool documenten van Anthropic maken duidelijk dat toolgebruik een contractgrens is. OpenAI Guardrails inclusief hallucinatie detectie tegen een referentiekennisbank via File Search. SelfCheckGPT toont aan dat self-consistentie over samples kan helpen bij het detecteren van niet-ondersteunde claims. De “Lost in the Middle” resultaten en de contextuele richtlijnen van Anthropic versterken beide dezelfde operationele les: meer tokens verwijderen niet de behoefte aan contextcuratie.

Voorkeur mitigatie stack kan saai en repetitief zijn: traceer elk verzoek, versioneer prompts, evalueer ophaling onafhankelijk, houd tools idempotent, en run regressie evals voordat je routes of geheugenbeleid verandert. De Evals documenten en repo van OpenAI 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 ophaling 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 Overzicht, Function Calling, Using Tools, Retrieval, File Search, Evals en MCP voor remote tool servers.

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

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

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

• Zelfgehoste runtimes en assistent-systemen: vLLM, llama.cpp server, Ollama embeddings, OpenClaw documenten en repo, Hermes documenten en repo.

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

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