Stellwerk

Architektur

Ein Kernel.Beliebig viele Module.

Stellwerk ist keine Sammlung verbundener Tools, sondern eine Plattform mit klar getrennten Schichten. Module teilen sich Kernel, Memory, Audit, Connectoren — und werden trotzdem unabhängig deployt. Diese Seite ist für CTOs, IT-Leiter und Compliance- Verantwortliche, die wissen wollen wie es technisch tickt.

Schichten

Vier Layer, klar getrennt

01

Frontend-Layer

Marketing-Sites + Workspace. Next.js 16, Tailwind, Server-Components. Marketing-Sites sind statisch und SEO-optimiert; Workspace ist session-gebunden.

02

API-Layer (Hono)

Modul-eigene Mounts (/api/outreach-sdr/:pluginId/…, /api/tender/:pluginId/…, /api/cadastre/:pluginId/…) mit zentraler plugin_domains-Whitelist (30 s Cache). Auth via Supabase JWT, Legacy-API-Key als Admin-Fallback, Enterprise-API-Keys mit SHA256-Hash + Rate-Limiting.

03

Module-Layer

Domain-Logik: outreach-sdr (~92 Engines), tender-match (~22 Engines), cadastre (6 Engines, NDS-Pilot). Jedes Modul ist ein eigenständiges Bundle aus Manifest, Engines, Routes, Workers, eigener Job-Queue + EventBus. Stateless designed — Module können unabhängig scaled werden.

04

Kernel-Layer

Plattform-Primitiven: Plugin-Registry, EventBus (Wildcards), JobQueue (Retry+Backoff), Connectors (Builtin + Custom), Vault (AES-256-GCM), Memory (pgvector-RAG, 14 Memory-Typen), Audit-Tracker, LLM-Provider-Pool (3-Tier-Routing), Supabase-Storage (Dossier- + Grundbuch-PDFs), PostGIS (Geometrie-Queries für Cadastre).

Plugin-Modell

Ein Plugin = ein Kunde, ein oder mehrere Module aktiv

Ein Plugin trägt die Identity (Sender-Email, Legal-Daten, Branche, Memory). Welche Module für das Plugin aktiv sind, steht in plugin_domains. Cross-Tenant-Isolation passiert auf zwei Ebenen: App-Code filtert strikt auf plugin_id, plus Postgres-RLS als Defense-in-Depth.

Was zum Plugin gehört

  • Sender-Identity + Legal-Footer
  • Branchen-Kontext + Knowledge-Base
  • Aktive Module (plugin_domains)
  • Eigene Memory (pgvector)
  • Stripe-Subscription
  • API-Keys mit Plugin-Scoping

Was Account-Level liegt

  • Plan + max_plugins (Tarif-Gate)
  • Account-Members (RBAC: owner/admin/member)
  • Pilot-Status + Eligibility
  • Stripe-Customer + Billing
  • Cross-Plugin-Reporting (für Agenturen)

AI-Layer

Memory + LLM-Routing

Memory (pgvector)

Jedes Plugin hat einen eigenen Memory-Korpus. Memory-Typen spannen alle Module: successful_email, objection, regional_learning, tender_won, tender_lost, cadastre_risk_assessed, cadastre_dossier_generated, owner_outreach_replied, … pgvector-Embeddings für semantische Recall-Queries. Cross-Plugin-Knowledge gibt es nicht — was ein Plugin lernt bleibt im Plugin.

Cross-Modul-Lernen

Innerhalb eines Plugins teilen sich die Module den Memory. Ein tender_won auf einer Branche fließt ins Win-Probability-Scoring von Outreach-Leads, wenn die CPV-Codes überlappen. Cadastre identifizierte Eigentümer landen mit personalisierten Pacht-/Kauf-Anschreiben direkt in der Outreach-Sequenz — End-to-End vom Standort-Sourcing zur Akquise-Antwort. Das ist der Plattform-Vorteil gegenüber Stand-alone-Tools.

LLM-Routing (3-Tier)

Routing zwischen Haiku (Layout-Klassifikation, Burden-Klassifikation, Subject-Lines), Sonnet (Personalisierung, Grundbuch-Extraktion, Tender-Analyse), Opus (Bid-Drafting, Compliance, juristisches Belastungs- Reasoning, Dossier-Narrative). Spart 40–50 % LLM-Kosten gegenüber „alles Sonnet“. Per-Plugin LLM-Provider-Pool — BYOK-fähig (Enterprise-Kunden zahlen ihren OpenAI/ Anthropic-Bill direkt).

Cost-Tracking

Jeder externe Service-Call (LLM, Google-Maps-API, Resend-Send, Stripe-Transaction) wird per agent_usage_log getrackt mit estimated_cost_micros. Pro Plugin pro Tag aggregierbar — Unit-Economics on Demand.

Compliance

Nicht nachträglich draufgepappt — eingebaut

DSGVO Art. 13

Datenquellen-Hinweis in jedem Outreach-Mail-Footer. Empfänger sieht woher seine Daten kommen, kann Auskunft + Löschung anfordern. Cadastre-Eigentümer-Daten unterliegen demselben Lösch-/Auskunfts-Workflow.

EU AI Act Art. 52

KI-Transparenz: AI-generierter Output an Empfänger ist als solcher gekennzeichnet. Audit-Log dokumentiert wann der Agent eigenständig entschieden hat. Cadastre-Dossiers tragen Quellen-Annotation pro Behauptung — juristisch nachvollziehbar.

UWG §7

HMAC-signierter Opt-Out-Link in jeder Outreach-Mail. Klick → sofort + verifizierbar opt-out, kein doppelter Mail-Empfang.

BGleichB §47 Abs. 2

Vergabe-Audit-Log für Tender-Entscheidungen. Für Behörden-/Bundeskunden mit Nachweis-Pflichten — strukturierter Report on Demand.

§ 12 GBO

Cadastre liest Grundbuch-Auszüge nur per Drag&Drop vom berechtigten Mandanten — kein Auto-Pull aus Amtsgerichts-APIs. Schützt vor Compliance-Risiko und vermeidet § 12 GBO Berechtigtes-Interesse-Prüfung auf Plattform-Ebene.

INSPIRE-Richtlinie

Cadastre-Geo-Layer (BfN, LGLN, NIBIS) sind INSPIRE-konforme öffentliche WMS/WFS-Dienste. Lizenzbedingungen pro Bundesland eingehalten — kein Whitewashing kostenpflichtiger Daten.

Plugin-Isolation

Postgres Row-Level-Security auf allen mandantengetrennten Tabellen (inkl. cadastre_*). Service-Role bypassed (Agent-Server), App-Sessions sehen nur ihren Plugin-Scope. cadastre_grundbuch_documents-Bucket ist private Supabase-Storage, signed-upload-URLs zeitlich begrenzt.

Soft-Delete + History

User-Daten werden soft-gelöscht (deleted_at), Plugin-Configs versioniert (history-Trigger). DSGVO-Lösch-Anfragen + Recovery beide trivial.

Audit-Bridge

Jedes domain-Event (cadastre.dossier.completed, tender.match.won, outreach.handoff.created, …) landet automatisch im agent_audit_log mit plugin_id, correlation_id und Payload. Single-Pane für Operator + Compliance-Auditor.

Workspace-Layer

Control-Levels + Capabilities

Zwei-Achsen-System

Der Workspace hat zwei Steuerungsachsen: Plan (Starter bis Enterprise) setzt die Obergrenze, Control-Level (observe / interact / control) wählt der Kunde selbst. resolveCapabilities(plan, level) liefert granulare Feature-Flags die jede Seite prüft.

Capability-gated UI

Sidebar-Einträge, Buttons, ganze Seiten prüfen capabilities.editTemplates oder capabilities.apiAccess. Gesperrte Items zeigen ein Lock-Icon — Nutzer sehen was möglich wäre, mit klarem Upgrade-Pfad.

Enterprise REST-API

API-Key-Format: sk_live_+ 48 Hex-Zeichen. SHA256-Hash in der DB, Timing-Safe-Comparison bei Validation. Prefix-basiertes DB-Lookup für schnelle Auflösung. Bis zu 10 aktive Keys pro Account.

Rate-Limiting

In-Memory Sliding-Window pro API-Key: 60 req/min (Standard), 300 req/min (Enterprise). X-RateLimit-* Header in jeder Response. API-Key-Auth ist zwischen Legacy-Key und JWT im Role-Guard eingebaut — keine separate Middleware.

Integration

Connectoren — pluggbare Datenquellen

Externe Datenquellen sind Connectors im Kernel. Module deklarieren welche Connectoren sie brauchen, der Kernel liefert sie. Custom- Connectors für proprietäre Quellen lassen sich pro Enterprise- Kunde implementieren ohne Core-Code anzufassen.

Outreach

  • Google Maps Places (Lead-Discovery)
  • Marktstammdatenregister (PV-Daten)
  • Handelsregister-API (Firmendaten)
  • Energieatlas NRW (regional)
  • Resend (Email-Send) + Postmark (Inbound)
  • 14 Lead-Sources DACH (MaStR, HRB, OSM, BNetzA, …)

Tender

  • TED-EU (EU-weite Ausschreibungen)
  • Bund-Vergabe (Bundesebene)
  • DTAD / DTVP (Länder + Kommunen)
  • eVergabe (Custom Enterprise)
  • Calendar-iCal (Frist-Reminder)

Cadastre

  • LGLN-NDS-WFS (ALKIS Niedersachsen)
  • BfN-Schutzgebiete (Natura2000, FFH, Vogelschutz — bundesweit)
  • NLWKN-NDS (Wasserschutz, Naturschutz)
  • NIBIS (Bodeninformationssystem, Altlasten — NDS)
  • Azure Document Intelligence (Grundbuch-OCR)
  • XPlanung (Bauleitplan, Phase 2)

Erweiterbarkeit

Neues Modul: 5-7 Engines + Manifest, ~1 Woche Arbeit

Ein neues Modul ist eine neue Domain unter agent/src/domains/<name>/. Drei Dinge sind nötig:

  1. Manifest — capabilities, schedules, dependencies. Wird vom Kernel beim Boot geladen.
  2. serverBoot-Function — was beim Hochfahren passiert (Worker registrieren, Routes mounten). Stateless.
  3. Engines + Routes — Domain-Logik. Typisch 5-10 Engines pro Modul. Kernel-Primitiven (Memory, Events, Jobs, Connectors) werden über die SDK-Schnittstelle genutzt.

In ALL_DOMAIN_MODULES registrieren — fertig. Keine Änderungen am Kernel oder anderen Modulen. Beweis: Cadastre haben wir mit dieser Architektur in einem Sprint von Manifest auf Pilot-fähig (Backend + Workspace-UI + Admin-UI + Marketing-Site) gehoben — ohne eine Zeile Outreach- oder Tender-Code anzufassen. Custom- Modul-Anfragen (Recruiting-Agent, Renewal-Agent, Support-Triage) liefern wir realistisch in 1–2 Wochen.

Custom-Modul-Anfrage →