optionOS optionOS

How my agents stay on track across context changes: anchor, stepper and conversation-cap

How do I work?
EditorClaude Code · Fable 5 EditorCodex
Experimental

Can AI turn my rapid speech and the regions I mark on screen into accurate, publishable content?

Tags
  • WORKFLOWRepeatable working flow.
  • AI-DEVELOPMENTAI development practice.
  • AGENTSThe surface for working with AI agents.
  • EVIDENCE-UIUnderstood through visual evidence.
  • ANNOTATIONMark, number, box or arrow tied to a speech moment.
  • CONTEXT-FORESTMulti-document AI context forest.
  • ACTIVE-USECurrently in use.

A goal alone is not what keeps an agent on target for twelve hours. My optionOS harness preserves three relationships together:

select the right rules
+ carry the work in a visible plan
+ return the valuable conversation after compaction without summarizing it

The agent below has been working alone on a refactor for roughly twelve hours. It still presents previews, shows its active step, reopens rule anchors encountered in the conversation, and continues pursuing its goal.

A Codex agent still pursuing the same goal after twelve hours Pursuing goal (12h 15m) — autonomous for 12 hoursAnother conversation's tab — the agent works in the backgroundNo action needed from you [5/6] — progress that does not wait for a humanThe D58 preview block — still publishing previews while it works[#kural:onizleme] — a rule tag inside the conversation
Goal: infinite progression
The logic of the goal is this: after a stop the agent must be able to continue on its own. Otherwise we would have to type "continue" every single time. The whole target content is already embedded inside the conversation; even when its time runs out, compaction arrives and afterwards the goal says "continue". This agent has been working like that for 12 hours — a simple refactor, moving files according to their lineage tree.
Bottom right: Pursuing goal (12h 15m)
The same goal, visible plan and reopened rules remain present twelve hours later.

The active goal, visible plan, preview and reopened rule anchors of a twelve-hour agent in one terminal view.

## Goal is the motor; the harness preserves direction

I work with roughly 15 agents at the same time. The synthetic user in the visual is only one of them. Before starting its own work, every agent selects the rules that apply to that work.

I use an anchor architecture for this. I do not dump the entire rule corpus into every agent context. The agent calls the anchors required by its current stage and task; the tool returns only the relevant rule blocks and their relationships.

The anchor, plan and stepper flow of the synthetic-user agent The "sentetik user" tab — one of fifteen agentsThe anchor command — the agent pulls the rule roots the task needsUpdated Plan — the plan we use to track the agent's own behaviorThe stepper [2/8] — past steps ✓, cursor ▶, future steps ○Cursor: ▶ 3 Deterministic product control — the current stageThe anchor call repeated in the same conversation — rules are re-read at every stage
One of fifteen agents
Right now I have an agent working on the synthetic user — one of my fifteen agents. Many agents are open across tabs and all of them work at the same time. While I am talking, they keep producing work in the background.
Every tab is a separate agent; this one is the synthetic-user agent
Selected agent → anchor call → plan → stepper → active stage → another rule call.

The selected agent, anchor call, plan, stepper, active stage and repeated rule routing in one work sequence.

## The rule heading is also an index

Every rule begins with a Markdown heading. Four pieces of information appear together in that heading:

[#rule-key] · evidence state · importance · when it should be opened

An anchor call returns not only the heading but also the rule content beneath it. If the rule refers to other anchors, the closure is followed and the related rule blocks enter the same context.

A rule is therefore not an isolated piece of prose. It is an addressable node with relationships to other rules.

Markdown heading anchors and relations inside a rule body The rule heading = the anchor: [#kural:yasam-dongusu] [tested] [required] [@rule]Relation: [#kural:anchor-routing] — a link from inside one rule to anotherRelation: [#kural:tek-ata] — lineage is also wired through anchors
Anchors, indexes
For rules I use my own anchor architecture; I use markdown headlines. Next to the anchor the heading carries labels: [tested] says the rule survived a real case, [required] states its weight, [@rule] names the working moment when it must be opened. The part after the heading is the information about when the rule is used.
Every rule starts with an anchor: a markdown headline plus labels
The rule heading and two related anchors in its body.

A rule heading and two anchor relationships in its body are inspected in sequence on the same source view.

## AGENTS.md does not carry every rule body

AGENTS.md is not a second copy of the full rule corpus. The agent sees a compact routing projection there: the rule key and the conditions under which it should be opened.

The actual rule content remains in its own authority. The anchor retrieves a rule when the agent's command or current context requires it.

This reduces two problems:

1. Filling every task context with irrelevant rules. 2. Copying rule authority into multiple files and creating drift.

The compact rule-routing projection inside AGENTS.md The AGENTS.md tab — the file where the headings liveA heading line: anchor + labels + when the rule must be opened
Home of the headings
The information about when each rule must be opened lives in my AGENTS.md file. The rule bodies are not here; they stay under a single authority. Right now I am inside my AGENTS.md file.
AGENTS.md: the routing surface handed to the agent
The `AGENTS.md` tab and routing lines that carry only the “when to open” information.

The compact routing projection in AGENTS.md carries rule keys and opening conditions instead of copying rule bodies.

## The plan is critical; the stepper is visible state in the conversation

The agent creates a plan while it works. The plan is not merely a to-do list; it is visible state showing the scope within which the agent continues its behavior.

I also display a stepper in the conversation:

✓ closed work
▶ the active bottleneck
○ future work

In the example, the agent is at [2/8] and moving through the third stage. The earlier steps, current position, and complete remaining scope are visible on the same surface.

This record remains important after compaction. The new context can read not only the goal text but also where the agent stopped. At every stage change, the agent calls the required rule anchors again.

## Compaction is a planned stop

When the context fills, Codex reaches Context compacted. My PostCompact hook deliberately stops the agent at that point.

The reason is injection timing: additional context can land too late while the agent continues running. Once the agent stops, the new context can be inserted in the correct place for the next start.

The Conversation interrupted line in the terminal is therefore not an unexpected failure here. It is a deliberate boundary in the continuation chain.

A Codex agent deliberately stopped by the PostCompact hook after context compaction The conversation tab — the agent whose context is running outContext compacted — the moment the context endsPostCompact hook (stopped) — the hook that deliberately stops the conversationConversation interrupted — the stop that makes injection possible
The compact mechanism
The logic is this: when the agent's context runs out, my compact mechanism takes over. Here is one of my agents — its context has just ended.
The agent's context is about to fill up
Context compacted → PostCompact stopped → deliberate interruption.

Context compacted, the PostCompact hook and the deliberate conversation interruption at one lifecycle boundary.

## continue opens the new context

Two paths use the same motor after the stop:

- I can write continue. - An active goal can automatically start the agent again after the stop.

At the next start, the SessionStart hook runs and injects the conversation-cap context:

<<<optionos:conversation-cap>>>
selection: continuation-safe
… +1148 lines

conversation-cap is not an LLM summary. It is an entirely algorithmic selection and dump mechanism.

Preserved:

- human messages, - agent answers that changed the human's reaction or next decision, - open decisions and context that affects continuation, - required lineage and file paths.

Discarded:

- disposable file-read output, - repeated tool noise, - intermediate carriers that do not change the next decision.

The goal is not to grow the complete transcript without limit. It is to carry the signal that formed the behavior into the next context without retelling it.

A Codex agent restarting with conversation-cap after the continue message A single message: devam (continue)SessionStart hook (completed) — my own system kicks in<<<optionos:conversation-cap>>> — a trimming algorithm with no LLM inside+1148 lines — the conversation body handed back
A one-word continue
After the context stops, the message I type here is just "devam" — continue. I ask for no summary and write no reminder; the system handles the rest.
After compaction the only thing I type is: continue
`continue` → SessionStart → continuation-safe selection → raw conversation lines.

The continue message, SessionStart hook, continuation-safe selection and raw conversation lines returned at the same start.

## The goal's job here is not to be memory

The goal's primary role is to make the agent run again after a stop. The complete target context already lives in the conversation.

The roles in the chain are therefore different:

goal              → continuation motor
plan + stepper    → where the agent stopped
rules + anchor    → which boundaries apply now
conversation-cap  → the historical context that formed the decision

An agent can run if only one of these remains, but it is not guaranteed to preserve direction. The harness reunites all four pieces at the same continuation moment.

## What do I see after twelve hours?

The long-running agent still:

- presents its own preview, - carries its [5/6] position, - sees rule markers such as [#kural:onizleme] in the conversation, - calls the rule tool again when necessary, - continues in the Pursuing goal (12h 15m) state.

This does not prove that the agent will never drift. It does reduce drift risk by reuniting the goal, plan, rules, and human conversation after context resets.

I do not yet have a measurement showing that it reduces token usage. My hypothesis is that preventing the agent from repeating the same research may lower the total load; I will not publish that as a measured fact.

## This is my current optionOS harness

I continually develop this system and make it more shareable. Two main blockers remain:

1. Proof: Showing that the mechanism actually works across different agents. 2. Invisible dependencies: Removing dependencies that exist on my computer but are absent from another installation.

As those pieces are resolved, I will publish components of the harness inside the optionOS ecosystem. For now, this Guide is a draft/evidence surface showing the working mechanism and its boundaries.