Über uns

Warum ich
lynox gebaut habe.

Ich bin 37. Die erste Website, die ich gebaut habe, war die meiner Eltern, mit zwölf — handgeschriebenes HTML und CSS. Der Weg von dort bis hierher ist die Geschichte hier drunter.

Zwölf bis siebenunddreissig

Von dieser ersten Homepage ging es weiter mit einer IT-Lehre und einem eidg. Diplom als Web Project Manager, danach ein professioneller Weg, den ich nicht wirklich geplant hatte: Mit Mitte zwanzig habe ich ein Entwicklungsteam von 10+ Personen bei einem der grösseren Unternehmen geleitet, für die ich gearbeitet habe. 15+ Jahre lang habe ich in der langweiligen-aber-wichtigen Schicht digitaler Arbeit für B2B- und B2C-Schweizer-Unternehmen gesteckt — Analytics, Ads, SEO, Tag Manager, Systemintegration, daten-getriebenes Marketing und die DSGVO-Compliance-Plumberei, die das alles für ein reguliertes Geschäft überhaupt deployable macht. Ich führe nebenbei eine kleine Agentur namens Brandfusion, wo dieselben Skills auf echte Kundendaten angewandt werden: echte Kampagnen, echte Analytics-Streams, echte Strategy-Reviews auf echten Zahlen. Genau diese Arbeit hat mir gezeigt, wie kaputt die operative Schicht kleiner Unternehmen ist.

Der Bruchpunkt

Ende 2025 bin ich ertrunken. Nicht in Kunden — die waren in Ordnung. In Tools. CRM hier, Automation-Engine dort, ChatGPT fürs Denken, GA4 für Analytics, die Ad-Plattformen, das CMS, die Buchhaltung, der E-Mail-Host, der Projekt-Tracker. Jeden Montagmorgen tippte ich denselben Kontext in drei verschiedene Fenster, damit jedes Tool 'verstand', was ich gerade tat. Die Daten sassen in Silos. Die Intelligenz sass in einem anderen Silo. Die zwei zu verbinden war Handarbeit. Da hatte ich AutoGPT schon seit Release ausprobiert — so klumpig es war, die Richtung war klar. Das würde verändern, wie operative Arbeit gemacht wird. Vor sechs Monaten habe ich angefangen, alles, was ich konnte, durch Claude Code zu fahren. Es wurde mein Playground für das Gefühl, was ein Agent-Loop in der Praxis ist. Das Ding ist extrem mächtig für Entwickler — aber Kommandozeilen-Agents werden nie ein kleines Business betreiben. Die CLI ist falsch für Business-Operatoren. Cross-Thread-Memory ist falsch. Neue APIs anbinden ist falsch. Nichts davon ist bereit für jemanden, der nicht schon Entwickler ist.

Personal Assistant vs Professional Agent

Anfang 2026 habe ich die OSS-Landschaft evaluiert. Ich habe kurz OpenClaw angeschaut, dann Agent Zero in einem Wochenend-Projekt ausprobiert. Mir hat Agent Zero gefallen — saubere Architektur, gute Loops. Aber damit es zu meiner tatsächlichen Arbeitsweise passt, hätte ich das Meiste neu bauen müssen. Es gibt einen Kategorien-Split, den die meisten verpassen. Die OSS-Landschaft, die ich evaluiert habe — OpenClaw, Agent Zero, die Post-AutoGPT-Welle — ist voll mit *Personal-Assistant*-Projekten. Sie optimieren für individuelle Kreativität: Chat mit einem schlauen LLM, schau zu, wie es ein paar Tools nutzt, sieh was passiert. Grossartige Hobby-Spielwiesen. 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 performt hat, die echte Zahlen aus Analytics und Ads zieht, wenn ich frage 'wo verliere ich Geld', die Montags KPI-Review auf Cron fährt, egal ob ich online bin oder nicht, die einen verschlüsselten Vault für die OAuth-Tokens hat, die sie braucht, und der ich einen regulierten Schweizer B2B-Auftrag übergeben kann, ohne eine separate Compliance-Schicht zusammenzuhacken. Personal-Assistant-Projekte gehen davon aus, dass du am Agent iterierst. Professional Agents gehen davon aus, dass du am *Business* iterierst und der Agent leise nachzieht. Das ist eine andere Architektur. (Manche nennen die Kategorie 'Business Agent'. Ich bevorzuge 'Professional Agent', weil die Zielgruppe Solo-Operatoren, Consultants und kleine Agenturen sind — Profis, die sich nicht immer mit dem Wort 'Business' identifizieren, sich aber absolut als Menschen identifizieren, die operative Arbeit richtig erledigt haben wollen.)

Die invertierte 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 gerade emergieren sah, war die Umkehrung: Menschen haben Agents, und die Agents kleben 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 aus Shopify', 'sprich mit meinem Stripe' — und lynox liest die Doku, baut ein typisiertes Integrations-Profil, nutzt es für immer. Wiederkehrende Arbeit wird als Workflow aufgezeichnet und geplant. Knowledge-Graph-Entities — Kunden, Deals, KPIs, Kampagnen — sammeln sich an. Der Agent macht das Wiring. Ich habe lynox ursprünglich nur für mich selbst bei Brandfusion gebaut — um operative Last von meiner Liste zu nehmen. Das Projekt ist schnell gewachsen, weil es funktioniert hat. Etwa einen Monat nach dem Public-Go ist lynox produktiv bei Brandfusion und frühen Self-Hostern im Einsatz.

Warum source-available

Ich habe absichtlich die Elastic License v2 gewählt statt einer OSI-approved Lizenz. ELv2 erlaubt jedem, den Code zu lesen, zu modifizieren, für das eigene Business oder die eigenen Kunden zu deployen und frei zu forken. Die eine Einschränkung: niemand darf lynox als konkurrierenden Managed-Service anbieten — genau der Zug, der genug Open-Source-Companies umgebracht hat, dass es wichtig ist. Die Lizenz-FAQ ist eine eigene Seite; lesenswert, falls dir der Trade-off wichtig ist.

Wohin es geht

lynox wird heute solo gewartet und wächst in ein kleines Team hinein. Öffentliche Roadmap, Fork-Rechte für immer, transparente Preise. Falls das Projekt je den Besitzer wechselt oder pivotet, läuft die Engine, die du bereits deployed hast, weiter — das ist, was source-available wirklich bedeutet. Es ist nicht für Chat-Bastler. Es ist für Menschen, die wollen, dass ihr Business-Operations laufen, während sie die Arbeit machen, die nur sie machen können. Wenn das du bist, ist die Engine, die du willst, im Repo.