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-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 OSS 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. (Some call this category 'business agent'. I prefer 'professional agent' because the audience is solo operators, consultants, and small agencies — professionals who don't always identify with the word 'business', but who absolutely identify as people running operational work that needs to be done right.)
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. 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. About a month after going public it's in production at Brandfusion and with early self-hosters.
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. 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 engine you've already deployed keeps running — that's what source-available actually means. 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. If that's you, the engine you want is in the repo.