Warum ich lynox gebaut habe

Ich bin 37. Die erste Website, die ich live geschaltet habe, war die Homepage meiner Eltern, mit zwölf — handgeschriebenes HTML und CSS. Danach IT-Lehre und eidg. Diplom als Web Project Manager, dann ein professioneller Weg, den ich nicht wirklich geplant hatte: Mit Mitte zwanzig habe ich ein Entwicklungsteam von 10+ Personen geleitet, bei einer der grösseren Firmen, für die ich tätig war.

15+ Jahre lang habe ich in der langweiligen-aber-wichtigen Schicht digitaler Arbeit gesteckt — Analytics, Ads, SEO, Tag Manager, Systemintegration, die DSGVO-Compliance-Plumberei, die das alles für ein reguliertes Geschäft überhaupt einsetzbar macht. Nebenbei führe ich eine kleine Agentur namens Brandfusion, in der dieselben Skills auf echte Kundendaten angewandt werden: echte Kampagnen, echte Analytics-Streams, echte Strategy-Reviews auf echten Zahlen.

Genau diese Arbeit hat mir auch gezeigt, wie kaputt die operative Schicht kleiner Unternehmen ist.

Der Bruchpunkt

Ende 2025 bin ich ertrunken. Nicht in Agentur-Kunden — die waren in Ordnung. In Tools.

CRM da, Automation-Engine dort, ChatGPT fürs Denken, GA4 für die Zahlen, die Ad-Plattformen, das CMS, die Buchhaltung, der Mail-Host, das Projekt-Tool. Jeden Montagmorgen habe ich denselben Kontext in drei verschiedene Fenster getippt, damit jedes Tool “versteht”, was ich gerade tue. Die Daten sassen in Silos. Die Intelligenz sass in einem anderen Silo. Das Verbinden war Handarbeit.

Und zu dem Zeitpunkt hatte ich schon seit dem Launch mit AutoGPT herumgespielt — so klobig wie das war, die Richtung war klar. Das wird verändern, wie operative Arbeit gemacht wird.

Vor einem halben Jahr habe ich angefangen, alles Mögliche durch Claude Code laufen zu lassen. Es wurde mein Spielplatz, um zu spüren, wie sich ein Agent-Loop in der Praxis anfühlt. Das Ding ist unfassbar mächtig für Entwickler — aber Command-Line-Agents werden nie ein Kleinunternehmen führen. Das CLI ist falsch für Business-Operators. Cross-Thread-Memory ist falsch. Neue APIs anschliessen ist falsch. Nichts davon ist bereit für jemanden, der nicht schon Entwickler ist.

Persönlicher Assistent vs Professional Agent

Anfang 2026 habe ich die Open-Source-Landschaft evaluiert. Habe kurz OpenClaw angeschaut, dann Agent Zero an einem Wochenende ausprobiert. Agent Zero hat mir gefallen — saubere Architektur, gute Loops. Aber um zu passen, wie ich tatsächlich arbeite, hätte ich das meiste neu bauen müssen.

Es gibt einen Kategorie-Split, den die meisten übersehen. Die OSS-Landschaft, die ich evaluiert habe — OpenClaw, Agent Zero, die Post-AutoGPT-Welle — besteht aus persönlichen Assistenten. Sie optimieren für individuelle Kreativität: Chat mit einem schlauen LLM, schau zu wie es ein paar Tools benutzt, beobachte was passiert. Tolle Hobby-Spielplätze.

Was ich brauchte, war ein Professional Agent. Kein cleverer Chatbot, sondern eine Runtime, die meine Kunden über Konversationen hinweg kennt, die sich erinnert, welche Kampagne letztes Quartal lief, die Live-Zahlen aus Analytics und Ads holt, wenn ich frage “wo verliere ich gerade Geld”, die Montags den KPI-Review als Cron-Job fährt, egal ob ich online bin oder nicht, die einen verschlüsselten Vault für die OAuth-Tokens hat, die ich brauche, der ich ein reguliertes Schweizer B2B-Mandat übergeben kann, ohne separat eine Compliance-Schicht zusammenzuhacken.

Persönliche-Assistenten-Projekte nehmen an, du iterierst am Agenten. Professional Agents nehmen an, du iterierst am Geschäft und der Agent zieht im Hintergrund nach. Das ist eine andere Architektur.

Die umgekehrte Wette

Etwa zur gleichen Zeit habe ich mich hingesetzt, um n8n-Flows für meine eigene Agentur zu bauen. Ich habe nach einer Stunde aufgehört. Die Form des Problems war falsch.

n8n und seinesgleichen gehen davon aus, dass die Zukunft Menschen sind, die Systeme zusammenkleben. Die echte Zukunft, die ich emergieren sah, war die Umkehrung: Menschen haben Agenten, und die Agenten verkleben die Systeme. Wieso also überhaupt Flows von Hand bauen? Wenn der Agent fähig genug ist, sagst du ihm welche API du nutzen willst, und er findet den Rest.

Dieser Insight ist, was lynox ist. Eine Runtime. Ein Chat. Ein persistentes Memory, das über Konversationen hinweg zusammenwächst. Du beschreibst, was du verbinden willst — “verbinde HubSpot”, “ich brauche Daten aus Shopify”, “sprich mit meinem Stripe” — und lynox liest die Doku, baut ein typisiertes Integrations-Profil, nutzt es immer wieder. Wiederkehrende Arbeit wird als Workflow aufgezeichnet und geplant. Knowledge-Graph-Entities — Kunden, Deals, KPIs, Kampagnen — sammeln sich an.

Es ist der Agent, der das Wiring macht.

Warum source-available

Ich habe die Elastic License v2 statt einer OSI-zertifizierten Lizenz mit Absicht gewählt. ELv2 lässt jeden den Code lesen, modifizieren, für sein eigenes Geschäft oder seine Kunden deployen und frei forken. Die eine Einschränkung: niemand darf lynox als konkurrierenden Managed-Service anbieten — genau die Bewegung, die genug Open-Source-Firmen ruiniert hat, damit das wichtig ist.

Deine Business-Daten sollten nicht in der Cloud von jemand anderem leben. Du solltest deinen AI-Provider mit einer Environment-Variable wechseln können. Wenn eine SaaS-Firma dichtmacht, sollten deine Daten nicht mit verschwinden. lynox läuft auf deinem Server. SQLite-Dateien. Mit scp verschiebbar. Worst case: lynox verschwindet — und deine Datendateien funktionieren weiter.

Wo es steht

Ich habe lynox ursprünglich nur für mich selbst bei Brandfusion gebaut — um operative Last von meinem Tisch zu nehmen. Das Projekt ist schnell gewachsen, weil es funktioniert hat. Etwa einen Monat nachdem es public ist, hat lynox 5 Pilot-Kunden in produktiver Nutzung — 3 auf Managed-Hosting, 2 self-hosting.

Es ist nicht für Chat-Tüftler. Es ist für Leute, die wollen, dass ihre Business-Operations laufen, während sie die Arbeit machen, die nur sie machen können.

npx @lynox-ai/core

Wenn das du bist, liegt die Engine, die du willst, im Repo.