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

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

Canonical: https://optionos.app/guide/en/agent-harness-loop
Published: 2026-07-25
Source: optionos-product:r19

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

```text
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](https://optionos.app/guide/agent-harness-goal-12h.png)
*The same goal, visible plan and reopened rules remain present twelve hours later.*
Interactive scene: https://optionos.app/guide/en/agent-harness-loop#agent-harness-goal-12h

## 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](https://optionos.app/guide/agent-harness-sentetik-user.png)
*Selected agent → anchor call → plan → stepper → active stage → another rule call.*
Interactive scene: https://optionos.app/guide/en/agent-harness-loop#agent-harness-sentetik-user

## The rule heading is also an index

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

```text
[#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](https://optionos.app/guide/agent-harness-kural-blogu.png)
*The rule heading and two related anchors in its body.*
Interactive scene: https://optionos.app/guide/en/agent-harness-loop#agent-harness-kural-blogu

## 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](https://optionos.app/guide/agent-harness-agents-basliklar.png)
*The `AGENTS.md` tab and routing lines that carry only the “when to open” information.*
Interactive scene: https://optionos.app/guide/en/agent-harness-loop#agent-harness-agents-basliklar

## 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:

```text
✓ 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](https://optionos.app/guide/agent-harness-context-compact.png)
*Context compacted → PostCompact stopped → deliberate interruption.*
Interactive scene: https://optionos.app/guide/en/agent-harness-loop#agent-harness-context-compact

## `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:

```text
<<<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](https://optionos.app/guide/agent-harness-devam-cap.png)
*`continue` → SessionStart → continuation-safe selection → raw conversation lines.*
Interactive scene: https://optionos.app/guide/en/agent-harness-loop#agent-harness-devam-cap

## 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:

```text
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.