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)

Per-Plugin-scoped Routes (/api/:pluginId/...) mit Per-Account-Auth. Tender hat eigenes Sub-Routing. Auth via Supabase JWT, Legacy-API-Key als Admin-Fallback.

03

Module-Layer

Domain-Logik: outreach-sdr, tender-match. Jedes Modul ist ein eigenständiges Bundle aus Manifest, Engines, Routes, Workers. Stateless designed (Phase B).

04

Kernel-Layer

Plattform-Primitiven: Plugin-Registry, EventBus, JobQueue, Connectors, Vault, Memory (pgvector-RAG), Audit-Tracker, LLM-Provider-Pool. Alle Module dürfen das nutzen, niemand muss es kennen.

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 mit 14 Memory-Typen (successful_email, objection, regional_learning, tender_won, tender_lost, …). 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 in das Win-Probability-Scoring von Outreach-Leads ein wenn die CPV-Codes überlappen. Das ist der Plattform-Vorteil gegenüber Stand-alone-Tools.

LLM-Routing

3-Tier-Routing zwischen Haiku (Klassifikation, Extraktion), Sonnet (Standard-Generation), Opus (Bid-Drafting, Compliance). 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.

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.

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.

Plugin-Isolation

Postgres Row-Level-Security auf allen mandantengetrennten Tabellen. Service-Role bypassed (Agent-Server), App-Sessions sehen nur ihren Plugin-Scope.

Soft-Delete + History

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

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 + Inbound)

Tender

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

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. Diese Klarheit ist warum wir bei Custom-Modul-Anfragen (Recruiting-Agent, Renewal-Agent, Support-Triage) realistisch 1-Wochen-Lieferzeit nennen können.

Custom-Modul-Anfrage →