For two months, I didn’t ship a single feature of my product.
OwlMeans is an AI development pipeline — you describe what you want as user stories, and a team of specialized AI roles turns them into full-stack apps you actually own. That is the thing I am supposed to be building. And from the middle of April to the middle of June, I barely touched it.
I wasn’t stuck. I wasn’t pivoting. I made a deliberate detour to build something else first: an agentic operating system for the company itself. A single place where I run development, strategy, and marketing — the same work I do every week — with the agents doing the heavy lifting and almost no overhead on me.
I don’t regret a day of it. Here is what I built, why I built it, and why I think the structure matters far more than the tool you run it on.
Why I walked away from the product
Here is the uncomfortable part. I am building a company whose entire promise is escape the mess that AI coding leaves behind — own software you can actually maintain. And meanwhile I was running the company itself like a pile of disconnected vibe-coded scripts.
Strategy lived in one place. Brand notes in another. The website in a third. Marketing copy got written from scratch every time because nothing remembered what we had already decided. Every conversation with an AI assistant started cold — I re-explained who we are, what we sell, what we don’t say in public, what changed last month. The agent was smart. The agent also forgot everything the moment I closed the window.
That is the dirty secret of working with coding agents today, and the research backs it up bluntly: tools like Claude Code have no real persistent memory — continuity only exists if you build it yourself out of “structured documentation, not the model’s internal memory.” The smartest model in the world still wakes up with amnesia every session.
So the problem I needed to solve for the company was the same one I am solving for customers in the product: turn a brilliant-but-forgetful generator into something with structure, memory, and discipline. I decided to solve it for myself first. If it worked, I would understand my own product better. If it didn’t, better to learn that on my own time than a client’s.
What I actually built
Not an app. Not a platform with a login screen. A structure — a folder of plain markdown files that any capable agent can read and act on. Three layers sit inside it.
A wiki that compounds. Every fact about the company lives in versioned markdown: strategy, brand voice, the naming rules, customer personas, legal, product positioning. When I learn something, it gets written down once. The next time any agent works on anything, that knowledge is already in the room. Nothing is re-derived from scratch. The wiki gets smarter every week without me maintaining it as a chore — it grows as a side effect of doing the work.
Skills that teach the agent how I work. A skill is just a markdown file describing a repeatable workflow — how to research and write an article, how to keep the website and the wiki in sync, how to update legal documents, how to run exhaustive research. I have twenty-six of them now. They are self-learning in the sense that matters: when I correct the agent, the correction goes back into the skill or the memory, and the mistake doesn’t come back. This is exactly what the industry figured out this year — “context engineering is the key thing,” structuring the information around the prompt instead of polishing the prompt itself.
Every project, linked in. More than twenty of our code repositories are attached to the workspace, including OwlMeans Common — the shared TypeScript foundation and project structure that our coding agents build on. So the same discipline runs from a strategy note all the way down into the source code. I can point the agent at any repo, ask what changed between two dates, and get a written digest — or turn that digest straight into a release post.
On top of those three layers sits a pipeline. An idea goes in; the agent researches it against live sources, drafts the piece in our voice, generates the images, and — when I say so — publishes it to the blog, which is itself just part of the website source. The article you are reading went through that pipeline. I dictated the idea in a few sentences. Everything else, including the research links above, the agent assembled.
How everyone else solves this — and why I went a different way
I am not the only person trying to run a business on top of AI agents. But almost everyone is doing it one of three ways, and each one has the same gap.
The bare agent. Most people just open a coding agent and start typing. It is genuinely good. It is also amnesiac — the whole reason people write up elaborate “second brain” setups is that the tool forgets between sessions and you spend your life re-explaining context. You get a brilliant intern who never keeps a single note.
A different coding agent. The open-source world now has excellent alternatives — OpenCode supports seventy-five-plus model providers, Aider is the git-native terminal favorite with forty-thousand-plus stars, Cline lives in your editor, OpenHands runs fully autonomous in a sandbox. They are all model-agnostic, and switching to them can cut your model bill by around sixty percent. But notice what they are: they are coding agents. Swapping one for another changes the engine. None of them hands you a company knowledge base, a brand-discipline layer, or a content pipeline. The agent was never the hard part.
A multi-agent framework. Then there is orchestration — Hermes and its kind, where a lead agent decomposes a task and spawns specialist workers that pass typed results back. Powerful for coordinating agents on a single complex job. But it is an engine you still have to wire up, and it is aimed at task execution, not at being the place your whole company lives. It does nothing for your strategy notes or your website.
Even the most impressive “we run our agency on Claude” write-ups I found — a Chief-of-Staff intake agent, ad-account monitors, natural-language querying over their data, three years of best practices fed into a transcription bot — are assembled with mountains of bespoke integration glue, and the author still calls himself “0.01% of the way there.”
Here is the thing all three approaches taught me: the value was never in the agent. The agent is a commodity now — you can swap it tomorrow. The value is in the structure that surrounds it. The wiki that remembers. The skills that encode how you work. The links between your knowledge and your code and your public-facing site. That structure is what I built, and it is plain text. It does not belong to any one tool.
What it gives me
The detour paid for itself faster than I expected.
- Knowledge compounds instead of evaporating. Every decision, pivot, and customer insight lands in the wiki the moment it happens. I never start cold again.
- There is no gap between thinking and publishing. The same brain that holds the strategy writes the blog post and updates the website. No copy-paste, no context switch, no “let me explain the company again.”
- Discipline is enforced, not remembered. Our naming rules and the claims we are allowed to make in public are baked into the skills. The agent doesn’t slip and use an internal name in a customer-facing post, because the structure won’t let it.
- The work I dreaded is now ambient. Release notes, research, marketing copy — the things that used to pile up because they needed a context-loading ritual — now take a sentence of intent.
How hard is it to set up
This is the part that surprised me most: it is almost all text.
The entry point is a single CLAUDE.md file that the agent reads first, every session, as the ground truth — that is a documented, native behavior, not a hack. Skills are folders with a markdown file inside; no code required. The wiki is markdown. Linking your repositories in is a matter of symlinks — nothing moves, nothing is copied. And because it is all plain files, the same structure works for GitHub Copilot too: I keep a mirror of the instructions where Copilot reads them, so the agent on my code follows the exact same playbook as the agent on my strategy.
I run mine on Claude Code today. But nothing about the structure is tied to it. Point Copilot, Cursor, OpenCode, or a local model at the same folders and the company still works the same way — because the company lives in the files, not in the agent.
I’ll build this for you
I built this for myself. I will build it for you too.
If you are running a company on top of AI agents and feeling the same friction — every session starting cold, knowledge trapped in your head, your tools and your strategy and your marketing living in separate worlds — that is exactly the problem this structure solves. OwlMeans now offers to deploy a complete agentic operating system for your company:
- On the agents and models you already use. Claude, Copilot, Cursor, OpenCode, a self-hosted open-weight model — the structure is agent-agnostic by design. We tune it to your stack, not the other way around.
- Self-learning from day one. Your wiki starts compounding immediately; the skills encode how your team actually works and get sharper every time you correct them.
- Everything integrated. Development, strategy, content, and your public site stop being separate jobs and start being one connected system.
- Yours to own. It is plain files in your repositories. No lock-in, no platform you depend on, nothing to rent. The same principle as our product: you keep what we build.
I spent two months proving to myself that the structure beats the tool. You can skip the two months.
OwlMeans is an AI development pipeline: describe what you want as user stories and get full-stack apps, chatbots, AI agents, and data pipelines — typed, SSO-ready, and yours to keep building with any agent. Want the same agentic operating system running your company? Let’s talk →