Episode 007: Where We Are Now

For the last several weeks, this series has mostly followed one problem into the next. I started with a business that had accumulated enough moving pieces that keeping everything organized in my own head was becoming increasingly difficult. AI helped, but simply giving it more information created its own problems. That led to structure, the structure became departments, the departments became a Business OS, and then I had to teach that system how I actually wanted it to work. Once it started working better, I discovered how dependent I had become on individual conversations, which led to the work in Episode 006 around separating conversations from memory and figuring out how the business could continue when a chat eventually ended. None of this was planned as a neat progression when I started. Each problem became visible because the previous solution worked well enough to expose the next one.

That is probably a good place to stop for a moment and look at what actually exists now.

JW Designs has a Business OS that is real enough that I use it every day. It has departments with different responsibilities. It has current-state records that tell those departments where the business actually stands rather than forcing them to reconstruct everything from months of conversation history. It has a Company Wiki that preserves the things I do not want disappearing when a chat gets replaced. It has operating rules for ownership, handoffs, reporting, and decision-making. It has already survived replacing several of the conversations that originally helped create it. At the same time, it is still very obviously something being built by one guy running a small manufacturing company in between product development, production, customers, marketing, and a full-time career. Some parts work remarkably well. Some parts are still manual. Some rules have already been rewritten because the first version created more work than it saved. New capabilities keep appearing that challenge assumptions I made only a few weeks earlier.

That makes this a useful point to take inventory, not because the system is finished, but because it has reached the point where I no longer think of it primarily as something I am building. Increasingly, it is something I am using.

“The Business OS did not reach a finish line. It reached the point where it became useful enough to live with.”

A Lot Has Changed Without Looking Dramatic

Most of the improvements lately have not been big architectural moments. They have been small corrections that happened because I used the system and something annoyed me.

A department would receive a handoff and then repeat the entire handoff back to me, explaining why the work belonged there even though I had just pasted it into the correct department. That technically followed the structure, but it defeated the purpose of reducing my workload, so the rule changed. Departments started producing the correct information for the CEO Dashboard but formatting it differently every time, which meant I was constantly fixing the output before moving it. That led to another small rule. At one point the system interpreted the need to preserve current state so aggressively that almost every useful conversation seemed to create another file-maintenance task for me. That was safe from a documentation perspective and ridiculous from an operating perspective, so we changed the standard to update state when something meaningful changed rather than treating every conversation like a database transaction.

None of those changes would make a very exciting diagram. They are probably more important than a lot of the diagrams I could make.

That has become one of the recurring lessons of this whole experiment. I can design a rule that sounds perfectly reasonable until I actually have to live with it. The moment I find myself doing unnecessary administrative work because the Business OS told me to, I have to remember what the system is for. It exists to remove friction from running JW Designs. It does not get extra credit for being technically complete if I am spending my evening maintaining it instead of building products, answering customers, or doing something else that actually moves the business forward.

The system has therefore been changing incrementally. A transfer gets shorter. A reporting rule gets clearer. A department learns not to hand work back to itself. A current-state record gets separated from permanent documentation. A replacement chat retrieves the information it needs instead of relying on an old conversation continuing forever. Most of the progress looks less like building a new operating system and more like tightening bolts on a machine that is already running.

“The useful changes have usually started with a very simple question: why am I still having to do this?”

Then One of My Assumptions Changed

One of the more interesting discoveries happened almost by accident.

A lot of the continuity work described in Episode 006 was built around what appeared to be a fairly hard boundary between conversations. If I moved from one department chat to another, I assumed the new conversation could not reliably know what had happened elsewhere unless the important information had been deliberately preserved in the Business OS. That assumption was reasonable based on how the system had behaved, and it led to some good architecture. Important knowledge moved into permanent records. Departments received current-state files. Conversations became replaceable workspaces rather than places I was terrified to lose.

Then I started using High thinking mode more heavily.

What I saw was not what I expected. In several cases the system was able to reach across conversations and recover surprisingly useful context. It was not simply remembering that another discussion existed. It could sometimes pick up enough of the thread to continue meaningful work. The most obvious example involved this series itself. A newer workspace was able to recover creative context from an older Business OS Development conversation well enough to continue an article that I had previously assumed needed to stay in the original chat because the writing rhythm would not transfer cleanly.

That does not mean I suddenly know exactly how this capability works. I do not. I have not tested the limits. I do not know how consistently it can find an obscure decision six months later, how it behaves when two conversations contain conflicting information, how far creative continuity can really be pushed, or whether what worked well once will work equally well every time. I am treating it the same way I would treat a new material or piece of shop equipment. The capability is interesting. The early results are promising. That is not the same thing as having a validated specification.

But it matters, because one of the assumptions behind the current Business OS may be changing.

“Sometimes the system improves because I redesign it. Sometimes the technology moves underneath it.”

The interesting part is that the discovery did not make the existing architecture pointless. In fact, almost immediately, it showed why the structure still mattered.

The CEO Dashboard was able to recover enough context from another workspace to continue creative work that actually belonged to Business OS Development. From a continuity perspective, that was impressive. From an ownership perspective, it was wrong. The system had enough context to do the work, so it simply did it. The boundary that had once been enforced partly by lack of information suddenly became easier to cross.

That created a new lesson almost immediately: having access to the context does not mean a department owns the work.

That distinction becomes more important as the technology gets better. When the system could not easily reach across conversations, some department boundaries were naturally reinforced by information boundaries. If those information boundaries become increasingly transparent, then ownership has to come from the operating model rather than from what a particular conversation happens to know.

In other words, better continuity could reduce one of my biggest frustrations while making the organizational structure more important, not less.

Maybe There Is a 2.0 Eventually

It would be very easy for me to see something like cross-chat continuity improving and immediately start redesigning the entire Business OS around it. That is exactly the kind of thing I am trying not to do anymore.

The current system works.

That matters more than whether it is the architecture I would design from scratch if I started today.

The local records still provide something conversational continuity does not: an explicit source of truth. The current-state records still solve the problem of knowing what is true now rather than merely finding something that was discussed before. Department ownership still tells the system which workspace should actually execute the work. The Company Wiki still gives permanent business knowledge somewhere to live that does not depend on the behavior of any particular AI model or feature. None of those things become bad ideas because the AI suddenly gets better at finding historical context.

What may change is how much effort is required to connect them.

That is where I can imagine a future Business OS 2.0 eventually coming from. Not because I have decided that the current system needs to be replaced, and definitely not because I want another architecture project to occupy my evenings. It would come from enough incremental changes accumulating that the simplest way to operate the business eventually becomes different from the one I use today.

Maybe stronger continuity means fewer manual transfers. Maybe better connections to the software I already use reduce the amount of file handling. Maybe the system eventually becomes better at recognizing where work belongs before I have to move it. Maybe some of the current-state maintenance becomes more automatic. Maybe a future version uses capabilities that do not exist yet.

For now, those are possibilities, not requirements.

I am much more interested in observing what actually becomes useful than designing around what might become possible.

“Version 2.0 should happen because Version 1.0 eventually becomes inconvenient, not because I get bored and want to redesign it.”

That is a surprisingly difficult rule for me to follow because I enjoy this kind of work. There is something satisfying about seeing a system become cleaner. But that can become its own trap. Every hour spent improving the Business OS is an hour that has to justify why it was not spent somewhere else.

That tradeoff is becoming especially real right now.

The Business Still Has to Fit Around Real Life

My available time is about to get tighter.

JW Designs is a real small business, but it is also one I am building alongside a full-time career. There have been stretches where I have had enough room to spend an evening working through a Business OS problem, redesigning a lid, testing a material, or improving some part of the manufacturing process simply because I wanted to keep pushing it forward. Other stretches are going to look different. Work gets busy. Life gets busy. There are still only so many hours in a day, and I cannot solve that problem by pretending otherwise.

In a strange way, that may be one of the better tests the Business OS could face.

It is easy to build an elaborate system when I have plenty of time to think about the system. The real value should appear when I do not. If I only have a small window to work on JW Designs, I need to be able to see what matters quickly. I need Operations to know what production work is active. I need Engineering to preserve a technical thread when I have to walk away from it for several days. I need Sales and Marketing to maintain enough continuity that I am not reconstructing everything every time I come back. I need ideas in Business Development to wait without disappearing or becoming emergencies simply because I have not looked at them in a week.

Most importantly, I need the Business OS to accept that sometimes the correct decision is to do less.

There will be weeks when improving the system sounds interesting and is still the wrong use of my limited time. There will be weeks when the right move is to fill orders, keep customers happy, handle everything else competing for my attention, and leave the rest alone. A useful operating system should make those choices easier, not become one more thing demanding attention.

That may be the best test I have found so far.

“The real test is not whether the system works when I have time. It is whether it still helps when I do not.”

So Where Are We?

The answer is somewhere between prototype and infrastructure.

The Business OS is far beyond the idea stage. I use it. It has survived real work. It has failed in real ways and been corrected. Departments have been replaced without losing the company. Important knowledge has moved out of individual conversations. The CEO Dashboard gives me a useful view of what is happening. Engineering, Operations, Sales and Marketing, Business Development, Company Wiki, and Business OS Development increasingly behave like different parts of the business instead of different labels on identical AI chats.

At the same time, I am still the connective tissue in plenty of places. I still move information manually. I still catch the system doing work in the wrong department. I still occasionally discover that a rule I created to reduce cognitive load has somehow invented three new administrative steps. I am still learning what the technology can actually do, and sometimes a new capability changes my understanding of what should be possible.

That no longer bothers me as much as it would have earlier in this process.

I think I spent the first part of this project trying to reach a point where the architecture would feel finished. I am increasingly convinced that point does not exist. JW Designs itself is not finished. The products are not finished. The manufacturing process is not finished. My understanding of the market is not finished. The tools I use will keep changing. The AI will certainly keep changing. Expecting the operating system around all of that to reach some permanent final form would be a strange standard to apply.

What matters is whether the current version helps me run the company I actually have today.

Right now, it does.

And that feels like a reasonable place to close the first chapter of this story.

“I stopped asking whether the Business OS was finished and started asking whether it was helping me run the business.”

The Next Chapter Is Really About the Business

There is one thing I have deliberately avoided doing too much in these first episodes.

I have talked about the departments, but I have not really explained why they exist.

It would be easy to show a diagram with seven boxes and describe the responsibilities of each one. That would probably be the least interesting way to tell the story. None of the departments were created because I thought JW Designs needed to look like a larger company. They exist because certain kinds of work kept colliding with each other.

Engineering exists because technical decisions need a different kind of thinking than production decisions. Operations exists because proving that something can be built is different from building it repeatedly, efficiently, and without surprises. Sales and Marketing exists because getting attention and turning that attention into customers is its own problem. Business Development exists because I needed somewhere for interesting opportunities to be evaluated without every interesting idea hijacking the business. Company Wiki exists because useful knowledge needed somewhere permanent to live. Business OS Development exists because eventually the system itself became something that needed to be designed and maintained. And the CEO Dashboard exists because somewhere above all of that I still need a place to decide what actually deserves my attention.

Those distinctions make much more sense when they are explained through the problems that created them.

So that is probably where this series goes next.

The first chapter was about why I ended up building an operating system around a small manufacturing business and what happened as I tried to make it work.

The next chapter can be about what is actually inside it.

Not the architecture first.

The problems first.

Because, just like everything else in this project, the departments did not begin with an organizational chart.

They began when something in the business became difficult enough that I needed a better way to handle it.