Better agents changed the rules I needed.
What I learned from making J_OS lighter without throwing away the lessons that kept the work grounded.
When the project growsAbout 3 min read
A useful rule usually had a reason
Many J_OS rules began after something went wrong. A conversation lost the project’s direction. An agent used an old record as if it described the current code. A completion report sounded more certain than the evidence allowed.
Writing down the lesson was sensible. Over time, however, the accumulated response could become another problem: more context to read, more handoffs to perform, and more work for me to manage before the actual work could begin.
Give the agent the problem and the boundary
As the agents became more capable, I needed to revisit rules written for earlier limitations. Telling a capable coding partner exactly which file to open at every step could prevent it from noticing a better answer in the current source.
I still need to establish what the tool is for, what must be preserved and which decisions need me. Within a clear boundary, ordinary investigation and implementation can belong to the agent. More freedom is useful when it serves an agreed outcome.
A history is not the current task
Keeping more notes can preserve useful decisions and also make an old state look current. In J_OS, I keep lasting project knowledge separate from live task progress in Linear. The current source and running app still matter when a record describes an earlier version.
I would give a new conversation the relevant foundation and the current task, then let it consult the history when a question calls for it. Lasting knowledge is not unchangeable knowledge; it needs revisiting when the project changes.
Simpler does not mean forgetting the person
The September simplification moved away from treating the agents as departments in a software company. One capable agent could continue across ordinary planning, making and checking when another handoff added little value.
But October showed why simplification cannot mean removing every shared requirement. In My Next Step, agents could still imagine a more technically confident user than the person the product was intended to help. A small, explicit project foundation became necessary: purpose, users, their needs and the decisions that should survive a new conversation.
That leaves me with a distinction to keep checking: which instructions protect a real need, and which repeat work the agent already knows how to do?
Keep the responsibility, revisit the method
I still ask for evidence, try the experience myself and decide whether important changes should go ahead. Those responsibilities do not disappear because a model becomes stronger.
The procedure around them can change. I now ask what failure a rule prevents, whether that risk is present in this task, and whether the same protection could be achieved with less ceremony. J_OS is still being shaped by those questions, rather than moving towards a final book of rules.