Grow while awake, strengthen the system while asleep: my agentic work loop
WORKFLOWRepeatable working flow.VOICEVoice-driven production.LINEAGEParent/child/relation lineage is required.AI-DEVELOPMENTAI development practice.
I want to show how I actually work right now. This is not an abstract “I work with AI” story. It is the construction site in front of me at that exact moment: how long the agents have been running, why a change is staged, why a rule is loaded, and how this very article comes out of the same loop.
The most honest cover is this: 1049 staged changes and 308 open changes. The numbers are not a “look how much code I wrote” badge. They are the inspection surface in front of me while many agents work in separate lineages on the same construction site.
A multi-agent Source Control surface with 1049 staged and 308 open changes.
I rarely move backward. Most of the system moves forward. I look at what an agent wrote and stage the part I accept. I do not try to create every commit myself because commits slow me down; commit agents close the staged work according to my commit rules. Changes holds work that is still active or not yet inspected.
My goal is not to read every source file in pursuit of a perfect system. I want the system to become visual, visible through the UI, and accountable through logs. When use reveals a break, I want to say: “Something broke. Look at the logs. Who broke this?” The agent follows the real path, checks Git history when needed, and repairs it.
Two energy states, two kinds of work
I use Ghostty. In this moment I am in refactor mode: the systems already exist, and separate agents are working across tabs.
Refactor agents working across separate responsibility areas in Ghostty.
When I have energy, I turn everything in my head into something concrete as fast as possible — even if it is initially broken: software, a running product, something I can see. When my energy runs out, usually after working too much and moving toward burnout, my mind wants lighter work.
I do not discard that time. I distribute agents by dependency chains — what I call lineage trees. I split files down to their real consumers and create smaller units when necessary. Instead of inventing a new product, I strengthen what already exists.
The whole cycle fits into one sentence:
While I am awake I keep trying to grow; while I sleep I focus on resilience. Let the system rest and protect itself while I rest.
What does a long-running agent actually mean?
For anyone curious, here are the active runtimes from that moment. Every one of these sessions is refactor work: one beyond ten hours, one almost twelve, two beyond three hours, and one at twelve hours fifty-three minutes. Some fall into a blocked state; I collect those when I wake up.
A ten-hour Forge refactor session verifying runtime on the second computer.
A Clipboard refactor agent that works in scope and leaves a SLOT at construction-site boundaries.
A Cockpit + terminal refactor session waiting for a foreign build to finish.
A COS refactor agent that follows the real launcher authority without hiding faults.
A Dictation refactor agent translating optional and environment uncertainty into closed states.
Long-running does not mean “leave the agent alone and accept whatever it does.” It means freezing scope, authority, runtime judges and the stop gate at the beginning. If another actor owns the live file, the agent leaves a SLOT. If a real build lock exists, it waits. If an assumed executable does not exist, it keeps the fault visible instead of inventing success.
I close inspection in use, not in source code
I do not care much about raw switch and test counts because checks happen continuously. Night work usually does not invent runtime behavior; it reduces uncertainty inside existing behavior. During inspection I also try not to code. Code makes me think and slows me down, so I stay at the visual layer whenever possible.
Agents run visual checks on my second computer:
The second computer where agents run visual and runtime checks.
Because I use the product continuously, I am always testing it. A break appears in normal use immediately. With voice capture running, that break can become context, a task and then content in the same moment. The general name is dogfooding, but in my loop dogfooding is not merely “using your own product”; it is carrying the friction of use into the agent without losing it.
Lineage: does deletion survive?
By lineage I mean one test: What can I delete before the system breaks? If deleting something breaks the system, it belongs to the same lineage and a real dependency should connect it. If the system survives deletion, the dependency should not exist.
If I can build this well, agents do not collide because they do not touch one another’s responsibility. Their code may live inside one project, but separated lineages reduce conflict. Perfect separation is hard and must be measured again as the system evolves, yet beyond a threshold it becomes a verbal and mechanical contract.
An example lineage that closes from source to receiver surface under one owner.
If one package uses half of a file and another package uses forty percent while nobody uses the whole thing, the agent splits it. Each consumer imports only what it uses. A build dependency does not survive without a runtime dependency. As this continues, duplicate definitions become visible. I call that drift — like assigning one job to two people. The agent routes the responsibility to one owner.
This is how the answer to “Why does this move while that one does not?” can become visible before runtime.
The construction site: share the place, not the scope
Every agent owns a responsibility area. Dictation, Clipboard and Cockpit are not completely isolated; shared code can appear. When I find a problem and do not know the owner, I send it to the likely agents with one instruction:
> “If this is in your scope, solve it. If not, continue your work and report who owns it.”
Clipboard may claim it while Dictation routes it to Clipboard. I coordinate that exchange because agents delete too much context when talking to each other and can drift on long tasks. I still hold the whole human context.
The phrase “you are working on a construction site” reminds an agent that other actors are live. It is not a magic word. Behind it are file lineages, owners, runtime boundaries, local authorities and rules for multi-actor work.
Not implementation prose: a tested principle
I have AGENTS files and a separate rule corpus. Rules are not implementation notes. If code and the compiler already force something mechanically, I do not duplicate it as prose. These are principles discovered while building, tested in multiple places, and important enough that removing them would let the system be built incorrectly.
For example: when the system performs work below the surface, the user must receive feedback. That feedback should not always be text; text forces conscious thought. Depending on the work it may be motion, animation, an image, sound or another form of feedback. This is not an implementation recipe but a principle tested across carriers. I do not declare a rule correct after one use; I may try it in five different places and move it to the right owner only after it keeps working.
This infrastructure did not appear overnight. Counting from my intensive Claude Code work, it represents about a year; the last seven or eight months may be the Mac application I kept refactoring. I rewrote the system repeatedly to understand the rules. That accumulation is why a broad rule, crawl and preflight infrastructure exists now.
I also tried loading rules through a flat file system. My observation was that some Claude/Fable sessions read my rules less consistently because their harness and environment prompts are heavier, while Codex's lighter terminal surface follows the same rules more often. This is not a universal law about the models; it is an observation from my environment. It is exactly why I stopped trusting “the file exists, so the agent will read it” and built anchor plus session telemetry.
The rule for creating rules lives in the prompt itself:
> Would the system definitely be built incorrectly without this rule?
Only a “yes,” combined with the absence of an existing mechanical enforcement, can become a durable rule.
This is the privacy-safe backbone of my refactor prompt. Internal file names, product routes and private implementation details are removed without cutting the useful structure:
Keep the primary target. Change the goal counter only when new scope truly expands done-state.
- Redesign by runtime lineage; move real consumer boundaries into packages and single owners.
- Cut build bonds that have no runtime bond; do not keep independent actors in one file/code lineage.
- Remove impossible state, fabrication, fallback and environment/path/string drift from real runtime code.
- Make action → authority → result accountable with O(1) visibility, dispatch tables and structured logs.
- Close single-writer, parent/lifecycle, duplicate-process and headless/background boundaries across apps.
- Bind permission, storage, hotkey and user-action lineages to predefined feedback/motion/sound policy.
- Prefer native systems; choose custom only when deterministic, zero-false-positive and cheaper to maintain.
- Do not enter another actor’s scope on the construction site. Leave a SLOT; do not add legacy aliases or fallbacks.
- Delete the old path only after the same behavior is measured in the new lineage. Recover missing behavior by migration, not by returning to legacy.My rule labels include [tested], [required], [try] and [useful]. They began as notes for myself, but agents also react to epistemic weight: tested + required is not a casual suggestion. Because agents can fabricate, I mainly carry tested and required rules into autonomous work; I inspect experimental ideas myself.
I do not publish the rule bodies. To show scale and naming, here are the 166 root Markdown surfaces from that moment, names only:
001. action.policy.effect-preview.rules
002. adr.rules
003. agent.contract.attention-index.rules
004. agent.judge.domain-entry.rules
005. agent.policy.decision-state.rules
006. agent.registry.skill-attention-axes.rules
007. agent.registry.workflow-axes.rules
008. agent.skill.closure.rules
009. agent.skill.work.rules
010. agent.workflow.attention-coordination.rules
011. agent.workflow.task-execution.rules
012. agentcore.handoff.recovery.codex.context
013. agentsession.contract.actor-duty.rules
014. annotation-scene.contract.lesson-lineage.rules
015. annotation-scene.contract.stage-interaction.rules
016. annotationcontracts.intent.screen-selection-layergraph-handoff.context
017. annotationkit.drift
018. archive.index.projection
019. archive.rules
020. audit.policy.readonly-dispatch.rules
021. axinspect.drift
022. backup.registry.rules
023. carrier-generalization.rules
024. checklist.registry.placement-checks.rules
025. clipboard-app.rules
026. clipboard-capture-schemas.drift
027. clipboard.intent.data-action-lineage.context
028. cockpit-tree-projection.drift
029. cockpit.policy.agent-session.rules
030. cockpit.projection.agent-session-carrier-map
031. cockpit.projection.engine-ecosystem.map
032. codex.adapter.lightweight-passive-hook.context
033. codex.adapter.lightweight-passive-hook.rules
034. comment.policy.executable-truth.rules
035. commit.algorithm.single-delta-commit
036. component-lineage-graph.drift
037. compose.contract.timeline-authority.rules
038. cursorfollowerhost.policy.dictation-direct-runtime.rules
039. data.registry.axes.rules
040. deep-copy.projection.concept-proof
041. dictation.intent.flagged-target-delivery-handoff.context
042. dictation.policy.hud-surface.rules
043. dictation.policy.notch-surface.rules
044. dictation.registry.deferred-decisions.rules
045. dictation.runtime.user-journey.context
046. dictationhost.policy.runtime-boundaries.rules
047. dictationintegration.drift
048. file.contract.filename-axis-grammar.rules
049. file.projection.filename-segments.source-wide
050. file.registry.axes.rules
051. file.registry.filename-segments
052. file.registry.rename-verdicts
053. file.rules
054. fundamentals.registry.axes.rules
055. ghosttyport.policy.session-binding.rules
056. graph.contract.lineage-closed-universe.rules
057. graph.registry.axes.rules
058. hooks.contract.hook-record.rules
059. hooks.contract.signal-record.rules
060. hooks.contract.visible-output.rules
061. hooks.registry.axes.rules
062. hotkey.projection.assignments
063. hotkey.registry.problems.rules
064. hotkey.rules
065. imprintkit.drift
066. index.rules
067. information.contract.anchor-lineage.rules
068. information.rules
069. inspector.contract.provider-consumer-boundary.rules
070. inspector.runtime.user-journey.context
071. intent-requirement.registry.axes.rules
072. json.rules
073. markdown.contract.claim-status-grammar.rules
074. markdown.policy.rule-surface.rules
075. markdown.registry.problems.rules
076. markdown.registry.semantic-carriers.rules
077. markdown.rules
078. markup-inspector.runtime.user-journey.context
079. markup-runtime.drift
080. media.contract.derived-decode.rules
081. menubar-update.rules
082. motion.registry.solved-effects.rules
083. note.policy.capture-gate.rules
084. onboarding.contract.engine-boundary.rules
085. optionos-api.policy.beta-telemetry-privacy.rules
086. optionos-api.policy.instagram-community-delivery.rules
087. optionos-api.policy.instagram-growth.rules
088. optionos-site.contract.public-content-lineage.rules
089. optionos-site.contract.seo-geo-surface.rules
090. optionos.command.app-icon-family.rules
091. optionos.context.contact
092. optionos.context.development-risk
093. optionos.context.positioning
094. optionos.contract.app-identity.rules
095. optionos.contract.memory-block.rules
096. optionos.contract.storage-lifecycle.rules
097. optionos.handoff.support-pricing.context
098. optionos.policy.legal-disclosure.rules
099. optionos.policy.rollout-phase.rules
100. optionos.registry.deferred-decisions.rules
101. oz.registry.axes.rules
102. package.rules
103. pasteformatcontracts.policy.transcript-attachment.rules
104. performance.contract.live-session.rules
105. precedence.registry.axes.rules
106. preflight.contract.signal-carrier.rules
107. preflight.rules
108. problem-solving.algorithm.cause-identification.rules
109. problem-solving.algorithm.structural-analogy.rules
110. problem-solving.registry.axes.rules
111. problem.rules
112. proof.registry.evidence.rules
113. python.contract.executable-carrier.rules
114. question-ledger.registry.axes.rules
115. raw.policy.prompt-memory.rules
116. rebrand.policy.name-purpose-alignment.rules
117. runtime-proof.projection
118. runtime-proof.rules
119. runtime.contract.boundary-context.rules
120. runtime.contract.build-output.rules
121. runtime.contract.event-signal.rules
122. runtime.contract.operation-budget.rules
123. runtime.contract.user-journey.rules
124. security.macos.rules
125. security.registry.axes.rules
126. security.web.rules
127. service.contract.headless-lifecycle.rules
128. session-hook.rules
129. ship.registry.axes.rules
130. skills.contract.host-skill-projection.rules
131. source.contract.rule-preflight.rules
132. source.policy.migration.rules
133. source.rules
134. swift.contract.main-thread-dispatch.rules
135. swift.contract.type-shape.rules
136. swift.package.rules
137. system.contract.structure.rules
138. system.registry.axes.rules
139. system.registry.problems.rules
140. tabgestures.contract.menu-onboarding.rules
141. term.registry.user-alias.rules
142. terminalport.contract.focus-truth.rules
143. trackpad-gesture-boundary.drift
144. type-shape.policy.static-decision.rules
145. typescript.contract.cli-stdout-drain.rules
146. typescript.contract.type-shape.rules
147. typescript.package.rules
148. ui.contract.accessibility-projection.rules
149. ui.contract.animation-motion.rules
150. ui.contract.excalidraw-canvas-lineage.rules
151. ui.contract.feedback.rules
152. ui.contract.interaction-continuity.rules
153. ui.contract.interface-copy.rules
154. ui.contract.navigation-wayfinding.rules
155. ui.contract.scaled-content.rules
156. ui.contract.settings-route.rules
157. ui.contract.typography.rules
158. ui.contract.visual-craft.rules
159. ui.contract.web-projection.rules
160. ui.contract.window-native.rules
161. ui.registry.axes.rules
162. ui.registry.relation-first-editing.axes.rules
163. verdict.registry.axes.rules
164. vscode.projection.session-chat-tree.rules
165. vscode.registry.problems.rules
166. whisper.policy.decoder-term-prompt.rulesThere is no body content in this list. Copying bodies would leak private value and turn authority into a stale projection. What matters publicly is the scale and the relation shape.
A few safe principle examples:
- [tested] [required] Visibility is the lifecycle ancestor of every below-surface job.
- [tested] [required] Single-writer gate. One owner changes a state; other actors emit events or requests.
- [tested] [required] Authority read order. Read the source that can break the result before projections, memory or notes.
- [tested] [required] Emit → refresh bond. If an event changes visible state, refresh the receiver projection from that causal event.
- [tested] [required] Parallel-writer discipline. Sharing a construction site does not mean sharing file ownership.
Headings carry frozen anchors such as [#...:...]. Rules call related rules through those anchors. A flat file system was not enough: agents sometimes skipped the required file and sometimes injected unrelated rules. I built a mechanism that resolves rule relations instead of loading a file pile.
COS anchor and preflight
COS means Chat Operation System. One of its key commands is anchor. The visual shows the command, consumer, session and selected roots.
Consumer, session and rule roots in a COS anchor command.
consumer records which agent or harness asked for the rules; session records the live conversation consuming them. Anchor roots open their descendant closure — children, grandchildren and required contexts. This lets me measure whether the agent received the right rule lineage.
I apply a telemetry-like model to agents: which agent used which rule? Do rules that travel together have a real relation? We remove unrelated passengers and add missing edges.
A SessionStart hook forces the context gate:
The context gate that forces preflight at SessionStart.
I call this preflight. At the beginning the agent collects my intent, independent rule roots and the target. On a large task, twenty to thirty percent of initial context may be rules. I pay more tokens early so I do not later pay for wandering through the repo, repeating tests and reconstructing lost context. Going in the wrong direction is the most expensive failure.
I tried feeding rules during the task. The agent became confused, forgot the primary target and made coordination harder. Now it collects roots at the beginning, freezes the work, shows me the target once and continues in the same session after approval. I do not erase relevant context merely because tokens are expensive.
Creation is open when I am present, closed when I am absent
When I supervise agents, I use them for creation. I provide the intent, point at the visual target and inspect the outcome. The human owns creation.
When I will not supervise — especially while sleeping — I close creation. Agents do not invent a product or new intent; they only resolve uncertainty. They make runtime states explicit earlier, separate lineages, remove duplicate authority, and add logs and judges.
A refactor agent working inside the same goal for 12 hours 30 minutes.
A goal string alone cannot do this. Repeating one prompt does not preserve a twelve-hour task. The decision-bearing context must be carried dynamically alongside the target.
Do not leave impossible state to runtime
Agents often make every field optional. Soon there are fifty optional values and unreachable combinations surviving until runtime. Bugs become harder to see and an agent can fill absence with a guess.
I close the state with a discriminated union or enum:
type RunState =
| { kind: "idle" }
| { kind: "running"; sessionId: string; startedAt: Date }
| { kind: "failed"; sessionId: string; error: RunError }
| { kind: "completed"; sessionId: string; result: RunResult };
function render(state: RunState): ViewModel {
switch (state.kind) {
case "idle": return idleView();
case "running": return runningView(state.sessionId, state.startedAt);
case "failed": return failedView(state.sessionId, state.error);
case "completed": return completedView(state.sessionId, state.result);
default: return assertNever(state);
}
}The same relation in Swift:
enum RunState {
case idle
case running(sessionID: SessionID, startedAt: Date)
case failed(sessionID: SessionID, error: RunError)
case completed(sessionID: SessionID, result: RunResult)
}
switch state {
case .idle:
showIdle()
case let .running(sessionID, startedAt):
showRunning(sessionID: sessionID, startedAt: startedAt)
case let .failed(sessionID, error):
showFailure(sessionID: sessionID, error: error)
case let .completed(sessionID, result):
showResult(sessionID: sessionID, result: result)
}The exhaustive switch exposes invented folders, missing owners and wrong fallbacks earlier. I call this translating runtime uncertainty into a build-time decision. The agent can do it without inventing behavior: understand the current runtime, translate it into an honest type, then measure the same behavior through logs.
I do not preserve long context as a static document
My COS transcript method takes a session ID and carries only three decision-changing things:
1. My messages. 2. The agent’s messages, because they change my next response. 3. Paths of files changed by the agent.
Most reads, tool traces and temporary rule loads are disposable intermediates. From a context window around 260K tokens, the decision-bearing body can be near 40K. I do not call it a new summary: it does not retell the source. It trims the transcript while retaining the original conversation as evidence.
After compaction, that body returns to the front. Compactions form rolling layers; older layers are dropped gradually. Source diffs are not copied into the packet, only paths. Context becomes a dynamic form that updates with the conversation instead of a static document.
A real private refactor conversation attached during this guide had roughly 91K tokens and exposed messages plus changed file paths. I do not publish its session ID or file list. The mechanism is what matters: human source words are preserved, while reproducible repository truth is carried by the path that can measure it again.
Does the finished work emit a new rule?
After I wake up and the task closes, I ask:
> “Did we discover a rule that is absent from our corpus? Would removing it let the system be built incorrectly?”
The agent proposes candidates and I inspect them personally. A wrong rule can corrupt every later implementation, so I treat it as more important than a single source edit.
When two rules conflict, I treat them like mathematical formulas. If a formula fails in one environment, condition the old formula: valid on this ground, route to the other rule elsewhere. Do not silently kill it; narrow its boundary and make the relation visible.
The second-order effect is that autonomous work accumulates not only code but tested working knowledge. This is valuable only when the human inspects rule candidates and every body stays under one authority.
This article came out of the same loop
I did not type this article. I spoke for roughly twenty-five to thirty minutes while looking at the material in front of me. About ten other agents were working; one fresh agent waited to turn this conversation into content.
The live transcript, capture actions and running agents while this guide was narrated.
While speaking I capture screens, order copied material and draw a rectangle at the moment I say “this part.”
The visual annotation panel and rectangle tool used while speaking.
Then I hand the source conversation — not a rewritten brief — to the fresh agent with all references intact:
A fresh agent ready to turn the thirty-minute conversation into content.
A thirty-minute conversation is not wasted. The agent shapes the article, but the article comes from my speech. The agent does not own intent; it organizes, relates and publishes a dense human intent emission.
Writing is slow when extracting an idea
The first optionOS product is about speech because context is the critical resource, and the most important context is the idea inside a human mind. Writing is slow when extracting that idea, so I speak.
Speech alone is not enough. People need to see something to remember it, so they need to speak while looking. I narrated this from agent outputs, screenshots and visual results rather than source code. The material sat in front of me like a presentation, but I was not reading text — I was looking and speaking from memory.
Text makes me think consciously, and that slows the production flow. I try to make the human surface visual, animated and intuitive. The user should not need to touch source code. Select the visual object, say “this is broken,” and let the system find the object’s code lineage.
I call this the Inspector: a path from the visual object to its source relation, like a DOM inspector expanded beyond the browser. A photo, a rectangle and speech arriving together can produce context incredibly quickly.
Human production must be captured continuously
The conversation history joins speech, visual references, source applications and rectangle events:
The history panel joining speech, visual references and drawing events.
Continuous recording prevents a computer or network failure from destroying thirty minutes of human production. This matters deeply to me: human production is incredibly valuable and must be collected smoothly and quickly.
The local panel showed 39 hours 34 minutes because I archive large collections manually. Across roughly six months, the total is around 350–400 hours and about 1.5 million words. That cannot be reconstructed later; the source emission must be captured when it happens.
Try the work method now
The primary product here is not one application but the working method. While awake, the human owns intent and growth. While asleep, agents do not invent intent; they improve resilience, visibility and certainty. Lineage protects scope, preflight selects the right rules, and the dynamic transcript protects long context.
Do not wait to try it. Start with one small workflow: speak while looking, capture friction immediately and separate responsibility lineages. To use optionOS systems, contact me or join the invitation list at optionos.app. Mention this guide and I will try to prioritize you on the waitlist.