Brezel CompanyOS Strategy

Dieses Papier dient als Referenz für die nächste Entwicklungsphase von Brezel. Es übersetzt die bestehende Stärke von Brezel in eine Produkt- und Plattformstrategie für die AI-Transition.

Kurzfassung

Brezel sollte nicht gegen generisches “vibe coding” antreten. Brezel sollte die Plattform sein, in der Unternehmenswissen dauerhaft modelliert, ausgeführt, erklärt, versioniert und sicher verändert wird.

Die zentrale These lautet:

LLMs können schnell Software improvisieren. Brezel macht Unternehmenslogik dauerhaft, prüfbar und betreibbar.

Ausgangslage

Brezel bringt bereits Eigenschaften mit, die für eine AI-native Unternehmensplattform entscheidend sind:

deklarative Systemdefinitionen über Bakery-Ressourcen
strukturierte Module, Felder, Layouts, Rollen und Menüs
ausführbare Workflows als kodierte Geschäftslogik
reale Kundenprojekte mit gewachsenem Domänenwissen
klare Systemgrenzen über systems/<system>/
wiederverwendbares Skeleton und Installer für reproduzierbare Setups

Reale Brezel-Systeme wie brezels/kab zeigen bereits, dass Brezel mehr ist als ein CRUD-Generator:

viele produktive Workflows
domänenspezifische Prozesslogik
gewachsene UI- und Datenstrukturen
operative Tiefe statt nur Konfigurationshülle

Genau diese Tiefe ist der Burggraben.

Problem

Die Gefahr durch AI ist nicht primär, dass LLMs Brezel technisch ersetzen. Die Gefahr ist, dass der Markt Brezel als austauschbares ERP-Framework wahrnimmt, während AI-generierte Individualsoftware zunächst schneller und zugänglicher wirkt.

Wenn Brezel nur als “Framework zum Bauen von Business-Software” positioniert bleibt, konkurriert es direkt mit:

Low-Code/No-Code
AI App Buildern
Agent-generierter Individualsoftware
Standard-SaaS-Werkzeugen mit AI-Schicht

Das ist die falsche Arena.

Strategische Positionierung

Brezel wird als CompanyOS positioniert.

CompanyOS bedeutet:

Das System of Record für Unternehmenswissen
Die Runtime für Prozesse, Rollen, Regeln und Entscheidungen
Der Ort, an dem Spezifikationen, Workflows, Policies und Ausführung zusammenlaufen
Die sichere Brücke zwischen Fachlichkeit, Betrieb und AI

Die Subline dazu kann je nach Zielgruppe variieren:

The AI-native CompanyOS for operational businesses
The operating system for company knowledge and workflows
Where business logic, process knowledge and execution live

Produktthese

Die Kernthese für Produkt und Vermarktung lautet:

Unternehmen brauchen nicht nur Software.
Unternehmen brauchen ein dauerhaftes Gedächtnis für ihre Abläufe, Regeln und Entscheidungen.
AI wird nur dann produktiv, wenn dieses Wissen strukturiert, auffindbar und ausführbar vorliegt.
Brezel kann genau diese Schicht werden.

North Star

Brezel wird die bevorzugte Plattform für Unternehmen, die ihre Abläufe nicht nur digitalisieren, sondern semantisch modellieren, sicher automatisieren und mit AI weiterentwickeln wollen.

Was Brezel nicht sein sollte

kein reiner Prompt-to-App-Baukasten
kein offenes “baue alles irgendwie”-Versprechen
kein Feature-Clone generischer ERP-Suiten
kein AI-Demo-Produkt ohne harte Betriebsfähigkeit

Was Brezel sein sollte

ein belastbares operatives System für Unternehmen
ein semantischer Layer über Business-Objekten und Workflows
ein sicherer Änderungsraum für AI-unterstützte Weiterentwicklung
ein Wissensspeicher mit Ausführungskontext
eine Plattform, die bestehendes Domänenwissen konserviert statt verwässert

Zielgruppen

Primär

bestehende Brezel-Kunden mit kodiertem Domänenwissen
KMU und Mid-Market-Unternehmen mit individuellen Prozessen
Agenturen und Umsetzungspartner, die wiederkehrende Geschäftslogik produktisieren wollen

Sekundär

neue Unternehmen, die kein generisches ERP, sondern ein anpassbares Betriebsmodell brauchen
AI-affine Teams, die Kontrolle und Revisionssicherheit brauchen
Branchen mit hoher Prozessdichte und Sonderlogik

Kernversprechen

Für Bestandskunden

“Euer Domänenwissen bleibt nicht nur erhalten, sondern wird AI-lesbar, erklärbar und sicher weiterentwickelbar.”

Für Neukunden

“Ihr müsst eure Firma nicht an starre Software anpassen. Ihr modelliert eure Realität in einem System, das AI verstehen und erweitern kann.”

Für Partner und Entwickler

“Brezel ist die Runtime, in der AI-generierte Änderungen nicht im luftleeren Raum passieren, sondern auf einer stabilen, versionierbaren Struktur landen.”

Strategische Prinzipien

Read before write AI muss bestehende Brezel-Systeme zuerst verstehen, bevor sie sie verändern darf.
Semantic over synthetic Nicht die Menge generierten Codes ist entscheidend, sondern die fachliche Klarheit der Modelle.
Safe change management AI-Änderungen brauchen Diffs, Impact-Analyse, Vorschau, Review und Rollback.
Existing customers first Die bestehende installierte Basis ist Vermögenswert, Trainingsgrundlage und Marktbeweis.
Declarative leverage Alles, was schon strukturiert ist, muss für AI nutzbar gemacht werden, bevor neue freie Konfigurationsformen entstehen.
Company memory as product Entscheidungen, Policies, Spezifikationen und Prozesse gehören ins Produkt, nicht nur in Notion, PDFs oder Köpfe.

Produktarchitektur für die nächste Phase

Die CompanyOS-Strategie benötigt fünf zusätzliche Produkt-Schichten über dem bestehenden Framework.

1. Semantic Layer

Jede zentrale Ressource braucht neben technischer Struktur eine fachliche Beschreibung.

Beispiele:

module purpose
business owner
inputs
outputs
invariants
risks
related workflows
human explanation
AI editing hints

Diese Schicht sollte zuerst auf bestehenden Bakery-Ressourcen aufsetzen und nicht als paralleles System entstehen.

2. Knowledge Layer

Neben Modulen und Workflows braucht Brezel erstklassige Artefakte für:

Spezifikationen
Architecture Decision Records
Policies
Prozessbeschreibungen
Terminologie/Glossare
Entscheidungshistorien
Betriebsnotizen und Ausnahmen

Diese Artefakte müssen referenzierbar mit Ressourcen und Workflows verbunden sein.

3. AI Workspace

Eine AI-Oberfläche in Brezel sollte nicht “magisch bauen”, sondern kontrolliert arbeiten:

Anforderungen analysieren
passende Module/Workflows/Rollen vorschlagen
Auswirkungen auf bestehende Ressourcen erklären
konkrete Diffs erzeugen
semantische Lücken benennen
Änderungsvorschläge zur Freigabe stellen

4. Change Safety Layer

AI-Änderungen müssen über einen sicheren Änderungsprozess laufen:

Vorschlag
fachliche Erklärung
technische Diff-Ansicht
Impact-Analyse
Simulation/Test
Freigabe
Apply
Versionierung und Rollback

Ein zentraler Bestandteil dieser Schicht ist testbare Geschäftslogik auf drei Ebenen:

Unit-Tests für einzelne Workflow-Element-Typen
Integrations-Tests für Workflow-Dispatch, Ports, Persistenz und Engine-Verhalten
Business-Workflow-Tests auf konkreter System- bzw. Unternehmensinstanz-Ebene

5. SaaS Control Plane

Wenn Brezel als SaaS angeboten wird, braucht es eine standardisierte Betriebs- und Mandantenkontrollschicht:

Provisioning
Tenant/System-Erzeugung
Pläne und Limits
sichere Defaults
Upgrades
Telemetrie
Feature Flags
Support- und Recovery-Werkzeuge

Produkt-Roadmap

Phase 1: Brezel lesbar machen

Zeitrahmen: 0 bis 6 Wochen

Ziel: Bestehende Brezel-Systeme werden für Menschen und LLMs transparent und erklärbar.

Deliverables:

kanonisches Ressourceninventar pro System
Identifier-Index für Module, Felder, Workflows, Rollen und Menüs
lesbare Systemzusammenfassung je system
Workflow-Katalog mit Triggern, Abhängigkeiten und Seiteneffekten
Grundlagen für semantische Annotationen

Erfolgskriterium: Eine Person oder ein Agent kann ein vorhandenes Brezel-System zuverlässig verstehen, ohne sich mühsam durch Rohdateien zu hangeln.

Phase 2: Semantik standardisieren

Zeitrahmen: 4 bis 10 Wochen

Ziel: Brezel-Ressourcen bekommen ein kanonisches semantisches Meta-Modell.

Deliverables:

Schema für semantische Metadaten
Konventionen für Module, Workflows, Rollen und Entscheidungen
erster Satz annotierter Referenzsysteme
Validierung und Dokumentation im Wiki

Erfolgskriterium: Fachliche Bedeutung ist strukturiert auslesbar und nicht nur implizit im Setup verborgen.

Phase 3: Sichere AI-Assistenz

Zeitrahmen: 8 bis 16 Wochen

Ziel: AI kann Brezel-Systeme erklären, prüfen und kontrolliert verändern.

Deliverables:

Analyse- und Erklärmodus
Vorschlagsmodus für neue Ressourcen oder Änderungen
Diff- und Impact-Ansichten
Freigabefluss für Änderungen
erste Guardrails für riskante Änderungen
testbare Change-Proposals mit Workflow-Testausführung vor Apply

Erfolgskriterium: AI erhöht Geschwindigkeit, ohne die Betriebsstabilität zu gefährden.

Phase 4: Vertikales Self-Serve SaaS

Zeitrahmen: 12 bis 24 Wochen

Ziel: Ein enger, marktfähiger Self-Serve-Einstieg wird produktiv.

Empfohlene Einstiegsformen:

Service-/Operations-ERP für kleine bis mittlere Betriebe
CRM + Auftragsabwicklung + Dokumente + Workflows
CompanyOS für agenturgeprägte oder projektgetriebene Organisationen

Erfolgskriterium: Ein neuer Kunde kann ohne individuelles Projektgeschäft zu einem lauffähigen, kontrollierbaren System gelangen.

Bestehende Kunden absichern

Bestandskunden sind kein Legacy-Problem, sondern der zentrale strategische Vermögenswert.

Das Programm für Bestandskunden sollte enthalten:

System-Audits
semantische Anreicherung bestehender Ressourcen
Workflow-Inventarisierung
AI-Lesbarmachung der Kundenlogik
Migrationspfade auf neue SaaS- und CompanyOS-Funktionen

Ziele:

Retention absichern
Upsell in AI- und Knowledge-Funktionen ermöglichen
hochwertige Referenzdaten für Produktverbesserung gewinnen

SEO- und AEO-Strategie

Das Endziel ist nicht nur Suchmaschinenpräsenz, sondern Assoziation in menschlichen und maschinellen Antworten.

Brezel sollte thematisch mit folgenden Problemräumen verknüpft werden:

CompanyOS
AI-ready ERP
enterprise knowledge runtime
semantic workflows
operational memory
AI-safe business process management
executable business knowledge

Content-Pfeiler

What is a CompanyOS?
Why AI-generated internal tools break at process depth
How to turn undocumented business logic into executable systems
Semantic workflows vs. brittle automations
How SMEs can become AI-ready without replacing their operations

AEO-Prinzip

Inhalte müssen so strukturiert sein, dass Frontier-Modelle daraus robuste Antworten ableiten können:

klare Begriffsdefinitionen
starke Informationsarchitektur
explizite Vergleiche
wiederholbare Terminologie
belastbare Beispiele
öffentlich dokumentierte Patterns

90-Tage-Plan

Stream 1: Positionierung

Ergebnisse:

Messaging House
neue Narrative für Website und Vertrieb
definierte ICPs
Abgrenzung gegen AI App Builder, ERP-Suiten und No-Code

Stream 2: Meta-Modell

Ergebnisse:

Spezifikation für semantische Annotationen
Referenzbeispiele
Dokumentation
Validierungsregeln

Stream 3: System Readability

Ergebnisse:

Tooling zum Indexieren von Systemen
Workflow-Maps
Explainability-Dokumente
technische Basis für Agenten

Stream 4: Safe AI Changes

Ergebnisse:

Diff-Modell
Änderungsfreigaben
Risk Flags
Preview/Simulation
Workflow-Testpyramide für Framework und Systemebene

Stream 5: SaaS Foundation

Ergebnisse:

Provisioning-Modell
Tenant-Control-Plane-Konzept
Plan- und Limitmodell
Standard-Onboarding

Priorisierte Entwicklungsinitiativen

Die nächsten Entwicklungsarbeiten sollten sich in dieser Reihenfolge orientieren:

System-Scanner und Ressourcenindex für bestehende Brezel-Installationen
Semantisches Metadatenmodell für Module und Workflows
Dokumentierte Explainability-Ausgabe für Systeme
Änderungsmodell für AI-generierte Vorschläge
SaaS-Provisioning auf Basis von Installer und Skeleton

Konkrete erste Artefakte

Diese Artefakte sollten als Nächstes entstehen:

ein formales Brezel Semantic Metadata Schema
ein system explain-Mechanismus für bestehende Installationen
ein workflow catalog-Artefakt für jedes System
ein change proposal-Format für AI-Vorschläge
ein standardisiertes workflow test-Konzept für Engine und Business-Workflows
eine Produktseite und Doku-Seite zu CompanyOS

Mögliche technische Übersetzung

Die vorhandene Brezel-Struktur legt nahe, zuerst im deklarativen Modell anzusetzen:

Erweiterung von Bakery-Ressourcen um semantische Metadaten
Exportierbare Indizes für systems/<system>/
Tooling zur Ableitung von Systemgraphen
Einbettung in Installer, Skeleton und Doku
spätere Integration in API und SPA

Entscheidungsregeln

Für die kommende Entwicklung gelten folgende Regeln:

Neue AI-Funktionen müssen Bestandslogik respektieren.
Jede wichtige Ressource braucht eine menschenlesbare und maschinenlesbare Bedeutung.
Änderungen ohne Diff, Erklärung und Rücknahmeoption sind nicht produktionsreif.
Self-Serve wird erst dann breit, wenn Guardrails und Betriebsmodell belastbar sind.
Dokumentation ist kein Nebenprodukt, sondern Teil der Plattform.

Offene Produktfragen

Diese Fragen sollten früh explizit beantwortet werden:

Wie genau werden semantische Metadaten gespeichert und validiert?
Welche AI-Funktionen laufen lokal im Produkt, welche extern?
Wie sieht der Freigabeprozess für AI-generierte Änderungen aus?
Was ist der erste enge SaaS-Use-Case?
Welche Bestandskunden eignen sich als Design Partner?

Empfehlung für den nächsten Schritt

Der sinnvollste nächste Umsetzungsschritt ist nicht direkt ein großer SaaS-Bau.

Der erste Stream sollte lauten:

Make Brezel systems explainable.

Wenn Brezel-Systeme zuverlässig ausgelesen, erklärt, katalogisiert und semantisch annotiert werden können, entsteht daraus fast alles Weitere:

AI-Assistenten
Kundenmigration
Wissensspeicher
Change-Safety
SaaS-Onboarding
SEO- und AEO-fähige öffentliche Narrative

Arbeitsauftrag an die nächste Entwicklungsphase

Die nächste Entwicklungsphase startet mit drei konkreten Aufgaben:

Ressourcen und Workflows bestehender Systeme maschinenlesbar inventarisieren.
Ein semantisches Metadatenmodell für Brezel definieren.
Eine erste Explainability-Schicht für Systeme, Module und Workflows bauen.

Damit verschiebt sich Brezel von einem konfigurierbaren ERP-Framework zu einer AI-nativen Ausführungs- und Wissensplattform für Unternehmen.