AI web: bouw en host je AI-agent met streaming en tools

AI web: bouw en host je AI-agent met streaming en tools

Geschreven door

in

AI web = een webapp waarin je AI (meestal een LLM) draait via een server, met een agent- of toollaag, en een directe user experience (streaming, state, authenticatie). Hieronder: een compacte bouwreceptuur, keuzehulp (hosting en streaming), en een werkende opzet die je vandaag nog kunt implementeren.

1) Eerst: wat je precies bouwt met “ai web”

Praktisch gezien heb je 4 lagen:

  • Frontend: chat UI, streaming weergave, input, en eventueel bestands- of toolknoppen.
  • Backend API: ontvangt user intent, valideert requests, doet auth, roept het model aan, en geeft tokens of events terug.
  • Agent en tools: plannen, tool calls (bijv. RAG, kalender, DB queries, fetch), en policy checks.
  • Hosting: draait je backend betrouwbaar, met schaal, logging, secrets, en observability.

Je “ai web”-waarde ontstaat vooral door de backend UX (streaming) en door het agentdeel (tools, state, en guardrails).

2) Referentiearchitectuur (direct inzetbaar)

Gebruik dit schema, omdat het zowel eenvoudig als productwaardig is:

  1. Frontend doet POST of opent een streaming endpoint.
  2. Backend draait een request pipeline:
    • Auth en rate limiting
    • Input validatie (schema)
    • Context opbouw (system prompt, user profiel, retrieved docs)
    • Model aanroep met streaming
    • Event mapping naar SSE of WebSocket events
  3. Agent bepaalt:
    • Moet er een tool call gebeuren?
    • Welke tool, met welke parameters?
    • Kunnen we tool outputs vertrouwen, en hoe verwerken we die in het antwoord?
  4. Observability registreert: latency, model cost, tool calls, error rates, en contextgrootte.

Streaming keuze: SSE boven proza

Voor de meeste “AI web”-chatapps is Server-Sent Events (SSE) de laagdrempelige optie, omdat je één richting events naar de browser kunt pushen. OpenAI’s streaming guides beschrijven expliciet HTTP streaming via SSE (met events). (developer-openai-com.sitemirror.store)

Als je echt bidirectioneel verkeer nodig hebt (bijv. complexere realtime interacties), kijk dan naar andere transports zoals WebTransport, maar dat is vaak meer werk. (w3.org)

3) Backend: model, streaming en agent loop

Doel: je backend moet de model output als events naar de frontend streamen, en ondertussen tool calls kunnen uitvoeren zonder je UI op te hangen.

3.1 Request contracten, schema’s en policies

Definieer een strak request contract. Minimaliseer vrije tekstvelden, en valideer tool parameters. Praktisch:

  • Een chat message object met role, content, en optionele metadata.
  • Een tool context object met toegestane toolnames en scope.
  • Een session state (bijv. conversation id) die je backend bewaart, niet de browser.

3.2 Streaming endpoint: SSE of events

Conceptueel loopt je flow zo:

  • Frontend opent een streaming request.
  • Backend zet SSE headers, en begint met het uitsturen van events.
  • Bij elke chunk/token stuur je een event, bijvoorbeeld type=token of type=delta.
  • Bij tool calls stuur je type=tool_call, dan tool_result, dan gaat de model output verder.

Als je OpenAI gebruikt, sluit aan op hun streaming gedrag. Hun guide stelt dat default outputs pas na volledige generatie in één response terugkomen, en dat streaming via stream=true werkt met SSE. (developer-openai-com.sitemirror.store)

3.3 Agent loop: tool calling zonder chaos

Een robuuste agent loop bestaat uit drie stappen per turn:

  1. Plan of acteerstap: model besluit, op basis van tool descriptors en constraints.
  2. Tool execute: backend voert tool uit, met schema-validated parameters.
  3. Observeer: backend geeft tool output terug aan het model, eventueel met confidence of filtering.

Belangrijk: zet tool execution altijd server-side. Laat de browser nooit direct naar interne tools knallen.

4) Tools en RAG op een technische manier (geen lijstjes)

In “ai web” wil je meestal twee toolcategorieën:

  • Knowledge tools: retrieval, embeddings, doc chunking, en citations.
  • Action tools: API calls, DB queries, workflow triggers.

4.1 RAG: minimalistische pipeline

Een werkbare RAG pipeline:

  1. Preprocess: document chunks, embeddings, en metadata (bron, datum, permissions).
  2. Runtime: query embedding, top-k retrieval, rerank optioneel.
  3. Context bouwen: concat met harde limieten op token budget.
  4. Answer: model schrijft antwoord met expliciete constraints (bijv. alleen antwoorden op basis van context).

4.2 Tool descriptors en parameter contracts

Gebruik tool descriptors die machine-leesbaar zijn (JSON schema achtig). Dit maakt:

  • validatie simpel
  • tool-calls voorspelbaarder
  • logging bruikbaar voor debugging en evals

4.3 Veiligheid bij tools

Praktijkregels die je direct kunt toepassen:

  • Allowlist van toolnames per endpoint of per user role.
  • Scope op basis van user identity, niet op basis van input tekst.
  • Output filtering: verwijder credentials, PII of secrets voordat je terugstuurt naar het model of browser.
  • Idempotency keys bij write-tools (bijv. “create ticket”).

Als je eerder met tools en streaming aan de slag wil, zijn dit relevante interne referenties om sneller te starten:

5) Hosting en deploy: kies je platform met reden

“AI web” mislukt vaak niet door het model, maar door hostingkeuzes: secrets, scaling, timeouts, en observability.

5.1 Managed agent hosting (voorbeeld, Azure)

Als je in Microsoft ecosystem zit, dan biedt Microsoft Foundry een concept voor AI app and agent factory, met managed endpoints, scaling en identity. (learn.microsoft.com)

Daarnaast is er documentatie specifiek over hosting van Agent Framework applicaties en de keuze tussen managed Hosted Agents en self-hosting. De hosting modelkeuze is daar expliciet, en Microsoft noemt ook “Last updated” data, wat belangrijk is omdat het platform verandert. (learn.microsoft.com)

Wat betekent dat technisch voor “ai web”?

  • Je krijgt sneller een endpoint voor je agent, inclusief infrastructuur en schaalregels, in plaats van zelf containers, ingress, en scaling af te handelen. (learn.microsoft.com)
  • Je kunt nog steeds server-side tool execution en je eigen API contracten beheren, zolang je orchestratie klopt.

5.2 Als je zelfhost: containers en web endpoints

Self-hosting is logisch als:

  • je eigen agent loop vereist een specifieke orchestration (bijv. LangGraph-achtige controle)
  • je een eigen multi-tenant model gateway hebt
  • je een afwijkende auth en routing setup hebt

Maar: dan moet je ook de engineering doen voor:

  • rate limiting
  • streaming timeouts
  • secret management
  • log correlation

5.3 AI web integratie in bestaande webapps

Als je “ai web” moet inbedden in een bestaande webapp, dan is het vaak praktischer om je AI backend als een API laag te integreren in je bestaande deployment stack. Microsoft beschrijft expliciet AI integratie, inclusief agentic web applications en tool exposing via OpenAPI in hun App Service context. (learn.microsoft.com)

Andere interne startpunten voor een concrete build richting productie:

6) DevOps en productie: observability, evals, kosten

Je wil dat “ai web” reproduceerbaar wordt. Dus meet alles wat je bijstuurt.

6.1 Wat je moet loggen

  • Request id, user id (geanonimiseerd), session id
  • Prompt budget (tokens in en tokens uit)
  • Retriever stats (top-k, overlap, context token count)
  • Tool calls (tool name, params hash, duration, result size)
  • Errors met categorie (auth, validation, model error, tool error)

6.2 Evals in je pipeline

Minimaal: een set van “golden prompts” die je bij elke prompt or tool wijziging opnieuw draait.

  • Check: hallucination rate
  • Check: tool call rate op relevante vragen
  • Check: refusal policy consistentie

6.3 Kostenbeheersing

Praktische knoppen:

  • hard limieten op output tokens
  • context truncation strategie
  • tools alleen triggeren wanneer nodig (niet altijd RAG)
  • caching voor retrieval (per query embedding hash)

7) Werkende checklist: bouw in 60 tot 120 minuten

Als je vandaag een eerste “ai web” draft wil draaien, doe dit. Geen theorie, wel volgorde.

  1. Definieer endpoint(s)
    • POST voor niet-streaming test
    • GET of POST voor streaming SSE
  2. Maak request/response schemas (validatie op backend)
  3. Implementeer SSE streaming
    • send event per delta
    • send event voor tool call start en tool call result
    • send final event, sluit stream netjes
  4. Agent loop
    • tool descriptors
    • tool execution server-side
    • tool output normaliseren naar modelvriendelijke input
  5. Auth en rate limiting
    • minimale auth voor starters
    • rate limiting per user en per IP
  6. Logging en correlation
    • request id door je entire call chain
    • duration voor model en tools
  7. Smoke tests
    • geen tool call scenario
    • wel tool call scenario
    • failure scenario tool error
  8. Frontend UX
    • tokens renderen
    • tool status tonen (optioneel)
    • retry alleen op idempotente acties

Als je wil bouwen met agent componenten, zijn deze interne links handig om structuur aan te brengen:

8) Veelgemaakte fouten (en hoe je ze in de code voorkomt)

  • Streaming zonder backpressure: als je tokens te agressief doorstuurt, krijg je UI glitches. Los op met buffer en flush beleid.
  • Tools aanroepen vanaf de browser: je lekt secrets, je mist server-side authorization, je breekt auditing.
  • Geen tool parameter validatie: agenten geven je ook wel eens het verkeerde schema terug. Valideer strikt.
  • Geen context limieten: retrieval kan je prompt budget slopen, waardoor latency en kosten exploderen.
  • Geen policy laag: bij acties en data access moet je expliciete checks doen voor user permissions.
  • Geen correlatie in logs: bij incidenten is het dan gokken waar de fout zat.

Conclusie: zo maak je van “ai web” iets dat je kunt runnen

Als je één ding onthoudt: ai web is geen “model in de browser”, het is een backend systeem met streaming UX en een agent plus toollaag. Bouw eerst het contract en de SSE streaming, voeg daarna de agent loop toe, en pas dan tools, RAG, en productie hardening (auth, observability, evals, kostenlimieten) toe.

Start met de checklist, link daarna door naar de technische build logs hierboven, en meet vanaf dag 1 latency, tool calls en contextgrootte. Daarmee voorkom je dat je project vastloopt in integratietijd en debugwerk.

Reacties

Geef een reactie

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *