J_OS

I wanted a record, not an operating system

I began by using AI, before I had a name for a way of working with it. In Google AI Studio, and later Antigravity, useful conversations turned into decisions, experiments and things I wanted to build. I needed a way to keep what mattered when the conversation moved on.

Over more than half a year, that request for a record grew into J_OS. The work changed my understanding of AI agents, and that understanding kept changing the system. J_OS became a project about how I work, alongside the apps I was making.

A shared memory, beyond one conversation

The first versions took shape around Antigravity. Obsidian and linked Markdown notes gave the work a place to live outside a chat: what a project was for, decisions already made, and lessons I did not want to lose.

When Codex joined, those records had to make sense to another working environment. Some instructions belonged to the project; others only made sense in one tool. Separating the two helped J_OS become less dependent on a single agent or platform.

ChatGPT, which I call G, also became a planning and review partner alongside Codex, C, and Antigravity, J. The letters were useful shorthand. The harder question was how to share enough understanding without making me carry every message between them.

The board worked. The working model did not fit.

J_OS Desk was an attempt to bring that collaboration into one place. An Obsidian board held work cards, assignments and returned results. A connection between the board and the agents let work move between them. There was real implementation, testing and a successful round of hands-on acceptance.

I did not continue using it after that acceptance. The board assumed a pattern of coordination that my everyday work did not really need. When the agents could already use the task record directly, another board risked becoming another place to keep in step.

I paused its routine use and further development. That was a product lesson rather than a verdict that the code was broken: I had built a plausible answer before establishing that this was how I wanted to work.

Better agents changed the rules I needed

Some rules began as a response to a real mistake: the wrong project, a forgotten decision, an unsupported claim that work was finished. Keeping those lessons mattered. Keeping every procedure forever was a different matter.

As the agents became more capable, I had to revisit instructions that prescribed too much ordinary engineering. A capable collaborator should be able to investigate, choose files and repair a bounded problem. I needed to make the purpose, limits and decisions clear, then leave room to work.

The September changes pushed J_OS back towards one person working with capable tools. I did not want to manage an imaginary software department before I could make progress. Another agent or another handoff should earn its place by improving the result.

Keep the lesson, give the live work one home

A record can help a new conversation begin with understanding. It can also make an old decision look current after the work has changed. More memory did not automatically mean better context.

I moved live task progress into Linear and kept lasting project knowledge in J_OS. The current task explains what is happening now. The project notes explain its purpose and important decisions. The actual code, tests and running app show what has really been built.

That separation reduced the need to copy the same status into several records. It also made a useful habit more explicit: history can explain a decision without becoming today’s instruction.

Still shaping, with people in view

The current work explores letting Codex coordinate bounded pieces of a larger, agreed plan, with other perspectives checking the combined result. Smaller tasks can stay with one capable agent. I still decide the product direction, try the experience and approve consequential changes.

October brought a useful reminder that fewer rules alone is not the goal. Agents working on My Next Step could still drift towards technically confident users. J_OS now makes a small project foundation explicit: who the tool is for, what those people need, and which decisions must survive a change of agent or conversation.

I am still learning which structure helps, which gets in the way, and when to take it away. The question is no longer how much I can make the agents follow. It is how to give them enough shared understanding to do useful work, while keeping the decisions that should remain mine.

Still in progress

Two reflections from this project