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. From there 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, the DSGVO-compliance plumbing 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 engine 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.
Personal assistant vs professional agent
In early 2026 I evaluated the open-source landscape. I 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 had to rebuild most of it.
There’s a category split most people miss. The OSS landscape I evaluated — OpenClaw, Agent Zero, the post-AutoGPT wave — is full of personal assistant projects. They optimise for individual creativity: chat to a smart LLM, watch it use a few tools, see what happens. They’re great hobby playgrounds.
What I needed was a professional agent. Not a clever chatbot, but a runtime 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 the OAuth tokens it needs, that I can hand a regulated Swiss B2B engagement to without hacking together a separate compliance layer.
Personal-assistant projects assume you’ll iterate on the agent. Professional agents assume you’ll iterate on the business and the agent quietly keeps up. That’s a different architecture.
The inverted bet
Around the same time I sat down to start building n8n flows for my own agency. I stopped within an hour. The shape of the problem was wrong.
n8n and its peers assume the future is humans wiring systems together. The actual future I was watching emerge was the inverse: humans have agents, and the agents wire the systems. So why build flows by hand at all? If the agent is capable enough, you tell it which API you want to use, and it figures out the rest.
That insight is what lynox is. One runtime. One chat. One persistent memory that compounds across conversations. You describe what you want connected — “connect HubSpot”, “I need to pull from Shopify”, “talk to my Stripe” — and lynox reads the docs, builds a typed integration profile, reuses it forever. Recurring work gets captured as a workflow and scheduled. Knowledge Graph entities — clients, deals, KPIs, campaigns — accumulate over time.
It’s the agent that does the wiring.
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 exactly the move that has killed enough open-source companies for this to matter.
Your business data shouldn’t live in someone else’s cloud. You should be able to switch AI providers with one environment variable. When a SaaS company shuts down, your data shouldn’t disappear with it. lynox runs on your server. SQLite files. Move them with scp. The worst case is that lynox disappears — and your data files still work.
Where it stands
I started building lynox originally just for myself in Brandfusion — to take operational load off my plate. The project grew quickly because it kept working. Roughly one month after going public, it has 5 pilot customers running production workloads — 3 on managed hosting, 2 self-hosting.
It’s not for chat-fiddlers. It’s for people who want their business operations to run while they do the work only they can do.
npx @lynox-ai/coreIf that’s you, the engine you want is in the repo.