Ein souveräner KI-Core · Open Telekom Cloud · eu-de

Ein Hirn. Viele Anwendungen.

◆

Viele Spezialisten-Apps. Ein gemeinsames Hirn.

Lotse, Hebebühne, Knowledgebot docken mit wenigen Configs an — und der Agent arbeitet wirklich: codet, installiert Tools, importiert große Daten, fährt Cronjobs. Sicher abgeschottet, gehostet bei T-Systems.

Das Schaubild Wie „zentral" arbeitet

eu-de

Hosting nur T-Systems OTC

US-LLM im Produkt-Datenpfad

Core als Fundament für alle Apps

Das Problem

KI in jede App neu zu bauen, skaliert nicht.

Eigener Prompt-Stack, eigene Tools, eigenes Memory pro App — das driftet, verdoppelt Arbeit, wird mit jeder Iteration teurer.

Die Idee

Ein Core wird schlauer — alle profitieren.

Der channel-agnostische Core kann Slack, Telegram, Web und eine API zugleich. Eine Verbesserung wirkt sofort in allen Apps. Module ändern nur ihre Config — nicht den Code.

◆ Architektur

Vom Hirn zur Anwendung

Drei Schichten — Hirn, Kanäle, Anwendungen. Dazwischen nur Config, übers Netz, nie ein geteiltes Dateisystem.

01 Das KI-Hirn — Core-Git

eine Codebasis

Anthropic Agent SDK

claude-code — via Sub

OpenCode SDK

Codex / GPT — via Sub

Austauschbare Engines · gemeinsamer Session-/Memory-/Tool-Layer · Doc-Mode & Markdown.

02 Kanäle — Channel-Adapter

ein Interface

Slack

Web

API ↗

Dieselbe Logik, egal welcher Messenger. Die API ist der Adapter, über den fremde Apps wie ein Messenger andocken — hinter Authentik/Caddy.

03 Anwendungen — nur Config

isolierte Instanzen

Lotse

Fragebogen-Studio

Hebebühne

baut jede Art App

Knowledgebot

große Daten · Importe

Jede App = eine Instanz mit eigener config, eigenen MCPs, eigenem briefing. Kein Core-Fork.

◆ Schaubild · das Ökosystem

Alles, was mit KI zu tun hat — ein Core.

Jede Willis-Werkstatt-App mit KI-Bezug docke an denselben Core an — nicht jede eine eigene Installation. Heute läuft manches noch getrennt (Knowledge auf eigenem Server). Ziel: eine zentrale Control-Plane, isolierte Ausführung pro Projekt, und je App nur Config — Prompts & Einstellungen.

Stepharo AI · KI-Core — unser Git

eine Installation, zentral

Control-Plane

Routing · Sessions · Memory · Orchestrierung

Sandboxes

isolierte Ausführung pro Projekt

Engines

Anthropic Agent SDK · OpenCode

Config-Layer

instance.json · briefing · mcp.json

Anbindung: API · MCP · Sandbox

Lotse

●

lotse-app.willis-werkstatt.com

KI: Studio-Chat · Frage-Assistent · „enhance"

VM-AAPI + Config

Hebebühne

●

hebebuehne.willis-werkstatt.com

KI: Doc-Chat · baut jede Art App

VM-ASandboxAPI

Knowledgebot

●

knowledge-bot · knowledge-app.willis-werkstatt.com

KI: MCP-first KB-Generator · große Importe · Cronjobs

VM-B · eigener ServerSandboxMCP

Cyberschutzengel

●

cyberschutzengel.willis-werkstatt.com

KI: WilliAI · CMS-Content-Bot

VM-AAPI + Config

Datenquelle — der Agent dockt an

Nextcloud · cloud.willis-werkstatt.com — Dateien & Dokumente über MCP / WebDAV (Service-User). Nicht KI selbst, sondern Daten, auf denen die KI arbeitet.

Legende

● KI-Touchpoint · VM-A 80.158.44.231 · VM-B 164.30.0.137

Zentral oder jeder für sich?

Heute: teils pro App, teils eigener Server. Ziel: ein Core bedient alle — Apps docken über API/MCP an, schwere Arbeit läuft in isolierten Sandboxes pro Projekt, jede App bringt nur ihre Config mit. Kein Code-Fork, kein N-faches Setup.

◆ Fallbeispiel · Hebebühne-Verheiratung

Core-Naht gebaut · nicht live

Die Naht existiert schon.

Hebebühne ruft heute einen externen RUNNER_URL (services/agent-runner). Gebaut (Core-Seite): unser Core kann dieser Runner sein — POST /run + Settings-Endpoints, getestet auf Branch feat/api-channel. Offen: RUNNER_URL umbiegen + Deploy. Kein Merge, kein neues Frontend.

bleibt bei Hebebühne

apps/web · apps/api

Frontend (Editor/Chat) + Domäne: Sessions, Projects, Board, Tickets, Tenant, DTOs/DB/i18n.

die Naht

RunnerClient → RUNNER_URL

zeigt künftig auf unseren Core (API-Channel) statt den lokalen Runner. POST /run, Blöcke zurück.

kommt raus

services/agent-runner

runner.mjs + providers/anthropic + openai — eine Zweitkopie genau dessen, was der Core kann.

engine claude/codex/fable
↔ Core-Engines

thinkLevel auto…max
↔ effort

ChatBlockDto (kind)
↔ Doc-Mode-Blöcke

repo
↔ Sandbox/Projekt

Frontend-Mode — Hebebühne als Cockpit

optional · in Syncgeplant

Der Core läuft auch ganz ohne Frontend (headless, wie telegramAgents). Ist der Frontend-Mode an, wird Hebebühne zur grafischen Steuerzentrale derselben Installation — Hebebühne und Slack zeigen denselben Core-Stand, immer in Sync (eine Session-/Sandbox-Quelle).

Projekt- & Session-Browser

Jedes Projekt und darin alle Sessions auf einen Blick — aus demselben Store, den Slack/Telegram nutzen.

Editor — draufschalten

Auf jede Session live aufschalten und weiterarbeiten — resume verbatim, §4-treu.

Settings — neben dem Editor

Projekt-individuelle Dateien sehen & pflegen: MEMORY.md, CLAUDE.md, Prompts (briefing), mcp.json, Doc-Mode-Blöcke.

◆ Die Kernfrage — beantwortet

Wie kann „zentral" echte Arbeit leisten?

Der Agent codet, installiert, importiert Gigabytes, startet Cronjobs. Ein geteilter Prozess auf einem Host wäre falsch. Die Lösung: das Brain bleibt zentral, die Ausführung wird pro Projekt isoliert.

Control-Plane · zentral

Das Brain

Channels/API, Routing, Session-DB, Memory-Index — und die Orchestrierung der Sandboxes. Eine Installation.

Execution-Plane · verteilt

Isolierte Sandboxes

Pro Projekt eine abgeschottete Sandbox. Dort läuft das SDK mit cwd = Projekt — eigenes FS, eigene Tools, Cronjobs, große Daten. §4 bleibt heil.

Impl. 1

live

local-process

heute — gleiche VM, geteiltes FS. Im Core gebaut (Sandbox-Seam).

Impl. 2

geplant

container

pro Projekt, cgroups-Quotas, OTC-Volumes. Der nächste Schritt.

Impl. 3

geplant

microvm

Firecracker/Kata für untrusted Code + Autoscale.

„Sandbox" ist ein austauschbares Backend — zentral vs. verteilt = ein Stecker, kein Rewrite.

Isoliert — und trotzdem schnell & sparsam

~100ms

Start — Container teilen den Kernel, keine VM

1×

Basis-Image geteilt, nur Diffs pro Projekt (OverlayFS)

CPU/RAM im Leerlauf — Idle-Stop, nur Disk bleibt

∞

cgroups-Quotas — ein Lauf killt sich, nie den Host

State lebt auf persistentem Volume, Compute ist wegwerfbar. Cold-Start ist neben einem LLM-Turn vernachlässigbar.

Zwei Engines

Anthropic & OpenCode — austauschbar

Anthropic Agent SDK

claude-code — primärer Test- & Entwicklungspfad, stabiler Session-Resume.

OpenCode SDK

Codex / GPT als zweite Engine — gleiche Schnittstelle, unabhängige Zweitmeinung.

Beide laufen erstmal über Subs — der Core orchestriert, die Engine arbeitet.

Config statt Code

Eine neue App = drei Dateien.

instances/hebebuehne/
  instance.json   { engine, model, prefix, docMode }
  briefing.md     # Rolle der App
  mcp.json        # erlaubte Tools

# auswählen:
WILLI_INSTANCE=hebebuehne

Engine, Modell, Verhalten, Tools, Doc-Mode, eigene Blöcke — alles deklarativ, ohne den Core anzufassen.

◆ Gedächtnis · im Core umgesetzt

live

Jede Konversation hat ihr eigenes Gedächtnis.

Jeder Channel/Thread bekommt einen eigenen Projektordner — mit eigener CLAUDE.md, MEMORY.md und einem isolierten Knowledge-Graph. Kein Quer-Leck zwischen Konversationen.

Drei Schichten

Vertrag · Speicher · Graph — auto-geladen bei Session-Start.

Erzwungene Isolation

Der Core erzwingt den per-Konversation-Pfad. Sicher by design.

Queue-Awareness

Der Dialog zerreißt nicht, wenn der Nutzer „blind" weiterschreibt.

◆ Ausgabe · im Core umgesetzt

live

Markdown out-of-the-box.
Doc-Mode, wenn's reicher sein soll.

Das Modell bettet typisierte Blöcke als ```willi-doc```-JSON ein; jeder Block hat Zod-Schema + deterministisches Markdown-Fallback. Nahezu HTML-Freiheit — aber nichts dem Zufall überlassen.

1 · Registry

Single Source of Truth

Schema + Fallback + Beispiel pro Block. Global oder pro Projekt (deklarativ, ohne Code).

2 · Discovery

`/wc-blocks` & Katalog

Ein Befehl, ein JSON-Katalog für MCP/Frontend, eine Prompt-Sektion fürs Modell — aus einer Registry.

3 · Frontend

Renderer + Fallback

Bekannte Blöcke schön, unbekannte als Markdown — nie kaputt, nie still verloren.

◆ Stand heute — die Wahrheit

Was läuft, was geplant ist

✓live

Slack / WilliCoder auf OTC

Channel- & Thread-Modus, Slash-Befehle, graceful Deploy.

✓live

Memory-Parität, verifiziert

Isolierter Knowledge-Graph + Auto-Load + Queue-Awareness.

✓live

Doc-Mode Block-System

14 Blöcke, getestet, off-by-default pro App aktivierbar.

◐Seam live

Sandbox-Backend

local-process gebaut; container/microvm geplant.

◐gebaut · nicht live

API-Channel + Settings-Endpoints

/run + /projects gebaut & getestet (Branch); Codex-Review + Deploy offen.

→geplant

Security-Pass

Sobald Slack/Core top läuft.

Souverän by design

T-Systems · eu-de · selbst-hostbar

Hosting nur Open Telekom Cloud, eu-de. Diese Seite inklusive.

US-LLM im Produkt-Datenpfad.

Core als Fundament — viele Apps, eine Wahrheit.

Baustelle

Ein Hirn. Viele Anwendungen.

KI in jede App neu zu bauen, skaliert nicht.

Ein Core wird schlauer — alle profitieren.

Vom Hirn zur Anwendung

01 Das KI-Hirn — Core-Git

02 Kanäle — Channel-Adapter

03 Anwendungen — nur Config

Alles, was mit KI zu tun hat — ein Core.

Stepharo AI · KI-Core — unser Git

Die Naht existiert schon.

Frontend-Mode — Hebebühne als Cockpit

Wie kann „zentral" echte Arbeit leisten?

Das Brain

Isolierte Sandboxes

Isoliert — und trotzdem schnell & sparsam

Anthropic & OpenCode — austauschbar

Eine neue App = drei Dateien.

Jede Konversation hat ihr eigenes Gedächtnis.

Markdown out-of-the-box.Doc-Mode, wenn's reicher sein soll.

Single Source of Truth

/wc-blocks & Katalog

Renderer + Fallback

Was läuft, was geplant ist

T-Systems · eu-de · selbst-hostbar

Markdown out-of-the-box.
Doc-Mode, wenn's reicher sein soll.

`/wc-blocks` & Katalog