Steering drafted from corrections
Oxagen now drafts steering from what people correct mid-run, reads refusals and failing tools across runs each night, and serves steering only to the agents it wraps.
Your team keeps a rules file for its coding agents. It started at twenty lines. It is now four hundred, and nobody can say which lines change what an agent does. Meanwhile the same things keep happening. An agent asks to push straight to a release branch, a hook refuses it, and the next run asks again. An engineer types "open a pull request, do not push to main" into the third session this week. The correction works for that run and is gone by the next.
The record already holds the answer to which rules are missing. People correct agents in the middle of a run, and agents hit the same refusal run after run. Oxagen 5.5.0 reads both, drafts the steering record that would have prevented them, and puts the draft in front of a person to accept or decline.
#How steering is drafted from corrections
The first version of this feature counted. A sentence a person sent to three or more runs became a suggested steering record. Most sentences that pass that count are kickoffs: the same opening prompt pasted into every session. A kickoff repeats because people reuse it, so its count says nothing about how the agent behaved.
The useful signal comes later in a run. Laban and colleagues found that models given an instruction over several turns commit to an early assumption and then lean on it.1 The message a person sends at turn four, after watching the agent go the wrong way, is the one that names the mistake. So stella, the assistant in the Oxagen app, now drafts a steering record only from a person's corrections. That means a prompt that opened the second turn of a session or a later one, or a message the person sent while the agent was still working. A run's first prompt never counts.
Text a harness wrote is removed before any sentence is matched. Task notifications, pasted-file markers, and tags the harness injected into the prompt no longer reach a draft. A sentence still has to appear in three runs across more than one sitting, but that floor now only limits how many sentences go to the judge. The count is evidence, and it is never the reason a draft opens.
The limit is the harnesses. Claude Code records a message delivered inside a running turn with its words. Codex, Cursor, and Stella can tell the first turn from later turns, but none can yet say which prompts arrived mid-turn. Cursor and Stella prompts name no sender, so the detector reads none of them. A person who corrects agents with the same words in fewer than three runs gets no draft.
#How a model judge screens each draft
Every draft, whether it came from corrections, a repeated steer, or a refusal, now passes a model judge before a person sees it. The judge reads the drafted record beside the records already in force and answers pass or fail with a one-sentence reason. A passing draft opens with that reason in its rationale. A failing draft is stored as declined, and its text is blocked from being suggested again.
A judge model is a filter, not an authority. Zheng and colleagues showed that model judges agree with people often enough to be useful, and also that they show position, verbosity, and self-enhancement biases.2 So the judge's verdict only decides what a person is asked about. Nothing changes until a person accepts the draft.
The judge also reads text that came from runs: refusal messages, error lines, commands, and tool descriptions. Greshake and colleagues showed that text an application retrieves can carry instructions the model will follow.3 The judge's prompt marks every piece of run text as data, and its answer can only draft words a person still reviews.
#How repeated refusals become steering
A refusal is one frame in one run. Nobody reads across runs, so an agent refused the same command in ten sessions looks like ten separate small events. The nightly findings pass now reads every refused call, every setup command that failed for a reason the repository can fix, and every MCP tool that fails often. It writes them as three findings: repeated refusals, recurring setup failures, and failing tool calls.
The thresholds are stated and are a first pass. A repeated refusal is five or more refusals with one key in three or more runs, with one of them in the last seven days. A recurring setup failure shows up in three or more runs on two or more days. A failing tool has ten or more calls in seven days across three or more runs, with a fifth or more failed or refused.
A refusal can come from Oxagen's own rule or from the harness, such as a local hook. The fix depends on which, so the fix builders try a set order and offer the first that applies.
The order the fix builders try for a repeated refusal
- Guardrail changeOnly for an Oxagen rule that asks a person first, and only when people approved 80 percent or more of the requests it held.
- Raise the record's forceA steering record covers the rule, but most refusing runs did not receive it.
- Change the record's wordsThe runs received the record and still asked.
- New steering recordNo record covers the rule.
The guardrail change comes first because approvals are direct evidence that people want the call to go through. Teaching an agent to stop asking for something people keep approving would be the wrong fix. The second step exists because a record an agent never received cannot change what it asks for. When many rules compete for one context, models follow fewer of them as the count grows, and they favor some positions over others.45 The assembler ranks records and cuts some to fit a token budget, and the delivery record says which were cut and why. A record that keeps getting cut is moved up.
Each drafted fix arrives on the Console as a card. At most three of these cards wait on one person at a time, and the pass drafts at most ten fixes per workspace a day. A guardrail fix applies only to requests on a capability Oxagen governs. A refused shell command goes to the steering fixes, because no rule in Oxagen names a shell command.
#Who can read steering
Until this release, any workspace key could read steering. A person who pasted a key into an agent's MCP config got the workspace's records in an agent Oxagen did not wrap, and so did a script. Nothing recorded what those callers did with them.
Steering reads now answer three callers: a person in the Oxagen app, stella acting for that person, and a run of Claude Code, Codex, Cursor, or Stella that Oxagen wraps, through the recorder's local gateway.6 Every other caller is refused, Claude Desktop included. Reads serve the versions on the steering repository's main branch at the moment of the read, so a record changed mid-run reaches the run in its new form.
Each gateway entry names its harness, and the server reads that name. The name sits in a config file the person owns, so it is policy, not a security boundary. It keeps steering out of an app whose use of it Oxagen does not record, and it claims nothing more. Machines on an older recorder keep their steering until their entries are rewritten.
This is a breaking change for anyone who read records, skills, or suggestions with a key over the API or MCP. Those calls now get no_wrapped_run. The tool that wrote a record straight into the registry is gone too. A record now reaches agents only through a commit on the steering repository's main branch.
#How to add skills from the registry
Every workspace now has a skill registry, and it starts as skills.sh, a public directory of agent skills.7 A person searches it from the app, picks a skill, and adds it. Skills follow the Agent Skills format: a folder with a SKILL.md file and any text files it needs.8
Adding a skill does not install it on agents directly. Oxagen reads the skill's files from its public GitHub repository and opens a pull request against the workspace's steering repository, and a reviewer decides whether to merge it. A skill holds text files only, within set size and count limits. A skill grants no authority either. "You may merge" written in a skill changes nothing, because the agent's toolbelt decides what it may do.
The full list of changes is in the Oxagen 5.5.0 release post.
#References
-
Laban, P., Hayashi, H., Zhou, Y., & Neville, J. (2025). LLMs Get Lost In Multi-Turn Conversation. arXiv. https://arxiv.org/abs/2505.06120 ↩
-
Zheng, L., Chiang, W.-L., Sheng, Y., Zhuang, S., Wu, Z., Zhuang, Y., Lin, Z., Li, Z., Li, D., Xing, E. P., Zhang, H., Gonzalez, J. E., & Stoica, I. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023 Datasets and Benchmarks. https://arxiv.org/abs/2306.05685 ↩
-
Greshake, K., Abdelnabi, S., Mishra, S., Endres, C., Holz, T., & Fritz, M. (2023). Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. AISec 2023. https://arxiv.org/abs/2302.12173 ↩
-
Jaroslawicz, D., Whiting, B., Shah, P., & Maamari, K. (2025). How Many Instructions Can LLMs Follow at Once? arXiv. https://arxiv.org/abs/2507.11538 ↩
-
Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2023). Lost in the Middle: How Language Models Use Long Contexts. TACL 2024. https://arxiv.org/abs/2307.03172 ↩
-
Oxagen (2026). Wrap an agent. Oxagen documentation. https://docs.oxagen.sh/docs/cli/wrap-an-agent ↩
-
skills.sh (2026). The Agent Skills Directory. skills.sh. https://skills.sh ↩
-
Agent Skills (2025). Specification. agentskills.io. https://agentskills.io/specification ↩

