Zum Hauptinhalt springen

AI surfaces (chatbot vs deskbot split over one guard)

Generated from mcp/patterns.registry.json — do not edit by hand; change the registry and run bun run patterns:build.

Category: AI · Tier: deep · Risk: high — user-facing LLM behavior and permissions

Two AI surfaces over one shared guard: a read-only, citation-faithful chatbot (Vely) vs an agentic, mutating, approval-gated deskbot — with a showcase-only rag-demo value kept out of production paths.

When to use: Use when one product needs both a safe answer-bot and an acting agent: splitting the surface (not forking the stack) keeps permissions and prompts honest per surface.

Docs

Code

  • src/lib/server/ai/guard.ts — guardAiRequest() — the one shared gate (GitHub · GitLab)
  • src/lib/server/ai/chat-orchestrator.ts — Chatbot orchestration (GitHub · GitLab)
  • src/lib/server/ai/deskbot-rag.ts — Deskbot retrieval side (GitHub · GitLab)
  • src/routes/api/ai/chatbot/+server.ts — Chatbot route adapter (GitHub · GitLab)
  • src/routes/api/ai/deskbot/+server.ts — Deskbot route adapter (GitHub · GitLab)
  • src/lib/components/composites/chatbot/ — Chatbot UI (GitHub · GitLab)

Tests

  • src/lib/server/ai/chat-orchestrator.test.ts (GitHub · GitLab)
  • src/lib/server/ai/tool-leak-guard.test.ts (GitHub · GitLab)

Proof

Invariants

  • The chatbot never emits a DeskEffect and never creates a proposal.
  • A chatbot tool never carries a desk scope; a deskbot tool always does — topology derives from manifest membership, not a scope artifact.
  • rag-demo is not a product surface and must not dilute the chatbot.

Emulation notes

  • Start with the read-only surface; add the mutating surface only with the approval gate (see deskbot-approval-gate).
  • Route adapters stay thin — both surfaces call the same guard then their orchestrator.

Depends on


Machine-readable record: ai-surfaces in mcp/patterns.registry.json.

← Back to Pattern Library

Geht dieses Pattern noch besser? Sag uns, wie.

Feedback geben