From the middle of April to the middle of June, I barely touched the features of my product.
I was building OwlMeans, a development pipeline that turns user stories into software. Meanwhile, the work around it was scattered. Strategy, brand notes, research and website copy lived in different places.
Every time I asked an agent for help, I explained the company again.
I spent two months changing that. I built the workspace I now use for company knowledge and recurring work.
The problem showed up in ordinary tasks.
An article needed the current positioning. A site edit needed the product’s actual capabilities. A research task needed the customer question we were trying to answer.
The same facts were relevant each time, but I was still supplying them by hand. Sometimes I forgot a qualification. Sometimes a draft used a message that belonged to an earlier version of the company.
A capable agent could work with the material I gave it. I had not given it a dependable place to find that material.
That distinction mattered. I could improve the prompt for each task, or make the company’s working knowledge easier to retrieve and update. I chose the second job.
The shared record
I put the company wiki in Markdown.
It holds strategy, customer knowledge, brand rules and product documentation. The folder indexes tell an agent where to look. A page has a specific subject, and a new finding belongs beside the knowledge it changes.
That sounds like filing. Much of it is.
Research and execution can use the same record. When an article needs a product fact, the agent has a place to check it. When a site edit exposes an outdated fact, the wiki has a place for the correction.
The record still needs judgement. An untested market belief does not become true because an agent put it in a well-organized folder. We keep open hypotheses separate from settled knowledge.
The next layer was skills.
I wrote down workflows I repeated: research, article preparation, site synchronization and the maintenance of product documentation. Each skill describes the task and the local rules that are easy to miss.
A correction can then improve the next run. It has to be written back into the appropriate guidance; the model does not permanently learn the company because I corrected it in chat.
A skill can become stale, just as a document can. Someone has to check that its procedure still matches the tools and the work.
The Agent Skills specification supplies the shared folder and metadata format. The instructions inside our skills are still ours to write and maintain.
The code beside the company
I also linked our repositories into the workspace.
That made a practical difference to writing. A release article could start from the implementation rather than a recollection of what we meant to ship. Technical documentation could distinguish committed code from an idea in a roadmap.
The connection does not remove the distinction between those sources. A design document describes intent. A commit shows an implementation. Neither proves that a particular customer workflow has been exercised successfully.
For a company that sells an AI development pipeline, keeping those distinctions visible is part of the work.
The article workflow gave the structure an immediate use.
I could dictate the subject, have the agent check our wiki and external sources, prepare a draft and pass it through the writing review. Images and social adaptations were separate steps. Publication happened only when requested.
The facts no longer had to travel from my memory into every prompt.
The same arrangement helped with site work. The public page and the internal explanation could be reconciled while both were available.
It did not make the company operate without me. I still chose what to publish, checked the claims and decided which work deserved attention.
This experience also informs our Services work. Defining the workflow and preparing a handoff matter alongside writing the software. They need a concrete scope for the customer’s project, rather than a promise that an agent will run the business.
The memory files
The June version of this story described the context files I was using then. That setup has since changed.
By October, our shared guidance lived under AGENTS.md and a common skills directory, with a small CLAUDE.md bridge where needed. The separate agent-specific instruction copies were no longer the arrangement to follow.
Claude Code’s current memory documentation distinguishes project instructions and automatic memory. That makes the old blanket claim that the tool has no persistent memory inappropriate.
Our company record serves a different purpose. It states what OwlMeans has decided, what evidence supports a product claim and which workflow applies to the task. I need that record to remain inspectable across tools.
The harness rework story describes the later repository structure in more detail.
What it cost
Two months is a large detour for a solo founder.
The workspace made repeated work easier to pick up, but creating it delayed product features. It also created an ongoing obligation: instructions and knowledge have to stay current.
I would make the same investment again because I use the structure in my work. I would start smaller if I were doing it again. A reliable record for a few recurring jobs is useful before it becomes a system for the whole company.
Revised 15 October 2026. The April–June detour is unchanged; the repository-layout and memory descriptions above distinguish the original setup from the current one.