Preparing Loomfield for the Public

Loomfield already does real work. That isn't the same thing as being ready for people who don't have me sitting beside it.

For most of the private beta, I can fill in the gaps without thinking about it. I know why a control exists, which rough edge is harmless, and what a session was trying to do when the result isn't quite right. A new user won't know any of that, and they shouldn't have to.

Preparing Loomfield for a public launch means pulling that private knowledge out of my head. The product has to explain what it is, show what it can do today, hold its boundaries when I'm not there, and recover cleanly when something goes wrong.

Private beta can borrow from the builder

A private beta is good at proving whether the core idea survives real work. I can use Loomfield across projects, watch where sessions lose the thread, and fix the parts that create friction. That gets the system out of diagrams and into the day.

It can also hide product problems. If I recognize an internal term, work around a rough screen, or manually reconnect a stalled handoff, the job still gets done. The system looks more complete than it would to someone seeing it for the first time.

That's the line I'm working through now. Loomfield can't depend on me knowing what it meant. The useful path has to be visible on its own.

The work has to be clear without me

A new user shouldn't need to learn an AI-systems vocabulary before doing useful work. They need to see what is moving, what needs a decision, what the system is preparing, and where the result will land.

That changes how I think about Today, Projects, and the Queue. Those aren't product architecture labels. They're answers to ordinary questions: What needs me now? What are we trying to finish? What is waiting, and why?

The same standard applies to product claims. Running now, private beta, and planned can't blur together because the idea is exciting. A public product has to tell people which parts they can rely on today and which parts are still being earned.

One place has to be true

Loomfield's shared project memory is the Weave. Projects, tasks, decisions, procedures, and useful lessons need one current home so a new session doesn't start by guessing which file or conversation is right.

The practical test is simple. Can a session find the current project, load only the part it needs, do the work, and leave the durable result where the next session will see it? If the answer only exists in chat, the system hasn't really learned anything.

This matters even more when the AI provider changes. Claude, Codex, and whatever comes next should be able to sit down at the same workbench. The project owns the memory. The model gets the turn.

Trust has to show up in the behavior

A warning label isn't a security model, and a path restriction isn't enough by itself. Authority has to be enforced where the action happens. A proposed action should stay proposed until the person with the decision confirms it.

The same goes for completion. A session saying it changed something isn't proof that the right change landed. Loomfield needs to read the result back, compare it with the intended state, and stop when the evidence doesn't line up.

I'm not trying to remove the person from the system. I'm trying to make their control specific. The user should be able to see what the system knows, what it wants to do, what it actually changed, and where it needs a decision.

The website is part of the product

The new Loomfield site is the first real public front door for the product. That doesn't make the public launch complete. It does force the story to make sense outside my own notes and screens.

The site has to answer the basic questions in plain language. What problem does Loomfield solve? What stays under the user's control? What works now? What is still in private beta? A visitor shouldn't have to reverse-engineer the architecture to understand the value.

That work has helped the product too. Every sentence that is hard to explain points back to something that may still be too complicated, too implicit, or not clearly bounded inside the system.

Preparing without pretending

Loomfield is still in private beta. The next stretch is onboarding, recovery, clearer state, more outside use, and the small pieces of polish that only show up when someone else tries to do the work.

So I'm opening a waitlist instead of declaring a finish line. The public front door at loomfield.ai is live, you can request early access there now, and I'll bring people in as the onboarding and recovery work makes the system genuinely ready to leave my room.

I'm excited about the public launch, but I don't want to manufacture a finish line. The standard is not whether the page is live or the label changes. It's whether a person can bring Loomfield real work, understand what it is doing, stay in control, and come back tomorrow with the project in better shape.

That's what I'm preparing for now: a product that can leave the room with its builder and still make sense.