Dreischichtiges Runtime
Runtime für Memory + Decision Engine.
Wie die Outputs deines Agents zu typisierten, auditierten Entscheidungen werden.
Drei Schichten, ein Vertrag mit deinem CTO: Tenants ownen ihre Kernels · Operators sehen deine Daten nicht · Reviewer sehen jede Choice.
01 · Die Architektur
Compute. Ontologien. Decision-Orchestration.
Drei Schichten, ein Runtime.
Das sieht dein CTO, wenn er die Architektur reviewt. Die Startseite benennt die drei Schichten in einer einzigen Zeile am Ende von “How it ships.” Hier bekommen sie jeweils ihre eigene Sektion.
Decision-Orchestration
Typisierte Entscheidungen · HITL-Gates · Audit-Zeilen · Overrides
Ontologien
Typisierte Per-Tenant-Kernels · vom Tenant authored
Compute
Per-Tenant-Datenbank · durable Workflows · Action-Dispatch
Compute
Per-Tenant-Datenbank, durable Workflow-Runtime, typisierter Action-Dispatch.
Deine Daten liegen im Schema deines Tenants. Lang laufende Operationen überleben Crashes. Jeder Side-Effect ist eine typisierte Zeile in einer Audit-Tabelle.
Ontologien
Typisierte Per-Tenant-Kernels. Dein Domain-Experte authored sie; die Plattform kompiliert sie zur Runtime in typisierte Klassen.
Dein Business-Vokabular gehört dir. Kein Prompt-Fragment. Keine Config- Datei. Ein Schema.
Decision-Orchestration
Typisierte Entscheidungen erscheinen als ChoiceArchitectures. HITL-Gates routen Human-Approvals. Audit-Zeilen protokollieren jede Choice.
Dein Agent gibt typisierte Entscheidungen aus, keine Strings. Dein Reviewer sieht die Trade-offs. Dein CTO sieht den Trail.
02 · Authoring
Dein Domain-Experte schreibt das Schema.
Über den IDE-Agent, den er ohnehin nutzt.
Die meisten Agent-Stacks pushen Domain-Wissen durch Prompts. Das macht das Schema implizit, brüchig und unowned. Wir exponieren Kernel-Authoring als MCP-Oberfläche: Claude Code (oder jede MCP-fähige IDE) kann Kernel- Änderungen gegen deinen Tenant vorschlagen, validieren und anwenden. Der Tenant ownt den Kernel; die Plattform ownt die Compile-Pipeline.
# tenant/ind-sales-pilot/kernel.yaml
id: https://ind-sales-pilot.zunft.ai/kernel
imports:
- linkml:types
classes:
Lead:
slots:
- lead_score # 0..100
- fit_signals # multi-select from your industry taxonomy
- risk_flags # compliance, credit, geopolitical
- recommendation # QualifyingDecision output
QualifyingDecision:
is_a: Decision
slots:
- lead_id
- options # 2..5 typed alternatives
- trade_offs # named tensions between options
- default # prescriptive with justification
- hitl_gate # reviewer state machine
- audit_row # sha256 + timestampArchitektur-Notiz
Der IDE-Agent ruft zunft.author_kernel über MCP auf. Der vorgeschlagene Kernel wird gegen den aktuellen Tenant-Kernel gediff’t, gegen Schema-Typregeln und plattformweite Invarianten validiert und dann zu typisierten Klassen und Runtime-Constraints kompiliert. Die Pipeline ist deterministisch; dasselbe YAML kompiliert zu denselben Klassen.
03 · Deciding
Dein Agent liefert eine Entscheidung.
Optionen, Trade-offs, Provenienz — typisiert.
Wenn der Agent eine echte Business-Frage beantwortet, liefert er eine ChoiceArchitecture — ein typisiertes Objekt mit zwei bis fünf substanziell unterschiedlichen Optionen, benannten Trade-offs, prognostizierten KPI-Deltas pro Option, Provenienz und einem Agency-Health-Score. Single-String-Antworten sind non-conformant: Es gibt keinen API-Pfad, der eine liefert.
result = zunft.generate_decision(
class_curie="lead:QualifyingDecision",
input={"lead_id": "L-4421"},
)
result.options # list[Option] — 2 to 5 substantively different
result.trade_offs # list[TradeOff] — cross-option tensions
result.default # Option — with prescriptive justification
result.options[0].pedigree # "conservative" | "novel" | "agency-preserving"
result.options[0].predicted_kpi # {conversion: +0.08, cycle_time: -0.05}
result.agency_health # 0.84
result.provenance # PROV-O chainArchitektur-Notiz
Die Options-Generierung nutzt eine Quality-Diversity-Suche, die substanziell unterschiedliche Pfade hervorbringt, nicht Variationen einer Antwort. Jede Option wird entlang mehrerer Achsen verifiziert (formale Shape, ausführbarer Plan, KPI-Projektion, Choice-Set-Diversity), bevor sie erscheint. Die ChoiceArchitecture ist der API-Vertrag, kein handgeformtes JSON.
04 · Auditing
Jede Entscheidung ist eine Zeile.
Jeder Override kalibriert den nächsten.
Jede Entscheidung, die Runtime emittiert, schreibt eine Audit-Zeile: welcher Tenant, welche Klasse, welche Optionen betrachtet wurden, welche defaulted wurde, ob HITL getriggert wurde, ob der Reviewer overrided hat und warum. Jeder Override ist ein typisiertes Event, das die nächste Iteration des Generators speist. Compliance beantwortet “wer hat der KI gesagt, das zu tun?” mit einer einzigen Query. Unter EU AI Act Art. 13 (Transparenz) IST die Audit-Zeile der Trail.
proposed → reviewer:pending → approved
│
└──→ overridden → rationale captured
→ triad classification
→ generator calibration eventaudit_row {
decision_id: lead-qual-2026-06-25-001
class: lead:QualifyingDecision
tenant: ind-sales-pilot
proposed_at: 2026-06-25T11:42:18Z
options_hash: sha256 7a3f…
default_option: opt-2
hitl_status: approved
reviewer: u_9c2e…
reviewer_at: 2026-06-25T12:01:04Z
override: none
provenance: PROV-O:activity/…
}Architektur-Notiz
Reviewer-State, Override-Rationale und Provenienz sind dieselbe Zeile. Es gibt keine separate Audit-Datenbank, kein separates Override-Log, keinen separaten Provenienz-Store. Compliance queryt gegen den Audit-Trail; der Generator queryt denselben Trail zur Kalibrierung.
05 · In Produktion
Von CRM-Optimierung zu Decision Engineering.
Runtime unter echten kommerziellen Use-Cases.
Die Startseite teast die CRM-Optimierungsfalle an. Hier wird sie aufgemacht. Eine Sales-Org auf einem modernen CRM hat Felder, Workflows, Integrationen — alles, was ein Record-Keeping-System braucht. Was fehlt, ist eine typisierte Repräsentation der Entscheidungsmomente: welcher Lead qualifiziert, welchen Deal eskalieren, welche kommerzielle Kondition nachgeben. Diese Momente leben als Fließtext im CRM, als Slack-Threads, als menschliches Tacit-Knowledge. Genau das typisiert Runtime.
01 · Die Optimierungsfalle
Das CRM einer Sales-Org erfasst Aktivitäten. Es erfasst nicht das Reasoning hinter den Aktivitäten. Während KI die Pipeline mit Drafts, Briefings und Empfehlungen flutet, wird die Reasoning-Lücke zum Bottleneck — niemand kann reviewen, niemand kann overriden, niemand kann tracen. Die Antwort des CRM lautet: mehr Felder, mehr Workflows. Das ist Optimierung, keine Transformation.
02 · Der Decision-Engine-Shift
Runtime typisiert die Entscheidungsmomente, die das CRM als Text stehen lässt. Jeder Moment wird zu einer Klasse im Tenant-Kernel. Jeder Aufruf wird zu einer typisierten ChoiceArchitecture. Jedes Reviewer-Sign-off wird zu einer Audit-Zeile. Das CRM bleibt; Runtime sitzt unter der Reasoning-Schicht.
03 · Aktuell im Betrieb
Wir betreiben Runtime gegen echte kommerzielle Use-Cases in Industrieservices in DACH. Deployments unter NDA — Produktion, nicht Proof-of-Concept. Wenn du einen kommerziellen Use-Case in Industrieservices hast und überlegst, wie du die Reasoning-Schicht aus CRM-Text in typisierte Entscheidungen überführst, bewirb dich als Design Partner.
Als Design Partner bewerben06 · Authored With
Author aus Claude Code.
Oder aus jeder MCP-fähigen IDE.
Die Integrations-Strip auf der Startseite nennt Claude Code als primäre Author-Time-Oberfläche. Hier ist der Grund: Unser Tenant-MCP-Server ist ein echter, gehosteter MCP-Endpoint unter api.zunft.ai/mcp/tenant/stream. Jeder Client, der MCP über streamable-HTTP mit OAuth-2.1-Discovery spricht, kann sich verbinden — wir liefern First-Class-Support für Claude Code und gaten andere Clients (Cursor, Cline, Codex) auf Stream-Kompatibilitätsprüfung.
Was der IDE-Agent bekommt
zunft.author_kernel— Kernel-Diffs vorschlagen, validieren, anwendenzunft.introspect_tenant— Klassen, Slots und HITL-Gate-State des aktuellen Tenants lesenzunft.dry_run_kernel— einen Kernel-Diff kompilieren, ohne ihn anzuwenden (prüft Typen + Invarianten)
Wie Auth funktioniert
Der erste MCP-Tool-Call liefert 401 Bearer mit einem resource_metadata-Header zurück. Dein IDE-Agent entdeckt unseren Authorization-Server über /.well-known/oauth-protected-resource, registriert sich dynamisch als OAuth-Client, führt den User per PKCE-Flow durch den Sign-in seines Tenants im Browser und cached das Token lokal. Nachfolgende Calls hängen den Bearer stillschweigend an.
Standards: MCP-Spec 2025-03-26 · OAuth 2.1 (RFC 8252) · JWKS-Token- Verifikation.
07 · Runs On
Runtime ist Protocol-First.
Wir betreiben LangGraph und Windmill unter der Haube.
Row 2 der Integrations-Strip auf der Startseite nennt drei Protocol-Oberflächen und zwei operative Frameworks. Protokolle halten dich Framework-agnostisch: Jeder Orchestrator, der HTTP oder MCP spricht, kann eine typisierte Entscheidung aufrufen oder ein typisiertes Schema lesen. LangGraph und Windmill sind namentlich genannt, weil wir sie selbst betreiben — sie sind keine Partnerschafts-Badges, sondern First-Party- Operational-Truth.
Protocol-Oberflächen
HTTP
REST-Endpoints für Schema-Introspection, Plan-Dispatch, Action- Invocation, Audit-Query. Framework-agnostisch.
MCP
Dieselbe Tool-Oberfläche (author, generate, audit) für IDE-Agents exponiert (siehe Sektion 06).
Python SDK
Per-Tenant-typisierte Klassen, vom Compiler emittiert.
importund nutzen — kein Schema-Roundtrip.
Operative Frameworks, die wir betreiben
LangGraph
Innerhalb von Runtime für Multi-Step-Agent-Flows genutzt, die Entscheidungen mit Retrieval und Action komponieren.
Windmill
Als durable Workflow-Schicht für lang laufende Operationen genutzt, die Prozess-Restarts überleben müssen.
08 · Multi-Tenant, By Design
Per-Tenant-Kernel. Per-Tenant-Datenbank.
Tenants ownen ihre Kernels. Operators sehen die Daten nicht.
Einen Tenant hinzuzufügen heißt: einen Kernel authoren und kompilieren. Keine Plattform-Code- Änderungen. Die dreischichtige Architektur operiert gegen jeden Tenant identisch, weil das universelle Vokabular via imports: in Scope ist und Tenant- Typen von Schema-Primitiven ableiten. Per-Tenant-Datenbank-Schemas isolieren Daten auf der Storage-Schicht, nicht auf der Application-Schicht.
01
Per-Tenant-Kernel
Jeder Tenant authored und ownt sein typisiertes Schema. Die Plattform kompiliert es zur Runtime in typisierte Klassen. Cross-Tenant-Patterns können als reusable Primitives extrahiert werden — aber niemals als Tenant-Daten.
02
Datensouveränität
Per-Tenant-Datenbank-Schema. Operators sehen keine Tenant-Zeilen. Reviewer-, Override- und Audit-Oberflächen laufen innerhalb der Tenant-Identität des Tenants, nicht der des Operators.
03
Compliance-Posture
DSGVO · EU AI Act Art. 13 Audit-Trail · Sovereign Cloud deploybar · SOC 2 (in Arbeit) · ISO 27001 (in Arbeit). Compliance ist ein Runtime-Concern, kein Bolt-on.