Why I built
lynox.
I'm 37. The first website I shipped was my parents' homepage when I was twelve — hand-rolled HTML and CSS. The path from there to here is the story below.
Twelve to thirty-seven
From that first homepage it was an IT apprenticeship and a Swiss federal diploma in Web Project Management, then a professional path I never really planned: by my mid-twenties I was leading a development team of 10+ at one of the larger companies I worked for. I've spent 15+ years in the boring-but-important layer of digital work for B2B and B2C Swiss companies — analytics, ads, SEO, Tag Manager, system integration, data-driven marketing, and the DSGVO/GDPR compliance work that makes any of it actually deployable for a regulated business. I run a small agency on the side called Brandfusion, where the same skills get applied to real client data: real campaigns, real analytics streams, real strategic reviews on real numbers. That work is also what showed me how broken the operational layer of small businesses is.
The breaking point
By the end of 2025 I was drowning. Not in agency clients — those were fine. In tools. CRM here, automation tool there, ChatGPT for the thinking, GA4 for the analytics, the ad platforms, the CMS, the accounting, the email host, the project tracker. Every Monday morning I'd retype the same context into three different windows so each tool could 'understand' what I was doing. The data sat in silos. The intelligence sat in another silo. Connecting the two was manual labour. And by then I'd already been playing with AutoGPT since it shipped — clumsy as it was, the trajectory was clear. This was going to change how operational work gets done. Six months ago I started running everything I could through Claude Code. It became my playground for what an agent loop actually felt like in practice. The thing is incredibly powerful for engineers — but command-line agents will never run a small business. The CLI is wrong for business operators. Cross-thread memory is wrong. Hooking up new APIs is wrong. None of it is ready for someone who isn't already a developer.
What the OSS landscape was missing
In early 2026 I evaluated the OSS landscape. Briefly looked at OpenClaw, then tried Agent Zero in a weekend project. I liked Agent Zero — clean architecture, good loops. But to fit how I actually work I'd have rebuilt most of it. The OSS landscape I evaluated — OpenClaw, Agent Zero, the post-AutoGPT wave — is mostly framed around individual experimentation: chat to a smart LLM, watch it use a few tools, see what happens. Great hobby playgrounds. What I needed was different: something that knows my clients across conversations, that remembers which campaign performed last quarter, that pulls live numbers from analytics and ads when I ask 'where am I losing money', that runs Monday's KPI review on cron whether I'm online or not, that has an encrypted vault for OAuth tokens, that I can hand a regulated Swiss B2B engagement to without bolting on a separate compliance layer. The existing OSS tools assume you iterate on the agent. I needed something where I iterate on the business and the agent quietly keeps up.
Why not n8n
Around the same time I sat down to start building n8n flows for my own agency. I stopped within an hour. n8n and similar tools (Zapier, Make) assume the future is humans wiring systems together at higher and higher levels of abstraction. The pattern I was actually watching emerge was the inverse: people use agents, and the agents wire the systems. So why build flows by hand at all? If the agent is capable enough, you describe which API you want to use and it figures out the rest. That's the bet lynox makes. You describe what you want connected — 'connect HubSpot', 'pull from Shopify', 'talk to my Stripe' — and the agent reads the docs and builds a typed integration. Recurring work I do twice gets captured into a workflow and scheduled. There's a graph store underneath that remembers entities (clients, deals, KPIs, campaigns) across conversations. I started building lynox just for myself at Brandfusion to take operational load off my plate. About a month after going public it's in production at Brandfusion and with early self-hosters.
If the project ever changes hands, the copy you already deployed keeps running.
Why source-available
I picked the Elastic License v2 instead of an OSI-approved licence on purpose. ELv2 lets anyone read the code, modify it, deploy it for their own business or their customers, and fork it freely. The one restriction is that nobody can take lynox and offer it as a competing managed service — which is the move that has put commercial pressure on enough open-source companies for this to matter. The licence FAQ is a separate page; it's worth a read if you care about the trade-off.
Where it's heading
lynox is solo-maintained today, growing into a small team. Public roadmap, fork-rights forever, transparent pricing. If the project ever changes hands or pivots, the copy you've already deployed keeps running — that's what source-available actually means. It's for people who want their business operations to run while they do the work only they can do. If that's you, it's all in the repo.