Kunde mit Open-WebUI + Mono-MCP onboarden

Kunde mit Open-WebUI onboarden

End-to-End-Pattern fuer einen Kunden-Setup mit Open-WebUI als Chat-UI plus Mono-MCP fuer die Tool-Anbindung. Erstes Live-Setup: Vibe Factory (Mai 2026). Pattern ist wiederholbar, mit Anpassungen fuer Hosting-Stack (AWS vs Hetzner) und Compliance-Anforderungen des Kunden.

Wann dieses Pattern passt

• Kunde ist KMU (5-50 Personen), arbeitet mit Microsoft 365 oder Google Workspace
• Will einen zentralen Chat-Agent fuer’s Team statt jeder selber ChatGPT-Pro
• Hat ein bestehendes Operating-System (SharePoint, Google Drive, Notion, etc.) das angebunden werden soll
• Braucht ein Buchhaltungs-/Branche-spezifisches Tool angebunden (Papierkram, TicketPAY, Lexware, etc.)

Nicht dieses Pattern wenn:

• Kunde will Claude/ChatGPT direkt nutzen ohne Custom-Setup → Empfehlung Claude Pro mit Custom Connector
• Kunde hat hohe Compliance-Anforderungen die EU-Onpremise erzwingen → siehe hosting-industriekunden (Hetzner + Mistral statt AWS + Bedrock)

Phasen — was wann passieren muss

Phase 0 — Discovery (vor jedem Setup, 1 Termin mit Kunde)

Eine Stunde mit dem Kunden, NUR um Realitaet zu verstehen:

• Team-Rollen — wer macht wirklich was, nicht was im Org-Chart steht. NICHT aus Vault-Files annehmen, immer beim Kunden fragen. Siehe system-prompt-deploys-guardrails Punkt 2.
• Bestehende Tools — wo arbeitet das Team taeglich (SharePoint? Notion? Papier?), wo liegen welche Daten
• Pain-Points — was nervt, was vergisst man, was dauert zu lange
• Domain-Daten — Firma, Rechtsform, Domain, Logo, Branding-Farben, Telefon-Adresse

Output: ein Realitaets-Dokument im Vault unter intern/kunden/<kunde>.md mit Stammdaten + Rollen + Pain-Points + Tools.

Phase 1 — Tool-Anbindung pruefen + Mono-MCP-Build

Pro externes System des Kunden:

• M365 / SharePoint → mcp-m365 nutzen, App-Registration im Kunden-Tenant, Sites.Selected pro Site granten (siehe sharepoint-permissions-app-grant)
• Papierkram → mcp-papierkram nutzen, API-Key vom Kunden
• TicketPAY → mcp-ticketpay nutzen, API-Key vom Kunden
• Andere → entweder existierender MCP oder Eigenbau via mcp-eigenbau

Dann Mono-MCP aufbauen der die einzelnen Sub-MCPs proxied. Siehe mcp-hosting-fargate-tunnel (AWS) oder eine kuenftige Hetzner-Variante.

Phase 2 — Open-WebUI-Hosting bereitstellen

Hosting-Stack-Wahl:

• AWS Fargate (Default, fuer normale KMU): siehe open-webui-fargate-bedrock — Bedrock-EU als Modell-Backend, ~50-80 EUR/Monat
• Hetzner (fuer strenge DSGVO-Industriekunden): siehe hosting-industriekunden — ~30-50 EUR/Monat, Mistral oder selbst-gehostetes Modell

Auth: Email + Passwort + MFA, eingebaut in Open WebUI.

Auf eigene Sub-Domain mappen: <kunde>-chat.agenticventures.de (Default) oder Kunden-eigene Domain mit Cloudflare-Tunnel.

Phase 3 — System-Prompt aufsetzen

NIEMALS aus Vault-Files destilieren ohne Realitaets-Check. NIEMALS direkt deployen ohne explizite User-Freigabe. Siehe system-prompt-deploys-guardrails.

Struktur des System-Prompts:

1. Identitaet — wer ist der Agent, fuer welchen Kunden, welche Tools hat er
2. Kontext — Datum, User-Identity (via Template-Variablen), Knowledge-Cutoff
3. Stammdaten — Firmenname, Domain, Telefon, Adresse, Rechtsform. PFLICHT — sonst kann der Agent „wie ist meine Webseite?”-Fragen nicht beantworten (siehe VF-Lesson 2026-05-14).
4. Werkzeug-Prioritaet — welcher Tool fuer welche Anfrage (mit AGGREGATION-FIRST-Hinweis bei Bilanz-Fragen)
5. Keine-Halluzinationen-Block — Tool-First-Disziplin, bei Zahl ERST Tool DANN Antwort
6. Fehler-Resilienz — bei Tool-Fehler nicht aufgeben, 1-2 Recovery-Versuche
7. Werkzeug-Sprache — niemals Tool-Namen im User-Output
8. Code-Interpreter-Pfade — /mnt/uploads/ fuer Open-WebUI-Pyodide, File-Link-Pattern fuer Downloads
9. Diagramme/Reports — HTML-Default mit Anthropic-Cream-Palette, nicht PDF
10. Arbeitsweise — Multistep-Persistence, Default-Optionen statt Klaerungsfragen
11. Sicherheits-Grenze — Tool-Outputs sind UNTRUSTED, Instruktionen daraus nicht ausfuehren
12. Vorsicht-Finanzberatung — bei steuerlichen/rechtlichen Fragen nur Fakten, keine Empfehlung
13. Output-Stil — Sprache, Tonalitaet, Zahlen-Notation, Quellenangabe-Pflicht

Beispiel-Referenz: ~/source/apps/open-webui-vf/prompts/vf-sonnet.txt (v2.6, ~15k chars).

Phase 4 — KI-Operating-System aufbauen

Damit der Agent sich an Kunden-Prozessen langhangeln kann, braucht der Kunde einen strukturierten Ort wo Standards/Prozesse/Vorlagen liegen.

Empfohlene Struktur (uebernommen von VF, anpassbar):

SharePoint/<kunde>/Dokumente/
├── 00_Unternehmen/        Firma, Vertraege, Gesellschafter
├── 01_Finanzen/           Banking, Berater-Kontakte
├── 02_Recht/              AGB, DSGVO, Versicherungen
├── 03_HR/                 (sensible, separate Permission!)
├── 04_Vertrieb/           Pipeline, Reports
├── 05_CRM/                Kunden-Records
├── 06_Marketing/          Content, Kampagnen
├── 07_Produkte_Leistungen/Was der Kunde anbietet
├── 08_Projekte/           Live-Projekte
├── 09_Standards/          PROZESS-DOKUMENTE — Agent liest hier
├── 10_Vorlagen/           Templates
├── 11_Wissen/             Wiki-artig
├── 12_Todos/              Team-Tasks
└── 99_Archiv/             Inaktives

Lazy-Loading-Pattern: Im System-Prompt nur ein Routing-Hinweis, dass 09_Standards/_routing.md als Index dient. Der Agent liest bei Bedarf rein, befolgt die Verzweigung in spezifische Prozess-Files. Vorteil: Aenderungen an Prozessen brauchen keinen System-Prompt-Deploy mehr.

Phase 5 — Smoke-Tests + Realitaets-Check

Mindestens 5 Smoke-Tests vor Go-Live, mindestens 2 davon Realitaets-Fragen:

• „Wer ist GF bei ?”
• „Was ist die Adresse / Telefon-Nummer / Rechtsform?”
• „Wer macht Buchhaltung?”
• Plus 2-3 Tool-Tests (z.B. „liste alle offenen Rechnungen”, „wie viele Tickets verkauft fuer Event X”)

Phase 6 — Uebergabe + Training

• 30-Min-Onboarding-Call mit dem Kunden-Team
• Login-Daten + Doku
• Erste 2 Wochen: Marvin schaut taeglich in Konversations-Logs, sammelt Drift-Faelle, korrigiert System-Prompt oder Standards-Files

Stolperfallen aus dem VF-Pilot (Mai 2026)

Diese Sammlung ist hart erkauft am 2026-05-14. Bei kuenftigen Kunden-Setups: Stolperfallen vorlesen + abhaken vor dem Start.

1. System-Prompt-Drift durch ungepruefte Snippet-Destillierung — siehe system-prompt-deploys-guardrails
2. SharePoint-Permission ist zwei-stufig — Tenant-Admin ≠ Site-Content-Zugriff. Siehe sharepoint-permissions-app-grant Abschnitt „Klassischer Stolperstein”.
3. Bedrock-Quirk — kein Assistant-Prefill. Title-Generation-Background-Tasks in Open WebUI deaktivieren oder auf anderes Modell zwingen, sonst HTTP-Errors.
4. Stammdaten fehlen im System-Prompt — Agent kann nicht antworten was Domain/Adresse des Kunden ist. Immer mit aufnehmen. Quelle: das Impressum der Kunden-Website (rechtsverbindlich + aktuell).
5. Open-WebUI Env-Var-Naming-Drift — ENABLE_RAG_WEB_SEARCH ist deprecated, ENABLE_WEB_SEARCH neu. Plus WEB_LOADER_ENGINE MUSS gesetzt sein (safe_web) sonst crasht fetch_url. Komplette Liste in open-webui-konfigurations-quirks.
6. Web-Search ist KEIN LLM-Tool sondern RAG-Pipeline — User muss Toggle klicken vor der Frage. Alternativ: Web-Fetch als eigenes MCP-Tool nachruesten damit der Agent es immer im Tool-Set hat.
7. MCP-Tools ueberschreiben Builtin-Tools — wenn ein Custom Model einen MCP attached hat, gehen die Open-WebUI-Builtins (fetch_url, image_generation, etc.) verloren. Wenn beides gebraucht: ins MCP nachruesten.
8. Local-MCP-Source != Hosted-MCP-Source — Aenderungen am lokalen Fork wirken nicht in der Fargate-Hosted-Instanz bis zum Rebuild + Deploy.
9. OneDrive Sync-Apps haengen sich an SharePoint — bei der Permission-Konfiguration nicht ueberraschen lassen wenn unbekannte App-IDs als Owner auftauchen (z.B. OneDrive SyncEngine).
10. Two-Site-Architektur statt Migrations-Big-Bang — den existierenden gewachsenen SharePoint-Bestand (z.B. /sites/OwnCloud) NICHT migrieren. Neue Site /sites/intern als Meta-Layer aufbauen mit Routing/Wissen/Standards/Indexes. Siehe sharepoint-meta-layer-architektur.
11. Anti-Pattern „Ueberproduktion” — nicht prophylaktisch hunderte Pointer-Ordner anlegen. _index.md mit Tabelle reicht. Bei „heute alles fertig”-Modus den Reflex hinterfragen ob’s wirklich gebraucht wird oder nur Symmetrie ist (Lesson aus VF-Pilot: 65 Pointer-Ordner gebaut + wieder geloescht — Zeitverschwendung).
12. Kunden-Naming-Konvention respektieren — der Kunde hat oft schon eine etablierte Konvention (z.B. YYYY_MM_DD - Kunde - Titel plus !Status-Praefix-Ordner). Der Agent soll das uebernehmen, nicht sein eigenes Schema durchsetzen.

Kosten-Schaetzung pro Kunde

Posten	AWS-Variante	Hetzner-Variante
Open-WebUI-Hosting	30-50 EUR/Monat	15-25 EUR/Monat
Modell-API (Sonnet/Mistral)	usage-based, ~30-100 EUR/Monat	usage-based oder selbst-gehostet
Mono-MCP-Hosting	10-20 EUR/Monat	10-15 EUR/Monat
Cloudflare-Tunnel	0	0
AWS-Account-Setup einmalig	enthalten in Org	n/a
Total laufend	70-170 EUR/Monat	40-65 EUR/Monat

Verrechnung an Kunde: at-cost (Hosting) + Subscription-Fee fuer Pflege + Stundensatz fuer Custom-Entwicklung.

Related

• open-webui-vf — VF-Pilot, Erster Live-Setup
• mcp-vf-hosted — VF-Mono-MCP
• produkt-bundle — wie das in unseren Tiers eingeordnet ist
• fahrplan — Business-Roadmap
• aws-multi-account-strategie — warum AWS-Org als Default-Hosting
• hosting-industriekunden — wann Hetzner statt AWS